Commit a1c4905f (Use the link information as a source of compile
definitions and includes., 2013-02-12) introduced the use of link
information as the source of target properties via the TARGET_PROPERTY
generator expression. This generator expression has a strict
interpretation of a valid target name and emits a fatal error for
invalid names.
Ensure that only targets with names valid for use with TARGET_PROPERTY
or targets which are determined by generator expressions are processed
by it. This means that at worst, invalid target names do not participate
in the transitive evaluation of properties, but the validation
generator expression can be extended where needed to resolve that.
As of commit 1da75022 (Don't include generator expressions in
old-style link handling., 2012-12-23), such entries are not
included in the LinkLibraries member. Generator expressions in
LinkLibraries are not processed anyway, so port to the new way
of getting link information.
This is similar in spirit to commit e48d8420 (Cache context-independent
includes on evaluation., 2013-02-03), but it is needed since commit
a1c4905f (Use the link information as a source of compile definitions
and includes., 2013-02-12), which changed how includes and defines
are determined. As they are now determined through the link interface,
we need to cache the result of evaluating them through that.
In the case of the includes, the result was already being cached
and then immediately disposed. Store the result as a member variable
instead to make use of the caching.
After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a
generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of
its link interface dependencies.
That means that code such as this will result in the 'user' target
using /bar/include and /foo/include:
add_library(foo ...)
target_include_directories(foo INTERFACE /foo/include)
add_library(bar ...)
target_include_directories(bar INTERFACE /bar/include)
target_link_libraries(bar LINK_PUBLIC foo)
add_executable(user ...)
target_include_directories(user PRIVATE
$<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>)
Also process the interface include directories from direct link
dependencies for in-build targets.
The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The
include directories related code is currently more complex because
we also need to store a backtrace at configure-time for the purpose
of debugging includes. The compile definitions related code will use
the same pattern in the future.
This is not a change in behavior, as existing code has the same effect,
but that existing code will be removed in follow-up commits.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
Stephen Kelly
Brad King