dolphin/Externals/zlib, branch master

replace zlib with zlib-ng

2022-07-24T21:33:37+00:00

since the benefits are so high, don't link with shared zlib

cmake: Disable warnings for most externals on MSVC, like we do in the VS project files.

2022-05-21T22:30:56+00:00

msbuild: use default Project attrs

2022-04-27T22:26:43+00:00

maybe it makes the xml less scary :D

msbuild: re-enable standalone vcxproj processing

2020-08-22T23:17:50+00:00

msbuild: refactor stuff out of project files (for externals)

2020-08-22T23:17:50+00:00

Add an ARM64 target to Visual Studio projects

2019-12-28T09:20:41+00:00

Update VS projects/solutions to VS2019

2019-11-30T03:42:52+00:00

zlib/CMakeLists: Fix check for unistd.h

2019-05-29T13:03:37+00:00

The CMakeLists file for the static zlib checks for presence of
unistd.h, but it doesn't properly define HAVE_UNISTD_H if it's found.

This change adds the necessary preprocessor definition if unistd.h is
found.

Upstream zlib handles this with by configuring zconf.h with CMake:
https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zconf.h.cmakein#L11

Dolphin's static version of zlib doesn't do this, which is why setting
Z_HAVE_UNISTD_H in zlib's CMakeLists.txt isn't enough.

This probably wasn't noticed since because most *nix systems will use
the shared zlib. Force use of the static zlib (comment out
find_package(ZLIB) in the root CMakeLists.txt) and you'll see implicit
function declaration warnings during its compilation.

Update to Visual Studio's default Windows SDK

2018-10-19T23:53:08+00:00

CMakeLists: Don't dump zlib's includes into the top-level directory

2018-04-13T12:32:48+00:00