Closed sonoro1234 closed 2 years ago
Update:
I have been able to compile static with this lines for adding the PortMidi subproject. It works, but I wonder if it would be cleaner with PM_LIB_SHARED instead
#this is luaportmidi cmake
set(PORTMIDI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../portmidi)
set(OLD_BUILD_SHARED_LIBS ${BUILD_SHARED_LIBS})
set(BUILD_SHARED_LIBS OFF CACHE BOOL "" FORCE)
add_subdirectory(${PORTMIDI_DIR} ${CMAKE_BINARY_DIR}/portmidi EXCLUDE_FROM_ALL)
set(BUILD_SHARED_LIBS ${OLD_BUILD_SHARED_LIBS})
Normally all you have to do is to use:
add_library(portmidi ${PM_LIB_PUBLIC_SRC})
and then you can control wether you want a shared or a static lib with the BUILD_SHARED_LIBS variable!
Yes, the problem appears when you need more than just this library
Solution would be to have a PortMidi specific variable
No, that breaks CMake conventions as recommended in the CMake documentation. If you want to set a variable just for one add_subdirectory
then I think https://github.com/PortMidi/portmidi/issues/8#issuecomment-1001963393 is an appropriate solution. Alternatively you can use ExternalProject_Add with CMAKE_ARGS -D BUILD_SHARED_LIBS=OFF
or a package manager.
Yes, https://github.com/PortMidi/portmidi/issues/8#issuecomment-1001963393 solves it for me, but I dont think that https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html is telling that specific variables are breaking any CMake convention at all.
So, I dont mind specially what is done, but I dont think that this "CMake conventions" are more than suppositions.
It seems like CMake has problems either way: both solutions create a "shadow variable" (either PM_BUILD_SHARED_LIBS or OLD_BUILD_SHARED_LIBS) to hide info from CMake where scope rules or modularity fail to do the job. Since directly using BUILD_SHARED_LIBS is already in place in PortMidi, I'm inclined to leave it -- at least it's simpler and easier to understand for most cases. I'm still open to counter-proposals/arguments. Maybe it's just my perception, but it seems CMake is constantly evolving, and perhaps this case will be better supported in some future release.
I dont think that this "CMake conventions" are more than suppositions
They are. Tooling is built around them. If you break them, you force packagers and downstream users to learn idiosyncratic hacks for one particular library.
So, lets close
Trying to build a static lib in windows (but I think this is not windows specific) fails. PortMidi is used as a submodule to my main project Lua2SC, where I want some librarys to be SHARED and others to be STATIC.
There is also a warning about using BUILD_SHARED_LIBS in portmidi
Solution would be to have a PortMidi specific variable ( as PM_LIB_SHARED for example) set by the user and then in pm_common/CMakeLists:
Also, all other uses of
BUILD_SHARED_LIBS
should be changed toPM_LIB_SHARED