[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core-utils 7.2; building only 'su'

From: Alfred M. Szmidt
Subject: Re: Core-utils 7.2; building only 'su'
Date: Tue, 14 Apr 2009 08:49:30 -0400

   >    Hmmm.  Would it be worth changing autoconf to make './configure
   >    --help' state something like the following:
   >    | Some influential environment variables:
   >    |   ...
   >    |   DESTDIR    leave unset during configure; allows installation to
   >    |              specify a staging area different than the final prefix
   >    Perhaps even issue a warning if DESTDIR is set during configure
   >    time?  Or would this proposal just cause more problems?
   > I know that the wording is only a suggestion, but I see multiple
   > problems.
   > DESTDIR is not synonymous with prefix, it is prepended to each of the
   > variables (exec_prefix, prefix, bindir, libexecdir, ...)  when they
   > are used as a destination during `make install'.

   Not all packages follow GNU Coding Standards, therefore, DESTDIR is not
   properly supported in a surprisingly large number of packages.

We already enforce a level of GNUism on packages that use
autoconf/automake, I do not think it would be the end of the world if
we did it in this case as well.

   > I do not think that users are confused about passing DESTDIR
   > during configure time either.  DESTDIR is and has always been a
   > automake variable.  Alas, the only useful place to put this
   > information is in the output of --help.  Maybe something more
   > like this would be a bit more suitable (not to happy about the
   > actual wording):
   > `To install FOO in a different directory for the purpose of
   > making a tarball, or similar pass DESTDIR to `make install''

   Maybe the shorter:

   `To install FOO in a staging directory, use `make install DESTDIR=...''

I like that.

   > Problem with the above, is that it only works when using make, but
   > maybe this is not a real problem?  If one uses AM_INIT in configure,
   > then the above could pop up...

   You have a point there - since autoconf cannot enforce the
   package's compliance of the GNU Coding Standards in its Makefile,
   it would not be good for autoconf to add this warning for the
   packages where DESTDIR doesn't work properly.  But automake already
   does such a good job at providing DESTDIR support (especially if
   the user remembered to run 'make distcheck'), that I think it would
   be nice if using AM_INIT_AUTOMAKE did make the ./configure --help
   mention the future effect of DESTDIR.

I agree.  Does distcheck actually test DESTDIR?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]