Files listed in the `VS_SOLUTION_ITEMS` directory property of a project
directory are added as solution items in the 'Solution Items' solution
directory.
If `source_group` is applied to the files listed in `VS_SOLUTION_ITEMS`,
solution groups matching the names of the source groups are created
outside of the default 'Solution Items' group. If not items are placed
into the default group, it is not created.
Solution items added to subprojects are not included in the top-level
project.
Closes: #26409
Add an `INSTALL_JOB_SERVER_AWARE` option to `ExternalProject_Add`.
When using an explicit `INSTALL_COMMAND`, the generated commands
won't use `$(MAKE)` thus failing to connect to the outer make's
job server. Add an option enable explicit job server integration.
This is the install step's equivalent to the build step's
`BUILD_JOB_SERVER_AWARE` option added by commit bc43398e72
(ExternalProject: Enable Make Job Server with Explicit Build Command,
2023-08-09, v3.28.0-rc1~217^2). It is useful when the external
project's installation is driven by its build system. Note that with
Makefile generators, our default install command does use `$(MAKE)` to
connect to the outer make's job server.
Issue: #26398
Add a way to specify, in a portable way, to raise an error for any
warning during the link step. For that purpose, define:
* CMAKE_LINK_WARNING_AS_ERROR variable
* LINK_WARNING_AS_ERROR target property
Fixes: #25343
7b19531291 macOS: Do not pass any SDK/-isysroot to compilers by default
3b8b70fe72 macOS: Simplify logic converting CMAKE_OSX_SYSROOT to a path
c55c113076 macOS: Revert finding tools inside Xcode that are not in the PATH
77fcee9204 macOS: Revert "Resolve compiler in /usr/bin to that reported by Xcode xcrun"
9eb530842c Tests/RunCMake/CMakePresets: Do not forward empty CMAKE_MAKE_PROGRAM
7fb14e707d Tests/RunCMake/XcFramework: Use macosx SDK in all multi-arch macOS cases
70ff1f15fc Tests/CTestTest*: Detect compiler from environment
1faf60cffc Tests/FortranC: Handle empty CMAKE_OSX_SYSROOT
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Acked-by: FX Coudert <fxcoudert@gmail.com>
Merge-request: !9977
On modern macOS, compiler wrappers like `/usr/bin/cc` automatically
choose a SDK to pass via `-isysroot` to an underlying compiler from
Xcode or the CommandLineTools. Other toolchains like Homebrew's `gcc-*`
come with a default SDK too. Therefore, when targeting macOS, we no
longer need to choose any SDK or pass an `-isysroot` flag by default.
Update initialization of `CMAKE_OSX_SYSROOT` to be empty by default when
targeting macOS.
Fixes: #19180
Revert commit 1f085e11e4 (OS X: Resolve compiler in /usr/bin to that
reported by Xcode xcrun, 2015-01-03, v3.2.0-rc1~126^2~1). The compilers
in Xcode cannot be used by build systems that do not add an `-isysroot`
flag.
Issue: #19180
This boolean setting allows parallel building to be disabled for
individual source files built via `add_custom_command`. Using this
option is equivalent to setting policy `CMP0147` to the `OLD` behavior.
Closes: #26413
This behavior was removed when we switched to libuv in CMake 3.11.
After backporting new changes from libuv v2, we can restore the
behavior.
Fixes: #20115
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.
In commit 95323c90a1 (file(MAKE_DIRECTORY): Add optional RESULT keyword
to capture failure., 2024-06-16, v3.31.0-rc1~414^2) the release note was
added in the wrong directory so it was not gathered for the 3.31 release.
Fixes: #26377
Re-introduce the behavior originally introduced in CMake 3.30.3 by
commit c1ece78d11 (project: non cache <project> prefix variables are
also created, 2024-08-27, v3.30.3~2^2), but this time with a policy for
compatibility.
Issue: #25714
Issue: #26243
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
