The Ninja generator traditionally referenced source files and include
directories using paths relative to the build directory if they could be
expressed without a `../` sequence that leaves the build and source
directories. For example, when using a `build/` directory inside the
source tree, sources would be compiled as `-c ../src.c` and include
directories would be referenced as `-I ../include`. This approach
matches the traditional Ninja convention of using relative paths
whenever possible, but has undesirable side effects such as:
* Compiler diagnostic messages may not use absolute paths, making it
harder for IDEs/editors to find the referenced sources or headers.
* Debug symbols may not use absolute paths, making it harder for
debuggers to find the referenced sources or headers.
* Different results depending on the path to the build tree relative
to the source tree.
* Inconsistent with the Makefile generators, which use absolute paths.
Switch to always using absolute paths to reference source files and
include directories on compiler command lines. While alternative
solutions for diagnostic messages and debug symbols may exist with
specific tooling, this is the simplest and most consistent approach.
Note that a previous attempt to do this in commit 955c2a630a (Ninja: Use
full path for all source files, 2016-08-05, v3.7.0-rc1~275^2) was
reverted by commit 666ad1df2d (Revert "Ninja: Use full path for all
source files", 2017-02-24, v3.8.0-rc2~9^2) due to problems hooking up
depfile dependencies on generated files. This time, the changes in
commit 2725ecff38 (Ninja: Handle depfiles with absolute paths to
generated files, 2021-05-19) should avoid those problems.
Fixes: #13894, #17450
Extend the change from commit 2725ecff38 (Ninja: Handle depfiles with
absolute paths to generated files, 2021-05-19) to work on versions of
Ninja that do not support implicit outputs. Specify the absolute paths
as normal outputs on such versions.
Issue: #13894, #21865
The `GetSourceFilePath` method is meant only for compiled sources, and
automatically handles converting it to a path for the Ninja build
manifest. Rename the method to clarify both.
The commit 98fea8205e (Compiler/TI: Avoid response file usage for
linker, 2020-07-11, v3.19.0-rc1~495^2) disabled linker file usage by
default. The previous settings were working, even if not for all cases.
Restore them and add an explanation in a comment.
Issue: #22233
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
The new variable allows projects to define custom key=value pairs of
variables to be set in CPack cmake_install.cmake script invocations.
This allows install(SCRIPT|CODE) to be parameterized at runtime.
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.
