Working on a fix for ticket #89

[Duncan Coutts]

On Wed, 2009-05-06 at 11:50 +1200, Stephen Blackheath [to cabal-devel]
wrote:
> All,
> 
> I'm working on a fix for ticket #89
> (http://hackage.haskell.org/trac/hackage/ticket/89), and I have a
> specific question for the list:
> 
> ----
> If I do this...
> 
> build-depends: base
> Library
>   build-depends: bytestring
> 
> ...then when the library compiles, it will fail to find the Prelude
> (i.e. -package base doesn't get passed to ghc).  Is there a reason why
> the global 'build-depends' doesn't add to all targets (i.e. all exes &
> libs)?  That's what I would expect it to do, but that might be just me.

It's a bug. When we added the new section style syntax most of the
fields that are now put in lib/exe sections were no longer allowed in
the global section. For tedious reasons the parser treats build-depends
differently from most other fields and so for some reason this field is
still allowed in the global section but the value is always ignored.

> Or more to the point, should this be fixed?

The simplest fix for now would be to make it an error to have
build-depends in the global section.

> ----
> 
> The code changes I'm working on also fix a couple of other things, so
> this is the complete list:
> 
>  - Ticket #89: Make it so the executable can depend on the library
> defined in the same package. If hs-source-dirs is used, you can avoid it
> compiling the .hs files multiple times.

Ah yes, because ghc will still pick local files over modules from a
package.

>  - Make it so build-depends: defined in a Library or Executable block
> affects only the build of those components, not all components as
> currently happens. For avoidance of package breakage, this behaviour
> only happens if you specify cabal-version: >= 1.7 (that is, versions
> less than 1.7 are entirely excluded).

Great.

>  - Make a really simple unit test harness using the test-framework
> package, and add some test cases for the new behaviour. The idea is that
> we can gradually integrate existing tests (hunit & quickcheck) into it.

Ok, I'm not familiar with test-framework but from at the description it
sounds good

>  - Make UnitTests compile (though hardly any of the tests pass).

Yeah, that's all the old stuff.

For new code I've been adding pure tests to tests/Test/, for example the
QC tests for the VersionRange and new VersionIntervals type.

> This patch is not yet tidy enough to submit, but it is complete enough
> to actually work for GHC. I would welcome any comments. Here it is
> (against HEAD):
> 
> http://upcycle.it/~blackh/cabal/cabal-ticket-89-v3.patch

Ok, reviewing the v5 version now...


Duncan