* CPU functions now exist in Hardware::CPU
* Added compatibility functions in compat/hardware_compat.rb
* Names are less specific to Mac hardware, e.g. CPU.family instead of
Hardware.intel_family
* Hardware::CPU.family works for both Intel and PowerPC
* New helper methods on CPU, like .sse4? and .altivec?
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
This message is either (a) never printed because the tools are
installed, or (b) printed every time this method is called.
See Homebrew/homebrew#16119.
This code shouldn't be responsible for UX anyway, so just remove it and
let other parts of Homebrew be responsible for failing or declaring that
they need the developer tools.
Rescuing false on the StandardCompilers map meant that the doctor
check assumed that the compilers were incorrect, not merely
unknown.
Instead, skip the check and return nil for unknown Xcode; nil
should be interpreted as "dunno", instead of "true" or "false",
and the doctor check no longer prints on nil.
The MacOS.version? family of methods (other than "leopard?") are poorly
defined and lead to confusing code. Replace them in formulae with more
explicit comparisons.
"MacOS.version" is a special version object that can be compared to
numerics, symbols, and strings using the standard Ruby comparison
methods.
The old methods were moved to compat when the version comparison code
was merged, and they must remain there "forever", but they should not be
used in new code.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Now we should get an sdk_path, but tools like xcodebuild, xcode-select and xcrun will still error out. But at least more of Homebrew will work.
Also putting the Xcode 3 path finder last. We get bug reports because newer Xcodes are installed in parallel to older Xcodes. We want to find and use the newer Xcode's first. Xcode.prefix is pretty smart about that.
Refs Homebrew/homebrew#14558.
1. A minimal build environment, we don't set CFLAGS, CPPFLAGS, LDFLAGS, etc. the rationale being, the less that is set, the less variables we are introducing that can break builds.
2. A set of scripts that replace cc, ld, etc. and inject the -I, -L, etc. flags we need into the args passed to the build-tools.
Because we now have complete control over compiler instantiations we do a variety of clean-up tasks, like removing bad flags, enforcing universal builds and ensuring makefiles don't try to change the order of library and include paths from ones that work to ones that don't.
The previous ENV-system is still available when --env=std is specified.
superenv applies to Xcode >= 4.3 only currently.
This will allow us to do comparisons like
if MacOS.version >= :lion
and hopefully deprecate the MacOS.<name>? family of methods, which are
counterinitutive.
A user on IRC was getting strange results from MacOS.dev_tools_path.
It turns out that xcrun's exit status is not always reliable - if
xcrun is a shim and not able to locate the real xcrun, it will exit
0 despite not actually doing what it was asked. Instead check to see
if the stout is empty.
In order to better support Xcode-only systems, where X11 libs and
executables live under /usr/X11 but headers live in the SDK, move the
x11_* helper methods into a new module.
This allows us to keep some of the CLT/Xcode-only and Apple X11/XQuartz
logic hidden from outside code, like ENV.x11.
Since Apple's X11 is actually XQuartz, name the module "MacOS::XQuartz".
