在我的configure/configure.ac，我做了多个PKG_CHECK_MODULES调用。他们大多返回相同的-I path:-I/usr/local/include，也是相同的-L path: -L/usr/local/lib.应该（以及如何去做）包含路径在配置脚本中折叠？
我会说-I path没有任何区别，因为海湾合作委员会编译一个时间源。编译多个源代码可能会有所不同？
但是，它可能确实让图书馆的差别，如下结构是可能的：
-L在/ usr/local/lib目录-lX11 -L/usr/lib目录-lcurses -L /选择/ lib -lcups
我猜想每个-L option都会改变当前顶层库的搜索路径。
这一切是否正确？我应该忽略-I冗余，还是尝试折叠路径？如何折叠它们？
（PS请不要在-I弄不清楚信件，-l：第一个是资本"i"中，包括哪些我问路径选项）
每个-L选项实际上只是增加了一些东西到当前搜索路径的结尾，这意味着与不同位置的不同库链接是一个难以产生通用解决方案的难题。如果在两个位置A和B中有相同的两个库，并且您想要A的第一个库和B的第二个库，那么使用-L选项来执行此操作令人惊讶。您最终不得不在链接行中包含文件.so的完整路径。
换句话说，在：
-L/usr/local/lib -lX11 -L/usr/lib -lcurses -L/opt/lib -lcups
libcups将在/usr/local/lib第一，然后/usr/lib被搜索，然后/opt/lib。如果在/usr/local/lib有一个libcups，你仍然会得到一个错误的。关于确定的唯一方法是用/opt/lib/libcups.so替换-L/opt/lib -lcups（它不像便携式;它不适用于HP-UX或AIX）。
要回答你的问题，大多数人不打算试图清理冗余。这种编译命令行在使用多个库的项目中相当典型。
可以修改PKG_CHECK_MODULES放置必要的标志为LDFLAGS和CPPFLAGS，而不是FOO_LIBS和FOO_CFLAGS并将其检查的pkg-config结果是多余的，如果已经存在不加入他们。在这样做的时候，增加一些AC_CHECK_LIB的调用来验证pkg-config返回的信息是明智的。由于他们不再需要明确引用@[email protected]和@[email protected]，因此它具有大量清理所有Makefile.am的额外好处。但是，停止使用PKG_CHECK_MODULES可能更容易。 （见PKG_CHECK_MODULES considered harmful?）