finding the dependecies of cabal packages

[Brian Smith]

On 7/27/05, Duncan Coutts <duncan.coutts at worcester.oxford.ac.uk> wrote:
> On Wed, 2005-07-27 at 16:10 -0500, Brian Smith wrote:
> > In short, the cabal package description is not the only information
> > you need to fully describe how to successfully build an application.
> 
> If we hope to have cabal packages properly supported by packaging
> systems (which I believe we do) then this sort of information is
> essential. And I think that it is important that it is discoverable
> automatically. If most packages in the hackage collection require manual
> fiddling and fixing then it will not be practical to mirror the hackage
> collection in normal distro packaging systems.

I think it is essential to be able to tell which build infrastructure
is being used, and which hooks need to be executed, without looking at
Setup.lhs. In fact, I think that the relationship between the Setup.hs
and Package.cabal file is backwards. Imagine that there was no
"Setup.hs," and that every Haskell implementation came with an
executable that could process Cabal files.

Now, let's say a Cabal package descriptions had these entries:

    Build-Infrastructure: Simple
    Hooks: None

This would mean that the Simple build infrastructure is being used,
and that there are no hooks; it is equivalent to
Distribution.Simple.defaultMain. Note that the default value of Hooks
could be "None" and the default Build-Infrastructure could be
"Simple."

If a package description had these entries:
    
    Build-Infrastructure: Simple
    Hooks: Setup (preBuild, postBuild, postClean)

it has the three hooks mentioned, which are exported from the
package's Setup module. Each hook is just a function with the same
type it has from Distribution.Simple.UserHooks. Each implementations's
setup tool would determine how to call these hooks.

Now, if a package description had this entry:

     Build-Infrastructure: Make

Then, tools that don't have Make (e.g. VHS.NET) could gracefully say
"Make is not a supported build infrastructure" or "Cannot build this
package because make is not installed."

Also, imagine being able to do this for a Cabal package that has:
     Build-Depends: HUnit, HaXml
    
$ ghci --cabal My.Module
Loading package base-1.0 ... linking ... done.
Loading package haskell98-1.0 ... linking ... done.
Loading package HaXml-1.13 ... linking ... done.
Loading package HUnit-1.1 ... linking ... done.
My.Module>

instead of:
$ ghci -package HUnit -package HaXml

- Brian