Since ae177adb2bd55ee5ad6367e7639c4cf0c774b63a, we can safely assume
that xcrun works, and a functioning xcrun will search dev_tools_path and
xctoolchain_path, so we can stop doing extra work here.
On CLT-only 10.7 and 10.8, xcrun will not work, but all the tools will
be in /usr/bin, which we check before invoking xcrun. Further, in this
case, dev_tools_path will be /usr/bin, and xctoolchain_path will not
exist, so the fallbacks here are unnecessary.
In this case we need to handle the throwing on an exception when
attempting to initialize the gcc48 Formula object.
This initialization should be unnecessary if the core GCC is already
installed and rescued if not.
This code originated in a slightly different form in 8e88b22fd1ec65a344ce6e4facd6dad4b415b2ad:
8e88b22fd1/Library/Homebrew/extend/ENV.rb (L30-L32)
Back then, MacOS.default_compiler could return nil, which meant
ENV.compiler could do the same. This code was carried forward as the
surrounding code changed. At this point it should be unreachable.
Formula::DATA only worked by accident of implementation; DATA during the
build is actually Object::DATA, so we should mirror that here.
This reverts commit b12444ba6e1ac1d596a70ff4c777d9386d0791ac.
Instances of `IOPatch` created by `patch :DATA` are not affected by re-setting
the `DATA` constant of the `Formula` instance. For these patches, we iterate
through the `patchlist` and use `instance_variable_set` to attach data.
A bit hacky, but `patchlist` has no write accessors so there isn't a clean way
to modify patch contents.
On older Apple compilers "-O4" is known to cause build errors. On recent
clang, it's the same as "-O3" and you have to pass "-O3 -flto" to get
the old behavior.
This requires hitting the network, which makes the first invocation
slow. The results are inaccurate as it only pulls down the first page of
results. It is also prone to false-positives.
A better implementation is welcome, but in the years since I wrote this
code I can't think of a single time where I found it useful.
