David Faure wrote: > The -L parameters are definitely generated, by cmake. > The question is how. And the answer is complex AFAIK, and depends on the > cmake version.
In CMake 2.4 the set of -L paths come from arguments to the link_directories() command and the locations of libraries given to target_link_libraries() by full path. In CMake 2.6 the latter case is usually handled just by passing the full path to the library file directly to the linker with no searching, but there are still some cases where it behaves similarly to 2.4. The input to the ordering algorithm is the original list of user-specified library search paths (given to link_directories) plus some set of library file full paths. The output is an ordered linker search path. We try to preserve the original order of user-specified directories, but the main rule is that the order is such that the libraries whose full paths are known will be found first if the linker searches for them with a -lfoo option. This guarantees that when a library is specified by full path that the copy of the library is favored over any other copy of the library at another place in the linker search path. CMake actually inspects all the linker search path locations to look for possibly conflicting files and builds a constraint graph. A topological sort on the resulting constraint graph produces the order. The order among an unconstrained group of paths is that in the original user-specified order. This is done much more formally in CMake 2.6 than in 2.4. -Brad _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem