dolphin/Externals/minizip/CMakeLists.txt

project(minizip C)

set(SRCS ioapi.c unzip.c)

add_definitions(-DNOUNCRYPT)
if(UNIX)
  add_definitions(-D__USE_FILE_OFFSET64)
  add_definitions(-D__USE_LARGEFILE64)
  add_definitions(-D_LARGEFILE64_SOURCE)
  add_definitions(-D_FILE_OFFSET_BIT=64)
endif()

add_library(minizip STATIC ${SRCS})
target_include_directories(minizip PUBLIC .)

target_link_libraries(minizip PUBLIC ZLIB::ZLIB)

add_library(MiniZip::minizip ALIAS minizip)
Externals: Add a stripped down version of minizip. 2017-09-05 08:37:40 +03:00			`project(minizip C)`

			`set(SRCS ioapi.c unzip.c)`

			`add_definitions(-DNOUNCRYPT)`
			`if(UNIX)`
			`add_definitions(-D__USE_FILE_OFFSET64)`
			`add_definitions(-D__USE_LARGEFILE64)`
			`add_definitions(-D_LARGEFILE64_SOURCE)`
			`add_definitions(-D_FILE_OFFSET_BIT=64)`
			`endif()`

			`add_library(minizip STATIC ${SRCS})`
			`target_include_directories(minizip PUBLIC .)`

Fix Windows CMake builds with shared zlib On Linux, if shared zlib is present, zlib.h is always available and -lz links to zlib, even if you don't run find_package(ZLIB). For some reason I have zlib installed on Windows (possibly from vcpkg), so find_package(ZLIB) succeeds and ZLIB_FOUND is true. When Dolphin uses shared zlib on Windows, the problem is that zlib.h is not in the default include path, and the CMake target is called ZLIB::ZLIB and there's neither a target nor a library called z. However, both find_package(ZLIB) and add_subdirectory(Externals/zlib) create a target called ZLIB::ZLIB, so I'll switch to that instead. Hopefully this change doesn't break anyone's build. 2020-06-06 00:01:16 +03:00			`target_link_libraries(minizip PUBLIC ZLIB::ZLIB)`
Externals/minizip: Link against zlib 2019-05-08 21:58:16 +03:00
Externals: Add a stripped down version of minizip. 2017-09-05 08:37:40 +03:00			`add_library(MiniZip::minizip ALIAS minizip)`