Superenv normally filters out "-m32" flag, preventing 32bit builds.
Some software, however, still only work in 32bit mode.
If ENV.m32 is called, superenv does not filter out the "-m32" flag.
Also note, superenv, does not explicitly add the -m32 flag and
expects the build system of the software to know when and where to
provide this flag.
ClosesHomebrew/homebrew#16350.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
Superenv scripts have a stripped PATH, which may not include
the brew binary itself. Make this explicitly available to
superenv scripts.
Fixes bsdmake wrapper.
ClosesHomebrew/homebrew#16805.
ClosesHomebrew/homebrew#16846.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
haskell-platform falls over badly if VERBOSE is set. Theoretically
this could happen to other packages too. Really it's just less
painful to avoid setting the env var in the first place.
FixesHomebrew/homebrew#15989.
A required special case since formula that use python can optionally use system python or Homebrew python. We'll probably need more of this sort of thing.
- Install a sitecustomize.py that is only executed for brewed
python to
- Fix the prefix, python thinks it is installed to.
(Remember, Python thinks it lives in the Cellar)
- Remove "/System/..." stuff from sys.path which caused
a lot of install trouble because setuptools has the
habbit to inject itself upfront, overwriting our distribute.
- Allow --with-poll and don't say, we didn't warn you.
- Don't need depends_on :x11 any longer. Yeah, no XQuartz!
- Add --with-brewed-openssl
- pip 1.2.1
- pip, pip-2.7, easy_install and easy_install-2.7 are installed
to prefix, such that they are directly available, even if
people have not set their PATH to include
$(brew --prefix)/share/python
- Caveats shorter and clear.
- For Xcode-only:
- Patch the distutils buildsystem to use "xcrun cc" etc.
- Teach distutils the MacOS.sdk_path (for incs and libs)
- superenv.rb add the right python include dir depending on
whether a brewed python is installed or not.
ClosesHomebrew/homebrew#15064.
Signed-off-by: Max Howell <mxcl@me.com>
We add the bins from all deps instead. Rationale: formula find and use eg. GNU-coreutils versions of things and then break. Only allow formula to use tools that they depend on and expect.
I want to go further and only add include paths etc. for dependencies, I have done some work on this, but I fear it may be impossible. If an include path is eg. /usr/local/lib/foo/include, is it possible to know if this path is bad? Not always AFAICT.
In cases where the xcode-select -print-path is '/' xcrun still hangs indefinitely, setting DEVELOPER_DIR to something (preferably the Xcode path) fixes that. So let's.
The MacOS.version? family of methods (other than "leopard?") are poorly
defined and lead to confusing code. Replace them in formulae with more
explicit comparisons.
"MacOS.version" is a special version object that can be compared to
numerics, symbols, and strings using the standard Ruby comparison
methods.
The old methods were moved to compat when the version comparison code
was merged, and they must remain there "forever", but they should not be
used in new code.
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.
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.
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.
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.
