-
-
Notifications
You must be signed in to change notification settings - Fork 597
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
CMake Migration #2
Conversation
I'm a little late to it but may I ask what the rationale was for switching to CMake? I was running live builds of Remmina up until the point you switched and I never saw any issues in the way autotools was being utilized. Is it a system the new devs are more comfortable with or was a it a design decision to improve development? |
@doctaweeks there's pretty much just me working on this right now, since vic is busy. In the related FreeRDP project we switched from autotools to cmake and we really liked it. It's much simpler and fun to develop with. It also has the ability to generate project files for just about any build system in existence, a very valuable feature. |
CMake Migration
Migration of the build system to cmake.
I have tried my best to replicate what the original build system was doing with cmake. It should be able to provide configurable builds, with proper installation of data files and translations.
The only little glitch left which I am not sure of is building remmina with libssh. The NX plugin can build and load fine with it, but as soon as remmina is built with libssh it will fail to start with an error saying that remmina is linked to both GTK2 and GTK3 libraries at the same time. When trying to identify the culprit I noticed that when libssh was enabled, remmina was linked against libgtk-x11-2.0.so.0, while it wouldn't if libssh was disabled.
The other thing which would be left to check is how to create packages, but that can come later.
If the current cmake migration is stable enough to be merged without affecting too much people, I suggest we go ahead.