Extending the dependency syntax
brianlsmith at gmail.com
Thu Jul 28 16:13:10 EDT 2005
[ I didn't see this message when I sent my previous two, sorry.]
On 7/28/05, Simon Marlow <simonmar at microsoft.com> wrote:
> So here's a strawman proposal to address some of the use cases raised
> recently 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.
>  http://www.haskell.org//pipermail/libraries/2005-July/004152.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.
> 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.
> 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
> (ghc>=6.4 || ghc>=6.2 [ghc62] || hugs-any [hugs])
> other-modules: Compat.Ghc62
> 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:
> ("DEBUG" HUnit>=1.0 [debug] || [release])
> other-modules: Tests
> ghc-options: -DDEBUG -Onot
> 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
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.
(ghc>=6.4 || ghc>=6.2 [ghc62] || hugs [hugs])
Optional Executable: gui
ghc-options: -DDEBUG -Onot
More information about the Libraries