search

radarsat1 / liblo

liblo is an implementation of the Open Sound Control protocol for POSIX systems
GNU Lesser General Public License v2.1
192 stars 60 forks source link

Cmake error on Github Actions #131

Closed malloch closed 2 years ago

malloch commented 2 years ago

After yesterday's merges, building liblo in GitHub Actions over on the libmapper repo fails on Windows.

-- Building for: Visual Studio 17 2022 -- Setting build type to 'Release' as none was specified. -- The C compiler identification is MSVC 19.33.31629.0 -- The CXX compiler identification is MSVC 19.33.31629.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.33.31629/bin/Hostx64/x64/cl.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.33.31629/bin/Hostx64/x64/cl.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for poll -- Looking for poll - not found -- Looking for select -- Looking for select - not found -- Windows configuration: Assuming select exists. -- Looking for getifaddrs -- Looking for getifaddrs - not found -- Looking for inet_pton -- Looking for inet_pton - not found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - not found -- Found Threads: TRUE
CMake Error at CMakeLists.txt:235 (target_link_libraries): Cannot specify link libraries for target "PRIVATE" which is not built by this project.

malloch commented 2 years ago

This may be due to some change in GitHub Actions – we are investigating...

radarsat1 commented 2 years ago

Yeah a couple of the changes introduced PRIVATE, but I thought that might be correct. Not sure. It seems that PRIVATE continues to link the library transitively, but stops propagating compilation flags associated with the transitive dependency. So maybe the Windows build needs some flags from the libraries that liblo needs to link with. I'll have a look over at what's going on with libmapper when I get a chance, probably tomorrow.

(And yeah, not a bad idea to stick to a release tag or commit checksum! But nice somehow that it triggered an issue so that it could be identified and fixed immediately.. not sure which I prefer ;) Maybe useful would be a build against a release/checksum version, and a second non-failing build against master that would just flag the issue?)