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