In commit 0f37000304 (try_{compile,run}: add LINKER_LANGUAGE option,
2023-10-12, v3.29.0-rc1~567^2) a release note was accidentally added in
the wrong directory and so was not included in the 3.29 release notes.
The change in commit 86ad7cc886 (project: Only define non-cache vars if
already defined, 2024-09-15, v3.30.4~2^2) was meant to only check for
non-cache variables when deciding whether to set non-cache project
variables for the current call. However, it erroneously checked for any
variable, including cache variables. This gives the intended result on
the first run, but on subsequent runs a cache variable will exist that
did not on the first run, leading to different behavior between the two
runs. Fix the logic to only check for a pre-existing non-cache
variable, as was originally intended.
Fixes: #26355
Add a 3.30.3 release note for commit c1ece78d11 (project: non cache
<project> prefix variables are also created, 2024-08-27, v3.30.3~2^2).
Prepare a 3.30.4 release note for commit 86ad7cc886 (project: Only
define non-cache vars if already defined, 2024-09-15).
In c1ece78d11 (project: non cache <project> prefix variables are
also created, 2024-08-27), we started explicitly setting the non-cache
variable for <projectName>_SOURCE_DIR, <projectName>_BINARY_DIR,
and <projectName>_IS_TOP_LEVEL in addition to setting them as
cache variables. This changed the behavior when a project name
was used more than once, and the second project call happens in
the same scope or a child scope of the first. Previously, the first
project call would set cache variables, and the second project call
would not overwrite those cache variables. With the change in
c1ece78d11, after the second project call the non-cache variables
would mask the cache variables and the project code would see
a different value to what it did before.
Setting the non-cache variable was added to handle the case where
a call to FetchContent_MakeAvailable() would set some non-cache
variables, and it just so happened those matched the same cache
variables that the project() command would set in the project being
fetched. The fetched project would then see a different set of
project-specific variables compared to when it was built standalone.
This commit here narrows the change from c1ece78d11 such that
the non-cache variable is only set by project() if there was already
a non-cache variable set. This still fixes the motivating problem
c1ece78d11 was intended to solve, but it avoids changing the variable
values seen by a project that re-uses the same project name in related scopes.
Issue: #26243, #25714Fixes: #26281
Define the `Python_DEFINITIONS` variable for the support of free
threaded Python developments on Windows.
This is a complement to commit 9a0dee7257 (FindPython: Add support for
free threaded python, 2024-05-30).
These were missed in commit e0355c4ea9 (FindBoost: Add policy to remove
this module, 2024-05-03, v3.30.0-rc1~150^2) and commit 0aba13a2f3
(ctest: Add explicit options for TLS server verification, 2024-03-01,
v3.30.0-rc1~408^2~3).
dbdca56555 Help: CPack/NuGet avoid deprecated variables in the usage example
d06a39dd59 Help: CPack/NuGet add `:Supported:` to some variables
a6a8212ba2 Help: CPack/NuGet add description to the added variables
039bf0f3f3 Help: CPack/NuGet fix `versionadded` position
391e339926 Help: CPack/NuGet add deprecation notes according to the current spec
4e11de312b Help: Reorder variables as they mentioned in the official spec
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9605
In commit 60661f6770 (CPack/WiX: Make InstallScope configurable,
2023-11-07, v3.29.0-rc1~413^2) the `CPACK_WIX_INSTALL_SCOPE` default was
set to `perMachine`. While installers created with `perMachine` have
better behavior on their own than installers created without any
`InstallScope`, they do not cleanly convert existing installations on
updates.
Fixes: #26029
In commit 60661f6770 (CPack/WiX: Make InstallScope configurable,
2023-11-07, v3.29.0-rc1~413^2) the `CPACK_WIX_INSTALL_SCOPE` default was
set to `perMachine`. While installers created with `perMachine` have
better behavior on their own than installers created without any
`InstallScope`, they do not cleanly convert existing installations on
updates.
Fixes: #26029
Add section headers similar to the 3.29 release notes and move each
individual bullet into an appropriate section. Revise a few bullets.
Drop the `CXX_MODULE_STD` release note since it is an experimental
feature.
