Introduce a policy to control the behavior.
The AliasTargets unit test already tests that using a
double-semicolon in the name is not an error. Change the ExportImport
test to use a namespace with a double-semicolon too.
The result is that the depends of the target are created.
So,
add_library(somelib foo.cpp)
add_library(anotherlib EXCLUDE_FROM_ALL foo.cpp)
add_library(extra EXCLUDE_FROM_ALL foo.cpp)
target_link_libraries(anotherlib extra)
add_library(iface INTERFACE)
target_link_libraries(iface INTERFACE anotherlib)
Executing 'make iface' will result in the anotherlib and extra targets
being made.
Adding a regular executable to the INTERFACE of an INTERFACE_LIBRARY
will not result in the executable being built with 'make iface' because
of the logic in cmComputeTargetDepends::AddTargetDepend.
So far, this is implemented only for the Makefile generator. Other
generators will follow if this feature is possible for them.
Make INTERFACE_LIBRARY targets part of the all target by default.
Test this by building the all target and making the expected library
EXCLUDE_FROM_ALL.
Drop all DefineProperty calls for non-chained properties. Drop the
documentation from the chained ones. The documentation for all
properties is now in Help/prop_*/*.rst files.
These checks want to know if named target properties are builtin, which
is now known by checking the Help/prop_tgt directory. (Previously the
check could be confused by a define_property call in the project.)
The final location and name of a build-target is not determined
until generate-time. However, reading the LOCATION property from
a target is currently allowed at configure time. Apart from creating
possibly-erroneous results, this has an impact on the implementation
of cmake itself, and prevents some major cleanups from being made.
Disallow reading LOCATION from build-targets with a policy. Port some
existing uses of it in CMake itself to use the TARGET_FILE generator
expression.
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.
6931999 VS6: Add some delimiting between error message and content.
d1a5f12 cmTarget: Fix typo in comment.
961c0ba Fix comments to match the code.
7cca50c Remove unused include.
We populate and maintain a vector of structs to keep track of
backtraces already, so no need to populate the Properties container
additionally.
For completeness, it is necessary to remove the condition for
populating the vector for only valid library names and generator
expressions. That condition is now determined when evaluating the
generator expressions.
Exclude Ninja and Xcode from the CMP0021 test
They do not behave the same as the makefile generator with
relative paths.
Don't overwrite the header file for in-source builds.
With this, projects can enable MACOSX_RPATH by default, but still have
a way to install libraries with no install name dirs into locations
such as /usr/local/lib by setting INSTALL_NAME_DIR="".
* 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.
It accepted an optional argument to test for equality, but no way
to get the linker language of a particular target.
TARGET_PROPERTY provides this flexibility and STREQUAL provides
the necessary API for equality test.
Extend the CompileDefinitions test to cover accessing the
property of another target.
9cf3547 Add the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property.
1925cff Add a SYSTEM parameter to target_include_directories (#14180)
286f227 Extend the cmTargetPropCommandBase interface property handling.
83498d4 Store system include directories in the cmTarget.
f1fcbe3 Add Target API to determine if an include is a system include.
2679a34 Remove unused variable.
Unlike other target properties, this does not have a corresponding
non-INTERFACE variant.
This allows propagation of system attribute on include directories
from link dependents.
Drop the "vsProjectFile" argument from cmTarget::TraceDependencies. It
appears to be the modern equivalent to a hunk added in commit ba68f771
(...added new custom command support, 2003-06-03):
+ name = libName;
+ name += ".dsp.cmake";
+ srcFilesToProcess.push(name);
but was broken by refactoring at some point. The current behavior tries
to trace dependencies on a source file named the same as a target, which
makes no sense. Furthermore, in code of the form
add_executable(foo foo.c)
add_custom_command(OUTPUT "${somewhere}/foo" ... DEPENDS foo)
the "vsProjectFile" value "foo" matches source "${somewhere}/foo.rule"
generated to hold the custom command and causes the command to be added
to the "foo" target incorrectly.
Simply drop the incorrect source file trace and supporting logic.
d7dd010 Add target property debugging for COMPILE_DEFINITIONS
1841215 Refactor cmTarget::GetCompileDefinitions to use an out-vector, not a string.
afc9243 Add an overload of cmIDEOptions::AddDefines taking a vector of strings.
d95651e Overload cmLocalGenerator::AppendDefines to add a list.
Use constructs similar to those for COMPILE_OPTIONS. This is a little
different because there is a command to remove_definitions(), so
we can't populate the equivalent target property until generate-time
in cmGlobalGenerator.
Use preprocessor loops and add a unit test for the appropriate
policies. All policies whose value is recorded at target creation
time should be part of this list.
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.
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.
This property replaces the properties which
match (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?, and is enabled
for IMPORTED targets, and for non-IMPORTED targets only with a policy.
For static libraries, the INTERFACE_LINK_LIBRARIES property is
also used as the source of transitive usage requirements content.
Static libraries still require users to link to all entries in
their LINK_LIBRARIES, but usage requirements such as INCLUDE_DIRECTORIES
COMPILE_DEFINITIONS and COMPILE_OPTIONS can be restricted to only
certain interface libraries.
Because the INTERFACE_LINK_LIBRARIES property is populated unconditionally,
we need to compare the evaluated result of it with the link implementation
to determine whether to issue the policy warning for static libraries. For
shared libraries, the policy warning is issued if the contents of
the INTERFACE_LINK_LIBRARIES property differs from the contents of the
relevant config-specific old LINK_INTERFACE_LIBRARIES property.
Entries from the cmMakefile are processed and maintained similarly
to other include directories. The include_directories(SYSTEM)
signature affects all following targets, and all prior targets
in the same makefile.
This has been requested, along with a patch, by Shaun Williams
in http://public.kitware.com/Bug/view.php?id=13788 .
It adds a global property AUTOMOC_TARGETS_FOLDER, which can
be used to group the automoc targets together in a folder e.g.
in Visual Studio.
Alex
This command is similar to add_definitions, in that it affects
the compile options of all targets which follow it. The implementation
is similar to the implementation of the include_directories command,
in that it is based on populating a COMPILE_OPTIONS directory property
and using that to initialize the same property on targets.
Unlike the include_directories command however, the add_compile_options
command does not affect previously defined targets. That is, in
the following code, foo will not be compiled with -Wall, but bar
will be:
add_library(foo ...)
add_compile_options(-Wall)
add_library(bar ...)
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.
RPATH support is activated on targets that have the MACOSX_RPATH
property turned on.
For install time, it is also useful to set INSTALL_RPATH to help
find dependent libraries with an @rpath in their install name.
Also adding detection of rpath conflicts when using frameworks.
This fixes bug #13797.
The kinds of changes applied in 373faae5 for frameworks are now
applied to CFBundle. The prefix and suffix for CFBundles are
now handled in cmTarget::GetFullNameInternal.
This corresponds to the g++ and clang++
option -fvisibility-inlines-hidden on linux. On Windows with MinGW,
this corresponds to -fno-keep-inline-dllexport. That option is
not supported by clang currently.
This is initialized by CMAKE_<LANG>_VISIBILITY_PRESET. The target
property is used as the operand to the -fvisibility= compile option
with GNU compilers and clang.
They can't be used when evaluating link libraries, but they can be
used for include directories and compile definitions. Later they can
be used for compile options.
Make handling of directory separators consistent between
non-bundle and bundle code.
Remove xcode specific flag from cmTarget when getting install_name.
Add (more) consistent convenience functions in cmTarget to get
directories inside of bundles and frameworks to add files to.
This refactor also fixes bug #12263 where frameworks
had the wrong install name when SKIP_BUILD_RPATH.
Also make install_name for frameworks consistent between Makefile
and Xcode generator.
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'.
Commit 42ebb188 (Memoize includes and defines from interface libraries.,
2013-02-22) introduced caching of the includes. Fix the memoization to
be configuration-specific so that we do not accumulate entries across
multiple evaluations in a multi-config generator.
Generator expressions, including configuration-specific expressions may
be used as link libraries of targets. The old-style keywords of
target_link_libraries are handled in terms of new generator expressions.
However, the generator expressions expect target names to be valid
against a regular expression, whereas target_link_libraries does not
require validation. In generator expression constructed without any
action from the user we need to ensure that only valid expressions are
generated. Ensure that strings which are not valid target names are not
used in generator expressions which validate the argument.
Code like
target_link_libraries(B debug A)
generates usage requirement references such as "$<$<CONFIG:DEBUG>:A>".
When cmTarget::GetIncludeDirectories uses such references it generates
expressions like:
$<TARGET_PROPERTY:$<$<CONFIG:DEBUG>:A>,INTERFACE_INCLUDE_DIRECTORIES>
When the conditions are false such references evaluate as an empty
string and the expression fails with an error such as:
$<TARGET_PROPERTY:tgt,prop> expression requires a non-empty target name.
Fix this by teaching cmTarget::GetIncludeDirectories to wrap the above
expression inside a conditional:
$<$<BOOL:$<$<CONFIG:DEBUG>:A>>:...>
so that $<TARGET_PROPERTY:...> will not be evaluated with an empty
target.
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.
Brad King
Stephen Kelly
Clinton Stimpson
Alex Neundorf
Christian Maaser
John Farrier
Rolf Eike Beer
Andreas Mohr