search

gkdr / lurch

XEP-0384: OMEMO Encryption for libpurple.
GNU General Public License v3.0
289 stars 32 forks source link

Switch to CMake #148

Open Flamefire opened 4 years ago

Flamefire commented 4 years ago

There are some issues open referring to building on other systems, packaging etc. This could be made much easier if using CMake instead of plain make.

It will also allow customization of build variants. E.g. currently the whole build is done in Debug mode without optimizations which is obviously suboptimal. Especially after https://github.com/gkdr/libomemo/commit/4d7bbc25e38789fa1265ae9610e64c6343a7ef3b in the sub library too includes debug symbols in the build. With CMake it is a matter of passing -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release to the configure process.

A couple of find_library or even find_package calls would help in pointing out dependencies and giving package managers hooks in how to inject known locations to existing libraries as well as allowing dependencies in non-default locations.

axc already uses CMake so integration with that would be made easier too.

I hence suggest to start moving libomemo to CMake, then follow with lurch. Inclusion can then happen either via add_subdirectory which builds the dependencies as part of the main build or by first building and installing the dependencies and then using find_ commands to find them with the downside of a multi-step build. Both can be combined as e.g. add_subdirctory is used when the find_ command does not find the package.

Final note: Start with CMake 3.8 as the minimum and use targets and target_* functions everywhere. Makes your life easier.

gkdr commented 3 years ago

hi @Flamefire,

sorry for not replying earlier. i agree, the build definitely got too complicated for a makefile, especially now. thanks for the pointers on which cmake functionality to make use of - since i have no experience with it, that might be a good start.

for the foreseeable future, i feel like there are more pressing matters for me personally. i'll gladly take a contribution though :slightly_smiling_face:

selurvedu commented 3 years ago

JFYI, Meson would be a better choice since Pidgin itself uses Meson. Well, not the 2.x.y branch, but still.

grimmy commented 3 years ago

Newer versions of the pidgin2 win-dev directory have support for meson if you want to go that route.