Add requirement for sibling checkout of build-variables repo. Bring in those
variables.

Make the platform 'case' statement handle windows64, darwin64, linux64 --
instead of skipping all build activity for those as it did before!

Adapt Mac configure variables CFLAGS and LDFLAGS to vary -arch depending on
AUTOBUILD_ADDRSIZE. Use LL_BUILD from build-variables/convenience for the
rest. Fix script bug in which install_name was set after use, causing the
linker to stamp the dylib with an empty -install_name.
For AUTOBUILD_ADDRSIZE=64, add --64 switch to configure.

Comment out all Mac Debug build and test activity. (Copy a couple script
comments from the Debug block to the Release block.)
Comment out anything to do with contrib/minizip.
Remove debug and minizip items from the darwin manifest in autobuild.xml.

Use awk to extract the section of the README containing the copyright info,
rather than using 'tail -n 31', which would break if the README contents
change with updated versions of the upstream software.

instead of deriving those values "by hand" from AUTOBUILD_ADDRSIZE.

On Windows, autobuild primes the AUTOBUILD environment variable with a
Windows-style pathname. Unfortunately, when it's a bash script (such as
build-cmd.sh) trying to invoke "$AUTOBUILD", this only confuses the issue. Use
cygpath -u to convert back to a pathname bash can handle.

Also from minizip/Makefile.Linden.Win32.mak, where I'd inserted it earlier to
be able to link the utility programs with the library.
It's not clear at what point the upstream project decided that ZLIB_WINAPI
should be the default for all Windows builds, but it wreaks havoc on our
viewer build dependency tree: when zlib is built that way, every 3p library
that depends on it must ALSO #define ZLIB_WINAPI to be able to link with it.
Cheaper to undo the macro in the zlib repo than to fix every consumer.

AUTOBUILD_VSVER should be set by the project in general; an individual repo
should only override it if that library must be built with a *different*
version of Visual Studio for some weird reason.

Also remove diagnostic output intended to help identify The Wrong CMake.

zlib.lib is built with __stdcall. Unless we specify ZLIB_WINAPI on the
mini{zip,unz}.exe builds, it thinks zlib entry points are __cdecl and fails to
link those symbols.

The assembler sources are built without SAFESEH; attempting to link them with
the C++ code produces link errors unless the C++ is also built without
SAFESEH.

We realize that's not the real solution -- it's fragile, won't necessarily
work on other hosts -- but it should at least let us know whether fixing the
PATH will succeed, or whether there are other errors that must be addressed...
such as incompatibilities between CMake 2.8.x and CMake 3.0.x.
Also dump the PATH.

Without that cmake step, the repo contains no zconf.h, and multiple compiles
fail.

because the zlib.h file has issues

Rely on wrapper to import autobuild functions
Switch to VS 2013

use the llqtwebkit2 repo to get us on modern build machines.

Consistently use /Z7 for archive targets to get debug symbols into
consumers.  On Mac, bring the libz symbols file that was started
in freetype into this repo where it belongs.  These are two
files, manually maintained, that list the global symbols defined
in the libz.a archives (debug and release).  These symbol lists
can then be used in an --unexported-symbols option to prevent
re-export in consumer shared libraries.

special makefiles for that process.  Include the README.Linden
in packages, it's useful to devs (or should be).