search

conformal / gotk3

Go bindings for GTK3
ISC License
470 stars 81 forks source link

Notice: Changing import paths #36

Open jrick opened 10 years ago

jrick commented 10 years ago

This issue is being opened to let others know about and track the progress of a change to the import paths for gotk3 packages. This is being done due to increased complexity from adding additional bindings which depend on the current packages in odd ways.

The problem with the current package model is that each component, regardless of its interaction with other packages, gets a top level directory for the package import. This does not parallel the C headers for each component, where subcomponents' headers are installed to a subdirectory of another project. Worse yet, some components are merged into the same package (like GObject bindings in the glib package) and can lead to some strange dependency issues.

As of now, the following new package directory structure is being considered:

Several things to note: First, the gdk package is being moved to a subpackage of the gtk package. GDK is installed and updated with GTK (on my system, GDK headers are installed to /usr/local/include/gtk-3.0/gdk). Second, GObject bindings will be split out of the glib package into a separate gobject subpackage. This will allow other packages (for example, gio) to use gobject without needing the rest of glib, and also preventing any cyclic dependency issues where gio depends on parts of glib, and other parts of glib depend on gio.

Moving packages to being subpackages of other packages also gives more reason for using the top level package go build tags in subpackages. Currently, gtk## build tags are being used in the gdk package. This works because both gtk and gdk are installed and update together. Moving the gdk package helps make this relation even clearer.

Needless to say, this change will require modifying applications to update to the new import paths, or they will not build. In most cases the changes should be trivial (like just changing the imports at the top of each go source code file), but in cases where types like glib.Object or glib.InitiallyUnowned are referenced, the package names will need to be changed to gobject.

Feedback on the planned change is welcome.

weberc2 commented 10 years ago

I appreciate the warning. I have no feedback at this time.