Hacker News Reader

Comment by nupark | Hacker News Reader

This is silly -- these are just blind leading the blind questions. I guess I can provide some answers ...

- homebrew should just provide binaries rather than trying to bootstrap a compiler for everyone.

- Barring that, homebrew should wait and see if Xcode4 is free with Lion.

- A compiler isn't enough. You also need an assembler, linker, etc. Those can be found in Apple's cctoolz and ld64 projects.

- Headers are are also required. Those belong to Apple and are not freely redistributable.

- GCC 4.2 is still the default, not clang. Apple still builds the majority of the OS with GCC.

- Apple does modify the compiler. Look at PLBlocks (http://code.google.com/p/plblocks/) for scripts that can drive an Apple compiler build.

- homebrew is learning why "do not dupe" is not viable when dealing with Apple in the longterm, and is going to just wind up being a less mature macports clone after going through a few more release cycles.

View on HN

- We are going to provide binaries for the CC toolchain.

- We can't wait for Lion, nor expect everyone to use Lion.

- The wiki page even says we need the whole toolchain

- Headers is a good point

- GCC is not the default /usr/bin/cc for Xcode4

- Yeah, we know that.

- Macports needs Xcode too.

We can't wait for Lion, nor expect everyone to use Lion.

But nothing has changed. The presence of Xcode 4 does not invalidate people's existing copies of Xcode 3 already installed or that exist on their OSX DVD. Further, the version of gcc is the same.

If this whole episode is what finally gives people the motivation to have an easier-to-install binary of gcc, then great. But the actual need is the same today as it was last week.

This is a fair point.

It may work that we can support both 3 and 4. But experience suggests that even minor build bumps of Xcode cause issues compiling software.

Ultimately it is a lot easier for us if we can say install this and use that and you will have very few issues using Homebrew.

The need is the same... 'ish. Personally I think Lion will have xcode 4 free (bit like Facetime has been done). Here's the thing tho, compiler bugfixes etc. need you to sign up to the dev. program or, at the moment, buy xcode. This is bad imho and therefore it's worth the effort to give the user of homebrew an option.

> Here's the thing tho, compiler bugfixes etc. need you to sign up to the dev. program or, at the moment, buy xcode. This is bad imho and therefore it's worth the effort to give the user of homebrew an option.

Xcode 3.2.6 was released at the same time as Xcode 4 and is freely downloadable.

- We are going to provide binaries for the CC toolchain.

I meant binary packages, not a bootstrap tool chain.

- We can't wait for Lion, nor expect everyone to use Lion.

Xcode3 is still available. Xcode4 is not yet mandatory.

- Headers is a good point

It's an insurmountable obstacle, unless you plan on independently generating your own replacement headers (which is possible, but is going to be a world of pain).

- GCC is not the default /usr/bin/cc for Xcode4

Yes, Apple is investing heavily in moving everything to LLVM/clang in Lion (... and, as such, with Xcode4), but even in Xcode4 the default /usr/bin/gcc and iOS compiler is llvm-gcc4.2, not clang.

Additionally, you'll likely find it more difficult to track clang over GCC, as Apple is less explicitly about matching up their custom branches to actual releases as shipped with Xcode.

- Macports needs Xcode too.

My point was that this demonstrates why working with a vendor as capricious[1] as Apple often requires one to carve out their own niche of stable dependencies, and most of what you've often claimed sets homebrew apart[2] will be gradually worn away as you have to deal with Apple major releases.

That said, I hope MacPorts just starts using their support for binary packaging of ports (port archives).

[1] They're not really capricious, so much as focus on the consumer, and not on developers building large port systems. [2] I'm reminded of this line-by-line assessment: http://apps.ycombinator.com/item?id=872072

It's an insurmountable obstacle, unless you plan on independently generating your own replacement headers (which is possible, but is going to be a world of pain).

How is it unsurmountable? I remember mingw/cygwin doing a similar thing for Windows.

It's not too hard to cobble together open-source headers and autogenerated minimally viable headers for the OS frameworks (this is what the initial non-official iPhone toolchains did).

They'll be very incomplete, however, quite a bit of software will not build correctly, and it will take a significant effort to clean them up.

I think you want something like http://rudix.org

Reply on news.ycombinator.com