SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal
m at tweag.io
Fri May 8 10:06:09 UTC 2015
[ Dropping wrong address for Malcolm. ]
Founder at http://tweag.io.
On 8 May 2015 at 12:05, Boespflug, Mathieu <m at tweag.io> wrote:
> I'm unclear why cpphs needs to be made a dependency of the GHC API and
> included as a lib. Could you elaborate? (in the wiki page possibly)
> Currently, GHC uses the system preprocessor, as a separate process.
> Couldn't we for GHC 7.12 keep to exactly that, save for the fact that by
> default GHC would call the cpphs binary for preprocessing, and have the
> cpphs binary be available in GHC's install dir somewhere?
> fork()/execvce() is cheap. Certainly cheaper than the cost of compiling a
> single Haskell module. Can't we keep to this
> separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep most
> license tainting concerns that way.
> On 8 May 2015 at 11:39, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
>> On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote:
>> > If the intention is to use cpphs as a library, won't the license
>> > affect every program built with the GHC API? That seems to be a high
>> > price to pay.
>> Yes, every program linking the `ghc` package would be affected by
>> LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page:
>> | - As a practical consequence of the //LGPL with
>> | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts**
>> | (i.e. the LGPL+SLE covered modules) of the GHC code-base,
>> | **then there is no requirement to ship (or make available) any source
>> | together with the binaries, even if other parts of the GHC code-base
>> | were modified.
>> However, don't forget we already have this issue w/ integer-gmp, and
>> with that the LGPL is in full effect (i.e. w/o a
>> In that context, the suggestion was made to handle the cpphs-code
>> like the GMP code, i.e. allow a compile-time configuration in the GHC
>> build-system to build a cpphs-free (and/or GMP-free) GHC for those
>> parties that need to avoid any LGPL-ish code whatsoever in their
>> Would that address this concern?
>> ghc-devs mailing list
>> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs