Search code examples
autotoolsautoconfautomakelibtoolbuild-system

Autotools: Optionally compile and link against a third-party library


I have an executable project prog on autotools build-system. This program links against libfoo which is also an autotools project.

I want to give my users (who wish to compile prog) the freedom to choose between linking against a previously installed libfoo, or to configure, compile (static linkage) and link to the libfoo source tree which is shipped within package (in third-party directory)

libfoo uses libtool and pkg-config if it matters...

Ideally this would be done with some autoconf arguments:

./configure --with-local-libfoo

vs

./configure --with-system-libfoo

The question is how to tell the buildsystem to compile libfoo before prog (in second case) and how to provide correct link flags?


Solution

  • Since libfoo is also an Autotools project, a copy of which is distributed inside the main project, it would be natural to set it up as a subproject. The key Autoconf macro here is AC_CONFIG_SUBDIRS. Thus, if the libfoo package were in a subdirectory libfoo/ of the directory containing the top-level configure script, the top-level configure.ac would use

    AC_CONFIG_SUBDIRS([libfoo])
    

    In that case, the top-level configure script will run libfoo's configure script automatically, passing it all the same options it received (including any that are meaningful only to libfoo). Moreover, the top-level script's --help option will print both its own and libfoo's options. You can make that conditional on a --with-* argument (but just one, don't use two different ones).

    On the Automake side, look into Automake conditionals and conditional subdirectories. You can use conditionals, with the condition controlled by your --with-system-libfoo or whatever, to select the right set of link options and to determine whether make will recurse into the libfoo package. When you're building your own copy of libfoo, it might be helpful to include the -static-libtool-libs option among the main program's link flags.

    The last bits revolve around preventing the local libfoo, when you build it, from being installed on the system along side the main program. I haven't come up with a good solution that doesn't involve tweaking libfoo's build system. Do switch libfoo.la to be a convenience library (named in noinst_LTLIBRARIES instead of in lib_LTLIBRARIES or such) and in fact generally switch build targets in the libfoo subpackage from installed ones to noinst_ ones.