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
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
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.
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.
Printing paths to CMake input files does not need to use the
generator-wide relative path conversion rules because we are not
actually generating a relative path for the build system that needs to
be consistent with anything else. Instead, simply print a relative path
if it does not need to start in `../`, and otherwise an absolute path.
The logic skipping relative paths for build trees on network paths came
from commit b5035770bc (BUG: On Windows network paths do not really
work..., 2003-12-24, v2.4.0~3517). However, since commit ad4055f3e2
(ENH: Set RelativePathTopSource and RelativePathTopBinary independently
..., 2007-03-07, v2.6.0~2061) we effectively ignore this logic if the
build tree is inside the source tree on a network path. Also, it is not
clear that logic using `RelativePathTopBinary` is prepared for it to be
empty. Remove the logic for now. If a problem comes up, we can choose
a new approach.
Fix the comment added by commit f6d4fa63f8 (cmStateDirectory: Comment
relative path top directory selection approach, 2021-05-13) to describe
the actual behavior.
In CMake 3.6 and below, running
cmake --build . --target "$(pwd)/SomeTarget"
with a Makefiles generator automatically converted the target
name and invoked `make SomeTarget`. This made the build command
work even though
make "$(pwd)/SomeTarget"
would fail. This behavior was not implemented for any other generators,
and does not make sense because `cmake --build` is supposed to be a thin
wrapper around the native build tool. It has also been broken since
commit 8d47a20f13 (cmOutputConverter: use new ConvertToRelativePath
signature internally, 2016-06-16, v3.7.0-rc1~90^2~1) because cmState's
relative path conversion logic is not initialized in `cmake --build`.
Remove the non-functioning code.
929c8a7860 INTERFACE_POSITION_INDEPENDENT_CODE must be transitive for OBJECT library
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6127
