[Haskell] haddock -cpp ? Cabal support for haddock ?

Benjamin Franksen benjamin.franksen at bessy.de
Fri Apr 22 16:06:04 EDT 2005

On Friday 22 April 2005 17:09, Isaac Jones wrote:
> >> > I'd certainly welcome Cabal support for other haddock features as
> >> > well (--source, --read-interface).  I am not sure where to put all
> >> > these arguments in the .cabal file.
> >>
> >> Cabal doesn't support these yet, though.  Maybe in the future.
> >
> > Dear Isaac,
> >
> > for the next release, I think *every* external program used by Cabal
> > should get a xyz-options (free form) tag to give additional options. We
> > already have them for linker, c-compiler, and hs-compiler, but not yet
> > for preprocessors and doc generators (haddock). This is very easy to
> > implement, does no harm at all, and greatly increases cabal's
> > flexibility as a build tool. (BTW, I can send you a darcs patch if you
> > are too busy at the moment.)
> And in the other thread you said:
> >> > I made the necessary changes for hsc2hs-options in a few minutes
> You added hsc2hs-options to the package description?  Cool.  I'm happy
> to get a patch to add options fields to all the preprocessors and
> haddock and anything else we may have missed.

I'll give it a try.

> There are basically 3 ways that people can customize their packages:
> - the .cabal file
> - the Setup script with UserHooks
> - flags to configure
> I was originally thinking of these extra flags as something to pass to
> configure, but actually putting them in the description file would be
> more consistent with what we have already...

'Flags to configure' is -- at least in my case -- not the correct solution, 
because only the package author knows what extra options are necessary. The 
user shouldn't need to bother with it. I haven't looked very deeply into 
UserHooks yet, but I think passing extra options is common enough to justify 
dot-cabal tags.

> One trick, though, is to make sure that the parser test cases for
> cabal still run when you make the changes.  It's all too common for
> someone to add a field and break the parser or pretty printer.  The
> important thing is that when you parse it, pretty print it, and parse
> it again it comes out the same.   Check out tests/ModuleTest.hs

Ok, I will add test cases and make sure all tests pass before sending 


More information about the Libraries mailing list