Hi, This problem has already been reported here more than 1 year ago by Brian J. Lopes: https://stat.ethz.ch/pipermail/r-sig-mac/2007-May/003863.html It's still present in R 2.8.0 beta (2008-10-07 r46631) on Mac OS X as you can see on the last build/check report for the xps package (Biosconductor): http://bioconductor.org/checkResults/2.3/bioc-LATEST/xps/pitt-buildsrc.html xps has a Makefile in its src/ folder (with a "clean:" target) and 'make clean' works fine for me if I run it manually from within the src/ folder on build machine pitt. However, 'R CMD build' fails to clean the src/ folder because it's apparently trying to access /Library/Frameworks/R.framework/Versions/2.8/Resources/etc/Makeconf instead of /Library/Frameworks/R.framework/Versions/2.8/Resources/etc/<arch>/Makeconf Are there any chance that this could be addressed? Thanks in advance, H.
'R CMD build <mypkg>' fails to 'make clean' when <mypkg> has a Makefile
5 messages · Hervé Pagès, Brian Ripley
On Fri, 17 Oct 2008, Herve Pages wrote:
Hi, This problem has already been reported here more than 1 year ago by Brian J. Lopes: https://stat.ethz.ch/pipermail/r-sig-mac/2007-May/003863.html
Maybe, but (AFAICS, see also below) no one submitted a patch to the appropriate list (r-devel) nor even a 'wish' to R-bugs.
It's still present in R 2.8.0 beta (2008-10-07 r46631) on Mac OS X as you can see on the last build/check report for the xps package (Biosconductor):
Why are you using a test version over a week old? CRAN tests on the current (when the test round started) version of R.
http://bioconductor.org/checkResults/2.3/bioc-LATEST/xps/pitt-buildsrc.html xps has a Makefile in its src/ folder (with a "clean:" target) and 'make clean' works fine for me if I run it manually from within the src/ folder on build machine pitt. However, 'R CMD build' fails to clean the src/ folder because it's apparently trying to access /Library/Frameworks/R.framework/Versions/2.8/Resources/etc/Makeconf instead of /Library/Frameworks/R.framework/Versions/2.8/Resources/etc/<arch>/Makeconf Are there any chance that this could be addressed?
A chance, but not in code freeze for 2.8.0. (Your timing is the worse possible.) That's an unusual setup (developing on a system with sub-architectures). If you submit a tested patch it is more likely to be 'addressed' once the R-2-8-branch is open again.
Thanks in advance, H.
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
2 days later
Hi,
Prof Brian Ripley wrote:
On Fri, 17 Oct 2008, Herve Pages wrote:
Hi, This problem has already been reported here more than 1 year ago by Brian J. Lopes: https://stat.ethz.ch/pipermail/r-sig-mac/2007-May/003863.html
[...]
Are there any chance that this could be addressed?
A chance, but not in code freeze for 2.8.0. (Your timing is the worse possible.) That's an unusual setup (developing on a system with sub-architectures).
Are you saying that developing on Tiger (or Leopard) is unusual?
If you submit a tested patch it is more likely to be 'addressed' once the R-2-8-branch is open again.
Thanks! H.
On Mon, 20 Oct 2008, Herve Pages wrote:
Hi, Prof Brian Ripley wrote:
On Fri, 17 Oct 2008, Herve Pages wrote:
Hi, This problem has already been reported here more than 1 year ago by Brian J. Lopes: https://stat.ethz.ch/pipermail/r-sig-mac/2007-May/003863.html
[...]
Are there any chance that this could be addressed?
A chance, but not in code freeze for 2.8.0. (Your timing is the worse possible.) That's an unusual setup (developing on a system with sub-architectures).
Are you saying that developing on Tiger (or Leopard) is unusual?
Well, yes (and we know that because of the non-standard tarballs those systems produce by default and which R CMD build now works around). But my observation was based on the fact that everyone I know who develops on Mac OS X (and almost everyone on Windows) builds R from the sources to suit their own preferences (and since that will be for the one architecture they are working on and sub-architectures are not the default), such people don't have sub-architectures. It's not just Mac OS: I have 32- and 64-bit versions on Linux and Solaris, but I keep them separate for development (and e.g. RH/Fedora has gone a different route for multi-architecture support that is tantamount to separate installs with a common front-end script).
If you submit a tested patch it is more likely to be 'addressed' once the R-2-8-branch is open again.
I think this is probably covered in changes now made in R-devel, but please do check for us.
Thanks! H.
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
2 days later
Hi,
Prof Brian Ripley wrote:
On Mon, 20 Oct 2008, Herve Pages wrote:
Hi, Prof Brian Ripley wrote:
On Fri, 17 Oct 2008, Herve Pages wrote:
Hi, This problem has already been reported here more than 1 year ago by Brian J. Lopes: https://stat.ethz.ch/pipermail/r-sig-mac/2007-May/003863.html
[...]
I think this is probably covered in changes now made in R-devel, but please do check for us.
We will, as soon as our builds are up and running with R-2.9 on macosx. I'll post again here to confirm. Thanks! H.