[Bioc-devel] portable make syntax
Gordon Brown
Gordon.Brown at cruk.cam.ac.uk
Tue Jan 27 15:39:00 CET 2015
From: Martin Morgan <mtmorgan at fredhutch.org<mailto:mtmorgan at fredhutch.org>>
Date: Tuesday, 27 January 2015 12:04
To: Gord Brown <gordon.brown at cruk.cam.ac.uk<mailto:gordon.brown at cruk.cam.ac.uk>>, "bioc-devel at r-project.org<mailto:bioc-devel at r-project.org>" <bioc-devel at r-project.org<mailto:bioc-devel at r-project.org>>
Subject: Re: [Bioc-devel] portable make syntax
On 01/27/2015 02:58 AM, Gordon Brown wrote:
Hi, Martin et al,
At the risk of revealing myself to be an idiot in public... I just cannot get
back ticks to work on an "include" line in a "Makevars" file.
The file contains these lines:
-----------------------------------------
SAMVARS = `echo 'cat(system.file("usretc", .Platform[["r_arch"]],"Rsamtools.mk",
package="Rsamtools", mustWork=TRUE))' | "$(R_HOME)/bin/R" --vanilla --slave`
include $(SAMVARS)
-----------------------------------------
as shown in the Rsamtools "Using samtools C libraries with Rsamtools" document.
But the "include" line is parsed by make, which ignores the back ticks, not by
the shell, as seen in the following snippet:
Also it seems like include() is an extension too (though used in the R source)?
I guess the backtick example from R-exts implies variable use in the target,
where shell processing occurs, rather than in the Makefile. So perhaps something
like
SAMTOOLS_PATH=\
`echo 'cat(system.file("usrlib", .Platform[["r_arch"]],\
package="Rsamtools", mustWork=TRUE))' |\
"${R_HOME}/bin/R" --vanilla --slave`
PKG_LIBS="$(SAMTOOLS_PATH)/libbam.a" "$(SAMTOOLS_PATH)/libbcf.a"\
"$(SAMTOOLS_PATH)/libtabix.a" -lz -pthread
PKG_CPPFLAGS=-D_USE_KNETFILE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
(which removes a level of indirection provided by SAMVARS= / include $(SAMVARS))
is closer to best practice?
Martin
I don't feel qualified to comment on what is best practice, but this does work, so it's good enough for me! Many thanks. I'll commit a fix as soon as I've checked some other changes with my co-author.
Cheers,
- Gord
-----------------------------------------------------------------
uk-cri-lsrv10 ~/packages $ R CMD build DiffBind
* checking for file 'DiffBind/DESCRIPTION' ... OK
* preparing 'DiffBind':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
-----------------------------------
* installing *source* package 'DiffBind' ...
** libs
Makevars:2: `echo: No such file or directory
Makevars:2: 'cat(system.file("usretc",: No such file or directory
Makevars:2: .Platform[["r_arch"]],"Rsamtools.mk",: No such file or directory
Makevars:2: package="Rsamtools",: No such file or directory
Makevars:2: mustWork=TRUE))': No such file or directory
Makevars:2: |: No such file or directory
Makevars:2: "/usr/local/lib64/R/bin/R": No such file or directory
Makevars:2: --vanilla: No such file or directory
Makevars:2: --slave`: No such file or directory
make: *** No rule to make target `--slave`'. Stop.
ERROR: compilation failed for package 'DiffBind'
* removing '/tmp/RtmpJaAJ8I/Rinst297e5010e355/DiffBind'
-----------------------------------
ERROR: package installation failed
-----------------------------------------------------------------
Reading through the make source code, there doesn't seem to be any attempt to
evaluate the back tick-ed expression after macro expansion but before splitting
into filenames, as seems clear from the errors above. Nor can I see any
POSIX-compatible way to force evaluation of the expression (reading from this
page: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html ). I
see the same behaviour if I use an actual Makefile as opposed to Makevars.
As you noted, I was indeed following the instructions in the Samtools docs... I
must be doing something simple wrong, but just can't see it. Can you give me a
hint as to what I should be doing differently?
Thanks in advance,
- Gord Brown
Details:
R v3.1.2, and also the latest devel version
gnu make 3.81, 3.82, 4.1
centos linux 6.6
*
*
Message: 3
Date: Fri, 23 Jan 2015 19:36:46 -0800
From: Martin Morgan <mtmorgan at fredhutch.org<mailto:mtmorgan at fredhutch.org> <mailto:mtmorgan at fredhutch.org>>
To: Michael Lawrence <lawrence.michael at gene.com<mailto:lawrence.michael at gene.com>
<mailto:lawrence.michael at gene.com>>, Kevin Ushey
<kevinushey at gmail.com<mailto:kevinushey at gmail.com> <mailto:kevinushey at gmail.com>>
Cc: bioc-devel <bioc-devel at stat.math.ethz.ch<mailto:bioc-devel at stat.math.ethz.ch>
<mailto:bioc-devel at stat.math.ethz.ch>>
Subject: Re: [Bioc-devel] portable make syntax
Message-ID: <54C3134E.8080604 at fredhutch.org<mailto:54C3134E.8080604 at fredhutch.org>
<mailto:54C3134E.8080604 at fredhutch.org>>
Content-Type: text/plain; charset="utf-8"; format=flowed
On 01/23/2015 06:22 PM, Michael Lawrence wrote:
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.
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).
If we absolutely need GNU Make, we can add this to DESCRIPTION:
SystemRequirements: GNU make
...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
On Fri, Jan 23, 2015 at 6:13 PM, Kevin Ushey <kevinushey at gmail.com<mailto:kevinushey at gmail.com>
<mailto:kevinushey at gmail.com>> wrote:
On Fri, Jan 23, 2015 at 5:18 PM, Dan Tenenbaum
<dtenenba at fredhutch.org<mailto:dtenenba at fredhutch.org> <mailto:dtenenba at fredhutch.org>> wrote:
----- Original Message -----
From: "Kevin Ushey" <kevinushey at gmail.com<mailto:kevinushey at gmail.com>
<mailto:kevinushey at gmail.com>>
To: "Laurent Gatto" <lg390 at cam.ac.uk<mailto:lg390 at cam.ac.uk> <mailto:lg390 at cam.ac.uk>>
Cc: "bioc-devel" <bioc-devel at stat.math.ethz.ch<mailto:bioc-devel at stat.math.ethz.ch>
<mailto:bioc-devel at stat.math.ethz.ch>>
Sent: Friday, January 23, 2015 4:58:40 PM
Subject: Re: [Bioc-devel] portable make syntax
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.
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
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
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<mailto:lg390 at cam.ac.uk> <mailto:lg390 at cam.ac.uk>>
wrote:
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
_______________________________________________
Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org>
<mailto:Bioc-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
_______________________________________________
Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> <mailto:Bioc-devel at r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
_______________________________________________
Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> <mailto:Bioc-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
_______________________________________________
Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> <mailto:Bioc-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
------------------------------
Subject: Digest Footer
_______________________________________________
Bioc-devel mailing list
Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> <mailto:Bioc-devel at r-project.org>
https://stat.ethz.ch/mailman/listinfo/bioc-devel
------------------------------
End of Bioc-devel Digest, Vol 130, Issue 26
*******************************************
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
[[alternative HTML version deleted]]
More information about the Bioc-devel
mailing list