Fix cpp building cmake

[rn3kk]

add LIBRARY_BUILD_TYPE to portaudiocpp

Need for fix static build as subproject (thrid-party)

[philburk]

@rn3kk - Thanks for this patch. Since you are building the CPP binding, could you please take a look at #939, and a possible fix in #963, and make a comment.

[philburk]

I am not a CMake expert. But would it be better to just build BOTH libraries using something like:

add_library(portaudiocpp_shared SHARED ${portaudiocpp-sources})
add_library(portaudiocpp_static STATIC ${portaudiocpp-sources})

[RossBencina]

I am not a CMake expert, but I think we need to go back to building both static and shared libs in the main PortAudio cmakelists. It is a regression that this functionality was removed, see

#486

and other related tickets:

https://github.com/PortAudio/portaudio/issues?q=is%3Aissue+is%3Aopen+label%3Abuild-cmake

[RossBencina]

This issue needs to be fixed but we're not currently convinced that this is the correct fix. Hence assigning low priority to this PR.

It would be good if someone can create an issue to track the actual bug that this PR is supposed to fix (i.e. the specific problem building the C++ binding).

[RossBencina]

Removing from milestone. No response for 6 minths. We have no maintainers for Cmake. We have not received any help in understanding whether this is the correct fix. Happy to contine the discussion, but this can't hold up releases.

[dmitrykos]

@RossBencina I can handle this question but in a different way. I already checked how C++ bindings are built and currently it is overly complicated - building C++ lib is detached from building of the main PA library. I can't build C++ bindings easily on Windows with MSVC currently as find_package package fails. Current implementation is probably Ok for Linux but not for generic Windows building experience.

I propose to simplify building C++ bindings by making them a byproduct of building the PA library. In this way CMake interface will provide an option to build C++ buildings PA_BUILD_CPP_BINDINGS. This approach will greatly simplify the CMake code for building C++ bindings and it will be more portable. Then will add option to make C++ bindings static or shared (similar to the intention of the given PR).

If you are ok with this approach I will develop a PR for further discussion and integration. Please let me know your opinion.

[jcelerier]

I think it should be the responsibility of the user to set BUILD_SHARED_LIBS or not depending on their needs ; as a cmake user it's actually fairly frustrating when a library tries to build both; Portaudio is small and builds fast so it's ok, but some other larger libraries or frameworks basically double their minutes-long build times for something that is going to be half-discarded anyways. It also means the user needs to pollute their own cmake code with complicated logic such as:

if(we are buildling portaudio in-tree)
  add_subdirectory(...)
  if(we want shared portaudio)
    set(portaudio_target_name portaudio_shared)
  else()
    set(portaudio_target_name portaudio_static)
  endif()
elseif(we are using prebuilt portaudio from distro)
  if(distro builds portaudio with autotools and does not ship portaudioconfig.cmake)  
    if(we want shared portaudio)
     find_library(portaudio_shared ...) # or portaudio depending on the packaging, I've seen all possible variations
    else()
     find_library(portaudio_static ...)
    endif()
    # create a target manually depending on if it's called portau
  elseif(distro ships portaudioconfig.cmake)
    find_package(portaudio)
    if(we want static portaudio and the distro provides static portaudio)
      set(portaudio_target_name PortAudio::portaudio_static)
    else if(we want shared portaudio and the distro provides shared portaudio)
      set(portaudio_target_name PortAudio::portaudio_shared)
    else(...)
      etc...
   endif()
endif()

@rn3kk if you want static build in a subproject you can just do

block()
  set(BUILD_SHARED_LIBS OFF)
  add_subdirectory(path/to/portaudio)
endblock()