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
