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. ----- Ursprungligt meddelande ----- Från: "Herbert Valerio Riedel" Skickat: ‎2015-‎05-‎08 11:02 Till: "Christian Maeder" Kopia: "Malcolm Wallace" ; "glasgow-haskell-users@haskell.org" ; "libraries@haskell.org" ; "ghc-devs@haskell.org" ; "haskell-cafe" Ämne: Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal Hello Christian, (I've re-CC'ed haskell-cafe, assuming this wasn't deliberate) On 2015-05-08 at 09:50:46 +0200, Christian Maeder wrote:

using cpphs is the right way to go!

Rewriting it from scratch may be a good exercise but is (essentially) a waste of time.

However, always asking Malcolm to get source changes into cpphs would be annoying.

Therefore it would be great if the sources were just part of the ghc sources (under git).

Another "problem" might be the dependency "polyparse" that is currently not part of the core libraries.

A scheme was actually discussed privately to address this: We certainly don't want to expose cpphs/polyparse (and text!) as new packages in GHC's global pkg-db. Which we'd end up, if we handled cpphs as the other exposed boot libraries. Therefore we'd only use the few relevant modules from cpphs/polyparse as "other-modules" (i.e. internal hidden dependencies -- i.e. we wouldn't use cpphs/polyparse's .cabal files) compiled into GHC, but not exposed. We'd either create a new Git submodule to hold our "fork" of cpphs/polyparse, or just add it somewhere inside ghc.git

(I guess that replacing polyparse by something else would also be a nice exercise.)

So (for me) the only question is, if Malcolm is willing to transfer control over cpphs to the haskell-community (or ghc head) - of course with due acknowledgements!

I don't think this will be necessary, as we don't need the cpphs-upstream to mirror each modifications immediately. The benefit of the scheme described above is that we'd be somewhat decoupled from cpphs' upstream, and can freely experiment in our "fork", and can sync up with Malcolm from time to time to merge improvements in both directions. -- hvr _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

[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 wrote:

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 static-linking-exception// | (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 static-linkage-exception!)

In that context, the suggestion was made[1] 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?

[1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_prop... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

To clarify my point more concretely: Adding cpphs the cli tool to ghc build process / bin dist has no more licensing implications than does using gcc as a compiler / assembler. Ie NONE Using cpphs as a library is Another discussion. But I don't think it's the one we're having today. On Friday, May 8, 2015, Carter Schonwald wrote:

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 javascript:_e(%7B%7D,'cvml','mboes@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.

...

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 static-linking-exception// | (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

On 8 May 2015 at 11:39, Herbert Valerio Riedel wrote: 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 static-linkage-exception!)

In that context, the suggestion was made[1] 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?

[1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_prop... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs