Some things, like `method[...](...)` or `x: ... = ...` python 3.5
doesn't support, so I made a comment instead with the intention that it
can someday be made into a real annotation.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
Now, all source files are ignored that are not part of the
language of the target. This is also what CMake does.
Additionally it is now supported to build source files that
are generated inside the build directory.
When the media file for a specific language doesn't exist we try to symlink
it to the C one. If symlinking fails we need to fall back to copying the C
one like in the non-symlink case.
The fallback code path didn't set the source so this always failed.
Also check if the C fallback exists before trying to symlink/copy, otherwise
we crash if C isn't the first lang we try.
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>
sompen
Dan Kegel
John Ericson
John Ericson
Daniel Mensinger
filippocrocchini
Christoph Reiter
Dylan Baker
Marcel Hollerbach
Markus Theil
Michael Hirsch, Ph.D
Mathieu Duponchelle
Paolo Bonzini