Code extracted from:
https://gitlab.kitware.com/utils/kwsys.git
at commit a24a6acbbb4a51cf6fefbeb10d1f63ed1b670c69 (master).
Upstream Shortlog
-----------------
Brad King (3):
15896025 SystemTools: Use C++11 in SystemToolsAppendComponents
c6f8e24a SystemTools: Fix CollapseFullPath with relative base path
5ca03af6 SystemTools: Revert "Reduce scope of 'buf' variable in CollapseFullPath"
David Bodnar (5):
116a4919 RegularExpression: Reduce scope of 'len' variable
31f5cdeb RegularExpression: Initialize private members on construction
6e36d909 SystemTools: Reduce scope of 'buf' variable in CollapseFullPath
a93bc28c SystemTools: Drop unnecessary .c_str()
6c3dfd25 CommandLineArguments: initialize internal class members directly
a4657ef670 Merge branch 'backport-clang-gnulike-support' into clang-gnulike-support
161b33f12b Help/guide/tutorial: Revert "require C++14 for the Tutorial"
4f15a6a5c2 Tests: Revert "require C++14 for the Tutorial"
5cfc39127e Merge branch 'backport-clang-gnulike-support' into clang-gnulike-support
d50b31be35 Clang: For MSVC ABI do not use modes older than C++14
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3592
Since commit a13a5c948e (Replace use of CollapseCombinedPath with
CollapseFullPath, 2019-03-19, v3.15.0-rc1~361^2~1), one code path now
calls `CollapseFullPath` with a base path that may be relative.
Backport KWSys commit c6f8e24a3 (SystemTools: Fix CollapseFullPath with
relative base path, 2019-07-24) to handle such base paths.
This case occurs when a build tree is placed in a directory inside a
source tree such that CMake is willing to generate a relative path from
the build tree to the source tree. Add a test covering this case.
Fixes: #19507
Revert the changes from commit a2a90f41e3 (Tests: require C++14 for the
Tutorial, 2019-03-21, v3.15.0-rc1~41^2~2) for the content in its new
home. In commit d50b31be35 (Clang: For MSVC ABI do not use modes older
than C++14, 2019-07-23) we fixed the C++ standard selection for GNU-like
Clang with the MSVC ABI so the test code itself no longer needs to do
it. In particular, changing the tests in this way broke the tutorial's
narrative.
Revert commit a2a90f41e3 (Tests: require C++14 for the Tutorial,
2019-03-21, v3.15.0-rc1~41^2~2). In commit d50b31be35 (Clang: For MSVC
ABI do not use modes older than C++14, 2019-07-23) we fixed the C++
standard selection for GNU-like Clang with the MSVC ABI so the test code
itself no longer needs to do it. In particular, changing the tests in
this way broke the tutorial's narrative.
Since commit d44c0db0b2 (clang: setup correct configuration in gnu mode,
2019-02-20, v3.15.0-rc1~41^2~5) we support the GNU-like Clang that
targets the MSVC ABI. However, Clang cannot compile with the MSVC
standard library unless it runs in a mode aware of C++14 (since MSVC
itself does not even have a lower mode). When `CMAKE_CXX_STANDARD` is
set to 98 or 11, use C++14 anyway.
Since Clang's default mode is aware of C++14, another option is to not
add any flags for 98 or 11. However, if a future Clang version ever
defaults to a higher C++ standard, setting the standard to 98 or 11
should at least not use a mode higher than 14.
Also revert test updates from commit 4819ff9647 (Tests: fix failures
with gnu mode clang on windows, 2019-03-21, v3.15.0-rc1~41^2~3) that
were meant to work around the standard selection problem.
Fixes: #19496
This changes `cmMakefile::AddDefinition` to take a `cm::string_view` as value
argument instead of a `const char *`.
Benefits are:
- `std::string` can be passed to `cmMakefile::AddDefinition` directly without
the `c_str()` plus string length recomputation fallback.
- Lengths of literals passed to `cmMakefile::AddDefinition` can be computed at
compile time.
In various sources uses of `cmMakefile::AddDefinition` are adapted to avoid
`std::string::c_str` calls and the `std::string` is passed directly.
Uses of `cmMakefile::AddDefinition`, where a `nullptr` `const char*` might
be passed to `cmMakefile::AddDefinition` are extended with `nullptr` checks.
This simplifies the `cmMakefile::AddDefinition` method with bool value
overload to call the string based `cmMakefile::AddDefinition` method
with either an "ON" or "OFF" string.
Also the method is renamed to `cmMakefile::AddDefinitionBool`
- Removes `cmDefinitions::Set` method overload that takes a `const char*`
value argument.
- Updates calls to `cmDefinitions::Set` to use the `cm::string_view` based
version instead.
- The `cmDefinitions::Def` struct is simplified by removing an unused
constructor and the `std_string` type definition. The std::string value
becomes a member variable instead of being derived from.
- The `cmDefinitions::Unset` method is added that unsets a definition.
It has the same functionality as calling `cmDefinitions::Set` with a
`nullptr` value argument,
- The `cmDefinitions::Set` method gets an overloaded version that takes a
`cm::string_view` as value argument.
- The originl `cmDefinitions::Set` method with `const char*` argument is
refactored to either call the `cm::string_view` based `cmDefinitions::Set`
overload or `cmDefinitions::Unset`, depending on whether the value
`const char*` is a nullptr (`Unset`) or not (`Set`).
When building the output-map-file.json, do not convert the path to a
Ninja path, which will make it relative. If `cmake` is invoked with the
`-B` option the files will be written relative to the directory where
CMake was invoked rather than relative to the build tree. This path
need not be a relative path since it is used internally by CMake to
determine where to write the output map file. This allows the use of
`-B` option in CMake in projects with Swift targets.
For each usage requirement (such as `INTERFACE_COMPILE_DEFINITIONS` or
`INTERFACE_INCLUDE_DIRECTORIES`), the value of the generator expression
`$<TARGET_PROPERTY:target,prop>` includes the values of the same
property from the transitive closure of link libraries of the target.
In cases that a target's transitive closure of dependencies does not
depend on the target being linked (the "head" target), we can memoize
whether or not a usage requirement property exists at all for that
target. When a usage requirement does not exist for a target, we
can skip evaluating it for every consuming target.
Fixes: #18964, #18965
In commit fec441ec17 (Teach CROSSCOMPILING_EMULATOR to support
arguments, 2019-05-30, v3.15.0-rc1~6^2) the new member
`cmCustomCommandGenerator::EmulatorsWithArguments` was not initialized
to the proper size. Fix this and add a test case covering the crash
that could occur with multiple commands where an emulator appears only
in a later command.
Fixes: #19500
Co-Author: Brad King <brad.king@kitware.com>
680a3c63bb target_*: Allow setting INTERFACE properties of UNKNOWN IMPORTED targets
62b5d1e4ad cmTargetPropCommandBase: Order target type condition by order in enum
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3581
dfaa87f1b3 cmState: Support BuiltinCommands as free functions
28f2d12a05 cmCommand: De-virtualize function InvokeInitialPass
de77d355ac cmState: Add scripted commands by value
0101ace131 cmUnexpectedCommand: Replace with lambda expression
015001aaf1 cmState: Hold commands by value
1eebc29563 cmCommand: deprecate functions GetMakefile and SetError
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3574
For each build setting property (such as `COMPILE_DEFINITIONS` or
`INCLUDE_DIRECTORIES`), the value of `$<TARGET_PROPERTY:target,prop>`
includes the values of the corresponding `INTERFACE_*` usage requirement
property from the transitive closure of link libraries of the target.
Previously we computed this by constructing a generator expression
string like `$<TARGET_PROPERTY:lib,INTERFACE_COMPILE_DEFINITIONS>` and
recursively evaluating it with the generator expression engine. Avoid
the string construction and parsing by using the dedicated evaluation
method `cmGeneratorTarget::EvaluateInterfaceProperty`.
Issue: #18964, #18965
In large projects the generation process spends a lot of time evaluating
usage requirements through transitive interface properties on targets.
This can be seen in a contrived example with deep dependencies:
set(prev "")
foreach(i RANGE 1 500)
add_library(a${i} a.c)
target_compile_definitions(a${i} PUBLIC A${i})
target_link_libraries(a${i} PUBLIC ${prev})
set(prev a${i})
endforeach()
For each usage requirement (such as `INTERFACE_COMPILE_DEFINITIONS` or
`INTERFACE_INCLUDE_DIRECTORIES`), the value of the generator expression
`$<TARGET_PROPERTY:target,prop>` includes the values of the same
property from the transitive closure of link libraries of the target.
Previously we computed this by constructing a generator expression
string like `$<TARGET_PROPERTY:lib,INTERFACE_COMPILE_DEFINITIONS>` and
recursively evaluating it with the generator expression engine. Avoid
the string construction and parsing by creating and using a dedicated
evaluation method `cmGeneratorTarget::EvaluateInterfaceProperty` that
looks up the properties directly.
Issue: #18964, #18965
Brad King
KWSys Upstream
Robert Maynard
Ben Boeckel
Sebastian Holtermann
Saleem Abdulrasool
Norbert Lange
Marek Antoniak
Gabor Bencze