[Rd] R-Project build system: DESTDIR support

Claudio Fontana sick_soul at yahoo.it
Mon Feb 27 02:11:37 CET 2006


Hello Dirk,
thanks for your answer.

--- Dirk Eddelbuettel <edd at debian.org> wrote:

> 
> 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. 

No need to be confused. DESTDIR is not required to be
able to maintain your project in Debian or in other
GNU/Linux distributions or other Unix-likes.

> 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...

AFAIK widespread DESTDIR use has begun with the
support in Automake, about 6-7 years ago.
DESTDIR dates back to the older INSTALL_ROOT, which is
still in use in the tcl community. 

> 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 [cut]
>
> So could you detail how using DESTDIR makes this
> (or, for that matter,
> another) use case any easier or better?

(
 I got your example screwed up by this mail service 
 and was difficult to read - care to send a possibly 
 more verbose version as attachment?
)

What you describe is conceptually very similar to
DESTDIR, if I understand you correctly.

A difference is that DESTDIR is written in the
Makefile.in, for each installation or uninstallation
rule, without altering the primaries. [...]

It only applies to the install/uninstall phase, so
hard-coded paths, and other location-dependant stuff
determined at build time remains valid for the final
destination.

DESTDIR is widely known and portable, and users and
programs can rely on it for running commands on the
to-be-installed files for different goals.

simple usage:
./configure --prefix=/my/final/prefix
make
make install DESTDIR=/staged/directory

simple rule example:
$(INSTALL_DATA) $(srcdir)/file.dat
$(pkgdatadir)/file.dat

becomes

$(INSTALL_DATA) $(srcdir)/file.dat
$(DESTDIR)$(pkgdatadir)/file.dat

Automake generates DESTDIR support automatically (with
some caution required in custom installation hooks).

Probably many sources can provide you more information
about DESTDIR that I can. 

More info is available in the GNU coding standards
(Makefile conventions), GNU make and GNU automake
manuals, and it is probably topical in the autotools
lists too. Google gives me some good hits for DESTDIR
too.

> | In each case, please contact me at this address
> <claudio at gnu.org>
> | 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 :)

Great, maybe you can forward our conversation?
  
> | Thank you for your help in making GNU projects
> build systems better.
> 
> Thanks for this initiative. It could indeed makes
> things better

I hope so, as I am putting a lot of effort in this.

> Cheers, Dirk

Best,

CLaudio



More information about the R-devel mailing list