Automake AM_LDADD workaround

Question

I want to set the same LDADD attribute (Unit test library) to a large number of targets (unit test C++ files). I first though that maybe automake has AM_LDADD variable to add that library to all the targets within the file but is not the case. In some mail list I found some short discussion asking to add it: http://gnu-automake.7480.n7.nabble.com/AM-LIBS-AM-LDADD-td3698.html

My question is, how do you deal with that? is it there any way to avoid manually adding LDADD attribute to each target?

So far my Makefile.am looks like:

 test1_SOURCES = ...
 test1_LDADD = -llibrary 
  ...
  ...
 test20_SOURCES = ...
 test20_LDADD = -llibrary 

Answer 1

The equivalent of an AM_LDADD variable is simply LDADD. e.g.,

LDADD = -llibrary

test1_SOURCES = ...
...
test20_SOURCES = ...

If you need to override LDADD for a particular program: prog, then prog_LDADD will always take precedence.

I always assumed that since there was no LDADD standard environment variable passed to configure - as you can see with configure --help - there is no real reason for an AM_LDADD. This kind of makes sense, as the configure script, and any options, e.g., --with-foo=<path> should (ideally) work out the library dependencies.

On the other hand, passing CFLAGS via configure might still need an AM_CFLAGS that combines CFLAGS and with other compiler flags determined by the configure script; or even a foo_CFLAGS override. Since configure must be informed of your custom CFLAGS.

---

Also, I don't know if the test<n> programs only take a single C++ source file, but if so, you can simplify the Makefile.am with:

LDADD = -llibrary

check_PROGRAMS = test1 test2 ... test20
AM_DEFAULT_SOURCE_EXT = .cc # or .cpp

as described here.

---

In regards to your comment, your can use a convenience library for that purpose - which is particularly useful for common code used by test programs:

noinst_LIBRARIES = libfoo.a  # or noinst_LTLIBRARIES = libfoo.la
libfoo_a_SOURCES = MyClass.hh MyClass.cc  # or libfoo_la_SOURCES

LDADD = ./libfoo.a -llibrary # or libfoo.la if using libtool.

... etc ...

Answer 2

It's a bad idea to modify LDADD in your Makefile.am, even if it seems convenient. It will make your build system very fragile.

In particular, if the user attempts to override LDADD from the make command line, then your definition of LDADD in Makefile.am will disappear. It's not unreasonable to expect that a user might override LDADD, so you should definitely protect yourself against this situation.

Your original definitions of test1_LDADD, ...,test20_LDADD are much more robust and, as far as I understand the automake manual, the recommended use.

See the remarks here for more info: https://www.gnu.org/software/automake/manual/html_node/User-Variables.html https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html