| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
6ade07ef89 Tests: Teach RunCMake to ignore Xcode extension point warnings
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6992
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On some Xcode versions, `xcodebuild` may warn:
... xcodebuild[...] Requested but did not find extension point with
identifier ...
Teach RunCMake to drop such incidental lines before matching against
expected output.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
f73457ca2e cmake: Ignore any empty "" command line arguments
67f97f5478 Tests: Add RunCMake helper to run cmake with raw execute_process args
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6980
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't treat empty quote arguments("") as the current working
directory but instead ignore them.
Fixes #23217
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
a7ef59c9c4 Tests: Fix CudaOnly.SeparateCompilationPTX test project name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6991
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix the test added by commit 61b9764b03 (CUDA: Allow both
CUDA_SEPARABLE_COMPILATION and CUDA_PTX_COMPILATION, 2021-09-17,
v3.23.0-rc1~516^2) to have a `project()` name matching what
is passed to CTest's `--build-project` option. Otherwise, on
VS builds, MSBuild warns:
MSBUILD : error MSB1009: Project file does not exist.
Other CUDA tests use a matching project name already.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
c1e812ad4f target_link_libraries: Improve tolerance of unquoted generator expressions
5571a31648 target_link_libraries: Handle keyword arguments in dedicated code path
42590df9f9 target_link_libraries: Remove likely-broken ancient compatibility check
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6989
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Prior to commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces from
INTERFACE_LINK_LIBRARIES, 2021-12-15, v3.23.0-rc1~228^2), the value of
`INTERFACE_LINK_LIBRARIES` was a single string. If an unquoted
generator expression passed to `target_link_libraries` contained `;` and
became multiple arguments, they would all accumulate as a single
`;`-separated list in the value of `INTERFACE_LINK_LIBRARIES`. Since
that commit, each argument to `target_link_libraries` is placed in
`INTERFACE_LINK_LIBRARIES` as a separate entry, as has long been the
case for `LINK_LIBRARIES`. That behavior change broke projects that were
accidentally relying on accumulation in `INTERFACE_LINK_LIBRARIES` to
produce complete generator expressions containing `;`.
Teach `target_link_libraries` to accumulate consecutive non-keyword
arguments into a single entry before placing them in `LINK_LIBRARIES` or
`INTERFACE_LINK_LIBRARIES`. For example, treat `a b c` as if they were
written as `"a;b;c"`. This restores the previously accidental support
for unquoted generator expressions in `INTERFACE_LINK_LIBRARIES`, and
also enables it for `LINK_LIBRARIES`.
For now, do not drop the `target_link_libraries` documentation that
recommends quoting generator expressions. Quoting is still important to
populate `LINK_LIBRARIES` in CMake 3.22 and below, and is also good
practice to keep generator expressions whole.
Fixes: #23203
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
61929f936f GoogleTest: Fix escaping in test names
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6965
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
231872ddb0 file(DOWNLOAD): Add options to download a range
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6986
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
a2cfa2da4f GenEx/LINK_LIBRARY: Add features for framework support on Apple
40178f3c90 cmGlobalGenerator: Add helper to split framework path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6967
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | / /
| | |/ /
| |/| |
| | | |
| | | | |
61929f936f GoogleTest: Fix escaping in test names
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6965
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Due to add_command() being a macro it introduced excessive and
nonobvious escaping in different parts of the script. Because of
one of such places the resulting script would have an erroneous
${TEST_LIST} if the user data (in test parameters) had a semicolon.
To eliminate this non-obvious escaping, add_command() was converted
to function. Updated the escaping accordingly.
Fixes: #23059
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
38de1bef2d find_package: Improve --debug-find-pkg= when using a find module
d634d20397 find_package: Avoid printing debug output header multiple times
df3e29450a find_package: Mention package name in Config mode debug output
636ca7f25c find_package: Fix find module name in --debug-find output
596e185409 find_package: Improve formatting of --debug-find output
2f43527574 Tests: Improve order of RunCMake.find_package cases
a690523fcf cmFindPackageCommand: Drop ComputeIfDebugModeWanted overload
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6973
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Extend the feature added by commit d7b18895bc (cmake: Add filtered
debug-find options, 2021-12-07, v3.23.0-rc1~217^2) to enable debug
output for `find_*` calls within a find module or cmake package
configuration file.
Fixes: #23211
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Otherwise, if there are no paths considered then the output does not
specify the name of the package.
|
| | | |
|
| | |
| | |
| | |
| | | |
Also spell out more complete content in the test's expect output.
|
| | |
| | |
| | |
| | | |
Sort recently added cases among similar-named cases.
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
41adfc6b04 Help: Clarify precedence of AND and OR in 'if' conditions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6970
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
641cb1093b Windows/Clang: Support PDB when cross-compiling
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex <leha-bot@yandex.ru>
Merge-request: !6959
|
| |\ \ \ \
| | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
83d79636bf install(TARGETS): Restore per-export INCLUDES DESTINATION
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6969
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
8e1e97ccca Trace: include `line_end` field in json-v1 format
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6968
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
After !6954 got merged, it has become easier for tools to get
full stack-traces for runtime traces of a CMake program. The trace
information already included in the JSON objects (line number, source
file path) allows tools that display these stack traces to print the
CMake source code associated to them. However, CMake commands may
spawn multiple lines, and the JSON information associated to a trace
only contains the line in which the command started, but not the one
in which it ended. If tools want to print stack traces along the
relevant source code, and they want to print the whole command
associated to the stack frame, they will have to implement their own
CMake language parser to know where the command ends.
In order to simplify the life of those who want to write tooling for
CMake, this commit adds a `line_end` field to the json-v1 trace
format. If a given command spans multiple lines, the `line_end` field
will contain the line of the last line spanned by the command (that of
the closing parenthesis associated to the command).
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `CONFIGURE_HANDLED_BY_BUILD` case occasionally fails on builds with
the `Borland Makefiles` generator due to the `make` tool's 1s file
timestamp resolution. Somehow the 1.125s delay is not enough. Several
other tests use a 3s delay for Borland tools for the same reason.
|
|\ \ \ \ \ \
| | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
41adfc6b04 Help: Clarify precedence of AND and OR in 'if' conditions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6970
|
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The wording update in commit b74819e4fe (Help: Format 'if' command
documentation, 2013-12-18, v3.0.0-rc1~227^2~1) incorrectly implied that
`AND` has higher precedence than `OR`. Although this is common in many
languages, it has never been true in CMake's implementation. Revise
the wording to clarify the precedence.
Add a test case demonstrating the order.
Fixes: #23207
|
|\ \ \ \ \
| | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
641cb1093b Windows/Clang: Support PDB when cross-compiling
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex <leha-bot@yandex.ru>
Merge-request: !6959
|
| |/ / / |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
073dd1bd81 GoogleTest: Change format for typed tests
f28f738bd2 GoogleTest: Fix type param tests for suites with many cases
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6958
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
cbb87e0a2c ExternalProject: Add support for USES_TERMINAL_PATCH keyword
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6940
|
|\ \ \ \ \ \
| |_|_|_|/ /
|/| | | | /
| | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | | |
83d79636bf install(TARGETS): Restore per-export INCLUDES DESTINATION
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6969
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In commit 55e4753bbb (Refactor cmTargetExport removing
InterfaceIncludeDirecories, 2021-07-20, v3.22.0-rc1~337^2~1) the storage
of `INCLUDES DESTINATION` was moved into each target. However, a target
may be installed in multiple exports, and their `INCLUDES DESTINATION`
should not be mixed.
Convert the IncludeDirectoriesEntries vector to a map and modify access
function to store the directories lists with respect to cmExportTarget
object. This fixes error when the same target is exported more than once
via different exports and each for consequent export its include
directories list grows. Add a test for this case.
Fixes: #23183
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
2a6b0415d7 $<LINK_LIBRARY>: Add LINK_LIBRARY_OVERRIDE target property
42965799b4 Genex: Add $<LINK_LIBRARY:...>
78dd7d5292 cmRulePlaceholderExpander: add base class for placeholder expansion reuse
4b55828a9f cmExpandListWithBacktrace: add handling of empty elements.
28d7432468 cmComputeLinkInformation: use cmComputeLinkDepends::LinkEntry
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6769
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
To enable the management of incompatible $<LINK_LIBRARY> declarations,
add LINK_LIBRARY_OVERRIDE and LINK_LIBRARY_OVERRIDE_<LIBRARY> target
properties.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This generator expression offers the capability, for the link step, to
decorate libraries with prefix/suffix flags and/or adding any specific flag for each
library.
Fixes: #22812, #18751, #20078, #22703
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
a41d6e4d7a Trace: add global_frame field to json-v1 format
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6954
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Tools using the json-v1 format might want to trace stack frames across
different `CMakeLists.txt` files, in order to, for example, provide
stacktraces that span from the top-level `CMakeLists.txt` in a
project. One would think that `frame` lets you do that, but it
doesn't, because it tells you the depth of the stack within the
current `CMakeLists.txt`, so it gets reset across calls to
`add_subdirectory`.
The solution involves adding a field with a "global frame". This value
gets incremented on calls to `add_subdirectory`, which makes it easier
for tools to reconstruct "global stacktraces".
I considered changing the current "frame" value, but I didn't because
it would be a breaking change. I cannot think of any use-case where
"frame" is more useful to "global-frame", but maybe I'm missing
something.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
b764c7c273 VS: Add property to turn off Visual Studio compile batching
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6957
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | | |
Resolves: #23179
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
7b23fd6c1b Tests: Run CTest.UpdateBZR tests only if explicitly enabled
7cf5355d5e Tests: Add cache entries to control ExternalProject test VCS tools
c8b29dc5b9 Tests: Add cache entries to control existence of CTest.Update* tests
a70864e300 Tests: Make condition for CTest.UpdateCVS match pattern of other tools
1972a75536 Tests: Drop CTestUpdate.BZR test check for xmloutput plugin
f2566f6416 Tests: Drop unnecessary check for FindCVS module
530242576c Tests: Remove always-true condition enabling CTest.Update* tests
4e88a4228e Tests: Remove unused CVS tool discovery
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6956
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
These tests have not been automatically enabled on current
versions of `bzr` in a long time. The recent change to
drop the `xmlplugins` heuristic caused the tests to start
running on some machines, but they do not work everywhere.
Disable the tests again pending further investigation.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Add undocumented `CMake_TEST_ExternalProject_*` cache entries to
explicitly enable or disable these tests. If not set, compute defaults
as before. Also consolidate the VCS default heuristics.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Add undocumented `CMake_TEST_CTestUpdate_*` cache entries to explicitly
enable or disable these tests. If not set, compute defaults as before.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Current `bzr` tools do not have any `bzr xmlplugins` command.
|