The new CMake builds are failing since the libbinio dependency is being met by getting the libbinio source from a git repo named "libbinio" owned by the same owner as the build project (so, in this case "adplug/libbinio"). Currently, it is requesting the cmake_build branch, which is incorrect since it should be specifying an exact version of the libbinio source code and because it expects a CMake build that can run an install with output that can be consumed by a confg mode find_package(). At least this failure makes it clear that something is not yet right. There should be a cross-platform and repeatable way to do this that is under the project's control. Using a local package manager (e.g., apt, brew, chocolatey) is not directly under the project's control and inherently platform-specific. A submodule could be used (without forcing those building adplug to use it), but some folks have strong opinions on using them.

Hi @henricj

I will try to look at your PR in the upcomming days. I have some experience with cmake and its CMakeLists.txt, but not a lot, so please allow me to ask some stypid questions upfront.

Which build-uses cases are intended to work currently:

a) package builders, people that make .deb and .rpm files or want to install stuff into their /usr/local/ area. Here the system normally will have libbinio and its development files in the system already, and they expect the build this library and install it into their system/buildroot .

b) app builders and projects that do not want to rely on external resources. Good example is to compile games into standalone application under Windows. They want to add libbinio, adplug and other external projects as git submodules, and have a master build-system which can be cmake.

Hi @henricj

I will try to look at your PR in the upcomming days. I have some experience with cmake and its CMakeLists.txt, but not a lot, so please allow me to ask some stypid questions upfront.

Which build-uses cases are intended to work currently:

a) package builders, people that make .deb and .rpm files or want to install stuff into their /usr/local/ area. Here the system normally will have libbinio and its development files in the system already, and they expect the build this library and install it into their system/buildroot .

b) app builders and projects that do not want to rely on external resources. Good example is to compile games into standalone application under Windows. They want to add libbinio, adplug and other external projects as git submodules, and have a master build-system which can be cmake.

The intention is for it to work both as a subdirectory (typically a git submodule, which I do here so that I can compile it with LTCG and statically link it with the game) and stand-alone (be that through a package manager or after cmake --build . --target install). Where I got stalled was when I wasn't sure how this project wanted to deal with the libbinio dependency. The first thing that came to mind was to add libbinio as a submodule, and then have a switch to let the user either reference that submodule or satisfy the dependency through a find_package(), providing a CMakePresets.json with presets for both. For testing and development (and repeatable CI builds), one wants them tightly coupled (especially since both are part of the same overall adplug umbrella), but it is also important that it work with the local system's libbinio through the normal package manager on that system where they are not tightly coupled.

Ideally, the CMake stuff should also "just work" for inclusion into vcpkg, but I haven't looked into that.

It has been a few weeks since I last looked at this, so I'm not as clear on all the details as I once was...