Open NicolasFirmo opened 1 month ago
What happens if you try using our most recent release (19.7) instead? I'd like to know whether this is a regression or a persistent problem.
I figured out what happened just a couple minutes ago.
I had to run ./configure inside PortAudio directory before running cmake.
A suggestion that I give is to make it automatic inside PortAudio's CMakeLists.txt, so it behaves like any other cmake project meant to be used as a submodule
autoconf and cmake are two completely independent systems and one shouldn't affect the other. If they do, it's a bug and running configure implicitly is certainly not a proper fix.
Describe the bug If added with
add_subdirectory(path/to/portaudio)
and thentarget_link_libraries(${PROJECT_NAME} PortAudio)
, the project builds, but when trying to use functions related to device enumeration or stream opening, they failedTo Reproduce Steps to reproduce the behavior. Include code if applicable.
add_subdirectory(path/to/portaudio)
target_link_libraries(${PROJECT_NAME} PortAudio)
Pa_OpenDefaultStream
(make sure you initialize portaudio withPa_Initialize
)Expected behavior
Pa_OpenDefaultStream
returnspaNoError
Actual behavior
Pa_OpenDefaultStream
returns Device unavailableDesktop (please complete the following information):
Additional context If I
./configure
andmake
portaudio, and then I link directly against the library generated inside libs/.libs, instead of using the targetPortAudio
generated byadd_subdirectory(path/to/portaudio)
, the program works.