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.
I understand that Gotk3 is manual bindings, but is there anything holding us back from going incremental and lessening the burden during binding generation.
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.
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.And the version selection during build is done using Inverted selection.
I understand that Gotk3 is manual bindings, but is there anything holding us back from going incremental and lessening the burden during binding generation.