| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a case like
target_link_libraries(targetInOtherDir PUBLIC "$<1:a;b>")
then all entries in the list need to be looked up in the caller's
scope. Previously our `::@(directory-id)` suffix would apply only
to the last entry. Instead surround the entire entry by a pair
`::@(directory-id);...;::@` so that the `::@` syntax can encode
a directory lookup scope change evaluated as the list is processed.
Fixes: #20204
|
|
|
|
|
|
|
|
|
|
| |
In commit a1ad0a699b (target_link_libraries: Allow use with targets in
other directories, 2018-09-07, v3.13.0-rc1~94^2) we added use of `<...>`
to encode a directory id, but the closing `>` can incorrectly terminate
a surrounding generator expression early. Encode the directory id using
`(...)` instead.
Fixes: #20202
|
|
|
|
| |
Issue: #20204
|
|
|
|
|
| |
Run the `clang-format.bash` script to update our C and C++ code to a new
include order `.clang-format`. Use `clang-format` version 6.0.
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit a1ad0a699b (target_link_libraries: Allow use with targets in
other directories, 2018-09-07, v3.13.0-rc1~94^2) we accidentally broke
the logic that adds `$<LINK_ONLY:...>` to private dependencies of static
libraries in their `INTERFACE_LINK_LIBRARIES` in the case that the
dependency is added from outside the directory creating the library.
The check for a valid target name should apply to the original name
specified by the caller and not the encoded cross-directory reference.
Fixes: #19197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the command did not allow naming targets on the LHS that
were not created in the calling directory. Lift this restriction to
enable more flexible use by projects.
Targets named on the RHS will need to be looked up during generation in
the scope of the call site rather than the scope of the LHS target.
Introduce an internal syntax in `[INTERFACE_]LINK_LIBRARIES` properties
to specify target names that need to be looked up in a directory other
than that containing the target on which the property is set. Add
minimal documentation of the syntax to help users that encounter it.
Unfortunately CMake previously did allow such calls in the case that
only `INTERFACE` libraries are specified, but those libraries would be
looked up in the target's directory rather than the caller's. Add
policy `CMP0079` to enable the new behavior with new lookup scope in a
compatible way.
Fixes: #17943
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
|
|
|
|
|
| |
Fixes the following tests on Solaris builds: wrapping, qtwrapping and
CMakeCommands.target_link_libraries
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sort include directives within each block (separated by a blank line) in
lexicographic order (except to prioritize `sys/types.h` first). First
run `clang-format` with the config file:
---
SortIncludes: false
...
Commit the result temporarily. Then run `clang-format` again with:
---
SortIncludes: true
IncludeCategories:
- Regex: 'sys/types.h'
Priority: -1
...
Commit the result temporarily. Start a new branch and cherry-pick the
second commit. Manually resolve conflicts to preserve indentation of
re-ordered includes. This cleans up the include ordering without
changing any other style.
Use the following command to run `clang-format`:
$ git ls-files -z -- \
'*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' |
egrep -z -v '(Lexer|Parser|ParserHelper)\.' |
egrep -z -v '^Source/cm_sha2' |
egrep -z -v '^Source/(kwsys|CursesDialog/form)/' |
egrep -z -v '^Utilities/(KW|cm).*/' |
egrep -z -v '^Tests/Module/GenerateExportHeader' |
egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' |
xargs -0 clang-format -i
This selects source files that do not come from a third-party.
Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
|
|
|
|
|
| |
Fix the CMakeCommands.target_link_libraries test to use "-V" instead of
"-v" on Solaris because the latter does not exist.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
|\ \
| |/
| |
| |
| | |
239b0c6 Don't add invalid content to static lib INTERFACE_LINK_LIBRARIES.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
Rename the variable added by commit 9ce1b9ef (Add
CMAKE_BUILD_INTERFACE_INCLUDES build-variable, 2012-11-25) to
CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE to be more consistent with the
existing CMAKE_INCLUDE_CURRENT_DIR variable.
Suggested-by: Alex Neundorf <neundorf@kde.org>
|
|\
| |
| |
| |
| |
| | |
1bdd167 Restore support for target names with '+' (#13986)
254687d Only process transitive interface properties for valid target names.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Extend the range of valid target names with the + sign. This character
can commonly be used for target names, such as those containing 'c++'.
Add a test but skip it for Borland and Watcom tools which do not support
the character.
Suggested-By: Benjamin Kloster
|
|/ |
|
|
|
|
|
|
| |
Update the unit test introduced in commit 57175d55 (Only use early
evaluation termination for transitive properties., 2013-02-07) to
not use the expression, but still test the appropriate code.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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 9cfe4f1b769597bd9ba179eba46572a9df27f64c.
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| | |
9cfe4f1 Allow target_link_libraries with IMPORTED targets.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | |
| | |
| | |
| | | |
7653862 Add LINK_LIBRARIES property for direct target link dependencies
40cf3fb Make linking APIs aware of 'head' target
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| | |
b6346f2 Tests: Fix warning about unused variable
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Resolve this warning:
".../Tests/CMakeCommands/target_link_libraries/depB.cpp", line 8: warning:
variable "a" was declared but never referenced
DepA a;
^
|
|/ |
|
| |
|
|
Makes it possible to specify the link dependencies and link
interfaces in one command without repetition.
|