search

conformal / gotk3

Go bindings for GTK3
ISC License
471 stars 84 forks source link

GTK version tags complicate building; propagate this complexity downstream #29

Closed weberc2 closed 10 years ago

weberc2 commented 10 years ago

While it's a little annoying to have to remember to add the -tags gtk_3_x flag to every go build/get/run/install command when I'm building Gotk3, it's even more annoying that contributors to downstream projects need to do this. Would it be possible to remove that requirement? Perhaps the additional API bindings for 3.8 and 3.10 could be added to their own packages such that:

  1. Downstream projects that don't use the newer APIs could import "gotk3/gtk" like normal
  2. Downstream projects that do use a newer API could specify import "gotk3/gtk3.10" or even import "gotk3/gtk/gtk3.10" or some such?

Then contributors to downstream projects wouldn't need to distribute gtk-version-dependent instructions for building/installing/etc their project?

I'm happy to do the legwork, but I would like to discuss the implementation with the community before doing the work. Thoughts?

jrick commented 10 years ago

You have this backwards: gotk3 aims to support the latest GTK release, not any older release with features cherrypicked from a newer releases. Build tags are only really meant as a intermediary solution until developers update (or not necessarily developers themselves, but for when devs begin targeting users on the latest release). When building with GTK 3.10, (currently) no build tags are needed. When the next GTK version releases and gotk3 updates, build tags will need to be used until the system is updated to GTK 3.12.

Yes, this ends up creating a moving target, and it can be a pain for those following the master branch (we have to use gotk3 with 3.8 on Windows for our btcgui MSI), but this is what releases are for. Developers and packagers who (for whatever reason) don't want to use build tags have the option of instead using the latest gotk3 release which targeted the GTK version they need, rather than using the latest github master. (We'll try to be more diligent with releases in the future.)

When gotk3 was first written, GTK 3.8 was the latest release, so that is what the bindings were targeted for. 3.10 support came shortly after, and to not leave developers hanging, the current build tag implementation was used. 3.6 support only came about as a freebie, since due to missing bindings, the 3.6 and 3.8 builds were the same and did not cause any compile-time errors.

The bigger issue here is that I don't want to disable the warnings (and with cgo, errors) for enabling deprecated features. Importing additional packages can only ever add to the available features, not take away. When 3.10 support was added, several <=3.8 macros and functions became deprecated, and had to be removed from the default build. If a developer wanted to use your proposed system to do the same, it would result in compile-time errors due to leaving bindings around for deprecated features in older releases.

The C way of hacking around this is using #ifdefs everywhere, which produces illegible code and can mask all kinds of errors. Go's build tags really are several orders of magnitude better. And it's not just gotk3's source that benefits from this change either: downstream applications can also take advantage of the gtk## build tag nomenclature to support multiple GTK releases, without ever enabling deprecated features, by moving the additional needed implementations to separate files rather than inlining everything in the same source file. As the guy who updated xombrero from GTK2 to GTK3, while still keeping support around for GTK2, I would have died for something as nice as this back then...