Redefine the `CMAKE_CI_PACKAGE` pipeline schedule variable to
indicate whether it is for a development version (`dev`) or a
release version (`v[0-9]...`). Use this to automatically turn
package upload jobs on or off without having to edit the jobs
in `.gitlab-ci.yml` for release branches.
In commit c705279bae (Help: Add `.. versionadded` directives to commands
documentation, 2020-11-08, v3.20.0-rc1~508^2) we accidentally added
``versionadded`` markup suggesting that the first argument to
`try_compile` was fixed as `RESULT_VAR` prior to CMake 3.14. This was
probably due to misinterpreting the change from commit 7975edeac5 (Help:
User-provided variable names for try_* commands, 2019-02-24,
v3.14.0-rc3~16^2~3).
The result variable has never been fixed. Drop the incorrect markup.
3.22.1 had no release notes because there were no changes to documented
features or interfaces. Now that we have a 3.22.2 section, add one
for the previous patch release to avoid confusion.
Commit 4a0485be (cmStandardLevelResolver: Avoid unnecessary flags, fix unset
level logic, 2021-04-29) unintentionally changed the behavior by modifying the
code to match a pre-existing comment. The resulting behavior change however
matches the intentions of CMP0128, so we simply need to guard it.
Fixes#23122.
294581a443 Help: Be more explicit about the behavior of if(<string>)
3a9695557d Help: Explicitly state that if(ENV{some_var}) is always false
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6768
This helps to maximize the amount of information visible in the GitLab
web interface.
Also document their meaning in the developer documentation and in the CI
configuration file directly.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/8496
This was intended to be part of the initial MR (!6177), but accidentally went
missing when debugging nightly failures on less common systems. Noticed during
!6711 review as the comment about this behaviour didn't match the code.
Documentation for CMP0128 is updated to remove a false case and note the two
cases related to this.
Fixes#22224.
CMake 3.18 added the first support for any compiler for 17 and 20,
but those were recognized as valid values in earlier CMake versions
even though there was no compiler that supported them. Make this
distinction clear to avoid creating the impression that these standards
could be usefully used before CMake 3.18.
While 98 is recognized as a valid value, it also just gets treated as 03
internally. Document this behavior as well.
Fixes: #22711
Add fields to the VS generator to select a target framework.
Migrate the existing default for VS 12 .NET CF for Windows CE.
Report the values in `CMAKE_VS_*` variables and use them for
the CSharp compiler id project too.
Issue: #22849
This generator expression does not report the locations of `.dll`
files on imported targets with the `UNKNWON` type, since their
`IMPORTED_LOCATION` refers to the import library and not the DLL.
Fixes: #22845
Explain that this represents the compiler's default and mustn't be modified
by the user. Clarify when it's used as the default.
Additionally:
* Add a reference to it in cmake-compile-features in text explaining the
feature.
* Add explanations for the default initialization by
`CMAKE_<LANG>_EXTENSIONS_DEFAULT` to all `<LANG>_EXTENSIONS` pages and
references to CMP0128.
* Slightly reduce the wordiness of the default initialization explanations by
removing an unnecessary "it is".
Fixes#22828.
Support for `CMAKE_GENERATOR_INSTANCE` was added in CMake 3.11, but the
possibility was mentioned in a comment in older versions, so the wrong
versionadded value was used in commit c43e845d09 (Help: Add `..
versionadded` directives to generator docs, 2020-11-11,
v3.20.0-rc1~476^2).
This makes `versionadded` and `versionchanged` directives show up in
`cmake --help-*` output instead of disappearing (and potentially making
empty sections).
Fixes: #22808
