Extend commit f513781bc5 (WINDOWS_EXPORT_ALL_SYMBOLS: Export vftable
symbol, 2023-02-13, v3.27.0-rc1~495^2) to classify the symbol as data
on ARM64EC.
Fixes: #26604
Fix use of the `signature::` directive by commit ae558b9ad0 (FindMatlab:
Support REGISTRY_VIEW, 2024-02-08, v3.30.0-rc1~528^2). The directive
was created for use inside `Help/command/*.rst` documents. Using it
in module documentation requires explicit anchors.
Account for changes to upstream ninja:
* commit `5d93f2da28` (Add exit code to the failed target, 2024-12-03)
* commit `311bf93416` (Propagate jobs' exit codes to the ninja's exit code,
2024-12-03)
854eba0c53 target_sources: Improve error message for CXX_MODULES on INTERFACE libraries
cd179e7560 Tests/RunCMake/CXXModules: Rename FileSetModules cases to be more specific
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10090
We support non-compiled `SOURCES` on `INTERFACE` libraries, and also
support `CXX_MODULES` on *imported* `INTERFACE` libraries (via synthetic
targets that compile module interface units). However, we do not
support `CXX_MODULES` on non-imported `INTERFACE` libraries because
there is no place to hold module interface unit's object files for their
module initializers. Previously this was not explicitly rejected, and
so was diagnosed only by "CMake Internal Error" messages due to
assumption violations in the implementation.
Fixes: #26524
Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8), the descriptors
for the `OUTPUT_FILE` and `ERROR_FILE` leak to child processes.
With `ExternalProject` + `INSTALL_COMMAND` + `LOG_INSTALL`, the logging
wrapper script leaks the log files' descriptors to the native build
tool. If they happen to match the `make` job server's pipe fds, e.g.,
with GNU `make` <= 4.3, then the build fails with an error like:
gmake[4]: *** read jobs pipe: Bad file descriptor. Stop.
Fixes: #26398
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_86_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.86.0 source tree.
They are the same as 1.85's dependencies, so just update
the version check for warning about newer versions.
Fixes: #26433
Historically, `needs` specifies the jobs which need to complete
successfully and `dependencies` specifies the jobs which provide
artifacts which should be used. Modern GitLab discourages using both as
`needs` now supports an `artifacts` key to say "depend on but do not use
artifacts", so remove `dependencies` and use `needs:artifacts` where
necessary.
See: https://docs.gitlab.com/ee/ci/yaml/#needsartifacts
The `set` command in `cmd` has terrible properties in that there's no
real structure to it. Sensitive sequences in values or variable names
that are escaping sequences can be interpreted at the wrong time or
things like newlines in values are not escaped at all and cause
ambiguities in parsing. Avoid all of that and use PowerShell to use JSON
as a communication mechanism.
The default behavior of bin2c is to create binary arrays that have no
null termination. So to use it as a C array we need to explicitly tell
it to create valid null terminated strings.
This will safely allow us to run PTX tests across all CUDA drivers.
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.
fa07ddfebf project: Only check non-cache vars when setting project vars
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9883
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).
86ad7cc886 project: Only define non-cache vars if already defined
4c152752da Help: State valid scopes for using proj_SOURCE_DIR and proj_BINARY_DIR
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9820
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
9ceca05e6b FindMatlab: Search mex and mx libraries for MCR
67e3c6b6eb FindMatlab: Cache whether MATLAB root contains MCR or MATLAB
b426ce1d04 FindMatlab: Add support for MCR distributions without mex.h
cd4782bac3 FindMatlab: Only consider versioned MCR subdirectory if it exists
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9831
