| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
We're only interested in the keys, not in the value (which was always
set to True), so a set is a better data structure anyway.
|
|
|
|
instead of opencoding what should be there in the rust compile rule
|
|
We have code to support this, but no tests. That seems pretty bad.
And better yet, it doesn't work on MSVC in some cases.
|
|
The correct name is "dylib" not "shared"
|
|
When pch are used for a target meson will make the compiler to include
the pre-compiled header. While this is useful, this needs to happen
before any other header has been included, otherwise:
1) we won't take advantage of pch for anything else previously included
2) gcc will just fail as it won't even try to look for a pre-compiled
header in this case [1]
This case can happen quite a easily when a dependency provides an
included header in its cflags.
As per this, split _generate_single_compile() in two phases, one is
responsible of initializing the compiler data, while the other is
defining commands for the context.
In this way, when pch can be used, we can insert the pch inclusion
earlier than any other provided by the target.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
|
|
|
|
|
|
|
|
|
|
This also makes us of the new enum value in the backend, for better type
saftey.
|
|
Take into account LDC on Windows
Fixes #8494
|
|
|
|
performed by running "pyupgrade --py36-plus" and committing the results
|
|
I made an incorrect assumption that -l arguments would always be static
libraries, but they might well be shared libraries.
|
|
This is a little cleaner, and short circuits correctly, unlike the loop
it replaces
|
|
Rust can link with any dependency that uses c linkage, which is pretty
much what we assume across the board anyway.
|
|
|
|
|
|
Even if the command is not wrapped by meson, it could have been modified
to add java/mono interpreters. This fix potential inconsistency between
wrapped and unwrapped commands.
|
|
|
|
Add a wrapper to the rust module for bindgen
|
|
run_target: Add env kwarg
|
|
|
|
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.
|
|
It is already checked by as_meson_exe_cmdline().
|
|
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.
|
|
Move helper functions get_source_dir_include_args and
get_build_dir_include_args to backend base class
|
|
|
|
dcbaker/submit/rust-fix-generated-sources-in-subdir
Submit/rust fix generated sources in subdir
|
|
Fixes for fortran: Include dirs for link_whole_targets and capital file suffix
|
|
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.
|
|
This was missed in the last iteration of fixing things.
|
|
The `determine_ext_objs` function did not take into account that fortran
(and d) does not support unity builds. This caused failures in some
cases.
|
|
[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>
|
|
This fixes fortran includes and fortran orderdeps for libraries that
were under link_whole_targets.
|
|
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.
|
|
There's starting to be a lot of things including coredata that coredata
needs to itself include. putting it in mesonlib makes more sense
|
|
|
|
|
|
|
|
|
