state of the cabal (preprocessors)

Isaac Jones ijones at
Wed Oct 27 13:14:57 EDT 2004

"Simon Marlow" <simonmar at> writes:

> On 26 October 2004 22:34, Isaac Jones wrote:
>> "Simon Marlow" <simonmar at> writes:
>> (snip)
>>> 3. We add CPP to the list of extensions in Cabal, so you can say {-#
>>> LANGUAGE CPP #-} to get C preprocessing in the current file, or add
>>> CPP to the list of extensions in the package description to get CPP
>>> on every file.  That doesn't preclude also using a .cpp extension,
>>> but it means you don't have to.
>> For hugs this would mean preprocessing all files and putting the new
>> .hs files into a temp directory and compiling these.
> Yes, modulo Henrik's comments.  I think you mean put the preprocessed
> .hs files into the dist/build/ directory and install them from there.

Right, but I was actually talking about the 'build' step, which is a
bit funny... For the build step, we have to do preprocessing still, so
that the developer or user of VS can use the code.

For the install step, unlike the other systems, we're proposing that
we do the preprocessing here rather than at the build step since
presumably it would be more convinient to be platform independent at
that point?

I'm not sure why this is such a great idea.  For each other haskell
implementation, once you build, it's tied to the platform, and you no
longer need the build tools.  Why not do the same thing for hugs?

Otherwise, the install step won't be based on the sources produced
during the build step, but rather at the unpreprocessed sources.
Usually the build step prepares the sources.

Also, what if there are other preprocessors that have to be run after
cpp?  Are we going to require these to be installed on the target
machine too?

Sorry if I'm going over ground we've already covered... I am in a
training class this week and don't have much internet time.  Feel free
to point me to the archive URLs for any of my questions :)



More information about the Libraries mailing list