On 10/24/06, Duncan Coutts<div><span class="gmail_quote"><b class="gmail_sendername"></b> &lt;<a href="mailto:duncan.coutts@worc.ox.ac.uk">duncan.coutts@worc.ox.ac.uk</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On the other hand, in Gtk2Hs I know one case where we do this. We have a<br>Graphics.UI.Gtk.Cairo api module that is only included if Gtk was built<br>against Cairo. In any case it could be faked by using cpp to just not<br>
export anything rather than not having the module exposed at all. So<br>it's not clear that it's worth banning. Or maybe making it slightly<br>harder is worth it so that people don't get in the habit.</blockquote><div><br>
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?
<br><br>Otherwise, how can you say &quot;I depend on the Gtk package being built with Cairo support&quot; and &quot;I depend on the GUI portion of the foo package?&quot;<br><br>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).
<br><br>Regards,<br>Brian<br></div></div>