- This also required auto-fixes for Layout/EmptyLinesAroundBlockBody and
Layout/InconsistentIndentation once the auto-fixer had got rid of the
"redundant begin"s.
This reduces the deviation in compilation flags on a given OS between
users and between bottling/not bottling to provide a consistent
behaviour for debugging and support.
ENV.cxx11 in a test block fails on Linux with
Error: ibex: failed
An exception occurred within a child process:
NoMethodError: undefined method `non_apple_gcc_version'
See for example brew test ibex on Linux.
`ENV.prepend_path "PATH", which("emacs").dirname` in the emacs
requirement was causing us to end up invoking /usr/bin/clang instead
of /usr/local/Homebrew/Library/Homebrew/shims/super/clang.
The experiment to add `-no_weak_imports` unconditionally has been a bit
of a failure. It's broken more than it's fixed and I don't think we can
have this as a default for Xcode 8.
Add `ENV.no_weak_imports` to be used by formulae authors and make
`ENV.no_weak_imports a no-op (for now).
We may reconsider this behaviour in future.
Issue Homebrew/homebrew-core#3727 suggested we set -no_weak_imports for
new versions of Xcode to ensure that e.g. building on 10.11 against the
10.12 SDK doesn't result in a situation where autotools thinks symbols
exist that don't actually exist on the current platform.
Further discussion in golang/go#16770 revealed that some packages
require weak imports to build normally.
Substitue each Version.new and HeadVersion.new with Version.create
to unify Version and HeadVersion instantiation among core code.
Note that this does not relate to Mac::OS::Version class.
Add SharedEnvExtension#gcc_with_cxx11_support? to centralise the
logic for checking whether a compiler is known to support C++11.
Update logic to accept GCC 4.8 and above (including 6). Thereby also
address oversight in #163 where support for GCC 6 was added without
updating the C++11 compiler whitelist.
Add tests for Superenv#cxx11.
Closes#346.
In theory, letting these be set once wasn't an awful idea because it allows
users choice on where Perl modules end up.
In reality, as we've moved closer to sandboxing and at the same time accepted more
perl binding options into formulae it has been exposed as something of a hellraiser.
It's not that uncommon for Perl users to set a custom `INSTALL_BASE` in the ENV which
means we end up with quite a few formula that fail hard with this sort of error:
```
Only one of PREFIX or INSTALL_BASE can be given. Not both.
```
The other common error, which we discovered via sandboxing, is that the Perl modules
end up outside Homebrew's control which means we don't automatically remove them
when the package is removed. Sandboxing blocks this, which means when we eventually
move to enable that by default for users as well as CI it'll quickly become a
prominent issue.
Raise an error when attempting to create universal binaries with a GCC
that can't do so.
ClosesHomebrew/homebrew#46630.
Signed-off-by: Baptiste Fontaine <batifon@yahoo.fr>
