On 10/25/06, <b class="gmail_sendername">Einar Karttunen</b> <<a href="mailto:ekarttun@cs.helsinki.fi">ekarttun@cs.helsinki.fi</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 24.10 21:45, Brian Smith wrote:<br>> In general, optional groups of modules should be split off into separate<br>> packages, and there should be a way of building a bundle of related packages<br>> together (just like one can build a group of related executables together
<br>> already).<br><br>The problem is that this creates a very large number of packages which<br>may have recursive dependencies (not supported by GHC!).<br><br>Also in many cases this would result in 1 package -> 10 packages most
<br>of which with one module.</blockquote><div> <br>Please point out some cases where splitting a package into multiple packages would lead to recursive package dependencies so I can study them. <br><br>I understand that this would increase the number of packages. But, if it would increase the number of packages 10x, then that means that the original package could be configured with 10 different subsets of functionality. In that case, saying "Build-depends: foo" for that package foo would be almost meaningless. You would need to add some kind of more specific dependency like "Build-depends: foo (
Foo.Bar.A, Foo.Bar.C, Foo.Bar.D)" to indicate what modules you need from foo.<br><br>Packages should be created in such a way that the set of things exported from the package should not change based on configuration. If some features are only valid under one configuration, then they should be factored out into a seperate module and then a seperate package. For example, GHC-specific features should be factored out into a separate package, Windows-specific features should be factored out into a separate package, etc. More-or-less, that is how the hierarchical libraries are designed at the module level.
<br><br>If you have that, then the Build-depends field is very useful.<br><br> Build-depends: foo, foo-ghc, foo-windows<br><br>Here, it is clear that the package will only work on GHC on Windows. "build configure" will tell you what is wrong. If all of these packages remained together as one package, you would have:
<br><br> Build-depends: foo<br><br>The GHC or Windows requirement is not obvious. "build configure" will not give you any indication that something is wrong.<br><br>The same issue comes up when you want to allow a package to build against either
base-1.0 or base 1.1, exposing more features if built with 1.1. We would have something like this:<br><br> Name: foo<br> Version: 2.0<br> Build-depends: base >= 1.0<br><br>If I build package foo with base 1.0, then I am going to be missing some features from it. The dependency "foo >=
2.0" doesn't fully describe the dependency. We could change it to " foo >= 2.0, base >= 1.1," but I'm not sure that means "I depend on foo 2.0 or later being built with base 1.1 or later" and furthermore, it means that packages' dependencies are not self-contained.
<br><br>- Brian<br><br></div></div>