PortAudio / portaudio

PortAudio is a cross-platform, open-source C language library for real-time audio input and output.
Other
1.43k stars 296 forks source link

Portaudio not working if added as a cmake submodule #942

Open NicolasFirmo opened 1 month ago

NicolasFirmo commented 1 month ago

Describe the bug If added with add_subdirectory(path/to/portaudio) and then target_link_libraries(${PROJECT_NAME} PortAudio), the project builds, but when trying to use functions related to device enumeration or stream opening, they failed

To Reproduce Steps to reproduce the behavior. Include code if applicable.

  1. Clone the repository into your project folder (or add as a git submodule)
  2. In the CMakeLists.txt: add_subdirectory(path/to/portaudio)
  3. Link portaudio to your project executable target_link_libraries(${PROJECT_NAME} PortAudio)
  4. Build the application that contains calls to functions like Pa_OpenDefaultStream (make sure you initialize portaudio with Pa_Initialize)
  5. Check the error code returned by the function

Expected behavior Pa_OpenDefaultStream returns paNoError

Actual behavior Pa_OpenDefaultStream returns Device unavailable

Desktop (please complete the following information):

Additional context If I ./configure and make portaudio, and then I link directly against the library generated inside libs/.libs, instead of using the target PortAudio generated by add_subdirectory(path/to/portaudio), the program works.

RossBencina commented 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.

NicolasFirmo commented 1 month ago

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

dechamps commented 1 month ago

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.