Generate sys module

[EPashkin]

If you still don't start it, i can begin do it (about 1 day) in following way: Add in Gir.toml options.sys_subpath = "gtk-sys" Generate funcs.rs with status = "generate" widgets functions, that will be included and reexported in lib.rs. All sys-depended code will go to sys subdirs of analyze and codegen

State of sys generation:

• [x] glib
• [x] gobject
• [x] gio
• gmodule - included from GdkPixbuf-2.0.gir, but seems not really used
• cairo - need rework cairo-1.0.gir, currently generate no content, so using old version of this
• [x] pango
• [x] gdkpixbuf
• [x] gdk
• [x] gtk

Features:

• [x] build script
• [x] constants
• [ ] "foreign" modules that we don't necessarily want to bind (fontconfig, freetype, xlib) need some solution
• [x] record methods
• [x] installed library version detection
• [x] features (with realization on named configuration parameters)
• deprecation (don't needed in sys)
• [ ] Make Option<fn(...)> handling more precise to respect non-nullable paramerers
• [x] Implement Debug for structs. This is complicated by the lack of impl Debug for fn(...)
• [ ] Stub out the struct fields we can't properly represent to keep the structs sizes and alignments consistent with C.

[EPashkin]

Also "return out parameters" little depends on this.

[gkoz]

I do plan to start the sys crate generation but why should anything else depend on that?

[EPashkin]

You still planing, or already started? In "return out parameters" I planing add rets:Vec<Parameters> along with old ret: Option<Parameter> to object::Info. I want this issue act as warning remover, therefore, I propose do it myself

[gkoz]

No, I have not started that. But I didn't want to couple the sys crate generation with other modes too much, for instance, I don't see why it should care about which widgets and methods are generated.

[EPashkin]

If you want generate all function, then no dependence.

[EPashkin]

gkoz: if you don't begin generate sys module, can i generate functions for all classes?

[gkoz]

Alright, go ahead.

[EPashkin]

gkoz: can you add to gtk-sys file funcs.rs where move GtkAboutDialog functions? I have problem with this.

[gkoz]

I don't see the point of splitting the sys crates into modules especially if they're autogenerated.

[EPashkin]

Then where i write functions?

[EPashkin]

Or you want autogenerate all sys module from begining?

[gkoz]

Yes, I could be wrong but this task seems simple enough to generate everything at once.

[EPashkin]

Ok. Then in first version i just rewrite begining of lib.rs.

[gkoz]

:+1:

[gkoz]

I think we're almost feature-complete vs the handmade sys crates so it's time to eliminate the gtk-related hardcoded stuff and accommodate generating all of glib-sys, gdk-sys, (possbily pango-sys), and gtk-sys.

[EPashkin]

Any hardcode in sys? IMHO better start with glib-sys. we need generate lib.rs, glib.rs, gobject.rs, gio.rs?

[EPashkin]

Not sure what better, one Gir.toml for each project, that can be stored in project, or one config for all libs, that stored in gir

[gkoz]

One way could be to generate glib.rs, gio.rs etc and do glob reexports in the lib.rs (pub use glib::*;). We'd also need a manual module with gboolean, gsize and other typedefs that could be imported uniformly from every generated module.

Any hardcode in sys?

Yes, the sys-related stuff.

[EPashkin]

Ok, I try make template tomorrow

[EPashkin]

What harcoded in sys?

[EPashkin]

IMHO only file path, and fix_namespace, it will changed anyway

[gkoz]

A part of the statics.rs too. Maybe that's all that is hardcoded.

[gkoz]

As to the configs, currently I prefer to have a separate config for each lib (namespace), for this choosing a config from command line would be handy. The configs might need to support blacklisting types and definitely need blacklisting constants because GLib-2.0.gir has a bunch of platform-specific ones.

[gkoz]

Let's just save ourselves the trouble and make glib-sys, gio-sys etc separate crates. This will have very little impact on the "front end" crates anyway.

[EPashkin]

If @GuillaumeGomez allow it

[GuillaumeGomez]

As long as it doesn't break rust-gnome "environment", there's no problem for me.

[GuillaumeGomez]

Actually, if someone could explain me a bit longer what's happening here, it would be amazing ! If you want to generate crates to be bound by all rust-gnome libraries, shouldn't we run tests before ? Otherwise, I can give write access to crates to @gkoz.

[gkoz]

@GuillaumeGomez The crates generated by this utility aren't yet ready to replace the rust-gnome ones (actually, only the glib-sys crate builds cleanly so far) but they're getting there and I plan to closely review the differences when that time comes. Testing the stuff properly is a tall order though because the coverage our examples crate provides is rather modest :)

The task will be less cumbersome if there is a 1:1 match between the libraries (such as glib, gio, gobject) and crates, so the generator won't have to incorporate another bunch of special cases. This doesn't make it necessary to change the higher level crates organization. But we might consider putting the new sys crates into their own single sys (or ffi) repo and removing the sys crates from the rest of the repos.

[GuillaumeGomez]

We actually could already do it. I think it's a bit disturbing for newcomers. We didn't have a big enough use to split sys from its "parent". Maybe it's the time ?

[gkoz]

In a week we might have a prototype repo with newly generated sys crates for everything except cairo.

[GuillaumeGomez]

Perfect, I'll wait until this date then. :-)

[EPashkin]

For full replace current syses we also need feature generation and better with deprecation.

[gkoz]

The current sys crates don't really do anything with the features, if I remember right. But we might make the build script add some constant that will help downstream crates change their cfgs.

[EPashkin]

When i tried apply replace sys in gtk it errored about features https://github.com/rust-gnome/gtk/blob/master/Cargo.toml

[gkoz]

The features are present in gtk-sys' Cargo.toml but don't do anything. Since it just works, we can instead stop expecting the sys crates to have them.

[EPashkin]

IMHO generate build script unneeded functionality, as it almost never changed, so not need to update from *.gir. Also in manual way can be checked needed library in os specified way (ex. for Gio-2.0.gir it can always check gio-2.0 and only on linux check gio-unix-2.0).

[gkoz]

I've finally found all the pieces need to replace the features with cfgs set by the build scripts, will make a proof of concept soon. The build script will be responsible for detecting the available library version and setting the cfgs that describe it (similar to current features).

[EPashkin]

Good. You will create issue for discussing "features" in https://github.com/rust-gnome/gtk ?

[gkoz]

Yes.

[EPashkin]

Good work on autodetecting features. Yet still I do not see the point to auto-generate build script.

[gkoz]

For one, they turned out big enough that not using some kind of template is going to be problematic.

[gkoz]

Potentially even Cargo.toml could be partly generated. Since toml is structured, it's possible to rewrite select portions while preserving manual modifications.

[EPashkin]

Agree, but IMHO as with build scripts it better done later, after we make main functionality. We still don't have signals.

[EPashkin]

Found attribute introspectable in GLib-2.0.gir. Don't we need ignore this function?

      <function name="append_vals"
                c:identifier="g_array_append_vals"
                introspectable="0">

[gkoz]

Yes, the auxiliary files can be left for later. I guess the build scripts could be rewritten to be more easily copyable by hand. But they're not very hard to generate either. (BTW does the generator still fail to create the target directory e.g. pango-sys?)

introspectable has to do with dynamic introspection used by dynamic languages that (I believe) process at runtime the type libraries, which are binary platform-specific versions of the GIR. We can ignore it.

[EPashkin]

Creating dir fixed with removing it from test.sh

[EPashkin]

Seems I totally misunderstand what we doing with "features". We add '#[cfg(gtk_3_10)]` to sys crates code or this condition added only in "normal" crates?

[gkoz]

Ultimately both. It's essential in normal crates and nice to have in the sys ones.

[EPashkin]

Marked as done build script and features

[EPashkin]

"foreign" modules still need solution?