| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
If the test is driven with a `ccache`-wrapped compiler then
the `CCACHE_BASEDIR` environment variable might break paths
the test checks.
Fixes: #23885
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit c564a3e3ff (Ninja: Always compile sources using absolute
paths, 2021-05-19, v3.21.0-rc1~129^2), both the Ninja and Makefile
generators pass source files and include directories to the compiler as
absolute paths. However, in some other contexts within generated build
systems, we generate paths that may be relative or absolute. In these
contexts, we prefer relative paths, but avoid them when they contain a
`../` sequence that leaves both the build tree and the source tree:
* When the build tree is outside of the source tree, all paths to the
source tree are absolute.
* When the build tree is inside the source tree, we previously assumed
that it is a real directory such that exiting the build tree with
`../` enters the source tree. This allowed paths to the source
tree to be relative to the build tree.
In the latter case, we previously did not support using a symbolic link
inside the source tree to point at the build tree. This is because
relative paths to the source tree would be generated with `../`
sequences leaving the build tree, but they would jump to the parent of
the real build tree, which is not the source tree.
Fix this by requiring that `../` sequences stay inside the build tree
even if its path appears to be inside the source tree. When the build
tree is inside the source tree, all paths to the source tree are now
absolute. For consistency, this applies regardless of whether the
path to the build tree contains a symbolic link.
Fixes: #21819
|
| |
|
|
|
|
|
|
|
|
|
| |
Since commit 61495cdaae (Fix Xcode project references to the source
tree, 2009-09-22, v2.8.0~43) we force source file references to use
relative paths from the source tree. If the source tree path is a
symbolic link inside the build tree, the relative `../` sequence
goes to the wrong place. The problem with debug breakpoints motivating
that change does not seem to occur in modern Xcode versions, so update
the logic to use a relative path only when it does not need to start
in any `../` sequence.
|
| |
|
|
|
| |
Inspired-by: Ben Boeckel <ben.boeckel@kitware.com>
Issue: #16228
|
| |
|
|
|
| |
Verify that the paths to source files and include directories
are passed to the compiler with the symlinks preserved.
|
| |
|
|
|
| |
Run each symlink layout case with various ways to pass the source
and binary directories.
|
| |
|
|
|
|
| |
Accept paths to the source and binary directories as arguments.
Prepare to support more ways of passing the source and binary
directories to `cmake`.
|
| |
|
|
| |
Avoid needing a `.cmake` file named for every case.
|
|
|
In commit dd8365b3f1 (Merge branch 'upstream-KWSys' into update-kwsys,
2020-04-06, v3.18.0-rc1~397^2) we imported KWSys commit `019afb6ea`
(SystemTools: Drop GetCurrentWorkingDirectory 'collapse' argument,
2020-04-03). That caused `GetCurrentWorkingDirectory` to no longer send
paths through the KWSys translation map and broke CMake's detection of
the absolute path to a build directory containing a symbolic link.
Add our own `cmSystemTools::GetCurrentWorkingDirectory` wrapper around
the KWSys method in order to restore that mapping.
Test-case-by: Ben Boeckel <ben.boeckel@kitware.com>
Issue: #16228
Fixes: #20900
|
