| Age | Commit message (Collapse) | Author |
|---|
|
GeneratedList does not need the full interpreter, only the source
and build directories which can be found in Environment.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
There is no generator list in the Interpreter.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
When a structured source contains non rust files, the backend may select
such a file to treat as the main file. That doesn't work obviously, so
instead filter the main file such that it must be a rust file.
|
|
This reverts https://github.com/mesonbuild/meson/pull/15107
Explicit objections regarding the design were raised and not answered,
so it shouldn't have been merged. It needs to be discussed and
revisited.
|
|
This just prevents some unintended instances of values become None, now
they always remain strings or literal-strings
|
|
|
|
There is some validation going on here that cannot (currently) be done
the KwargInfo validators, namely that the files exist. Additionally,
BuildTarget.extra_files is doing some membership checking for dups,
which means it should probably be an OrderedSet instead of a list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's a smell for `BuildTarget` to be checking if it's a `StaticLibrary`
and then doing code. This also allows us to tighten the type checking a
bit.
|
|
There's really no reason to not do this in the `_extract_pic_pie` helper,
it only increases the chance of us not doing this when we should.
|
|
|
|
We have type checking, we also have interpreter level validation from
the DSL, we don't need this.
|
|
|
|
This includes cleaning up some of the type handling to account for
cleanups that are done at the DSL level.
|
|
This just does what would happen later, but with the potential to fail
in obscure way.
|
|
|
|
This reverts commit 93c11f249495c4af4a88206cebefef3ecf0f3228.
We're going to use it again in the next commit
|
|
The Interpreter has been merging gui_app and win_subsystem for a while,
but now with the typed kwargs we can feel more comfortable that gui_app
wont get passed through beneath us
|
|
|
|
|
|
|
|
|
|
This has the "processed" keyword arguments that the interpreter is
supposed to create for us, or that we expect internal users to build by
build.
This requires some hacking around in the rust module for the moment
because we suddenly have a type.
|
|
This is the only caller, so there's no reason to not do this.
|
|
This fixes the following error occured in the test 3 of the Emscripten
build.
> wasm-ld: error: unable to find library -llibvalue.a
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Meson sets 64-bit offsets as the default for all platforms but MSVC.
Lets do the same for bindgen, to ensure we get compatible definitions.
Do this by calling `get_always_args()` on the first C'ish host compiler
we can find.
Note that the `libc` crate does not expose 64-bit types as the default
and there is no intention to do so. Instead, it exposes 32-bit default
types, plus the 64-bit extended types with the `*64` suffix. This is
quite unfortunate, but it seems unlikely to change [1].
However, use of `bindgen` is usually not tied to the `libc` crate.
Instead, it is tied to whatever other C code in the same project does.
And Meson sets `_FILE_OFFSET_BITS=64` unconditionally for all this C
code. It thus seems much more plausible for Meson to also imply it for
bindgen.
Given that Rust code that uses the `libc` crate very likely already uses
the `*64` suffixed variants, they are unaffected by whether
`_FILE_OFFSET_BITS=64` is set. If they use `libc::off_t`, they already
explicitly state that they use the 32-bit variant on 32-bit platforms.
Hence, it is inherently incompatible to C code that uses
`_FILE_OFFSET_BITS=64`.
And lastly, if a Meson project is Rust-only, but generates its internal
code from its public C headers, then it is better suited to actually
call `add_language('c')` and ensure that Meson knows what the compiler
configuration for the target platform actually is. Otherwise, bindgen
cannot know what platform options to enable. Hence, warn loudly if
`rust.bindgen()` is used without a configured C compiler (even if the
compiler used by bindgen does not necessarily match the configured one).
[1] https://github.com/rust-lang/libc/issues/3223#issuecomment-2033298952
|
|
Extracted from a patch by Xavier Claessens <xclaessens@netflix.com>
|
|
A dependency might specify a version that is compatible with the one
in Cargo.lock, but not the exact same version. Whenever Cargo.lock
contains the package, only use the pinned versions that can be used;
update the version in the manifest so that the correct API level is
used as well.
Originally by Xavier Claessens <xclaessens@netflix.com>, but
almost completely rewritten.
|
