On Windows, os.execv spawn the process in background and returns 0.
Therefore, it prevents devenv to return proper exit code from the
called process. (see https://github.com/python/cpython/issues/63323
for reference.)
The solution is to call subprocess.run instead, on Windows, at the
price of keeping the meson python process alive while the devenv
subprocess runs.
This is an old method, that is now just a wrapper around the OptionStore
method, that doesn't add any value. It's also an option related method
attached to the CoreData instead of the OptionStore, so useless and a
layering violation.
We don't need an extra process in the process tree (specifically the
`meson devenv` process itself). Aside for the redundancy, it's actively
problematic if you abort a program in the devenv by using CTRL+C, as
meson itself will then emit a traceback (KeyboardInterrupt) which is
quite ugly.
It's utterly broken, and only works when one path is inside the other:
Traceback (most recent call last):
File "/usr/lib/python3.12/site-packages/mesonbuild/mesonmain.py", line 194, in run
return options.run_func(options)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/site-packages/mesonbuild/mdevenv.py", line 188, in run
write_gdb_script(privatedir, install_data, workdir)
File "/usr/lib/python3.12/site-packages/mesonbuild/mdevenv.py", line 142, in write_gdb_script
rel_path = gdbinit_path.relative_to(workdir_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/pathlib.py", line 682, in relative_to
raise ValueError(f"{str(self)!r} is not in the subpath of {str(other)!r}")
ValueError: '/path/to/builddir/.gdbinit' is not in the subpath of '/path/to/workdir'
ERROR: Unhandled python exception
This is a Meson bug and should be reported!
If an annotation could not be resolved, it's classified as a "missing
import" and our configuration ignored it:
```
Skipping analyzing "mesonbuild.backends": module is installed, but missing library stubs or py.typed marker
```
As far as mypy is concerned, this library may or may not exist, but it
doesn't have any typing information at all (may need to be installed
first).
We ignored this because of our docs/ and tools/ thirdparty dependencies,
but we really should not. It is trivial to install them, and then
enforce that this "just works".
By enforcing it, we also make sure typos get caught.
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
This lessens the amount of code imported at Meson startup by mapping
each dependency to a dictionary entry and using a programmable import to
dynamically return it.
Minus 16 files and 6399 lines of code imported at startup.
We need to remember its value when reconfiguring, but the Build object
is not reused, only coredata is.
This also makes CLI more consistent by allowing `-Dvsenv=true` syntax.
Fixes: #11309
It is often more useful to generate shell script than dumping to stdout.
It is also important to be able to select the shell format.
Formats currently implemented:
- sh: Basic VAR=prepend_value:$VAR
- export: Same as 'sh', but also export VAR
- vscode: Same as 'sh', but without substitutions because they don't
seems to work. To be used in launch.json's envFile.
Now that top builddir is not the default workdir any more, the .gdbinit
file we write there won't be loaded automatically unless user cd there,
or use --init-command. There is also a global setting that user has to
set to allow automatically loading .gdbinit file.
Most of the time it is preferable to remain the the top source dir
instead of going into the builddir. Add --workdir argument to be able to
have a different workdir than builddir, but keep it default to builddir
for backward compatibility, and also because it makes gdb integration
better.
We already use options.command for the subcommand in use, in this case
devenv. We cannot reuse that variable name for the list of words to
execute inside the devenv.
- Remove duplicated code in mdevenv.py
- Change the limit to 1024 instead of 2048 which is what has been
tested.
- Skip shortening if it is already short enough.
- Skip shortening with wine >= 6.4 which does not seems to have that
limitation any more.
- Downgrade exception to warning in the case WINEPATH cannot be
shortened under 1024 chars, it is possible that it will still work.
We might be using all fallbacks, or be super weird and not use
bash-completion, or simply have a different PKG_CONFIG_LIBDIR set. And
devenv already checks whether the dependency is found, but defaults to
required anyway, which is wrong.
When the project instals GDB helper scripts, copy them into
meson-private directory with the right tree layout and write a .gdbinit
script to load them automatically.
Currently it tries to run "cmd" by default in a MSYS2 bash.
Passing "bash" doesn't work since that defaults to WSL and
one has to pass an absolute path to bash instead, and even then
one misses out on the PS1 override.
In case $SHELL is set and the contained path exists prefer it even if
we are on Windows.
To make the PS1 override work we can't use Unix paths in Python since
we might be on Windows, so move the .bashrc check into the temporary
bash script itself.
This makes "meson devenv" work the same under MSYS2 as on Linux.
"meson setup" is resolving symlinks for the build directory in
validate_core_dirs. For consistency with it, do the same when
the build directory is passed via -C to devenv, dist, init, install
and test.
This ensures for example that the path to test dependencies is
computed correctly in "meson test".
Fixes: #8765
Charles Brunet