Previously, running `gdbus-codegen` with no arguments would exit
successfully with no output. While technically correct, that seems
unhelpful.
Require at least one interface file to be specified, so the user gets an
error message if they don’t specify any.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It’s not particularly useful to put the gdbus-codegen version or the
name of the input file into the output from `gdbus-codegen`, and it
makes the output less reproducible. Drop it.
Also clarify the licensing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1612
Whitelist a safe set of characters for use in header guards instead of
maintaining a (growing) blacklist.
The whitelist is intentionally short since reading up on all
peculiarities of the C and C++ standard for identifiers is not my idea
of fun. :)
Fixes#1379
This reverts commit 4aba03562b, preserving
the new tests but adjusting them to assert that the old behaviour is
restored.
As expected, there were a few projects which broke because of this.
Unfortunately, in one case the breakage crosses a project boundary:
sysprof ships D-Bus introspection XML, which is consumed by mutter and
passed through gdbus-codegen.
Since sysprof cannot add this annotation without breaking its existing
users, a warning is also not appropriate.
https://gitlab.gnome.org/GNOME/jhbuild/issues/41https://gitlab.gnome.org/GNOME/sysprof/issues/17https://gitlab.gnome.org/GNOME/glib/issues/1726
Previously, if a method was not annotated with org.gtk.GDBus.C.UnixFD
then the generated code would never contain GUnixFDList parameters, even
if the method has 'h' (file descriptor) parameters. However, in this
case, the generated code is essentially useless: the method cannot be
called or handled except in degenerate cases where the file descriptors
are missing or ignored.
Check the argument types for 'h', and if present, generate code as if
org.gtk.GDBus.C.UnixFD annotation were specified.
This change will break any existing code which refers to the (useless)
wrappers for such methods. The workaround for such code is to add the
org.gtk.GDBus.C.UnixFD annotation, which will cause the same generated
code to be emitted before and after this change.
If this is found to cause widespread problems, we can explore a
different approach (perhaps emitting a warning from the code generator,
or annotating the symbols as deprecated).
https://gitlab.gnome.org/GNOME/glib/issues/1726
We're using the `install` argument for configure_file() all over the
place.
The support for an `install` argument for configure_file() was added in
Meson 0.50, but we haven't bumped the minimum version of Meson we
require, yet; which means we're getting compatibility warnings when
using recent versions of Meson, and undefined behaviour when using older
versions.
The configure_file() object defaults to `install: false`, unless an
install directory is used. This means that all instances of an `install`
argument with an explicit `true` or `false` value can be removed,
whereas all instances of `install` with a value determined from a
configuration option must be turned into an explicit conditional.
If using the --interface-info-{body,header} options to gdbus-codegen,
and the first interface to be outputted has no methods, but does have
properties or signals, an uninitialised variable would be used for the
property/signal ‘since’ values.
In other situations, the ‘since’ value for a prior method would have
been incorrectly used for the properties/signals.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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>
This means the output (including lists of filenames) does not depend on
the order of the input files, which may matter if this tool is invoked
with a glob or some other mechanism that doesn't guarantee an order.
Previously, method and signal arguments were sorted by name, which
(assuming you don't happen to give your arguments
lexicographically-ordered names) means the generated signatures were
incorrect when there is more than 1 argument.
While sorting the methods and signals themselves (and properties, and
annotations on all these) is fine, it's easiest to not sort anything.
Since 1217b1bc4f, LICENSE_STR has taken two
parameters, not one. Without this change, running either mode fails
with a traceback like:
Traceback (most recent call last):
File "../gdbus-codegen", line 55, in <module>
sys.exit(codegen_main.codegen_main())
File ".../codegen_main.py", line 294, in codegen_main
gen.generate()
File ".../codegen.py", line 896, in generate
self.generate_body_preamble()
File ".../codegen.py", line 682, in generate_body_preamble
self.outfile.write(LICENSE_STR.format(config.VERSION))
IndexError: tuple index out of range
8916874ee6, which introduced these flags,
was actually merged after that commit, but I assume it was written
beforehand.
If a D-Bus interface was annotated with o.fd.DBus.Deprecated, then the
corresponding GObject property, in the common GInterface implemented
by the generated GDBusObjectProxies and GDBusObjectSkeletons, to
access the generated code for the D-Bus interface was not being marked
with G_PARAM_DEPRECATED, even though the gtk-doc snippet had the
'Deprecated: ' tag.
G_PARAM_DEPRECATED is older than gdbus-codegen, 2.26 and 2.30
respectively, hence it can be used unconditionally.
https://gitlab.gnome.org/GNOME/glib/merge_requests/485
If a D-Bus interface has a property that's annotated with
o.fd.DBus.Deprecated, then the corresponding GObject property was not
being marked with G_PARAM_DEPRECATED, even though the gtk-doc snippet
had the 'Deprecated: ' tag.
G_PARAM_DEPRECATED is older than gdbus-codegen, 2.26 and 2.30
respectively, hence it can be used unconditionally.
https://gitlab.gnome.org/GNOME/glib/merge_requests/485
None of these files starts with a #! line, and they are not native
binary executables, so if a user attempts to execute them as a program,
Unix shells will run them as /bin/sh scripts. This is not going to end
well, since none of them are shell scripts (the gio bash completion
is for bash, which is not a lowest-common-denominator POSIX shell, and
in any case is designed to be sourced rather than executed).
Fixes: #1539
Signed-off-by: Simon McVittie <smcv@collabora.com>
The existing code was generating code with undefined results that modern compilers warn about:
accounts-generated.c:204:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
(GDBusArgInfo **) &_accounts_accounts_method_info_list_cached_users_OUT_ARG_pointers,
The new python module, added with 0.46, works with Python 2 and 3 and
allows to pass a path for the interpreter to use, if the need arises.
Previously the meson build set PYTHON, used in the shebang line of
the scripts installed by glib, to the full path of the interpreter.
The new meson module doesn't expose that atm, but we should set it to
a executable name anyway, and not a full path.
Several of our tools are installed and are used by other projects to
generate code. However, there is no 'install' when projects use glib
as a subproject.
We need some way for glib to 'provide' these tools so that when some
project uses glib as a subproject, find_program('glib-mkenums') will
transparently return the glib-mkenums we just built.
Starting from Meson 0.46, this can be done with the
`meson.override_find_program()` function.
As a bonus, the Meson GNOME module will also use these
'overriden'/'provided' programs instead of looking for them in PATH.
PEP8 says that:
"Comparisons to singletons like None should always be done with is or
is not, never the equality operators."
glib uses a mix of "== None" and "is None". This patch changes all
cases to the latter.
Since it’s deprecated in favour of positional arguments, including it in
the help output is confusing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795304
These generate basic .c and .h files containing the GDBusInterfaceInfo
for a D-Bus introspection XML file, but no other code (no skeletons,
proxies, GObjects, etc.).
This is useful for projects who want to describe their D-Bus interfaces
using introspection XML, but who wish to implement the interfaces
manually (for various reasons, typically because the skeletons generated
by gdbus-codegen are too simplistic and limiting). Previously, these
projects would have had to write the GDBusInterfaceInfo manually, which
is painstaking and error-prone.
The new --interface-info-[body|header] options are very similar to
--[body|header], but mutually exclusive with them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795304
Recursive annotations do seem to be supported, so we should support them
properly in the type system representation. This currently introduces no
behavioural changes, but will be used in upcoming commits.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795304
This makes it a bit easier for debugging which files were generated from
which introspection XML.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=650875
g_variant_get_objpathv() doesn’t exist. The code actually meant
g_variant_get_objv().
This fixes a leak with `ao`-type properties in generated code.
Previously they wouldn’t be freed; now the container is (correctly)
freed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=770335
In cases where gdbus-codegen is used only for docbook generation,
the execution stops with the following error message:
`Using --header or --body requires --output`
This is because it was assumed that, in addition to the docbook
generation, the header or source code were always generated.
This patch fixes this, and the header or source code generation
is not mandatory, so the docbook can be generated separately.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
gdbus-codegen's options only allow a simultaneous header and source
code generation.
A `--header` and `--body` options have been added along with the
`--output` option which allow separate C header and code
generation.
These options cannot be used in addition to the old options such
as `--generate-c-code`, `--generate-docbook` or
`--output-directory`.
These options have also been added to gdbus-codegen's documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The `outdir` and `docbook` parameters are passed to the
`DocbookCodeGenerator` constructor, but these parameters are only
used at docbook generation, which is optional.
The parameters have been removed from the class creation and added
to the `generate` method, where they are actually being used.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The class that generated both C header and code has been split into
two classes. These clases are now specialized on creating the header
or the body code.
All parameters that do not belong to each class have also been
deleted, so only the necessary parameters still remain. These also
includes the header and code file descriptors, leaving only the
corresponding file descriptor necessary for each class.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The generation of the C header and code preambles have been split
in order to be able to generate both files separately in the future.
The functions for generating preambles and postambles have also been
renamed following the function names used in the glib-genmarshal
rewrite, so that they stay consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The #pragma once is widely supported preprocessor directive that can
be used instead of include guards.
This adds support for using optionally this directive instead of
include guards.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The optparse module is deprecated since version 2.7 and the
development continues with the argparse.
The code has been moved from optparse to argparse when parsing
command-line options. This has also led to the deprecation of the
`--xml-files`, and positional arguments should be used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
`glib-genmarshal` and `glib-mkenums` use a `Color` class which
implements a number of print_* methods to print colored messages
to the standard error output.
In order to be consistent with those programs' output,
`gdbus-codegen` has also started using that same class and methods.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
The license string which is embedded in the C header and body
preambles has been moved to a global variable. This way it can be
reused in both sections.
https://bugzilla.gnome.org/show_bug.cgi?id=791015
Putting a <!-- --> in plural<!-- -->s was an old hack used to fix
linking the symbol with gtk-doc when gtk-doc didn’t know about plural
forms. gtk-doc does now know about plural forms, so the hack can be
removed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When using gdbus-codegen to produce generated code for a method with
an out parameter with a signature like 'as', make sure to include
an "(array)" annotation for that parameter.
(Reworked by Philip Withnall to improve code formatting.)
https://bugzilla.gnome.org/show_bug.cgi?id=741167
This assumption breaks when, for instance:
* Called as /bin/gdbus-codegen
* Installed on Windows in a directory that is not `bin/`
For such cases, we cannot make any assumptions about the directory
structure, and must hard-code the datadir.
https://bugzilla.gnome.org/show_bug.cgi?id=786785
Disable gio tests on Windows, fix .gitignore to not ignore
config.h.meson, and add more things to it.
Rename the library file naming and versioning to match what Autotools
outputs, e.g., libglib-2.0.so.0.5000.2 on Linux, libglib-2.0-0.dll and
glib-2.0-0.dll on Windows with MSVC.
Several more tiny fixes, more executables built and installed, install
pkg-config and m4 files, fix building of gobject tests.
Changes to gdbus-codegen to support out-of-tree builds without
environment variables set (which you can't in Meson). We now add the
build directory to the Python module search path.
In addition to code, gdbus-codegen can also generate docbook
documentation for DBus interfaces. There's no good reason why
the newly added --output-directory option shouldn't apply to
those generated files as well.
https://bugzilla.gnome.org/show_bug.cgi?id=783201
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
People might put more extraneous whitespace in a @since line in a
documentation comment, which should not affect the ordering of
methods/signals/etc. in the generated output.
https://bugzilla.gnome.org/show_bug.cgi?id=770372
Previously, this would not work, as it would result in comparing the
order of a string and an integer. Make it work, and make 'UNRELEASED'
compare higher than other versions so it's always treated as the latest
version.
'UNRELEASED' is commonly used by maintainers to highlight new API while
it's being prototyped, until they know which version it will actually
be released in. At the time of release, they replace all 'UNRELEASED'
strings in git with the new version number.
An example of this usage is here:
d380ac6a2a (9208ee267cb05db1afd3a5c323d71e51db489447_7619_7656)https://bugzilla.gnome.org/show_bug.cgi?id=769995
This adds a new --c-generate-autocleanup option to gdbus-codegen
which can be used to instruct gdbus-codegen about what autocleanup
definitions to emit.
Doing this unconditionally was found to interfere with existing
code out in the wild.
The new option takes an argument that can be
none, objects or all; to indicate whether to generate no
autocleanup functions, only do it for object types, or do it
for interface types as well. The default is 'objects', which
matches the unconditional behavior of gdbus-codegen on the 2.48
branch.
https://bugzilla.gnome.org/show_bug.cgi?id=763379
Some GNOME projects unconditionally work around the generated code's
lack of g_autoptr support by defining the autoptr cleanup function
themselves, which is not forward-compatible; as a result, commit
cbbcaa4 broke them. Do not define the cleanup function unless the
including app "opts in" to newer APIs via GLIB_VERSION_MAX_ALLOWED.
Projects requiring compatibility with GLib < 2.49 can get a
forward-compatible g_autoptr for a generated GInterface type found in
a library, for example ExampleAnimal in the GIO tests, by declaring
and using a typedef with a distinct name outside the library's
namespace:
typedef AutoExampleAnimal ExampleAnimal;
G_DEFINE_AUTOPTR_CLEANUP_FUNC (AutoExampleAnimal, g_object_unref)
...
g_autoptr (AutoExampleAnimal) animal = NULL;
/* returns ExampleAnimal * */
animal = example_animal_proxy_new_sync (...);
/* takes ExampleAnimal * first argument */
example_animal_call_poke_sync (animal, ...);
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=763379
Reviewed-by: Colin Walters <walters@verbum.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
The rest of the generated classes gained g_autoptr support in fd6ca66,
but this one is still missing. Because whatever_proxy_new_finish() and
whatever_proxy_new_sync() are declared as returning a Whatever *
instead of a WhateverProxy *, and the generated method-call stubs
act on a Whatever *, it's reasonably common to want to declare a
g_autoptr (Whatever).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/review?bug=763379
Reviewed-by: Colin Walters <walters@verbum.org>
When replacing a version of goa-daemon (from gnome-online-accounts)
by a newer version with some added interfaces, evolution-data-server
and the gvfs-goa volume monitor might crash as there's no interface
definition for this new interface.
Work-around this by returning earlier from the _notify() implementation,
rather than accessing invalid memory.
https://bugzilla.gnome.org/show_bug.cgi?id=720539
Comparing the code generated for the setter and other methods without
(real) return value, I noticed that the setter does not unref the
gvariant it gets.
https://bugzilla.gnome.org/show_bug.cgi?id=719472
...so that the generated code will build on all platforms, as compilers
like Visual C++ does not like #ifdef checks during a definition/use of
a macro.
https://bugzilla.gnome.org/show_bug.cgi?id=711049
The G_ADD_PRIVATE() macro, and the auto-generated get_instance_private()
internal function, should be used conditionally depending on the maximum
allowed version of GLib, as defined by the GLIB_VERSION_MAX_ALLOWED
pre-processor symbol.
This allows generating code that can be compiled in projects that wish
to use an older API version of GLib through the use of the
GLIB_VERSION_MAX_ALLOWED symbol.
https://bugzilla.gnome.org/show_bug.cgi?id=710133
Under C locale, open() in Python 3 sets the file encoding to ASCII.
As expat looks at encoding="..." in XML declaration, gdbus-codegen can
simply open the input file as binary and let expat decode the content.
https://bugzilla.gnome.org/show_bug.cgi?id=696633
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
to avoid warnings when built with -Wredundant-decls:
sessionmanager-presence-generated.c:316:1: warning: redundant redeclaration of ‘session_manager_presence_default_init’ [-Wredundant-decls]
sessionmanager-presence-generated.c:281:1: note: previous definition of ‘session_manager_presence_default_init’ was here
sessionmanager-presence-generated.c:1273:1: warning: redundant redeclaration of ‘object_default_init’ [-Wredundant-decls]
sessionmanager-presence-generated.c:1259:1: note: previous definition of ‘object_default_init’ was here
https://bugzilla.gnome.org/show_bug.cgi?id=696108
This is the expected (and sane) behavior - without this bug-fix you'd
have to add "Since" to every member of a newly added D-Bus interface.
Also show-case this in the codegen example.
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
If the interface given cannot be matched, `iface_obj' was left uninitialized and
the iface_obj == None check would end up crashing:
Traceback (most recent call last):
File "/usr/bin/gdbus-codegen", line 41, in <module>
sys.exit(codegen_main.codegen_main())
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 175, in codegen_main
apply_annotations(all_ifaces, opts.annotate)
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 146, in apply_annotations
apply_annotation(iface_list, iface, None, None, None, None, key, value)
File "/usr/lib64/gdbus-2.0/codegen/codegen_main.py", line 64, in apply_annotation
if iface_obj == None:
UnboundLocalError: local variable 'iface_obj' referenced before assignment
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=683088
The in commit b79fbc5c3f for fixing
-Wstrict-aliasing warnings was a little too brutal, make it a bit
better.
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
For a D-Bus property with name "Type" (fairly common), we used to
generate a GObject property with name "type-" and C accessors
get_type_() (to avoid clashing with the GType getter), set_type_()
(for symmetri).
However, the rules for GObject property names are fairly rigid and
specifically prohibit names ending in a dash.
Therefore change things so the chosen GObject property name is "type"
but preserve the naming rules for the C getter and setter (for the
same reasons: avoiding name clashing and symmetri).
This change does break the API of generated code (but only on the
GObject property level, the C symbols are not changed) but strictly
speaking the behavior was undefined since "type-" was an invalid
GObject property name.
Also add a test case for this.
Bug 679473.
https://bugzilla.gnome.org/show_bug.cgi?id=679473
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
Most changes were just replacing usage of "has_key" with "in".
Also updated the sorting function which was simplified and
changed to a "key" function instead of "cmp" (which is no longer
supported in python3. Verified everything builds with
python 2.7 and 3.
https://bugzilla.gnome.org/show_bug.cgi?id=678066
