Configurations proposal

[Brian Smith]

On 10/25/06, Einar Karttunen <ekarttun at cs.helsinki.fi> wrote:
>
> On 24.10 21:45, Brian Smith wrote:
> > 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).
>
> The problem is that this creates a very large number of packages which
> may have recursive dependencies (not supported by GHC!).
>
> Also in many cases this would result in 1 package -> 10 packages most
> of which with one module.


Please point out some cases where splitting a package into multiple packages
would lead to recursive package dependencies so I can study them.

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.

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.

If you have that, then the Build-depends field is very useful.

     Build-depends: foo, foo-ghc, foo-windows

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:

    Build-depends: foo

The GHC or Windows requirement is not obvious. "build configure" will not
give you any indication that something is wrong.

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:

    Name: foo
    Version: 2.0
    Build-depends: base >= 1.0

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.

- Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20061025/5bdc4354/attachment.htm