项目附带了库foo的副本，文件系统布局如下：
myproject/
myproject/src/ # sources of my project
myproject/libfoo/ # import of "foo" library
标准（基于autotools的）构建系统构建libfoo，然后构建myproject，动态链接libfoo。
libfoo基本上没有修改（有一些小的修改，以适当地适应构建系统）。 libfoo本身使用autotools，所以我通常使用AC_CONFIG_SUBDIRS递归调用configure。
但是，libfoo已经打包用于各种发行版，所以我想避免在这些系统上构建导入的库，而是使用系统范围的安装 - 这样我就可以获得更好的维护版本的好处libfoo（更少的错误，安全问题，......）。
otoh，我想在我的源代码树中保留libfoo，这样我就可以在没有发布该库的系统上进行构建（没有用户需要单独获取源代码并自己构建lib）。
我可以想到我可以介绍的一些配置标志，因此用户可以选择是否要使用系统安装，本地或没有库来构建项目。 （这是一个可选的依赖）。 禁用“本地foo”，应该完全禁用libfoo的构建（也可能还要配置foo）
e.g。类似的东西：
./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选择的最佳做法是，使用本地副本或库，系统范围的副本还是根本不使用该库？
指向使用这种机制的项目非常受欢迎。
答案 0 :(得分：3)
我的项目中有类似的情况，我在使用包含的BuDDy库版本时（1）尚未安装库，或者（2）它已安装但不需要我期望的接口，或者（ 3）configure与--with-included-buddy一起运行。
您可以看到configure宏here。之后，我只在$(BUDDY_CPPFLAGS)中使用$(BUDDY_LDFLAGS)和Makefile.am，而the top-level Makefile.am仅在buddy中有条件地包含SUBDIRS目录。
答案 1 :(得分：1)
我在处理external software时更喜欢--with- foo ，但这只是一种偏好。链接中的示例和文档可能有助于您决定如何执行此操作。我将使用您的第一个示例，该示例仅使用一个标志，而不是使用两个标志的第二个示例，以便于文档/维护。
答案 2 :(得分：1)
你将使构建机器变得更复杂，并且大多数人都认为autotools被认为是黑魔法。对于开发人员来说，这会让事情变得复杂得多，对于潜在的发行版打包程序来说会有点复杂，对于最终用户而言也会更加复杂。
如果您有条件地配置，那么您将构建分发tarball（make dist / make distcheck）的过程变得更加脆弱。
This is the sort of trouble you can cause.
您可以调整my recent answer中的代码。