CI improvements

[janheinrichmerker]

• use of GitHub Actions matrix builds for building the C libraries and CLI
• add all OS-specific libraries/CLIs to releases
• add Python 3.13 support
• build using GCC and clang

[TheMrSheldon]

What do you think about moving some of the badges away from the top of the readme since that looks rather cluttered now. Instead, the top of the readme could contain OS support badges (though we should also stress that these are the OS's that we automatically test for and probably not the only ones we support) and the language specific measures could either be moved into the language specific readme sections or in the language specific subfolders (/(c/python/jvm)/readme.md).

[TheMrSheldon]

Thank you very much for your hard work on the PR! I will look into it soon

[TheMrSheldon]

Build Debian Package should only be necessary from ubuntu-16.04 and with one compiler (clang-18) since, if the CLI can be built on various systems, so can the Debian Package and we only need to build it once to publish it in the release. As such, the Debian Package Build may even only be done on Release if we want.

[janheinrichmerker]

What do you think about moving some of the badges away from the top of the readme since that looks rather cluttered now.

I would maybe like to keep the badges at the top. If it looks a bit cluttered, that might actually also be a handy visual indicator that we support and test "everything".

[janheinrichmerker]

Build Debian Package should only be necessary from ubuntu-16.04 and with one compiler (clang-18) since, if the CLI can be built on various systems, so can the Debian Package and we only need to build it once to publish it in the release. As such, the Debian Package Build may even only be done on Release if we want.

Is this guaranteed? Or could it fail if some tool is missing? In either case, I would like to have all artifacts built before the release. So that we only do a GitHub release if everything works. And then, a matrix test does not hurt.

[TheMrSheldon]

Build Debian Package should only be necessary from ubuntu-16.04 and with one compiler (clang-18) since, if the CLI can be built on various systems, so can the Debian Package and we only need to build it once to publish it in the release. As such, the Debian Package Build may even only be done on Release if we want.

Is this guaranteed? Or could it fail if some tool is missing? In either case, I would like to have all artifacts built before the release. So that we only do a GitHub release if everything works. And then, a matrix test does not hurt.

AFAIK yes. CPack is part of CMake and the Package target does not do anything more than building the binaries and using CPack.

[janheinrichmerker]

Build Debian Package should only be necessary from ubuntu-16.04 and with one compiler (clang-18) since, if the CLI can be built on various systems, so can the Debian Package and we only need to build it once to publish it in the release. As such, the Debian Package Build may even only be done on Release if we want.

Is this guaranteed? Or could it fail if some tool is missing? In either case, I would like to have all artifacts built before the release. So that we only do a GitHub release if everything works. And then, a matrix test does not hurt.

AFAIK yes. CPack is part of CMake and the Package target does not do anything more than building the binaries and using CPack.

Still, does it hurt to test it? Let us not rely too much on some knowledge of the inner workings of CMake. To me as a C amateur, it looks like the package build "under the hood" could potentially run something completely different from the library build. And that detail is hidden in the CMakeLists.txt files (which are, frankly, not very easily understandable to non C professionals)
By the way, the Debian package job almost always finishes before the C library job anyway (as Windows is slooow), so it does not add to the overall build time.

[janheinrichmerker]

I think, re-enabling the failing build configs and fixing each of these issues should be done in separate issues and PRs after we merge this one. I'd also like to work on Maven Central publishing, so lets get this merged 🙂

[TheMrSheldon]

I think, re-enabling the failing build configs and fixing each of these issues should be done in separate issues and PRs after we merge this one. I'd also like to work on Maven Central publishing, so lets get this merged 🙂

Yeah, makes sense to me