dolphin/Source/Core/UpdaterCommon/CMakeLists.txt

add_library(updatercommon
  UI.h
  UpdaterCommon.cpp
  UpdaterCommon.h
)

target_link_libraries(updatercommon PRIVATE
  uicommon
  mbedtls
  ZLIB::ZLIB
  ed25519
  cpp-optparse
)
Move shared Updater logic into UpdaterCommon 2019-02-25 23:08:03 +01:00			`add_library(updatercommon`
UpdaterCommon/CMakeLists: Specify headers in target sources 2019-05-29 05:22:45 -04:00			`UI.h`
			`UpdaterCommon.cpp`
			`UpdaterCommon.h`
			`)`

Move shared Updater logic into UpdaterCommon 2019-02-25 23:08:03 +01:00			`target_link_libraries(updatercommon PRIVATE`
			`uicommon`
			`mbedtls`
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-05 14:01:16 -07:00			`ZLIB::ZLIB`
UpdaterCommon: Move most of the programs here 2019-03-03 13:56:54 +01:00			`ed25519`
UpdaterCommon/CMakeLists: Specify headers in target sources 2019-05-29 05:22:45 -04:00			`cpp-optparse`
			`)`