<div dir="ltr">So if I'm reading this all correctly:<div><br></div><div>1. Package authors are *not* encouraged to change their code to try and work around this issue.</div><div>2. Medium/long term, this won't be a problem at all due to changes in GHC itself.</div>
<div>3. Short term, users need to follow the instructions at [1] if they're using GHC 7.6 (or earlier?).</div><div><br></div><div>[1] <a href="http://www.haskell.org/platform/mac.html" target="_blank">http://www.haskell.org/platform/mac.html</a></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 16, 2014 at 9:25 AM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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)<br>
<div>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 </div>
<div><br></div><div>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. </div><div class="HOEnZb"><div class="h5"><div><br></div><div><br>
</div><div><br>On Wednesday, April 16, 2014, Brandon Allbery <<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 16, 2014 at 2:05 AM, Michael Snoyman <span dir="ltr"><<a>michael@snoyman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>
<br></div><div>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.</div>
</div>
</blockquote></div><div class="gmail_extra"><br></div>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:</div><div class="gmail_extra">
<br></div><div class="gmail_extra">- 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;</div><div class="gmail_extra">
<br></div><div class="gmail_extra">- 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;</div><div class="gmail_extra">
<br></div><div class="gmail_extra">- 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.<br>
<div><br></div>-- <br><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a>allbery.b@gmail.com</a> <a>ballbery@sinenomine.net</a></div>
<div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div>
</div></div>
</blockquote></div>
</div></div></blockquote></div><br></div>