Automake workaround AM_LDADD

Question

I want to set the same attribute LDADD (Unit test library) for a large number of purposes (Unit test C ++ files). I first, although perhaps automake has the variable AM_LDADD to add this library to all the targets in the file, but it is not. In some mailing lists, I found a short discussion asking me to add it: http://gnu-automake.7480.n7.nabble.com/AM-LIBS-AM-LDADD-td3698.html

My question is: how do you deal with this? is there any way to avoid manually adding the LDADD attribute for each target?

So far, my Makefile.am looks like this:

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

Answer 1

The equivalent of AM_LDADD is just LDADD . eg.

 LDADD = -llibrary test1_SOURCES = ... ... test20_SOURCES = ... 

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

I always assumed that since the standard LDADD environment variable passed to configure does not exist, as you can see with configure --help , there is no real reason for AM_LDADD . This type makes sense since configure script, and any parameters, for example --with-foo=<path> , should (ideally) work with library dependencies.

On the other hand, passing CFLAGS through configure may still need AM_CFLAGS , which combines CFLAGS with other compiler flags defined by configure script; or even overriding foo_CFLAGS . Because configure should be informed about your custom CFLAGS .

---

Also, I don’t know, only test<n> programs take only one C ++ source file, but if so, you can simplify Makefile.am with

 LDADD = -llibrary check_PROGRAMS = test1 test2 ... test20 AM_DEFAULT_SOURCE_EXT = .cc # or .cpp 

as described here .

---

As for your comment, you can use the convenience library for this purpose, which is especially useful for the general 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 is a bad idea to modify LDADD in your Makefile.am, even if it seems convenient. This will make your build system very fragile.

In particular, if a user tries to override LDADD from the make command line, your LDADD definition in Makefile.am will disappear. It is unreasonable to expect the user to override LDADD , so you should definitely protect yourself from this situation.

Your initial definitions of test1_LDADD , ..., test20_LDADD are much more reliable and, as I understand it, the manual for using the machine is recommended.

See comments here for more information: 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