Hi Claudio,
On 25 February 2006 at 03:11, Claudio Fontana wrote:
| Hello,
|
| I am writing you about the GNU R-Project,
| as part of by effort to help GNU projects provide a better, more
| consistent build system.
|
| Currently, your project does not support the DESTDIR variable in
| generated Makefiles (marked as optional in the GNU coding policies, make and
| automake manual).
|
| In my opinion, DESTDIR support can be very helpful for the user, the
| distribution-specific packagers and third-party programs, because it
| offers a consistent and portable way to perform staged installations.
I'm confused. We've been maintaining R in Debian quite merrily even with the
exisiting standards. To the best of my knowledge things seem to work without
DESTDIR.
In a nutshell, what we do -- and this is, or at least used to be, pretty
canonical across GNU-style packages and has been in effect for probably a
dozen years. Now, I may miss something newer happening elsewhere...
The key is that configure details the _final_ location on the installed
system, whereas 'make install' pivots off to a subdirectory in the archive of
the currently built package is 'installed' before being tarred:
./configure --prefix=/usr \
--with-system-bzlib \
[...]
--build $(buildarch)
[...]
$(MAKE) CFLAGS="$(compilerflags)" \
CXXFLAGS="$(compilerflags)" \
FFLAGS="$(compilerflags)" \
CC=${compiler} \
CXX=${cxxcompiler} \
${fortrancompiler} \
R
[...]
$(MAKE) prefix=$(debtmp)/usr \
mandir=$(debtmp)/usr/share/man \
rsharedir=$(debtmp)/usr/share/R/share \
rincludedir=$(debtmp)/usr/share/R/include \
rdocdir=$(debtmp)/usr/share/R/doc \
install
So could you detail how using DESTDIR makes this (or, for that matter,
another) use case any easier or better?
| In each case, please contact me at this address <[EMAIL PROTECTED]>
| to provide your feedback about this issue _in any case_, should you
| want to support DESTDIR or not.
|
| I am ready to offer you information, help and support.
You may want to talk to Kurt Hornik who covers the autoconf et al build
process for R. Whenever I had little gripes or needs, he reflected these
and typically with much better solutions than I could have proposed :)
| Thank you for your help in making GNU projects build systems better.
Thanks for this initiative. It could indeed makes things better
Cheers, Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
