finding the dependecies of cabal packages

Duncan Coutts duncan.coutts at
Fri Jul 29 16:17:40 EDT 2005

On Fri, 2005-07-29 at 12:43 -0700, Isaac Jones wrote:
> > For example, an IDE might use the GHC API to implement an
> > "incremental build" feature, which would rebuild projects upon
> > detecting changes to the source files (like Eclipse
> > does). Futhermore, it might want to provide context-sensitive
> > features like autocomplete that Cabal doesn't provide, and that
> > requires knowledge of all source code dependencies in the source
> > code.
> I don't understand what you mean; how does this involve the simple
> build system if you're using the GHC API?

I think the requirements of an IDE on a build system are probably even
more extreme than what I've been banging on about - the needs of
packaging systems.

Packaging systems want quite a bit of flexibility and insight into the
build but don't really care too much about many internals like whether
it is incremental or monolithic. This provides flexibility by allowing
multiple build systems to conform to the same Cabal interface.

However an IDE wants even more. It wants to be able to rebuild
individual files quickly (so dependency tracking is required and linear
build scripts are out). It will want to provide a GUI interface for
changing build system parameters (which means that the build system has
to be declarative, not scripted). And no doubt there are other things

The point is that fulfilling these requirements might be possible for
some imagined future version of the "simple" build system, however if
the Cabal interface is extended to stipulate these same features then it
would exclude most other build system implementations.


More information about the Libraries mailing list