在我的configure/configure.ac中，我打了多个PKG_CHECK_MODULES电话。他们中的大多数返回相同-I path:-I/usr/local/include，也相同-L path: -L/usr/local/lib.
我会说这-I path没有任何区别，因为 gcc 一次编译一个源。编译多个源时可能会有所不同？
但是，它可能确实对库产生了影响，因为以下构造是可能的：
-L/usr/local/lib -lX11 -L/usr/lib -lcurses -L/opt/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。如果 中有一个 libcups /usr/local/lib，你仍然会得到错误的。唯一可以确定的方法是替换-L/opt/lib -lcups为/opt/lib/libcups.so（它不那么便携；例如，它不适用于 HP-UX 或 AIX）。
要回答您的问题，大多数情况下人们不会费心尝试清理冗余。这种编译命令行在使用多个库的项目中相当典型。
您可以修改PKG_CHECK_MODULES以将必要的标志放入LDFLAGSandCPPFLAGS而不是FOO_LIBSandFOO_CFLAGS并让它检查结果是否pkg-config是多余的，如果已经存在则不要添加它们。这样做时，明智的做法是添加一些 的调用AC_CHECK_LIB来验证pkg-config. 这有一个额外的好处，那就是基本上清理你所有的Makefile.am，因为它们不再需要显式引用@FOO_LIBS@and @FOO_CFLAGS@。但是，停止使用可能更容易PKG_CHECK_MODULES。（参见PKG_CHECK_MODULES 是否认为有害？）