[Haskell-cafe] Listing package dependencies from GHC

[Duncan Coutts]

On Thu, 2007-05-03 at 16:49 +0200, Thomas Schilling wrote:
> >  By dependencies I
> > meant, library packages that GHC knows about.
> >
> > For example, if I load something simple like
> >
> >> import System.Posix.Files
> >> main = touchFile "example"
> >
> > into GHCi and execute ":main" it prints
> >
> >> Loading package unix-1.0 ... linking ... done.
> >
> 
> Oh, right.  Well, then please file it as a bug report on Cabal.  I'll  
> be working on Cabal configs as my Summer of Code project; this is  
> clearly related.  With a bit of luck it'll be done before end of August.

This is not a Cabal bug. By design, Cabal does not just pick up any
packages from the environment like --make does. One of the main points
of Cabal is to be able to explicitly track dependencies of a package, so
we do require that they all be listed explicitly. Cabal then tells ghc
to *only* look in those listed packages and ignore all others even if
they happen to be installed.

Now certainly it would be nicer if ghc+cabal could be more helpful and
tell you all the missing packages that you need to list in the
"build-depends" field in the .cabal file, rather than currently where
you have to do it one by one.

This feature could be implemented in GHC, or it could actually be
implemented in Cabal. To do it in cabal requires that cabal gain an
infrastructure for doing dependency analysis of modules. We don't have
that yet. We do need this infrastructure anyway though, since for
example some pre-processors (notably c2hs) need to be called in
dependency order. It would also allow other nice things like having
cabal work out for you exactly which pre-processors and build tools are
required, and make partial and parallel rebuilds possible.

I'm not sure that's in scope for this SoC project but if anyone wants to
volunteer to look at this project then that'd be a great service to the
community. There's quite a bit of existing code to look at, in ghc, yhc,
jhc and hmake which already do some kind of dependency chasing. We'd
need that plus make it extensible to arbitrary pre-processors (eg using
suffix rules, .y -> .hs, .hs.pp -> .hs)

Duncan