RFC: "Native -XCPP" Proposal
carter.schonwald at gmail.com
Fri May 8 12:07:07 UTC 2015
Indeed. This is also how we use gcc and the llvm tooling.
If we want the cpp tooling to be available as a library, that's a whole
nother set of needs.
Gmp lgpl I can brush under the rug at work because there's the various
integer simple options, this gets a bit more squirrelly otherwise.
Maybe it'd be simpler for two people to sit down for a weekend, one only
narrating the cpphs code, the other only listening and paraphrasing it into
a new program. Copyright on text only covers literal copying. Nontrivial
rephrasing of everything plus some rejiggering of non local structure is
not prevented by copyright law, and I doubt there are any patents in play.
On Friday, May 8, 2015, Mathieu Boespflug <mboes at tweag.net> wrote:
> [Gah, wrong From: email address given the list subscriptions, sorry
> for the duplicates.]
> 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
> > Hello,
> > 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 code**
> > | 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
> > toolchain.
> > Would that address this concern?
> > :
> > _______________________________________________
> > Haskell-Cafe mailing list
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> ghc-devs mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs