darcs patch: added cppOptions and c2hsOptions

[Duncan Coutts]

On Wed, 2007-05-02 at 00:31 +0100, Ross Paterson wrote:
> 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 talking nonsense I realise. Of course for building the sdist we
don't run c2hs anyway, we only generate the platform-independent .hs
files. So the only one of those that takes time is happy and that never
takes that long and people typically do not have dozens of .y files in a
project (unlike .chs/.hsc files).

> 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.)

Hmm, so then for example most people will end up not getting the fastest
possible haddock since the tarball will contain only the generic happy
parser. Actually won't everyone using the haddock tarball get the slow
parser even if they do have happy installed because the normal thing is
to not rebuild the pre-preocessed file if it was modified later?

> 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.)

Oh ok, so that does deal with the haddock tarball containing the generic
parser but me having happy installed on the system and ending up with
the fast parser.

> 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,

Why would we want to do that?

> and also generate the Paths module directly there instead of in autogen.

Yes.

> 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.

Ah yes, indeed.

Duncan