Our approach to unity builds with vala is broken, you cannot unify the
generated C files, as they contain duplicate symbols. We would need to
instead combine the files while they are still in their vala form, then
convert that to C and compile the unified C file.
This does not fix the linked issue, as this removed the ability to do
vala unity builds, but it does allow running vala with `--unity=on`.
Related: #5280
Replacements are already done by eval_custom_target_command() and must
be done BEFORE calling as_meson_exe_cmdline() anyway. replace_paths() is
still used by generators.
Make eval_custom_target_command() more readable by handling error in the
final else case instead of in the middle of elif.
Re-implement it in backend using the same code path as for
custom_target(). This for example handle setting PATH on Windows when
command is an executable.
Currently mesonlib does some import tricks to figure out whether it
needs to use windows or posix specific functions. This is a little
hacky, but works fine. However, the way the typing stubs are implemented
for the msvcrt and fnctl modules will cause mypy to fail on the other
platform, since the functions are not implemented.
To aleviate this (and for slightly cleaner design), I've split mesonlib
into a pacakge with three modules. A universal module contains all of
the platform agnositc code, a win32 module contains window specific
code, a posix module contains the posix specific code, and a platform
module contains no-op implementations. Then the package's __init__ file
imports all of the universal functions and all of the functions from the
approriate platform module, or the no-op versions as fallbacks. This
makes mypy happy, and avoids `if`ing all over the code to switch between
the platform specific code.
[why]
If we build and test a library we need to make sure that we find the
currently build library object first, before an older system installed
one.
This can be broken if the library in question is installed in a custom
path, and another library we depend on also is installed there.
[how]
Just move the rpath to the current build artifacts to the front.
Solves #8030.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
In Fortran it is common to use capital F in the suffix (eg. '.F90') if
the source file makes use of preprocessor statements. Such files should
probably be treated like all other fortran files by meson.
Case insensitivity for suffixes was already implemented several places
in meson before this. So most likely, the few places changed here were
oversights anyway.
There are still caveats here. Rust/cargo handles generated sources by
writing out all targets of a single repo into a single output directory,
setting a path to that via a build-time environment variable, and then
include those files via a set of functions and macros. Meson's build
layout is naturally different, and ninja makes working with environment
variables at compile time difficult.
Fixes#8157
we have two functions to do the exact same thing, and they're basically
implemented the same way. Instead, let's just use the BuildTarget one,
as it's more generally available.
This patches takes the options work to it's logical conclusion: A single
flat dictionary of OptionKey: UserOptions. This allows us to simplify a
large number of cases, as we don't need to check if an option is in this
dict or that one (or any of 5 or 6, actually).
I would have prefered to do these seperatately, but they are combined in
some cases, so it was much easier to convert them together.
this eliminates the builtins_per_machine dict, as it's duplicated with
the OptionKey's machine parameter.
These do not go into the command line, and therefore do not matter
for the purpose of avoiding unnecessary rebuilds after meson is
rerun. However, they complicate the task of finding differences
between build lines across meson reruns.
So take the easy way out and sort everything after | and ||.
With this change, there is absolutely no change in QEMU's 40000-line
build.ninja file after meson is rerun.
There are two bugs here, first is that we open coded the output args,
instead of using the compiler method. The second is that rust args are
not passed down to the backend invocation.
Using the std option, so now `rust_std=..` will work. I've chosen to use
"std" even though rust calls these "editions", as meson refers to
language versions as "standards", which makes meson feel more uniform,
and be less surprising.
Fixes: #5100
I've always found ninja reporting 'a meson_exe.py custom command'
unclear and confusing. Instead say we are invoking a custom command,
wrapped by meson, and why.
Jussi Pakkanen
Dylan Baker
Xavier Claessens
Jeff Moguillansky
Jonas Lundholm Bertelsen
Fini Jastrow
Samuel Longchamps
Laurin-Luis Lehning
Paolo Bonzini
Alexander Neumann
Daniel Mensinger
Jon Turney
Martin Storsjö