Don't add generator expressions to variables which are used
for CMP0003, CMP0004, and the old-style _LIB_DEPENDS content. They
will not be evaluated when read anyway and would probably confuse
the code reading them.
This makes it legitimate to use target_link_libraries with generator
expressions as arguments.
77d2646 Allow generator expressions in LINK_INTERFACE_LIBRARIES.
94aeaf7 Split LINK_INTERFACE_LIBRARIES export handling into dedicated method.
a3aedb8 Split the generator expression before extracting targets.
b6036d1 Extract the AddTargetNamespace method.
cb1afbf Don't pass a position when determining if a target name is a literal.
f99196d Add cmGeneratorExpression::Split() API.
In the implementation of "cmake -E cmake_link_script", skip lines from
the input file that are empty or contain only whitespace. Do not try to
run a child with no command line.
The Config and IMPORTED_ variants may also contain generator
expressions.
If 'the implementation is the interface', then the result of
evaluating the expressions at generate time is used to populate
the IMPORTED_LINK_INTERFACE_LIBRARIES property.
1) In the case of non-static libraries, this is fine because the
user still has the option to populate the LINK_INTERFACE_LIBRARIES
with generator expressions if that is what is wanted.
2) In the case of static libraries, this prevents a footgun,
enforcing that the interface and the implementation are really
the same.
Otherwise, the LINK_LIBRARIES could contain a generator
expression which is evaluated with a different context at build
time, and when used as an imported target. That would mean that the
result of evaluating the INTERFACE_LINK_LIBRARIES property for
a static library would not necessarily be the 'link implementation'.
For example:
add_library(libone STATIC libone.cpp)
add_library(libtwo STATIC libtwo.cpp)
add_library(libthree STATIC libthree.cpp)
target_link_libraries(libtwo
$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>)
target_link_libraries(libthree libtwo)
If the LINK_LIBRARIES content was simply copied to the
IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but
executables linking to libthree will not link to libone.
3) As the 'implementation is the interface' concept is to be
deprecated in the future anyway, this should be fine.
Now that we're processing a LINK_INTERFACE_LIBRARIES string, it
can contain targets. Make sure they are extracted for
namespacing purposes.
This needs to be restricted to strings which can actually have
targets named in them. For example, this is not done for
INTERFACE_COMPILE_DEFINITIONS, because even if there is a target
named 'foo', the string 'foo' in that property means that '-Dfoo'
will be set when compiling.
3581b96 Process the INTERFACE_PIC property from linked dependencies
042ecf0 Add API to calculate link-interface-dependent bool properties or error.
bf5ece5 Keep track of properties used to determine linker libraries.
0380f36 FindOpenGL: add Haiku paths
8e9630c FindGLUT: BeOS does not have libXi and libXmu
50bfedf FindLua51: do not try to link libm on BeOS
3d2e6a0 check for Haiku only with __HAIKU__
7a1b961 Haiku no longer defines __BEOS__
ed96d9a bootstrap: use better defaults for Haiku
This allows a dependee to inform a target that it should have its
POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of
the POSITION_INDEPENDENT_CODE property, if set, must be consistent
with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees.
Add a test covering the consistency checks on platforms where they run.
This new method checks that the property FOO on a target is consistent
with the INTERFACE_FOO properties of its dependees. If they are not the
consistent, an error is reported. 'Consistent' means that iff the
property is set, it must have the same boolean value as all other
related properties.
This makes
set(CMAKE_BUILD_INTERFACE_INCLUDES ON)
add the equivalent of
set_property(TARGET tgt APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}>
)
to every target.
If the headers are in CMAKE_CURRENT_SOURCE_DIR, and the generated headers
are in CMAKE_CURRENT_BINARY_DIR, this is a convenient way to build a target
bar, which depends on foo, just by using target_link_libraries() and adding
the INTERFACE_INCLUDE_DIRECTORIES to the INCLUDE_DIRECTORIES of the target
being linked. There will be more-convenient porcelain API to consume the
property in the future.
This makes it possible to use:
target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar)
where foo is an IMPORTED target. Other tll() signatures are not
allowed.
Previously we kept direct link dependencies in OriginalLinkLibraries.
The property exposes the information in the CMake language through the
get/set_property commands. We preserve the OriginalLinkLibraries value
internally to support old APIs like that for CMP0003's OLD behavior, but
the property is now authoritative. This follows up from commit d5cf644a
(Split link information processing into two steps, 2012-11-01).
This will be used later to populate the link interface properties when
exporting targets, and will later allow use of generator expressions
when linking to libraries with target_link_libraries.
Also make targets depend on the (config-specific) union of dependencies.
CMake now allows linking to dependencies or not depending on the config.
However, generated build systems are not all capable of processing
config-specific dependencies, so the targets depend on the union of
dependencies for all configs.
The 'head' is the dependent target to be linked with the current target.
It will be used to evaluate generator expressions with proper handling
of mapped configurations and is used as the source target of properties.
This requires that memoization is done with a key of a pair of target
and config, instead of just config, because now the result also depends
on the target. Removing the memoization entirely is not an option
because it slows cmake down considerably.
cc676c3 OS X: Detect implicit linker framework search paths
2dd67c7 OS X: Detect implicit link directories on modern toolchains
ba58d0c OS X: Link with all framework search paths, not just the last
894f52f Handle INTERFACE properties transitively for includes and defines.
f5b1980 Populate the ExportedTargets member early in GenerateMainFile
c67b812 Make cycles in target properties ignored, not an error.
d0f950f Use mapped config properties to evaluate $<CONFIG>
26def17 Make all relevant targets available in the genex context.
0c657dc Add API to populate INTERFACE properties in exported targets.
e04f737 Add API to extract target names from a genex string.
b0c8f73 Add the TARGET_NAME generator expression.
77475fe Allow generator expressions to require literals.
b2f1700 GenEx: Add expressions to specify build- or install-only values
Since commit 9a6ff950 (Fix for bug where VS2010 did not use .obj files as
part of the build, 2011-04-01) and commit b291d9e7 (VS10: Fix external
objects generated outside target, 2012-03-19) we try to detect whether an
external object file is also a custom command output in the same target.
This is because VS10 includes .obj custom command outputs on the link line
by default.
VS 11 supports a "<LinkObjects ...>false</LinkObjects>" setting in custom
command rules to tell VS not to link the outputs. From the VS help:
Specify whether the Inputs and output files with specific extensions (.obj,
.lib, .res, .rsc) are passed to the linker.
Treat all external object files the same and add "<Object>" settings for them.
The member variable is checked to determine whether to call
HandleMissingTarget(). As that could be called during the loop in
the comming commits, ensure that it contains all targets being
exported.
Constructs such as these are an error as they are direct self-references:
set_property(TARGET foo APPEND PROPERTY
INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
set_property(TARGET foo APPEND PROPERTY
INCLUDE_DIRECTORIES $<TARGET_PROPERTY:INCLUDE_DIRECTORIES>)
However, this is an indirect self-reference in a cycle, and not an error:
set_property(TARGET foo APPEND PROPERTY
INCLUDE_DIRECTORIES $<TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES>)
set_property(TARGET bar APPEND PROPERTY
INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
The TARGET_NAME expression, which requires a literal, provides
target names. $<TARGET_PROPERTY:tgt,prop> also provides target
names in the cases where tgt is a literal, so that TARGET_NAME is
not needed then in addition.
This is for specifying INCLUDE_DIRECTORIES relevant to the build-location
or the install location for example:
set_property(TARGET foo PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
"$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>"
"$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include>"
)
A 'bar' target can then use:
set_property(TARGET bar PROPERTY
INCLUDE_DIRECTORIES
"$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>"
)
and it will work whether foo is in the same project, or an imported target
from an installation location, or an imported target from a build location
generated by the export() command.
Because the generator expressions are only evaluated at build-time, these
new expressions are equivalent to the ZeroNode and OneNode.
The GeneratorExpression test is split into parts. Some shells can't run
the custom command as it is getting too long.
Xcode and VS <= 7.1 will not build targets that have no source files
besides $<TARGET_OBJECTS:...>. Suggest in the documentation that
projects always add at least one real source file.
0941d62 Add a way to print the origins of used include directories.
18a3195 Keep track of INCLUDE_DIRECTORIES as a vector of structs.
76ea420 Use cmsys::auto_ptr to manage cmCompiledGeneratorExpressions
Note it is still possible for CTest to start more than the number of
processes specified by PARALLEL_LEVEL, but this prevents the number of
tests to start from being unbounded because of overflow.
Previously we hard-coded a list of implicit framework directories but
did not account for CMAKE_OSX_SYSROOT or for changes to the list across
OS X versions. Instead we should automatically detect the framework
directories for the active toolchain.
The parent commit added the "-Wl,-v" option to ask "ld" to print its
implicit directories. It displays a block such as:
Framework search paths:
/...
Parse this block to extract the list of framework directories.
Detection may fail on toolchains that do not list their framework
directories, such as older OS X linkers. Always treat the paths
<sdk>/Library/Frameworks
<sdk>/System/Library/Frameworks
<sdk>/Network/Library/Frameworks # Older OS X only
/System/Library/Frameworks
as implicit. Note that /System/Library/Frameworks should always be
considered implicit so that frameworks CMake finds there will not
override the SDK copies.
Refactoring in commit 8d674e78 (Ninja: move -LIBPATH behind -link
option, 2012-09-26) accidentally added code that overwrites the
framework search path flags on each iteration instead of appending.
Change '=' to '+=' to fix it. This affects Makefile and Ninja
generators.
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
Brad King
Stephen Kelly
Kitware Robot
Yury G. Kudryashov
Rolf Eike Beer
Peter Kümmel
Eric LaFranchi
David Cole
Casey Goodlett
Alex Neundorf
Nils Gladitz
Patrick Gansterer
Mathias Gaunard
Clemens Heppner