[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: Wed, 15 Apr 2009 12:00:53 -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 

   Please, let's not bloat `configure --help' output even more.  It is
   already very long for a simple help text, it should not document
   things that are not, in fact, settings for configure but for the

I see no harm in mentioning it in the output for configure --help, the
output is not _that_ long.

| By default, `make install' will install all the files in
| `/usr/local/bin', `/usr/local/lib' etc.  You can specify
| an installation prefix other than `/usr/local' using `--prefix',
| for instance `--prefix=$HOME'.

We already mention `make install' in the output, so it would make
sense to add a single line to this sentence.  Maybe the sentence that
Eric suggested.

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

   This case is different.  DESTDIR has the important drawback that it
   does not work well with w32-style installation directory names like
   `C:/foo', because you cannot prepend to such a path.  So for
   maximum portability you should support this in your package, too.
   BTW, why do you state that overriding just $prefix would be "almost
   always wrong"?

What is the problem with DESTDIR=C:/foo?

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

   However, this text may not be added by Autoconf as Autoconf cannot
   be sure that the package supports this.  Pedantically, the package
   cannot even be sure that `make' is used at all.  IMVHO the right
   place to document DESTDIR is along with documentation to the
   standard make targets.  INSTALL documents a couple, but would grow
   too large if it documented all (and is also targeted at
   non-automake-using packages).

The output from configure already mentions things that it cannot be
sure of, so I do not see the problem.  A project can easily ignore the
fact that --libexecdir is for daemons, and use sbindir or something
similar, or simply not use `make install' which configure --help
reports as something that is supported.

   Maybe the generic INSTALL file should provide pointers to more
   comprehensive documentation?

Making users have to hunt and pek to find all informaation is a bad
idea IHMO.

reply via email to

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