Re: Faster install for libtool outputs.

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sat, Sep 13, 2008 at 09:46:47AM CEST:
> Hmm, apparently I failed to notice that `libtool --mode=install' doesn't
> mind being invoked for multiple files at once, even with libtool 1.5.x.
> This makes the rules more consistent with the rest (never mind the
> apparent increased duplication in ltlib.am).  Pushed.

>     Faster install for libtool outputs.
> 
>     * lib/am/ltlib.am (install-%DIR%LTLIBRARIES): Invoke `libtool
>     --mode=install' with multiple libraries at once.
>     (%DIR%LTLIBRARIES_INSTALL): No need to use install_sh any more.
>     * lib/am/progs.am (install-%DIR%PROGRAMS): Likewise, remove much
>     of the libtool special-casing by invoking it for multiple
>     programs at once.

Sigh, this was overly optimistic.  With libtool libraries, the
eventual need to relink at install time requires that the ordering
is exactly the same as given in the Makefile.am lines.

This is because automake is not smart enough to translate *_LIBADD
settings into install-order dependencies, so it has to rely on the
developer listing libraries in correct install order.  Luckily that
coincides with build order requirements, at least when all libraries
are listed in the same primary.

So we only get a small advantage out of ltlib: passing multiple
nobase_ libraries to be installed in the same directory can still
be done at once, as libtool will treat them in the order given.

While writing a test case for this, I noticed that nobase_ is broken
for LTLIBRARIES in more ways, and before the install changes:

* -rpath is not adjusted to point to the subdir.  What's worse,
  libtool even doesn't warn about it.
* unlike lib_LTLIBRARIES, nobase_lib_LTLIBRARIES aren't consistently
  installed before bin_PROGRAMS.  :-/

Also, the documentation needs help:

* my pending patch needs to mention that automake obeys this order.
* the following is not strictly true ATM:
|    Finally, note that a variable using the `nobase_' prefix can always
| be replaced by several variables, one for each destination directory
| (*note Uniform::).  [...]

Further, uninstall should probably reverse the order in which it removes
the libraries.

So much for a shrinking TODO list...

Cheers,
Ralf