To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
Rather than having the gtk-doc build machinery have a list of header
files to exclude, change the GLib build to dump a list of public
header files generated from the maintained Makefile.am files for
each of glib/, gobject/, gio/.
Also, for glib, always install glib-unix.h, even on non-Unix
platforms, for the same reason we install gwin32.h even on Unix.
https://bugzilla.gnome.org/show_bug.cgi?id=651745
The check for _MSC_VER here is not necessary here because:
-One cannot compile GLib out-of-the-box with VS 2003 (let alone VS6
or earlier) since GLib 2.22.4 or so.
-This code compiles fine with the currently-supported VS versions
(2008/2010) without the error mentioned in the comments.
This will close Bug 652002.
Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>
From discussion, GVariantIter is not useful for bindings, but
GVariantBuilder may be.
https://bugzilla.gnome.org/show_bug.cgi?id=646635
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
The grouping in files/headers is not used anymore, and
the function attributes neither. Adapt abicheck scripts
and .def file generation rules accordingly.
The hash table used exclusively for looking up types by name used to map
quarks => types. But we can easily make it map strings => types, which
avoids the quark lookup. And that in trun avoids taking a lock and
consulting another hash table. So this change should make
g_type_from_name() roughly twice as fast.
In some cases, signal arguments have to be collected, even if there are i
no signal handlers connected (e.g. for GVariant parameters, where collection
consumes a floating variant).
Based on a patch by Christian Persch.
Bug #643624.
These are the updates to the autotools files to
ensure the expansion of the GIO, GLib and GObject
project files (*.vcxproj, *.vcxproj.filters) and to
enable the distribution of the VS2010 project files
The actual VS2010 project files will follow shortly
I couldn't tell from reading the documentation whether I had to pass in
an uninitialized value, or a value initialized to the exact type, or
something else. It turns out (from reading the source) that you have to
pass in an initialized value, but you can use any type to which the
property's actual type can be transformed.
So, let's document this.
The code section guarded with toggle_refs_mutex includes a call to
g_object_unref(), which may call toggle_refs_notify(). As the latter
tries to acquire the same mutex, glib locks up.
https://bugzilla.gnome.org/show_bug.cgi?id=632884
Previously, dumping a GValue holding a GStrv just yielded "((GStrv *)
0xDEADBEEF)". I think it'd be more useful to dump a Python list-style
representation of the GStrv's contents, if it's not NULL.
Fixes: <https://bugzilla.gnome.org/show_bug.cgi?id=629192>
Since we added g_object_notify_by_pspec(), an efficient way to install
and notify properties relies on storing the GParamSpec pointers inside
a static arrays, like we do for signal identifiers.
Instead of multiple calls to g_object_class_install_property(), we
should have a single function to take the static array of GParamSpecs
and iterate it.
https://bugzilla.gnome.org/show_bug.cgi?id=626919
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
This should fix bug #628952.
Don't include glib/gdatasetprivate.h directly. Especially don't define
GLIB_COMPILATION when doing that, as that causes breakage on Windows
because of the variable dllimport/dllexport stuff in gtypes.h that
checks GLIB_COMPILATION. That macro really should be defined only when
compiling code that goes into the libglib DLL. Otherwise the compiler
thinks that variables that should be imported from libglib are
actually defined in the code being compiled.
Just call g_atomic_pointer_get() as such, don't bother with
G_DATALIST_GET_FLAGS.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
The gdatasetprivate.h header includes gatomic.h directly. It all works
well in GLib, but inside GObject it will trigger the single inclusion
guard.
Since this is a private header, and it's kind of a special case, one way
to fix it is to declare GLIB_COMPILATION around it and fool the single
inclusion guard in gatomic.h into thinking we're compiling GLib and not
GObject.
g_object_class_list_properties tries to sort the returned list of
paramspecs by 'type depth' and param_id. But all the overridden
interface properties have a param_id of 0, so they come out in
a random order.
Bug 628253.
The previous code dedup'd when thawing and threw nasty warnings your way
if you notified too often. This can now easily be avoided.
Performance should be roughly identical, as both are O(n²).
The g_object_bind_property_with_closures() function should set a
marshaller if the two GClosures don't have one already. This simplifies
the caller code and avoids duplication.
We need to add a new marshaller to the gmarshal.list matching the
signature of the GBindingTransformFunc function.
Since GSettings got the same functionality and flag in commit ca3b7b75b
GBinding should also have the ability to automatically invert a boolean
value without requiring a custom transformation function.
Since using the function pointer version muddles the memory management
requirements of language bindings, we should implement a GClosure-based
variant on top of g_object_bind_property_full().
https://bugzilla.gnome.org/show_bug.cgi?id=622278
This reverts commit 0201a81f04 and adds
locks in the right place.
As this file is a public header (see last commit), we cannot just remove
functions from it.
gobjectnotifyqueue.c is a public header, so we cannot remove files from
it. (Yes you read that right, this .c file is a public header. See your
installation directory.)
Adds locking around object property change notification handling. The
notifications are only emitted after all threads have called
g_object_thaw_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=166020
