Re: improving INSTALL contents, take two

[Alfred M. Szmidt]

   address@hidden
   +Optionally, type @samp{make installcheck} to repeat any self-tests, but
   +this time using the binaries in their final installed location.

Maybe mention that installcheck should be run as a normal user, and
that it doesn't install anything?

    @item
   @@ -159,16 +178,52 @@ 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.

`..., unless they are explicitly declared as well.'?

   +The most portable way to affect installation locations is to pass the
   +correct locations to @command{configure}; however, many packages provide
   +one or both of the following shortcuts to change installation locations
   +without having to reconfigure or recompile.
   +
   +The first method involves passing additional @command{make} variables
   +for each affected directory as part of the command line to @samp{make
   +install}.  For example, @samp{make install prefix=/path/to/alternate}

A very minor nitpick, we use the word `path' to mean a list of
directories to search through, not an single directory.  The above
would be clearer with `prefix=/installation/directory'.

   +will choose an alternate location, as well as influencing all other
   +directory configuration variables that were expressed in terms of
   address@hidden@address@hidden (or, put another way, all directories specified
   +during @command{configure} but not in terms of the common prefix must
   +each be overridden at install time for the entire installation to be
   +relocated).  The approach of makefile variable overrides for each
   +directory variable is required by the @acronym{GNU} Coding Standards,
   +and ideally causes no recompilation.  

I find this paragraph extremely confusing, and am not entierly sure
what is being said.

   +However, some platforms have known
   +limitations with the semantics of shared libraries that end up requiring
   +recompilation when using this method, particularly noticeable in
   +packages that use @acronym{GNU} Libtool.

Is it worth mentioning this libtool bug?  Maybe put it in a footnote?

   +For packages which support @samp{DESTDIR}, the variable should remain
   +undefined during @command{configure} and @samp{make all}, and only be
   +specified during @samp{make install}.

Does anyone know of a package that gets affected during
configure/install time by DESTDIR?  I find the aboe a bit confusing,
and think that it might be worth not mentioning it at all.


Overall, while I still think that it is a bug that DESTDIR is not
required, but what has been suggested is a extremely good compromise
that should make all parties happy.

I feel a bit like a kid who got a nice lollipop, and is complaining
that it is to sweet when I write this.