Currently default_options uses "" for the kwarks id, however this
is incorect and it must be "/". Additionally, this error won't be
ignored in the future with "--skip" (this is why the tests were
passing and this wasn't detected earlier).
when we are generating the include directories for a build target, then
we are iterating over all include directories, check if they are . or ..
and if not, generate a compile args object for it. However, the join
calls and the generation of the compile object is quite expensive, if we
cache the results of this, then we can _generate_single_compile from 60%
to roughly 50%.
the problem here is, that get_custom_target_provided_libraries iterated
over all generated sources of a target. In each output we check if this
is a library or not. In projects like EFL we have added a lot of
generated target to many different targets, so the iterating of the
output is rather consistent, with this commit we drop from 19% of the
time spending in get_custom_target_provided_libraries down to 3.51%.
this is better, but it's still not perfect. cmake doesn't return quotes
to us in the trace output, and being 100% the same as cmake is pretty
much impossible without that information. What I've done should be a
"good enough" implementation without having to maintain a copy of every
property allowed in cmake, as well as custom properties.
determine_rpath_dirs() can return paths to external dependencies not
in the build dir and passing them first as a link path leads to
g-ir-scanner for example linking against the already installed library
instead of the just built one.
This was reported in g-i: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/272
and comes up quite often when a library adds some new symbols which aren't present in the
system library, which then makes linking fail.
The first place where the order is changed is _scan_gir_targets(), which looks like an unintentional
change in the refactoring in 8377ea45aa
The second place in _get_link_args() has always been that way and only the rpath order is changed,
but it looks to me as if the same rules should apply here too.
The host environment could change between the time "meson setup"
produces intro-tests.json, and the time "meson test" is run.
Including it only adds clutter to the introspection data.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It turns out that llvm-config on windows can return such wonderful
output as `-LIBDIR:c:\\... c:\\abslute\\path\\to\\lib.lib`, which was
all fine and dandy when we were blindly passing it through, GCC/MinGW
ignored it and MSVC understood it meant `/LIBDIR:`; however, after we
added some code to validate linker arguments, and we have some code
before the validation that tries to remove posix style -L arguments,
resulting in IBDIR:..., which doesn't validate.
This patch fixes up the output of llvm-config so that -LIBDIR: is
replaced by the the link libdir argument of the compiler, via the
compiler/linker method for getting that.
Fixes#5419
In QEMU a single set of source files is built against many different
configurations in order to generate many executable. Each executable
includes a different but overlapping subset of the source files; some
of the files are compiled separately for each output, others are
compiled just once.
Using Makefiles, this is achieved with a complicated mechanism involving
a combination of non-recursive and recursive make; Meson can do better,
but because there are hundreds of such conditional rules, it's important
to keep meson.build files brief and easy to follow. Therefore, this
commit adds a new module to satisfy this use case while preserving
Meson's declarative nature.
Configurations are mapped to a configuration_data object, and a new
"source set" object is used to store all the rules, and then retrieve
the desired set of sources together with their dependencies.
The test case shows how extract_objects can be used to satisfy both
cases, i.e. when the object files are shared across targets and when
they have to be separate. In the real-world case, a project would use
two source set objects for the two cases and then do
"executable(..., sources: ... , objects: ...)". The next commit
adds such an example.
Switch from build.compiler to environment.coredata.compiler and likewise
from build.cross_compiler to environment.coredata.cross_compiler in
backends. (Only seems to be actually used in ninja backend).
It doesn't make much sense to have this and not also have
cross-compilers (so any use of this is already pretty suspect as
probably wrong when cross-compiling).
This information is accessible anyhow via environment.coredata.
Handling the PKG_CONFIG_PATH variable in meson introduces a new problem
for caching dependencies. We want to encode the pkg_config_path (or
cross_pkg_config_path if we're cross compiling) to be part of the key,
but we don't want to put that into the key for non-pkg-config
dependencies to avoid spurious cache misses (since pkg_config_path isn't
relevant to cmake, for example). However, on a cache lookup we can't
know that a dependency is a pkg-config dependency until we've looked in
the cache.
My solution is a two layer cache, the first layer remains the same as
before, the second layer is a dict-like object that encapsulates the
dependency type information and uses pkg_config_path and
cross_pkg_config_path as a sub key (and could be extended easily for
other types). A new object type is introduced to encapsulate this so
that callers don't need to be aware of the implementation details.
It was using ':' as a path separator while GCC uses ';' resulting in bogus
paths being returned. Instead assume that the compiler uses the platform native
separator.
The previous splitting code still worked sometimes because splitting
"C:/foo;C:/bar" resulted in the last part "/bar" being valid if "<DriveOfCWD>:/bar"
existed.
The fix also exposes a clang Windows bug where it uses the wrong separator:
https://reviews.llvm.org/D61121 . Use a regex to fix those first.
This resulted in linker errors when statically linking against a library which
had an external dependency linking against system libs.
Fixes#5386
Currently this test assumes that the user doesn't have XDG_DATA_HOME
set in their path, but this isn't a good assumption, and can result in
the test not actually testing what it means to.
Apparently we have no tests for this because this is broken pretty
badly. This extends the basic test to actually check for the correct
free-form argument and thus test this.
Jussi Pakkanen
John Ericson
John Ericson
Dylan Baker
Daniel Mensinger
Marcel Hollerbach
Markus Theil
Eli Schwartz
Michael Hirsch, Ph.D
Mathieu Duponchelle
Christoph Reiter
Paolo Bonzini
Joel Rosdahl
Erik Faye-Lund
Luís Ferreira
Federico Mena Quintero
Jon Turney
Szunti