Working on a fix for ticket #89

[Stephen Blackheath [to cabal-devel]]

Newer version...
http://upcycle.it/~blackh/cabal/cabal-ticket-89-v5.darcs-send

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.


Steve

Stephen Blackheath [to cabal-devel] wrote:
> All,
> 
> Now I'm ready to submit this patch for consideration - I have attached
> it in 'darcs send' format. Please review.
> 
> Here it is:
> http://upcycle.it/~blackh/cabal/cabal-ticket-89-v4.darcs-send
> 
> It has test cases for the new logic, and some tests for old logic (to
> make sure it behaves the same on 1.6.0.3 and HEAD).  To test:
> 
> cd tests
> runhaskell suite
> 
> Tested on ghc-6.8.2 and ghc-6.10.2
> 
> 
> Steve
> 
> 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.
>>
>> 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):
>>
>> http://upcycle.it/~blackh/cabal/cabal-ticket-89-v3.patch
>>
>>
>> Steve
>>
> 
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>