The glib-mkenums program allows generating code to handle enums/flags
with very different purposes. One of its purposes could be generating
per-enum/flag methods to be exposed in a library API, and while doing
that, it would be nice to have a way to specify in which API version
the enum/flag was introduced, so that the same version could be shown
in the generated API methods.
E.g. From the following code:
/**
* QmiWmsMessageProtocol:
* @QMI_WMS_MESSAGE_PROTOCOL_CDMA: CDMA.
* @QMI_WMS_MESSAGE_PROTOCOL_WCDMA: WCDMA.
*
* Type of message protocol.
*
* Since: 1.0
*/
typedef enum { /*< since=1.0 >*/
QMI_WMS_MESSAGE_PROTOCOL_CDMA = 0x00,
QMI_WMS_MESSAGE_PROTOCOL_WCDMA = 0x01
} QmiWmsMessageProtocol;
The template would allow us to generate a method documented like this,
including the Since tag with the value given in the mkenums 'since' tag.
/**
* qmi_wms_message_protocol_get_string:
* @val: a QmiWmsMessageProtocol.
*
* Gets the nickname string for the #QmiWmsMessageProtocol specified at @val.
*
* Returns: (transfer none): a string with the nickname, or %NULL if not found. Do not free the returned value.
* Since: 1.0
*/
const gchar *qmi_wms_message_protocol_get_string (QmiWmsMessageProtocol val);
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
If some other per value option was present than 'skip' or 'nick' then
a KeyError would occur. Ignoring such options matches the behaviour of
the old, Perl-based glib-mkenums.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
https://gitlab.gnome.org/GNOME/glib/issues/1360
Previously we were only detecting typedef\*senum\s*\{, which does not
handle the case where there is an entifier for the enum itself but
not the typedef. glib-mkenums would then attempt to read the next line
looking for a matching {, but in vain.
https://bugzilla.gnome.org/show_bug.cgi?id=794506
Some source files aren't valid utf-8 containing for example
iso8859-1 accented characters in author's names.
Replace invalid data with a replacement '?' character and print a
warning to keep things working.
Based on a patch from Christoph Reiter in
https://bugzilla.gnome.org/show_bug.cgi?id=785113#c20
Clarify the licensing of the code generated by the two scripts in a
comment in the header of each generated file. The intention is that the
license of GLib does *not* apply to the generated files; but that they
are subject to the linking restrictions of the LGPL, since they link to
GLib and GLib is licensed under the LGPL. The generated files themselves
are under the license of whatever project they’re generated for.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788990
We should ensure a stable order when processing the files, regardless of
the order they were submitted on the command line, to increase the
chances of a reproducible build.
The old Perl-based version of glib-mkenums was fixed in commit 8686e430
to do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=691436
The fallback code for providing a default comment template only worked
if a template file was provided. It didn’t work if individual templates
were provided on the command line (and --comment wasn’t).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788990
In case of Python 2 and stdout being redirected to a file, sys.stdout.encoding
is None and it defaults ASCII for encoding text.
To match the behaviour of Python 3, which uses the locale encoding also when
redirecting to a file, wrap sys.stdout with a StreamWriter using the
locale encoding.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
Instead of using NamedTemporaryFile, which doesn't take an encoding in Python 2
use mkstemp() to create a file and open it with io.open(), with a proper
encoding set.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
On Windows open() defaults to ANSI and on Python 2 it doesn't take
an encoding. Use io.open() instead which provides the same interface
on both Python versions.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
The Meson build has fallen a bit behind the Autotools one, when it comes
to the internally built tools like glib-mkenums and glib-genmarshals.
We don't need to generate gmarshal.strings any more, and since the
glib-genmarshal tool is now written in Python it can also be used when
cross-compiling, and without indirection, just like we use glib-mkenums.
We can also coalesce various rules into a simple array iteration, with
minimal changes to glib-mkenums, thus making the build a bit more
resilient and without unnecessary duplication.
The old glib-mkenums was more forgiving, and simply ignored any files it
could not find.
We're going to print a warning, as in the future we may want to allow
more strictness.
This is a bit of a hack to maintain some semblance of backward
compatibility with the old, Perl-based glib-mkenums. The old tool had an
implicit ordering on the arguments and templates; each argument was
parsed in order, and all the strings appended. This allowed developers
to write:
glib-mkenums \
--fhead ... \
--template a-template-file.c.in \
--ftail ...
And have the fhead be prepended to the file-head stanza in the template,
as well as the ftail be appended to the file-tail stanza in the
template. Short of throwing away ArgumentParser and going over
sys.argv[] element by element, we can simulate that behaviour by
ensuring some ordering in how we build the template strings:
- the head stanzas are always prepended to the template
- the prod stanzas are always appended to the template
- the tail stanzas are always appended to the template
Within each instance of the command line argument, we append each value
to the array in the order in which it appears on the command line.
This change fixes the libqmi build.
Some of the arguments that affect the generated result in glib-mkenums
can be used multiple times, to avoid embedding unnecessary newlines in
their values.
This change fixes the NetworkManager build.
Fixes get_type function generation for:
- GMountMountFlags
- GDriveStartFlags
- GResourceLookupFlags
- GSocketMsgFlags
- GTlsDatabaseVerifyFlags
- GTestDBusFlags
which were registered as enum types before, which broke
some unit tests.
Problem is that the flags annotation has no value, so
options.get('flags') would always return None even if
it was present.
https://bugzilla.gnome.org/show_bug.cgi?id=779332
This reduces the build-time dependencies of glib to only Python 3,
Meson, and git. Git is also optional if you provide a tarball in
which the subproject directories already exist.
The Python port was done by Jussi Pakkanen on bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=779332
This version contains some fixes from that and also changes all
instances of `@` to `\u0040` because Meson does not yet provide a
configure_file() mode that ignores unknown @MACRO@ values.
It is possible, when using GTK-Doc, to mark sections of an enumeration
type as "private": the values are there, but they are not documented,
and GTK-Doc won't complain about missing symbols:
typedef enum {
/*< private >*/
MY_FOO_PRIVATE,
/*< public >*/
MY_FOO_VALUE_A,
MY_FOO_VALUE_B,
/*< private >*/
MY_FOO_VALUE_C,
MY_FOO_VALUE_D
} MyFooValue;
The glib-mkenums parser also allows skipping enumeration values, using a
slightly different syntax:
typedef enum P
MY_BAR_PRIVATE, /*< skip >*/
MY_BAR_VALUE_A,
MY_BAR_VALUE_B
} MyBarValue;
The annotation must sit on the same line as the enumeration value.
Both GTK-Doc and glib-mkenum use the same trigraph syntax, but slightly
different keys. This makes combining them slightly redundant, but
feasible.
All would be well and good, except that glib-mkenum will generate a
warning for lines it does not understand — and that includes the GTK-Doc
annotation trigraph, which, when confronted with the MyFooValue
enumeration above, will result in a warning like:
glib-mkenums: myfoo.h:2: Failed to parse ` /*< private >*/ '
glib-mkenums: myfoo.h:5: Failed to parse ` /*< public >*/ '
glib-mkenums: myfoo.h:9: Failed to parse ` /*< private >*/ '
Of course, we could make glib-mkenum ignore any trigraph comment on a
stand alone line, but it would probably be better to ensure that both
glib-mkenums and gtk-doc behave consistently with each other, and
especially with the maintainer's intent of hiding some values from the
user, and reserving them for internal use.
So we should ensure that glib-mkenums automatically skips all the
enumeration values after a "private" flag has been set, until it reaches
a "public" stanza.
https://bugzilla.gnome.org/show_bug.cgi?id=782162
