diff options
author | Eli Schwartz <eschwartz@archlinux.org> | 2023-03-14 23:09:56 -0400 |
---|---|---|
committer | Jussi Pakkanen <jpakkane@gmail.com> | 2023-03-28 15:29:52 +0300 |
commit | 3070bd49a28ae62a4d1ee9828cd658d9782fb17e (patch) | |
tree | 136ff117c552b1e7101c847297cab2276b420d1d /run_meson_command_tests.py | |
parent | be092c252e180d2c7e1fc6639d9ebc56aac80fd1 (diff) | |
download | meson-3070bd49a28ae62a4d1ee9828cd658d9782fb17e.zip meson-3070bd49a28ae62a4d1ee9828cd658d9782fb17e.tar.gz meson-3070bd49a28ae62a4d1ee9828cd658d9782fb17e.tar.bz2 |
do not resolve symlinks when calculating the meson command
We embed the route to executing meson in various cases, most especially
regen rules in build.ninja. And we take care to ensure that it's a
canonicalized path. Although the code has moved around over time, and
adapted in ways both bad and good, the root of the matter really comes
down to commit 69ca8f5b544f700210d9f18613311bcce3c2e37a which notes the
importance of being able to run meson from any location, potentially
not on PATH or anything else.
For this reason, we switched from embedding sys.argv[0] to
os.path.realpath, a very heavy stick indeed. It turns out that that's
not actually a good thing though... simply resolving the absolute path
is enough to ensure we can accurately call meson the same way we
originally did, and it avoids cases where the original way to call meson
is via a stable symlink, and we resolved a hidden location.
Homebrew does this, because the version of a package is embedded into
the install directory. Even the bugfix release. e.g.
```
/opt/homebrew/bin/meson
```
is symlinked to
```
/opt/homebrew/Cellar/meson/1.0.0/bin/meson
```
Since we went beyond absolutizing the path and onwards to canonicalizing
symlinks, we ended up writing the latter to build.ninja, and got a
"command not found" when meson was upgraded to 1.0.1. This was supposed
to work flawlessly, because build directories are compatible across
bugfix releases.
We also get a "command not found" when upgrading to new feature
releases, e.g. 0.64.x to 1.0.0, which is a terrible error message. Meson
explicitly "doesn't support" doing this, we throw a MesonVersionMismatchException
or in some cases warn you and then effectively act like --wipe was given.
But the user is supposed to be informed exactly what the problem is, rather
than getting "command not found".
Since there was never a rationale to get the realpath anyways, downgrade
this to abspath.
Fixes #11520
Diffstat (limited to 'run_meson_command_tests.py')
-rwxr-xr-x | run_meson_command_tests.py | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/run_meson_command_tests.py b/run_meson_command_tests.py index 040105a..093d6ea 100755 --- a/run_meson_command_tests.py +++ b/run_meson_command_tests.py @@ -135,8 +135,7 @@ class CommandTests(unittest.TestCase): (bindir / 'python3').symlink_to(python_command[0]) os.environ['PATH'] = str(bindir) + os.pathsep + os.environ['PATH'] # use our overridden PATH-compatible python - path_resolved_meson_command = resolved_meson_command.copy() - path_resolved_meson_command[0] = str(bindir / 'python3') + path_resolved_meson_command = [str(bindir / 'meson')] # See if it works! meson_py = 'meson' meson_setup = [meson_py, 'setup'] |