bug#7621: add a way to pass link dependencies

[Bruno Haible]

Hello Ralf,

Thank you for taking care of this long-standing problem.

> implement both (A) and (B), but in the latter
> let $(prog_LIBS) override $(LIBS) instead of having both.

For (A), the list of options to be ignored during dependency extraction is the
following (cf. gnulib/build-aux/config.rpath):
  -rpath /some/path
  -Wl,-rpath -Wl,/some/path
  -Wl,-rpath,/some/path
  -lopt=-rpath -lopt=/some/path
  -Qoption ld -rpath -Qoption ld /some/path
  -R/some/path
  -R /some/path
  -blibpath:/some/path
  -Wl,-blibpath:/some/path
  +b /some/path
  -Wl,+b -Wl,/some/path

A) Allow the above listed -rpath options also in *_LDADD variables,
   and allow the above listed -rpath options and -l, -L options also in
   *_LIBADD variables of libraries built with libtool.

B) Introduce a new set of variables *_LIBS that can contain link options
   for dependencies, like $(LIBICONV) and $(LTLIBICONV) above. Let them
   default to $(LIBS). Modify the link commands to look like this:

   For maude:
     $(CCLD) $(maude_CFLAGS) $(CFLAGS) \
             $(maude_LDFLAGS) $(LDFLAGS) \
             -o $@ \
             $(maude_OBJECTS) \
             $(maude_LDADD) $(maude_LIBS)

   For maudelt:
     $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) 
--mode=link \
     $(CCLD) $(maudelt_CFLAGS) $(CFLAGS) \
             $(maudelt_LDFLAGS) $(LDFLAGS) \
             -o $@ \
             $(maudelt_OBJECTS) \
             $(maudelt_LDADD) $(maudelt_LIBS)

   For librarylt.la:
     $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) 
--mode=link \
     $(CCLD) $(librarylt_la_CFLAGS) $(CFLAGS) \
             $(librarylt_la_LDFLAGS) $(LDFLAGS) \
             -o $@ \
             -rpath $(libdir) \
             $(librarylt_la_OBJECTS) \
             $(librarylt_la_LIBADD) $(librarylt_la_LIBS)

For the user, the benefit of using the *_LDADD and *_LIBADD variables will be
that he does not make a distinction between already installed libraries and
libraries in the build tree. But he has to be careful not to augment the
*_LIBADD variable of a .a library.

Whereas his benefit of using the *_LIBS variables will be that he can treat
programs, .a libraries, and .la libraries the same way. But he has to be
careful to handle dependencies to libraries in the build tree differently than
dependencies to already installed libraries.

The documentation could point this out.

But if you ask me, it is suboptimal to offer to the user two different ways of
doing the same thing, each with a different drawback. Ideally, there should be
one way of doing it, with none of the drawbacks.

So what I propose is

C) Introduce a new set of variables *_LIBS like in (B), and use them (in the
   case of a program or .la library) for the construction of the *_DEPENDENCIES
   variable.

   This computation of the *_DEPENDENCIES variable would then need to be
   enhanced to ignore all kinds of linker options and pick only the tokens
   that end in ".a" or ".la". This will be needed because people can write
   conditional code like

      if USING_GNU_LD
      maude_LIBS += -Wl,-E
      endif
      if ON_WIN32
      maude_LIBS += -Wl,--disable-auto-import
      endif
      if USE_EMBEDDED_LIBFOO
      maude_LIBS += ../foo/libfoo.a
      endif

   The documentation would make it clear that all link dependencies go in
   *_LIBS, for all kinds of programs and libraries.

   As a consequence, deprecate *_LDADD.

But wait, deprecating *_LDADD and letting *_LIBS take over their role is a
bit harsh. Why not keep the simplicity of proposal (C) without the deprecation?

D) Introduce a new set of variables *_LDADD for libraries that are built
   with libtool. Don't touch LIBS. Modify the link commands to look like this:

   For maude:
     $(CCLD) $(maude_CFLAGS) $(CFLAGS) \
             $(maude_LDFLAGS) $(LDFLAGS) \
             -o $@ \
             $(maude_OBJECTS) \
             $(maude_LDADD) $(LIBS)

   For maudelt:
     $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) 
--mode=link \
     $(CCLD) $(maudelt_CFLAGS) $(CFLAGS) \
             $(maudelt_LDFLAGS) $(LDFLAGS) \
             -o $@ \
             $(maudelt_OBJECTS) \
             $(maudelt_LDADD) $(LIBS)

   For librarylt.la:
     $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) 
--mode=link \
     $(CCLD) $(librarylt_la_CFLAGS) $(CFLAGS) \
             $(librarylt_la_LDFLAGS) $(LDFLAGS) \
             -o $@ \
             -rpath $(libdir) \
             $(librarylt_la_OBJECTS) \
             $(librarylt_la_LIBADD) $(librarylt_la_LDADD) $(LIBS)

   Compute the *_DEPENDENCIES not only from *_LDADD, but also from LIBS,
   ignoring all linker options like in proposal (C) above.

   The documentation would make it clear that all link dependencies go in
   *_LDADD and LIBS, for all kinds of programs and libraries, that LIBS
   is common to all programs and libraries being built by the same Makefile,
   and that the contents of *_LDADD and of LIBS are treated the same way.

   For libraries (both .la and .a libraries), the doc would continue to
   state that extra contents of the library goes in *_LIBADD whereas
   link dependencies go in *_LDADD (the latter being ignored for .a
   libraries, of course).

I think this proposal does not have any of the drawbacks, provides a
simple rule that the developer can easily remember, and is a straightforward
extension of what Automake offers now.

Bruno