It has been long enough since `depends_on :x11` was introduced that we
can make it the caller's responsibility to ensure X11 is present before
invoking ENV.x11, so stop outputting a warning.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
It was dumb to have make call different compilers to configure depending on the `servile?` flag. This is not a route to reliability.
Instead now we set CC (formula that break if CC is set like Jack be damned, their build-systems are just plain broken and should not be supported). When cc is called we examine HOMEBREW_CC, otherwise we instantiate the tool that was called, just like the formula's build-system will expect.
FixesHomebrew/homebrew#14659 (though the build fails later for me, with the same error for stdenv and superenv).
So many formula assume CFLAGS etc. are not nil. One fix would be to set them to "" but this would set them in the environment, and that could have consequences for build-scripts. This hack works but with a (hopefully) small caveat.
FixesHomebrew/homebrew#14580.
FixesHomebrew/homebrew#14554.
We justify doing this because pre 10.8 X11 came with GL for all Homebrew-capable systems and as such is a default that we'd prefer not to have to address.
serf requires you to explicitly tell it where to find the supertool because otherwise it has a hardcoded /usr/bin/apr-1-config (:P), ctail however is sensible and searches the PATH so now it's as though we do nothing special in that formula. Nice.
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.
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.
