Sphinx 4 by default generates `man/#/foo.#`, but older versions generate
`man/foo.#` as our install rules expect. Update our Sphinx config file
to tell Sphinx 4 to use the old layout.
Fixes: #22192
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
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
