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.
Some variables are reserved because meson set them automatically. But we
are not setting them for dataonly pc files, so there is no reason to
reserve them.
Fixes: #8583.
Currently the Qt Dependencies still use the old "combined" method for
dependencies with multiple ways to be found. This is problematic as it
means that `get_variable()` and friends don't work, as the dependency
can't implement any of those methods. The correct solution is to make
use of multiple Dependency instances, and a factory to tie them
together. This does that.
To handle QMake, I've leveraged the existing config-tool mechanism,
which allows us to save a good deal of code, and use well tested code
instead of rolling more of our own code.
The one thing this doesn't do, but we probably should, is expose the
macOS ExtraFrameworks directly, instead of forcing them to be found
through QMake. That is a problem for another series, and someone who
cares more about macOS than I do.
Dylan Baker
Eli Schwartz
Daniel Mensinger
Xavier Claessens
Florian Fischer
Ross Burton
Nellie Zhang
Olexa Bilaniuk