| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Extend the change made by commit fe4b25ec2f (Teach target_* commands to
set INTERFACE properties of IMPORTED targets, 2017-09-18,
v3.11.0-rc1~433^2~2) to work with imported targets of type `UNKNOWN`.
Fixes: #19434
|
|
|
|
| |
This improves readability.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following was disallowed:
add_library(iface INTERFACE)
target_link_libraries(iface PUBLIC)
just due to the mention of the `PUBLIC` keyword. Instead, only error if
there are actually `PUBLIC` dependencies specified (and analogously for
other restrictions).
Update tests to expect this new behavior.
|
|
|
|
| |
The outside of the loop does the same return expression.
|
|
|
|
|
|
| |
Some target types don't allow setting certain properties even if there
is no value being set there. Guard against this by avoiding property
setting when there is nothing to add.
|
|
|
|
|
|
|
|
|
|
|
| |
Now, several `INTERFACE_*` properties can be set on `IMPORTED` targets,
not only via `set_property` and `set_target_properties` but also via
`target_compile_definitions`, `target_compile_features`,
`target_compile_options`, `target_include_directories`, `target_sources`
and `target_link_libraries`.
Fixes: #15689
Issue: #17197
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modern editors provide plenty of ways to visually separate functions.
Drop the explicit comments that previously served this purpose.
Use the following command to automate the change:
$ git ls-files -z -- \
"*.c" "*.cc" "*.cpp" "*.cxx" "*.h" "*.hh" "*.hpp" "*.hxx" |
egrep -z -v "^Source/cmCommandArgumentLexer\." |
egrep -z -v "^Source/cmCommandArgumentParser(\.y|\.cxx|Tokens\.h)" |
egrep -z -v "^Source/cmDependsJavaLexer\." |
egrep -z -v "^Source/cmDependsJavaParser(\.y|\.cxx|Tokens\.h)" |
egrep -z -v "^Source/cmExprLexer\." |
egrep -z -v "^Source/cmExprParser(\.y|\.cxx|Tokens\.h)" |
egrep -z -v "^Source/cmFortranLexer\." |
egrep -z -v "^Source/cmFortranParser(\.y|\.cxx|Tokens\.h)" |
egrep -z -v "^Source/cmListFileLexer\." |
egrep -z -v "^Source/cm_sha2" |
egrep -z -v "^Source/(kwsys|CursesDialog/form)/" |
egrep -z -v "^Utilities/(KW|cm).*/" |
xargs -0 sed -i '/^\(\/\/---*\|\/\*---*\*\/\)$/ {d;}'
This avoids modifying third-party sources and generated sources.
|
|
|
|
|
|
|
| |
Mostly automated:
values=( "EXECUTABLE" "STATIC_LIBRARY" "SHARED_LIBRARY" "MODULE_LIBRARY" "OBJECT_LIBRARY" "UTILITY" "GLOBAL_TARGET" "INTERFACE_LIBRARY" "UNKNOWN_LIBRARY" "TargetType")
for i in "${values[@]}"; do git grep -l cmTarget::$i | xargs sed -i "s|cmTarget::$i|cmState::$i|g"; done
|
|
|
|
|
| |
This is needed for the target_compile_features command, which
may fail at configure time if an invalid feature is specified.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
All callers passed 0 in, so just remove the branch.
|
|
|
|
| |
Property names are always generated by CMake and should never be NULL.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
Code such as
target_include_directories(foo PRIVATE ${items})
should not work or break based on whether items is defined or not.
|
|
|
|
|
|
| |
This is similar to the include_directories(SYSTEM) signature
in that it allows telling the compiler to ignore warnings from
such headers.
|
|
|
|
|
| |
This can be used to handle INTERFACE SYSTEM include directories
in particular.
|
|
|
|
|
| |
Setting include directories or compile definitions on a target created
with add_custom_target does not make sense.
|
|
|
|
|
| |
This way we can add handling of relative/absolute paths and of
-D in compile definitions.
|
| |
|
|\
| |
| |
| |
| |
| | |
b98d14d Disallow porcelain to populate includes and defines of IMPORTED targets.
48a4cf2 Revert "Allow target_link_libraries with IMPORTED targets."
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With similar reasoning to the parent commit, as downstreams, we can't
determine what $<CONFIG> generator expressions would be appropriate.
Upstream would have populated the INTERFACE_INCLUDE_DIRECTORIES with
config-specific generator expressions, possibly appropriate for
their DEBUG_CONFIGURATIONS. In theory, if we would add include
directories for a DEBUG intent, we would have to match the upstream
configurations for that.
Rather than attempting to discover the appropriate configurations
at this time, simplify the feature instead. The use of IMPORTED targets
with these commands could still be added in the future if targets
would export their DEBUG_CONFIGURATIONS somehow.
|
|/
|
|
|
| |
Handle the case that a generator expression is used before treating
a non-target as an error.
|
|
This is a convenience API to populate the corresponding properties.
|