Anyone did cmake based build system? for use with CLion?

Development
1

Anyone did cmake based build system? for use with CLion?

2

You’re the first to ask, so if you did this yourself, you likely wouldn’t be doing redundant work.

1 Like
3

Not cmake, but I did a setup with meson to build 0.6 and plugins thereof.

  • There’s a built-in mechanism for downloading, unpacking and patching external dependencies from archive files. I used that to replace wgets in the makefile and the patches added meson definitions.
  • There is also a mechanism for dealing with git submodules but those can’t have patches. Which means you have to either subordinate the repo under an extra folder or patch upstream to support being a subproject. This worked in Rack’s case, but…
  • Meson is opinionated. All subprojects have to go in a specific folder. It won’t let you define entire projects at the top level (ex. if two subprojects have a “config” header, you have to rename the headers or place meson build scripts in subdirectories) and PRs to fix it were emphatically rejected.

The bonus was that it was more modern than a GNU Makefile. There’s a built-in mechanism for handling basic config tests. There’s a built-in mechanism for downloading tarballs to use as subprojects. There’s less boilerplate to write than CMake. There’s less lines of code to support vendored dependencies (ex. for a while I had a Rack build that removed the majority of dependencies in favor for ones from Tumbleweed, though it did require patching around two GLFW call sites very minorly.)

CMake is more obedient (although perhaps also much larger both in total documentation and binary sizes) so likely an easy port from the meson files back to CMake. Depending on if you want the build system to totally encapsulate the project (as I did) or simply work around the dependency build systems (as Rack, and often CMake projects do.)

Although with this line in the repo:

I rarely accept code contributions to Rack itself, so please notify me in advance if you wish to send a pull request.

I’m not sure that augmenting the build system is worthwhile.

  • Windows and macOS users are installing from bins anyway,
  • AUR users don’t care about dependency vendoring one way or the other,
  • Launchpad/OpenBuildService builds don’t care and,
  • I’m not sure being accepted in official Deb/Ubuntu/Fedora/SuSE bins is a goal.

Building plugins is derpier. You can do it (make them subprojects, so Rack+all interested OSS plugins end up part of the same ninja build call) but meson’s opinionation makes it hard to install them in the format Rack wants them in.

1 Like
4

I’m using cmake with CLion. You can find my CMakeLists.txt file here: https://github.com/dhemery/DHE-Modules/blob/master/plugin/CMakeLists.txt

1 Like
5

@dhemery I’ve noticed that you stopped using CMake, mind to share why?
AFAIK without it code inspection does not work in CLion

6

I never felt I understood CMake, or how it integrates with CLion. When CLion added makefile support, I found that I could do everything I needed with make, and CLion was reasonably happy about it.

For my own inspections I use clang-tidy, which I invoke via make. I think CLion runs clang-tidy also, based on the .clang-tidy file.

I sometimes change tools merely to learn something new, or for no good reason at all. I’m fickle that way. At the moment, for example, I’m seriously exploring the upcoming neovim, to see if its LSP support gives me enough IDE-like features. If it does, I might drop CMake.

7

Thank you, yeah CMake is complicated beast, only yesterday I stumbled on bug in latest version, to explore LSP also in my todo list, but with Sublime Text and upcoming version 4.