Extending the dependency syntax

[Simon Marlow]

On 10 August 2005 06:56, Brian Smith wrote:

> On 8/9/05, Simon Marlow <simonmar at microsoft.com> wrote:
>> ------------------
>> build-depends:
>>           ghc? (ghc >= 6.4, [ghc64] | ghc >= 5.04, [ghc-old])       
>>         | hugs? [hugs], debug?
>>            (HUnit-1.0, [debug])
>>            [release],
>>         gnome? ( libglade >= 2,
>>                  gtksourceview >= 0.6,
>>                  gconf >= 2, [gnome] ),
>>         mozilla? ( mozilla >= 1.4, [mozilla] ),
>>         doc? ( haddock >= 0.6 )
>> 
>> [gnome]
>> extra-libraries: gnome
>> extra-ghc-options: -DENABLE_GNOME
>> ...
>> 
>> [debug]
>> extra-ghc-options: -O0 -DDEBUG
>> 
>> [release]
>> extra-ghc-options: -O2
> 
> As described, it seems like I would need to pass "--enable-hugs" or
> "--enable-ghc" explicitly, or else this program's build would fail.
> But, I don't think that is your intention; instead you are intending
> for Cabal to automatically enable these flags as appropriate, right?
> Perhaps there would be other automatic flags too, like "windows" and
> "unix"?

Actually I made a mistake in the above example, I meant to write

build-depends:
          ghc? (ghc >= 6.4, [ghc64] | ghc >= 5.04, [ghc-old])       
            (hugs? [hugs])

but anyway, this syntax has caught several people out, me included, so
we should pick something better (again).  It seems that most people
would be happier if

  x? (a) | b

means b if x is false.  I think we can fix it, though.  How about this
syntax:

deps   ::= choice
         | choice ',' deps

choice ::= alt1 '|' ... '|' altN  (n >= 1)
         | adep

alt    ::= adep '?' adep

adep   ::= pkg version-range
         | '(' deps ')'
         | --enable-flag
         | true

The point is that now a disjunction is always of the form  (x1?(a1) |
... | xn?(an)), and the meaning is that we take the leftmost branch for
which x is true.  It's a case statement.

Also, to avoid some of the overloading you pointed out, I'm writing
flags as --enable-flag.

The example in this syntax:

build-depends:
          --enable-ghc? (
              ghc>=6.4  ? [ghc64] |
              ghc>=5.04 ? [ghc-old])
        | --enable-hugs? [hugs]
        | true ? true,  -- other compilers are allowed
        --enable-debug? (HUnit-1.0, [debug]) | true? [release]
        --enable-gnome? ( 
                 libglade >= 2,
                 gtksourceview >= 0.6,
                 gconf >= 2, [gnome] ),
        --enable-mozilla? ( mozilla >= 1.4, [mozilla] ),
        --enable-doc? ( haddock >= 0.6 )

I'm not wildly excited about "true ? true", but we could add special
syntax for that if it turns out to be used often.

> Can configurations contain their own "Build-depends", like this?:
> 
>     [windows]
>     Build-depends: Win32
>     extra-libraries: gnome

The problem I have with this is that it means you can only decide
dependencies based on the settings of flags, rather than the other way
around.  We use both in the above example - [ghc64] is decided based on
the availability of ghc versions, whereas [mozilla] is chosen based on a
configuration flag.  You had to hack it in your example:

> I think it would be clearer to specify the configuration seperately,
> like this: 
> 
>     configuration:
>           ghc >= 6.4 ? [ghc64] | ghc >= 5.04 ? [ghc-old]) | hugs?
>           [hugs], debug enabled ? [debug] | [release],
>           gnome enabled ? [gnome],
>           mozilla enabled ? [mozilla],
>           doc enabled ? [doc]
>     -- the "global" Build-depends applies to everything
>     Build-depends: base >= 1.0, haskell98 >= 1.0

So configuration contains dependencies like ghc >= 6.4.  I think it's
clearer to put all the dependencies in one place.

> Finally, are you intending to allow multiple executable stanzas inside
> configurations?:

I've been avoiding this issue for now.  I believe we need to completely
redesign the way multiple executables are handled, and provide a more
general framework for a package that contains multiple libraries &
executables (essentially a wrapper for multiple packages with
interdependencies).  I know Isaac is thinking about this too.  Let's
deal with one issue at a time.

Cheers,
	Simon