When to use cmake and when not?

Community
1

After trying hard to put cmake working on various OS and for various IDEs, Im not convinced by cmake advantages: unifying all these worlds.

There were always pitfalls depending on the IDE or OS. So, Im thinking, I would have been better off, just keeping up to a certain OS and a certain IDE, rather than trying to write the unifying cmake of the whole universe.

So, if I ask you, when to use cmake and when not, what would you answer?

2

I would switch from system specific build system to CMake if:

  • the final user/developer does not loose the advantage of its usual IDE, otherwise she/he will always blame CMake (and you if you pushed the switch)
  • you gain something for this system: performance, robustness, unified build for part of system/IDE sets, …

I am using CMake for almost 15 years so I’m quite confident on what can be done with CMake and the benefit you can get from it, however I wouldn’t try to convince an accustomed Visual Studio/IntelliJ/PickYourIDE developer that he ought to be using CMake if he does not want to try.

All that said CMake seems to be a new tool for you, so there is a learning curve which is not steep for making it working, but some corner case are not always easy to handle at first. May be you can take low hanging fruit and leave the problematic system/IDE as they are and come back to them later when you gain experience with the system/IDE couple that work seamlessly with CMake.

1 Like
3

Thanks.

How would you gain system performance and robustness through cmake? And it seems to me that the “unified build for part of system/IDE sets” is a kind of a myth, especially for cross-compiling. You have to cmake code every peculiarity specific to an IDE (OS sometimes as well)

As for now, the time effort is unjustified too high to put into cmake everything. what has worked before in IDE/OS configurations… So why put a layer cmake over an IDE, if you have to reprogram, everything which has been always configured and set into an IDE? I cannot recognize the benefit of doing this?

4

I did migrate hand-written makefile-based build system which was unable to correctly build in parallel because many dependencies were missing. Moreover this legacy system was not very efficient because of makefile re-entrance usage.

After a move to cmake+ninja we get a fully parallel build (able to use up to 20 cores in CI) which always work unlike the previous build system.
In the end the parallel build was something like 10 times faster than before.
Moreover the move to CMake ease the usage of compiler cache (ccache) so that we gain even more
performance of the build in CI and among developers who can share the compiler cache.
The ccache usage bring an extra speed-up (I don’t remember the figures though).

My recent use case does not require cross-compiling, I did a couple of CMake projects that require it
and they were working as expected but those projects began with a CMake build system so we didn’t have anything to compare to. May be others have more experience than me in cross compiling can
give more valuable feedback.

Peculiarity of OS is probably already taken into account by your base code using compiler macro using CMake does not change much in that area.
Peculiarity of the IDE appears if you are used/target very specific IDE features, in that case CMake does not help because CMake cannot bring specifics of one IDE into another. At most he can unify the common features of the supported IDE.

If you don’t, don’t do It.
like I said I won’t try to convince you.
It would be a waste of time for you and probably for me too.

5

What was the part of cmake to make it parallel ?

How is this to be explained?

Although off-topic: I would wish an “export to cmake tool” for each main IDE.

I hoped for more constructive answer. I really want to find the answer to this question.

6

The fact that CMake generates either ninja build file and/or makefiles that are ready (and complete in terms of dependencies) for a parallel build with ninja or cmake.
Ninja appears to be the easiest one because it tries to use all available core if you don’t say nothing.

You have a single point of modification (the main CMakeLists.txt) of your project.

Forgive me if my answer appears to be not constructive.
I do really think what I wrote. You shouldn’t fight against your developers if they are happy with their current tool.

I mean if you have used say XCode for ages, the cost of the switch to CMake+XCode may be huge because CMake is not handling your code the XCode way you are used to.
From my personal experience, when you change the build tool (from whatever to maven, gradle, …) you need to adapt. The problem (and benefits) with IDE is the Integrated part. because you are used to a bundle: editor + code configuration + build tool + compiler.
Now with the switch to CMake you get a new kid in town you never had before: the build system generator. Before that the IDE was doing it all in a single (unified) interface after that you have to write code (in CMake script) to program for several IDE/OS/compiler.

The benefit you ?should? get is getting from a single set of files (CMakeLists.txt) various IDE files (XCode, VS, Eclipse, etc…) and various build system (ninja, unix makefile,…).

I.e. you gain more IDE support, unless you already have all what you need before, more build system support (like ninja) but again if this wasn’t a need you gain nothing.

My very personal opinion is: ask you the question what do you want to get from CMake that you didn’t have before, then verify that CMake can bring you that. If it can you win, if it cannot then this may not be the way to go.

The fact that CMake was gainful for my usage does not mean it has to be for yours.

2 Likes