Core change: XCode only install, with CLT or both

Allow XCode without the Command Line Tools to
work with homebrew, so it's not necessary
to register an Apple Dev ID and/or go to the
XCode prefs and download the CLT. Yay!

Further, this commit allows to use the CLT
solely (without the need for XCode).
Saves quite some megs.
(Some furmulae require xcodebuild)

Of course XCode together with the CLT is still
fine and has been tested on 10.7 and 10.6
with Xcode 4 and Xcode 3.

New in utils:
  MacOS.locate method to get the path to a
  binary tool. It issmart enough to look in
  /usr/bin or query "/usr/bin/xcrun" tool.
  As a final resort find the needed tool within
  Xcode Toolchains or in the MacOS.dev_tools_path.
  Note, xcrun has been removed from ENV.rb.

New MacOS.xcode_installed? telling us whether
the Xcode is installed or not.

MacOS.xcode_version may return a version string
that is guessed based on the compiler, so do not
use it in order to check if Xcode is installed.

New MacOS.clt_installed? telling us
whether the CLT are installed or not.

MacOS.xctoolchain_path gives the path of the
Xcode toolchain (compiler and such).

MacOS.macosx_sdk_path(version) returning the path
of the MacOSX SDK.

ENV.macosxsdk function sets all needed lib and include
dirs to CFLAGS, CPPFLAGS, LDFLAGS.

In build.rb it is checked if Xcode >= 4.3 and
xctoolchain path exists. If yes, the new
ENV.macosxsdk(MacOSX.version) is called
to set up the environment and PATH.

--config.rb shows the version number of the CLT and
the path to Xcode.app unless in a standard place.

Only on Lion or above, tell the user about the options,
which are
- Xcode without CLT
- CLT without Xcode
- both (ok, it's not directly stated, but implicit)
So if no Xcode is found and we are on Lion or above,
we don't fail but check for the CLTs now.
For older Macs, the old message that Xcode is needed
and the installer should be run is still displayed.
If the CLT are not found but Xcode is, then we
print out about the experimental status of this setup.

ENV.x11 respects macosx_sdk_path

Core-change: keg_fix_install_names now uses MacOS.locate.
fcgi: fix "Symbol not found: _environ"

Fixes #12844.

Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
mapserver: add optional support for fastcgi

Closes #12844.

Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
Xcode from the App Store is no more an installer.

- Removed outdated message about running the installer.

Closes #12857.

Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
blacklist: update Xcode message for 10.8
warn if unrar is needed but not found.

You can `brew unrar`

Closes #12858.

Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
lua: Using our LDFLAGS

This is needed for Xcode-only installations, since the LDFLAGS matter.

Closes #12856.

Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
lua: style nit
cmake: fix for Xcode-only installs

Help cmake to find the files located within the SDK by writing
a CMAE_FIND_ROOT_PATH.txt.
python: Do not link against system's python lib!

- Fix http://bugs.python.org/issue11445.
This caused various bugs and build failures of certain modules.
- made the dynamic extensions of sqlite optional, since it can lead to not building sqlite at all.
vtk 5.10 & add pyqt+sip

Upgrade vtk to version 5.10.
Add deps on sip and pyqt if the user options `--qt` and `--python`
Add cmake args to enable the python sip wrapper and the location
of `-DSIP_PYQT_DIR` to be in `share`.
Change the location of the python `.so` modules so they and the Egg
get installed into `lib/which_python/'site-packages'`.
Add code so that directory is created and prepended to the users's
PYTHONPATH to stop build errors.
Remove the workaround code that was previously added to support
the python getting RPATHs.
Add code that removes three duplicate files in `site-packages`
that was causing the linking step to fail, files that already
exist either in the System directories or in HB `site-packages`
when using brewed Python.

This formula will work once the HB installer scripts are modified
so that `install_name_tool` is recursed through `site-packages`
and modifies the `.so` files there.  Atm I think it only modifies
files that end in `.dylib`.

Closes #12807.

Signed-off-by: samueljohn <github@samueljohn.de>