Working on a fix for ticket #89
Stephen Blackheath [to cabal-devel]
rubbernecking.trumpet.stephen at blacksapphire.com
Wed May 6 19:00:31 EDT 2009
I had to fix it so the ability to depend on an internally defined
package would fail unless you said 'cabal-version: >= 1.7' - otherwise
there's a risk someone will create a package that doesn't work on older
versions of cabal than the one they're using. Oops.
Stephen Blackheath [to cabal-devel] wrote:
> Now I'm ready to submit this patch for consideration - I have attached
> it in 'darcs send' format. Please review.
> Here it is:
> It has test cases for the new logic, and some tests for old logic (to
> make sure it behaves the same on 22.214.171.124 and HEAD). To test:
> cd tests
> runhaskell suite
> Tested on ghc-6.8.2 and ghc-6.10.2
> Stephen Blackheath [to cabal-devel] wrote:
>> 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
>> 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.
>> Or more to the point, should this be fixed?
>> 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.
>> - 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).
>> - 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.
>> - Make UnitTests compile (though hardly any of the tests pass).
>> 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):
> cabal-devel mailing list
> cabal-devel at haskell.org
More information about the cabal-devel