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.
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
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.).
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.
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
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.
f78b167a23 cmCommandLineArgument: Provide more information syntax error messages
5aa0dec6b0 cmake: `--build` and `--install` error out when encountering bad flags
928cdb17c5 cmCommandLineArgument: Correctly record parsing failures
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6119
f78b167a23 cmCommandLineArgument: Provide more information syntax error messages
5aa0dec6b0 cmake: `--build` and `--install` error out when encountering bad flags
928cdb17c5 cmCommandLineArgument: Correctly record parsing failures
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6119
add_jar() currently requires (undocumented) that resources be supplied
as relative paths. The resources *may* then end up in a path which does
not reflect the original path particularly when performing out-of-source
builds. This change adds a RESOURCE (and NAMESPACE) parameter and a
function to add the names resources into the named namespace within the
jar- and thus address both of these problems.
Fixes: #22101
fd02f10103 Xcode: Fix typos and spelling in error message
5950e54325 Source: Fix typos and spelling in comments
7072d83772 Help: Fix typos and spelling in documentation
03b1140ddc CONTRIBUTING: Fix typos and spelling
87f8843d8b FindMatlab: Fix spelling in warning and documentation
15cc39ed7f Modules: Fix typos and spelling in documentation
f015c36c5a Modules: Fix typos and spelling in comments of generated code
dad5b9d845 Modules: Fix typos and spelling in comments
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !6099
In ac6a4d4884 (ExternalProject: Improve robustness of update step,
2020-10-17), the method used to check whether we already have a
commit or not was changed from using git rev-list to git rev-parse.
The new logic assumed rev-parse would output nothing if given a commit
hash it didn't know about, but it simply prints the hash again without
raising an error in this scenario. Amend that logic by adding ^{commit} to
the ref to ensure we do get an error if that ref is not currently known.
Fixes: #22166
In commit 7f89053953 (cmSystemTools: Return KWSys Status from CreateLink
and CreateSymlink, 2021-04-15) we just took the `-err` from libuv and
treated it as a POSIX error. This is accurate on POSIX, but on Windows
does not match the POSIX error codes.
Use `uv_fs_get_system_error` to get the actual system error code.
This requires libuv 1.38 or higher. Require that for Windows, but
fall back to the previous approach on POSIX.
Since commit 94c955e508 (Tests: Test the CMakePresets.json example in
the documentation, 2020-10-09, v3.19.0-rc1~8^2) we transform the
documented preset example for testing by replacing the generator.
Extend the transformation with a step to fix `PATH` env var syntax.
These have been added to:
GCC_PREPROCESSOR_DEFINITIONS
OTHER_CFLAGS
OTHER_LDFLAGS
This is to allow Cocoapods to work correctly as it uses xcconfig files to alter build settings in Xcode, and requires these build settings to inherit from their parent, not overwrite.
Raul Tambre