darcs patch: added cppOptions and c2hsOptions

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Tue May 1 10:45:00 EDT 2007

On Sat, 2007-04-21 at 22:35 +0100, Ross Paterson wrote: 
> On Sat, Apr 21, 2007 at 10:32:08PM +1000, Duncan Coutts wrote:
> > I have a patch, I'll send it soonish (probably Monday) for other people
> > to review and test.
> > 
> > It's a general change to the way Cabal does pre-processing. Instead of
> > generating the .hs files in place in the source tree we put them all in
> > a special build tree in the dist dir (like where we put the .o and .hi
> > files, but not actually the same directory).
> I've been meaning to do something like that, to get the generated files
> under dist, and to separate out the compiler-independent part of the code.
> There should be no need for the compiler-specific parts to worry about
> main-is or hs-source-dirs, when the first phase can handle those.
> Another benefit is that we could include compiler-independent preprocessor
> output (where possible) in source distributions.  If the package is
> built in an environment lacking that preprocessor, it can use the
> shipped output.  If the preprocessor is available, it can run it with
> compiler-specific flags (e.g. happy -agc).  Not all preprocessors can
> produce compiler-independent output, though.

I've got it to a half-way house, I've made PreProcessor into a record
data type which records if the pre-processor generates platform
independent output. We should add something about whether the result is
independent of the haskell implementation or not.

( Incidentally, This PreProcessor abstraction is probably the right
place to add things like composing pre-processors, eg .y.pp, .chs.pp
etc. I'm not sure if PreProcessor should incorporate the suffix stuff or
if it should represent a particular use of a pre-processor independent
of some general suffix rule. )

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

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

So how about this, we put generated sources into their own dir, not
dist/build but somewhere else. We separate platform dependent and
independent generated sources. We could even separate impl-dependent
sources from independent ones. Then if you do sdist after a build then
there is no additional pre-processing needed, but if you do sdist from a
clean tree then it will do the pre-processing.

Some thing like:

it would be the gen/platform-independent/ tree that'd be included into
the src tarball. That way when it comes to building from a tarball we
find we don't have to re-run the pre-processor, assuming the file
modification times all work out as expected.

I don't think the gen/platform-independent can live under dist since
that doesn't need to be anywhere related to the build tree and yet this
must be present if we build from a tarball.



More information about the cabal-devel mailing list