redundant code generation

[rythmkraze]

I notice that the binding generation in Gobbi is not incremental for newer versions of the Gtk library. I have not run the code generation tool myself, but it appears to be a lot of work to regenerate the same bindings over and over for different versions.

While going through the Gotk3 codebase, I found that their binding files are named *_since_<version>.go and only newer API's are found in the newer version file.

gtk_since_3_22.go
gtk_since_3_20.go

And the version selection during build is done using Inverted selection.

// +build gtk_3_6,!gtk_3_8,!gtk_3_10,!gtk_3_12,!gtk_3_14,!gtk_3_16,!gtk_3_18,!gtk_3_20

I understand that Gotk3 is manual bindings, but is there anything holding us back from going incremental and lessening the burden during binding generation.

[pekim]

I've experimented with this a bit in the past. I found that when the code to be compiled was split across more files, it took longer to build. I suspect that this was mostly related to the heavy use of cgo.