libusb-cmake as libusb provider and added MSVC Support #1440
Conversation
- Changed Legacy MINGW Checkers for MSVC - If not available, now `Findlibusb.cmake` fetches `libusb-cmake` repo and includes it at config time - For MSVC, Added fix for ill-defined `ssize-t` - For linux build-along, added check whether LIBUDEV is installed/enabled
cmake/modules/Findlibusb.cmake
Outdated
| if (NOT LIBUSB_FOUND) | ||
| message(FATAL_ERROR "libusb library not found on your system! Install libusb 1.0.x from your package repository.") | ||
| message(STATUS "No libusb-1.0 not installed into your system. Downloading and building it from source") |
There was a problem hiding this comment.
This is not a good practise from my point of view.
All unix-based systems should continue to install and use libusb provided from their respective package repositories. It must be considered a very bad attempt to mix locally installed newer library versions with probably already existing dependencies used by other (system) packages originating from the package system, as this opens the door for incompatibilities and functional failures.
There was a problem hiding this comment.
Ok, no problem, Will revert to the old practice!
As for windows, Will do some checks for dll locations compatibility later today or tmr, so we can be sure for this as well
|
Tested the MSVC Build and it needs some additional root cmake modifications to work, but totally easy to do. Will come back with them sometime later today. As for the library part, This is something that cannot be brought to this PR, since it requres restructuring in both code and CMAKE:
|
| # Link shared library | ||
| if (WIN32) | ||
| target_link_libraries(${STLINK_LIB_SHARED} ${LIBUSB_LIBRARY} ${SSP_LIB} wsock32 ws2_32) | ||
| else () | ||
| target_link_libraries(${STLINK_LIB_SHARED} ${LIBUSB_LIBRARY} ${SSP_LIB}) | ||
| endif() | ||
|
|
||
| install(TARGETS ${STLINK_LIB_SHARED} ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}) | ||
|
|
||
| # For windows, shared libraries go to `bin` and their implibs go to `lib` |
There was a problem hiding this comment.
Documentaton: Replace "implibs" with "imported libraries (implibs)" in comment for clarification.
| @@ -51,75 +52,42 @@ elseif (CMAKE_SYSTEM_NAME STREQUAL "OpenBSD") # OpenBSD; libus | |||
| message(FATAL_ERROR "No libusb-1.0 library found on your system! Install libusb-1.0 from ports or packages.") | |||
| endif() | |||
|
|
|||
| elseif (WIN32 OR (MINGW AND EXISTS "/etc/debian_version")) # Windows OR cross-build with MinGW-toolchain on Debian | |||
There was a problem hiding this comment.
Would it be possible to leave
elseif (MINGW AND EXISTS "/etc/debian_version") # Cross-build with MinGW-toolchain on Debian
including the following associated code block for now, until cross building via MVSC on Linux has also been tested and verified? The idea is to drop this part as well later on, if everything works well. I'd just prefer to keep at least one working approach for now ...
Overview
This pull request alters
Findlibusb.cmakein order to add proper Windows MSVC handling. It discards the old MINGW approach and uses thelibusb-cmakerepository as the main provider instead for both Windows and Linux. As it stands now, iflibusbis not installed for these two OSes, the libusb-cmake repository is being cloned and incorporated into the build. This way,stlinkhas a freshly builtlibusb, tailored to the system's configuration and needs, installed into the sameINSTALL_PREFIXasstlink.Additionally, this pull request adds Windows/MSVC support into the c/c++ github workflow.
Potential issues
In Windows, there is a possibility that the installation path for all
LIBRARYitems must be the same as the one ofRUNTIMEitems, as opposed to the Linux paradime, whereLIBRARYandARCHIVEitems are the ones that share location. This needs further investigation and potentialy a complementary fix, as I currently have no equipment and a clean environment to test it. I'll get back to it once I manage to prepare the proper testing ground.One very important note on this PR is that it probably drops support for MINGW. If mingw is still needed I'm going to need assistance, Since I've never worked with it in the past and i do not know how to properly validate such builds.