Integrating tools with Cabal
roma at ro-che.info
Fri Nov 9 18:25:09 CET 2012
* Mikhail Glushenkov <the.dead.shall.rise at gmail.com> [2012-11-09 18:08:58+0100]
> > Also, is there a way to write a program that would be equivalent to
> > "cabal configure && cabal build" without relying on cabal-install or ghc
> > being installed, just by using the Cabal library? I realise that it
> > would only work for build-type: Simple, but it might be still useful.
> 'cabal build' is equivalent to 'runhaskell Setup.hs build'
> 'cabal configure' is mostly equivalent to 'runhaskell Setup.hs
> configure --user', but uses preferences from ~/.cabal/config.
> So I think that you can just ship a compiled Setup.hs with your
Thanks — this makes sense.
> but you will have to trick 'configure' into thinking that
> you have all dependencies for the packages that you're compiling
> installed (basically you'll have to provide a fake 'ghc-pkg' that
> supports the 'dump' command - with ghc installed, you can just invoke
> the real ghc-pkg).
That's not a problem, I have to maintain my own package database anyway.
> > I tried this, and one problem I ran into is that Cabal invokes the
> > linker on the files that it expects my tool to produce. 'ld' fails, and
> > the build aborts.
> So you're building a library. Looking at buildLib in
> Distribution.Simple.GHC I don't see a way to stop the build before the
> linking phase. But your tool should have already processed all the
> source files at this stage. Maybe you can produce some dud .o files to
> placate ld or just print a message that says something like "Analysis
> complete. Don't worry about the link failure."?
Sorry, I forgot to mention — that actually happens during the configure
My command looks like this:
runghc Setup -v3 configure --ghc --with-compiler=gen-iface --with-hc-pkg=gen-iface
... and the relevant output from Cabal is
searching for ld in path.
found ld at /usr/bin/ld
/usr/bin/ld returned ExitFailure 1 with error message:
/tmp/17368.o: file not recognized: File truncated
Setup: /tmp/17369.o: does not exist
I guess I can fake it by invoking gcc on '-c', but at this stage it
becomes too dirty for my taste.
More information about the cabal-devel