In my configure/configure.ac, I do multiple PKG_CHECK_MODULES calls. Most of them return the same -I path:-I/usr/local/include, and also the same -L path: -L/usr/local/lib.
I would say that -I path doesn't do any difference, because gcc compiles one source at time. It might make a difference when multiple sources would be compiled?
However, it probably does make a difference for libraries, as following constructs are possible:
-L/usr/local/lib -lX11 -L/usr/lib -lcurses -L/opt/lib -lcups
I guess that each -L option changes current top library search path.
Is this all correct? Should I ignore -I redundance, or try to collapse the paths? How to collapse them?
(PS. Please don't get confused about letters in -I, -l: the first one is capital "i", the include path option about which I am asking)
Each -L option actually just adds something to the end of the current search path, which means that linking against different libraries in different locations is a hard problem to produce a general solution for. If you have the same two libraries in two locations A and B, and you want the first library from A and the second library from B, it's surprisingly annoying to do that with -L options. You end up having to include the full path to the .so file on the link line instead.
In other words, in:
-L/usr/local/lib -lX11 -L/usr/lib -lcurses -L/opt/lib -lcups
libcups will be searched for in /usr/local/lib first, then /usr/lib, and then /opt/lib. If there is a libcups in /usr/local/lib, you'll still get the wrong one. About the only way to be sure is to replace -L/opt/lib -lcups with /opt/lib/libcups.so (which is not as portable; it doesn't work on HP-UX or AIX, for example).
To answer your question, for the most part people don't bother trying to clean up the redundancy. This sort of compilation command line is fairly typical in projects that use multiple libraries.