07bc3b07ec gitlab-ci: test C++ modules using GCC
1b2270aa4e ci: add a Docker image to test out C++ modules with GCC
8c5a53096a Tests/RunCMake/CXXModules: add module-using examples
4151547e2f cmGlobalNinjaGenerator: use `cmModuleMapper` implementation
b43bdaff3c cmCxxModuleMapper: implement support for GCC's module map format
02d0f0e752 cmCxxModuleMapper: add source to handle module mapper contents
a046a45aad cmGlobalNinjaGenerator: add a TODO for header units
386465bf83 cmTarget: add support for C++ module fileset types
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7369
This includes a number of examples that should work for various levels
of support in a compiler.
There are a number of tests which are gated on various features in the
compilers. To enable the tests, set `CMake_TEST_MODULE_COMPILATION` to a
comma-separated (to avoid `;`-escaping problems) to the list of features
which are supported:
- `named`: Named modules are supported.
- `shared`: Shared libraries with module usage at the API boundary are
supported.
- `partitions`: Named module partitions are supported.
- `internal_partitions`: Named module internal partitions are
supported.
Additionally, a `CMake_TEST_MODULE_COMPILATION_RULES` file must be
passed which contains the rules for how to build modules using the
provided compiler. It will be included in the tests to provide these
rules. To verify that the file provided works as intended, it must set
`CMake_TEST_CXXModules_UUID` to a specific version to indicate that it
is an expected file.
C++ modules have two variants which are of importance to CMake:
- `CXX_MODULES`: interface modules (those using `export module M;`,
`export module M:part;`, or `module M:internal_part;`)
- `CXX_MODULE_HEADER_UNITS`: importable header units
Creating C++ modules or partitions are *not* supported in any other
source listing. This is because the source files must be installed (so
their scope matters), but not part of usage requirements (what it means
for a module source to be injected into a consumer is not clear at this
moment). Due to the way `FILE_SET` works with scopes, they are a perfect
fit as long as `INTERFACE` is not allowed (which it is not).
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.17 and below to encourage projects to port
away from setting policies to OLD.
One of three Fortran/C interface test functions is missing a prototype,
which causes warnings and sometimes errors depending on compiler versions
and flags.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
On some Xcode versions, `xcodebuild` may warn:
... xcodebuild[...] [MT] DVTSDK: Warning: SDK path collision for path ...
Teach RunCMake to drop such incidental lines before matching against
expected output.
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 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.
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.
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)
In certain specific scenarios, it is possible to end up with JAVA_COMPILE
being unset, but Java_JAVAC_EXECUTABLE being set. This typically occurs
when running different versions of CMake in the same build directory
without deleting the CMakeCache.txt each time. This can result in an
obscure error about the wrong number of arguments to the
get_filename_component() command, but the real cause is the
JAVA_COMPILE variable being unset.
The JAVA_COMPILE variable is only set by the FindJava module, and it
is a legacy variable that has been superceded by Java_JAVAC_EXECUTABLE.
The latter is what the if() expression tests, so use that same variable in
the body of the if() block for consistency and to avoid the above problem.
Our 1.125s delay does not seem to be long enough to be reliable with
the Borland "make" tool. Use a longer delay for Borland and Watcom.
Follow the pattern from commit 67040500ea (Tests: Fix
RunCMake.BuildDepends filesystem delay for Borland Makefiles,
2015-09-25, v3.4.0-rc1~38^2).
Add a new property, INTERFACE_HEADER_SETS_TO_VERIFY, which contains
a list of header sets that should be verified by
VERIFY_INTERFACE_HEADER_SETS.
Fixes: #23522
d9b4264cb8 FindVulkan: Add component for `MoltenVK`
10a6bb16bb FindVulkan: Mark test target with `cxx_std_11` to avoid AppleClang warnings
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7286
Brad King