Test '230 external project' uses make, but is too dumb to use the
platform conventions for shared library names in installed files
expected by shared_lib, so special case that.
By default, we build with debug info which can be useful for
investigating why a test segfaults instead of either passing or failing.
The nasm language hooks this up, but using nasm as a generator program
does not.
Bug: https://bugs.gentoo.org/936911
The command we use to heuristically parse whether it is dirty by
interpreting prose descriptions of the repository state, is vulnerable
to changes in locale resulting in failing to match the English word that
means it is clean.
Unfortunately, I am no mercurial expert so I am unaware if mercurial
supports scripting, like git does. Perhaps the technology simply does
not exist. A quick attempt at searching for the answer turned nothing
up. It appears that #4278 had good cause indeed for using this prose
parsing command.
So, we simply sanitize the environment due to lack of any better idea.
Bug: https://bugs.gentoo.org/936670
In particular, it is only ever constructed once, and all but two of its
arguments are always passed. So there's no reason or valid justification
to initialize them as None or pretend that you have to check them for
None values. Nor in fact does the command list need to be a
default_factory.
There are also two instance attributes which it is never instantiated
with, but which are tracked after the fact. Don't add this to the
signature for `__init__` as that is misleading.
create_target_linker_introspection is only ever called from one place,
which passes in CompilerArgs. This was implemented in commit
5eb55075ba which performed this conversion
as a preventative measure, since its type was not obvious (and thereby
modified the *type* of the variable in place).
We have a function that wraps two others because it first checks whether
the input is static or shared. By the same token, it has to return types
valid for either. We already *know* that we are a shared library, so we
can and should use the real function directly, which is both a
micro-optimization of function call overhead, and fixes a mypy
"union-attr" error.
It's always true because the func is always a real, truthy func object.
In the cmake case, the logic seems to be broken because if a path is not
a file, then that includes the case where it does not exist. It also
clearly meant "or" instead of "and".
What actually ended up happening was that this check never fired at all.
Because "if not func and not ..." would always fail, because "not func"
is always false. Maybe we don't need this logic at all...
On Windows, the output read from the stream has '\r\n', which in .txt,
.json and console logger (when captured to a file) translates to '\n\n'.
This results in every log line being separated by an empty line.
This is a bit of a hack, since the rule is added outside of the
`__init__` method, and that's probably bad. But at least we can get some
additional help by telling type checkers what it will be
URLError is a subclass of OSError and intermittent server errors can
manifest as OSError while reading instead of a URLError while
establishing a connection, which will cause the fallback url to be
ignored:
```
Looking for a fallback subproject for the dependency gudev-1.0
Downloading libgudev source from https://gitlab.gnome.org/GNOME/libgudev/-/archive/238/libgudev-238.tar.bz2
HTTP Error 404: Not Found
WARNING: failed to download with error: could not get https://gitlab.gnome.org/GNOME/libgudev/-/archive/238/libgudev-238.tar.bz2 is the internet available?. Trying after a delay...
HTTP Error 404: Not Found
WARNING: failed to download with error: could not get https://gitlab.gnome.org/GNOME/libgudev/-/archive/238/libgudev-238.tar.bz2 is the internet available?. Trying after a delay...
HTTP Error 404: Not Found
WARNING: failed to download with error: could not get https://gitlab.gnome.org/GNOME/libgudev/-/archive/238/libgudev-238.tar.bz2 is the internet available?. Trying after a delay...
WARNING: failed to download with error: The read operation timed out. Trying after a delay...
WARNING: failed to download with error: The read operation timed out. Trying after a delay...
ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment.
```
At an OS level, Unix-like OSes usually have very large or even
unlimited sized command line limits. In practice, however, many
applications do not handle this (intentionally or otherwise). Notably
Wine has the same limits Windows does, 32,768 characters. Because we
previously double counted most characters, we papered over most
situations that we would need an RSP file on Unix-like OSes with Wine.
To fix this issue I have set the command line limit to 32k, this is
still a massive command line to pass without an RSP file, and will only
cause the use of an RSP file where it is not strictly necessary in a
small number of cases, but will fix Wine applications. Projects who wish
to not use an RSP file can still set the MESON_RSP_THRESHOLD environment
variable to a very large number instead.
Fixes: #13414
Fixes: cf0fecfce ("backend/ninja: Fix bug in NinjaRule.length_estimate")
This causes us to not count the spaces between arguments, thereby
undercounting the number of elements. This is extra important because we
previously double counted all actual characters, covering this issue up.
Fixes: cf0fecfce ("backend/ninja: Fix bug in NinjaRule.length_estimate")
makepkg can do this, if when building packages from source you enable
debug. This is apparently being shipped in the /etc/makepkg.conf in
docker containers, which means building AUR packages now requires
installing debugedit, and then bloating your container with
/usr/src/debug. We really do not want that.
Reconfigure so that we do not, in fact, need that.
Due to reasons, Arch has chosen to split out the glib2 package into a
glib2-devel package containing a small handful of python programs. The
references to these programs are contained in the main glib2 package, so
meson fails a lot in CI with e.g.
```
test cases/frameworks/7 gnome/gdbus/meson.build:1:18: ERROR: Dependency 'gio-2.0' tool variable 'gdbus_codegen' contains erroneous value: '/usr/bin/gdbus-codegen'
This is a distributor issue -- please report it to your gio-2.0 provider.
```
In commit c9aa4aff66 we added a refresh
call to git to catch cases where checking for uncommitted changes would
misfire. Unfortunately, that refresh performs a write operation, which
in turn misfires on readonly media. We don't actually care about the
return value of the refresh, since its purpose is solely to make the
next command more accurate -- so ignore it.
Fixes: c9aa4aff66Fixes: #13461
The existing "*-linux-gnu*" works on the Debian multiarch model for
Linux architectures; tweak it to be "*-gnu*" so it works also for Hurd
architectures.
This makes the cmake-based search of dependencies work on Debian
GNU/Hurd.
Fallout from the OptionStore refactor, and specifically commit
9a6fcd4d9a. The `std` object was migrated
from having an option itself, to having the value fetched and saved
directly. In most cases, this also meant avoiding `.value`, but in a
couple cases this refactor went overlooked, and crashed at runtime.
Only affects Elbrus and Intel C++ compilers, seemingly.
Fixes#13401
Since they do not implement a default install dir like BuildTargets do.
gnome.compile_resources() would result in an unhandled python exception
when missing install_dir argument together with providing following arguments:
gresource_bundle: true
install: true
closes: https://github.com/mesonbuild/meson/issues/13447
Signed-off-by: RaviRahar <ravirahar33@gmail.com>
Jon Turney
Charles Brunet
Nirbheek Chauhan
Dylan Baker
Eli Schwartz
H. Vetinari
Mateusz Patyk
Jannik Glückert
Monson Shao
Jussi Pakkanen
Pino Toscano
LegStrong
Joey Pabalinas
Mads Andreasen
RaviRahar