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):
Ok, reviewing the v5 version now... Duncan