一个项目附带一个库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维护版本的好处（更少的bug，安全性）问题...）。 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选择的最佳做法是什么，是使用本地副本还是库，系统范围的副本还是根本不使用库？
指向使用这种机制的项目的指针是最受欢迎的。
我在我的项目中有一个类似的地方，我在使用包含的BuDDy库版本时（1）尚未安装库，或者（2）它已安装但不需要我期望的接口，或者（3）configure与--with-included-buddy一起运行。
你可以看到configure宏here。之后我只在$(BUDDY_CPPFLAGS)s中使用$(BUDDY_LDFLAGS)和Makefile.am，而the top-level Makefile.am仅在buddy中有条件地包含SUBDIRS目录。
在与--with-打交道时，我更喜欢external softwarefoo，但这只是一种偏好。链接中的示例和文档可能有助于您决定如何执行此操作。我将使用您的第一个示例，该示例仅使用一个标志而不是第二个使用两个标志以便于文档/维护的标志。
你将使构建机器变得更复杂，并且大多数人都认为autotools被认为是黑魔法。对于开发人员来说，这会让事情变得复杂得多，对于潜在的发行版打包程序来说会有点复杂，而对于最终用户来说则更加容易。
如果您有条件地配置，那么您将构建分发tarball（make dist / make distcheck）的过程更加脆弱。
This is the sort of trouble you can cause.
您可以在my recent answer中调整代码。