<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Sean Leather:</div><blockquote type="cite">On Fri, Jun 10, 2011 at 03:15, Manuel M T Chakravarty&nbsp;wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">Ian Lynagh:<br>
<div>&gt; On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote:<br>&gt;&gt; On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote:<br>&gt;&gt;&gt; I would be fantastic if XCode wasn't a dependency. &nbsp;...<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Not to detract at all from the work of the wonderful GHC and Haskell<br>
&gt;&gt;&gt; Platform contributors in any way. For me it would just make it that<br>
&gt;&gt;&gt; much easier to convince mac-using friends to give Haskell a try.<br>
&gt;&gt;<br>
&gt;&gt; The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. &nbsp;I wonder if they would consider the possibility of shipping gcc on Mac too? &nbsp;(There may be good reasons not to do that, but let's have the discussion.)<br>



&gt;<br>
&gt; I'm pretty sure we aren't allowed to redistribute XCode.<br>
&gt;<br>
&gt; As well as gcc and friends, I think XCode also includes various headers<br>
&gt; and/or libraries that we need.<br>
&gt;<br>
&gt; If there is an alternative - especially one that allows us to support<br>
&gt; multiple versions of OS X more easily - then using it may make sense.<br>
<br>
</div>You are right, the Xcode install includes many tools as well as headers etc.<br>
<br>
What would be the advantage of including gcc and all these other things in GHC?</blockquote><div><br></div><div>To simplify the process of installing GHC and to support people with versions of Mac OS X older than the most current. We want to spread the Haskell love as far as possible.</div></div></blockquote><div><br></div><div>The only simplification is that people who haven't got Xcode yet need to install two packages instead of just one.</div><div><br></div><div>However, for people who already have got Xcode installed, it means that they get two versions of all the dev tools, headers, etc. &nbsp;Then, compiling a C file (eg, as part of a Haskell project) by directly invoking gcc or by compiling it via ghc will use different compilers, headers, etc. &nbsp;That quickly leads to annoying and hard to debug problems.</div><div><br></div><div>Given that almost every developer on a Mac will be in the second group, you are not simplifying matters, you are complicating them.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">Anybody who is halfway serious about developing software on a Mac will have Xcode installed anyway.</blockquote>


<div><br></div><div>You could say the same about people halfway serious about developing software on Windows. But GHC doesn't require you to install MinGW, Cygwin, or Virtual Studio.</div></div></blockquote><div><br></div><div>No. &nbsp;A serious Windows dev will have Visual Studio installed. &nbsp;That won't help with installing GHC at all AND the GHC-bundled Unix tools do not interfere with Visual Studio in the same way that custom installs of Unix tools interfere with Xcode.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">


Besides, as Xcode updates are now available from the Mac App Store,</blockquote><div><br></div><div>Not for older versions of Mac OS X.</div></div></blockquote><div><br></div><div>Well, then get the DVDs bundled with your Mac and install Xcode from those, or sign up at <a href="http://developer.apple.com">developer.apple.com</a> and get it there. &nbsp; BTW, Mac users (and esp devs) upgrade very quickly, much faster than, say, Windows users.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">


you don't even need to register as a developer with Apple anymore  yes, you need to pay the nominal $5 for the 4GB download. &nbsp;If you don't want to do that, install the (probably older) version of Xcode that came with the install DVDs of your Mac.<br>


</blockquote><div><br></div><div>This doesn't solve the problem if the GHC package only supports later versions of Xcode. There has already been at least one difference between Xcode 3 and 4 (&nbsp;<a href="http://hackage.haskell.org/trac/ghc/ticket/5011">http://hackage.haskell.org/trac/ghc/ticket/5011</a> ) that caused a problem and there may be others in the future.</div></div></blockquote><div><br></div><div>That was arguably a bug in GHC's build setup. &nbsp;It hardcoded a particular SDK version and died when Apple didn't ship that with the default install anymore. &nbsp;Nevertheless, new versions of Xcode will require adaptations in GHC, just like new gcc and GNU tool/lib versions require fixes in GHC on Linux.</div><div><br></div><div>Bundling doesn't solve that problem; it shifts it due to the mismatch of system-wide and GHC-installed compilers, tools, and libs.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
I don't think you can compare this with the situation on Windows. &nbsp;Microsoft does not distribute a canonical set of Unix tools that all developers use.</blockquote><div><br></div><div>No, but Cygwin and MinGW are available for free and have been around for a long time. Why does GHC bundle MinGW instead of expecting the user to install it herself? Convenience?</div></div></blockquote><div><br></div>Again, this is a different situation. &nbsp;Window's standard dev environment is Visual Studio, you cannot expect devs to have MinGW installed. &nbsp;Mac OS X's standard dev environment is Xcode and you can expect devs to have that installed.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div>I think there is a clear benefit to supporting older versions of Mac OS X. Not everybody upgrades at the same rate that Apple releases new versions. Indeed, Apple's updates occasionally change architecture requirements or break applications, so some people cannot upgrade.</div></div></blockquote><div><br></div><div>Most people upgrade quickly on the Mac platform and, anyway, it does not matter if they have Xcode already installed, which is the case for the majority of devs. &nbsp;In fact, that majority is inconvenienced by the additional complexity of different versions of the tools and libraries.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>Having a new package bundling GNU tools/libraries doesn't preclude the current package using Xcode. The only good arguments against a new package, that I can see, are the additional work to develop the packaging and the testing, release, and maintenance efforts. Perhaps there are some compatibility concerns, working with other OS X libraries/applications. Of course, these are not at all insignificant issues, but these are the main concerns.</div></div></blockquote><div><br></div></div>If you want to make a second, alternative package that bundles tools and libraries, sure, go ahead. &nbsp;As long as that is not the default, that is fine.<div><br></div><div>Manuel</div><div><br></div></body></html>