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
The commented-out command used "bdist", which produces a "dumb" format
(that's what the setuptools docs call it! it's an alias for
"bdist_dumb"). A tarball that can be extracted to / and installs a
system image containing e.g. /usr/lib/python3.12 and /usr/share/, but
no metadata outside of that.
It apparently may have also generated a wheel at some point? But current
versions of setuptools do no such thing. And wheels are what we actually
want, since we uploaded them for years and they are faster for PyPI
users to install.
The canonical command name for producing wheels is actually
"bdist_wheel" instead of "bdist_dumb". No clue what setuptools changed,
about the latter, but the former definitely works.
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
We have two ways of marking a test as skipped:
- raise MESON_SKIP_TEST
- declare that the tools it needs in test.json are unavailable
Doing the former requires performing the configure stage including e.g.
language setup.
In several cases we weren't even getting this far anyway since we used
both mechanisms (the cmake category has a category-wide skip for this,
in fact). In some case, we were missing test.json declaring it skippable;
add this.
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.
This tests that CMake link flags marked as PRIVATE are not propagated
through the generated Meson dependency. -Wl,--version-script is used as
the "poison" here, the build ultimately fails if it appears in the
shared_library() link command.
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.
Fedora, at the very least, now packages zlib-ng as zlib. This means the
version reported for the dependency is now X.Y.Z.zlib-ng by pkgconfig
whereas the test expected X.Y.Z. Make the version check work for both
regular zlib and zlib-ng.
The poorly named `print_tool_versions()` doesn't just print the tools
versions, it finds them and populates a global table, without which some
tests will fail. Rename the function and add a `report` argument so that
calls can decide whether they want to have the printed message, because
the single runner doesn't in quick mode.
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.