The previous 2.57.2 release failed. The tarball for this one will be
generated using `ninja dist`, but should still be good to be built using
autotools. `make distcheck` on it has been tested.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1436
See previous commit; same reasoning behind the commit, except that these
sources weren’t (yet) causing `make distcheck` to fail.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of messing around with EXTRA_*_SOURCES and manually handling .lo
files, why not just add gwin32.c to the GLib sources conditionally?
This will hopefully fix `make distcheck` failing due to gwin32.Plo not
being generated in the sub-builddir≠srcdir stage, due to depcomp
inexplicably not generating it. (Note that it is correctly generated in
non-distcheck builds.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The parser state machine for bookmark files did not handle unexpected
nesting of elements, such as a <bookmark> element inside a <title>
element — it would print a critical warning rather than returning a
GError.
Fix that, and add various unit tests for it. The set of tests includes
various other general markup tests as provided by Jussi Judin.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1035
That should format these character classes correctly in the
documentation, and prevent them being interpreted by gtk-doc as (broken)
Markdown hyperlinks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This fixes a gtk-doc complaint about the argument name not matching
what’s used in the gtk-doc comment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
They should either be generated at build time, or ignored completely,
depending on the presence of --[enable|disable]-man.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It is a bug if we distribute files which are generated at build time —
they should be built on the machine which is compiling GLib, not be
shipped in the tarball.
This brings the autotools-generated tarball in line with the
ninja-generated one, with the exception of man pages and gtk-doc HTML
output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If something which looks like a closing tag is left unfinished, but
isn’t paired to an opening tag in the document, the error handling code
would do a null pointer dereference. Avoid that, at the cost of
introducing a new translatable error message.
Includes a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1461
When formatting the error messages for markup parsing errors, the parser
was unconditionally reading a UTF-8 character from the input buffer —
but the buffer might end with a partial code sequence, resulting in
reading off the end of the buffer by up to three bytes.
Fix this and add a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1462
The network monitor portal interface is changing.
Version 2 is no longer using properties, but getters
instead (this lets the portal apply access control
and avoid sending information to non-networked
sandboxes).
To support both version 1 and 2 of the interface,
we stop using generated code and instead deal with
the api differences in our own code, which is not
too difficult.
Support version 1 as well
The new python module, added with 0.46, works with Python 2 and 3 and
allows to pass a path for the interpreter to use, if the need arises.
Previously the meson build set PYTHON, used in the shebang line of
the scripts installed by glib, to the full path of the interpreter.
The new meson module doesn't expose that atm, but we should set it to
a executable name anyway, and not a full path.
Several of our tools are installed and are used by other projects to
generate code. However, there is no 'install' when projects use glib
as a subproject.
We need some way for glib to 'provide' these tools so that when some
project uses glib as a subproject, find_program('glib-mkenums') will
transparently return the glib-mkenums we just built.
Starting from Meson 0.46, this can be done with the
`meson.override_find_program()` function.
As a bonus, the Meson GNOME module will also use these
'overriden'/'provided' programs instead of looking for them in PATH.