finding the dependecies of cabal packages

[Brian Smith]

On 7/28/05, ross at soi.city.ac.uk <ross at soi.city.ac.uk> wrote:
> On Thu, Jul 28, 2005 at 11:53:23AM +1000, Bernard Pope wrote:
> > I've been using autoconf and automake for buddha, which though ugly at
> > times, provides a nice path to making packages for various unixy systems
> > (generally I think because this is the standard GNU way of doing
> > things).
> >
> > However, I haven't been able to migrate this over to cabal. One thing
> > that is not clear in my mind is where cabal ends and autotools begin.
> > There seems to be some overlap. Personally, I would love to throw away
> > all the autotools stuff, but I'm not sure if I can easily replicate
> > everything in cabal alone.
> >
> > Is it a goal of cabal to be able to avoid autotools?

It seems to be. The Visual Haskell Studio.NET project uses _just_ the
Cabal package description to build projects. So, if your Cabal project
requires autotools then it won't work in that environment. In general,
it seems like at least the GHC and Hugs teams want to support Windows
users that don't have MinGW/MSYS or Cygwin (which means that they
don't have autotools).

> But if it's just Haskell, finding all the Haskell tools and using those
> to build executables and libraries, Cabal should do that by itself.
> There's currently no way to specify constraints on versions of the
> tools, though.

I agree that not all of the information belongs in the package
description file. For example, if I only have one module that requires
undecidable instances, I don't want to have Extensions:
UndecidableInstances in my project file, because then everything gets
built with overlapping instances turned on. Instead, I would {#-
LANGUAGE UndecidableInstances -#} in one source file (assuming that it
is fixed to work with GHC).

Potentially, we could build a tool that can generate a list of
dependencies that a project has, like this:
     Required-Extensions: OverlappingInstances, MultiParamTypeClasses, CPP 
     Required-Tools: Happy, Alex, HC, GCC
But, this wouldn't tell you which versions of the tools that you
needed (or in the case of HC, which compiler/interpreter and which
version). But, if we had a mapping like this:

     Hugs-1.2.3: OverlappingInstances, MultiParamTypeClasses, ....
     GHC-6.2.2: CPP, OverlappingInstances,  MultiParamTypeClasses, ....
     GHC-6.4.1: GADT, CPP, OverlappingInstances, MultiParamTypeClasses, ....

Then, new automatic tool could say:

     You cannot build this package because it requires 
     language extension(s) that are unsupported by your installed Haskell
     implementation(s):
     Hugs-1.2.3 does not support CPP, GADT
     GHC-6.2.2 does not support GADT

and

     You cannot build this package because it requires the following tool(s):
     Happy: (needed for src/Some/Module/Grammar.ly, ...)
     Alex: (needed for src/Some/Module/Lexer.x, ...)
     HSC2C: (needed for ...)

For determining which version of a tool is required, a package author
could also annotate their package description like this:

     Supported-Configuration: GHC >= 6.4, Happy >= 1.13, Alex >= 2.0
     Supported-Configuration: Hugs >= 1.2.3, Happy >= 1.14, Alex >= 2.0.1

     Tested-Configuration: GHC-6.4.1, Happy-1.13, Alex-2.0,
                  base-1.0, HUnit-1.1, OpenGL-2.0
     Tested-Configuration: GHC-6.4, Happy-1.14, Alex-2.0.1,
                  base-1.0, HUnit-1.1, OpenGL-2.0
     Tested-Configuration: Hugs-1.2.3, Happy-1.14, Alex-2.0.1,
                  base-1.0, HUnit-1.1, OpenGL-2.0

Where, "Supported-Configuration" means "It is supposed to work with
JUST these tools, plus that packages in Build-Depends" and
"Tested-Configuration" means "I assert that it does in fact work with
exactly these versions of these tools and packages."

The new, nonexistant tool mentioned above could help automate the
generation of Supported-Configuration and Tested-Configuration
entries. Also, it would be a valuable tool for processing bug reports.

Would this be enough information for Gentoo/Debian/RPM?

- Brian