The target_link_libraries command records the PRIVATE dependencies of a
STATIC library in INTERFACE_LINK_LIBRARIES as "$<LINK_ONLY:dep>". This
hides the target name from export namespacing logic inside a generator
expression. When user-written generator expressions reference a target
name they must put it inside a "$<TARGET_NAME:dep>" expression to allow
the export logic to rename the target. In the case that the private
dependency is not already a generator expression, target_link_libraries
must use "$<LINK_ONLY:$<TARGET_NAME:dep>>" to allow the export logic to
rename the target.
Reported-by: Tamás Kenéz <tamas.kenez@gmail.com>
Since commit v3.3.0-rc1~62^2~5 (cmTarget: Store only cmListFileContext
for CMP0023 handling, 2015-05-18) a call to target_link_libraries on a
target that was defined in another (non-ancestor) directory crashes
because no execution context is left active. Fix this by getting the
execution context from the actual cmMakefile where the current
target_link_libraries call takes place. Test this by verifying that
such calls correctly produce an error diagnostic instead of crashing.
Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
Most callers already have a std::string, on which they called c_str() to pass it
into these methods, which internally converted it back to std::string. Pass a
std::string directly to these methods now, avoiding all these conversions.
Those methods that only pass in a const char* will get the conversion to
std::string now only once.
Resolve conflict in Source/cmTarget.cxx by integrating the changes to
the internal copy constructor from both sides. Also resolve a logical
conflict by dropping the special case for INTERFACE_LIBRARY targets.
Since cmTarget::SetMakefile already forces CMP0022 to NEW for such
targets we need no special handling.
Resolve conflict in Source/cmTargetLinkLibrariesCommand.h by dropping
the documentation change. We will make the same change in the new
location of the same documentation in a separate commit.
Resolve conflicts in
Tests/RunCMake/CMP0022/CMP0022-WARN-empty-old-stderr.txt
Tests/RunCMake/CMP0022/RunCMakeTest.cmake
by taking the side from the 'policy-CMP0022-fixes' branch.
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.
In commit c4373b33 (cmTarget: Make GetProperty() const, 2013-10-29)
we accidentally changed the cmTargetLinkLibrariesCommand.cxx logic
in a way that looks like a local experiment leftover that went
unnoticed due to the size of the other changes in the commit.
Revert it.
This has follow-on effects for other methods and classes. Further
work on making the use of const cmTarget pointers common can be
done, particularly with a view to generate-time methods.
Only valid target names or generator expressions may appear in
the target field of a LINK_ONLY expression.
Other content like link flags should still be added to that property
(wrapped in config-specific generator expressions), but not wrapped
in LINK_ONLY. Otherwise undue warnings would be issued for the
policy CMP0022.
The LINK_ONLY expression only has an effect for actual target
names anyway, so there is no logical deficit.
This has not been allowed since they were introduced in
commit 91438222 (target_link_libraries: Add LINK_(PUBLIC|PRIVATE)
options, 2011-10-07), but allowing this form makes it more compatible
with the newer PUBLIC and PRIVATE keywords.
This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.
The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.
An ALIAS target may be created for an INTERFACE library.
At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.
The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.
* The ALIAS name must match a validity regex.
* Executables and libraries may be aliased.
* An ALIAS acts immutable. It can not be used as the lhs
of target_link_libraries or other commands.
* An ALIAS can be used with add_custom_command, add_custom_target,
and add_test in the same way regular targets can.
* The target of an ALIAS can be retrieved with the ALIASED_TARGET
target property.
* An ALIAS does not appear in the generated buildsystem. It
is kept separate from cmMakefile::Targets for that reason.
* A target may have multiple aliases.
* An ALIAS target may not itself have an alias.
* An IMPORTED target may not have an alias.
* An ALIAS may not be exported or imported.
Add a new signature to help populate INTERFACE_LINK_LIBRARIES and
LINK_LIBRARIES cleanly in a single call. Add policy CMP0023 to control
whether the keyword signatures can be mixed with uses of the plain
signatures on the same target.
Always populate the INTERFACE_LINK_LIBRARIES for interface
entries. Don't populate the old interface properties
matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?
if CMP0022 is NEW.
Because the INTERFACE_LINK_LIBRARIES property is now populated by
the target_link_libraries when operating on a static library,
make an equivalent change which populates the property with
the same value when the old link_libraries() command is used. This
silences the policy warning in that case.
Maintain a target's internal list of usage requirement include
directories whenever the LINK_LIBRARIES property is set by either
target_link_libraries or set_property.
This is a partial revert of commit 77cecb77 (Add includes and compile
definitions with target_link_libraries., 2012-11-05).
As the interface includes and defines are now determined by the link
closure, there is no need to populate the corresponding properties
explicitly.
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 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 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.
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.
This library type can compile sources to object files but does not link
or archive them. It will be useful to reference from executable and
normal library targets for direct inclusion of object files in them.
Diagnose and reject the following as errors:
* An OBJECT library may not be referenced in target_link_libraries.
* An OBJECT library may contain only compiling sources and supporting
headers and custom commands. Other source types that are not normally
ignored are not allowed.
* An OBJECT library may not have PRE_BUILD, PRE_LINK, or POST_BUILD
commands.
* An OBJECT library may not be installed, exported, or imported.
Some of these cases may be supported in the future but are not for now.
Teach the VS generator that OBJECT_LIBRARY targets are "linkable" just
like STATIC_LIBRARY targets for the LinkLibraryDependencies behavior.
Remove extra parens in test for not handling LINK_INTERFACE_LIBRARIES.
Remove redundant test for equality with ProcessingPrivateInterface
subsumed by test for inequality with ProcessingPublicInterface.
When set to OLD, target_link_libraries() silently accepts if it is called
with only one argument and this one argument is not a target.
When set to NEW, this is an error. By default it is a warning now.
Alex
As discussed on cmake-devel, if target_link_libraries() is called with
only one argument, and this one argument is not a valid target, just
print a warning but don't fail, since otherwise probably some existing
code somewhere might stop building.
Alex
target_link_libraries() did not complain if there was only one argument,
and this one (first) argument wasn't a valid target name, e.g.
add_executable(hello main.cpp)
target_link_libraries(-static-intel)
Here the target "hello" was forgotten in the tll() call, but cmake didn't
complain. With this commit it does.
Alex
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
Rename the recently added INTERFACE mode of the target_link_libraries()
command to LINK_INTERFACE_LIBRARIES. This makes it much more distinct
from a normal call to the command, and clearly states its connection to
the property of the same name. Also require the option to appear
immediately after the target name to make it a mode rather than an
option.
Create an INTERFACE option to the target_link_libraries command to help
set the LINK_INTERFACE_LIBRARIES and LINK_INTERFACE_LIBRARIES_DEBUG
properties. This will help users specify link interfaces using
variables from Find*.cmake modules that include the 'debug' and
'optimized' keywords.
The "debug", "optimized", and "general" link library type specifier
arguments to the target_link_library commands are sometimes repeated in
user code due to variable expansion and other complications. Instead of
silently accepting the duplicates and trying to link to a bogus library
like "optimized.lib", warn and ignore the earlier specifiers.
Brad King
Stephen Kelly
Nils Gladitz
Ben Boeckel
Rolf Eike Beer
Alex Neundorf
Ken Martin