xcode 5 psa info on haskell platform page

[Carter Schonwald]

It clarify further,  there IS going to be a 7.6.4 bug fix release, so that
we have  a systematic work around.  This has already been settled (to my
understanding). There is nothing to debate here on that matter.

Subject to that, can we assume haskell platform WILL use 7.6.4 for the Fall
2013 release? I hope the answer is yes! :)


On Mon, Oct 28, 2013 at 12:08 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> 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/aa800c31/attachment.htm>