Extend documentation for CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES to
explain how it is used by CMake and how it can be influenced by
environment variables.
Inspired-by: Alex Neundorf <neundorf@kde.org>
f0d9385 Makefile: Use modern link information for framework search paths
2bc22bd Xcode: Add frameworks search paths from link dependeny closure (#13397)
Use cmComputeLinkInformation::GetFrameworkPaths to get the list of
framework paths needed by the linker. Drop the now unused framework
information from the old-style cmTarget link dependency analysis.
This should finally fix#13667 and #13762.
Instead of adding special handling to guess whether implicit include dirs
may have been removed, simply make it possible to query the include dirs
without removing the implicit ones.
Alex
The Xcode generator produces FRAMEWORK_SEARCH_PATHS from:
(1) Include directories of the form /path/to/Foo.framework become
-F/path/to so '#include <Foo/H>' can find H in the framework.
(2) Linked frameworks of the form /path/to/Foo.framework become
-F/path/to -framework Foo so the linker can find the framework.
Originally commit 82bb6fae (add framework support to FIND_FILE,
2005-12-27) added these and used the (then current) old-style link
dependency analysis results to get the frameworks. Later a second
setting was added by commit 2ed6191f (add initial xcode framework stuff,
2007-05-08) to transform -F/path/to linker options produced by the old
link line generation into entries appended to FRAMEWORK_SEARCH_PATHS.
Then commit 96fd5909 (Implement linking with paths to library files,
2008-01-22) updated the second setting to directly use the results of
full modern link dependency analysis, but forgot to remove the use of
old-style link results from the original setting location.
The two settings worked together for a while, with the second one
appending to the first. Then commit f33a27ab (Generate native Xcode 3.0
and 3.1 projects, 2009-06-29) changed the internal representation format
produced by the first setting but did not update the second setting to
append to the new representation. As a result, if the first setting
added any paths (usually via the old-style link analysis) then the
second setting containing the modern link analysis results would not be
applied at all.
Fix this by removing use of the old-style link analysis results.
Replace it using the modern link dependencies and remove the second
setting altogether. Now all values for FRAMEWORK_SEARCH_PATHS are
collected in one place so no special append logic is needed.
Historically CMake has always expanded ${} variable references in the
values given to include_directories(), link_directories(), and
link_libraries(). This has been unnecessary since general ${}
evaluation syntax was added to the language a LONG time ago, but has
remained for compatibility with VERY early CMake versions.
For a long time the re-expansion was a lightweight operation because it
was only processed once at the directory level and the fast-path of
cmMakefile::ExpandVariablesInString was usually taken because values did
not have any '$' in them. Then commit d899eb71 (Call
ExpandVariablesInString for each target's INCLUDE_DIRECTORIES,
2012-02-22) made the operation a bit heavier because the expansion is
now needed on a per-target basis. In the future we will support
generator expressions in INCLUDE_DIRECTORIES with $<> syntax, so the
fast-path in cmMakefile::ExpandVariablesInString will no longer be taken
and re-expansion will be very expensive.
Add policy CMP0019 to skip the re-expansion altogether in NEW behavior.
In OLD behavior perform the expansion but improve the fast-path
heuristic to match ${} but not $<>. If the policy is not set then warn
if expansion actually does anything. We expect this to be encountered
very rarely in practice.
CONFIGURE_PACKAGE_CONFIG_FILE() now additionally generates
"Any changes to this file will be overwritten by the next CMake run
The input file was FooConfig.cmake.in"
into the configured file.
Alex
Eliminate the platform difference in calling stat. We call stat normally
in other places in the CMake code base just fine. Works everywhere we
work. Will hopefully also fix the Borland Continuous dashboard failure
that is occurring with respect to correctly measuring the modification
time of a freshly generated file.
Handle OpenBSD specific paths in Qt3/Qt4, allowing concurrent building
and installation. Some common programs are renamed with suffixes of
either 3 or 4. Also, allow qt3/qt4 installed under /usr/local to be
searched and recognized appropriately.
Kitware Robot
David Cole
Brad King
Alex Neundorf
Amit Kulkarni
Nils Gladitz