On 26 May 2013, at 02:15, Daniel Wagner <wagnerdm@...> wrote:
> On 2013-05-25 07:39, Axel Simon wrote:
>> Hi Daniel,
>> On 25.05.2013, at 02:50, Daniel Wagner <wagnerdm@...>
>>> The more I looked at the gtk3 support we had so far, the more
>>> uncomfortable I got with how different the interfaces were. Since
>>> not really possible for a cabal package to depend on a compilation
>>> I feel like the right thing to do is to split gtk2 and gtk3 support
>>> separate packages. I've begun doing this, and I encourage interested
>>> readers to pull the latest sources and try it out.
>>> There is at least one unfortunate drawback to this: there is now a
>>> pretty fair amount of code duplication between the "gtk" and "gtk3"
>>> packages. Ideas on how to handle this are welcome.
>>> ...in fact, just generally all feedback on this split is welcome. =)
>> Before I try to do a visual diff: Could you detail what got
>> duplicated? Just the cabal file and the Setup.hs? Or are there modules
>> that cannot be customized using CPP flags?
> Actually, quite a lot of things got duplicated. Anything that was *not*
> inside #if's before -- the interface that's common between gtk2 and
> gtk3, which is the bulk of the code, I believe -- is now duplicated
> between the two packages.
> It's not that things *can't* be customized with CPP -- just that
> downstream packages would have no way of influencing which way the CPP
> went. There is a lot of shared interface, but there's also a lot of
> unshared interface, and this means it would be perfectly reasonable to
> write a GUI that targets gtk3 but not gtk2 (or vice versa). But there
> would be nothing you could write in your cabal file that would say "I
> want gtk3 and not gtk2" (or vice versa). You would just have to tell
> your users "well, build gtk2hs with the -fgtk3 flag" and then if they
> have other software that they want to use that tells them "build with
> the -f-gtk3 flag" they're just hosed. They can't do both.
pkg-config treats gtk3 as a whole new package, so it might make sense
for gtk2hs to do the same. But I think we could consider using the
major version. We could call the new one gtk-3.12.x. Cabal should
let you install both gtk-0.12 and gtk-3.12 at the same time.
Am I right in thinking you are building a nice clean Gtk3 source tree
that has no 2.X specific code and #ifdefs (and a Gtk2 one without the
If you are worried about duplicating all the code then another option
would be to stick with the status quo and release two packages
to Hackage with exactly the same code but different .cabal files.
The only difference between these would be how the -fgtk3 flag worked.
We could remove it and hard code the behaviour in the .cabal files.
gtk.cabal with version 0.12.x - would work like -f-gtk3
gtk.cabal with version 3.12.x - would work like -fgtk3
I don't have any strong feelings either way. I suspect a clean Gtk3
source tree will make adding more Gtk3 support easier and #ifdefs
would make keeping Gtk2 code up to date easier.
For gtksourceview and webkit I think multple .cabal files with shared
code using #ifdefs might be best as there is a lot less Gtk3 specific
code in those repos.