Our wrapper always runs the real xcrun at least once, to try to find
the path of the tool being run, but this meant that we were generating
a huge number of error messages on every cc invocaton. Mostly this was
annoying but harmless, but notably it managed to break the compilation
of go.
If we're using a homebrewed gcc-4.2, xcrun may fail to find it (or,
worse, find superenv's shim instead). Explicitly add it to the PATH and
search all path elements for the requested tool.
Also make sure to specify 'gcc-4.2' as the compiler name, not plain
'gcc'. That can resolve to llvm-gcc and to gcc-4.0 on various Xcodes.
- The Library/ENV/4.3/xcrun shim now respects
ENV['DEVELOPER_DIR'] instead assuming the location
of /Applications/Xcode.app/Contents/Developer.
- The env var DEVELOPER_DIR is set if it is not
already. So, during superenv this var is always set
and we no longer have to care about people with unset
or wrongly set xcode-select stuff. This has been
a major PITA in the past.
- determine_developer_dir (which is used to set
the DEVELOPER_DIR var) now uses MacOS::Xcode.prefix
which is proven and very capable and uses splotlight
correctly.
- Replace (and remove) MacSystem.xcode43_developer_dir
with Xcode.prefix
ClosesHomebrew/homebrew#18618
xcrun has a lot of fallbacks if the first case fails but never actually
reaches them on CLT systems since it doesn't check the validity of the
first path before executing it.
(When should it reach these? Mainly for non-Xcode compilers we
support, e.g. apple-gcc42 which can be found by xcrun but which isn't
in /usr/bin)
The xcrun invocation also needed chomping.
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.
