6c09451ed3 ci: Enable FindOpenMP tests in Intel nightly CI jobs on Windows
d427bfae61 FindOpenMP: Restore support for Intel compilers on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9284
Executables that don't export a public API should not emit a
swiftmodule, but the swift modulename is observable from within the
program, so we should still set the module name on executable builds.
Fixes: #25710
Fix the condition added by commit 3019af64c2 (FindOpenMP: Add support
for GNU-like Clang targeting MSVC ABI, 2024-02-08, v3.29.0-rc1~8^2~1)
to be more specific.
Fixes: #25711
5b8e9e068f Restore support for TARGET_OBJECTS in link interfaces with unity builds
1313c78a9c Tests: Update RunCMake.TargetObjects cmake_minimum_required version
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9279
5b8e9e068f Restore support for TARGET_OBJECTS in link interfaces with unity builds
1313c78a9c Tests: Update RunCMake.TargetObjects cmake_minimum_required version
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9279
Amends 01e33df83f (Help: Modernize BUILD_SHARED_LIBS
documentation, 2024-02-21) to highlight that BUILD_SHARED_LIBS
needs to be set early enough to prevent different behavior between
the first and subsequent runs.
This was broken by commit df08c37a42 (cmGlobalGenerator: Add unity/pch
sources after computing compile features, 2024-02-02, v3.28.3~1^2~1^2),
and 3.28.2's commit 76b5383123 (cmGlobalGenerator: add unity sources
after computing target compile features, 2024-01-01, v3.28.2~17^2~1).
The problem is very similar to that fixed by commit 4e8f24e977 (PCH:
Clear link interface cache when adding PCH object to it, 2022-01-24,
v3.23.0-rc1~44^2~9). Generalize that fix.
Fixes: #25696
When cross-compiling, `clang-scan-deps` needs help to find the correct
location of core headers such as `stddef.h`. Always determine this path
and pass it when available.
Fixes: #25590
This allows for transitive modules to work because
`$<COMPILE_ONLY>`-wrapped dependencies do not end up in the
`linked-target-dirs` collator property. Test suite exported property
tests updated to account for the change.
d256581bb0 VS: Fix '-T version=14.40' under VS 17.10 preview 1
3a7fbd04c8 VS: Verify toolset version= field format more strictly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9271
8b6fc81fc3 cmTarget: copy link libraries from the right properties
d4a517f82a Tests/CXXModules: add a test with transitive targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9265
VS 17.10 preview 1 comes with toolset `v143` version `14.40`. This is
the first time that the first three digits of the version do not match
the toolset name. Add a special case to map version `14.40` back to
toolset `v143`.
In commit 5f13168419 (VS: Add option to select the version of the
toolset used by VS 2017, 2018-05-19, v3.12.0-rc1~38^2) we added logic to
verify that the toolset version, such as `14.35`, matches the toolset
name, such as `v143`. Clarify the logic to not construct a temporary
nonsensical toolset name like `v1435`. Also verify the format of the
toolset version more strictly, e.g., to reject `14.350` earlier.
Previously the latter example was only rejected by the `.props` file not
existing.
