| Age | Commit message (Collapse) | Author |
|---|
|
validate_original_args only checks whether an option is prefixed with the name of a
built-in option that was also set. It does not check whether the prefix is the full
name of the option specified with -D. Adding an "=" at the end fixes the test.
Fixes: #14487
Reported-by: Alyssa Ross <hi@alyssa.is>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
By setting android_exe_type to `application`, the executable gets
actually built as a shared library instead of an executable. This makes
it possible to use an application within an android application process.
mesonbuild#13758
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7555/
|
|
|
|
|
|
If the user specifies java sources as input to a non-jar build
target, raise an error with a message directing them to use the jar
target instead.
Fixes: https://github.com/mesonbuild/meson/issues/13870
|
|
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.
|
|
Cover ":foo" syntax in default_options as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This actually tests the handling of deprecated options
when passed to meson instead of just as default_options.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
"prefix" has a lot of special handling that has to go on because so many
other options depend on prefix. It was also regressed by the option
refactor changes, so having a test feels appropriate.
This was verified against the 1.7 release, so it has the same behavior
as pre-option refactor Meson.
|
|
Don't add "<project_source_dir>/<subproject>/__CMake_build" directory
to include directories.
Fixes #12351
|
|
Since dmd frontend version 2.111 integer debug and version statements
error during parsing:
https://dlang.org/changelog/2.111.0.html#dmd.deprecation-version-debug-number
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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>
|
|
This was broken twice, so check that it does not regress.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Since the comment saying we need a generic way to do this is a little
outdated.
|
|
We already test for custom_targets and configure_file, but we should
test a generator too
|
|
|
|
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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: https://github.com/apache/arrow/issues/36411
|
|
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 <a.horodniceanu@proton.me>
|
|
In the preceding commit we have started to perform compiler checks for
the value of `b_sanitize`, which allows us to detect sanitizers that
aren't supported by the compiler toolchain. But we haven't yet loosened
the option itself to accept arbitrary values, so until now it's still
only possible to pass sanitizer combinations known by Meson, which is
quite restrictive.
Lift that restriction by adapting the `b_sanitize` option to become a
free-form array. Like this, users can pass whatever combination of
comma-separated sanitizers to Meson, which will then figure out whether
that combination is supported via the compiler checks. This lifts a
couple of restrictions and makes the supporting infrastructure way more
future proof.
A couple of notes regarding backwards compatibility:
- All previous values of `b_sanitize` will remain valid as the syntax
for free-form array values and valid combo choices is the same. We
also treat 'none' specially so that we know to convert it into an
empty array.
- Even though the option has been converted into a free-form array,
callers of `get_option('b_sanitize')` continue to get a string as
value. We may eventually want to introduce a kwarg to alter this
behaviour, but for now it is expected to be good enough for most use
cases.
Fixes #8283
Fixes #7761
Fixes #5154
Fixes #1582
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
The current approach of determining dub dependencies is by specifying
a name and, optionally, a version. Dub will then be called to generate
a json summary of the package and code in meson will parse that and
extract relevant information. This can be insufficient because dub
packages can provide multiple configurations for multiple use-cases,
examples include providing a configuration for an executable and a
configuration for a library. As a practical example, the dub package
itself provides an application configuration and multiple library
configurations, the json description of dub will, by default, be for
the application configuration which will make dub as a library
unusable in meson.
This can be solved without modifying the meson build interface by
having dub describe the entire local project and collecting
dependencies information from that. This way dub will generate
information based on the project's 'dub.json' file, which is free to
require dependencies in any way accepted by dub, by specifying
configurations, by modifying compilation flags etc. This is all
transparent to meson as dub's main purpose is to provide a path to the
library file generated by the dependency in addition to other
command-line arguments for the compiler.
This change will, however, require that projects that want to build
with meson also provided a 'dub.json' file in which dependency
information is recorded. Failure to do so will not break existing
projects that didn't use a 'dub.json', but they will be limited to
what the previous implementation offered. Projects that already have a
'dub.json' should be fine, so long as the file is valid and the
information in it matches the one in 'meson.build'. For example for a
'dependency()' call in 'meson.build' that dependency must exist in
'dub.json', otherwise the call will now fail when it worked
previously.
Using a 'dub.json' also has as a consequence that the version of the
dependencies that are found are the ones specified in
'dub.selections.json', which can be helpful for projects that already
provide a 'dub.json' in addition to 'meson.build' to de-duplicate code.
In terms of other code changes:
- multiple version requirements for a dub dependency now work, though
they can only be used when a 'dub.json' is present in which case the
version of dependencies is already pinned by 'dub.selections.json'
- the 'd/11 dub' test case has been changed to auto-generate the
'dub.json' config outside of the source directory, as the
auto-generated file triggers warning when parsed by dub, which upsets
the new code as the warnings interfere with the legitimate output.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
|
|
Which was improperly updated by the option store refactor.
Fixes: #14329
|
|
Add the support for the doc-format argument if g-ir-scanner supports it.
Ignore the argument otherwise as this is a no-op in such cases.
|
|
|
|
We check to see if a test extension exists, and if so add its path to
sys.path... immediately before unconditionally importing it, obviously.
This raises the question: why bother checking? Can it ever fail? What if
it does fail, do we simply not add path entries and then expect the rest
of the test file to work??? The whole thing seems silly and useless.
In fact it can fail, if the python interpreter and/or standard library
is broken. This is the case for the initial release of PyPy 3.11, in
which `'*tachyon*'` fails to glob correctly (and `'tachyon*'` would
work, funnily enough -- this is valid too for our use case although
still just as pointless).
Delete the useless check. It's technically correct to delete it, and it
*also* works around the PyPy breakage as a bonus.
Closes: https://github.com/mesonbuild/meson/issues/14307
|
|
|
|
When running tests with `--interactive` we don't redirect stdin, stdout
or stderr and instead pass them on to the user's console. This redirect
causes us to hang in case the test in question needs parsing, like it is
the case for TAP output, because we cannot read the process's stdout.
Fix this hang by not parsing output when running in interactive mode.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
Executing tests can take a very long time. As an example, the Git test
suite on Windows takes around 4 hours to execute. The Git project has
been working around the issue by splitting up CI jobs into multiple
slices: one job creates the build artifacts, and then we spawn N test
jobs with those artifacts, where each test job executes 1/Nth of the
tests.
This can be scripted rather easily by using `meson test --list`,
selecting every Nth line, but there may be other projects that have a
similar need. Wire up a new option "--slice i/n" to `meson test` that
does implements this logic.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
|
|
When supplying -Wno-vla-larger-than to compiler.get_supported_arguments,
meson will inject -Wvla-larger-than as an argument which considered
invalid by GCC, as the converse argument is -Wvla-larger-than=<value>.
Just like CLikeCompiler._has_multi_arguments special-cases
-Wno-attributes=, do the same for -Wno-vla-larger-than.
Resolves: https://github.com/mesonbuild/meson/issues/14208
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
Some dependencies can bring include paths pointing to older macOS SDK's.
In this case, it was libffi pointing to SDK from 12.0. When the
Foundation
framework is imported in Swift, swiftc attempts to import the FFI module
from the most recent version of the SDK, which causes a compilation
error
because of conflicting definitions between the two SDK versions.
SwiftPM also had this problem:
https://github.com/swiftlang/swift-package-manager/pull/6772
The solution on our side is a simplified version of what SwiftPM did.
Let's naively look for .sdk paths in the compile args of our
dependencies
and replace them with the most recent one.
I included a test which is confirmed to fail without the workaround
added in this patch. This was not tested on anything else than macOS,
but I don't expect it to make the situation worse in any case.
|
|
Support lists for ObjC and ObjC++ standards
|
|
Where it is now working.
|
|
Which doesn't work with the packaged version of Vala
|
|
This tests ObjC and ObjC++ both with and without C enabled. I did this
because I ran into issues where ObjC only worked when C was enabled, and
then a later bug where C was disabled, due to the fact that C and ObjC
both use `c_std` and not `objc_std`.
|
|
|
|
This reverts commit 82fedf04033305e2b28db1eea2346018c237d167.
|
|
rpaths are calculated in bytes, and that's also how depfixer processes
them. We need to ensure that the ascii padding we use (bytes == unicode)
is the correct offset for the install rpath - build rpath (both
specified in unicode which then gets converted to bytes).
In the event of a unicode install_rpath, we can get into a situation
where the install rpath is longer than the padding, since we assumed
that the install_rpath was shorter than it actually is -- because we
counted the length in characters instead of the length in bytes.
This then broke installation for people who e.g. install into a prefix
inside their home directory, when their home directory contains
multibyte unicode characters.
Bug: https://gitlab.gnome.org/GNOME/gnome-builder/-/issues/2280
|
|
Add an exception to the disabler check to allow objects with a `get_variable`
method to not always pick a disabler if their arguments contain one. This
mimics the behaviour already in place for calls to function, which has a set
of excepted functions.
Closes #13717
Signed-off-by: Andrew McNulty <amcn102@gmail.com>
|
|
#13837 broke both_lib transitive deps, because the
`as_static` and `as_shared` functions return libraries
that still contain references to the other lib type.
|
|
|
|
Qml modules
|
|
|
|
|
|
Inconsistency in the original implementation of commit
79e2c52a15e896e46ff3cfa3ec16fbf3f132ee01.
If an explicit list of targets is passed on the CLI, then that is passed
to rebuild_deps. If not, we pass every loaded test to rebuild_deps
instead. This means we cannot distinguish between "trying to run all
tests" and "trying to run specific tests". We then load all the deps for
all tests, and try to build them all as explicit arguments to the
underlying ninja.
There are two situations where this falls flat:
- given underspecified deps
- given all (selected?) tests legitimately happen to have no
dependencies
In both cases, we calculate that there are no deps to rebuild, we run
ninja without any targets, and this invokes the default "all" rule and
maybe builds a few thousand targets that this specific test run does not
need.
Additionally, in large projects which define many tests with many
dependencies, we could end up overflowing ARG_MAX when processing *all*
tests.
Instead, pass no tests to rebuild_deps. We then specially handle this by
directly running the relevant ninja target for "all test deps", which is
overall more elegant than specifying many many dependencies by name.
Given a subset of tests to guarantee the freshness of, we instead skip
running ninja at all if there are indeed no test dependencies.
|
