GitLab

The G_DEFINE_TYPE_WITH_PRIVATE call was moved as it needs to know the
storage size of private structure.

The G_DEFINE_TYPE_WITH_PRIVATE call was moved as it needs to know the
storage size of private structure.

The G_DEFINE_TYPE_WITH_PRIVATE call was moved as it needs to know the
storage size of private structure.

The G_DEFINE_TYPE_WITH_PRIVATE call was moved as it needs to know the
storage size of private structure.

The G_DEFINE_TYPE_WITH_PRIVATE call was moved as it needs to know the
storage size of private structure.

The G_DEFINE_TYPE_WITH_PRIVATE call was moved as it needs to know the
storage size of private structure.

The G_DEFINE_TYPE_WITH_PRIVATE call was moved as it needs to know the
storage size of private structure.

The G_DEFINE_TYPE_WITH_PRIVATE call was moved as it needs to know the
storage size of private structure.

The G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE call was moved as it needs to
know the storage size of private structure.

Removes several of the following:
 > ../tests/test-gom-transform.c:170:3: warning: ‘g_type_class_add_private’ is deprecated [-Wdeprecated-declarations]
 >   170 |   g_type_class_add_private(object_class, sizeof(ItemResourcePrivate));
 >       |   ^~~~~~~~~~~~~~~~~~~~~~~~

While at it, use a single variable for glib, gio and gobject

Closes: #22

DEPRECATION: Project targeting '>= 0.38.1' but tried to use feature deprecated since '0.48.0': python3 module
WARNING: Deprecated features used:
 * 0.48.0: {'python3 module'}

The GomResourceClass associated with an child class (such as
ItemResourceClass in much of our tests) isn't the same as the one in
GomResourceClass' class_init().

We have the right GomResourceClass subclass during
gom_resource_init(), but GType has temporarily changed its g_class
pointer to point to the GomResourceClass instance for GOM_TYPE_RESOURCE
while calling gom_resource_init().

It will later change the g_class pointer back to the GomResourceClass
instance for ITEM_TYPE_RESOURCE (as is used in most of our tests).
g_class is used by G_OBJECT_GET_CLASS() to get the class struct instance.

See https://gitlab.gnome.org/GNOME/glib/blob/341c58b44a698c68ba96639636fd02e54cbaddd7/gobject/gtype.c#L1860

Add a constructed vfunc so that we can get the GomResourceClass
associated with the child class' instance after the g_class swap, with,
this time, the primary_key correctly set to a non-empty value.

This empty value was also causing warnings (and fatal warnings in test
suites) with newer versions of GLib as it tried to connect to the
"notify::" signal.

See glib@5e89ba5a

Closes: #24

The error messages under sqlite-3.7.17-8.el7_7.1.x86_64 were slightly
different, causing the tests to fail.

In particular, check that NULL values are stored in the database as
NULL.

Currently Gom will store NULL GDateTimes in the database as a string
representing the epoch, '1970-01-01T00:00:00Z', instead of NULL.  This
unneccessarily increases the storage requirements of every NULL
GDateTime column in every row by 20 bytes.  This also presents a loss
of information: there's no way to distinguish between the valid input
values of the epoch and NULL.  The API user has to account for the way
in which the library is transforming data values.

To fix this, we store NULL GDateTime values in the database as NULL
instead.

worldofpeace authored Apr 11, 2019 and Bastien Nocera committed Jul 17, 2019

Closes: #3

bindings: Get the right Python overrides install dir

See merge request !1

On most platforms, Python's LIBDIR is:

    /usr/lib (or something similar)

However, on Debian, and inside org.gnome.Sdk//master, that's instead:

    /usr/lib/{arch}

As a result, we weren't installing the GI overrides in the right
directory.

On all those platforms, SCRIPTDIR is always /usr/lib, which makes it a
better path to use.

The old test would simply crash when attempting to use a
resource with the invalid table name for the first time. With the
validity checks, we now assert much earlier. Adapt the test to succeed
if the check fails as expected.

https://bugzilla.gnome.org/show_bug.cgi?id=785983

https://bugzilla.gnome.org/show_bug.cgi?id=785983

https://bugzilla.gnome.org/show_bug.cgi?id=785983

https://bugzilla.gnome.org/show_bug.cgi?id=785983

Mathieu Bridon authored Mar 07, 2017 and Bastien Nocera committed Jun 21, 2017

We build with Meson now, so there's no need for this any more.

https://bugzilla.gnome.org/show_bug.cgi?id=779732

We'd like everybody to build Gom with Meson in the near-future.

However, for now we're still generating the release tarballs with the
Autotools and their `make distcheck` target.

This change makes sure tarballs contain the essentials to be built with
Meson.

https://bugzilla.gnome.org/show_bug.cgi?id=781944

Most tests are declared the exact same way: they have a name, which
corresponds to the source file, and they depend on libgom, without
anything special.

We can factorize these to simplify the build system.

https://bugzilla.gnome.org/show_bug.cgi?id=781944

We were using the generic find_program function to find the python3
executable.

However, Meson provides a  builtin python3 module which, among other
things, allows doing just that.

http://mesonbuild.com/Python-3-module.html

https://bugzilla.gnome.org/show_bug.cgi?id=781944

We don't want an exact match, but at least that version.

https://bugzilla.gnome.org/show_bug.cgi?id=779732