The `Vulkan::Headers` target complements existing Vulkan::Vulkan target.
It is the same except it omits the Vulkan library which supports
applications that loads the Vulkan library in at runtime.
The `Vulkan::glslangValidator` target provides the glslangValidator
executable which is the tool for converting between shader languages
(GLSL, SPIR-V, etc.).
On subsequent runs of configure from cmake-gui the global generator is
swapped. So on runs other than the first it was setting CC and CXX to
empty when they were otherwise undefined.
Instead, restore them if non-empty and unset them if empty when changing
the global generator and a previous generator exists.
Fixes: #21449
Simplified the text regarding adding sources to be more general as there's also
target_sources().
Improved the wording for FindCUDAToolkit to be more explicit of its usecase and
avoid using "superseded" since the common usecase of FindCUDA was superseded by
the language support.
Wording suggestions incopropated from discussion on #22203.
FindCUDA is still widely used, but has been superseded by the much more robust
native language support. However the deprecation hasn't been noticed well
enough and real-world experience shows there's still new code written to use
it.
Change this particular notice to a warning to get a hard to miss red box.
We lose the semantic meaning, but we don't want to make all notices like this.
If there are similar cases in the future requiring it would be worth adding a
custom variant of the deprecated directive.
Fixes#22203.
The OpenMPI package in Fedora 34 requires a CPU with AVX instructions.
Some of our CI machines do not have them, and so fail the FindMPI.Test
test with `SIGILL`. Switch to MPICH. Since we test with OpenMPI on the
Debian jobs, this covers more MPI vendors anyway.
0a0a0f8a74 cmMessenger: Color messages to terminal by type
bceb8e2ed2 cmMessenger: Pass title inside a metadata structure
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6105
2725ecff38 Ninja: Handle depfiles with absolute paths to generated files
bc40cd7a4e Tests: Add case covering a unity build with a generated source
ae927f936d cmGlobalNinjaGenerator: Improve allocation pattern in WriteBuild
68e5f92cad cmGlobalNinjaGenerator: Factor out custom command output collection
c5195193d3 cmGlobalNinjaGenerator: Reduce string copies in WriteCustomCommandBuild
8bac527b0c cmGlobalNinjaGenerator: Re-order logic in WriteCustomCommandBuild
ddc030f5ca cmGlobalNinjaGenerator: Record implicit outputs as known too
ceb82752ef cmLocalNinjaGenerator: Use variable for main custom command output path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6143
1cb65e680d (ExternalProject: Prevent the noisy detached head
messages on checkout, 2021-01-17) unconditionally added the advice.detachedHead
git config setting, but it requires git 1.7.7 or later. Since it isn't fatal to not
have it, just noisier, only add it when it is supported.
Fixes: #22206
Ninja treats every (normalized) path as its own node. It does not
recognize `/abs/path/to/file` in a depfile as matching `path/to/file`
even when `build.ninja` and the working directory are in `/abs/`.
See Ninja Issue 1251. In cases where we pass absolute paths to the
compiler, it will write a depfile containing absolute paths. If those
files are generated in the build tree by custom commands, `build.ninja`
references them by relative path in build statement outputs, so Ninja
does not hook up the dependency and rebuild the project correctly.
Add infrastructure to work around this problem by adding implicit
outputs to custom command build statements that reference the main
outputs by absolute path. Use a `${cmake_ninja_workdir}` placeholder
to avoid repeating the base path. For example:
build out.txt | ${cmake_ninja_workdir}out.txt: CUSTOM_COMMAND ...
Ninja will create two nodes for the output file, one with a relative
path and one with an absolute path. A depfile may then mention either
form of the path and Ninja will hook up the dependency. Unfortunately
Ninja will also stat the file twice.
Issue: #13894Fixes: #21865
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.
