mesonbuild.dependencies.__init__ exposes configtool, pkgconfig, cmake
and more in __init__.py, so there's no reason we should be tying
SystemDependency to the internal organization implementation of the
subpackage!
In the 2nd previous commit it took quite some effort to figure out that
the python module "does not exist" because of import errors while
refactoring something completely different.
For qt we already have all of the necissary checking in place. Now in
the interpreter we have the same, the intrperter does all of the
checking, then passed the arguments to the Generator initializer, which
just assigns the passed values. This is nice, neat, and clean and fixes
the layering violatino between build and interpreter.
This adds a number of missing type annotations to existing functions,
and makes a few members protected instead of public, as they were never
meant to be public
In commit 3340284805 the new ModuleObject
API got further updated to hide self.interpreter; at the time, the CUDA
module got transferred over to the wrapper which does provide it.
But it works fine without self.interpreter, so let's just use the best
base class.
Custom objects returned by modules must be subclass of ModuleObject and
have the state argument in its methods.
Add MutableModuleObject base class for objects that needs to be deep
copied on assignation.
The only advantage they have is they have the interpreter in arguments,
but it's already available as self.interpreter. We should discourage
usage of the interpreter API and rely on ModuleState object instead in
the future.
This also lift the restriction that a module method cannot add build
targets, but that was not enforced for snippet methods anyway (and some
modules were doing it) and it's really loose restriction as it should
check for many other things if we wanted to make it consistent.
We need to pass any generated sources down the CustomTarget
inititalizers so that they will generate a dependency correctly,
otherwise we get race conditions.
We need to escape space in variables that gets into cflags or libs
because otherwise we cannot split compiler args when paths contains
spaces. But custom variables are unlikely to be path that gets used in
cflags/libs, and escaping them cause regression in GStreamer that use
space as separator in a list variable.
install_scripts used to replace @BUILD_ROOT@ and @SOURCE_ROOT@ but it
was not documented and got removed in Meson 0.58.0. gnome.gtkdoc() was
relying on that behaviour, but it has always been broken in the case the
source or build directory contains spaces.
Fix this by changing get_include_args() to substitue paths directly
which will then get escaped correctly.
Add a unit test that builds GObject documentation which is where this
issue has been spotted.
Fixes: #8744
With this change File objects created with the builtin files() function
can be used with the fs submodule like normal strings.
All methods that seem reasonable support FileOrSting arguments.
For example fs.exists() still only takes str arguments because meson
already ensures that File objects do exist when creating them with files().
Each user facing function of the fs module has an additional FeatureNew
check when used with File objects.
The test cases for fs are extended appropriately with tests for File objects.
Cross-compiling and generating gobject-introspection isn't trivial, but
with wrapper scripts that call qemu-user it's perfectly doable[1].
Currently looking up the gobject-introspection pkgconfig is done as a
native dependency, which means in cross-compilation environments this
is not the right paths (wrong library path, for example).
Solve this by generalisiing _get_native_dep() to _get_dep(native) and
asking for the host gobject-introspection instead.
[1] https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-gnome/gobject-introspection/
If an invalid resource path is specified, then an uncaught python
exception occurs, and a backtrace is shown. Throw a MesonException
instead to produce a cleaner error message.