[Rd] standardized add-on package configuration

[Kurt Hornik]

>>>>> Torsten Hothorn writes:

> On Wed, 15 Nov 2000, Kurt Hornik wrote:

>> Several add-on packages (e.g., most DBMS ones, XML, ...) come with a
>> configure script which tries to find headers and libraries required by
>> the package.  I was wondering whether we could/should standardize how
>> this is done.

> IMO the main problem is that header files and libraries are not in
> /usr/include or /usr/lib but, for example, for mysql in
> /usr/local/mysql/{include,lib} by default. A package should build
> without interaction if headers and libs are in their default place.

Your mileage may vary on what `default' places are.  Basically, there
are two philosophies.  The more traditional one would be to have a
package/type layout, as you indicate above.  The modern style, used and
recommended e.g. in the GNU, Debian, and TeX/MF standards, is to have
type/package or type instead.

E.g., when I install mysql on Debian, I get the libraries in /usr/lib
and the headers in /usr/include/mysql.

>> 
>> In what follows, suppose package FOO needs functionality BAR.
>> 
>> * One approach would be via command-line arguments to configure.  There
>> seems to be no standard for this.  GNOME uses
>> 
>> --with-FOO-prefix
>> --with-FOO-exec-prefix
>> 
>> in several of its components.  However, this, assumes that the GNU
>> standards are followed in the sense that headers go into
>> 
>> FOO-prefix/include
>> 
>> and libs go into
>> 
>> FOO-exec-prefix/lib
>> 
>> which might not necessarily be the case.
>> 
>> Alternatively, we could have
>> 
>> --with-FOO-libraries
>> --with-FOO-libs
>> 
>> and
>> 
>> --with-FOO-includes
>> --with-FOO-headers
>> 
>> (one of each only, of course).

> Can one define default values here?

Yes, of course.

>> 
>> * The other possibility would be via environment variables, such as
>> CPPFLAGS and LIBS or maybe FOO_CPPFLAGS and FOO_LIBS.  (E.g., for
>> package XML we would use LIBXML_CPPFLAGS and LIBXML_LIBS.)
>> 
>> I think the simplest solution would be via CPPFLAGS and LIBS because it
>> is not package-specific.  So installation would happen via
>> 
>> CPPFLAGS=... LIBS=... R CMD INSTALL /path/to/pkg.tar.gz

> Maybe it is possible to check if CPPFLAGS is empty (replace it with a
> default value) or not (try to build the package and give an error
> message if it failed, pointing to the appropriate environment
> variable)?

That'w what I had in mind.

The above should be

* much nicer to use than doing something like

	R CMD INSTALL \
	  --configure-args="--with-foo-libs=/some/path ..." \
	  /path/to/pkg.tar.gz

* would be consistent with what is used to configure the R base system

* and would be uniform across packages.

On the other hand, it is a bit dangerous .. hmm, as we actually have
PKG_CPPFLAGS and PKG_LIBS, maybe we should use these variables instead?

Will think some more about this.

>> 
>> (did not check if this works now).
>> 
>> Now I did not check all packages, so is there something I may be
>> overlooking?
>> 
>> (Once we agree on a standard, I would like to document it in R-exts.)
>> 
>> -k

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._