Distribution.PreProcess

[Isaac Jones]

Ross Paterson <ross at soi.city.ac.uk> writes:

> A couple of remarks about the current design:
>
> Currently the output of preprocessing is left in the same directory as
> the source.  

Yeah, I don't like this.  I hope to fix it.

> For Hugs, it would be more convenient to preprocess a source
> tree to make a new tree, especially if cpp turns Foo.hs into Foo.hs.

We originally had it move all the files into a temporary spot, then
preprocss, then build.  One problem with that, of course, is the
threat of an IDE bringing up an error in one of the files that's been
moved, the user fixing it, running the build again, and having the
same error.

> The restriction to extensions delimited with '.' rules out things like
> *_hsc_make.c (portable output of hsc2hs).

Can you make a small example of this for me to put in my test
directory?

> It might be preferable not to unlit .lhs files, as all implementations
> can handle them, and the originals are better for human readers (such
> as Hugs users curious about their libraries).  There's no real need to
> unlit .ly files either, though some other preprocessors will need it.
> (And should unlit be treated as just another preprocessor?)

Yeah... should we get rid of the unlit preprocessor?

> As I understand it, preprocessing with cpp is only needed for Hugs,
> as the compilers have -cpp flags, and will do it properly
> themselves.  For Hugs, cpp will need a -D__HUGS__ option, plus extra
> options that are often system-dependent (and will also be needed by
> the compilers).  This harks back to the need to separate
> system-dependent build parameters from the package description, and
> provide hooks to generate and use them.

I'll try to think more about this.

peace,

  isaac