Commit 5abaf65154 (Check*: Restore toleration of `;-W...` in
CMAKE_REQUIRED_FLAGS, 2026-06-24, v4.4.0-rc3~2^2) introduced logic to
prevent `-W*` arguments in `CMAKE_REQUIRED_FLAGS` from being passed as
CMake arguments. It was never the intent of `CMAKE_REQUIRED_FLAGS` to
support such usage; however, since older versions of CMake would
silently accept such arguments, some users were unintentionally passing
compiler warnings as CMake arguments. Although this usage is incorrect,
it was silently tolerated until CMake 4.4, which began treating unknown
`-W*` as an error.
Because it turns out that modules besides `CheckSource{Compiles,Runs}`
are affected, we are going to need the logic added by that commit in
many more places. As a first step toward accommodating that need, move
the logic to a new internal helper. While we're at it, try to generally
consolidate the common logic for handling the various variables that the
`Check*` family of modules uses for injecting arguments into the
ultimate `try_compile` calls.
The `CMAKE_REQUIRED_FLAGS` variable, used by the various entry points to
`cmake_check_source_{compiles,runs}`, specifies that flags shall not be
separated by semicolons. This is because the way in which it is passed
to the child `cmake` process means that, when considered as a list (with
semicolon separated items), only the first item is actually used as
compile flags, with any additional items actually seen as arguments to
the child `cmake` process. While this usage is unsupported, if invoked
accidentally, flags starting with `-W` were silently ignored by CMake.
However, CMake 4.4 newly complains about unrecognized warning
categories, which means that uses which were silently broken now result
in a hard error.
In the longer term, it would be helpful to introduce a policy to repair
improper use of semicolons in `CMAKE_REQUIRED_FLAGS` in order to do what
the user probably meant. However, for various reasons, we do not want to
introduce a policy to CMake 4.4 at this time, and anyway, the policy
won't help users that haven't enabled it. Therefore, alter the 'check
source' functions to detect arguments being passed to `cmake` rather
than the compiler, and remove any such that start with `-W`. This
removes any arguments that newly cause errors starting with CMake 4.4,
while not otherwise altering behavior in case any users were abusing
this implementation quirk.
Strictly speaking, this means that users can no longer abuse this quirk
to alter CMake's diagnostics. However, the only case in which this
should be observable is if the user is already abusing the quirk to
inject their own CMake logic into the CMake-provided test projects.
Since this was never supported, anyone doing that can keep the pieces.
Issue: #27901Fixes: #27893
`try_compile` and `try_run` now automatically log checks using them to
`CMakeConfigureLog.yaml`.
Add `LOG_DESCRIPTION` arguments to some `try_compile` calls to
replace the description previously written to the old logs.
Issue: #23200
Xcode uses its own heuristics to determine whether or not to accept
top-level code in a source file while Ninja uses the swift driver
heuristics.
With the Swift driver, if the module contains a single file, that file
will be parsed as a top-level code context. With Xcode, the single file
will only be parsed as top-level code if the name of that file is
'main.swift'.
To ensure more consistent behavior between the two generators, if we're
building Swift and the try-compile target type is executable or
undefined, we name the file `main.swift` to ensure that both will handle
the single file as top-level code.
Modify some modules that ship with CMake to use the new SOURCES_FROM_*
arguments to try_compile / try_run as added by commits cb14ae2b87
(try_compile: Add SOURCE_FROM_{ARG,VAR}, 2022-09-21) and 611d801790
(try_compile: Add SOURCE_FROM_FILE, 2022-09-22). This covers users which
previously either used an existing file (but sometimes needed to rename
it), or which wrote out their source in entirety. It does NOT cover
users that actually need configure_file functionality, as those will be
more involved to update and will thus be tackled in part 2.
Modify most of the modules that ship with CMake to use the new
try_compile / try_run signatures added by commit aa9220d3a0
(try_compile: Add keyword-dispatched signature, 2022-09-02). This
improves debugging by each invocation using its own directory so that
the results of multiple invocations can be retained.
This does not cover any invocations which provide an entire project, as
that flavor of try_compile has not yet been updated.
Fix the language checks added by commit 90dead024c (CheckCompilerFlag:
unified way to check compiler flags per language, 2020-09-25,
v3.19.0-rc1~88^2), commit 10ae907de0 (CheckSoureCompiles: Add a unified
way to check if a source compiles, 2020-09-14, v3.19.0-rc1~118^2~1), and
commit 357e2ef429 (CheckSoureRuns: Add a unified way to check if a
source runs, 2020-09-14, v3.19.0-rc1~118^2) to work when variables of
the language names are set.
Fixes: #21500
The conversion of Check<Lang>CompilerFlag, SourceCompiles, and
SourceRuns over to the new functions has the possibility of breaking
projects that had functions with those existing names.
To reduce the possibility of collisions we now have all the
legacy code call functions that start with `cmake_`, and users
will need to explicitly include the new modules to get the
non-prefixed versions
Fixes: #21359
