On 21/05/15 19:07, Herbert Valerio Riedel wrote:
Don't you still have to support -pgmF?
I guess so, unfortunately... so we'd have to keep a legacy code-path for
external cpp processing around, at least in the short run...
It's not just about legacy; -pgmF is used for all sorts of awesome
Hi Yitzchak,
On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote:
[...]
Bardur Arantsson wrote:
I don't see any need for an option. Just bundle cpphs together with GHC
and build/use it as an external program. AFAICT this has absolutely no
licensing implications for GHC, derived from GHC or
On 05/21/2015 12:31 PM, Herbert Valerio Riedel wrote:
Hi Yitzchak,
On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote:
[...]
Bardur Arantsson wrote:
I don't see any need for an option. Just bundle cpphs together with GHC
and build/use it as an external program. AFAICT this has
On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
Performance isn't (my) motivation for avoiding fork/exec (and the
equivalent on Win32) but rather avoiding the added complexity of
marshalling/IPC with fork/exec, as opposed to simply calling into a
native
On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote:
On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
Performance isn't (my) motivation for avoiding fork/exec (and the
equivalent on Win32) but rather avoiding the added complexity of
marshalling/IPC with
On 2015-05-21 at 16:54:11 +0200, Bardur Arantsson wrote:
[...]
That would be the preferred way from a technical standpoint, as it would
avoid fork/exec and make it easier to integrate the CPP-phase tighter
into the lexer/parser.
fork/exec is almost certainly going to be negligable compared
The license issue is a real concern for any company using
GHC to develop a product whose binaries they distribute to
customers. And it is concern for GHC itself, if we want
GHC to continue to be viewed as a candidate for use in
industry.
The real issue is not whether you can explain why this
On 05/20/2015 03:39 PM, Yitzchak Gale wrote:
[--snip--]
Keeping the license as is seems to be important to Malcolm.
So could we have an option to build GHC without cpphs
and instead use it as a stand-alone external program?
That would make the situation no worse than GMP.
I don't see any need
Yes, this is what I am asking. Is the LGPL so dangerous to your business, that
you have taken the steps necessary to build a special GHC using integer-simple
instead of integer-gmp? Or are the lawyers happy simply for the option to be
available, but unexercised? (If the latter, then I could
Hi!
GMP is optional, anyone who cares about the license can build with
integer-simple.
Regards,
Niklas
- Ursprungligt meddelande -
Från: malcolm.wallace malcolm.wall...@me.com
Skickat: 2015-05-19 13:11
Till: Lars Kuhtz hask...@kuhtz.eu
Kopia: ghc-devs@haskell.org
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
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
12 matches
Mail list logo
