5

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
Vicente Bolea
  • 1,409
  • 16
  • 39

2 Answers2

5

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 ...
Brett Hale
  • 21,653
  • 2
  • 61
  • 90
  • Thanks for the last tip, unfortunately the tests require the test class and the original class, any idea of how to deal with? – Vicente Bolea Mar 25 '15 at 12:40
  • 1
    @VicenteAdolfoBoleaSánchez - yes, there's an easy way for that - I'll add to the answer. Are you using `libtool` with your package? – Brett Hale Mar 25 '15 at 12:45
  • Not really it is just a static library file (.a), It is a third party library so I'll prefer not to modify it. – Vicente Bolea Mar 25 '15 at 12:47
  • @VicenteAdolfoBoleaSánchez - that's fine, I put the libtool equivalent in comments. – Brett Hale Mar 25 '15 at 12:54
  • Awesome reply, I have more questions regarding how is the standard way to do unit testing with Autotools, here is the question http://stackoverflow.com/questions/29251038/unit-tests-using-automake – Vicente Bolea Mar 25 '15 at 13:05
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

RRahaman
  • 41
  • 3