Auto-generate all enums in Gtk/Gdk

[bfredl]

This enables auto-generation of the complete set of consts and enums in Gtk/Gdk (using gobject-introspection). The support code is in https://github.com/bfredl/GI.jl . However there are a few outstanding issues:

Gobject-introspection does work on windows (used for instance by pygtk as of gtk3) but the introspection data is not currently included in the WinRPM packages. I think this comes down to enable some configuration flags in the WinRPM build scripts; I will look into it later. As with cindex it is only a dependency for regenerating the cache, not for using the package.
As of #24 "_MASK" are stripped of the Gdk mask enum values. If we want to keep this convention this could be done systematically also in the geneated enums, since libgirepo contains info which enums are in fact masks. Right now the enums are in a submodule but when this is resolved they could all be put in the main Gtk namespace.
This PR replaces the EnumName.get symbol lookup functions with getfield, which probably is somewhat slower (cannot be constant folded I guess). If this is a problem EnumName.get could be generated as well (for all enums or a relevant subset of the enums).

Would people consider this useful? If so I will try fix the remaining issues, as needed.

[vtjnash]

Yes. I'm starting to realize this may be the way to go for a lot of stuff: cache auto-gen info from GI and eval it at startup

Let's keep them in Gtk.Constants, but add an export statement for all of the constants. (and a corresponding using .Constants in Gtk)

Any idea how long it takes to parse this? I've measured that GAccessors took 0.5 sec to parse, or 0.01 to read from the fast-cache. This can probably be appended to the same cache file.

I think we should either drop the usage of lowercase, or generate both symbols in the module, that should simplify the get_enum function (which may actually be faster than EnumName.get since it doesn't compile as many functions, and inference/codegen knows how to emit getfield efficiently. All it needs is a typeassert::Enum.

I still think stripping _MASK is the way to go, for keeping code concise.

[tknopp]

@bfredl Autogenerating enums seems great! But I am not totally sure: At which moment is GI required? Only once on your side and not on the Gtk.jl users side, rigtht?

[bfredl]

@vtjnash a quick test gives 0.38 for the entire eval( ... include(constcache) ) stmt, of which 0.23s is only include(constache). I also think all generated code should be appended to the same binary cache.

Well, the introspection data actually contains the enum fields as lowercase, so I think a viable alternative is to only have the fields as lowercase. It's obvious imho that GtkJustification.left is an enum value. Having both is of course very convenient, but I think code will be more consistent and easier to read if one choice is enforced.
getfield being effective is good news, then auto-generated methods (the next step) could allow symbol values for all enum parameters.

@tknopp Correct, all cached code from GI.jl should not runtime-depend on the introspection library. It works the same as the cindex accessors in this respect.

[bfredl]

Ok, I moved most of the generation code to Gtk.jl, so it's easier to special case stuff (like currently exclude GDK_KEY_* as these are almost more than the size of all other enums combined) and it only depends on the layer of GI.jl that I can let be api-stable right now.

lowercase generates quite some keyword conflicts (like end), so I have kept it uppercase-only for now.

[vtjnash]

is there no dependence on gtk_version?

[bfredl]

Well, I thought constants were backwards compatible (as Gtk.jl has done well sofar with only one set of constants). It turns to be a few enums in gtk2 removed in gtk3, so I made it dependent on version. Seems like libgirepository cannot load both gtk2 and gtk3 in the same process, so one has to run the regeneration script twice.

[vtjnash]

I've merged this. I'm not sure which approach (GI or Clang) is necessarily better so I'll keep both at present. It's good for verification that they generate nearly the same thing.

Note: I removed get_enum(E, s), since it was functionally identical to E.(s)

[bfredl]

Ah, I didn't know about the x.(y) syntax. That's very practical to know, thanks!