Extending the dependency syntax

[Simon Marlow]

On 28 July 2005 22:36, Duncan Coutts wrote:

> While the sensible normal behaviour might be to just pick up as many
> dependencies as the environment supports, packaging systems like to
> know about all dependencies and control them. For example it is
> normal to build a package on one system and deploy it on another. If
> there are extra dependencies that are picked up (because they happen
> to be in the build environment) it may cause a failure on the target
> system because the dependency is not present.

A very good point.

> As an example consider Gtk2Hs which has a number of optional
> dependencies (libglade, GConf, Mozilla). If you do a normal build then
> it will automatically build all the optional bits for which the
> dependencies are satisfied. This is what casual users want.
> 
> However for packagers we provide a --enable-packager-mode flag which
> turns off all automatic dependency decisions and so the packager must
> explicitly specify --enable-gconf --enable-libglade etc.

Thank you, you've provided an excellent example to demonstrate the
flexibility of the scheme I proposed :-)

I need one more operator, which I'll write ':', and which means the same
as a Prolog cut(!).  Don't worry if you're not familiar with Prolog, all
will become clear.

So here's how you express the Gtk dependencies:

build-depends:
  ("packager-mode":
     ("enable-gconf":    gconf>=1.0    [gconf] ||)
     ("enable-libglade": libglade>=1.0 [libglade] ||)
  ) 
  || (
    (gconf>=1.0 [gconf] ||)
    (libglade>=1.0 [libglade] ||)
  )

In words, this says

  - if "packager-mode" is defined, then
     - if "enable-gconf" is defined then require gconf>=1.0 
       and process the [gconf] stanza
     - if "enable-libglade" is defined then require libglade>=1.0
       and process the [libglade] stanza
  - otherwise,
     - if gconf>=1.0 is available, process the [gconf] stanza
     - if libglade>=1.0 is available, process the [libglade] stanza

I have to admit, I think this is beautiful.  But I'm prepared to believe
that others might prefer to go for something a bit more concrete.  I
imagine that the packager-mode concept is something that we'd want every
package to conform to, so we don't want to require every packager to
write the appropriate build-depends magic.

OTOH, I still like the simplicity of the design.  We could add built-in
packager-mode support like this: (a) --packager-mode causes all
dependencies inside a disjunction to fail by default, and (b)
--enable-foo forces an optional dependency on foo to be required.  So
then the packager just writes

build-depends:
    (gconf>=1.0 [gconf] ||)
    (libglade>=1.0 [libglade] ||)

But this is starting to get a bit subtle.

Cheers,
	Simon