xcode 5 psa info on haskell platform page

[Carter Schonwald]

I agree with all of Darin's points and support the stance he's taking on
this matter. Its the solution that supports all of the communities users,
whether haskell-platform, built from source  or otherwise, in a systematic
way.


On Mon, Oct 28, 2013 at 12:00 AM, Darin Morrison <darinmorrison at gmail.com>wrote:

> On Sun, Oct 27, 2013 at 1:18 PM, Mark Lentczner <mark.lentczner at gmail.com>wrote:
>
>> I've reviewed all the changes in that branch - and they seem to fall into
>> two categories:
>>
>> 1) Changes the flags that ghc passes to whatever it thinks is gcc, so
>> that they work with clang.
>> 2) Changes to ghc source so that clang can compile it.
>>
>
> Not quite. Two of the patches (the ones authored by me) are needed to
> build 7.6.3 on 10.9 regardless of whether clang or GCC are used.
>
>
>> For the platform, we don't care about #2 - we don't ship the GHC source,
>> and we don't expect platform users to build it.
>>
>
> I'm not suggesting that we change the principles of the Haskell Platform
> to expect users to build their own binaries.
>
> However, there are a fair number of users who do this—either directly or
> indirectly (via Homebrew or Macports). In general, I think it's a bit of a
> problem that it's not currently possible to build GHC and the rest of the
> Haskell Platform on 10.9.
>
> I think it would be especially bad to ship a _new_ Haskell Platform
> release that can't be built on the current version of OS X.
>
>
>> Items in #1 look to my eye like they are covered by the wrapper script
>> (or some equivalent that we can build with it). What's more, the changes in
>> #1 seem to rely on the idea that GHC was built knowing whether it will be
>> used with gcc or with clang. This seems undesirable to me (at least for
>> now), insofar as there will be people running Xcode 4 for the foreseeable
>> future, and I'd really rather not have to produce variants of GHC or HP
>> just to support Xcode 4 vs. 5.
>>
>
> I'm not sure if this is accurate, but it is a problem if correct. There's
> also the issue of C compiler command being hard-coded into the settings
> file.
>
>
>> I don't see anything in those changes that handles the fact that gcc is
>> hard coded into hsc2hs, though I might be misunderstanding that issue.
>>
>> So - looks to me like a bash script wrapper, and redirecting ghc's
>> settings is still the best option.
>>
>
> I still don't like the idea of a wrapper script, especially if it's a hack
> specific only to the OS X version.
>
> I would prefer depending on an updated version of GHC which 1) compiles
> cleanly on 10.9, 2) works with clang and GCC, and 3) either dynamically
> detects which C compiler is available or offers a static configuration
> method like xcode-select but which updates the GHC settings. Something like
> version (3) could be run during install time, preventing the need for
> separate binaries.
>
> That's just my take on it. I realize it would require more work but I
> think it would be a cleaner and more reliable approach than a wrapper
> script.
>
> —Darin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20131028/ad9b65e3/attachment.htm>