Build & USE portaudio via. cmake in WINDOWS

[unbadfish]

The current document is TOO far away from clear.
My practice below successfully install and use portaudio in my project, without using mingw-w64-x86_64-portaudio package provided by pacman.

---

1. definition: {pa_place} contains src/, include/, etc.
2. {build_place} will have src/, include/, etc. after building, and should have nothing before compile
3. {project_place} contains your own code, have build/, and CMakeLists.txt
4. For example, I copied pa_devs.c into {project_place}/
5. cd into {build_place} and run the following command for the same host api as the mingw-w64-x86_64-portaudio:

I believe it comes with DirectSound, WASAPI, WD/MKS, WD/MKS_DEVICE_INFO, and WMME. (compile_cmake.html)

cmake {pa_place} -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX={build_place} \
-DPA_USE_DS=1 -DPA_USE_WASAPI=1 -DPA_USE_WDMKS=1 \
-DPAWIN_USE_WDMKS_DEVICE_INFO=1 -DPA_USE_WMME=1 -DPA_USE_JACK=0

6. cd into {build_place} and run make, and run make install
7. the following code showed a minimum example of {project_place}/CMakeLists.txt

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
project(project1)
list(APPEND CMAKE_PREFIX_PATH {build_place})
# List the whole cmake prefix path list
foreach(i IN LISTS CMAKE_PREFIX_PATH)
    message(STATUS ${i})
endforeach()
# Raise error when portaudio is not found
find_package(portaudio)
if(portaudio_FOUND)
    message(STATUS "PortAudio version: " ${portaudio_VERSION})
else()
    message(FATAL_ERROR "PortAudio NOT found!")
endif()
# Remember to add the"::PortAudio"
add_executable(example1 pa_devs.c)
target_link_libraries(example1 PortAudio::PortAudio)

8. if debug is needed, add add_definitions("-Wall -g") to cmakelist
9. I didn't figure out the following question, if anyone figure out, please @ me :
   • how to build static project
   • how to debug with portaudio's source code

---

I will close my issue as fixed

• Unable to use portaudio::portaudio via. Cmake as usual practices in my project #748

[RJVB]

IMHO it would be a good idea to focus on using the CMake build system on all supported platforms. You'd gain in clarity and build efficiency (no more libtool, easy use of an out-of-source build directory, ...).

[RossBencina]

Thank you for raising this. We would love the CMake build documentation to be correct. I have been asking the CMake contributors to do this for quite some time now.

Related #662 #518 #486 #745

@RJVB we're not going to carry a required dependency on CMake. ./configure; make is the default where available -- that's much more user-friendly.

[RossBencina]

Here is the doxygen source for the current instructions if anyone would like to improve it:

https://github.com/PortAudio/portaudio/blob/master/doc/src/tutorial/compile_cmake.dox

[RJVB]

On Friday May 19 2023 16:33:28 Ross Bencina wrote: @RJVB we're not going to carry a required dependency on CMake. `./configure; make` is the default where available -- that's much more user-friendly.

I disagree. The automake/autoconf build system has probably about as many dependencies as CMake (arguments which are largely moot because both systems will be available through the distribution), it's a dinosaur that's being dropped left and right and comes with significant runtime overhead (due to the libtool wrapper script). And that's not even mentioning the waste of resources to maintain 2 build systems. User-friendly ... what are the odds that said users are developers who'd prefer to have a separate build tree (in or out of tree) and a build system defined in human-readable code that reconfigures itself automatically and efficiently when you tweak one of the build description files? And that, incidentally, is also integrated with a number of good IDEs.