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.
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.
...revealed by the Nightly dashboard runs last night.
Use "size_t" instead of "std::size_t" so that it compiles with
Visual Studio 6, too.
Fix warnings about shadowed "tmp" local variable and ordering of
member variables vs. lines of code in the constructor initializer
list.
Solution folders are supported as read-only in the VS11 Express
Edition, so do not prohibit their use just because we detect the
express edition (as we did in the VS10 generator).
Inspired-by: Paris
Use same technique here with UuidToString as already found in
cmGlobalVisualStudio7Generator::CreateGUID to avoid using a type
that is not defined on older systems... (VS 7.0 and Borland)
This new CPack generator produces an *.msi installer file.
Requires having the WiX Toolset installed in order to work
properly.
Download the WiX Toolset installer "WiX36.exe" here:
http://wix.codeplex.com/releases/view/93929
Previously it was necessary for writers of Config files
which incude exported target files to write the guard themselves, but
this was not immediately obvious or documented. Options for them
would be to use a variable, or an INHERITED directory property in an
effort to avoid accidental name clashes in all contexts in
which find_package can be used.
Getting this right requires boiler plate code, so generate a simpler
check automatically instead.
3a1006e VS: Added "Deploy" at project configuration for WindowsCE targets
40c36c9 VS: Make DetermineCompilerId working with WinCE too
038df9e VS: Allow setting the name of the target platform
6fe4fcb VS: Add parser for WCE.VCPlatform.config to read WinCE platforms
2118a20 VS: Support setting correct subsystem and entry point for WinCE
6920fed VS: Change variable type of Name from const char* to string
102521b VS: Change variable type of ArchitectureId from const char* to string
332dc09 VS: Add static method to get the base of the registry
d41d4d3 VS: Add CMAKE_VS_PLATFORM_NAME definition to cmMakefile
14861f8 VS: Remove TargetMachine for linker when checking compiler id
0bbae6f Revert "Move GetLinkInformation to cmGeneratorTarget"
d5cf644 Split link information processing into two steps.
d8a59ea Port cmGeneratorExpression to cmTarget from cmGeneratorTarget.
Add a dummy mainCRTStartup() function, since the linker searches for
it instead of main() and set the CMAKE_SYSTEM_* variables depending
on the MSVC_C_ARCHITECTURE_ID and CMAKE_VS_WINCE_VERSION variables.
Parse the WCE.VCPlatform.config file, which contains the installed
WindowsCE SDKs in XML format, and add possibility to generate
Visual Studio generators for them.
Implement support for multiarch include directories as specified here:
https://wiki.ubuntu.com/MultiarchCross
Generalize the multiarch feature added in commit b41ad3b3 (Teach
find_(library|package) about Linux multiarch, 2011-06-08) to the
find_path and find_file commands. Teach them to search
<prefix>/include/<arch> whenever they would search <prefix>/include.
When adding more platforms to the Visual Studio generators a simple
regular expressing can not handle all cases anymore. This new
define holds the name of the Visual Studio target platform.
add_custom_command can have empty DEPENDS arguments, which
was triggering invalid makefile generation for the NMake
Makefiles generator. We were mistakenly emitting the build
directory appended with "/" plus the empty string... which
was then translated to a string ending in \" in build.make...
which nmake choked on.
The solution is not to emit any dependency when the input
DEPENDS is the empty string. Return early from GetRealDependency
in this empty input case.
This is for consistency throughout cmake. The cmsys version exists
becaues uses of auto_ptr types as return types does not work with
some implementations in ancient compilers.
Following from the discussion here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5170
(Re: Generator expressisons in target properties, 26 Oct 12:10)
we can't split cmTarget API for linking into cmGeneratorTarget. In
the future we will probably also need to move the include and compile
definitions API back to cmTarget so that it can be used by export().
75ebebc VS: Remove platform specific generator files
8b62080 VS: Remove EnableLanguage from platform-specific generators
5bdf011 VS: Remove GetPlatformName from platform-specific generators
8d42ab4 VS: Fix ArchitectureId of Visual Studio 10 IA64 generator
6f439b3 VS: Remove AddPlatformDefinitions from platform-specific generators
5170a88 Make cmGlobalGenerator::GetDocumentation() a static function
04ff866 Allow a GeneratorFactory handling of more than one generator
984ebc3 Search generator in cmake::ExtraGenerators before in cmake::Generators
30a6950 Add cmGlobalGeneratorFactory::GetGenerators()
e8f8414 Introduce the abstract class cmGlobalGeneratorFactory
On some systems, ${QT_INCLUDE_DIR} is reported by gcc as a builtin
include search dir. Some projects use this information to extend
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES.
In cmake 2.8.10 now the targets are queried for the include directories
they use. When they return the result, the include dirs contained in
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES have been removed.
In cmake 2.8.9 and below the INCLUDE_DIRECTORIES directory property
was queried, where this had not been stripped.
So, in those projects which modify the implicit include dirs variable,
on systems where ${QT_INCLUDE_DIR} is reported by gcc, this directory,
e.g. /usr/lib/include/qt/, was not given anymore to moc. This made moc
not find required headers, so the build broke.
Simply giving the full CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES to moc
is no solution either, since moc can't handle some of the headers it
finds then (https://bugreports.qt-project.org/browse/QTBUG-28045).
So now cmake checks CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES, and if this
contains ${QT_INCLUDE_DIR}, and the target reports that it uses
${QT_QTCORE_INCLUDE_DIR} but not ${QT_INCLUDE_DIR}, ${QT_INCLUDE_DIR}
is added to the include dirs given to moc.
Alex
Pass the name of the requested generator to the generator factory,
which is now responsible to check if it can create a matching
generator for the name. This allows us to add more logic to the
factory in a next step, so that not every possible generator needs
to get registered explicit in cmake::AddDefaultGenerators().
Since ExtraGenerators does not contain items, which are in Generators
too, there is not change in behaviour. The benefit of this change is,
that the lookup in the Generators map is now only done once.
Kitware Robot
Brad King
David Cole
Alex Neundorf
Nils Gladitz
Patrick Gansterer
Stephen Kelly
Mathias Gaunard
Clemens Heppner
Peter Kümmel
David Golub