0

项目附带 library 的副本，foo文件系统布局如下：

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

标准（基于自动工具的）构建系统构建 libfoo，然后构建动态链接到libfoo. libfoo基本上没有修改（有一些小的修改以正确适应构建系统）。libfoo使用 autotools 本身，所以我通常使用AC_CONFIG_SUBDIRS.

但是，libfoo已经为各种发行版打包，所以我想避免在这些系统上构建导入库，而是使用系统范围的安装 - 这样我可以获得更好维护的 libfoo 版本的好处（更少的错误，安全问题，...）。otoh，我想将 libfoo 保留在我的源代码树中，这样我就可以在不提供该库的系统上进行构建（无需用户单独获取源代码并自己构建库）。

我可以想到一些我可以引入的配置标志，因此用户可以选择是否要使用系统安装、本地或不使用库来构建项目。（这是一个可选的依赖项）。禁用“本地 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 选择的最佳实践是使用本地副本还是库、系统范围的副本还是根本不使用库？

非常欢迎使用这种机制的项目的指针。

4

3 回答 3

3

我的项目中有一个类似的地方，当（1）该库尚未安装，或（2）它已安装但不必与我期望的接口，或（3）时，我使用 BuDDy 库的包含configure版本运行--with-included-buddy。

你可以在这里configure看到宏。之后我只在s中使用和，而顶层仅在 . 中有条件地包含目录。$(BUDDY_CPPFLAGS)$(BUDDY_LDFLAGS)Makefile.amMakefile.ambuddySUBDIRS

于 2013-03-06T07:30:51.210 回答
1

在处理外部软件时我更喜欢--with-foo，但这只是一种偏好。链接中的示例和文档可能会帮助您决定如何操作。我将使用您的第一个示例，该示例仅使用一个标志，而不是第二个使用两个标志以便于文档/维护的示例。

于 2013-03-05T18:38:29.207 回答
1

我真的不认为你想这样做

您将使构建机器变得更加复杂，并且大多数人已经将自动工具视为黑魔法。对于开发人员来说，这会让事情变得更加复杂，对于潜在的发行版打包者来说会更加复杂，对于最终用户来说会变得更加容易。

如果您有条件地进行配置，那么您会使构建分发 tarball ( make dist/ make distcheck) 的过程更加脆弱。

这是你可能造成的麻烦。

但如果你必须...

您也许可以在我最近的回答中调整代码。

于 2013-03-05T21:38:34.033 回答