Extending the dependency syntax

Isaac Jones ijones at syntaxpolice.org
Wed Aug 10 23:38:16 EDT 2005

"Simon Marlow" <simonmar at microsoft.com> writes:

> 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 )

What happens now with the issue that Duncan mentioned, where the built
system picks up configuration information from the build / configure
environment that's different from the user's environment?  It could
either pick up too much or too little.  For "too little" we could use
the --enable flags to override the detection mechanism, and maybe a
--disable-all-detection mechanism similar to the -fhide-all-packages
mechanism would be useful.  One problem is that --enable-foo doesn't
necessarily exist for optional dependencies.

Another point: The dependency syntax you show mixes packages and
pseudo-packages like GHC, alex, etc... I don't think we should use the
same syntax / field for this, since in reality, they have separate
namespaces.  In fact you might be insane enough to want to talk about
them separately: maybe you have the haxml library installed, but not
the haxml toolchain... maybe you want the ghc executable, but not the
ghc package...

Stuff like GHC is auto-detected by looking in the PATH, which is
dicier than using the package configuration database for a few

1) we have to pull tricks like: HC-pkg should be found at
   compiler-path++"-pkg".  there may be other special cases out there,

2) we need to add a --with-tool= flag to configure for each tool,
   along with -extra-tool-opts

3) we can only handle tools we know about.

We used to have a distinction between depends and build-depends, but
we threw that away, I think because we weren't using the
non-build-depends stuff at all... I note that having separate depends
vs build-depends fields doesn't actually fix the above problems.  BTW,
are you suggesting that we change the meaning of depends and really
adding a build-depends field?

There are at least four kinds of simple dependencies, not taking into
account configurations:

1) build-depending on packages - which is what depends: means now.
   This is always a build-time dependency.

2) build-depending on executables like GHC - that the simple build
   infrastructure knows about / needs.  It would also be nice if we
   had a more sensible way of adding --with-foo= flags,
   extra-foo-opts, and configure-time detection for stuff in this

3) run-time depending on executables like gpg, gnome, etc.  These are
   likely to be executables that Simple has never heard of before.

4) build-depending on stuff that the simple build infrastructure
   doesn't know about.  This may not be very common, but folks not
   using Distribution.Simple may want to use this field to express
   dependencies too, so it would be nice if we could express
   build-time dependencies on non-package tools which we don't already
   know about.

In reality, there are even more kinds :(

The original request, I believe, was for better support of
tool-depends mainly 2, but perhaps 3 and 4 are also important?  3 is a
very common situation in Debian, and 4 is important for completeness
for systems that don't want to use Distribution.Simple, and maybe for
stuff like libglade?

I have been thinking that Cabal should worry about 1 and 2 only, and
let the OS package system worry about 3 and 4, but Duncan's
requirements open the door to 3, and it's not going to be obvious to
people that they can't talk about tools that Simple doesn't know
about.  In fact, it snuck into the above example.  How the heck does
Distribution.Simple know what version of Mozilla is installed?  Maybe
you didn't really mean that?

But I do think that if we're overhauling the dependency syntax, we
should think about all kinds of dependencies so we don't paint
ourselves into a corner.  1 is the only kind that currently has a
flexible infrastructure; 2 is done now, but can be sloppy sometimes;
as I haven't always added --with-foo= flags when we need them and

But how can we be flexible about 3 and 4?  Are they important?  Is
$PATH searching good enough?  Probably not; how do we discover
versions?  Maybe we should have a database similar to the hc-pkg
database, but for tool dependencies, and we could include stuff like
alex.  But now I'm really drifting into the area of OS package
management systems, and how do we get mozilla to register its version
with the cabal package manager?

Am I being too much of a perfectionist in trying to be complete here?
Should we really just allow 1 and 2 and punt on the rest?  Is it
important to distinguish between 1 and 2?

These are the questions I had in mind when I said earlier that cabal
could become a generic packaging system if we kept going down this

Also, I'm not sure we're really doing gentoo a favor by making the
dependency syntax so complex.  I think Duncan wanted to be able to
automatically parse the cabal file and figure out the dependencies for
alex and such, but now he's faced with:

--enable-mozilla? ( mozilla >= 1.4, [mozilla] ),

so he'll either have to figure all that out, or maybe he'll punt and
suck out only the required dependencies.

>> 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.

Yes, that is still high on my list!  Stayed tuned.



More information about the Libraries mailing list