state of the cabal (preprocessors)

[Graham Klyne]

This has me thinking that it might be helpful if Cabal's package config 
file allowed package filenaming conventions to be specified (with 
appropriate defaults so that most packagers don't have to worry about it).

#g
--

At 14:12 20/10/04 +0100, Simon Marlow wrote:
>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
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact