Forward `CMAKE_<LANG>_FLAGS` and `CMAKE_<LANG>_FLAGS_DEBUG` from the
calling project into the test project. The set of flags may affect the
availability of IPO support. Since this may change the result of the
check for existing projects, add a policy for compatibility.
This was discovered after commit 5fcadc481e (MSVC: Default to -ZI
instead of /Zi for x86 and x64, 2022-05-24) introduced policy CMP0138 to
switch our default for MSVC's debug info flag. The `-ZI` flag is
incompatible with the `-GL` flag used for IPO, so CMP0138 was reverted
pending future work on an alternative solution. Re-use the CMP0138
policy number for this change to CheckIPOSupported instead.
Fixes: #23607
Revert commit 5fcadc481e (MSVC: Default to -ZI instead of /Zi for x86
and x64, 2022-05-24). The `-ZI` flag is incompatible with the `-GL`
flag used for IPO, and so is not an unconditionally better default.
Revert the change pending future design of a first-class setting for
MSVC debug info format that can be automatically reconciled with IPO
settings.
That commit introduced policy CMP0138, but we already have later policy
numbers used too. Leave placeholder text to avoid policy renumbering.
Issue: #23607, #10189
The guide previously only focused on the find_package() command,
with a bias towards libraries. FetchContent was not mentioned at all.
Reorganise and update the existing content. Add new sections to cover
providing dependencies with FetchContent and dependency providers.
Improve discoverability of the guide by mentioning it at the beginning
of the find_package(), FetchContent and dependency provider docs.
The ExternalProject module has long used the generator-specific
placeholder in the `${CMAKE_CFG_INTDIR}` variable to express per-config
stamp file paths in multi-config generators. Now that most generators
support generator expressions in custom command outputs, we can use
the `$<CONFIG>` genex instead.
In particular, this fixes cross-config `BUILD_BYPRODUCTS` with the Ninja
Multi-Config generator.
Fixes: #23595
d14349c907 ci: Enable ISPC tests on Linux, Windows, and macOS nightly builds
49996faaac ci: remove ISPC from the Fedora CI image
3e791592ad gitlab-ci: init macOS and Windows jobs with per-CMAKE_CONFIGURATION scripts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7336
Revert commit 5ece12b7e4 (gitlab-ci: add ISPC to the Fedora CI image,
2020-08-18, v3.19.0-rc1~244^2). Later we will download ISPC in specific
jobs.
Update a `RunCMake.NinjaMultiConfig` test expectation to account for
a change to the Qt deployed on Fedora 36.
Apply the approach from commit 747940157f (gitlab-ci: init environment
with per-CMAKE_CONFIGURATION shell scripts, 2021-03-12,
v3.21.0-rc1~480^2~4) to macOS and Windows too.
Add three tests in Tests/RunCMake/PrintHelpers, meant to verify
basic functionality of the module. Tests are:
* Variables: Test the results of a cmake_print_variables()
call on two variables set within the test script.
* Properties: Test cmake_print_properties() calls on a pair
of SOURCES and a pair of TARGETS, printing some basic properties.
* PropertiesSources: Specifically verify the results of a
cmake_print_properties() call for the SOURCES property of a
TARGET. Prior to the fix introduced alongside these tests, it
was a known bug that such a request caused a FATAL_ERROR.
It's been a long-standing bug in CMakePrintHelpers that the
cmake_print_properties() function cannot print the SOURCES
property of a requested TARGET, confusing it with a request
to print properties of SOURCES.
We work around this by parsing the arguments in two stages,
so that a SOURCES that comes after the PROPERTIES keyword
is handled differently from a SOURCES that comes before it.
This adds the restriction that the "mode" keyword (TARGETS
SOURCES DIRECTORIES etc...) and its arguments **must** precede
the PROPERTIES keyword and its arguments. In other words:
1. Both of these are now valid and will be interpreted correctly,
whereas previously only the first was, and the second caused
a FATAL_ERROR:
cmake_print_properties(SOURCES foo.c PROPERTIES LANGUAGE)
cmake_print_properties(TARGETS foo PROPERTIES SOURCES)
2. This, OTOH, which used to be valid, no longer is, and will
trigger a FATAL_ERROR:
cmake_print_properties(PROPERTIES LANGUAGE SOURCES foo.c)
Fixes: #14883
We previously defined `_POSIX_C_SOURCE` and friends while building
binary packages in order to minimize the version of glibc needed at
runtime. The definitions were added by commit facc240a45
(Utilities/Release: Add docker specs to build and test Linux binaries,
2019-08-23, v3.16.0-rc1~184^2~2), but came from older packaging scripts
that were removed by commit 689fdbfc61 (Utilities/Release: Drop linux64
script in favor of docker build, 2019-08-27, v3.16.0-rc1~184^2). Those
older scripts were meant for use in a hand-maintained environment. Now
that we use base images of old CentOS versions to establish the build
environment, our builds are already limited to older glibc versions
(glibc 2.12 from centos6 on x86_64, and 2.17 from centos7 on aarch64).
Our old system API definitions no longer affect the glibc version
required by the binaries. Drop them to avoid potential conflicts with
system API definitions added by changes like commit f034b0f663 (CMake
compilation: do not use compiler extensions, 2020-03-14, v3.18.0-rc1~494^2)
and commit c7c3e39e4f (Utilities: Activate POSIX APIs even without
compiler extensions, 2022-06-02).
c7c3e39e4f Utilities: Activate POSIX APIs even without compiler extensions
3ba324b6b6 libarchive: Remove a system preprocessor macro that conflicts with a local var
4a283fcc31 librhash: Explicitly enable large file support on 32-bit targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7320
With CMP0128 OLD compiler extensions are enabled by default regardless of the
compiler's default.
Fix the test to always check for the extension flag as it was intended to.
Fixes: 4a0485be7f (cmStandardLevelResolver: Avoid
unnecessary flags, fix unset level logic, 2021-04-29)
Brad King