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. 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. 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. Thanks, Yitz _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
