Skip to content

[Bioc-devel] portable make syntax

7 messages · Laurent Gatto, Kevin Ushey, Dan Tenenbaum +3 more

#
Dear all,

I have been using the following in various vignettes/Makefile

ifeq (${R_HOME},)
R_HOME= $(shell R RHOME)
endif

This syntax is GNU specific and now results in warnings when checking
the package:

* checking for GNU extensions in Makefiles ... WARNING
Found the following file(s) containing GNU extensions:
  vignettes/Makefile
Portable Makefiles do not use GNU extensions such as +=, :=, $(shell),
$(wildcard), ifeq ... endif. See section ?Writing portable packages? in
the ?Writing R Extensions? manual.

I couldn't find anything in R-exts; does anyone know a more portable
syntax?

Alternatively, I could add

SystemRequirements: GNU make

to my DESCRIPTION file, which however does not seem ideal.

Any suggestions?

Thank you very much in advance.

Laurent
#
If I understand correctly, all versions of `make` on the BioC build
systems will support GNU extensions to Makefiles, and so it's probably
not worth your time to make this 'portable' -- just add the
SystemRequirements bit.

However, you could work around this by (following R-exts at
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-portable-packages)
wrapping your shell command in backticks, e.g.

    R_HOME=`if test -z ${R_HOME}; then ...; else ...; fi`

or something to that effect.
On Fri, Jan 23, 2015 at 4:05 PM, Laurent Gatto <lg390 at cam.ac.uk> wrote:
#
----- Original Message -----
BTW, the warning was added in recent versions of R-devel and I don't know why it was added. 
It could be that GNU extensions may not be supported in future versions of Rtools (the windows
toolchain maintained by Duncan Murdoch). I really have no idea. But since a warning was added, it's probably a good idea to find out why rather than to ignore it. So it might be worth a note to R-devel asking about the intention of that warning.

Dan
#
On Fri, Jan 23, 2015 at 5:18 PM, Dan Tenenbaum <dtenenba at fredhutch.org> wrote:
Very unlikely -- I am really not sure of what the motivation is,
beyond R wanting to support platforms with versions of make that do
not support GNU extensions (whichever those might be... BSD make? AT&T
make on Solaris? See:
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT51)

I am guessing that the Windows toolchain will continue to be based off
of MinGW + GCC for the foreseeable future, and hence will continue to
allow GNU extensions. In fact, R-exts specifically prescribes GNU
extensions for Windows makefiles -- from R-exts,

    Since the only viable make for Windows is GNU make, it is
permissible to use GNU extensions in files Makevars.win or
Makefile.win.

so I really doubt Windows would ever foresake GNU extensions.

Kevin
#
Here is a quote from Brian's email to CRAN maintainers:

------------

The set of make programs in use for R is shifting (BSD make seems to
be no longer in use by Apple or FreeBSD; dmake and pmake variants are
appearing) and we have taken the POSIX standard as the baseline for
portability.

------------

It sounds like this is a CRAN-specific requirement. Bioc of course is
left to make its own decision on make support.

If we absolutely need GNU Make, we can add this to DESCRIPTION:

SystemRequirements: GNU make
On Fri, Jan 23, 2015 at 6:13 PM, Kevin Ushey <kevinushey at gmail.com> wrote:
#
On 01/23/2015 06:22 PM, Michael Lawrence wrote:
I think that most make files can be made to conform easily to POSIX standards, 
which seems in general like a good idea (Linux flavored packages build from 
source, so the compilers on the Bioc build machines are a poor guide to those 
encountered in the wild).
...remembering that this merely quietens the note, and we would rather address 
the issue.

I haven't looked at the build reports, but the it looks like the following 
(including several apparently following poorly worded instructions in Rsamtools; 
aargh) can be easily brought into conformance through use of ` rather than $(shell).

$ ls */src/Makevars|xargs grep -l shell
ArrayExpressHTS/src/Makevars
ChemmineR/src/Makevars
DiffBind/src/Makevars
eiR/src/Makevars
flipflop/src/Makevars
mosaics/src/Makevars
qrqc/src/Makevars
QuasR/src/Makevars
VariantAnnotation/src/Makevars

Martin

  
    
#
As Martin says, it looks like the difference between GNU makefiles and
portable makefiles are very minor for most usages.  What we just need is
some easy accessible comments on how to do it portable, perhaps on the
HOWTOs.  I see no need to sacrifice portability when the fixes are so easy.

Best,
Kasper

On Fri, Jan 23, 2015 at 10:36 PM, Martin Morgan <mtmorgan at fredhutch.org>
wrote: