[ Dropping wrong address for Malcolm. ] -- Mathieu Boespflug Founder at http://tweag.io.
On 8 May 2015 at 12:05, Boespflug, Mathieu <m...@tweag.io> wrote: > 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 <hvrie...@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 >> _______________________________________________ >> ghc-devs mailing list >> ghc-d...@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
