On 2015-05-21 at 14:09:13 +0200, Yitzchak Gale wrote:
> I wrote:
>>> ...I thought that the idea was that we wanted
>>> it actually integrated into GHC.
> Herbert Valerio Riedel 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.
>>
>> However, due to the, sadly, mostly non-technical issues brought up,
>> it seems to me that isolating cpphs into a separate process (w/ the
>> option to configure GHC to use some other cpp implementation at your
>> own risk if you need to avoid the cpphs implementation at all costs)
>> would be the compromise acceptable to everyone in the short run while
>> addressing the primary goal to decouple the default-configuration of
>> GHC from the fragile system-cpp semantics.
>
> Correct me if I'm wrong:
>
> GHC already supports using an external CPP processor
> as an option. And cpphs is already easily buildable as
> a stand-alone external CPP processor compatible with
> GHC.
Yes
> So can't we incorporate cpphs into GHC as is, but
> also provide a build option to exclude it from a GHC
> build? In a non-cpphs build, CPP would only work
> if an external processor is provided.
Well, that's more or less the plan (I hinted at in what I wrote earlier)
for cpphs-as-an-executable/isolated-process;
Except that we may[1] not want to build a cpphs as you'd get if you
simply 'cabal install cpphs' (as that would pull in more build-deps than
desirable), but maybe implement a stripped down GHC-specific frontend to
the cpphs library (while trying keep the original cpphs modules
untouched, and/or contributing changes back to upstream so we don't
diverge).
In any case, the cpphs-ish tool bundled with GHC could be considered a
GHC-specific fork of cpphs (and possibly with a GHC-tailored CLI) *and*
you'd have the option as you suggest to exclude it from the GHC build,
in order to create a GHC toolchain w/o any "cpphs" code (which uses
e.g. the system-cpp as in the past).
> That's even better than the GMP situation - it really
> would be simple and practical to create and use
> a non-cpphs GHC if needed. As opposed to a non-GMP
> build, which in reality is only a theoretical possibility
> to satisfy the lawyers.
[1]: I'm just thinking out loud here; it'll only become clear what's
sensible once we have *actually* attempted to integrate cpphs into
the GHC build-system, and have a working proof of concept (that'll
need to be thrown at Hackage)
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
