In `extend/ENV/std.rb`, the methods `set_cpu_flags` and
`set_cpu_cflags` have been violating the `Naming/AccessorMethodName`
cop.
A recent modification in #7e13b3749 woke up the cop. That means we’re
likely dealing with legacy code here, predating the introduction of
RuboCop into Homebrew.
This commit disables the cop for either method. I believe refactoring
wouldn’t currently be worth the effort, especially given that
`#set_cpu_cflags` is mostly called without arguments.
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.
Unlike macOS, Linux installations can be installed/deployed on a
variety of hardware. The HOMEBREW_ARCH environment variable
allows the end user to set a custom -march=... option for the
compiler. If the variable is not set, it defaults to "native".
This only applies on Linux; on macOS, behavior remains unchanged.
Rather than just re-adding HOMEBREW_PREFIX/bin if it's missing re-add
everything from HOMEBREW_PATH. This works well with or without
environment filtering being enabled but with environment filtering it
ensures that ENV/std just builds on the original user environment.
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.
Setting -mcpu and -mtune on Tiger with gcc-4.2 exposes a bug in one of the
system headers, causing certain builds to fail. This can be fixed by
adding -faltivec to CFLAGS.
See: http://trac.macports.org/ticket/34213
`Library/ENV` like `Library/Homebrew` is part of Homebrew basecode. It
should be able to be accessed during the `brew tests`.
By adding HOMEBREW_ENV_PATH variable, we allow test suit to locate these
codes.
