When cmExportFileGenerator::SetImportLinkInterface exports the old
LINK_INTERFACE_LIBRARIES property values it skips doing so for
non-linkable targets because target->GetLinkInterface returns NULL for
such targets.
Since cmExportFileGenerator::PopulateInterfaceLinkLibrariesProperty
looks at the INTERFACE_LINK_LIBRARIES property directly instead of using
the computed link interface, teach it to skip exporting the property if
target->IsLinkable returns false.
Extend the RunCMake.CMP0022 test with a case covering this. Simply
export an executable target that links to a library that is not
exported.
The CMP0022 NEW behavior is that the INTERFACE_LINK_LIBRARIES property
exactly defines the link interface. The plain target_link_libraries
signature says linking is transitive by default, so it should populate
the property.
Teach the target_link_libraries plain signature to populate the
INTERFACE_LINK_LIBRARIES regardless of the CMP0022 setting. Refactor
the cmTarget::ComputeLinkInterface checks that warn when the policy is
not set to compare the new property to either the explicitly set old
link interface properties or the link implementation fallback for all
linkable target types, not just static libraries.
This fixes a regression in 2.8.12.0 that caused target_link_libraries to
not implement transitive linking in the plain signature once the policy
CMP0022 is set to NEW.
The new feature of install(TARGETS ... INCLUDES DESTINATION) introduced
in commit 650e61f8 (Add a convenient way to add the includes install
dir to the INTERFACE., 2013-01-05) introduced this crash. If the
new feature is used with a target which has no
INTERFACE_INCLUDE_DIRECTORIES, a segfault occurred.
First, it prevents a NULL dereference and second it reiterates that
targets without languages are not supported by CMake.
Add a RunCMake.ExportWithoutLanguage test exporting a library without a
languages.
Export the INCLUDES DESTINATION without appending to the
INTERFACE_INCLUDE_DIRECTORIES of the target itself. That way, a target
can be exported multiple times with different INCLUDES DESTINATION
without unintended cross-pollution of export sets.
This patch adds a comment above the block which protects
the exported targets file against multiple inclusion, to make
the file easier to understand for readers.
Alex
This property is generated only for targets which have recorded
policy CMP0022 as NEW, and a compatibility mode is added to
additionally export the old interfaces in that case too.
If the old interfaces are not exported, the generated export files
require CMake 2.8.12. Because the unit tests use a version which
is not yet called 2.8.12, temporarily require a lower version.
dc1d025 OS X: Add test for rpaths on Mac.
8576b3f OS X: Add support for @rpath in export files.
00d71bd Xcode: Add rpath support in Xcode generator.
94e7fef OS X: Add RPATH support for Mac.
This allows for example, the buildsystem to use names like 'boost_any'
instead of the overly generic 'any', and still be able to generate
IMPORTED targets called 'boost::any'.
Check that source and binary directories are not part of the
INTERFACE_INCLUDE_DIRECTORIES for installed IMPORTED targets.
This is limited to directories which do not contain generator
expressions to evaluate. Such paths can only be checked at time
of use of the imported target, which will be done in a follow up
patch.
236133e Handle targets in the LINK_LIBRARIES of try_compile.
1c0597c Add a new Export generator for IMPORTED targets.
f2ab17d Keep track of all targets seen while evaluating a genex.
Instead of generating a whole bunch of repeated if-statements
now a foreach()-loop is generated in the targets-file.
Also now a comment is inserted in the generated file if no
targets from other export sets are used, so if somebody looks
at the file he can see whether the information about missing
imported targets has been generated or not.
Alex
This reverts commit 2c3654c3de.
The removal of some tests added in commit 77cecb77 (Add includes and compile
definitions with target_link_libraries., 2012-11-05) are also squashed
into this commit.
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.
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.
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.
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.
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.
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.
This way the name of the searched package can be accessed in find-modules,
config-files and more importantly in generated target export files.
This is now used when a target export file detects that a required
target does not exist.
Alex
Before, cmExportFileGenerator::ComplainAboutMissingTarget() was a virtual
function which had to be implemented in the subclasses. It is not
anymore. Instead, there is now a virtual function
HandleMissingTargets(), which is implemented in the two subclasses.
This makes e.g. dealing correctly with APPEND mode easier.
Alex
Brad King
Stephen Kelly
Ben Boeckel
Alex Neundorf
Clinton Stimpson