Skip to content

R RC: make all

6 messages · Uwe Ligges, Peter Dalgaard, Brian Ripley +1 more

#
Looks like
   make all
does not imply
   make recommended
in the RC version of R-2.5.0 ...

Uwe
#
Uwe Ligges wrote:
Eh? What makes you say that?


all: Makefile Makeconf R docs recommended
recommended: @USE_RECOMMENDED_PACKAGES_TRUE@ stamp-recommended
#
On Mon, 23 Apr 2007, Uwe Ligges wrote:

            
It never did on Windows, seems still to on Unix (I've just tested it 
under our Intel compilers, newly updated so they work again on Fedora Core 
5).

Brian
#
Peter Dalgaard wrote:
Apologies! This happens if doing things too quickly.

I was talking about ./src/gnuwin32/Makefile and just recognized that 
'make recommended' was never part of 'make all', just of 'make 
distribution'. I was somehow mixing it with the Linux version, 
obviously. My autobuilder usually builds R for me, hence I am unused to 
do it manually.

Uwe
#
On 4/23/2007 8:51 AM, Peter Dalgaard wrote:
This is true in the Windows src/gnuwin32/Makefile, but it's not new. 
The only target that depends on "recommended" is "distribution", and it 
does it by forcing "make recommended" every time, whether needed or not.

"make all" also misses "bitmapdll" (which I think has no equivalent in 
Unix?), "manuals" (part of "docs" in Unix), and installer related targets.

It would probably be reasonable if "make all" were more consistent 
across platforms, but "make recommended" is quite slow, so I'm not sure 
I would like it to be in the default ("all" is the default target).

Another argument in favour of including "recommended" in the default is 
that currently "make ; make check" fails in Windows, because some of the 
checks depend on recommended packages.

Duncan Murdoch
#
On Mon, 23 Apr 2007, Duncan Murdoch wrote:

            
'make manuals' is equivalent to 'make pdf' on Unix.
This could be overcome by using timestamps, as on Unix.  However, those do 
not work entirely right on Unix, as they only check if the package sources 
have been updated, and not that R has been changed in a way that needs the 
package to be regnerated (e.g. the C headers have changed, or methods need 
to be re-dumped).  So I have been reluctant to change to a known flawed 
system.  (Originally the Windows toolkit was missing 'touch', which you 
would need to do timestamps right.)