ba48e63 Generate config-specific interface link libraries propeties.
deb51a7 Remove unused forward declarations.
9712362 Don't allow utility or global targets in the LINKED expression.
faa927e Make sure INTERFACE properties work with OBJECT libraries.
510fdcb Whitelist target types in target_{include_directories,compile_definitions}
4de7178 Ensure that the build interface includes have been added.
df74bc3 Only append build interface include dirs to particular targets.
d4e5c67 Don't keep track of content determined by target property values.
1fb545a Move a special case for PIC from the genex to the cmTarget code.
57175d5 Only use early evaluation termination for transitive properties.
4cf161a Fix determination of evaluating link libraries.
3a298c0 Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.
655e98b Ensure type specific compatible interface properties do not intersect.
46e2896 The COMPATIBLE_INTERFACE does not affect the target it is set on.
5f926a5 Test printing origin of include dirs from tll().
7c0ec75 De-duplicate validation of genex target names.
...
Since commit fd33bf93 (fix for bug 6102, allow users to change the
compiler, 2007-12-13) we keep an internal ;-list of language compiler
variable and value pairs. Preserve empty values on expansion to ensure
that the key/value pairing remains consistent.
This is needed in the case that Automoc is used, as that calls
GetIncludeDirectories, which may cache the resulting include dirs
too early in the generate step.
Also, because the automoc step is so early, we can't cache the
include directories at that point. At that point the build interface
of all dependencies are not populated yet, so we'd be caching the
includes before appending the build interface. Only start caching
when we're definitely generating the buildsystem. At that point, the
includes should be stable.
We still need to invoke AppendBuildInterfaceIncludes
in the GlobalGenerator because the build interface includes affect
mostly the dependencies of targets (such as the automoc targets),
rather than the targets themselves, so the build interface needs
to be appended for all targets before generation is done.
The ctest_configure command already reads the CTEST_CMAKE_GENERATOR
variable to get the value for the cmake -G option. Read new variable
CTEST_CMAKE_GENERATOR_TOOLSET for -T.
The "ctest --build-and-test" mode already has "--build-generator" to
specify the -G option to CMake. Add a "--build-generator-toolset" option
to specify the -T value.
Implement generator toolset selection (cmake -T) for VS >= 10 by setting
the PlatformToolset. Extend the RunCMake.GeneratorToolset test case to
verify CMAKE_GENERATOR_TOOLSET when the generator supports -T.
Since commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23)
all MSVC version information is detected during the compiler id step
from the actual compiler invoked by generated build systems rather than
hard-coded in VS generators. Therefore we can set the PlatformToolset
in VS >= 10 project files and support toolsets from other VS versions.
Reject the option by default. It will be implemented on a per-generator
basis. Pass the setting into try_compile project generation. Add cache
entry CMAKE_GENERATOR_TOOLSET and associated variable documentation to
hold the value persistently.
Add a RunCMake.GeneratorToolset test to cover basic "-T" option cases.
Verify that CMAKE_GENERATOR_TOOLSET is empty without -T, that -T is
rejected when the generator doesn't support it, and that two -T options
are always rejected.
This tracking was added during the development of commit 042ecf04
(Add API to calculate link-interface-dependent bool properties
or error., 2013-01-06), but was never used.
It was not necessary to use the content because what is really
useful in that logic is to determine if a property has been implied
to be null by appearing in a LINK_LIBRARIES genex.
I think the motivating usecase for developing the feature of
keeping track of the targets relevant to a property was that I
thought it would make it possible to allow requiring granular
compatibility of interface properties only for targets which
depended on the interface property. Eg:
add_library(foo ...)
add_library(bar ...)
add_executable(user ...)
# Read the INTERFACE_POSITION_INDEPENDENT_CODE from bar, but not
# from foo:
target_link_libraries(user foo $<$<TARGET_PROPERTY:POSTITION_INDEPENDENT_CODE>:bar>)
This obviously doesn't make sense. We require that INTERFACE
properties are consistent across all linked targets instead.
We need to make sure expressions which evaluate TARGET_PROPERTY:TYPE
multiple times for example get the correct result each time, and
not an empty string instead.
As INTERFACE_COMPILE_DEFINITIONS are now possible, we can have
situations like this:
add_library(foo ...)
add_library(bar ...)
target_link_libraries(foo bar)
target_compile_definitions(bar INTERFACE SOME_DEF)
The INTERFACE_COMPILE_DEFINITIONS of bar determine how foo should be
compiled, and if they change, foo should be rebuilt.
Additionally, as of commit d1446ca7 (Append the COMPILE_DEFINITIONS
from the Makefile to all targets., 2012-09-17), we don't need to
read definitions from the makefile if we read them from the target,
so also de-duplicate the cached info.
The DependInfo for INTERFACE_INCLUDE_DIRECTORIES is already handled
correctly.
Remove the old "nocwd" behavior that attempts to provide the "--help"
output when no working directory is available. The long help output
scrolls the real error message out of typical terminal sizes. Also
execute as little code as possible when no working directory exists.
Since commit 08cb4fa4 (Process generator expressions in the
INCLUDE_DIRECTORIES property., 2012-09-18), it is possible to use
generator expressions with the include_directories command.
As that command can also have a SYSTEM argument, ensure that the
result of using that argument with generator expressions gives a
sane result.
e48d842 Cache context-independent includes on evaluation.
089fe1c Optimize genex evaluation for includes and defines.
179f495 find_package: Reword <package>_NO_INTERFACES documentation
e7b579b Test workaround of bad interface include directories from depends.
77cecb7 Add includes and compile definitions with target_link_libraries.
0b92602 Add the $<LINKED:...> generator expression.
0fa7f69 Add API to check if we're reading a includes or defines property.
2c3654c Add a way to exclude INTERFACE properties from exported targets.
d4297d5 Export targets to a targets file, not a Config file.
df4d2b2 Make it an error for INSTALL_PREFIX to be evaluated.
7ceeba9 Advance more when preprocessing exported strings.
30268b4 Handle reading empty properties defined by the link interface.
The commit 18a3195a ('Keep track of INCLUDE_DIRECTORIES as a vector
of structs.', 2012-11-19) moved the handling of includes from
cmGeneratorTarget to cmTarget, but in the process introduced this
bug.
link.exe has problems with very very long lines in rsp files too.
Use $in_newline instead of $in variable for rspcontent which
separates the arguments with a newline instead of a simple space
and was specially made for this purpose.
Since commit d46d8df0 (Re-implemented cmGeneratedFileStream to look like a
real stream and replace the destination file atomically, 2004-11-03) our
RenameFile implementation tries to deal with MoveFile not replacing
read-only files. In order to avoid the Get/SetFileAttributes pair we used
stat to test for existence of the destination file. This has a race in
which the destination could be created between the test for existence and
the MoveFile call.
Remove the stat call and use GetFileAttributes to detect whether the file
exists. This shortens the race but does not eliminate it. Use a loop to
try multiple times in case we lose the race. While at it, drop Win9x
support and always use MoveFileEx.
Generator expressions whose output depends on the configuration
now record that fact. The GetIncludeDirectories method can use
that result to cache the include directories for later calls.
GetIncludeDirectories is called multiple times for a target
for each configuration, so this should restore performance for
multi-config generators.
While porting boost to use these features, the generation step took
too long (several minutes before I stopped it). The reason was that
the boost libraries form a large interdependent mesh. The libraries
list their dependencies in their INTERFACE such as:
$<LINKED:boost::core>;$<LINKED:boost::config>;$<LINKED:boost::mpl>
As boost::core already depends on the boost::config libraries, that
expression has no impact on the end-content, as it is removed after
the generation step. There is no DAG issue though, so the generator
expression evaluation would fully evaluate them. In the case of the
config library, it also depends on the core library, so all depends
are followed through that again, despite the fact that they've just
been evaluated. After this patch, the evaluation skips libraries if
they have already been seen via depends or directly in the content.
This patch keeps track of targets whose INTERFACE has been consumed
already. The INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS properties
are whitelisted because repeated content will be stripped out later
during generation. For other properties now and in the future, that
may not be the case.
This establishes that linking is used to propagate usage-requirements
between targets in CMake code. The use of the target_link_libraries
command as the API for this is chosen because introducing a new command
would introduce confusion due to multiple commands which differ only in
a subtle way.
This is both a short form of using a TARGET_DEFINED expression
together with a TARGET_PROPERTY definition, and a way to strip
non-target content from interface properties when exporting.
Projects set interface requirements upstream, and existing
downstreams use of target_link_libraries will consume those interfaces.
This can create a backward compatibility concern as the result may
be changing the order of include directories of downstreams, or another
side-effect of using the INTERFACE properties.
Provide a way for them to emulate the behavior of a version-based
policy in the config file.
Both commit 8a37ebec (Add the target_include_directories command,
2013-01-01) and commit fc61a7a7 (Add the target_compile_definitions
command, 2013-01-08) added command implementations deriving from the new
cmTargetPropCommandBase class. Fix cmTypeMacro declarations of the
inheritance relationship.
7bf490e Make subclasses responsible for joining content.
f6b16d4 Don't allow targets args in the new target commands.
b3a7e19 Make the Property name protected so that subclasses can use it.
We need to make sure we can export targets which have content such
as $<0:$<TARGET_PROPERTY:not_a_target,INTERFACE_INCLUDE_DIRECTORIES>
That means making not finding a target non-fatal here.
Explain in the documentation for the legacy signature
target_link_libraries(foo bar)
that the other signatures like
target_link_libraries(foo LINK_INTERFACE_LIBRARIES ...)
target_link_libraries(foo LINK_PRIVATE ...)
will set the LINK_INTERFACE_LIBRARIES target property and therefore make
libraries specified only by the legacy signature private.
These interface-related link-libraries properties are used to determine
the value of the other INTERFACE properties, so we were getting infinite
recursion and segfaults otherwise.
6063fef Output include directories as LOG messages, not warnings.
aa66748 Specify the target whose includes are being listed.
d70204a Only output includes once after the start of 'generate-time' when debugging.
0d46e9a Store includes from the same include_directories call together.
830246e Export the COMPATIBLE_INTERFACE_BOOL content properties
bd82bb4 Clear the link information in ClearLinkMaps.
e987991 Make INTERFACE determined properties readable in generator expressions.
d9afacc Exit early if we find an inconsistent property.
1800f70 Populate the link information cache before checking dependent properties.
With similar reasoning to the parent commit, as downstreams, we can't
determine what $<CONFIG> generator expressions would be appropriate.
Upstream would have populated the INTERFACE_INCLUDE_DIRECTORIES with
config-specific generator expressions, possibly appropriate for
their DEBUG_CONFIGURATIONS. In theory, if we would add include
directories for a DEBUG intent, we would have to match the upstream
configurations for that.
Rather than attempting to discover the appropriate configurations
at this time, simplify the feature instead. The use of IMPORTED targets
with these commands could still be added in the future if targets
would export their DEBUG_CONFIGURATIONS somehow.
This reverts commit 9cfe4f1b76.
It turns out that correctly adding the content to
the IMPORTED_LINK_INTERFACE_LIBARIES_<CONFIG> of an upstream target
from the buildsystem of a downstream project is not simple.
If upstream had added the INTERFACE content, the config-specific
properties would be determined by the DEBUG_CONFIGURATIONS of
upstream.
As downstream, we don't have any information about what
the DEBUG_CONFIGURATIONS of upstream were, so we can't determine
which configuration-specific properties to populate. The best we can do
is add it to all of them or add it to the ones downstream considers to
be DEBUG_CONFIGURATIONS, neither of which is a good solution.
So, removing the porcelain API for that is the best approach. A human
can still determine which properties to populate and use
the set_property API to populate the desired properies.
Another solution to this would be for upstream targets to publish
what they consider DEBUG_CONFIGURATIONS, but that can be added in
a future release.
During configure-time, GetIncludeDirectories may be called too, for example
if using the export() command. As the content can be different, it should
be output each time then.
Otherwise, we get a separate IncludeDirectoriesEntry for each include,
and that causes unnecessary and confusing splitting in the output when
debugging the INCLUDE_DIRECTORIES property.
The cache here needs to be cleared if GetLinkInformation is called
at configure-time, such as during an export().
The next commit does exactly that, and without this patch,
the LinkLanguage test would fail.
It is not necessary and the current state is unintentional. Before
this patch,
target_link_libraries(foo bar)
causes the LINK_LIBRARIES property of foo to contain
$<TARGET_NAME:bar>
instead of just
bar
This new expression allows checking how a policy was set when a target
was created. That information is only recorded for a subset of policies,
so a whitelist is used.
1d74ba2 Test evaluation target via export for generator expressions
522bdac Export the INTERFACE_PIC property.
4ee872c Make the BUILD_INTERFACE of export()ed targets work.
1d47cd9 Add a test for the interfaces in targets exported from the build tree.
6c828f9 Move the exported check for file existence.
cfd4f0a Move the exported check for dependencies of targets
d8fe1fc Only generate one check per missing target.
f623d37 Don't write a comment in the export file without the code.
b279f2b Strip consecutive semicolons when preprocessing genex strings.
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.
Stephen Kelly
Kitware Robot
Brad King
Alex Neundorf
Patrick Gansterer
Rolf Eike Beer
Yury G. Kudryashov
Robert Maynard