issues with configurations
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
configuration: debug && (HUnit11 || package(HUnit>=1, 1.1))
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.
More information about the cabal-devel