The current note makes it look like the marshaller code generation has
been deprecated in favour of the libffi-based generic marshaller; this
is not the case, so we should probably clarify the point a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=677235
Otherwise we crash with a null-ptr deref in g_object_newv and ever there we
should not return null, as we're saying that object creation will not return
null.
Expand the documentation for g_object_[freeze|thaw]_notify() to explain that
it deduplicates “notify” signals emitted by frozen objects, so that at most
one signal is emitted per property.
https://bugzilla.gnome.org/show_bug.cgi?id=676937
I didn't do this comprehensively, since there's a lot of it, mainly
due to the GDBus object manager stuff, but anyone trying to use
that would fail fast due to lack of the gdbus code generator.
My main goal was to get API additions to existing classes like
g_data_input_stream_read_line_utf8(), as well as the lower level new
API like glib-unix.h.
https://bugzilla.gnome.org/show_bug.cgi?id=676816
Commit f084b60377 incorrectly set
DIST_SUBDIRS for the toplevel Makefile.am. In general actually we
don't need to set it, because modern automake automatically sets
it by looking at conditionals for SUBDIRS.
Tested-by: Rico Tzschichholz <ricotz@t-online.de>
https://bugzilla.gnome.org/show_bug.cgi?id=667806
This patch solves two problems:
First, it allows builders to optionally cut the circular dependency
between dbus and glib by disabling the modular tests (just like how
the tests can be disabled in dbus).
Second, the tests are entirely pointless to build if cross-compiling.
It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree. This would allow us to
run the tests constantly, not just when glib is built.
https://bugzilla.gnome.org/show_bug.cgi?id=667806
When building with MinGW/MSYS with srcdir != builddir the build fails:
- to locate the generated .def files
- creating libglib-gdb.py
- creating libgobject-gdb.py
Solved this by explicitly instructing these files to be generated
in $(builddir)/...
https://bugzilla.gnome.org/show_bug.cgi?id=653167
If the optimization is used for only having one closure handling a
signal emission, then hooks will not be run, so it should be disabled
when an emission hook is added.
https://bugzilla.gnome.org/show_bug.cgi?id=671918
The trace of the signal emission of the was calculating the instance
type after the instance was unrefed. Fix this by keeping the instance type around.
The ability to cross-compile glib got broken after the
merge of the 'signal-performance' branch as the assumption
was made that the generated glib-genmarshal can be executed
on the host (which isn't valid when cross-compiling).
Fixed this by using the just-built glib-genmarshal for normal
compilations and the native (host) glib-genmarshal when doing a
cross-compilation as was also done in several other areas of GLib
Tested for host=x86_64-unknown-linux-gnu, target=x86_64-unknown-linux-gnu
and host=x86_64-unknown-linux-gnu, target=i686-w64-mingw32
https://bugzilla.gnome.org/show_bug.cgi?id=671676
In the code generation portion, va_copy() is not universally available,
so use the existing G_VA_COPY macro that in turn calls va_copy() if it
is available or call an appropriate emulation otherwise.
va_vopy() is not universally available in all compilers, so make use of
the existing G_VA_COPY macro which either calls va_copy() if it is
available, or emulates it if otherwise.
When there is only one closure handling a signal emission and
it doesn't have a bunch of complicated features enabled we
can short circuit the va_args collection into GValues and call the
callback via the va_marshaller directly.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
If the signal argumment types matches a built in standard
marshaller we use the va_marshaller for that, and also the
normal marshaller if NULL was specified (as its faster than
the generic one).
This lets you set a va_marshaller on your signal which will be
propagated to all closures for the signal. Also, automatically
uses the generica va_marshaller if you specify a NULL c_marshaller.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
This means we're not abusing the notifiers for meta_marshallres,
and we're able to later cleanly add other fields to GClosure.
We still have to leave the ABI intact for the GClosure->meta_marshal
bit, as old G_CLOSURE_N_NOTIFIERS macro instances still accesses it.
However, we always set it to zero to keep those macros working.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
