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