SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal

Herbert Valerio Riedel hvriedel at gmail.com
Thu May 21 10:31:43 UTC 2015


Hi Yitzchak,

On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote:

[...]

> Bardur Arantsson wrote:
>> I don't see any need for an option. Just bundle cpphs together with GHC
>> and build/use it as an external program. AFAICT this has absolutely no
>> licensing implications for GHC, derived from GHC or anything compiled
>> with GHC.
>
> Agreed, that would work. But I thought that the idea was that we wanted
> it actually integrated into GHC.

That would be the preferred way from a technical standpoint, as it would
avoid fork/exec and make it easier to integrate the CPP-phase tighter
into the lexer/parser.

However, due to the, sadly, mostly non-technical issues brought up, it
seems to me that isolating cpphs into a separate process (w/ the option
to configure GHC to use some other cpp implementation at your own risk
if you need to avoid the cpphs implementation at all costs) would be the
compromise acceptable to everyone in the short run while addressing the
primary goal to decouple the default-configuration of GHC from the
fragile system-cpp semantics.

NB: Nothing's been decided yet by GHC HQ


PS: As an observation,

     http://packdeps.haskellers.com/reverse/cpphs

    shows that cpphs is already used by popular packages like hlint and
    haskell-src-exts (and thus an indirect build-dep of the
    haskell-suite project). Therefore, if LGPL+SLE is unacceptable in
    some work-environments, it may require some vigilance to keep track
    where cpphs may sneak into as a build-dependency... I'm surprised
    there's still such resistance given the ubiquity of Linux
    distributions made up of numerous (L)GPLed components, IMHO it's
    kinda like tilting at windmills...

Cheers,
  hvr


More information about the ghc-devs mailing list