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")
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>
For other reasons, Meson transforms "-Wno-x" into "-Wx -Wno-x" for GCC,
but this breaks with "-Wno-attributes=x" with:
```
cc1plus: error: arguments ignored for '-Wattributes='; use '-Wno-attributes=' instead
```
Suppress that workaround for -Wno-attributes=.
Closes: https://github.com/mesonbuild/meson/issues/13022
aee941559 ("rust: recursively pull proc-macro dependencies as well")
had to be reverted (in a66cb97e8) because it broke Mesa cross
compilation. This happened because a C shared library was linked with
a Rust C-ABI static library, which caused it to inherit the proc macro
dependency the Rust static library was linked with.
The right way to handle this is for only Rust targets to inherit proc
macro dependencies from static libraries they link with. A Rust
executable, library, or whatever will need the proc macros its Rust
dependencies use, as illustrated in the test case that I've
reintroduced here.
I've verified that Mesa still cross compiles correctly with this
change. The same failure was also identified by the "rust/21
transitive dependencies" test case, but only when cross compiling, so
it wasn't caught by CI.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
If need_exe_wrapper() is called while figuring out the language compiler,
the MachineInfo isn't complete yet, so machine_info_can_run() would return
False despite not cross compiling.
Make sure this fails loudly.
c1076241af changed the logic in multiple
places, in particular it looks like it was assumed that is_cross is always
the same as need_exe_wrapper(), but that's not true.
Also the commit only talks about mypy, so this was definitely not intended.
This reverts all the cases where need_exe_wrapper() was introduced back to
is_cross.
The change in backends.py could be a correct simplification, but I don't know
the code base enough, so reverting that too.
See #13403 and #13410
This reverts commit cc201a5396.
It's true that some aarch64 CPUs can run 32-bit ARM code, but some
(especially high-end ones, those most likely to be running builds)
cannot. It's better to assume that they can't, so builds don't
unnecessarily fail due to attempting to run a sanity check executable.
CMake has two target properties, LINK_OPTIONS and INTERFACE_LINK_OPTIONS.
The former is for link flags that apply only to the target (PRIVATE).
The latter is used for link flags that propagate to dependents (PUBLIC
or INTERFACE). Meson currently propagates all flags, PUBLIC and PRIVATE,
as part of the generated dependency() which causes problems when some of
the private flags are highly disruptive, e.g. `-Wl,--version-script`.
Tease apart the two kinds of link flags and, for non-static libraries,
only propagate the PUBLIC/INTERFACE flags and not the PRIVATE ones.
The documentation for subprocess.run at https://docs.python.org/3/library/subprocess.html#popen-constructor has a warning,
pointing to using shutil.which() instead of subprocess.run for detecting if exe files exists on the path.
shutil.which() is used in many places already.
Fix incorrect map access to custom_target_output_buildfile in CustomTargetIndex
case. Map keys are file names with the path appended, but the used keys were
just the file name. This led to crashes.
Revert "interpreter: when overriding a dependency make its name match"
This reverts commit b1340e9bb1.
Revert "dependency: define equality and hash operators for Dependency"
This reverts commit 6d713e40f8.
This caused some projects to fail to build, such as libplacebo and
libepoxy. Taking libplacebo as the example, the produced build.ninja
does not include libvulkan.so as a linker input for
src/libplacebo.so.338.
We are probably getting dependency hashing wrong somewhere. Unsure where
exactly and unsure how to create a test case. We are also deep into rc2.
Revert it for now and try to re-land these changes for 1.6.
Bug: https://bugs.gentoo.org/935443Fixes: #13352
This reverts commit 9f02d0a3e5.
It turns out that this does introduce a behavioral change in existing
users of ConfigurationData, which it wasn't supposed to (it was supposed
to preserve behavior there, and add a new *warning* for
EnvironmentVariables).
This breaks projects such as pulseaudio, libvirt, and probably more.
Roll back the change and try again after 1.5.0 is released.
Fixes: #13372
Don't require the string to be enclosed in parentheses.
https://github.com/llvm/llvm-project/pull/97323 changed the LLD
version printout to no longer be enclosed in parentheses, which
made Meson fail to detect the linker style used here.
The LLD change is being reverted in
https://github.com/llvm/llvm-project/pull/97698 in order to fix
building with existing Meson versions, but for the future, loosen
the check slightly, to not require the parentheses.
When building a limited API module on Windows the library
to link with should be python3.dll, not python3X.dll. This was
already the case for non-GCC, but should have been the case
unconditionally.