So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The behaviour of the Meson build has changed a little vs what we did in
autotools. In autotools, --enable-debug was a tristate (yes, no,
undefined), with all three options resulting in different macro
definitions.
In Meson, we have a bistate of --buildtype={debug,debugoptimized} vs
--buildtype=(anything else). There is no way to automatically define
G_DISABLE_ASSERT or G_DISABLE_CHECKS while building GLib — you need to
define them in your CPPFLAGS in your environment instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Drop mentions of autotools. In particular, update the list of configure
options to reflect what’s available in the Meson build.
Further work is needed as a follow-up to improve our handling of (what
was formerly) the --enable-debug option.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We’re about to drop autotools support. Rather than keep the .mk files
around in master indefinitely, link to the versions in the glib-2-58
branch (the last stable release of GLib which supports building with
autotools) in readiness for dropping the .mk files from master.
Any future fixes to these files can happen on the glib-2-58 branch. The
links should work forever (as long as we use GitLab).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We don’t actually build this; the Makefile was just there to allow
ad-hoc regeneration of the glib-mirroring-tab output files.
Port it to Meson just so there are no remnants of GNU make left in GLib.
Don’t hook it up to the rest of the build.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
But it can't be used as a drop-in implementation of G_GNUC_NORETURN
because it can only be placed at the start of the function prototype.
Document this in a comment so that the next person doesn't spend
20 min figuring it out.
This is a wrapper around g_private_set() which allocates the desired
amount of memory for the caller and calls g_private_set() on it.
This is intended to make it easier to suppress Valgrind warnings about
leaked memory, since g_private_set() is typically used to make one-time
per-thread allocations. We can now just add a blanket suppression rule
for any allocations inside g_private_set_alloc0().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Check for over- and underflow when manipulating positions.
This makes the sequence
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
return NULL for the second call, as it should.
Closes: #1639
Calling
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
does not return NULL for the second call, as it should.
This was showing up in GTK+ list model tests.
Since commit 290bb0dd, where various members of GTask were converted to
a bitfield, some of the getters:
• g_task_get_check_cancellable()
• g_task_get_return_on_cancel()
• g_task_get_completed()
have been returning truthy ints (zero or an arbitrary non-zero integer)
as boolean values, rather than the canonical boolean ints of 1 and 0.
This broke the `yield` statement in Vala, whose generated C code
compares `g_task_get_completed (…) != TRUE`. i.e. Whether the
`completed` field has a value not equal to 1.
Fix this by explicitly converting truthy ints to canonical boolean ints
in all getters.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1636
This is a new polling method allowing to poll more than 64 handles
based on the glib one.
When we reach the limit of 64 we create a thread and we poll
on that thread for a batch of handles this way we overcome the limit.
https://gitlab.gnome.org/GNOME/glib/issues/1071
And mention why it’s not a GInterfaceInitFunc as people who have read
the GObject docs cover-to-cover might expect.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
According to msdn documentation last backslash(es) of quoted argument
in a win32 cmdline need to be escaped, since they are
directly preceding quote in the resulting string:
https://docs.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments
Glib <=2.58.0 passed children arguments like C:\Program Files\
without escaping last backslash(es).
So it had been passed as "C:\Program Files\"
windows command line parsing treated this as escaped quote,
and later text was treated as argument continuation instead of separate
arguments.
Existing implementation wasn't easily adoptable to fix this problem,
so escaping logic was rewritten.
Since the resulting length need to be increased due to extra escaping
it was rewritten too. Now the calculated length assumes that all
escapable chars would be escaped in a resulting string,
so the length may be a bit bigger than actually needed,
since backslashes not preceding quotes are not escaped.
This fixes the glib/tests/spawn-singlethread.c test
(which introduced testing for special chars to make this problem
testable).
The problem itself was found during investigations about fixing
related https://gitlab.gnome.org/GNOME/glib/issues/1566
The logic is duplicated in protect_argv_string() and protect_wargv() funcs.
However there is no single obvious way to get rid of duplication -
https://gitlab.gnome.org/GNOME/glib/merge_requests/419#note_371483
So by now adding a note referencing protect_wargv from protect_argv_string,
the other direction is already referenced.
