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
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
Revert commit 204aecdf82 (cmGlobalGenerator: Port configure-time code to
cmMakefile., 2015-08-02, v3.4.0-rc1~234^2~8). `AddRuleHash` is
generate-time code.
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.
Revert commit 8377d9e00b (Fortran: Inline conversion to relative path,
2016-10-04, v3.8.0-rc1~494^2~4). The inline implementation is still
identical to what was previously called. Restore the call again.
These fields are specified by our `P1689r3` paper, but are not actually
needed. The dependencies of the scanning results themselves can be
captured via normal depfile logic. Avoid saving this possibly-large
information in the scanning results. It is not needed by later steps.
Since commit f3eed2c49d (cmGlobalNinjaGenerator: use P1689 dependency
file format for Fortran, 2019-03-12, v3.20.0-rc1~454^2), Fortran stopped
working in a build tree whose path contains a symlink. The reason is
that the P1689r3 format's `work-directory` field gets populated with the
realpath (via `getcwd`) of the build tree instead of the logical path to
the build tree used for generating relative paths in `build.ninja`.
This causes the `Fortran.dd` file to get absolute (real)paths to `.o`
files, and Ninja does not match them with the relative `.o` file paths
in `build.ninja`.
Fix this by dropping use of the `work-directory` field. This restores
our prior approach of generating paths in the dyndep file using the same
forms of paths received from the buildsystem generator. The P1689r3
paper's format may need to be revised to account for this.
Fixes: #21683
18bd63af41 ci: enable FindProtobuf gRPC test on Linux builds
27adb6c78e gitlab-ci: update Debian base images
89478e643f gitlab-ci: update to Fedora 34 base images
6ff48b862c ci: add gRPC to Debian and Fedora base images
4ad8bfcd9b ci: add codespell to Fedora base image
fa261d1b7d ci: add Qt 6 to Fedora base image
82fc490f93 ci: update to Fedora 34 for Linux base images
a69e6dba92 gitlab-ci: update to Fedora 34 for upload jobs
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !6117
