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.
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.
Grab Xcode 4. It's still beta and buggy but it's all one window and is pretty good IMO.
There's keyboard shortcuts for spaces. And CMD` to switch between windows in apps.
OS X isn't perfect, I switched from KDE 5 years ago. Eventually you start noticing all the little touches that mean it is—really—light years ahead of Linux desktop options.
It does have a lot of little "Apple" touches though that you'll just have to take with a LOL.
This is pretty much the opposite of my opinions. Android documentation is awful. Mostly it isn't there at all. Many times I found that it was in fact wrong. iOS documentation is really good. Garbage collection on mobile devices means you get UI stutter because GC kicks in when you don't want it which means your app feels less slick. Xcode 4 is pretty good, but yeah Xcode 3… However Eclipse is slow, clunky and buggy.
Also I have found myself doing weeks worth of hacks on Android AND iOS. Both are large frameworks, and ultimately they don't have abstractions for everything you may want to do.
The article reads like the guy hasn't really got his feet wet with Android development yet. He's yet to be bitten by not handling the activity lifecycle correctly for instance. The real edge cases of that didn't start materialising until we had 20,000 beta testers.
http://github.com/mxcl/homebrew is my project. IMO anyone who is afraid of forking is actually just afraid of losing control. It's much easier now for people to do a better job than you. You have to work harder in order to keep your kudos. That guy who has submitted 20 patches a month since 2005 could in theory attract more attention than you and everyone would start using their fork.
/usr/local makes it far easier to install stuff like Gems with C extensions. It is a standard path checked by the C build system (eg. gcc).
There no good reason I have yet heard why using /usr/local is bad advise. I assume that since you provided no rationale for your statement you are in fact unaware of one.
But anyway having said this it is merely a recommendation — do whatever you want. The installation guide goes to great lengths to tell you that you should do whatever you want.
Back when I initially made Homebrew I was interested in the greatest goal of maximum awesome O99 CFLAG awesomeness. Now I'm only interested in reliable compiles and the default CFLAGS are pretty sensible. At the time I wouldn't have recommended the project to anyone particularly, but it got popular anyway.
But anyway, I never copy and pasted without reading a bunch first. I spent several days researching the stuff, the Gentoo wiki was a good source.
There is no anti MacPorts stuff in any of the docs anymore. I was never anti MacPorts at all, if anyone will believe me. I just found it to be not a great tool for developers. Homebrew is a grass roots project, at the time it seemed harmless fun to poke fun at the competition. As the project became more popular I took it all out. Now there is just a small gibe that I couldn't resist because it's too good a bit of wit.
Finally, no offence? May I suggest next time you say such a thing you don't immediately accuse the person to whom you mean no offence of being both ignorant and arrogant.
PS with offence, you're an ignorant twat, and probably ugly too.
