- 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.
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.
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.
Xcode 3.2.6 was released at the same time as Xcode 4 and is freely downloadable.
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
How is it unsurmountable? I remember mingw/cygwin doing a similar thing for Windows.
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.