LLVMFlang 18.0 adds MSVC runtime library selection flags and associated
Fortran runtime library variants. Resolve the corresponding FIXME left
by commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2).
Issue: #24840
As of llvm-project `main` branch commit `86accd4e03` (2023-12-04),
LLVMFlang 18.0.0, when used to drive linking an executable, emits a MSVC
linker flag to use all object files from the `Fortran_main` library.
These object files are meant for use when linking the program entry
point, and so are not implicit link dependencies of Fortran libraries.
The internal helper variable '_GOOGLETEST_DISCOVER_TESTS_SCRIPT' can have gone
out-of-scope when 'gtest_discover_tests()' is called, depending on where the
GoogleTest module is actually included. This leads to a silent failure of
dynamic test discovery, since the custom post-build commands actually does
nothing (it basically invokes 'cmake -P ""'). Ctest will then fail to run the
tests, considering them to be 'not built'.
Fix this by determining the path to the GoogleTest module based on
'${CMAKE_ROOT}' instead, which is always available.
A new test case was added to test suite 'RunCMake/GoogleTest' to ensure that
'gtest_discover_tests()' works correctly when invoked in a different variable
scope.
Fixes: #25477
Previously CMake may generate incomplete transitive requirements in
CMakeFiles/<target>.dir/CXXModules.json and therefore in module mapper
for compiler, when source files were listed in CMakeList.txt in a
certain order.
This commit fixes the problem by correctly tracking unfinished
transitive requirements computation of module units.
There have been a simple circular test case whose circular dependency
was reported by build system. Now with this correct implementation it's
reported by CMake generating module mappers.
Add two test cases for transitive requirements computation, one with
adding source files in hardcoded order, and the other in randomized
order.
Fixes: #25465
40dc13b242 cmNinjaTargetGenerator: PCH files do not need dyndep
f61c64cd1c cmLocalGenerator: prevent scanning of PCH source files
ea8c37b759 Tests/CXXModules: add a test which scans a PCH-using source
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9032
This test previously did not *require* that the internal partition be
specified as a transitive usage because nothing from it was exposed.
Plumb through usages such that the internal partitions are required.
In commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2) we incorrectly recorded `-g` as
supporting the `ProgramDatabase` format, but it is actually `Embedded`,
matching Clang.
In order to support easy integration with C and C++ projects that use
the `.pdb` debug formats, pretend LLVMFlang supports them and just don't
actually emit any debug information.
Issue: #24840
80fe56c481 ctest: Add support for running under a make job server on POSIX systems
5396f4a9a3 cmUVJobServerClient: Add libuv-based job server integration client
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9021
The operator added by commit 17690558c3 (cmUVHandlePtr: Add explicit
conversion to bool, 2023-10-26) works in direct expressions like
`if(foo)` but not compound expressions like `if(foo && ...)`.
Drop the `explicit` mark when compiling with Oracle Studio so we
can at least compile valid code.
f6d2efa752 Tests: Add case to cover execute_process support for no extension on Windows
da9df7425a libuv: win/spawn: run executables with no file extension
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !9017
Since commit 337bc5662c (if(): add operators IS_READABLE, IS_WRITABLE
and IS_EXECUTABLE., 2023-10-21) we create some non-readable directories.
CMake 3.28 and below do not know how to delete them, so some nightly
builds fail ctest_empty_binary_directory. Add read permission to those
directories when we are finished with them.
Tell users what generators *do* support C++ modules. Report the current
generator to make clear it is not one of those supporting modules.
Also clarify the purpose of the existing documentation references.
Fix commit e40d2cb3af (Xcode: Add embed resources support, 2023-07-31,
v3.28.0-rc1~281^2). The implementation should not name the `_PATH`
suffix explicitly. That variant is automatically handled by
`cmGlobalXCodeGenerator::AddEmbeddedObjects`.
53991e62da CPack/RPM: Append .rpm to CPACK_RPM_FILE_NAME if missing
f2a6d423da CPack/DEB: Append .deb to CPACK_DEBIAN_FILE_NAME if missing
907d4db558 Help: Format allowed CPACK_{DEB,RPM}_FILE_NAME values as definition list
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8880
Previously we issued an error when the `.rpm` suffix is missing.
Instead, append the suffix automatically. This matches the behavior of
`CPACK_ARCHIVE_FILE_NAME`, to which the archive format suffix is
automatically appended. With this change, developers can simply do
set(CPACK_RPM_comp_FILE_NAME "${CPACK_ARCHIVE_comp_FILE_NAME}")
Previously we issued an error when the `.deb` or `.ipk` suffix
is missing. Instead, append the suffix `.deb` automatically.
This matches the behavior of `CPACK_ARCHIVE_FILE_NAME`, to
which the archive format suffix is automatically appended.
The previous code used `char **` and `const char **`` types as if they
were the same. But they are distinct types in C, so when passing
these pointers as function arguments, their types have to match.
Future C compilers will treat this as an error, similar to what
C++ compilers do today.
When a target uses objects from another target which provides modules as
sources, the modules provided by the referenced target must also be
treated as if they were provided by the referencing target. Add the
concept of "forwarding" modules so that consumers can use modules
created by these sources as well.
Note that this is only sensible for Fortran where module usages are
implicit as far as CMake's visibility model is concerned. C++ modules
have their own concept of visibility which does not require or support
such `$<TARGET_OBJECTS>` reuse in this way.
Brad King