introduce single CMake script build all packages

[syuu1228]

This introduces single CMake script to build all packages and non-package build with same result, including shared library SONAME and versioning.

Complicated shellscripting to build package build are no longer required, everything can be build with "cmake -S . -B build && cmake --build build".

Note that there is a limitation, this requires a dummy C code to call libscylla-cpp-driver function. It is because this rebuild libraries with C Linker on CMake. The dummy C code is located at dummy/dummy.c.

CMakeList.txt is now fully re-written without unrelated codes. And to build Rust code easier, imported CMakeRust project: https://github.com/Devolutions/CMakeRust

And also FindLibClang.cmake from cpp2py: https://github.com/TRIQS/cpp2py/blob/master/cmake/FindLibClang.cmake

Both included few patches since little bit outdated, and have few bugs.

Pre-review checklist

• [ ] I have split my patch into logically separate commits.
• [ ] All commit messages clearly explain what they change and why.
• [ ] PR description sums up the changes and reasons why they should be introduced.
• [ ] I have enabled appropriate tests in .github/workflows/build.yml in gtest_filter.
• [ ] I have enabled appropriate tests in .github/workflows/cassandra.yml in gtest_filter.

[syuu1228]

Build passed on following environments:

• RPM
  • rocky-8-x86_64
  • rocky-9-x86_64
  • fedora-38-x86_64
  • fedora-39-x86_64
  • fedora-40-x86_64
  • fedora-rawhide-x86_64
• DEB
  • Ubuntu x86_64
  • focal (20.04), jammy (22.04), mantic (23.04), noble (24.04), oracular (24 .10)
  • Debian x86_64
  • bullseye (11), bookworm (12), trixie (13), sid (unstable)
• HomeBrew
  • macOS Sonoma 14.5/arm64

Build failed on following environments:

• DEB
  • Ubuntu x86_64
  • bionic (18.04)
  • Debian x86_64
  • buster (10)

These two are outdated releases, does not have newer packages for build dependencies. I think we just can drop them from support list.

[wprzytula]

@syuu1228 CI is failing because libclang is not found.

[wprzytula]

Waiting with review until CI stops failing.

[syuu1228]

Rewrited almost all code, now CI can pass. Here are change lists:

• Clean up of CMakeLists.txt broke INTEGRATION_TESTS so I reverted this code, and re-implemented same feature without cleanup.
• Fixed dependencies on INTEGRATION_TESTS Github Actions
• On previous version, a shared library builds on CMake with C linker, which can set SONAME and do versioning natively. But I have found that exported symbols are very different, when comparing a shared library built on CMake vs built on Cargo. Seems like CMake one including all private functions, Cargo one is not. So I stopped building a shared library on CMake, implemented library versioning on CMake instead (it does almost same thing with versioning.sh).
• Dropped FindLibClang.cmake, since it cause error on some environment, even cargo build can run without the error on same environment.

[syuu1228]

Build failed on following environments:

• DEB

  • Ubuntu x86_64

  • bionic (18.04)

  • Debian x86_64

  • buster (10)

These two are outdated releases, does not have newer packages for build dependencies. I think we just can drop them from support list.

Fixed the build failure, now build passed on these distros.

[Lorak-mmk]

Afaik apart from using prebuiilt libraries (.so + .h) it's popular in C/C++ to use submodules (or something similar) and CMake's add_subdirectory to build dependency alongside main project. It was one of the goals to be mostly compatible with cpp-driver, which allowed such usage. Example: I used cpp-driver in this manner during ZPP project in a more modern C++ wrapper: https://github.com/scylla-zpp-blas/scylla_modern_cpp_driver/blob/a9ea3ca5b2d2921af497164994d64ddf09e52fd9/CMakeLists.txt#L6

Is such usage still possible after your changes? I didn't review the changes yet, but I see fragments:

#---------------
# Policies
#---------------

if(POLICY CMP0074)
  cmake_policy(SET CMP0074 NEW)
endif()

if (POLICY CMP0054)
  cmake_policy(SET CMP0054 NEW)
endif()

or

set_property(GLOBAL PROPERTY USE_FOLDERS ON)

I can't say I know CMake that well, so I'm not sure: is this going to be a problem?

[mykaul]

What's the status of this PR?