In the same spirit of commit ce1cadd35a, (Tests/ConfigSources: fix for
non main stream CMAKE_BUILD_TYPE, 2021-04-01).
Allow distributions' check to pass seemlessly.
Issue: #22470
cb777dd81e Ninja Multi-Config: Restore TARGET_OBJECTS support in cross-configs
83c8272280 cmGeneratorExpressionNode: Factor out local variable for global generator
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6371
We could not rely on .ui files when generating the ninja rules
for the generated UI header files. .ui files might be added to the
target sources but never processed by AUTOUIC afterward, since UI
header files are never included in a source code. Instead of adding
dependency rules based on the .ui files, this approach scans
non-generated source files for includes of the UI header files,
as AUTOUIC does. This gives the consistent set of UI header files
at configure time, that could be used to generate byproducts rules
for the AUTOUIC. Also, the path to the generated UI header file depends
not on the .ui file location but on the include line is used in source
files.
Fixes: #16776
Since commit 2ae72ef74b (Xcode: Enable multi-arch TARGET_OBJECTS genex
in [INTERFACE_]LINK_LIBRARIES, 2021-05-26, v3.21.0-rc1~126^2) the
TARGET_OBJECTS genex, when referenced for linking, is now evaluated with
EvaluateForBuildsystem enabled. This causes the object file paths to be
computed with a buildsystem-specific placeholder for the configuration.
This is normally fine because the placeholder will be evaluated by the
native buildsystem tool using the proper configuration. However, the
Ninja Multi-Config generator's `${CONFIGURATION}` placeholder may not
have the correct value for cross-config object files. Switch back to
using the per-config location of each object file for this generator.
Fixes: #22436
Extend the `SwiftOnly` test to cover the fix in commit 3ddd7f3576
(enable_language: Fix test for working compiler with CMP0126 NEW
behavior, 2021-07-15), as that commit did for the `CSharpOnly` test.
Fixes: #22451
Since commit 0a0a0f8a74 (cmMessenger: Color messages to terminal by
type, 2021-05-18, v3.21.0-rc1~146^2) the message output no longer goes
through our custom streambuf on Windows that converts output encoding.
This can cause messages to be printed with the wrong encoding in a
Windows Console. It also causes messages to have a mix of LF and CRLF
newlines because `stderr` converts LF to CRLF but our custom streambuf
does not.
Revert to using just `cerr` for messages on Windows. Another approach
will be needed to achieve color output on Windows later.
Fixes: #22444
Revert commit 0665d9092e (CMakeDependentOption: Allow parentheses in the
depends string, 2021-06-13, v3.21.0-rc1~32^2). It broke existing use
cases with parentheses in regular expressions. Also add a test for this.
Fixes: #22447
When resolving binaryDir into a full path from a relative path, we
forgot to check if binaryDir is altogether empty, causing empty
binaryDir's to resolve to the source directory. Fix this.
Fixes: #22434
Update the logic that converts a `try_compile` result from a cache
entry to a normal variable to tolerate an existing normal variable
under CMP0126 NEW behavior. Otherwise the `try_compile` result
is ignored because CMake uses the false value of the normal variable,
and CMake incorrectly reports that the compiler does not work.
This went unnoticed for some languages (e.g. C and CXX) because the
check for a working compiler is skipped if ABI detection works.
It does affect other languages (e.g. CSharp).
Fixes: #22423
Documentation added by
* commit 4f4f2028b8 (Help: Add documentation for buildPresets and
testPresets, 2021-01-13, v3.20.0-rc1~51^2~7)
* commit 676ecf0d37 (cmake-presets: Add build and test presets,
2020-12-14, v3.20.0-rc1~51^2~6)
used square brackets in the `cmake --build` signature to indicate
non-optional alternatives, which is not a typical convention.
A common convention is to use parentheses instead, but in this
case it is probably clearer to list the two signatures separately.
Fixes: #22413
Since commit 84036d30d4 (IntelLLVM: Fix C/C++ standard level flags on
Windows, 2021-07-07, v3.21.0-rc3~8^2~1) we activate C/C++ standard level
logic for IntelLLVM when targeting the MSVC ABI. Update the
`RunCMake.try_compile` test to be aware of this even when CMake is
itself configured by an older CMake that does not know this.
This was previously fixed by commit d46590910c (Check*CompilerFlag: Do
not set result as a normal variable too, 2020-09-21, v3.18.3~1^2^2), but
was regressed by refactoring in commit 90dead024c (CheckCompilerFlag:
unified way to check compiler flags per language, 2020-09-25,
v3.19.0-rc1~88^2) due to the changes being developed concurrently.
Fix it again, and add a test case.
Fixes: #21207
The RunCMake infrastructure's `*-stdout.txt` expected output files
interpret `\n` as a `\` and `n` rather than a newline. Use a literal
newline instead. Otherwise the cases that were trying to match any
configuration name via `[^\n]*` would fail on `RelWithDebInfo` because
it contains the letter `n`.
Refactoring in commit 7f506b95a7 (cmGeneratorTarget: Refactor link item
lookup, 2021-05-26, v3.21.0-rc1~103^2~4) accidentally dropped the
persistent lookup scope tracking across multiple items that was added by
commit f0e67da061 (target_link_libraries: Fix out-of-dir linking of a
list of targets, 2020-01-14, v3.17.0-rc1~149^2). This broke a
transitive out-of-dir linking case not covered by our test suite.
Restore the scope tracking and add a test case.
Fixes: #22363
RPM 4.11.3 for el7 contains backported support for the RPM weak dep tags.
It only supports querying those tags, but rpmbuild can not make use of them.
Since CPack relies on rpmbuild --querytags to check for support, this
commit switches to rpm --suggests to check for support of weak
dependencies.
Fixes: #22350
93c718791e VS: Use 64-bit MSBuild in VS 2022
c46b265839 VS: Add Visual Studio 17 2022 generator
b610b7a35c VS: Update v142 CL flag table for VS 17.0 Preview 1
43375c6418 Help: Remove unnecessary Sphinx versionadded markup in VS toolset selection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6268
Running `xcode -version` on an ARM box prints content to stderr:
objc[...]: Class ... is implemented in both...
One of the two will be used. Which one is undefined.
Capture and parse only stdout. Otherwise we might configure test
behavior for the wrong version of Xcode.
e13704ce72 Add directory property to list imported targets
ea6d338ea1 cmState: Record imported target names in each directory
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6215
369725faa5 gitlab-ci: add job to run CPack RPM tests
1186ed64d0 ci: add rpm-build to Fedora base image
60380bd77c Tests: Fix RunCMake.CPack_RPM.DEBUGINFO test case
5130ff6878 Tests: Fix CPackComponentsForAll-RPM-IgnoreGroup test on Fedora 34
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !6214
The linker shipped with Xcode 13 changed the architecture
mismatch linker warning into:
```
ld: warning: ignoring file libfoo.a, building for macOS-x86_64 but attempting to link with file built for macOS-i386
```
Since commit c826745f5a (CPack/DEB: Do not crash when asked for debug
symbols when there are none, 2020-10-29, v3.20.0-rc1~461^2) the test
fails because CPackRPM warns about no sources in which to find debug
symbols. Add expected output for this case.
Update the cross-arch case from commit f174b919d6 (Tests: CpackRPM test
component architecture, 2015-02-19, v3.3.0-rc1~415^2~1) to use
`armv7hl`, which is supported by current RPM versions.
Fixes: #19983
Đoàn Trần Công Danh