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
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.
They seem to actually cause trouble, like an error reported on IRC where some
but not all CMake invocations may end up with an error like this:
CMake Warning (dev) at /usr/share/cmake/Modules/CMakeParseImplicitIncludeInfo.cmake:74 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted keywords like ")" will no longer be interpreted as keywords when the
policy is set to NEW. Since the policy is not set the OLD behavior will be
used.
Call Stack (most recent call first):
/usr/share/cmake/Modules/CMakeParseImplicitIncludeInfo.cmake:179 (cmake_parse_implicit_include_line)
/usr/share/cmake/Modules/CMakeDetermineCompilerABI.cmake:119 (cmake_parse_implicit_include_info)
/usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:26 (CMAKE_DETERMINE_COMPILER_ABI)
CMakeLists.txt:24 (project)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at /usr/share/cmake/Modules/CMakeParseImplicitIncludeInfo.cmake:74 (if):
if given arguments:
"GNU" "STREQUAL" "SunPro" "AND" "(" ")" "MATCHES" "-D__SUNPRO_C" "OR" ")" "MATCHES" "-D__SUNPRO_F" ")"
I suspect that the line ends up being just ")", which then causes this error.
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.
