sony
Any interest in making nmos-cpp supported by vcpkg?
Why not supporting vcpkg with nmos-cpp so that nmos-cpp can be installed with vcpkg?
As nmos-cpp isn't only installing nmos specific headers in the nmos include directory, I created an outer optional CMakeLists.txt to configure/build nmos-cpp in terms of a library. There were some changes to the Development/CMakeLists.txt and Development/cmake/NmosCppLibraries.cmake necessary which only do affect the project if the outer CMakeLists.txt is used or special CMake parameters are set. If not nmos-cpp configures and builds in the same way as before without these changes.
Find the patches here: https://github.com/aholzinger/nmos-cpp/commit/faedea227c487964f7ae00d2bf13a66d0cce415 https://github.com/aholzinger/nmos-cpp/commit/ae0ac6e0252311108da703fb354b8eba76da3035
I then created a vcpkg CONTROL file and a vcpkg portfile.cmake. By creating an nmos-cpp directory in the ports directory of the vcpkg repo and copying the two files there one can install nmos-cpp in vcpkg. The following patch added the two files: https://github.com/aholzinger/nmos-cpp/commit/7957bf1636860e1b289633f4250a2c4ea8d5d8fe
Only tested under Windows yet with x86-windows-static and x64-windows-static triplets.
(By the way I've fixed up all your URL links in these issues, because you didn't have the Markdown syntax quite right.)
Sorry foir the links, I'm not very familiar with github :-( Thanks for fixing.
The next step I will do is to check dynamic linking (just orederd a 12TB hard disk :-) and then Linux.
With some small change in the portfile https://github.com/aholzinger/nmos-cpp/commit/d290f1ff570b76509698ccf292f7541fc7ffaa13 x86-windows and x64-windows (which use the dynamic runtime) do also work.
I've pushed 61808cd9034c0dfd9c3abc1e3a2460971dbc169a, based on https://github.com/aholzinger/nmos-cpp/commit/ae0ac6e0252311108da703fb354b8eba76da3035.
Is https://github.com/aholzinger/nmos-cpp/commit/faedea227c487964f7ae00d2bf13a66d0cce415 actually required for vcpkg, or only because nesting the nmos-cpp top-level CMakeLists.txt? It was my intention people wouldn't do that, but would use cmake/NmosCppLibraries.cmake if they were building their own Nodes rather than nmos-cpp-node.
Yes, it's needed for the outer CMakeLists.txt.
Could you explain more detailed what you mean by
would use cmake/NmosCppLibraries.cmake
How could one make use of CMake without a CMakeLists.txt?
My understanding was to use nmos-cpp as a library, resp. a set of libraries to build nodes/registries and with CMake add it to a project via find_package for example. But I might have understood wrongly.
What is instead the recomended way of "using" nmos-cpp in my project? I would prefer finally not to use a fork, but sony/nmos-cpp.
The nmos-cpp project delivers a number of static libraries, two example applications and a (partial) unit test suite (most our testing effort goes into the AMWA NMOS Testing Tool).
The main point of the top-level CMakeLists.txt is to build the example applications. If you wanted to build your own Node using the libraries/modules, I thought you would prepare your own top-level CMakeLists.txt using cmake/NmosCppLibraries.cmake to build the libraries. But this was first attempt at packaging the libraries and apps with CMake, so I am happy to refactor it, for sure.