<div dir="ltr">[ Dropping wrong address for Malcolm. ]</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Mathieu Boespflug<br>Founder at <a href="http://tweag.io" target="_blank">http://tweag.io</a>.</div></div>
<br><div class="gmail_quote">On 8 May 2015 at 12:05, Boespflug, Mathieu <span dir="ltr"><<a href="mailto:m@tweag.io" target="_blank">m@tweag.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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)<div><br></div><div>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?<br><div class="gmail_extra"><div><div><br></div></div><div>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.</div><div><div class="h5"><div><br></div>
<br><div class="gmail_quote">On 8 May 2015 at 11:39, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<span><br>
On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote:<br>
> If the intention is to use cpphs as a library, won't the license<br>
> affect every program built with the GHC API? That seems to be a high<br>
> price to pay.<br>
<br>
</span>Yes, every program linking the `ghc` package would be affected by<br>
LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page:<br>
<br>
| - As a practical consequence of the //LGPL with static-linking-exception//<br>
|   (LGPL+SLE), **if no modifications are made to the `cpphs`-parts**<br>
|   (i.e. the LGPL+SLE covered modules) of the GHC code-base,<br>
|   **then there is no requirement to ship (or make available) any source code**<br>
|   together with the binaries, even if other parts of the GHC code-base<br>
|   were modified.<br>
<br>
However, don't forget we already have this issue w/ integer-gmp, and<br>
with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!)<br>
<br>
In that context, the suggestion was made[1] to handle the cpphs-code<br>
like the GMP code, i.e. allow a compile-time configuration in the GHC<br>
build-system to build a cpphs-free (and/or GMP-free) GHC for those<br>
parties that need to avoid any LGPL-ish code whatsoever in their<br>
toolchain.<br>
<br>
Would that address this concern?<br>
<br>
<br>
 [1]: <a href="http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb" target="_blank">http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb</a><br>
<div><div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>