使用/不包含库构建的最佳实践 [英] best practice for building with/out included libraries
问题描述
一个项目附带了一个库 foo
的副本,文件系统布局如下:
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
标准(基于自动工具)构建系统构建 libfoo,然后构建动态链接到 libfoo
的 myproject.libfoo
基本上没有修改(有一些小的修改以正确适应构建系统).libfoo
使用 autotools 本身,所以我通常使用 AC_CONFIG_SUBDIRS
递归调用 configure.
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
.
然而,libfoo
已经为各种发行版打包,所以我想避免在这些系统上针对导入的库进行构建,而是使用系统范围的安装 - 这样我就可以获得更好维护的 libfoo 版本(更少的错误,安全问题,...).otoh,我想将 libfoo 保留在我的源代码树中,这样我就可以在不提供该库的系统上进行构建(无需用户需要单独获取源代码并自己构建库).
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).
我可以想到一些我可以引入的配置标志,因此用户可以选择是否要使用系统安装、本地或不使用库来构建项目.(这是一个可选的依赖项).禁用本地 foo",应该完全禁用 libfoo 的构建(并且可能还配置 foo)
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)
例如类似:
./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
但我想以符合标准的方式执行此操作.
but i'd like to do this in a standard-conformant way.
通过 autoconf 进行选择的最佳实践是什么,是使用本地副本还是库、系统范围的副本还是根本不使用库?
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) 库尚未安装时,我使用包含版本的 BuDDy 库,或 (2)它已安装但不必与我期望的接口连接,或者 (3) configure
与 --with-included-buddy
一起运行.
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
.
你可以看到configure
宏此处.之后,我只在 Makefile.am
和 顶级Makefile.am
仅在 SUBDIRS
中有条件地包含 buddy
目录.
You can see the configure
macro here. After that I just use $(BUDDY_CPPFLAGS)
and $(BUDDY_LDFLAGS)
in the Makefile.am
s, and the top-level Makefile.am
only include the buddy
directory conditionally in SUBDIRS
.
这篇关于使用/不包含库构建的最佳实践的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!