Thanks for the suggestion. I do have a configure script (that is what
is reading the --with-netica arg) but I didn't think about searching the
standard install locations. I can probably use that to work around this
problem.
However, that doesn't completely solve the problem. If I want to force
the configure script to use a non-standard location (say to use an
experimental version of the library), I still need to be able to pass
configure args to INSTALL and check. I admit the need for doing this
with build is a little bit less clear, although it is also unclear why
build (which is making a source tarball) needs to compile the C code.
--Russell
On 07/30/2015 05:11 PM, Dirk Eddelbuettel wrote:
Besides what Duncan said, relying on user to supply arguments is pretty bad
as it more or less guarantees _any_ automated test will not succeed (for lack
of involvement of the sage user).
Writing configure scripts feels like yet another painful step, but it really
is not that hard if you know a little shell scripting already. You can even
do simple things and just loop over a fixed (but hopefully long) list of know
locations -- which is what RPostgreSQL does:
https://github.com/cran/RPostgreSQL/blob/master/configure.in#L38-L69
Not my proudest moment, but it worked for a few (ten-)thousands of
installations and builds ...
Dirk
--
Russell Almond
Associate Professor, Measurement & Statistics
Educational Psychology and Learning Systems
1114 W. Call St.
Florida State University
Tallahassee, FL 32306
(850) 644-5203
ralm...@fsu.edu
http://ralmond.net/
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
