Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

[Ralf Wildenhues]

Hi Eric,

thanks for pursuing this.

* Eric Blake wrote on Wed, May 13, 2009 at 02:51:34PM CEST:
> @@ -156,7 +158,25 @@ Installation Names
>  In addition, if you use an unusual directory layout you can give options
>  like @address@hidden to specify different values for
>  particular kinds of files.  Run @samp{configure --help} for a list of
> -the directories you can set and what kinds of files go in them.
> +the directories you can set and what kinds of files go in them.  In
> +general, the default for these options is expressed in terms of
> address@hidden@address@hidden, so that specifying just @option{--prefix} will
> +affect all of the other directory specifications.
> +
> +Depending on the package, the default directory layout chosen during
> address@hidden can be altered during subsequent execution of
> address@hidden  For example, the command @samp{make
> +prefix=/path/to/alternate} will choose an alternate prefix, and
> +additionally impact all configuration variables that were expressed in
> +terms of @address@hidden@}}.

This has a couple of issues:

- it fails to take into account that many packages that provide INSTALL
  do not provide this flexibility (e.g., all of those that use libtool
  don't currently provide it in full flexibility).

- it sounds as if developers are expected to check whether "prefix" has
  been changed, an in that case, rebuild files that need its definition.
  However, the GCS states that upon "make install prefix=...", no files
  are to be changed to reflect the changed prefix.  The above fails to
  make this clear.  As a consequence, it is not very useful to use
  "make all prefix=..." after a plain "make all", because typically that
  would not change any files either.

>  However, some programs need to know at
> +compile time where files will be installed, so the user should ensure
> +that the same directory choice is made for both @samp{make all} and
> address@hidden install}.  Some packages also support installation into a
> +staging area, via @samp{make address@hidden install}.  If your
> address@hidden does not understand arguments containing variable
> +assignments, you can try @samp{env address@hidden make -e install},
> +although you must then be careful of any other environment variables
> +affecting @command{make} behavior.

The last sentence can be omitted; packages that support DESTDIR
installs typically do not set DESTDIR in their makefiles.  All make
implementations understand arguments containing variable assignments,
and they override the settings in a toplevel makefile too, it's only
that they don't transport them to sub-makes if variables are also set in
the sub makefile.  (Yes, this is complicated, and applies to non-GNU
make only; see autoconf.texi.)

> +Some packages offer the ability to configure how verbose the execution
> +of @command{make} will be.  For these packages, running
> address@hidden/configure --enable-silent-rules} sets the default to minimal
> +output, which can be overridden with @code{make V=1}; while running
> address@hidden/configure --disable-silent-rules} sets the default to verbose,
> +which can be overridden with @code{make V=0}.

Cheers,
Ralf