Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to CMake #148

Open
Flamefire opened this issue Apr 29, 2020 · 3 comments · May be fixed by #177
Open

Switch to CMake #148

Flamefire opened this issue Apr 29, 2020 · 3 comments · May be fixed by #177

Comments

@Flamefire
Copy link

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 gkdr/libomemo@4d7bbc2 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
Copy link
Owner

gkdr commented Mar 10, 2021

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 🙂

@selurvedu
Copy link

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

@gkdr gkdr mentioned this issue Jun 3, 2021
3 tasks
@grimmy
Copy link

grimmy commented Jun 10, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants