Not sure how I failed so badly at logic. This should be rewritten so that the build info has a tested MacOS version too. However it seems unlikely that the same LLVM versions on different platforms would have different compile errors. So we'll risk it, and it'll be informative for us too.
* Use new "url" features
* Use keg_only DSL
* Use "skip_clean :all" DSL
* Whitespace and style cleanups
* Make bash invocations less silly
* Use new man2-man8 helpers
* Remove "FileUtils." since it is included in Formula
* Use real names for deps instead of aliases
* ENV.x11 now updates path, so remove that from individual brews
Replaced ENV.gcc_4_2 + comments with calls to "fails_with_llvm",
to specifically message to the user when a formula is known or suspected
to not build with LLVM. If the user specifies "--use-llvm", the message
will be displayed, but compilation will be tried anyway.
Since using LLVM is now an advanced/hidden feature instead of the
default on 10.6, we'll let the user try anyway (and submit patches
if things are now working.)
Because the system comes with them. Having two of these is just complicated.
They are both gems themselves, so gem that is already installed manages them.
Optional flag to install them anyway.
brewkit.rb changes ENV destructively, so lets not do that everytime a formula
is required. Now it's possible for other tools to require a formula
description without worrying about side-effects.
Ruby is not natively threaded; there is absolutely no reason to build against
pthread unless you intend to link against libraries themselves built with
pthread (tcl/tk). More information: http://blogs.sun.com/prashant/entry/ruby_and_enable_pthreads
As far as I can deduce, the source of that flag is in Dan Benjamin’s article,
here: http://hivelogic.com/articles/ruby-rails-leopard
However, he provides no explanation for its use, and did not respond to
commentors’ requests for said explanation; on top of that, I can find no useful
references anywhere else. Hence, removing it.
Old formulas are valid, but should be maintained in a separate branch if
that's what is needed.
The exact way we are going to do this is not yet agreed on.
