[ I didn't see this message when I sent my previous two, sorry.]
On 7/28/05, Simon Marlow
So here's a strawman proposal to address some of the use cases raised recently[1] that Cabal doesn't currently support well. This is just a first attempt; I expect we'll need to make changes or start over if we discover cases that it doesn't handle.
[1] http://www.haskell.org//pipermail/libraries/2005-July/004152.html http://www.haskell.org//pipermail/libraries/2005-July/004133.html
Firstly, we define certain pseudo-packages on which dependencies can be expressed. The pseudo packages would consist of the compilers and pre-processors that Cabal understands, and any other tools required by the build process. eg.
build-depends: ghc>=6.4 happy>=1.5 base>=1.0
This is basically the same thing as what I was trying to do with my proposed "Supported-Configuration." I agree that it makes sense to include them together in build-depends. I seperated them in the hope of backwards-compatibility, but if that is not a requirement then your idea is definitely better.
Now, I suggest we expand the language of dependencies to include disjunction and optional stanzas.
<snip>
The idea is that Cabal evaluates the dependencies trying disjunctions left-to-right, where optional stanzas [foo] are assumed to be satisfied. When a set of satisfying dependencies has been found, Cabal processes all the optional stanzas it contains. We now need to be able to accumulate values from fields specified multiple times, rather than require each field to be specified at most once.
<snip>
Here's an example where a library can be built by multiple compilers, where each compiler requires different modules to be compiled:
---------------- name: mylib version: 1.0 exposed-modules: My.Lib build-depends: base>=1.0 (ghc>=6.4 || ghc>=6.2 [ghc62] || hugs-any [hugs])
[ghc62] other-modules: Compat.Ghc62
[hugs] other-modules: Compat.Hugs -----------------
This covers Duncan's requirements, and Brian Smith's 1(a),1(b),1(d),2(a). 1(c) is not covered yet:
(c) Cabal depends on HUnit if DEBUG is set, but it doesn't depend on HUnit if DEBUG is not set. (The dependency isn't controlled by the existence of a package, but by a configuration option.)
Perhaps the concrete syntax for config is a string (eg. "DEBUG"). We can express the HUnit example now: ---------------- build-depends: base>=1.0 ("DEBUG" HUnit>=1.0 [debug] || [release])
[debug] other-modules: Tests ghc-options: -DDEBUG -Onot
[release] ghc-options: -O ----------------
To me, this is saying "use the debug configuration if "DEBUG" is set and "HUnit" is available, otherwise use the release config." I think that instead, we should have only "use the debug configuration if DEBUG is set, otherwise use RELEASE." We should give an error message to the user when they request the DEBUG version without having HUnit installed, instead of silently using the RELEASE config. We could just say that you can name configurations on the command line, and not have any defaulting mechanism (i.e. you must always request either RELEASE or DEBUG). I think that the [stanza name] syntax is not clear enough. How about "Configuration: [name]"? I am also unsure how to represent my use case 2(a) in your proposal: Build an executable if wxHaskell is available, otherwise skip it. The idea is that the whole build should be a failure if the command-line version's dependencies are not satisfied, but that the GUI can be skipped with just a warning if its dependencies are not satisfied. Would you write "[Executable: gui]" instead of "Executable: gui"? In the example below (modified from yours), I added an "Optional" modifier to the "Executable" stanza syntax to indicate this. ---------------- name: mylib version: 1.0 exposed-modules: My.Lib build-depends: base>=1.0 (ghc>=6.4 || ghc>=6.2 [ghc62] || hugs [hugs]) Optional Executable: gui Build-Depends: wx Main-Is: GUIMain Executable: commandline Main-Is: Main Configuration: DEBUG other-modules: Tests ghc-options: -DDEBUG -Onot build-depends: HUnit>=1.0 Configuration: RELEASE ghc-options: -O Configuration: ghc62 other-modules: Compat.Ghc62 Configuration: hugs other-modules: Compat.Hugs ---------------- - Brian