Native -XCPP Conclusion (was: RFC: "Native -XCPP" Proposal)
Herbert Valerio Riedel
hvr at gnu.org
Thu Jun 18 08:32:05 UTC 2015
Hello *,
Following up on the "Native -XCPP" Proposal discussion, it appears that
cpphs' current LGPL+SLE licensing doesn't pose an *objective*
showstopper problem but is rather more of an inconvenience as it causes
argumentation/discussion overhead (which then /may/ actually result in
Haskell being turned down eventually over alternatives that do without
LGPL components).
In order to acknowledge this discomfort, for GHC 7.12 we propose to follow
"plan 4" according to [1] (i.e. calling out to a cpphs-executable as a
separate process), thereby avoiding pulling any LGPL-subjected cpphs
code into produced executables when linking against the 'ghc' package.
"Plan 2" (i.e. embedding/linking cpphs' code directly into ghc) would
reduce fork/exec overhead, which can be substantial on Windows [2],
but plan 4 is no worse than what we have now.
Last Call: Are there any objections with GHC adopting "plan 4"[1]?
[1]: <https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp>
[2]: <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869>
Thanks,
HVR
On 2015-05-06 at 13:08:03 +0200, Herbert Valerio Riedel wrote:
> Hello *,
>
> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
> currently relies on the system's C-compiler bundled `cpp` program to
> provide a "traditional mode" c-preprocessor.
>
> This has caused several problems in the past, since parsing Haskell code
> with a preprocessor mode designed for use with C's tokenizer has caused
> already quite some problems[1] in the past. I'd like to see GHC 7.12
> adopt an implemntation of `-XCPP` that does not rely on the shaky
> system-`cpp` foundation. To this end I've created a wiki page
>
> https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
>
> to describe the actual problems in more detail, and a couple of possible
> ways forward. Ideally, we'd simply integrate `cpphs` into GHC
> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be
> discussed and debated since affects the overall-license of the GHC
> code-base, which may or may not be a problem to GHC's user-base (and
> that's what I hope this discussion will help to find out).
>
> So please go ahead and read the Wiki page... and then speak your mind!
>
>
> Thanks,
> HVR
>
>
> [1]: ...does anybody remember the issues Haskell packages (& GHC)
> encountered when Apple switched to the Clang tool-chain, thereby
> causing code using `-XCPP` to suddenly break due to subtly
> different `cpp`-semantics?
--
"Elegance is not optional" -- Richard O'Keefe
More information about the ghc-devs
mailing list