Switch to HOMEBREW_LIBRARY since HOMEBREW_LIBRARY_PATH already includes
"/Homebrew" and HOMEBREW_LIBRARY is less confusing.
Closes#530.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
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.
Move some stuff formerly in `Library/ENV` around:
- Move `Library/ENV/$XCODE_VERSION` to `Library/Homebrew/env/super` as they are
all superenv wrappers and all symlinks to the same version. We never needed
the "separate shims for separate versions" functionality and it just adds
confusion.
- Move `Library/ENV/pkgconfig` to `Library/Homebrew/env/pkgconfig` to get more
things under `Library/Homebrew`
- Move `Library/ENV/scm` to `Library/scm` as these wrappers are not actually
used by or related to superenv (or stdenv) in any way.
In 0d189fae57
we completely removed `effective_sysroot`, which consequently left all the
`effective_sysroot`/usr/include calls pointing at `/usr/include`. This is wildly
problematic on systems where the Command Line Tools aren't installed because
`/usr/include` is not a default-created folder prior to CLT installation.
I'm unsure if `effective_sysroot` should still be mentioned in Library/Homebrew/extend/ENV/super.rb
at all. If it can be deleted, feel free to do that without waiting for me to review.
This seems to fix:
* https://github.com/Homebrew/homebrew-core/issues/2991
* https://github.com/Homebrew/homebrew-core/issues/2986
* https://github.com/Homebrew/homebrew-core/issues/2962
Add an extension for accessing Git-related meta data that can be mixed
in into a Pathname object (e.g. `HOMBREW_REPOSITORY` or the path of a
`Tap` instance). The goal here is to eliminate code duplication.
Beta versions of XQuartz have address sanitization enabled, which
breaks some software at runtime, including wine.
Closes Homebrew/homebrew-core#2481.
Closes#459.
Signed-off-by: Misty De Meo <mistydemeo@github.com>
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.
The fix changes behavior in same cases, but those cases were all either
broken or showed unexpected behavior. The new behavior is very simple:
- If an argument starts with `--<option-name>=`, return whatever comes
after the equals sign.
Prior to this change, `ARGV.value` showed some unexpected behavior:
- `ARGV.value("foo")` returned `nil` for `--foo=` because at least one
character needed to be present after the equals sign. (All other
option parser implementations I'm aware of allow for empty values.)
- `ARGV.value("bar")` returned `"baz"` for `--foo=--bar=baz` because the
regular expression was not anchored to the start of the argument.
- `ARGV.value("++")` raised an exception because the string wasn't
escaped for use in the regular expression. (An unlikely corner case.)
Closes#231.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
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
The new stage() signature introduced by #66 breaks back-compatibility
under Ruby 1.8.7. This fixes it by switching back to a one-argument
block signature and using a new class to wrap both the Resource and
Mktemp info for the staging context, in a signature-back-compatible
way.
Addresses homebrew/homebrew-core#529.
Closes#135.
Signed-off-by: Andrew Janke <andrew@apjanke.net>
