[REQUEST] Add Cmake support about btop HOT 10 CLOSED

Windows is very unlikely to be supported unless someone else takes on that pretty big challenge. Btop++ is written with very much POSIX in mind, things like threading, signal handling and input are very much POSIX dependent.

Changing the build system for something that isn't even looked at being implemented and if it was, likely would take a long time to finish would be extremely premature.

from btop.

@WSLUser
I really don't see a use for Cmake. This is a small project with few files. The only platform dependent compiler flag is -fcf-protection and is easily handled by logic in the Makefile.
llvm-clang is currently not supported because clang currently don't support C++20 Ranges. When clang has complete C++20 support (or as complete as gcc), there is no problem to again handle the correct flags for the compiler with logic in the Makefile.

Biggest one is portability. On platforms where Make isn't available, Cmake can still be made use of.

First off, which platform are you referring to that doesn't support Make ?!?
Second, CMake can't replace Make. It's a build system generator, you still need a build system like Make to actually build the software.

from btop.

@WSLUser I created a fork with cmake support and opened a PR draft #82. Your input would be most welcome.

from btop.

First off, which platform are you referring to that doesn't support Make ?!?

Windows for one, but I think there are others based on arch or other reasons. I'm not sure how Visual Studio handles cmake, maybe they use the Msys2 or WSL make in the backend. Right now point is, I want to see the project available for as many platform and architectures as possible and that requires doing things like adding cmake support.

from btop.

There was a lot of discussion in #82 but the TL:DR is that there will be no cmake in this repo unless it becomes necessary.
So I decided to merge my cmake branch into the main of my fork and maintain a cmake version there.
I've now setup a job scheduled to run every 5min merging the upstream master. If a new version tag was added upstream it will create a corresponding version tag with the suffix -cmake on my fork and run my build and release workflow.
This creates static musl builds for all available 51 targets and dynamically linked ubuntu packages.
https://github.com/jan-guenter/btop/releases

I also setup a notification whenever the Makefile changes and I'll do my best to keep the cmake file in sync.
Other automated distro package build will follow shortly.

@aristocratos following the discussion in #82 I feel it makes little sense to keep this issue open, since it's idea is basically declined for now.

from btop.

Closing for now.

@jan-guenter
Do you want me to add a note regarding your cmake fork in the readme?

from btop.

@aristocratos That's up to you, but might be interesting for some.

from btop.

@aristocratos Different idea: Perhaps a wiki page would be more useful than bloating the readme with information not strictly relating to this project. You could still link the wiki page in the readme.
In such a wiki page you could collect other derived works or user packages like #73

from btop.

@jan-guenter

Perhaps a wiki page would be more useful than bloating the readme with information not strictly relating to this project.

That is a good idea, but then there also the expectation that I should fill it with useful information :)

Will take a look at it when I've got time.

from btop.

@aristocratos
True, but perhaps there are other willing to contribute to it.
You could open an issue and ask the community for help and contributions. You would still need to vet the contributions but still better to write everything on your own.
That said, I also agree that's not a priority and perhaps a bit early in the projects life.

from btop.