Automake AM_LDADD workaround

前端 未结 2 1870
庸人自扰
庸人自扰 2020-12-19 13:27

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 ad

相关标签:
2条回答
  • 2020-12-19 14:08

    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 ...
    
    0 讨论(0)
  • 2020-12-19 14:14

    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

    0 讨论(0)
提交回复
热议问题