Store the main dependency as the first entry in the dependency list plus
a boolean member indicating its existence. Note that this slightly
changes existing behavior: the main dependency was previously the last
entry of the dependency list.
It is unused since commit c564a3e3ff (Ninja: Always compile sources
using absolute paths, 2021-05-19, v3.21.0-rc1~129^2), which left
behind a FIXME comment to eventually remove it.
Note 1: `detail::AddCustomCommandToTarget()` resets cc,
since cc is not moved away.
Note 2: In `detail::AddUtilityCommand()`, a few vars are preserved
before using. Their refs will be alive in most cases, but cc might
be destroyed in the future.
Make `cmCustomCommand` have just only default constructor.
Use each setter instead. This follows the builder pattern.
Introduce `cc::SetOutputs(std::string output)`.
This will be used later, as substitution for `cc::SetOutputs({output})`.
Single-config generators already support unity builds with per-config
sources because they compute sources using `CMAKE_BUILD_TYPE` as the
configuration. Each original source is either included in the unity
build source, or not.
Teach multi-config generators to compute the list of sources for
inclusion in unity builds using all configurations. Previously they
only used the empty string as the configuration. Each original source
may be included in some configurations, but not others. Use
preprocessor conditions to guard their inclusion when necessary.
Fixes: #22892
4707ecbe6f CUDA: Support CMP0105 on Clang
15fde4c420 CUDA: Use local shorthands for variables in Clang device link code
cf7e68087d CUDA: Avoid unnecessary allocation and GetLinkLanguage()
5b0693411e CUDA: Ignore USE_WATCOM_QUOTE for device link rules
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6709
The copy_idb_pdb.cmake script would be executed for every configuration
for all configurations.
Debug would still want to get the RelWithDebInfo files, and the other
way around.
If the Debug configuration contains `/ZI` but the RelWithDebInfo doesn't
then the copy_pdb_idb.cmake script will cause problems due to the fact
that it was common for both configurations but they are incompatible
with each other.
There's no reason to allocate the cmNinjaLinkLineDeviceComputer on the heap.
We can also assume the link language as CUDA in cmLocalGenerator::GetDeviceLinkFlags().
The pch object file could cause problems when the reused pch is passed
through an OBJECT library, which would use INTERFACE_LINK_LIBRARIES to
link the pch object file.
Fixes: #22630
Currently, this feature is only supported on ELF platforms. So, the property
LINK_WHAT_YOU_USE will be ignored for other plateforms.
Moreover, flags and commands are now controled by CMake variables.
Fixes: #20174
Extend the fix from commit 2d0b0e2b9d (Do not exclude include
directories made implicit by CPATH, 2019-05-29, v3.14.5~2^2) to cover
include directories that are symlinks to paths listed in `CPATH`.
Compare resolved paths against resolved entries of `CPATH`.
Resolve the entries as late as possible in case symlinks change.
Fixes: #22383
OUTPUT variant with a TARGET given to allow resolving target-based generator
expressions wouldn't work because OUTPUT is resolved before generator targets
are created, i.e. FindGeneratorTargetToUse() returns nullptr.
This is a known limitation, see #21364.
Implements #21336.
In a per-component installation the generated installation scripts
are invoked once for each component.
Per default custom installation script code added by install(CODE|SCRIPT)
only runs for one specific component in this context.
The new ALL_COMPONENTS option allows custom script code to be run once
for each component being installed.
With the recent update to `GetObjectFileNameWithoutTarget`, we no longer
have any call sites for `MaybeRelativeToCurSrcDir`. It does not make
sense for the generator to produce paths relative to the source tree in
general, so remove the method.
We select an object file name based on the path to its source file.
Localize the logic for shortening this via relative paths. It does not
need to use the generator-wide relative path conversion rules because we
are not actually generating a relative path that needs to be consistent
with anything else.
Most calls to `MaybeConvertToRelativePath` use one of our common work
directories (e.g. top of the build tree) as the local path. Add helpers
for each of the common cases to simplify and clarify call sites.
