The Meson build has fallen a bit behind the Autotools one, when it comes
to the internally built tools like glib-mkenums and glib-genmarshals.
We don't need to generate gmarshal.strings any more, and since the
glib-genmarshal tool is now written in Python it can also be used when
cross-compiling, and without indirection, just like we use glib-mkenums.
We can also coalesce various rules into a simple array iteration, with
minimal changes to glib-mkenums, thus making the build a bit more
resilient and without unnecessary duplication.
The old glib-mkenums was more forgiving, and simply ignored any files it
could not find.
We're going to print a warning, as in the future we may want to allow
more strictness.
This is a bit of a hack to maintain some semblance of backward
compatibility with the old, Perl-based glib-mkenums. The old tool had an
implicit ordering on the arguments and templates; each argument was
parsed in order, and all the strings appended. This allowed developers
to write:
glib-mkenums \
--fhead ... \
--template a-template-file.c.in \
--ftail ...
And have the fhead be prepended to the file-head stanza in the template,
as well as the ftail be appended to the file-tail stanza in the
template. Short of throwing away ArgumentParser and going over
sys.argv[] element by element, we can simulate that behaviour by
ensuring some ordering in how we build the template strings:
- the head stanzas are always prepended to the template
- the prod stanzas are always appended to the template
- the tail stanzas are always appended to the template
Within each instance of the command line argument, we append each value
to the array in the order in which it appears on the command line.
This change fixes the libqmi build.
On Visual Studio, the compilation of the check program for va_copy() and
__va_copy() succeeds even though they may not be really available. So,
make sure we include msvc_recommended_pragmas.h which helps us to detect
this situation by bailing out when warning C4013 (which means this
function is really not available) is encountered.
Also make sure that on Visual Studio builds we always include
msvc_recommended_pragmas.h is included so that it helps us to find out
problems in the build, and update comments for dirent.h and sys/time.h
as they are not shipped with any Visual Studio.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Some of the arguments that affect the generated result in glib-mkenums
can be used multiple times, to avoid embedding unnecessary newlines in
their values.
This change fixes the NetworkManager build.
When using the `--header --body` compatibility mode, we need to emit
things we generally define in the header, such as the aliases for
standard marshallers, and aliases for deprecated tokens.
This fixes dbus-binding-tool, which is using `--header --body` and
deprecated tokens.
See: https://bugs.freedesktop.org/show_bug.cgi?id=101799
When building glib as a subproject, #include's for xdp-dbus.h from xdp-dbus.c
and for gdbus-daemon-generated.h from gdbus-daemon-generated.c were generated as
being prefixed with the subproject prefix, eg
#include "subproject/glib/gio/gdbus-daemon-generated.h".
That failed since the root of the build directory is obviously not part of the
include path when building a subproject.
Passing --output-directory @OUTDIR@ to gdbus-codegen and removing @OUTDIR@ from
--generate-c-code fixes the issue.
meson.source_root() returns the toplevel source directory
of the toplevel project, thus the paths were wrong when using
it. Simply using files() gets us the right path
https://bugzilla.gnome.org/show_bug.cgi?id=784133
With meson from git dependencies of dependencies are no
longer added automatically and recursively to the linker
lines. Meaning dependencies that are used have to be
passed directly and explicitly or we'll get linker errors.
Fixes get_type function generation for:
- GMountMountFlags
- GDriveStartFlags
- GResourceLookupFlags
- GSocketMsgFlags
- GTlsDatabaseVerifyFlags
- GTestDBusFlags
which were registered as enum types before, which broke
some unit tests.
Problem is that the flags annotation has no value, so
options.get('flags') would always return None even if
it was present.
https://bugzilla.gnome.org/show_bug.cgi?id=779332
Need to fix up some of the tests a little, because the
test binary will not necessarily be run from the current
build sub-directory, and the build directory structure
might not always be a mirror of the source directory
structure, so pass location of glib-mkenums and
glib-compile-scheme and such directly.
