issues with configurations

Simon Marlow simonmarhaskell at gmail.com
Fri Aug 11 07:15:26 EDT 2006


Einar Karttunen wrote:

> 2) HUnit
> 
> build-depends: Flag(debug) ? 
>                (Flag(Hunit11) ? (HUnit-1.1),
>                 !Flag(Huni11) ? (HUnit >= 1, Hunit < 1.1 || > 1.1))
> 
> flag: debug   = !True
> flag: HUnit11 = HUnit-1.1 && !(Hunit > 1.1)
> 
> configuration: Flag(HUnit11)
> ghc-options: -DHUNIT11
> 
> This seems quite complex. But it works - the meaning is:
> * if debug flag is set then:
> * if HUnit11 is set depend on on HUnit-1.1 and -DHUNIT11
> * if HUnit11 is not set depend on version of HUnit
>   that is >1 and (<1.1 or >1.1) that is not 1.1
> * thus the -D is correct
> * the guess is just a guess and does not affect the semantics

What can I say?  yeuch!  I think we've left simplicity behind here.

One goal (that I keep having to remind myself of) is that a .cabal file should 
be modifyable by an IDE such as Visual Haskell.  I can't see Visual Haskell 
being able to successfully modify that complicated build-depends expression. 
This is one reason I decided to go the simpler route of individual 
configurations with conditionals, and why a conditional could be evaluated 
independently of all the others knowing only facts about the environment.

FWIW, using my original syntax and semantics, here's how to do what you did above:

configuration: debug && !Hunit11
build-depends: HUnit >= 1

configuration: debug && HUnit11
build-depends: HUnit-1.1

configuration: debug && (HUnit11 || package(HUnit>=1, 1.1))
ghc-options: -DHUNIT11

The whole thing is easier to understand IMO, and it's simple to implement too: 
no ordering, conditionals can be evalutated independently.

I'm back to the two-argument package() conditional, because it's actually 
useful.  package(Hunit>=1, 1.1) is not the same as package(HUnit-1.1) or even 
package(HUnit>=1 && 1.1).  It says "the dependency HUnit>=1 resolves to version 
1.1", which is exactly what you wanted to know.  This is how you write 
conditionals that test the versions of packages you actually depend on, which is 
the criticism raised by Duncan at the beginning of this thread.  I believe my 
original syntax addressed this concern.

Now there are bad things that you can do with this syntax (auto-optional 
dependencies), and there are downright ridiculous things you can do with this 
syntax (test versions of packages you don't depend on), but I believe we could 
either make Cabal warn about those or disallow them altogether.  I don't mind which.

Cheers,
	Simon


More information about the cabal-devel mailing list