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