[Haskell-cafe] Current status of Mavericks CPP
michael at snoyman.com
Wed Apr 16 06:33:46 UTC 2014
So if I'm reading this all correctly:
1. Package authors are *not* encouraged to change their code to try and
work around this issue.
2. Medium/long term, this won't be a problem at all due to changes in GHC
3. Short term, users need to follow the instructions at  if they're
using GHC 7.6 (or earlier?).
On Wed, Apr 16, 2014 at 9:25 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:
> Further more, once some patches I've cooked up land in 7.8.3, it will be
> possible to ship ghc with it's own cpp program (or use GCC or clang cpp)
> Austin's 7.8.2 mavericks build will correctly handle / cope with clangs
> cpp, but there's a clear concensus to evolve Haskell cpp tooling going
> forward to avoid these issues in the future
> For those on ghc 7.6 or earlier who can't upgrade to ghc 7.8, the work
> arounds listed on the platform site are the current options.
> On Wednesday, April 16, 2014, Brandon Allbery <allbery.b at gmail.com> wrote:
>> On Wed, Apr 16, 2014 at 2:05 AM, Michael Snoyman <michael at snoyman.com>wrote:
>>> I still seem to be getting bug reports about the CPP implementation of
>>> Mavericks. Last I'd heard, it seemed that general consensus was that
>>> packages should *not* be patched to work around the different CPP
>>> implementation, and instead Mavericks users should be installing GCC's CPP.
>>> Is this accurate? And is there a wiki page somewhere describing the
>>> situation and how to work around it? I'd like to have some authoritative
>>> URL to point people to, especially given that I have no access to a Mac
>>> system and therefore can't test this myself.
>> The correct answer is for ghc 7.8 to become established, because it
>> removes the dependency on an external C preprocessor. Some of the reasons
>> for this are:
>> - with FreeBSD 10 having moved to clang on x86 / x86_64, it is clearly
>> only a matter of time before this becomes more than just a "Mavericks"
>> - pretty much everyone *except* the Haskell community accepted that
>> expecting cpp to handle anything other than C and derivatives was a mistake
>> back when ANSI C came out;
>> - even with a K&R-style cpp like gcc -traditional, there are Haskell
>> constructs that can break it; consider that it must know how to parse
>> strings (there are some subtle differences between Haskell and C string
>> syntax) and char constants (did you know that C allows multi-character
>> (char) constants? and pretty much always has?) in order to know when to
>> expand macros. With an ANSI cpp like clang's, it must also know when to
>> interpret # and ## as splices.
>> brandon s allbery kf8nh sine nomine
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe