Age | Commit message (Collapse) | Author | Files | Lines |
|
Allows explicitly setting the Swift module name. By default, this is set
to the target name, which we might want to change for various reasons,
for example when it isn't a valid module name, or when building two
targets with the same module name (e.g. a host and native variant).
|
|
|
|
|
|
When arrays were added they were called arrays. Because the are
implemented with Python lists, that language started leaking into
talking about Meson types. This is confusing. I've attempted, as much as
possible, to move to using one name, array. I picked array because 1)
It's the original name used, and 2) what Meson has are more properly
arrays as they have a fixed length, while a critical property of lists
are the ability to link and unlink them.
There are a couple of places where the list language has leaked into the
names of keyword arguments. I have not made any attempt to change those,
I don't know if it's that useful or not.
|
|
clang-tidy can't be ran as is on every source file and header
|
|
This allows users to do two things, flatten potentially nested arrays
themselves, and, to safely convert types that may be an array to not an
array.
```meson
x = [meson.get_external_property('may_be_array)].flatten()
```
```meson
x = ['a', ['b', 'c']]
assert(x.flatten() == ['a', 'b', 'c'])
```
|
|
|
|
As an initial implementation, simply adding "-C prefer-dynamic" works
for binary crates (as well as dylib and proc-macro that already used it).
In the future this could be extended to other crate types. For more
information see the comment in the changed file, as well as
https://github.com/mesonbuild/meson/issues/8828 and
https://github.com/mesonbuild/meson/issues/14215.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
|
|
|
|
gdbus-docgen supports reStructuredText output since 2.71.1 and markdown
since 2.75.2, allow to simply generate it.
|
|
|
|
Update reference table for eld
Mention eld support in release notes
Signed-off-by: Kushal Pal <kushpal@qti.qualcomm.com>
|
|
|
|
See https://github.com/mesonbuild/meson/pull/14391
|
|
|
|
|
|
|
|
Sync with the English version
|
|
Fixes #14270.
|
|
See the way that it is created:
dir_node = assign(dir_var, function(include_directories, tgt.includes))
sys_node = assign(sys_var, function(include_directories, tgt.sys_includes, {is_system: True}))
inc_node = assign(inc_var, array([id_node(dir_var), id_node(sys_var)]))
Due to incorrect documentation, commit 1f4bb3737 ("modules/cmake: Make fully type
safe", 2025-04-02) added an incorrect assertion. Fix both.
Fixes: #14530
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reflects the upstream project, which dropped the + in 2020
|
|
This removes a lot of projects from our list of users, unless they are
very notable.
|
|
|
|
Some of the projects listed are part of larger umbrella organizations,
which have many project using Meson. Instead of listing every single
project from them, list the organization itself and a couple of major
projects (if we have any listed) from those organizations.
|
|
As of this commit, meson has three different
pathways to set an exe_wrapper field.
exe_wrapper set through `meson test --wrapper`
CLI arg or `add_test_setup()` meson function argument
are treated equally. Only one wrapper through either
of these routes may be set though.
The exe_wrapper field set in the cross file is handled
separately internally in mtest.py, and holds a little
more consequence over meson test behavior than the other
two fields.
Perhaps a future version of meson should treat these
fields equally and explicitly document how they are
combined.
For now, I think its a better first step to
document current behavior to generate discussion about
how exactly the future version should behave.
|
|
|
|
|
|
|
|
We don't want churn with thie list for every project someone creates
that uses Meson. Change the intro to say we want notable projects and
link to a GitHub search for 'meson.build' files for people who want
further examples to consider.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All of iOS, tvOS, visionOS, watchOS use the XNU kernel. Report that and also
make them return true for is_darwin() which is really more like "is_xnu()".
Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
This method call xgettext to extract translatable
string from source files into a .pot translation template.
It differs from a plain CustomTarget in three ways:
- It accepts build targets as sources, and automatically resolves source
files from those build targets;
- It detects command lines that are too long, and writes, at config
time, the list of source files into a text file to be consumed by the
xgettext command;
- It detects dependencies between pot extraction targets, based on the
dependencies between source targets.
|
|
|
|
|
|
|
|
We document --wrapper and --wrap works only by expanding it automatically
to --wrapper as it is unambiguous.
|
|
Because rustc does not support extract_objects, QEMU creates a static library
with all the C objects. It then passes this static library as link_whole,
together with another static library containing general purpose utility
functions which is passed as link_with.
However, this is brittle because the two have a circular dependency and
they cannot be merged because of the link_whole/link_with difference.
While lld seems to have the --start-group/--end-group semantics
automatically, ld.bfd can fail if these options are needed. This can
cause difference between distros depending on how Rust is packaged
(e.g. Ubuntu 22.04 and Debian bookworm seem to use ld.bfd).
The simplest solution is for Meson to implement "objects:" properly
for Rust. Then QEMU can use the same internal dependency objects that it
already has in place for C programs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
sort_files has always defaulted to true.
Fixes: 2b37101998c8 ("meson format command")
|
|
We currently suggest that users run `meson test --wrapper valgrind`, but
this doesn't do what one might expect: Valgrind doesn't error out on
violations/issues it detects.
In the past, we had special handling for Valgrind in tests, see
1f76b76a84cb635f764ecbd2b77aaba1d375d72b but it was later dropped in
951262d7590343ffa9730666c427ad9d708a9fb6.
This is similar to what we do for {A,UB,M}SAN_OPTIONS to give sensible
behaviour that users expect out-of-the-box.
Only do this if we see 'valgrind' in the wrapper command to avoid
polluting logs. We may want to do that for the sanitizers variables
in future too.
Note that we're not adding --exit-on-first-error=yes here, as there
may be several issues in an application, or a test may be rather slow,
and so on. But --error-exitcode=1 to simply make Valgrind's exit status
reflect whether an error was found is uncontroversial.
Bug: https://github.com/mesonbuild/meson/issues/4727
Bug: https://github.com/mesonbuild/meson/issues/1105
Bug: https://github.com/mesonbuild/meson/issues/1175
Bug: https://github.com/mesonbuild/meson/issues/13745
|