Update to meson 1.8.3 #23
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
This is just a wrapper around `OptionStore.get_option_for`, but without taking an `OptionKey`. This complicates the subproject passing, since `OptionKey` is designed to encapsulate the option name and subproject.
Which are basically the same, except for handling of deprecated options, and various bugs that only existed in one implementation or the other.
More specifically, the bug had been fixed shortly before we implemented this workaround. It's documented as only necessary for the binutils brand specifically, and was fixed upstream in 2.28. We can avoid producing these arguments at all on newer (post-2016) versions of binutils, so gate this behind a version check. This can significantly reduce the size of compiler command lines in some cases, as it encodes the full build directory. It also helps that one person who decides to put commas into their build directory name (which `-Wl,...` interprets as multiple arguments, rather than a single directory string). Bug: mesonbuild#1898 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20535 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16936
Dub is very thorough about what it encodes in a build id even collecting the compiler path. Therefore, if dub is not provided the exact same compiler path that meson got during setup, the dependency would not be found and the test would fail. Signed-off-by: Andrei Horodniceanu <[email protected]>
…rings The behavioral change is there since be1d013 so align the documentation with what is allowed here.
Signed-off-by: Andrei Horodniceanu <[email protected]>
It is not used elsewhere
subproject_dir, environment, and coredata
MSYS2 dropped Python 2 in msys2/MINGW-packages#23713
We should simply remap these to elide the ../ as it's pretty obviously
the natural expectation of using ../ to fetch files from outside the
project and then drop them *into* the project.
Monorepos will likely have a single license file (or set) under which
the monorepo is licensed. But there will be many components, each of
which may use a different build system, which are "standalone" for the
most part. We already support this case as long as you build from the
monorepo, but the resulting license file gets installed to
```
{licensedir}/../
```
which is silly and unhelpful.
Bug: apache/arrow#36411
Move the mention of the (deprecated) default command mode down near the end of the page, instead of presenting it right up front.
Put cygwin filemode tests back under the sourcedir Remove inheritable permissions from the sourcedir For :reasons:, the unit tests which check file mode were built in the tempdir. Instead, remove inheritable permissions from the working directory (which the GitHub VM image has set for some reaons), since they can interfere with getting exactly the file mode you asked for. Partially reverts 04ae1cf
Cuts down the spam radically when building with MSVC.
Don't hardcode paths in /usr when looking for the GTest sources, as in cross-compile or other builds with a sysroot this will find the host sources, not ones that we want to use in the sysroot. Closes mesonbuild#12690.
Both dynamic libraries and bundles these days can be dynamically loaded using the dl APIs (e.g. dlopen, dlclose). It is not possible to include bundles on a linker command line as if they were shared libraries, but that's pretty much the only difference. However, bundles fail the Apple verification for iOS: 2025-02-10 13:54:09.095 ERROR: Validation failed (409) The binary is invalid. The executable 'Runner.app/Frameworks/numpy._core._operand_flag_tests.framework/numpy._core._operand_flag_tests' has type 'BUNDLE' that is not valid. Only 'EXECUTE' is permitted. 2025-02-10 13:54:09.096 ERROR: Validation failed (409) Missing load commands. The executable at 'Runner.app/Frameworks/numpy._core._operand_flag_tests.framework' does not have the necessary load commands. Try rebuilding the app with the latest Xcode version. If you are using third party development tools, contact the provider. So switch to -dynamiclib for shared modules as well. Fixes: mesonbuild#14240
Fix the unhandled KeyError exception that occurs when cross-compilation configuration files are missing required parameters (such as 'endian'). This issue was introduced in commit b0d2a92 (PR mesonbuild#11692), where the key validation logic didn't properly handle the relationship between provided and required keys: - Previously, the code used `set(literal) < minimum_literal` to check if provided keys were a strict subset of the required keys in minimum_literal - This validation logic broke down when the provided keys weren't a strict subset anymore, but rather an overlapping set with disjoint elements on both sides - When required keys were missing, the code continued execution and later threw an unhandled KeyError when trying to access the non-existent keys Changed the condition check from: if set(literal) < minimum_literal: to: if minimum_literal - set(literal): This new check specifically identifies keys that are "present in required but not present in provided", providing users with clear error messages instead of raising unhandled exceptions. This change also removes the implicit requirement that "provided keys must not contain any keys not present in the required set" - allowing for optional keys to exist in the provided configuration. Fixes mesonbuild#14385
…Windows We have previously updated the python_command handling to correctly detect PyInstaller builds without assuming that it is only Windows, back in commit c39ee88. But the fix was incomplete. This affects e.g. running --internal scripts such as symbolextractor. The issue in this case is slightly more subtle. While sys.executable won't be a valid python so it intuitively falls over quite badly when trying to run it as one, getting the original command is broken in a more interesting way. PyInstaller sets `sys.argv[0]` to the basename of the executable, which then got absolutized to a nonexistent file in the current working directory. Fixes: mesonbuild#14412
Another rust tool, another rough copy of the code to run clippy. Apart from the slightly different command lines, the output is in a directory and test targets are skipped. Knowing the output directory can be useful, so print that on successful execution of rustdoc. Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Allow reusing the code for doctests. In particular, the sources are shared between the two cases. Signed-off-by: Paolo Bonzini <[email protected]>
This restores the behavior before 1.8's option store refactoring. The bug arises because c_link_args has been stored in pending_options, and therefore the extended value (which get_global_options correctly computes) is overwritten by the value passed on the command line. In fact, this bug is the reason why I added the "link_args_from_envvar" check: the CFLAGS would be ignored anyway, so I put that logic in code instead of relying on the option store's behavior. The fix is to extend the value *after* the option has been added and the pending_options resolved. This requires a tiny refactoring of the split between CoreData.add_lang_args and compilers.get_global_options. Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit 1c14c08)
Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit 2dc4dde)
The use of os.path.join is inserting `\` into the compile_args, which is wrong since qmake outputs `/` even on Windows, and in fact it causes pkgconfig files that depend on qmake dependencies to have `\` path separators, which get resolved as escape sequences. Use Path.as_posix() to avoid this. (cherry picked from commit 9ca2764)
Fixes: mesonbuild#14788 Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit bdabc2e)
Check that build options fall back to host options, and that they can be retrieved with get_option. Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit 1537a13)
Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit b9ddea2)
This is allowed -- it is already deprecated for the cross file, but it should not assert. Add a deprecation for the native file too, and remove the assert. Fixes: d37d649 Fixes: mesonbuild#14789 Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit 6eb1f2d)
Fixes: mesonbuild#14789 Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit 0376d65)
(cherry picked from commit 8f9eea8)
This is a heavyweight and expensive function to use to verify that we have a string list. Just cast to make mypy happy, we know what we have. (cherry picked from commit cec99fb)
It is too old and barfs on patches from git-format-patch: ``` Applying diff file "orc-0.4.38\0001-meson-fix-symbols-leaking-from-static-library-on-Win.patch" patching file meson.build Assertation failed! Program: C:\Strawberry\c\bin\patch.EXE File: .\src\patch\2.5.9\patch-2.5.9-src\patch.c, Line 354 Expression: hunk ``` 2.6.1 is the oldest known version that works correctly. (cherry picked from commit ab261f9)
Commit eca1ac1 (mesonbuild#14252) added support for properly detecting the -Wno-vla-larger-than flag: a value must be specified for its positive form (-Wvla-larger-than=N), or GCC will exit with the error "missing argument to ‘-Walloc-size-larger-than=’". There is a handful of other -Wno-* flags whose positive form act in the same manner, but are not covered here: * -Wno-alloc-size-larger-than (GCC >=7.1.0) * -Wno-alloca-larger-than (GCC >=7.1.0) * -Wno-frame-larger-than (GCC >=4.4.0) * -Wno-stack-usage (GCC >=4.7.0) Add logic to treat these in the same way. Signed-off-by: Henrik Lehtonen <[email protected]> (cherry picked from commit e501a22)
Fix `scalapack.MKLPkgConfigDependency` not to crash when `MKLROOT`
is unset:
```
File "/meson/mesonbuild/dependencies/scalapack.py", line 65, in __init__
super().__init__(name, env, kwargs, language=language)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/meson/mesonbuild/dependencies/pkgconfig.py", line 322, in __init__
self._set_cargs()
~~~~~~~~~~~~~~~^^
File "/meson/mesonbuild/dependencies/scalapack.py", line 141, in _set_cargs
cflags = self.pkgconfig.cflags(self.name, allow_system, define_variable=(('prefix', self.__mklroot.as_posix()),))
^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'as_posix'
```
The code is crashing because the `_set_cargs()` method assumes that
`self.__mklroot` will always be set, presumably because it assumes
it will only be called only when `MKLPkgConfigDependency.__init__()`
finishes with `is_found = True`. However, both `_set_cargs()`
and `_set_libs()` are called during `PkgConfigDependency.__init__()`,
and therefore they will be called if pkg-config lookup succeeds even
without `MKL_ROOT` set.
To avoid the issue, check for `self.__mklroot is None` in both
functions, and raise a `DependencyException` — effectively causing
the pkg-config lookup to fail in a natural way.
Fixes mesonbuild#11172
Signed-off-by: Michał Górny <[email protected]>
(cherry picked from commit 27c5ac3)
Skip the hdf5 Fortran config-tool test when running on CI and h5fc looks broken. This is needed due to upstream bug that h5fc does not include include paths when built via CMake, that currently affects at least Arch Linux and Gentoo. Bug: HDFGroup/hdf5#5660 Signed-off-by: Michał Górny <[email protected]> (cherry picked from commit 23e4901)
In `run_meson_command_tests.py`. Replace it with `pip install .` if `pip` is available. Replace it with 'gpep517 install-from-source` if available. Else keep the old behaviour. Fixes mesonbuild#14522. (cherry picked from commit b4d3276)
Fixes mesonbuild#6710 (cherry picked from commit 49c462b)
…ting only the real arguments to response file (cherry picked from commit e8c7157)
I ran into GStreamer's CI being overwhelmed by a 5k long command line to g-ir-scanner. This will help bypass the limitation. See https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/532 See mesonbuild#6710 (cherry picked from commit 98f5802)
|
The feature unittests have bit-rotted.
Is there a different way to revive them? |
|
I tested this on much of NumPy's CI over at mattip/numpy#95 and it is passing there. |
|
Any thoughts here or should I self-merge it? It would be nice to fix the testing, but I think it has been broken for a while |
|
Reviewing now. All the BLAS tests were skipped on mattip/numpy#95 and the SIMD tests are failing straight away, so this isn't actually mergeable yet. |
rgommers
approved these changes
Aug 5, 2025
There was a problem hiding this comment.
Okay the full set of CI jobs is happy after all: numpy/numpy#29509. And git diff 1.8.3 HEAD looks sensible. So in it goes, thanks @mattip!
For future reference: we shouldn't be making unnecessary changes here for test suite or linting. It's very hard to get CI to pass, due to the way upstream CI is structural (it's never passed on this repo), and it makes the diff between the fork and upstream larger.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I merged meson 1.8.3 into this branch on my fork, and resolved the conflicts mostly by accepting the changes from upstream meson. There were no conflicts caused by the cpu feature detection additions.
I then ran a build locally. I will submit a PR to numpy/numpy to build with this PR, to make sure it works correctly. Until that passes I am marking this as 'draft'