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.
This new cmake module allows to generate cmake package files. This may ease the
porting for cmake projects that are exporting cmake package informations for other
depending projects. The module uses as much as possible the templates provided by
the cmake installation (and so cmake needs to be installed).
This would normally be exposed by the ExternalProgramHolder, but wasn't
due to the implementation of the PythonInstallation module. Because of
that I've duplicated the method so that we can add the FeatureNew
decorator.
Fixes#4070
Into a generic interpreter object. This isn't a module, it's an object
returned by a module, it also happens to be a special case of an
ExternalProgram, which is a normal interpreter object. Let's treat it
like one.
Daniel Mensinger
Dylan Baker
Thibault Saunier
Konstantin
Jussi Pakkanen
Nacho García
Luca Weiss
Ninja-Koala
Mark Schulte
Georges Basile Stavracas Neto
Eli Schwartz
Olexa Bilaniuk
Frediano Ziglio
Christoph Reiter
John Ericson
Elliott Sales de Andrade
Nirbheek Chauhan
Xavier Claessens
Michael Hirsch, Ph.D
Sergey Shatunov
David Fort
Alistair Thomas
John Ericson
guruDanny67