cabal-install-0.8 final testing

Duncan Coutts duncan.coutts at
Mon Dec 21 09:47:02 EST 2009

On Mon, 2009-12-21 at 12:44 +0000, Simon Marlow wrote:

> > The current Cabal code takes a slightly different approach. It says at
> > the end "oh this exe isn't buildable, so its deps do not contribute to
> > the deps of the package".
> >
> > The problem is what it was doing before that. It sees the dependency on
> > HUnit and checks that it can be satisfied. It's only at the end that it
> > ends up discarding it. So if it was not actually available then it fails
> > earlier.
> I was following the description up until this paragraph (too many "it"s 
> and "that"s, I'm not sure what they all refer to). Don't worry about it 
> if it's hard to explain, but if you have time to elaborate a bit I'd be 
> interested.

Sorry, I'll try again:

There are essentially two stages to the resolution. The main one and a
simple post-processing. The post-processing notes that some components
are not buildable and so ignores the deps from those components.

But that's not good enough because the first stage would already have
failed if those dependencies of the non-buildable component were not
available. So it's no good just doing it as a post-processing stage. We
must properly express the fact that the dependencies are optional and
related to whether or not the component is buildable.

The solver currently does not know that "buildable" is special in any
way. Indeed that it should be special is rather irksome. We had this
field before we added conditionals. We would not have added "buildable"
like this way after adding conditionals. Instead we should have added
things with comprehensible semantics like "fail".


More information about the Glasgow-haskell-users mailing list