[Haskell-cafe] Current status of Mavericks CPP

[Michael Snoyman]

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
itself.
3. Short term, users need to follow the instructions at [1] if they're
using GHC 7.6 (or earlier?).

[1] http://www.haskell.org/platform/mac.html


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"
>> issue;
>>
>> - 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
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140416/6717f02e/attachment.html>