stuff/suyu
stuff/suyu
1
0
Fork 0
mirror of https://git.suyu.dev/suyu/suyu.git synced 2024-11-22 02:41:49 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
suyu/externals/libusb/CMakeLists.txt

278 lines
9.5 KiB
CMake
Raw Normal View History

chore: make yuzu REUSE compliant [REUSE] is a specification that aims at making file copyright information consistent, so that it can be both human and machine readable. It basically requires that all files have a header containing copyright and licensing information. When this isn't possible, like when dealing with binary assets, generated files or embedded third-party dependencies, it is permitted to insert copyright information in the `.reuse/dep5` file. Oh, and it also requires that all the licenses used in the project are present in the `LICENSES` folder, that's why the diff is so huge. This can be done automatically with `reuse download --all`. The `reuse` tool also contains a handy subcommand that analyzes the project and tells whether or not the project is (still) compliant, `reuse lint`. Following REUSE has a few advantages over the current approach: - Copyright information is easy to access for users / downstream - Files like `dist/license.md` do not need to exist anymore, as `.reuse/dep5` is used instead - `reuse lint` makes it easy to ensure that copyright information of files like binary assets / images is always accurate and up to date To add copyright information of files that didn't have it I looked up who committed what and when, for each file. As yuzu contributors do not have to sign a CLA or similar I couldn't assume that copyright ownership was of the "yuzu Emulator Project", so I used the name and/or email of the commit author instead. [REUSE]: https://reuse.software Follow-up to 01cf05bc75b1e47beb08937439f3ed9339e7b254
2022-05-14 20:06:02 -04:00
# SPDX-FileCopyrightText: 2020 yuzu Emulator Project
# SPDX-License-Identifier: GPL-2.0-or-later
libusb: Apple is a POSIX system
2021-06-26 15:24:18 -04:00
if (MINGW OR (${CMAKE_SYSTEM_NAME} MATCHES "Linux") OR APPLE)
externals: Don't set FOUND or VERSION on LIBUSB Fixes an issue where libusb.h wouldn't be found when building yuzu on MSVC. This only affects the "traditional" CMake pathway for linking libusb to yuzu AKA MSVC. For autotools we still want to set these variables before configuring SDL.
2021-06-11 16:57:04 -04:00
set(LIBUSB_FOUND ON CACHE BOOL "libusb is present" FORCE)
set(LIBUSB_VERSION "1.0.24" CACHE STRING "libusb version string" FORCE)
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
# GNU toolchains for some reason doesn't work with the later half of this CMakeLists after
# updating to 1.0.24, so we do it the old-fashioned way for now.
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
cmake: Fix find_program usage for 3.15 yuzu requires CMake 3.15 yet find_program was using REQUIRED, which is only available on 3.18 and later. Instead, we check for "<VAR>-NOTFOUND". In addition, check for additional requirements before building libusb or FFmpeg with autotools. Otherwise, CMake configuration will pass yet compilation will fail.
2021-06-13 01:15:54 -04:00
# Require autoconf and libtoolize here, rather than crash during compilation
find_program(AUTOCONF autoconf)
if ("${AUTOCONF}" STREQUAL "AUTOCONF-NOTFOUND")
message(FATAL_ERROR "Required program `autoconf` not found.")
endif()
find_program(LIBTOOLIZE libtoolize)
if ("${LIBTOOLIZE}" STREQUAL "LIBTOOLIZE-NOTFOUND")
message(FATAL_ERROR "Required program `libtoolize` not found.")
endif()
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
set(LIBUSB_PREFIX "${CMAKE_CURRENT_BINARY_DIR}/libusb")
set(LIBUSB_SRC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/libusb")
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
# Workarounds for MSYS/MinGW
if (MSYS)
# CMake on Windows passes `C:/`, but we need `/C/` or `/c/` to use `configure`
string(REPLACE ":/" "/" LIBUSB_SRC_DIR "${LIBUSB_SRC_DIR}")
set(LIBUSB_SRC_DIR "/${LIBUSB_SRC_DIR}")
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
# And now that we are using /C/ for srcdir but everything else is using C:/, we need to
# compile everything in the source directory, else `configure` won't think the build
# environment is sane.
set(LIBUSB_PREFIX "${LIBUSB_SRC_DIR}")
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
endif()
externals: Work around libusb duplicate GUID errors Given we have two libraries that seem to use the same identifier, we can alter one of them so that the variable is used in place, effectively changing the used identifier, but without altering the source of libusb.
2020-09-02 19:30:20 -04:00
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
set(LIBUSB_CONFIGURE "${LIBUSB_SRC_DIR}/configure")
set(LIBUSB_MAKEFILE "${LIBUSB_PREFIX}/Makefile")
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
if (MINGW)
cmake: General improvements to libusb linking Delegates libusb external communication to externals/CMakeLists.txt Ensures an interface library `usb` for every pathway input_common just links to the `usb` library now externals/libusb/CMakeLists.txt sets variables to override SDL2's libusb finding Other minor cleanup
2021-06-03 03:49:35 -04:00
set(LIBUSB_LIBRARIES "${LIBUSB_PREFIX}/libusb/.libs/libusb-1.0.dll.a" CACHE PATH "libusb library path" FORCE)
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
set(LIBUSB_SHARED_LIBRARY "${LIBUSB_PREFIX}/libusb/.libs/libusb-1.0.dll")
set(LIBUSB_SHARED_LIBRARY_DEST "${CMAKE_BINARY_DIR}/bin/libusb-1.0.dll")
set(LIBUSB_CONFIGURE_ARGS --host=x86_64-w64-mingw32 --build=x86_64-windows)
else()
externals: libusb: Link libusb statically on Linux Turns out that this is possible. Also addresses my own review comment.
2021-06-03 04:38:29 -04:00
set(LIBUSB_LIBRARIES "${LIBUSB_PREFIX}/libusb/.libs/libusb-1.0.a" CACHE PATH "libusb library path" FORCE)
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
endif()
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
cmake: General improvements to libusb linking Delegates libusb external communication to externals/CMakeLists.txt Ensures an interface library `usb` for every pathway input_common just links to the `usb` library now externals/libusb/CMakeLists.txt sets variables to override SDL2's libusb finding Other minor cleanup
2021-06-03 03:49:35 -04:00
set(LIBUSB_INCLUDE_DIRS "${LIBUSB_SRC_DIR}/libusb" CACHE PATH "libusb headers path" FORCE)
externals: libusb: Link libusb statically on Linux Turns out that this is possible. Also addresses my own review comment.
2021-06-03 04:38:29 -04:00
# MINGW: causes "externals/libusb/libusb/libusb/os/windows_winusb.c:1427:2: error: conversion to non-scalar type requested", so cannot statically link it for now.
if (NOT MINGW)
set(LIBUSB_CFLAGS "-DGUID_DEVINTERFACE_USB_DEVICE=\\(GUID\\){0xA5DCBF10,0x6530,0x11D2,{0x90,0x1F,0x00,0xC0,0x4F,0xB9,0x51,0xED}}")
endif()
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
make_directory("${LIBUSB_PREFIX}")
add_custom_command(
OUTPUT
cmake: General improvements to libusb linking Delegates libusb external communication to externals/CMakeLists.txt Ensures an interface library `usb` for every pathway input_common just links to the `usb` library now externals/libusb/CMakeLists.txt sets variables to override SDL2's libusb finding Other minor cleanup
2021-06-03 03:49:35 -04:00
"${LIBUSB_LIBRARIES}"
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
COMMAND
make
WORKING_DIRECTORY
"${LIBUSB_PREFIX}"
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
)
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
add_custom_command(
OUTPUT
"${LIBUSB_MAKEFILE}"
COMMAND
externals: libusb: Call program names not full paths
2021-06-03 04:53:01 -04:00
env
cmake: Specify the compiler on autotools externals Enables CCache on externals if available.
2021-07-06 12:54:24 -04:00
CC="${CMAKE_C_COMPILER}"
CXX="${CMAKE_CXX_COMPILER}"
externals: libusb: Link libusb statically on Linux Turns out that this is possible. Also addresses my own review comment.
2021-06-03 04:38:29 -04:00
CFLAGS="${LIBUSB_CFLAGS}"
externals: libusb: Call program names not full paths
2021-06-03 04:53:01 -04:00
sh "${LIBUSB_CONFIGURE}"
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
${LIBUSB_CONFIGURE_ARGS}
--srcdir="${LIBUSB_SRC_DIR}"
WORKING_DIRECTORY
"${LIBUSB_PREFIX}"
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
)
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
add_custom_command(
OUTPUT
"${LIBUSB_CONFIGURE}"
COMMAND
externals: libusb: Call program names not full paths
2021-06-03 04:53:01 -04:00
sh "${LIBUSB_SRC_DIR}/bootstrap.sh"
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
WORKING_DIRECTORY
"${LIBUSB_SRC_DIR}"
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
)
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
add_custom_command(
OUTPUT
"${LIBUSB_SHARED_LIBRARY_DEST}"
COMMAND
externals: libusb: Call program names not full paths
2021-06-03 04:53:01 -04:00
cp "${LIBUSB_SHARED_LIBRARY}" "${LIBUSB_SHARED_LIBRARY_DEST}"
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
)
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
add_custom_target(usb-bootstrap DEPENDS "${LIBUSB_CONFIGURE}")
add_custom_target(usb-configure DEPENDS "${LIBUSB_MAKEFILE}" usb-bootstrap)
cmake: General improvements to libusb linking Delegates libusb external communication to externals/CMakeLists.txt Ensures an interface library `usb` for every pathway input_common just links to the `usb` library now externals/libusb/CMakeLists.txt sets variables to override SDL2's libusb finding Other minor cleanup
2021-06-03 03:49:35 -04:00
add_custom_target(usb-build ALL DEPENDS "${LIBUSB_LIBRARIES}" usb-configure)
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
# Workaround since static linking didn't work out -- We need to copy the DLL to the bin directory
add_custom_target(usb-copy ALL DEPENDS "${LIBUSB_SHARED_LIBRARY_DEST}" usb-build)
add_library(usb INTERFACE)
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
add_dependencies(usb usb-copy)
cmake: General improvements to libusb linking Delegates libusb external communication to externals/CMakeLists.txt Ensures an interface library `usb` for every pathway input_common just links to the `usb` library now externals/libusb/CMakeLists.txt sets variables to override SDL2's libusb finding Other minor cleanup
2021-06-03 03:49:35 -04:00
target_link_libraries(usb INTERFACE "${LIBUSB_LIBRARIES}")
target_include_directories(usb INTERFACE "${LIBUSB_INCLUDE_DIRS}")
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
cmake: Fix FindPkgConfig
2022-09-20 16:21:52 -04:00
find_package(PkgConfig)
externals: libusb: Link libusb statically on Linux Turns out that this is possible. Also addresses my own review comment.
2021-06-03 04:38:29 -04:00
pkg_check_modules(LIBUDEV REQUIRED libudev)
if (LIBUDEV_FOUND)
target_include_directories(usb INTERFACE "${LIBUDEV_INCLUDE_DIRS}")
target_link_libraries(usb INTERFACE "${LIBUDEV_STATIC_LIBRARIES}")
cmake: Use autotools to build libusb generally for GNU Building libusb was also broken on GCC (and maybe Clang) on our CMakeLists after upgrading to 1.0.24, but it was not being checked because our 18.04 container had libusb installed on it. This builds on the MinGW work from earlier and extends it to the rest of the GNU toolchains. In addition we make use of pkg-config when present to find libusb. pkg-config is preferrable because we can specify a minimum required version.
2021-06-03 02:49:53 -04:00
endif()
endif()
cmake: General improvements to libusb linking Delegates libusb external communication to externals/CMakeLists.txt Ensures an interface library `usb` for every pathway input_common just links to the `usb` library now externals/libusb/CMakeLists.txt sets variables to override SDL2's libusb finding Other minor cleanup
2021-06-03 03:49:35 -04:00
else() # MINGW OR (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
# Ensure libusb compiles with UTF-8 encoding on MSVC
if(MSVC)
add_compile_options(/utf-8)
endif()
cmake: apply defaults to all externals
2023-03-01 15:31:27 -05:00
add_library(usb
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
libusb/libusb/core.c
libusb/libusb/core.c
libusb/libusb/descriptor.c
libusb/libusb/hotplug.c
libusb/libusb/io.c
libusb/libusb/strerror.c
libusb/libusb/sync.c
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
)
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
set_target_properties(usb PROPERTIES VERSION 1.0.24)
if(WIN32)
target_include_directories(usb
BEFORE
PUBLIC
libusb/libusb
PRIVATE
"${CMAKE_CURRENT_BINARY_DIR}"
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
)
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
if (NOT MINGW)
target_include_directories(usb BEFORE PRIVATE libusb/msvc)
endif()
# Works around other libraries providing their own definition of USB GUIDs (e.g. SDL2)
target_compile_definitions(usb PRIVATE "-DGUID_DEVINTERFACE_USB_DEVICE=(GUID){ 0xA5DCBF10, 0x6530, 0x11D2, {0x90, 0x1F, 0x00, 0xC0, 0x4F, 0xB9, 0x51, 0xED}}")
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
else()
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
target_include_directories(usb
# turns out other projects also have "config.h", so make sure the
# LibUSB one comes first
BEFORE
PUBLIC
libusb/libusb
PRIVATE
"${CMAKE_CURRENT_BINARY_DIR}"
)
endif()
if(WIN32 OR CYGWIN)
target_sources(usb PRIVATE
libusb/libusb/os/threads_windows.c
libusb/libusb/os/windows_winusb.c
libusb/libusb/os/windows_usbdk.c
libusb/libusb/os/windows_common.c
)
set(OS_WINDOWS TRUE)
elseif(APPLE)
target_sources(usb PRIVATE
libusb/libusb/os/darwin_usb.c
)
find_library(COREFOUNDATION_LIBRARY CoreFoundation)
find_library(IOKIT_LIBRARY IOKit)
find_library(OBJC_LIBRARY objc)
target_link_libraries(usb PRIVATE
${COREFOUNDATION_LIBRARY}
${IOKIT_LIBRARY}
${OBJC_LIBRARY}
)
set(OS_DARWIN TRUE)
elseif(ANDROID)
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
target_sources(usb PRIVATE
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
libusb/libusb/os/linux_usbfs.c
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
libusb/libusb/os/linux_netlink.c
)
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
find_library(LOG_LIBRARY log)
target_link_libraries(usb PRIVATE ${LOG_LIBRARY})
set(OS_LINUX TRUE)
elseif(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
target_sources(usb PRIVATE
libusb/libusb/os/linux_usbfs.c
)
find_package(Libudev)
if(LIBUDEV_FOUND)
target_sources(usb PRIVATE
libusb/libusb/os/linux_udev.c
)
target_link_libraries(usb PRIVATE "${LIBUDEV_LIBRARIES}")
target_include_directories(usb PRIVATE "${LIBUDEV_INCLUDE_DIR}")
set(HAVE_LIBUDEV TRUE)
set(USE_UDEV TRUE)
else()
target_sources(usb PRIVATE
libusb/libusb/os/linux_netlink.c
)
endif()
set(OS_LINUX TRUE)
elseif(${CMAKE_SYSTEM_NAME} MATCHES "NetBSD")
target_sources(usb PRIVATE
libusb/libusb/os/netbsd_usb.c
)
set(OS_NETBSD TRUE)
elseif(${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD")
target_sources(usb PRIVATE
libusb/libusb/os/openbsd_usb.c
)
set(OS_OPENBSD TRUE)
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
endif()
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
if(UNIX)
target_sources(usb PRIVATE
libusb/libusb/os/events_posix.c
libusb/libusb/os/threads_posix.c
)
find_package(Threads REQUIRED)
if(THREADS_HAVE_PTHREAD_ARG)
target_compile_options(usb PUBLIC "-pthread")
endif()
if(CMAKE_THREAD_LIBS_INIT)
target_link_libraries(usb PRIVATE "${CMAKE_THREAD_LIBS_INIT}")
endif()
set(THREADS_POSIX TRUE)
elseif(WIN32)
target_sources(usb PRIVATE
libusb/libusb/os/events_windows.c
libusb/libusb/os/threads_windows.c
)
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
endif()
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
include(CheckFunctionExists)
include(CheckIncludeFiles)
include(CheckTypeSize)
check_include_files(asm/types.h HAVE_ASM_TYPES_H)
check_function_exists(gettimeofday HAVE_GETTIMEOFDAY)
check_include_files(linux/filter.h HAVE_LINUX_FILTER_H)
check_include_files(linux/netlink.h HAVE_LINUX_NETLINK_H)
check_include_files(poll.h HAVE_POLL_H)
check_include_files(signal.h HAVE_SIGNAL_H)
check_include_files(strings.h HAVE_STRINGS_H)
check_type_size("struct timespec" STRUCT_TIMESPEC)
check_function_exists(syslog HAVE_SYSLOG_FUNC)
check_include_files(syslog.h HAVE_SYSLOG_H)
check_include_files(sys/socket.h HAVE_SYS_SOCKET_H)
check_include_files(sys/time.h HAVE_SYS_TIME_H)
check_include_files(sys/types.h HAVE_SYS_TYPES_H)
set(CMAKE_EXTRA_INCLUDE_FILES poll.h)
check_type_size("nfds_t" nfds_t)
unset(CMAKE_EXTRA_INCLUDE_FILES)
if(HAVE_NFDS_T)
set(POLL_NFDS_TYPE "nfds_t")
else()
set(POLL_NFDS_TYPE "unsigned int")
externals: Track upstream libusb We can place the external in an inner folder and manage the custom files necessary to integrate it with CMake directly. This allows us to directly change how we use it with our build system, as opposed to needing to change a fork.
2020-08-25 22:21:32 -04:00
endif()
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-30 22:26:06 -04:00
check_include_files(sys/timerfd.h USBI_TIMERFD_AVAILABLE)
configure_file(config.h.in config.h)
cmake: General improvements to libusb linking Delegates libusb external communication to externals/CMakeLists.txt Ensures an interface library `usb` for every pathway input_common just links to the `usb` library now externals/libusb/CMakeLists.txt sets variables to override SDL2's libusb finding Other minor cleanup
2021-06-03 03:49:35 -04:00
endif() # MINGW OR (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
cmake: prefer system libusb
2022-12-05 16:03:34 -05:00
add_library(libusb::usb ALIAS usb)
Reference in a new issue Copy permalink