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).

End of an experiement in packaging both types of libraries.  It
mostly adds work without material gain.  We'll continue to build
both to test for breakage.  Additional comments on Linux build
environment at Linden and better SDK selection on Mac.

vc10 project files.  Unit tests.  Include .so's on Linux.

--HG--
branch : vendor

--HG--
branch : vendor

--HG--
branch : vendor