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 <darinmorri...@gmail.com>wrote: > On Sun, Oct 27, 2013 at 1:18 PM, Mark Lentczner > <mark.lentcz...@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 >
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
