Implement CMake build script

[jcelerier]

Hello, here's a build script to allow using RubberBand with CMake.

It's not finished yet, but if you want to review it it should not change much.

[Be-ing]

have more in common with systems I'm using elsewhere

This is the big reason for using CMake over Meson. The C/C++ ecosystem is generally converging on CMake. Qt6 now uses CMake. Microsoft Visual Studio includes CMake now. Microsoft's vcpkg is built with CMake too and using CMake makes it trivially easy to package libraries in vcpkg (which is the motivation for @Holzhaus and me working on this).

[Holzhaus]

Of course you can build both static and shared libs simultaneously when renaming one of them: https://stackoverflow.com/a/29824424

However, this is pretty bad from the user's standpoint IMHO:

1. It breaks the standard BUILD_SHARED_LIBS option
2. If you add both to the ALL target, both are built by default even though most users only need one of them
3. Projects that use rubberband now need able to detect multiple different names or drop support for one of them.

[matthiasbeyer]

From a packagers perspective (packing on CentOS/Debian as my dayjob, and Nix by night) I can say: Don't use meson. It's the one build system we (dayjob) have the biggest problems with (except maybe autotools), because it pulls in python and with that a whole zoo of stuff.

Just my 2ct, tho.

[eszlari]

One thing to consider: CMake's add_subdirectory() vs. Meson's subproject(). Normally, they each can only include other projects into their tree, that use the same buildsystem. But Meson has (some) support for CMake, which ironically would make CMake the better choice, because this way, other projects could add rubberband to their trees, whether they use Meson or CMake.

[cannam]

The next release will definitely use Meson. I'll keep an eye on feedback (including from commercial users) and may review later. I am actively working on Rubber Band at the moment, so (a) I am glad to have a build system I like working with, but also (b) there should be more releases to follow, giving options to review the situation.

I'm also going to retain some of the previous build files in a subdirectory (otherbuilds) in case anyone directly needs a Makefile or Visual Studio project file. These will be modified to build only the static library, so no versioning issues, and will also be tested in CI.

Thank you everyone for providing the impulse to review the build situation, and for all the work put into the proposed CMake scripts. If this decision turns out to be a bad one, then switching will be much easier with this work to start from.

[eszlari]

@cannam Any estimate when you will merge the meson branch into master?

I guess when rubberband is available through vcpkg, it will not make much of a difference for consumers on Windows, wether you use Meson or CMake. And vcpkg improved their Meson support too.

[Be-ing]

Actually it will make a difference because Meson has nothing comparable to WINDOWS_EXPORT_ALL_SYMBOLS for dynamic linking on Windows. Dynamic linking on Windows could be implemented on Windows with Meson, but this requires some more work than simply setting the WINDOWS_EXPORT_ALL_SYMBOLS property on a CMake target.

[eszlari]

You could add a custom_target() in Meson that uses dumpbin to generate the .def file:

https://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll