Hacker Newsnew | comments | show | ask | jobs | submit login

Notably missing feature: one that allows them to issue a point release to the SDK without making you redownload 3gb of dev environment each time.

I would go further. What I have always wanted is simple: a compiler. I believe that the only way to get one on a Mac is from Apple itself, though I would be happy to take a compiler from a third-party. I don't want to be a Mac dev or an iPhone dev. I don't want their IDE. I want a compiler.

So far as I know, the only way to get gcc (or any other compiler) initially onto a Mac is by accepting the entire Xcode package. I'm posting this here because you mentioned the 3GB download, which always makes me cringe. I'm curious to see if anyone knows a better way. (I've had this conversation online in a number of places in the last few years, but never received an alternative.)


You can try navigating inside the main Developer Tools package and installing the individual components (although they may not link properly).

I don't see any reason why you can't compilers. Here's the instructions for Clang [1] and LLVM [2].

You can't really do a lot without the system headers and libraries, though, which are installed via the Xcode Dev Tools.

[1] http://clang-analyzer.llvm.org/installation.html [2] http://llvm.darwinports.com/


I'm not sure why you linked to the darwinports web site, it’s a domain squatting site, not at all linked to the original darwinports project, and I believe one of the reasons they changed the name. Even without this, darwinports, not macports, have ever (really) supported binary installs, which means you need a compiler (namely gcc) to get this LLVM package installed.


I've always had good experiences with the MacPorts gcc and nowadays they even have clang. Download MacPorts, run "sudo port install gcc", and go get coffee. Altogether much less than 3 GB. The only caveat with MacPorts is that you should make sure that the package you're downloading is fairly recent since some maintainers neglect them.


But MacPorts requires the Apple Dev tools to be installed, it can't go by itself.


You don't have to actually install the full xcode IDE. You can do a minimal install of XCode from the installation CD, enough to get the required dependencies, and then install gcc from macports.


This is not a bad thought, but it runs afoul of Apple's strange choices. If you view the "Custom" install of Xcode, there are five parts:

1. Essentials (1.75GB)

2. System tools (56.8MB)

3. UNIX Dev Support (563.7MB)

4. Documentation (Zero KB - sic! More seriously, it's a download at next boot, hence zero KB of stuff is installed immediately from the disc. Why they don't report the size of the later download, I don't know.)

5. Mac OS X 10.4 Support (Zero KB - again, sic!)

By default, 1-4 are selected and 5 is deselected. But here's where it gets interesting: you can only deselect 2-5 manually. 1 is a must. Care to guess where Xcode lives?

Here's how Apple describes "Essentials":

> Installs Xcode, Interface Builder, Instruments, Dashcode, Quartz Composer, GCC 4.0.1, GCC 4.2.1, llvm-gcc 4.2.1, GDB, and other developer tools. Also installs the Mac OS X 10.5 and Mac OS X 10.6 SDKs. All content is placed inside a location chosen by the user (default is /Developer on the boot volume).

I feel like John Belushi in the old "All I wanted was a pony, but nooooooooo" skit.


But you can re-direct the location for the installation of Essentials. It has "Other". Point it at an external drive (USB, whatever) and then wipe it. Make sure you install UNIX Dev Support - it will go onto the boot volume (and the gcc compilers come too.) And make sure to de-select "Documentation" if you don't like surprises later.


Take a look at CharlesSoft's Pacifist. It gives you a lot more room to stretch.


I don't understand why they need to do this. Does anyone have a good explanation ?


Deploying a major release as a diff to a complex development environment is far from effortless. They probably figured the effort vs. payoff ratio didn't work out, compared to making improvements to the product itself.


I remember having to upgrade VS 2005 to VS 2005 SP1. It took 2 hours to apply the changes.

And it was difficult to tell if the updating application froze or was still working. So while patching is nice, it is a huge effort to get it done cleanly.


It's strange to me how products like source control manage this. Why is this different?


Source control applications don't generally worry about dependencies, and they also generally aren't concerned with multiple projects.

Using .NET as an example, the SDK patches would include: Drivers DirectX XNA WPF BackOffice SQL Server (or Express or Lite or whatever they call it) System libraries ASP.NET C# F# ILR C++ .NET VB.NET

And the list goes on.

Apple's developer kit has a similarly vast suite of libraries and services, I just don't know all of their names. Each one in isolation wouldn't be all that big a deal, but combine them and you have the option of massive downloads or a nightmarish dependency management problem.


With Visual Studio for example, it's not only about merging files, but installing various DLLs (for the runtime - vcredist*.exe), COM objects, .NET stuff, etc. Also creating (if possible) proper uninstalls.

VS2008 runs some SQLserver, PDBserver, and who knows what else (run ProcExp and see)


They manage it for typically-small changes. Try computing a patch for the differences between major revisions of a Linux project, and watch how long it takes. Then try to apply it.


Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact