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.
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.