There is no reason to not always do this. Without this, we end up with
a relative path to meson.py in build.ninja files when meson.py is
launched using subprocess.Popen and friends from the meson source root.
This was causing the unittests to intermittently fail when regen was
getting invoked by the pic test. Funnily enough, this only happened when
run via ./run_tests.py because __file__ was 'run_unittests.py' in that
(as opposed to './run_unittests.py') case which made
os.path.dirname(__file__) be '', and the os.path.split test in meson.py
thought that meson.py was invoked via PATH.
When installing Meson, distutils may choose to put shim scripts in the
`PATH` that only set up the egg requirements before launching the real
`meson.py` contained in the egg.
This means that `__file__` points to the real `meson.py` file, but
launching it directly is doomed to fail as it's missing the metadata
contained in the shim to set up the path egg, resulting in errors when
trying to import the `mesonbuild` module.
A similar issue affects Meson when installed as a zipapp, with the
current code going great lengths to figure out how to relaunch itself.
Using `argv[0]` avoids these issues as it gives us the way the current
executable has been launched, so we are pretty much guaranteed that
using it will create another instance of the same executable. We only
need to resolve relative paths as the current working directory may
get changed before re-launching the script, and using `realpath()` for
that saves us the trouble of manually resolving links and getting caught
in endless loops.
This also mean that `meson_script_file` no longer necessarily point to a
absolute file, so rename it to `_launcher` which hopefully would be less
prone to inducing false assumptions.
When installing Meson distutils may choose to put shim scripts in the
PATH that only set up the egg requirements before launching the real
`meson.py` contained in the egg.
This means that __file__ points to the real `meson.py` file, but
launching it directly is doomed to fail as it's missing the metadata
contained in the shim to set up the path egg, resulting in errors when
trying to import the `mesonbuild` module.
A similar issue affects Meson when installed as a zipapp, with the
current code going great lengths to figure out how to relaunch itself.
Using argv[0] avoids these issues as it gives us the way the current
executable has been launched, so we are pretty much guaranteed that
using it will create another instance of the same executable.
Jussi Pakkanen