installing non-haskell binaries with cabal

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Wed Jun 11 18:52:37 EDT 2008


On Wed, 2008-06-11 at 06:41 -0700, Jonathan Cast wrote:

> > > Yikes.  Every time I learn something new about Cabal, it's /always/ some
> > > new limitation, never a new feature.  Are there any plans to someday
> > > permit doing things with Cabal the Cabal developers haven't added
> > > specific code for yet?
> > 
> > All these things are already possible (if not easy) using custom code in
> > the Setup.hs script and/or using a ./configure script.
> 
> I assume the claim above about cabal-install failing to install such a
> package is incorrect, right?

Right. cabal-install works perfectly well with packages that use custom
Setup.hs scripts. It picks a suitable version of the Cabal library to
build them with.

> Beyond which, to paraphrase what I tell my boss at work, I can get
> Setup.lhs to do anything I want, it's written in a Turing-complete
> language.  But I'd rather not use a tool I'm going to have to fight.

The honest situation is this: the Setup.hs can override hooks into
pretty much every phase of configuration, build and installation (see
UserHooks module) and you can use any of the base and other core libs to
do what you want. So yes, you can do pretty much anything, however the
API to get information out of Cabal and to use its functions is of
variable utility and stability because the API that setup.hs scripts are
expected to use has never been carefully delineated or designed. We now
know a lot more about how it *should* be designed but that's not of any
immediate help to you. So as people say, once you start to need a custom
Setup.hs things become rather harder.

On the other hand it is still probably a good deal easier than writing a
custom build system with make + autoconf and making that easy to
deploy. 

If you find specific tasks you'd like to be able to do but are currently
tricky then file feature requests.

Duncan



More information about the Libraries mailing list