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