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
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 ...
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With