Update to meson 1.9.2 #24
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
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
As of Swift 5.9, C++/Objective-C++ code can be mixed with Swift, and C++ APIs can be imported to Swift. However, this must be explicitly enabled, as it is disabled by default. Xcode 15 introduces a new setting for this, so only set it on Xcode 15 and above.
Skip if Swift 5.9 or above is not detected.
As is the case with most other methods, it must be overriden in another compiler for it to have any use. Only the Swift compiler uses this method at this time.
Previously, meson would only check if glib was part of target.external_dependencies and add --target-glib appropriately. This however had the downside of meson not adding --target-glib if glib was included as a subproject, potentially breaking otherwise builds. Instead of checking external_dependencies, check target.added_deps for an occurrence of 'glib-2.0' and then pick the appropriate codepath (either from the external dependency based on version_reqs or for the internal dependency based on the actual version, potentially downgraded to the latest release version) Related-to: mesonbuild#14694
See mesonbuild#14756 (comment). When I changed Gentoo's binhost.git in a117703e74dfabc6972911504453c2492c11dead, I'd forgot that we match those settings in Meson's CI builder, so we've not been able to take advantage of the binpkg since then.
The check is currently broken as atomic_flag_clear is a macro, not a function. Change it to test linkage instead. Also test if atomics work with 64-bit types. On certain platforms like MIPS, external libatomic is needed. Signed-off-by: Rosen Penev <rosenp@gmail.com>
This reverts commit 60d0410. The rationale for making this change was bogus and misunderstands the purpose of the dependency. > The check is currently broken as atomic_flag_clear is a macro, not a > function. Change it to test linkage instead. ... does not make any sense since the standard requires it to be a function. We already test linkage. > Also test if atomics work with 64-bit types. On certain platforms like > MIPS, external libatomic is needed. ... misses the fact that we already check for external libatomic ***first***, for precisely this reason. That was in the original design of this dependency. Checking for more interesting forms of atomic usage is quite pointless. You can't write code that "requires" -latomic, as the toolchain may arbitrarily implement *anything* internally or else as a helper library, and we can't force it to do the latter. Instead, we: - check if the ISO header exists, and -latomic is a valid library. If so, assume it's needed. Maybe it is, maybe it isn't, -latomic can always be pruned by `-Wl,--as-needed` so we refuse to clutch pearls over it - if -latomic doesn't exist, smoketest that the toolchain has "some kind of atomic support". That is, the ISO header exists and one randomly chosen function successfully links. This is not intended to be comprehensive, it is a fallback. Notice that unlike most dependencies with a "builtin" method, we do NOT prefer the builtin! This is, again, because the ***primary purpose*** of `dependency('atomic')` is to handle the fact that you should always use -latomic if it exists. Okay, so why revert the change? Maybe it doesn't matter? Well... that's a problem, since it was never actually tested. The code fails with: ``` $ gcc -latomic -o /tmp/foo /tmp/foo.c In file included from /tmp/foo.c:1: /tmp/foo.c: In function ‘main’: /tmp/foo.c:5:30: error: ‘b’ undeclared (first use in this function) 5 | return atomic_fetch_add(&b, 1); | ^ /tmp/foo.c:5:30: note: each undeclared identifier is reported only once for each function it appears in ``` As it was never tested, we shall not assume it fixes a real world problem. But it sure does break the fallback.
ELD updated the output for `--version` flag qualcomm/eld#156 this commit updates detection for new output. Signed-off-by: Kushal Pal <kushpal@qti.qualcomm.com>
In get_option_std_args for the Intel C compiler, the requested command line flag is 'winlibs' which returns a list of strings of libs. It should be 'std' as in other adjacent classes, to return the particular value of the C standard desired.
As shown in the test, "-Dtests=true" should not override the subproject() call because tests is a project options and those do not share a namespace. Fixes: mesonbuild#14728 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove knowledge of the internal pending_options from msetup; operate on the command line and check against the option store. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reserve pending_options for those that could appear later in the configuration process. Options are added there only if accept_as_pending_option() is true. This is a preparation for changing the code so that it checks pending_options for subprojects as well. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fixes: 8dcc9d3 ("options: accept compiler and built-in options in --reconfigure and "meson configure"", 2025-05-21 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove all the special casing and late validation now that early augments are stored in pending_subproject_options until the subproject is found. As a result, this makes the buildtype special case operate on subprojects as well. It also simplifies set_from_configure_command(), which does not have to treat various kinds of options in different ways. Fixes: mesonbuild#14729 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Restore behavior of 1.7. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
…by subproject This is already done most of the time for default_library but not in these cases. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
New languages and subprojects can appear in subsequent configurations. Subproject options are kept for later now that they are not stored in pending_options, but compiler options for example are not. Drop OptionStore.clear_pending so that they are preserved as well. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fixes: mesonbuild#14774 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Go through the whole initialization and set_option process, and check that the option value is unaffected by the creation of a subproject. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently, when using frameworks on MacOS systems, Meson will send the appropriate flags to the linker but fails to pass flags to the compiler, resulting in the headers not being found for the included frameworks.
This patch adds the required "-F{framework}" flag to the compiler options, so that the compiler can find the headers of included frameworks.
See: mesonbuild#14641
…LAGS Commit 2d1c67f ("options: restore special behavior of CFLAGS vs. c_args", 2025-05-15) incorrectly checked the presence of c_link_args, and did not apply CFLAGS if c_link_args was set. This was not the behavior of 1.7, so remove the check. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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 <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Sometimes, a Rust static library's native static libs refer to libraries installed in the rustc target libdir. This is always the case for most musl targets (with the intention of making it easier to use them on non-musl systems), and other targets can also be configured to do this using e.g. the llvm-libunwind option when building the standard libraries for the target. When rustc is responsible for linking it will always add the appropriate directory to the linker search path, but if we're not using Rust for linking, we have to tell the linker about that directory ourselves. The added test demonstrates a scenario where this comes up: linking a static Rust library, built for musl, into a C executable. -lunwind is in the native static libs list from the compiler, but it's referring to the libunwind.a in the self-contained directory. (cherry picked from commit a01cede)
Omitting test()'s `suite` kwarg used to default to `test.suite==['']` because of how stringlistify() works. That had inconsistent behavior with `suite: []` which makes `test.suite==[]`. That changed when porting to typed_kwarg (mesonbuild#8855), which made the default `test.suite==[]`. Change `suite: []`, and missing kwarg, back to `test.suite==['']` which was the original intention. It has impact on `meson test --suite` selection, an empty `test.suite` list means that test is never going to be selected when `--suite` is used, even when we want all tests from a given subproject. It was also unclear what `--suite foo` means. Is `foo` a suite or a project name? It can now be either, it selects all tests from project `foo` as well as all tests from any project in suite `foo`. (cherry picked from commit 59a46da)
This makes easier to run a single test after running them all. For example the test "test_accsadubl" in the suite "default" of project "orc" used to be displayed "orc:default / test_accsadubl". To run that test specifically the command line is `meson test -C builddir orc:test_accsadubl --suite default`. To make this more consistent the test is now displayed as "default - orc:test_accsadubl". (cherry picked from commit 1d12e52)
If the first line already conained a match, the former regex didn't catch it correctly, because it was looking for a newline character to detect the start of a line. The new regex is using the proper `^` to match the beginning of a line. For this to work as expected the `re.MULTILINE` flag has to be set. (cherry picked from commit f314f68)
The previous commit eb1e52a introduced a variable `rebuild_only_tests` to fix various edge cases in rebuild_deps. In particular, if all tests are selected anyway, rebuild_deps prior to the introduction of `rebuild_only_tests` would potentially create a huge list of targets, which may overflow the ARG_MAX limit. For that case `rebuild_only_tests` was introduced and is set to an empty list, which means that rebuild_deps falls back to the `meson-test-prereq` ninja target, that already contains the necessary targets. This is wrong, though, when `meson test` is executed with the "--suite" option. In that case, the user requested a particular subset of the tests, but `rebuild_only_tests` will be set to an empty list anyway, which means the `meson-test-prereq` target is executed, which contains the targets for all tests. Instead, `rebuild_only_tests` should only be set to an empty list, when the selected tests are identical to the complete list of available tests: `tests == self.tests` Since after this commit we compare directly to the result of `self.get_tests()`, this will do the correct thing for all other options, which change or filter the list of selected tests (e.g. `self.options.args`, `self.options.slice`). (cherry picked from commit 18c1ce7)
Global objects are treated as UnknownValue(), but unlike other variables their object is created on every call to get_cur_value_if_defined() instead of coming from a dictionary. This causes the dataflow DAG to have multiple objects from the same object. Fix this by building the UnknownValues at interpreter construction time. Fixes: mesonbuild#15261 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 03a0926)
Respect collected sources for `meson init` as well as --executable. This regressed in 9f0ac31 (part of mesonbuild#14086, it's easier to see how with the whole PR). Also, add subtests (distinguishing between empty directories and those with some file(s) within). We already had some of these but they weren't marked as such. Test `meson init` with a broken source file in the source directory as we should fail with that, not ignore the file. It's easier to test with a broken file than a working one as we can assert the build should fail, it'll pass with just the 1 example file we generate. Closes: mesonbuild#15286 (cherry picked from commit 9104bb6)
Add error checks for cases in which the write target is unknown and ensure all error cases indeed abort the execution to avoid internal crash. Resolves mesonbuild#13502. Signed-off-by: Eyal Itkin <eyal.itkin@gmail.com> (cherry picked from commit 23657a4)
…andling too
That's how it is done in the other two places and without that one
argument too many is passed to the filter function:
```
[...]
File "/usr/lib/python3.14/site-packages/mesonbuild/wrap/wrap.py", line 607, in _get_file
shutil.unpack_archive(path, extract_dir)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.14/shutil.py", line 1432, in unpack_archive
func(filename, extract_dir, **kwargs)
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.14/shutil.py", line 1349, in _unpack_tarfile
tarobj.extractall(extract_dir, filter=filter)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.14/tarfile.py", line 2409, in extractall
tarinfo, unfiltered = self._get_extract_tarinfo(
~~~~~~~~~~~~~~~~~~~~~~~~~^
member, filter_function, path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.14/tarfile.py", line 2496, in _get_extract_tarinfo
filtered = filter_function(unfiltered, path)
TypeError: fully_trusted_filter() takes 2 positional arguments but 3 were given
```
(cherry picked from commit fad1d6e)
https: //github.com/actions/runner-images/issues/12045 (cherry picked from commit ea82dba)
Force multiline arguments when there is a trailing comma. This is the behavior of muon. Fixes mesonbuild#14721. (cherry picked from commit 0188454)
The group_arg_value option allow to put --key and its value on the same line on multiline arguments. However, when the options is `--`, it is an argument separator, and should not be grouped with the following argument. (cherry picked from commit 70b0de4)
Bug: https://bugs.gentoo.org/910572 (cherry picked from commit cdd6a3d)
This dates back to before we changed to Python 3.12 default in Gentoo. I don't remember why we specifically wanted/needed 3.12 in the CI builder though (maybe something to do with distutils removal to test that). The Python changes here shouldn't make much difference to binpkg eligibility right now because the binhost has a double builder for old targets, though it won't cover everything. Signed-off-by: Sam James <sam@gentoo.org> (cherry picked from commit aac2f82)
By doing some cleanups here, we can now use a binpkg for dev-build/b2 and often dev-libs/boost. Signed-off-by: Sam James <sam@gentoo.org> (cherry picked from commit 76cec64)
Gentoo does a weirdo thing where you cannot detect vala without setting an environment variable. It's usually only set in ebuild recipes, and vala simply does not work on Gentoo at all, period, end of story, outside of that. Capitulate, and parse the output of portage to find the most recent vala installed and export that directly into meson's binary table lookup. We aren't interested in whether *Gentoo* works with Vala, we are interested in finding out whether newly packaged vala versions in Gentoo are compatible with meson. Bug: https://bugs.gentoo.org/513658 (cherry picked from commit d4c9536)
We've been using the desktop profile until now, mostly because it automatically provides various frameworks we test e.g. wayland, gtk, qt etc that all install out of the box. It also guarantees that binpackages match. The image is also really fat though. :( Switch to the base profile, install a few packages that otherwise wouldn't be installed, and tweak individual USE flags for binary coverage. (cherry picked from commit f517487)
Currently what this does is permit freethreaded builds, which are stablemasked but not masked, which means we get a binpackage cache miss for something we frankly very much do not care about at all. We can and do unmask implementations themselves later on in this file, which should handle all this for us anyway. (cherry picked from commit af27c36)
(cherry picked from commit 1a71f91)
Stable HDF5 has a fixed .pc file, but we need to enable hdf5[cxx] for H5Cpp.h. (cherry picked from commit 79fa009)
See https://forums.opensuse.org/t/cant-find-libboost-system-devel-dependency/188865. (cherry picked from commit 2189ab0)
(cherry picked from commit f4650db)
``` emerge: there are no ebuilds built with USE flags to satisfy ">=media-libs/freetype-2.5.0.1:2[harfbuzz,png,abi_x86_64(-)]". !!! One of the following packages is required to complete your request: - media-libs/freetype-2.14.1-r1::gentoo (Change USE: +harfbuzz) (dependency required by "x11-libs/pango-1.57.0::gentoo" [binary]) (dependency required by "gnome-base/librsvg-2.60.0::gentoo" [binary]) (dependency required by "x11-themes/adwaita-icon-theme-legacy-46.2::gentoo" [binary]) (dependency required by "x11-themes/adwaita-icon-theme-48.1::gentoo" [binary]) (dependency required by "x11-libs/gtk+-3.24.51::gentoo" [binary]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) ``` This comes from the change we made now that the FT<->HB cycle is gone where pango now unconditionally depends on freetype[harfbuzz] because it's janky at runtime otherwise. Bug: https://bugs.gentoo.org/712374 Bug: https://bugs.gentoo.org/962715 Signed-off-by: Sam James <sam@gentoo.org> (cherry picked from commit e38b2e8)
Member
Author
|
CI on numpy/numpy#30553 is happy, so I'll merge this so I can update that PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
No description provided.