Build system idea

[Duncan Coutts]

Just cleaning out my inbox and realised I meant to reply to this about 4
months ago :-)

On Thu, 2008-09-04 at 23:15 -0700, Iavor Diatchki wrote:

> On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
> > Packages are not supposed to expose different APIs with different
> flags
> > so I don't think that's right. Under that assumption cabal-install
> can
> > in principle resolve everything fine. I'm not claiming the current
> > resolution algorithm is very clever when it comes to picking flags
> > (though it should always pick ones that give an overall valid
> solution)
> > but there is certainly scope for a cleverer one. Also, the user can
> > always specify what features they want, which is what systems like
> > Gentoo do.
> >
> > Do you have any specific test cases where the current algorithm is less
> > than ideal? It'd be useful to report those for the next time someone
> > hacks on the resolver.
> 
> The examples that I was thinking of arise when libraries can provide
> conditional functionality, depending on what is already installed on
> the system, a kind of "co-dependecy".  [...]
> 
> I guess, you could say that we structured the library wrong---perhaps
> we should have had a core package that only provides manual parsing
> (no external libraries required), and then have a separate packages
> for each of the parsers that use a different parsing combinator
> library.
> 
> Conceptually, this might be better, but in practice it seems like a
> bit of a pain---each parser is a single module, but it would need a
> whole separate directory, with a separate cabal file, license, and a
> setup script, all of which would be almost copies of each other.

Right, I admit it might be handy. Unfortunately we could not translate
such packages into other packaging systems because I don't know of any
standard native packaging systems that allow such co-dependencies. They
have to be translated into multiple packages.

If we did support such conditional stuff it would have to be explicit to
the package manager because otherwise choices about install order would
change the exposed functionality (indeed it might not even be stable /
globally solvable).

In particular I've no idea what we should do about instances. Where we'd
like to provide an instance for a class defined in another package that
we do not directly need (except to be able to provide the instance).

If we did not have the constraint of wanting to generate native packages
then there are various more sophisticated things we could do, but
generating native packages is really quite important to our plans for
world domination.

Duncan