state of the cabal (preprocessors)

[Simon Marlow]

On 19 October 2004 18:03, Malcolm Wallace wrote:

>> I agree with Henrik about doing the preprocessing for Hugs at
>> installation or packaging time, so that users don't need the full
>> environment. 
>> That's what currently happens with the fptools libraries.
> 
> OK, so I think we are probably agreed on this then:
> 
>   * When Cabal is installing for Hugs, it does 'cpp -D__HUGS__'
>     (or equivalent) on all Haskell source files, as it copies them
>     into the installation location.

Sure, I thought that was the plan already?  For Hugs, "compiling"
consists of preprocessing and nothing more.
 
> If any more complicated situations arise between the ordering of
> cpp and other preprocessors, use a chain of file extensions to
> disambiguate?  e.g.
>    .ly.cpp  = cpp first -> .ly, then literate happy to get .hs file.
>    .cpp.ly  = literate happy -> .cpp.hs, then cpp to get plain .hs
> file. 

The second example is inconsistent - if the convention is that the
suffix at the end of the filename specifies the topmost layer, then
.cpp.hs is a plain Haskell file (whereas .hs.cpp would be Haskell to be
processed with CPP).  You'd have to modify Happy to generate .hs.cpp
from .ly, or do this with an explicit -o option to Happy.

While consistency is a good thing, in this case I'm not convinced.
Converting all my .hs files to .hs.cpp is going to be really painful.
Plus it's not really a compiler-independent CPP phase because of the
preprocessor symbols injected by the compiler.

I think a special case for CPP is in order, because (at least in my
experience) a lot of Haskell is CPP'd.  All of GHC and most of the
libraries are CPP'd for example.  

So I'd be happy if Cabal had a package-wide CPP flag.  That is, with the
flag on, all .hs and .lhs files in the package are CPP'd.  Think of it
as a flag that affects the language, in the same way that we turn on
various Haskell extensions via flags (I know the analogy isn't perfect).

If you want per-file granularity, then a directive in the Haskell file
would be fine.  GHC currently uses {-# OPTIONS -cpp #-}, but I'd be
happy to implement a different syntax.

Cheers,
	Simon