Restore the logic removed by commit 035078d847 (cmake-gui: Remove
explicit locale setup, 2020-12-17, v3.20.0-rc1~205^2~6), but only with
Qt5 on Windows. Leave a FIXME comment to support Qt6 later.
Fixes: #23562
Issue: #23565
In commit afcd9fe669 (AIX: Add an option to disable automatic exports
from shared libraries, 2020-01-30, v3.17.0-rc1~47^2) the population of
the `<AIX_EXPORTS>` rule variable placeholder was accidentally added to
the device linking rule rather than the main linking rule. This caused
our `ExportImportList` script on AIX, when called for executables with
`ENABLE_EXPORTS` set, to be given an `AIX_EXPORTS` file name that does
not exist, leading to a warning from the `dump` tool.
Move the population of the `<AIX_EXPORTS>` placeholder in the Makefile
generators to the main link rule.
Issue: #20290
In the `cmake` command-line tool, the `message()` command with no
message mode argument prints the message stderr using the C++ `cerr`
stream. Since commit 0a0a0f8a74 (cmMessenger: Color messages to
terminal by type, 2021-05-18, v3.21.0-rc1~146^2) and an update by
commit c7a8c9c811 (cmMessenger: Revert to non-color messages on
Windows, 2021-07-20, v3.21.1~15^2), we print the newline at the end of
the message using just `\n`. We've now observed some cases of output
on stdout and stderr getting jumbled when the two go to the same file
descriptor. Previously the newline was printed with `endl`, which
implicitly flushes. Flush explicitly to restore that behavior.
Fixes: #23155
Since commit f3f57cc4ed (NMake: Use UTF-8 with BOM if supported by
nmake, 2021-04-22, v3.21.0-rc1~217^2), we add a BOM to response files
to tell MSVC tooling that they are encoded as UTF-8. However, the
"NMake Makefiles" generator may also be used with non-MSVC toolchains
that do not understand the BOM. Update the response file encoding
selection heuristic to add the BOM only with MSVC tooling.
Fixes: #23143
Since commit f3f57cc4ed (NMake: Use UTF-8 with BOM if supported by
nmake, 2021-04-22, v3.21.0-rc1~217^2) the encoding of response files is
selected based on the makefile encoding. In principle these may be
orthogonal, but in practice it is a useful heuristic. Call out this
heuristic in a comment, and leave a FIXME to do something better.
The Makefile generators use an internal `cmake -E cmake_copy_f90_mod`
tool to avoid rebuilding module consumers when the `.mod` content
changes only in a trivial way (e.g. the time it was built). This is
done with logic specific to each vendor's module file format. Enable
the "Intel" format support when using the IntelLLVM compiler (ifx) too.
Issue: #22922
Since CMake's default compiler flags with MSVC include `-DWIN32` for
historical reasons, a few preprocessor conditions were accidentally
checking for `WIN32` instead of `_WIN32`. The corresponding blocks
were left out when compiling official binaries for `cmake.org` because
we hard-code compiler flags without `-DWIN32`.
Fixes: #22764
Instead of using the target name directly (which ends up in the `Ninja`
generators querying for the `LOCATION` parameter), wrap up the target
name in a `$<TARGET_LINKER_FILE:>` to avoid the query for the unset
property.
Backport KWSys commit `4ef5b1063` (SystemTools: Ensure Windows Vista
APIs are available before using them, 2021-08-30) to the CMake 3.21
release branch.
Extend the table of special cases from commit 58a50a3a0a (VS: Fix '-T
version=14.28' under VS 16.9, 2021-03-11, v3.19.7~1^2~1) and updated by
commit a60141feaa (VS: Add special case for '-T version=14.29.16.10'
under VS 16.10, 2021-05-27, v3.20.4~11^2). Add a special case for the
name VS 17 will use for VS 16.11's default toolset, so that it can be
used with VS 16.11 too.
Issue: #21922
Revert commit e5ec0e52f4 (AUTOUIC: Fix generating of dependency rules
for UI header files, 2021-07-22, v3.21.1~8^2) because it caused
regressions. For example, changing one C++ source can now cause many
others to rebuild. Revert the change pending further investigation.
Fixes: #22531
Issue: #16776
In commit d7159f9591, (Ninja: Fix LINK_WHAT_YOU_USE link flag placement,
2021-06-24), we fixed usage of -Wl,--no-as-needed to override
-Wl,--as-needed from LDFLAGS. However, that change also passes
-Wl,--no-as-needed to `ar`, which is incorrect flag for `ar`.
Let's check the target type before passing down the flags.
Fixes: #22487
Since commit 4391913133 (Add INTERFACE libraries to generated
buildsystem if they have SOURCES, 2020-07-20, v3.19.0-rc1~346^2~1), the
VS generator may process INTERFACE libraries. Avoid code paths in the
generator that process include directories because they should not be
used by INTERFACE libraries since they do not compile anything.
Fixes: #22494
Move the logic for appending cubin afterwards, so the check can simply be
empty().
With the Makefile generator the option is now at the front instead of being
intermixed with the actual bins.
Seems the relative paths were wrong basically all around such that only
compiling files in the top-level directory would work. I've modified
CudaOnly.SeparateCompilation to cover this.
Fixes#22482.
44ad3f0b added multi-options to CTest, but didn't reset them,
causing ctest_test() to fail if it was run multiple times with
different label arguments. Reset the multi-options.
Fixes: #22485
06e6981 added support for optional binaryDir and generator, but
use the dependent preset's file version instead of the current
preset's file version. Check presets with their own file version
instead of their dependent's file version.
Fixes: #22428
For an AUTOMOC'ed target foo, when depfiles are used, there are the
following dependencies:
foo_autogen -> foo_autogen/timestamp
foo_autogen/mocs_compilation.cpp -> foo_autogen/timestamp
The first is used to trigger AUTOGEN.
The second erroneously triggers a recompilation of
mocs_compilation.cpp when any source file of target foo is touched.
Remove the latter dependency and replace it with an order-only
dependency from foo_autogen/mocs_compilation.cpp to
foo_autogen_timestamp_deps.
That is achieved by making mocs_compilation.cpp or its
per-configuration variants byproduct(s) of the timestamp file.
Fixes: #22338
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