RFC: "Native -XCPP" Proposal

[Carter Schonwald]

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 <carter.schonwald at gmail.com> 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 <mboes at tweag.net
> <javascript:_e(%7B%7D,'cvml','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>
>> 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_proposal/cr1cdhb
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150508/b1289c1c/attachment.html>