cabal: question on compiling build prerequisites

[Peter Selinger]

Henning Thielemann wrote:
> 
> On Fri, 6 Dec 2013, Peter Selinger wrote:
> 
> > My current solution is to make the pre-processor a shell script,
> > rather than a Haskell program. But this is ugly and not portable
> > (won't work in Windows, for example).
> >
> > To clarify: my custom preprocessor is local to this package. It has no
> > independent value, so it would not make sense to publish it as a
> > separate package just so that I can add it to build-depends.
> >
> > Is there a known solution to this problem?
> 
> I have not tried this solution but I would guess that it is a good idea to 
> put the preprocessor in a separate package anyway, since it might have its 
> own build-depends.

I'd like to report on how I resolved these issues in the end. In a
way, I followed your suggestion after all. But rather than putting
just the preprocessor in a separate package, I put my entire build
system in a separate package. Actually, this turned out rather nicely,
because now other packages can use it too.

The build system in question is now the package superdoc:
http://hackage.haskell.org/package/superdoc

Its purpose is to extend Haddock's markup language with new markup:
for example, superscripts, boldface, images, and Unicode. It's
implemented as a bunch of UserHooks for a Setup.hs script and a
preprocessor.

What makes this particular use of a preprocessor interesting is that
the preprocessor is only used for building documentation, not for
building the actual code. Because it is now in a separate package,
other packages can use it transparently (the preprocessor will already
be installed). An example of a package using superdoc is newsynth:
http://hackage.haskell.org/package/newsynth.

The only slight complication is bootstrapping: Superdoc's own
documentation uses Superdoc markup. This creates a chicken-and-egg
situation, where the preprocessor may not yet be installed by the time
it needs to be used. It cannot be resolved with "build-tools" or
similar settings, because the library is a prerequisite of the
preprocessor, and the preprocessor is a prerequisite of the
documentation of the library (but not the library itself). 

To resolve this, I bit the bullet and used shell scripts as wrappers
for invoking the preprocessor via runhaskell. I provided both .sh and
.bat versions of the shell script (as well as code to decide which one
to run), so hopefully this is now fully portable. Tested under Linux
and Windows.

Thanks for all your feedback and suggestions! -- Peter