Have looked a bit at how this is done currently in g-i and looks like the headers are first passed through cpp then parsed. As this will omit the constants, a second parsing pass is done on the lines that look like macros, this time without invoking cpp.

#define TP_USER_ACTION_TIME_CURRENT_TIME (G_MAXINT64)

This would not be a problem if G_MAXINT64 was defined. But it's not because it's defined in terms of G_GINT64_CONSTANT().

A solution would likely involve invoking cpp on the right side of those defines, then using the result as values for those constants.

(In reply to comment #1)
> A solution would likely involve invoking cpp on the right side of those
> defines, then using the result as values for those constants.

Have been playing a bit with this idea and while it would help with some other constants, it wouldn't work on this case, as it would end up evaluating to:

#define TP_USER_ACTION_TIME_CURRENT_TIME ((__extension__ (0LL)))

which the C parser cannot recognize as an integer literal without knowing that __extension__ is intended for gcc and can be ignored.

Any suggestions about how to solve this issue?

We have similar issue with features:

GQuark tp_connection_get_feature_quark_core (void) G_GNUC_CONST;
is propery exported, but


#define TP_CONNECTION_FEATURE_CORE \
  (tp_connection_get_feature_quark_core ())
is not

We only support int/float/string constants for now.

There's now support for Value: annotations to override the constant, it's sometimes necessary as we don't expand the pre-processed part on the right hide sand.

[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]

Nothing happened in 7 years, so let's close this. Constants can be integers, floats, and strings; for anything computed, there's the Value annotation. Anything more complicated than that is usually an indication of some C trickery that does not translate to other languages.