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.
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.
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.
For dynamic linking, some mingw releases don't link
correctly with pythonXX.lib in all cases.
This patch forces mingw to link against
pyhthonXX.dll instead of the .lib file, which has
a better compatiblity.
Note that msys 1.0 old platform is detected
as windows instead of 'mingw'
@permittedKwargs() is basically copying the logic of CustomTarget,
but it is not actually up to date, leading to warnings on perfectly
valid values such as 'build_by_default'.
Use CustomTarget.known_kwargs instead, and only append the specific
kwargs of i18n.merge_file().
Fixes https://github.com/mesonbuild/meson/issues/5079
The documentation for this change was left out of its implementation in
commit b4aee4675a and was later documented
in commit f831c05b55 as if it had always
existed.
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
When using pkg.generate(mylib, library : publicdep) it is pretty clear
we don't want to associate publicdep to this generated pkg-config file.
This is a small behaviour break in theory, but also fixes real bug in
the case publicdep is later used to generate another pkg-config file
that does not depend on mylib, that would write a wrong `Requires:
mylib` in the genarated pkg-config file.
This fix unavoidable deprecation warning when glib is cross built
for Android. Glib does `pkg.generate(libglib, libraries : [libintl],
...)` which wrongly associates libintl to the generated glib-2.0.pc, so
when later it generates gio-2.0.pc file that depends on libglib, it will
warn about libintl being associated with libglib. This does not happen
in normal glib build because libintl is usually provided by glibc and is
only an internal library when it fallbacks to a subproject.
Daniel Mensinger
Christoph Reiter
Paolo Bonzini
Federico Mena Quintero
Jon Turney
Dylan Baker
Score_Under
myd7349
Thibault Saunier
Konstantin
Jussi Pakkanen
Nacho García
Luca Weiss
Ninja-Koala
Mark Schulte
Georges Basile Stavracas Neto
Eli Schwartz
Olexa Bilaniuk
Frediano Ziglio
John Ericson
Elliott Sales de Andrade
Nirbheek Chauhan
Xavier Claessens