This situation should be impossible now (in that, we should detect sdk_path provided we also detected nclt), so if it happens somehow raise in such a way that the user will be encouraged to report the bug.
Checking the license text is probably the most future proofed method. Though for future reference other possible methods are listed in the below ticket.
ClosesHomebrew/homebrew#14558.
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.
superenv defaults to servile mode. In servile mode:
* If 'gcc' is called, then 'gcc' is run (we ignore HOMEBREW_CC)
* CFLAGS (optimizations) are not applied
* ARGV is not mangled (TODO though we should apply fixes)
* -I and -L environment is still forcibly inserted.
This fixes, eg. jack which was still broken with stdenv. Jack was broken because we set CC in stdenv, and Jack has a stupid build-system. Unsetting CC allowed Jack to find and use the gcc tool it so demanded, but (previously) we would then substitute clang under its nose. The configure still failed. In servile mode (llvm-)gcc is used and Jack compiles.
In normal circumstances clang would then be inserted again during the make phase. But Jack uses the niche-wag build tool that we don't support for setting the O HOMEBREW_CCCFG flag that disables servile mode.
User paths might have anything in them, anything can break builds.
Instead special case these two formula with the view to having an eventual DSL to allow injection of user paths into superenv. Certainly defaulting to off.
This patch removes most of the settings for CC, CXX etc. because we are trying to be minimal. Then we force the compiler to Homebrew's choice underneath in superenv. We however leave LD because we prefer that build-systems use the c-compiler for linking, it generally works better (copiously tested), however when the build-system explicitly calls ld, we respect that. This gets around the ocaml bug in question, since somehow clang was crashing during link, but the ld tool itself (which is kind of clang, kind of llvm-gcc) is okay with this.
Also moved the setting of O (so that cc-args are refurbished) into a make wrapper. Not sure if this matter much, but seems more consistent.
If the rcov gem is installed, `rake rcov` will generate a test coverage
report in the coverage directory.
I picked rcov because it is 1.8 compatible. But it could easily be
swapped out for another coverage tool.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
The problem here now is though that the warnings only appear when compiling verbosely. But they should thus be visible if the build fails. Or if people are hunting for problems.
This was mostly used to prevent stripping. Now we don't strip. Force formula to remove this setting or be more specific about folders they don't want pruned.
Since we are moving towards only depending on X11 for X-headers, superenv now doesn't automatically add X11 compilation. I was reluctant to do this, but it is the right thing to do now that X11 is not automatically installed by OS X or Xcode.
I didn't implement ENV.x11 because the order that the X headers are inserted is important. It must be done at initial setup to ensure that brewed versions of e.g. freetype and Cairo are used and not the ones installed by XQuartz.
This is safe, I tested various scenarios, including Homebrew installed in ~. The only files that are removed are unexpected files in Homebrew's already managed directories.
Adding MacOS.dev_tools_path to our PATH was slow. We no longer need to do this because of the previous commit making a script wrapper for git and svn. It was slow because the function calls out to lots of slow utilities to determine this path.
Two wrapper scripts that find git and svn using the ENV variables we support and then searching through the PATH and looking inside Xcode.app if necessary.
Now just calling git or svn in Homebrew code will find and exec the right tool and we can stop fussing.
Apologies to @adamv who is probably unimpressed that the cmds directory has non-commands in it now. If it's consolation these are temporary pending some more work on superenv whereby some more directories are created under the superenv root.
Rationale: if ack is unlinked but installed, typing ack does nothing, but then user tries to install and it says it is already installed. What gives? The user thinks.
Formula ending up unlinked can happen due to failures during the link phase and we recommend unlinking formula for conflicts. So common enough to justify this amendment.
Let's not show weird error messages when user interrupts during various stages of brew initialization.
Tested by doing `for x in $(brew search); do brew install $x; done` and pressing CTRL-C at random short intervals.
Python et al, require stdenv because otherwise pip, gem, etc. don't work. Can be fixed, just I'm not doing it now.
We want a DSL to do this but I couldn't be bothered to make that work etc. I want to commit. Apologies.
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.
