Re: pointless automake error about libtool libraries

[Ralf Wildenhues]

Hello Bruno,

* Bruno Haible wrote on Mon, Aug 21, 2006 at 06:57:50PM CEST:
> Ralf Wildenhues wrote:
> > But this would still prevent automake to warn the user when he used
[...]
> 
> automake could still _warn_ about it. What I'm complaining about is that
> it gives an error (exit code 1), although the purpose of the error -
> avoiding conflicts in -rpath options - is not met.

Well, another point is that it is not easy to fix the above suggestion
_cleanly_ in automake.  If automake copies its input to its output, then
taking both lines
  noinst_LTLIBRARIES = libfoo.la
  lib_LTLIBRARIES = libfoo.la

and having the respective rules leaves you with two different dependency
paths both updating libfoo.la, but with different rules.  Very bad, as
that leads to subtle bugs.

> Here actually I'd like to have one tool specify what to compile

EXTRA_LTLIBRARIES = libfoo.la
noinst_LTLIBRARIES = gl_noinst_ltlibs
lib_LTLIBRARIES = gl_lib_ltlibs

> (namely, libfoo.la), and other tool specify what to install (namely,
> libfoo.la as well).

gl_noinst_ltlibs = libfoo.la

or from configure.ac:
  AC_SUBST([gl_noinst_ltlibs], [libfoo.la])

But say, do you have two tools writing in the same Makefile.am (or does
one include the other)?  I may seem dense, but I have really not
understood the usage case for gnulib-tool in this case.

> You force me to put both specifications into the same
> line in Makefile.am. This makes it impossible to have gnulib-tool
> generate one of them and have the other one written by hand.

I don't think so; see above.

> > gnulib-tool could be made smart enough to output the right thing in
> > the first place
> 
> Do you have an idea how to do so without an additional command-line option?

Well, for that I'd need to understand better the instance that actually
decides whether the library is installed or not (and _when_ the decision
can be made, and why).

Cheers,
Ralf