Open ximion opened 8 years ago
The current plan is to make the dynamic linking optional in the stand alone generator, and then switch GtkD over to the stand alone generator, and possibly break it up into smaller libraries (cairod, glibd, gtkd, ...). And at some point stop including the generated code in the repository ( #24 ), or keep it in an separate branch.
It will be a few week until i can resume working on this though.
Yes, that sounds awesome! Would make policy-compliant Debian packaging really easy, and with GLib split out, I could also use it in appstream-generator directly, instead of embedding the generated bindings.
GtkD is now available in Debian and soon Ubuntu as well: https://packages.debian.org/source/sid/gtk-d We need to sort out a couple of issues with LDC first though to make this work properly (current LDC is semi-broken in Debian). Anyway, the GtkD packages available there are usable with code compiled with LDC :-)
Looks like this is possible with the current makefile (with regeneration).
One little problem is that ldflags from gtk's pkgconfig file don't seem to apply when linking (even though SOFLAGS_GTKD
gets them). I've had to add -L/usr/local/lib
to LDFLAGS manually..
Hi! I am packaging GtkD for Debian right now, and life would be much easier if GtkD could link to the current versions of GTK+/Pango/etc. directly, instead of dynamically loading them. This would help our tools to automatically depend on the right versions of the libraries, instead of figuring this out manually and keeping it up to date. It would also give us proof that GtkD is using the right library versions and will work correctly with them. Furthermore, there might be a small speed-gain by having GtkD link to the libs directly.
This could also be a build-time option, to select between dynamically loading the libs or linking them statically. Cheers, Matthias