| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
`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.
|
|
|
|
| |
Issue: #21752
|
|
|
|
| |
This method returns now a std::unique_ptr instance rather than a raw pointer.
|
|
|
|
|
|
| |
Based on work done by @ben.boeckel (!8051)
Fixes: #22217
|
| |
|
| |
|
|
|
|
|
|
| |
The call site in `AddLanguageFlags` is now the "one true place" for
adding language standard flags. Inline the helper to reduce risk of
adding other call sites later.
|
| |
|
|
|
|
| |
Fixes #22200
|
|
|
|
| |
Migrate from `cmCommonTargetGenerator::AddModuleDefinitionFlag`.
|
|
|
|
| |
Fixes: #18420
|
|
|
|
|
|
|
| |
Add a variable to control both makefile color messages and compiler
color diagnostics.
Fixes: #15502
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously items linked via the link interface of a dependency were
reported in CMP0028 messages as if directly linked by a target.
Clarify the messages to indicate that an offending item is actually
in the link interface of a given target, regardless of its consumer.
Move the check to the end of generation and look through the final set
of link implementations and link interfaces that were used for
generation. This avoids repeating messages on link interfaces that
have multiple consumers.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
|
|
|
|
| |
There's no reason to allocate the cmNinjaLinkLineDeviceComputer on the heap.
We can also assume the link language as CUDA in cmLocalGenerator::GetDeviceLinkFlags().
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
14e57e9637 LINK_WHAT_YOU_USE feature: externalize configuration
9c5132a586 PGI: Fix "LINKER:" prefix generated separator
8a93de080c cmGeneratorTarget: Add method for LINKER: prefix translation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6306
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|
|
|
| |
Move them up from cmLocalGenerator and out of cmStateDirectory.
|
|
|
|
| |
We have the member from the cmOutputConverter parent.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the `config` argument non-optional so all callers must be explicit.
Convert the path style argument to an enumeration to make its role clear
at call sites.
The path style argument is implemented by `ConvertToIncludeReference`,
which was introduced with the Ninja generator by commit 5b114c9bee
(Introduce a cmLocalGenerator::ConvertToIncludeReference function,
2011-09-07, v2.8.7~187^2~4). Its only purpose is to allow the Ninja
generator to use relative paths in `-I` flags. Add a comment explaining
this role.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
0110aa018d IOS_INSTALL_COMBINED: Support Xcode 12 (command line only)
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5785
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Xcode 12 doesn't allow nested builds within the same build directory.
That means we can no longer do an install by building the install target
when IOS_INSTALL_COMBINED is true. We can, however, still do an install
by running the cmake_install.cmake script or executing cmake --install,
since there is no outer build and therefore the associated SDK can be
built as a sub-build.
The non-build methods previously didn't work when
IOS_INSTALL_COMBINED was true because the generated install script
and the CMakeIOSInstallCombined script both made certain assumptions
that relied on being part of a build. Those assumptions are now
removed. A side-effect of this work is that cpack now also works from the
command line when IOS_INSTALL_COMBINED is true.
Relates: #21282
Fixes: #20023
|
| | |
|
| |
| |
| | |
Fixes: #21564
|
| |
| |
| |
| | |
Co-Author: Brad King <brad.king@kitware.com>
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Add support for constructing and using multiple generators for one
custom command. cmGeneratorTarget contains a code path that needs this
behavior when used with Ninja but not other generators, so use virtual
dispatch through cmLocalGenerator.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove unnecessary check of policy CMP0049. The policy can never
trigger on our internally-generated name because it has no variable
references.
The rename in commit 0ed5ce4cd8 (cmTarget: Rename AddSource method for
backward compatibility., 2014-03-17, v3.1.0-rc1~688^2~17) made it look
like this code path depended on CMP0049. Then commit 0e1faa28cb
(cmMakefile: Separate custom command setup from actual creation,
2019-09-14, v3.16.0-rc1~85^2) and commit ea1bed34b2 (cmMakefile: Extract
utilities used for creation of custom commands, 2019-09-21,
v3.16.0-rc1~52^2~1) built additional infrastructure to thread that
dependence through the call stack. Remove it all.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Custom commands with generator expressions in their OUTPUTs or
BYPRODUCTS are still attached to a single `.rule` file. We use an
internal map to look up the source file holding the custom command for a
given output. Populate this map using the outputs and byproducts from
all configurations after evaluating the generator expressions for each
configuration.
Issue: #12877
|
| |
| |
| |
| |
| | |
Move calls to `CreateGeneratedSource` over to `UpdateOutputToSourceMap`,
which is called for all generated outputs and byproducts.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
Since commit 777ceaea94 (cmMakefile: Delay custom command creation,
2019-10-17, v3.17.0-rc1~352^2) we process custom command declarations at
generate time. Therefore we do not need to look up what source file
holds the custom command producing a given output until generate time.
|