best practice for building with/out included libra

问题:

a project ships with a copy of library foo, in a filesystem layout like:

myproject/
myproject/src/ # sources of my project
myproject/libfoo/ # import of "foo" library

the standard (autotools-based) build-system builds libfoo, then builds myproject which dynamically links against libfoo. libfoo is basically unmodified (with some minor amendments to properly fit into the build-system). libfoo uses autotools itself, so i'm usually calling configure recursively using AC_CONFIG_SUBDIRS.

however, libfoo is already packaged for various distributions, so i would like to avoid building against the imported library on these systems and rather use system-wide installation - this way i get the benefits of a better maintained version of libfoo (less bugs, security issues,...). otoh, i want keep libfoo in my source-tree, so that i have a fallback for building on systems that do not ship that library (without the user requiring to separately fetch the sources and build the lib themselves).

i can think of a number of configure-flags i could instroduce, so the user can select whether they want to build the project with the system-installed, the local or without the library. (it's an optional dependency). disabling the "local foo", should completely disable building of libfoo (and probably also configuring foo)

e.g. something like:

./configure --enable-foo=no    # aka "--disable-foo": build without foo
./configure --enable-foo       # use system-wide foo
./configure --enable-foo=local # use local copy of foo

alternatively:

./configure --disable-foo
./configure --enable-foo  --disable-local-foo
./configure --enable-foo  --enable-local-foo

but i'd like to do this in a standard-conformant way.

what's the best practice for selecting via autoconf, whether to use a local copy or a library, a system-wide copy or to not use the library at all?

pointers to projects that use such a mechanism are most welcome.

回答1:

I have a similar in my project where I use the included version of the BuDDy library when (1) the library isn't already installed, or (2) it is installed but does not have to interface I expect, or (3) configure was run with --with-included-buddy.

You can see the configure macro here. After that I just use $(BUDDY_CPPFLAGS) and $(BUDDY_LDFLAGS) in the Makefile.ams, and the top-level Makefile.am only include the buddy directory conditionally in SUBDIRS.

回答2:

I prefer --with-foo when dealing with external software, but it's just a preference. The examples and documentation at the link might help you decide how you want to do it. I'd go with your first example that uses only one flag rather than the second one that uses two flags for easier documentation/maintenance.

回答3:

I really don't think you want to do this

You're going to make the build machinery a lot more complicated, and autotools are already considered black magic by most. It'll make things a lot more complicated for the developer, a little more complicated for a potential distro packager and ever-so-slightly easier for the end user.

If you're conditionally configuring then you make the process of building distribution tarballs (make dist/make distcheck) more brittle.

This is the sort of trouble you can cause.

But if you must...

You may be able to adapt the code in my recent answer.