<[EMAIL PROTECTED]> wrote:
Couldn't you split this into Gtk and Gtk-Cairo packages, where the latter is only built if Cairo is available? Similarly, in your GUI example, couldn't you have seperate foo and foo-gui packages, and only build the foo-gui package if the GUI libraries are available?
Otherwise, how can you say "I depend on the Gtk package being built with Cairo support" and "I depend on the GUI portion of the foo package?"
In general, optional groups of modules should be split off into separate packages, and there should be a way of building a bundle of related packages together (just like one can build a group of related executables together already).
Regards,
Brian
On the other hand, in Gtk2Hs I know one case where we do this. We have a
Graphics.UI.Gtk.Cairo api module that is only included if Gtk was built
against Cairo. In any case it could be faked by using cpp to just not
export anything rather than not having the module exposed at all. So
it's not clear that it's worth banning. Or maybe making it slightly
harder is worth it so that people don't get in the habit.
Couldn't you split this into Gtk and Gtk-Cairo packages, where the latter is only built if Cairo is available? Similarly, in your GUI example, couldn't you have seperate foo and foo-gui packages, and only build the foo-gui package if the GUI libraries are available?
Otherwise, how can you say "I depend on the Gtk package being built with Cairo support" and "I depend on the GUI portion of the foo package?"
In general, optional groups of modules should be split off into separate packages, and there should be a way of building a bundle of related packages together (just like one can build a group of related executables together already).
Regards,
Brian
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
