有/无包含库构建的最佳实践 [英] best practice for building with/out included libraries

问题描述

一个项目附带一个库foo的副本，文件格式如下:

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

标准(基于自动工具的)构建系统将构建libfoo，然后构建myproject，该动态链接到libfoo. libfoo基本上是未修改的(进行了一些小的修改，以适合构建系统). libfoo本身使用自动工具，因此我通常使用AC_CONFIG_SUBDIRS递归调用configure.

但是，libfoo已经针对各种发行版进行了打包，因此我想避免在这些系统上针对导入的库进行构建，而宁愿使用系统范围的安装-这样，我可以获得更好维护的libfoo版本的好处(更少的错误，安全问题，...). otoh，我想将libfoo保留在我的源代码树中，以便在没有发布该库的系统上进行构建时有一个后备功能(无需用户要求单独获取源文件并自己构建lib).

我可以想到许多我可以介绍的配置标志，因此用户可以选择是否要使用系统安装的，本地的或不带库的项目来构建项目. (这是一个可选的依赖项). 禁用本地foo"，应完全禁用libfoo的构建(并且可能还配置foo)

例如像这样:

./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

或者:

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

但是我想以符合标准的方式来做.

通过autoconf进行选择的最佳实践是使用本地副本还是使用库，系统范围的副本还是根本不使用库?

最欢迎使用这种机制的项目的指针.

解决方案

在我的项目中，我有一个类似的地方，其中当(1)尚未安装库或(2)时使用BuDDy库的随附版本它已安装但不必与我期望的接口连接，或者(3)configure与--with-included-buddy一起运行.

您可以看到configure宏此处.之后，我只需在Makefile.am s中使用$(BUDDY_CPPFLAGS)和$(BUDDY_LDFLAGS)，然后使用

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.

解决方案

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.

这篇关于有/无包含库构建的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！