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
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
Sources that will be scanned for C++ module dependencies need to be
excluded from unity builds. We need to compute compile features in
order to know which sources will be scanned. Unity build and PCH
sources can be added afterward without changing the compile features.
This re-implements commit 76b5383123 (cmGlobalGenerator: add unity
sources after computing target compile features, 2024-01-01,
v3.28.2~17^2~1) using a simpler approach that also preserves support for
PCH with Unity builds.
Issue: #25650
Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>
We need to know which sources will be scanned for C++ module
dependencies in order to exclude them from unity builds. The
addition of unity sources will not change the set of features.
The original GetLanguageOutputExtension took a sourcefile instead of the
name of the language itself. This implementation provided a convenient
handler for when the SourceFile doesn't know what language it is, but
there are times where we know the language, but don't necessarily have a
source file. Adding an overload that takes the name of the language and
returns the extension of that language, or empty string if no extension
is registered.
Commit f2617cf8e6 (Source: Add cmInstallRuntimeDependencySet,
2021-05-19) introduced via !6186 to 3.21 added storage to the global
generator for runtime dependency sets. However, this was not cleared at
the start of configure in the `ClearGeneratorMembers()` method. When
using `ccmake` to configure (and, presumably `cmake-gui` too), projects
using `install(TARGETS … RUNTIME_DEPENDENCY_SET)` would use dependency
set tracking instances from previous configure runs that held references
to targets free'd with the `cmMakefile` instance that held them.
Clear the dependency sets at the beginning of configure so that they are
not remembered and trigger via use-after-free bugs when used.
Fixes: #25446
We need to be able to construct BMIs that will be usable from the client
modules for the target importing the module, so create BMI-only
compilation rules for `IMPORTED` targets to create these BMIs.
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 12.
8451a3f0b5 cmGlobalGenerator: use a stream for output in `Build`
e060666531 cmake: write the build command itself with `--verbose`
b017c9f127 cmGlobalGenerator: fix off-by-one for `&&` command joining
c715fd8d76 cmGlobalGenerator: quote commands in `::Build` output
d6c0e827bc cmGlobalGenerator: add a `QuotedPrintable` method for commands
28ee3bef34 cmGlobalGenerator: add missing spaces in output
465ab8d872 cmGlobalGenerator: use `cmStrCat` in `::Build`
81d45dabc4 cmOutputConverter: add a `static` version of `EscapeForShell`
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Acked-by: Alex <leha-bot@yandex.ru>
Merge-request: !8183
When the build system re-runs `cmake` to regenerate itself, preserve the
`--compile-no-warning-as-error` option if it was used when `cmake` was
last explicitly invoked. Normally such settings are preserved in the
cache, but the purpose of this option is to be beyond the reach of
project code.
429a452705 Autogen: Add target's C++ standard to moc_predef.h
21f812e57c Autogen: Split creation and setup of custom targets into separate steps
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8359
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we prefer `llvm-strip` over
`strip` when using Clang. However, since commit 20291e8e72 (install:
Fix stripping on macOS, 2019-01-30, v3.14.0-rc1~31^2) on macOS we add
flags `-u -r`, needed by Apple's `strip` for executables, but that
`llvm-strip` does not need or support. Improve the condition to add
Apple-specific flags only when the selected `strip` tool is Apple's.
Note that Apple dylibs must be stripped with `-x` with either Apple's
`strip` or `llvm-strip`.
Fixes: #24601
Defer the setup step until after compile features have been finalized on
normal targets. Later this will help pass the information to Qt tools.
Issue: #24624
The "extra" generators were created in CMake's early years to provide
support for users of specific IDEs by directly generating their project
files alongside make or ninja files. Nowadays the file-api provides a
more generic, maintainable, well-tested, and robust way for IDEs to view
CMake project build trees. Deprecate the legacy "extra" generators to
encourage the corresponding IDEs to use the file-api.
Fixes: #19090
Brad King