339ae33e55 CPack: Change CPACK_PRODUCTBUILD_DOMAINS default to true (CMP0161)
4e7f2397e4 CPack: Clear temporary variable after it is no longer needed
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9197
701029726f ctest_test: add options INCLUDE_FROM_FILE and EXCLUDE_FROM_FILE
dbacc1d5a8 ctest: add command line option to exclude tests listed in a given file
022f20f663 ctest: add command line option to run the tests listed in a given file
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex <leha-bot@yandex.ru>
Merge-request: !9128
Add `--tests-from-file <filename>` to run only the tests listed in the
given file. The test names must match exactly, no regexps or something.
The listed tests can still be filtered with a regexp using -R.
Issue: #25455
When targeting the GNU ABI, we consider `.a` libraries first but also
accept `.lib`. For symmetry, when targeting the MSVC ABI, we now
consider `.lib` first but also accept `.a`.
This adds support for meson-generated static libraries, which are named
with the pattern `lib${foo}.a`:
* https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa
Note that this was previously attempted by
* commit be848a71b0 (MSVC: Teach find_library to consider the 'libfoo.a'
naming convention, 2022-09-19, v3.25.0-rc1~111^2)
but was reverted by
* commit 955d6245c1 (MSVC: Revert "Teach find_library to consider the
'libfoo.a' naming convention", 2022-11-28, v3.25.1~6^2)
due to problems finding GNU ABI libraries in PATH-derived prefixes.
Since then,
* commit 0a81110b84 (find_(library|file|path): Drop PATH-derived search
prefixes, 2023-09-14, v3.28.0-rc1~91^2)
removed the problematic search paths, so we can restore this change.
Fixes: #23975
* Per-config values were added to `AUTO*_EXECUTABLE`.
* Dependency order was refactored for `cmake_autogen` and `cmake_autorcc` to avoid unnecessary rebuilds.
* A new parameter was added for `cmake_autogen` and `cmake_autorcc` to specify the config name of the `auto*_executable` to be used.
* Add `AUTOGEN_BETTER_GRAPH_MULTI_CONFIG` target property to change the behavior of the dependency graph.
* The timestamp target is split into three targets for per-config to avoid redundant `mocs_compilation` builds when `AUTOGEN_BETTER_GRAPH_MULTI_CONFIG` is ON
* Per-config `DEP_FILE_RULE_NAME` values were added to `AutogenInfo.json` for `Multi-Config` usage.
* Some functions were refactored to avoid code duplication.
This commit reimplements fddd0f0443Fixes: #20074
1bb1769235 cmake_language: Add EXIT subcommand
4f160f7906 cmakemain: Return the SCRIPT_MODE exit code if it was set
b62dcbf5d2 cmMakefile: check cmake script mode exit code after command
3d9d504646 cmMakefile: Store the exit code from cmExecutionStatus to cmake instance
9f6c937408 Source/cmake.h: Add ScriptModeExitCode for proper storing exit code
1082b9cb9a cmExecutionStatus: Add ability to set optional custom exit code
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Acked-by: Leonid Pospelov <pospelovlm@yandex.ru>
Acked-by: NoMaY (a user of Renesas Rulz Japanese Forum) <nomay-jp@outlook.com>
Merge-request: !8228
Add tests to cover these cases:
* run as regular CMake module, in NORMAL_MODE (expected to fail);
* run as CMake script in SCRIPT_MODE (expected to exit with given code);
* run as CMake script that `include()`-s another script with EXIT subcommand;
* run as CMake script which EVAL-uates EXIT subcommand via
`cmake_language(EVAL CODE "<cmake code>")`.
Fixes: #23162
Every policy documents whether CMake warns when it is not set.
This behavior does not change with the CMake version, so avoid
possibly confusing mention of the current CMake version.
Every policy's documentation has a paragraph on what version of CMake
introduced it, how to set the policy, and whether CMake warns if the
policy is not set. The wording of this paragraph has diverged across
policies over time. Factor the paragraph out into a standard advice
document included by every policy.
It was added by commit 496ec6036f (Help: Add Sphinx 'versionadded'
directives to each top-level document, 2020-07-06, v3.19.0-rc1~558^2)
because the document happened to be added during the 3.9 release series,
but the variable has existed since the beginning.
In commit 18e02ace5b (install(CODE|SCRIPT): Support $<INSTALL_PREFIX>
genex, 2023-02-24, v3.27.0-rc1~431^2) we documented the feature without
stating what version added it.
This was missed in commit ca5a300d7f (add_test: Honor
CROSSCOMPILING_EMULATOR only when cross-compiling, 2023-11-02) when it
slipped from the 3.28 release.
Since ff6234509e (Help: Clarify behavior of INHERITED properties, 2018-03-21),
the docs for some get_..._property() commands incorrectly describe
the behavior for inherited properties. When a property is not set, even
in a parent scope, the returned result from the get_..._property()
command is the same whether the property is inherited or not.
The docs incorrectly stated that an empty string would be returned
for inherited properties in such cases.
Property-related commands used a mix of <VAR>, <var>, or
<variable> to specify the variable to store the result in. The <VAR>
form is particularly confusing, since being uppercase it looks more
like a keyword. Use <variable> consistently across all the commands
so that the behavior is clear.
Xcode has been reported to not work at all with this when
ExternalProject projects share download files.
Revert commit 872daff159 (ExternalProject: declare byproducts for the
download step, 2023-09-21, v3.28.0-rc1~27^2) pending further
investigation.
Fixes: #25525
