Hacker Newsnew | comments | show | ask | jobs | submitlogin

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 Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: