finding the dependecies of cabal packages

[Duncan Coutts]

On Wed, 2005-07-27 at 16:10 -0500, Brian Smith wrote:
> On 7/27/05, Duncan Coutts <duncan.coutts at worcester.oxford.ac.uk> wrote:
> > In particular the ebuild must list all the dependencies of the package.
> > Required Haskell libraries are listed in the "build-depends:" field in
> > the cabal file, so that one is easy. However it is not clear how to find
> > out the build tools that the cabal package requires.
> 
> First of all, you would  have to parse the Setup.lhs/Setup.hs file to
> determine which build infrastructure is being used, whether any hooks
> are being used, etc. Assuming that the build infrastructure is
> "Simple" and there are no hooks being used, then you have choices:
> 
> (1) You could build a compiled version using GHC and the tools that
> come with it, (2) You can build an interpreted version using Hugs and
> the tools that come with it.
> 
> However, I think there are going to be a lot of cases where the
> application can only be built with GHC. You would have to parse each
> file for {-# OPTIONS #-} and {-# OPTIONS_GHC #-}
> 
> 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.

If cabal packages can be adapted to 'native' packages easily (be that
windows MSI installers, .deb .rpm etc) then it will allow Haskell
libraries/programs to be distributed much more easily and to a wider
audience.

I think this aspect of Cabal has not got enough attention yet. Perhaps
the people who package haskell programs/libs for the major systems
(Debian, Gentoo, Fedora, MacOS X, FreeBSD, Windows) should get together
and think about our requirements.

Duncan