740bee97bd Xcode: Add settings to control a scheme's launch configuration
39456c70e1 Xcode: Add settings to control a scheme's GPU Validation values
4034272ed8 gitignore: Tell Git to ignore the .cache/ directory
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7581
44a2f3f332 Add new flow-control commands for variables and policies scopes management
604993248f cmMakefile::VariablePushPop: helper class to manage variable scopes
3d94ee0e03 cmMakefile::RaiseScope: Add support for cmValue argument
553da0685f cmFunctionBlocker: Add handling of close block without parameters.
02c067dee5 cm::enum_set: fix various bugs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: John Ericson <git@johnericson.me>
Merge-request: !7575
a20d7a9707 BSD: Set *BSD variables when targeting a *BSD system
2ae42d0aa3 kFreeBSD: Do not unset LINUX variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7573
When `cmake -E env` is given the `--modify` flag, try to parse the
following argument as an `ENVIRONMENT_MODIFICATION` operation and apply
it to the environment.
This generalizes `--unset=`:
1. When implementing `ENVIRONMENT_MODIFICATION` features for other CMake
commands, the `MYVAR=OP:VALUE` strings do not need to be translated
to OP-specific flags.
2. This provides a natural and consistent extension point to introduce
new operations without introducing very many flags.
3. Users need to learn only one syntax to access the same functionality.
There is one difference between the behavior here as compared to CTest's
interpretation of the `ENVIRONMENT_MODIFICATION` test property.
The `MYVAR=reset:` command when run in `cmake -E env` will reset `MYVAR`
to whatever its value was when `cmake -E env` launched, rather than try
to checkpoint after plain `MYVAR=VALUE` options. This makes `MYVAR=VALUE`
and `--modify MYVAR=set:VALUE` semantically equivalent.
nvtx3 is a header-only replacement for the previous shared library
implementations.
I implemented it as a separate target since while the header names match and
ideally it should be API compatible, forcing its include directory into the old
target would lengthen the include search path and could cause confusion or
possible build differences for projects using multiple build systems. This
keeps it explicit as a developer opt-in.
Implements: #21377Resolves: #23835
The `PREFIX/(Foo|foo|FOO).*/(cmake|CMake)/(Foo|foo|FOO).*/` search
path is the similar to the one already exists
`PREFIX/(Foo|foo|FOO).*/(lib/ARCH|lib*|share)/cmake/(Foo|foo|FOO).*/`.
4f95e6b284 ci: test BMI exporting and installation with GCC in CI
c49d5f137b RunCMake/CXXModules: add a "deep-chain" test
297e0f4dce cmCxxModuleMapper: support MSVC module map format
b3c2880cb2 cmCxxModuleMapper: track transitive modules for MSVC
a43713d615 CTestCustom: ignore `cm::optional` uninitialized memory false positive
b90de0b492 RunCMake/CXXModules: support MSVC extensions
a84c186a7d cmScanDepFormat: support the MSVC 17.3 toolchain temporarily
d7f5064ff7 cmScanDepFormat: support P1689R5
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7481
The foundation of the Doxygen Find Module's detection methodology
is the command `find_program`, which has inhibited the module from
properly handling user version restrictions when provided.
Because `find_program` historically has always returned after the first
match and does not consider version constraints, users of this module
are inadvertently at the mercy of the command's search procedure.
Essentially, `find_package(Doxygen ...)` will always provide the first
Doxygen build found through said procedure, even if it conflicts with
the user's version requirements, and even if another build exists on
the system that would satisfy those requirements (i.e. shadowing).
Utilizes the new `VALIDATOR` option of `find_program` to ensure all
otherwise detectable builds of Doxygen on a given system are evaluated
and that only a build in compliance with `Doxygen_FIND_VERSION`
et. al., when defined, will be matched against.
Also enables handling of version ranges specified within `find_package`
via the **FindPackageHandleStandardArgs** module.
Finally, ensures that only the major, minor, and patch components of
Doxygen's `--version` output are captured for comparison in cases where
it contains additional information, such as a git commit hash.
Fixes: #23692
The new sub-command writes a string representation of the
current log level to the output variable given to the
sub-command.
Given that the log-level might be set either via the --log-level
command line option or via the CMAKE_MESSAGE_LOG_LEVEL
cache / regular variables, the priority for each of the log level
sources is as follows, with the first one being the highest:
1) --log-level
2) CMAKE_MESSAGE_LOG_LEVEL regular variable
3) CMAKE_MESSAGE_LOG_LEVEL cache variable
4) default log level (STATUS)
Fixes: #23572
Extend the change from commit e01990999a (Ninja: On Windows, select the
compiler occurring first in PATH, 2020-04-17, v3.18.0-rc1~291^2) to
apply to the MSYS/MinGW Makefiles generators too. Drop the implied
`gcc` and `g++` default compilers. This allows MinGW/Clang environments
to work out of the box.
Inspired-by: Mehdi Chinoune <mehdi.chinoune@hotmail.com>
Fixes: #23542
