darcs patch: added cppOptions and c2hsOptions

[Ross Paterson]

On Tue, May 01, 2007 at 03:45:00PM +0100, Duncan Coutts wrote:
> Also, I've still got the platform-independent pre-processed files going
> back into the src dirs. This isn't nice. The only reason I'm doing that
> is not to break sdist, however we should probably do that differently
> anyway.
> 
> For example at the moment you need to have done a build for the
> pre-processed sources to exist in the src dir. Perhaps sdist should
> just generate the platform independent (and impl-independent) sources
> directly into the temp dir where we make the tarball. Then during
> builds we can put them all into the dist/build dir.

Certainly.  Building (using specialized preprocessing) ought to be
separated from constructing source packages (which requires portable
preprocessor output).

> The only downside to this
> is if generating the sources is expensive. Sometimes it is indeed
> expensive, happy can take quite a while on large grammars and in Gtk2Hs,
> generating 100+ .hs files with c2hs takes a minute or two on a fast box.

I wonder if optimizing this is worth the increase in complexity (and
where does it end -- you need platform-specific versions to avoid the
c2hs runs).

I was after something less ambitious: including portable preprocessor
output in a source package so that people can build it even if they
don't have the preprocessor.  (Their build may be sub-optimal, though.)
That could be done by mapping each suffix to a pair of functions

        portable :: BuildInfo -> LocalBuildInfo -> Maybe PreProcessor
        specific :: BuildInfo -> LocalBuildInfo -> Maybe PreProcessor
for
        type Preprocessor =
                (FilePath, FilePath) -> (FilePath, FilePath) -> Int -> IO ()

The first one would be used in sdist; if the portable preprocessor is
available, add its output to the source package.

The second function would be used in build; if the specific preprocessor
is unavailable, copy the .hs version of the module (which, if present,
should be portable preprocessor output).  (Presumably if the portable
preprocessor is available the specific one is too, but we don't need to
use that.)

BTW, since you're now collecting Haskell files in a single build
hierarchy, you could copy the main-is to Main.[l]hs in that hierarchy,
and also generate the Paths module directly there instead of in autogen.

BTW2, building under Hugs will now require two directories under dist:
one for the (build-specific) preprocessor output and another for the
build outputs, which may be obtained from those using cpphs and ffihugs.