Various cmake improvements

[Ri0n]

initial problem was missing protobuf-c on windows.

So added various way of building with protobuf-c suitable probably for every imaginable case.
Also added installation of cmake config files to make it super easy to use libomemo from other cmake projects.

For example I can build a bundled/static version with

cmake -DCMAKE_INSTALL_PREFIX=../omemo-static-install -DBUILD_WITH_PROTOBUF=bundled -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Debug ~/projects/psi/qomemo/

and then use it like

list(PREPEND CMAKE_PREFIX_PATH /home/rion/temp/omemo-static-install)
find_package(omemo-c)
target_link_libraries(mytarget omemo-c::omemo-c)

[Neustradamus]

@mar-v-in, @fiaxh: What do you think about this PR?

[mar-v-in]

Hi @Ri0n and @Vitozz

Instead of adding further complexities to the CMake-based build system, I plan to migrate this entirely to Meson, which has a lot of built-in advanced features for a) cross-platform builds, b) building static libraries and c) bundling with dependencies (libprotobuf-c in this case).

I started work on the meson branch (but it currently requires having protoc-c/protoc-gen-c already available on the host system to build the .pb-c.{c,h} files, which in the CMake approach came shipped in the repository - another thing I don't like with the current build approach as the repository should not include automatically generated files).

Can you describe in more detail what exactly you need for your usecase? Is all you need a simple command that builds libomemo-c into a single static library for Windows?

[Vitozz]

Hello @mar-v-in.
I will try briefly describe the changes in the CMake scripts

1. Added module for searching the protobuf-c library. This has allowed us to abandon the pkg-config, which simplifies the build for Windows. Under Linux, the module uses the pkg-config if the library has not been found earlier and the search result is not in the cache.
2. Added generation of a CMake module for integrating the library into the system. This module allows you to easily "connect" the library to other CMake-based projects (our project uses CMake).
3. Added the ability to compile omemo-c library with built-in protobuf-c library without having it in the system. The script downloads the protobuf-c source code to the omemo-c build directory and builds the omemo-c library together with protobuf-c. The change is controversial. I can describe why we did it this way. We use the omemo-c library for the plugin. We compile the plugin for Windows using MSVC and cross-compilation using MXE. When compiling the plugin the script downloads omemo-c library sources, omemo-c script downloads sources of protobuf-c and then as a compilation result we get one file of the plugin library. This greatly simplifies further maintenance not only in Windows, but also in MacOS and when creating an appimage for Linux. The only thing is that in the built-in protobuf-c library module there is no specific tag for the protobuf-c github repository, now it links to main branch, which can lead to problems with radical changes.

If Meson is going to be used, this pull request may not be worth paying attention to.

[LecrisUT]

I plan to migrate this entirely to Meson, which has a lot of built-in advanced features for a) cross-platform builds, b) building static libraries and c) bundling with dependencies (libprotobuf-c in this case).

Just wanted to point out that all of those features are available with CMake, e.g. c) is FetchContent. But if you wanted to migrate anyway, up to you. Note that you should provide the equivalent of Config.cmake of meson for distro packagers to opt-out of bundling, but I'm not aware of meson having that.

[mar-v-in]

@LecrisUT Meson fetches und builds fallback wraps only on demand. If a dependency library is available on the system, the system library will be used instead. Fallback wraps can also be entirely turned off easily by setting -Dwrap_mode=nofallback.

The meson branch now has CI builds for the three major platforms, which also tests that dependency libraries can be either available on the system or built as wrap submodules. This even includes that the regular protoc is built, used to build protoc-gen-c, which itself is then used to build the .pb-c.{c,h} files all at build time. I still need to do a few things more explicit (by hosting the required .wrap files in the submodules folder rather than fetching them on demand from WrapDB and by running the CI with -Dwrap_mode=nofallback or -Dwrap_mode=forcefallback respectively), but beside that, this already works great and on Windows you only need to set up Visual Studio and Meson (incl. ninja) to be able to compile everything.

[Ri0n]

I know nothing of Meson. But if the package will be available on Conan for Windows and Mac being built with various compilers, I believe it will solve all problems for me.
Linux is usually resolved automagically =)