mirror/CMake
1
0
Fork 0
mirror of https://github.com/Kitware/CMake.git synced 2026-04-22 06:09:14 -05:00
Code Issues Packages Projects Releases Wiki Activity

project: Only check non-cache vars when setting project vars

Browse Source 
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
This commit is contained in:
Craig Scott
2024-10-06 16:04:26 +11:00
committed by Brad King
parent 5e4526d6dd
commit fa07ddfebf
4 changed files with 48 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Help/command/project.rst
+20 -4
View File
@@ -44,11 +44,27 @@ Projects should not rely on ``<PROJECT-NAME>_SOURCE_DIR`` or
``<PROJECT-NAME>_BINARY_DIR`` holding a particular value outside of the scope
of the call to ``project()`` or one of its child scopes.
.. versionchanged:: 3.30.3
``<PROJECT-NAME>_SOURCE_DIR``, ``<PROJECT-NAME>_BINARY_DIR``, and
``<PROJECT-NAME>_IS_TOP_LEVEL`` are always set as non-cache variables by
``project(<PROJECT-NAME> ...)``.
.. versionchanged:: 3.30.4
If the variables ``<PROJECT-NAME>_SOURCE_DIR``,
``<PROJECT-NAME>_BINARY_DIR``, or ``<PROJECT-NAME>_IS_TOP_LEVEL`` are
already set as non-cache variables when ``project(<PROJECT-NAME> ...)``
is called, the ``project()`` command will overwrite the previous values.
The variables ``<PROJECT-NAME>_SOURCE_DIR``, ``<PROJECT-NAME>_BINARY_DIR``,
and ``<PROJECT-NAME>_IS_TOP_LEVEL`` are only set as non-cache variables if
they are already set as cache or non-cache variables when
``project(<PROJECT-NAME> ...)`` is called.
Note that this logic is flawed, as it can result in different behavior
between the first and subsequent runs because cache variables won't exist
on the first run, but they will on subsequent runs.
.. versionchanged:: 3.30.5
The variables ``<PROJECT-NAME>_SOURCE_DIR``, ``<PROJECT-NAME>_BINARY_DIR``,
and ``<PROJECT-NAME>_IS_TOP_LEVEL`` are only set as non-cache variables if
they are already set as non-cache variables when
``project(<PROJECT-NAME> ...)`` is called.
Unlike the flawed behavior of 3.30.4, non-cache variables will not be set
if only cache variables of the same name are set.
Options
^^^^^^^
Help/release/3.30.rst
+19 -3
View File
@@ -277,7 +277,23 @@ Changes made since CMake 3.30.0 include the following.
* The :command:`project(<PROJECT-NAME>)` command now sets
:variable:`<PROJECT-NAME>_SOURCE_DIR`, :variable:`<PROJECT-NAME>_BINARY_DIR`,
and :variable:`<PROJECT-NAME>_IS_TOP_LEVEL` as normal variables only if they
are already set as normal variables when :command:`project` is invoked.
Cache entries by the same names are always set as before.
are already set as cache or non-cache variables when :command:`project` is
invoked. Cache entries by the same names are always set as before.
This refines 3.30.3's behavior change to restore behavior of nested
directories that call :command:`project` with the same project name.
directories that call :command:`project` with the same project name,
but the implementation in this release is flawed (this release note has
been retoractively updated). It can result in different behavior between
the first and subsequent runs. Do not use CMake 3.30.4 if your project
contains nested calls to :command:`project` with the same project name
and you use these variables.
.. 3.30.5 (unreleased)
* The :command:`project(<PROJECT-NAME>)` command now sets
:variable:`<PROJECT-NAME>_SOURCE_DIR`, :variable:`<PROJECT-NAME>_BINARY_DIR`,
and :variable:`<PROJECT-NAME>_IS_TOP_LEVEL` as non-cache variables only if
they are already set as non-cache variables when :command:`project` is
invoked. Cache entries by the same names are always set as before.
This refines 3.30.3's behavior change to restore behavior of nested
directories that call :command:`project` with the same project name,
and it addresses the bug in the implementation introduced in 3.30.4.