| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the configure script is mostly meant for the convenience of
GNOME Continuous, but with minimal changes we can make it an appropriate
wrapper to the autotools-like build-api.
We can ensure that Meson is invoked with the location of the build
directory, as well as the source directory; we can also ensure that the
Makefile wrapper around Ninja is capable to calling Ninja with the
location of the generated build.ninja file.
Finally, we can generate a simple `check` target that calls `mesontest`
in the build directory.
These changes allow building JSON-GLib following the usual sequence:
./configure …
make
make check
make install
While keeping all the build-related files under a build directory
(except for the generated Makefile, which can be safely ignored).
|
| |
|
|
|
| |
We can drop basically everything, as Meson does not dump stuff into the
source directory.
|
| |
|
|
| |
The `reference` path has been removed.
|
| |
|
|
|
| |
We don't need to show what they evaluate to, given that the value
changes with every release.
|
| |
|
|
|
|
|
| |
We need to remove the path specification inside the sources listing, and
modify the enumeration type and marshallers generation rules to cope
with it (by adding the $(srcdir) when needed). This is similar to the
changes there were made to Clutter.
|
| |
|
|
|
| |
We can verify that the documentation is correct and up to date every
time we distcheck by turning on the gtk-doc check tool.
|
| | |
|
| |
|
|
|
| |
The small utilities we build and install should have their own manual
pages.
|
| |
|
|
|
| |
A simple command line utility to format JSON data; it allows prettifying
and unprettifying JSON.
|
| |
|
|
|
| |
The json-glib-validate tool is a small utility that validates the data
found at the URIs passed on its command line.
|
| |
|
|
|
| |
Instead of using the old GLib test harness, we should use the newly
added TAP support and the TAP driver inside autotools.
|
| |
|
|
|
|
|
| |
See https://live.gnome.org/GnomeGoals/InstalledTests for more
information.
It's still possible to run `make check` with locally uninstalled tests.
|
| | |
|
| |
|
|
| |
With lcov we get nicer reporting tools, with HTML output.
|
| |
|
|
| |
We need to translate the GError messages.
|
| |
|
|
|
| |
Use noinst_PROGRAMS to generate the list of test binaries to ignore
directly in the test directories.
|
| |
|
|
|
|
| |
JsonReader is a simple, cursor-based API for parsing a JSON DOM. It is
similar, in spirit, to the XmlReader API provided by various platforms
and XML parsing libraries.
|
| |
|
|
| |
We depend on automake 1.11, now.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=621141
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Use GCOV, a GCC extension, to perform a coverage test on JSON-GLib when
we perform a 'make check'.
GCOV support builds JSON-GLib with compiler and linker flags that enable
coverage reports; then the check-local target will build the gcov file
for each source file, and the coverage report will be extracted from
those.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Serializing and deserializing GBoxed types is fairly complicated
currently. If a GObject implements JsonSerializable it is possible
for the class to intercept the JsonNode, parse it manually and
then set the value to the property.
This leaves a hole opened for:
• manual (de)serialization of GBoxed types
• (de)serialization of GBoxed properties in classes not
implementing JsonSerializable
In order to serialize and deserialize a GBoxed JSON-GLib should
provide a mechanism similar to the GValue transformation functions:
when registering the boxed type the developer should also be able
to register a serialization and a deserialization functions pair
matching the tuple:
(GBoxed type, JSON type)
The serialization function would be:
JsonNode *(* JsonBoxedSerializeFunc) (gconstpointer boxed);
And, conversely, the deserialization function would be:
gpointer (* JsonBoxedDeserializeFunc) (JsonNode *node);
Obviously, the whole machinery works only for GBoxed types that
register the serialization and deserialization functions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the rules can be moved into their own files to be included
when needed, like:
• silent rules (QUIET_*)
• glib-mkenums rules
• glib-genmarshal rules
Also, the test suite rules should be moved from the top-level of
the project into the build/autotools directory and then included
only where it makes sense.
This requires changing most of the build system to use the new
files layout.
|
| |
|
|
|
| |
Build the Introspection data when compiling JSON-GLib; this way, the
API should be available to other languages automatically.
|
| |
|
|
|
|
| |
Use the m4 AS_COMPILER_FLAGS macro to check for the maintainer
compiler flags supported by the C compiler. This should allow the
build to handle gracefully different versions of GCC.
|
| | |
|
| |
|
|
|
|
|
|
| |
Clean up the configure.ac and Makefile.am files to use something
that is not entirely made of FAIL.
Also, use Shave to sanitize the libtool and compiler incantations
and restore sanity to the build system.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| | |
Merge branch 'master' into json-scanner
|
| | |
| |
| |
| |
| | |
Use a similar test unit as the JsonArray one, testing creation, empty
objects, addition and removal of members.
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This commit adds json-gobject.h and json_serialize_gobject() to
JSON-GLib, to serialize a GObject instance into a JSON data stream.
|
| |
|
|
|
|
|
|
|
| |
Add a test unit for JSON object generation using JsonGenerator. The
empty, simple (1-depth) and complex (nested object and array) cases
are exercised.
The complex object generation is taken from the RFC 4627, Examples
section.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
