6 ms·

- 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 whol

by mxcl 16y ago

- 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.

scott_s 16y ago
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.
- mxcl 16y ago
  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.
- leepa 16y ago
  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.
  - masklinn 16y ago
    > 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.
nupark 16y ago
- 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 http://apps.ycombinator.com/item?id=872072
- wladimir 16y ago
  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.
  - nupark 16y ago
    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.
- zppx 16y ago

by mxcl 16y ago

scott_s 16y ago

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.

mxcl 16y ago
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.
leepa 16y ago
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.
- masklinn 16y ago
  > 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.

nupark 16y ago

- 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 http://apps.ycombinator.com/item?id=872072

wladimir 16y ago
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.
- nupark 16y ago
  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.
zppx 16y ago