I have read “Professional CMake” by Craig Scott. This is short review. This time the review is, indeed, going to be short, because I cannot really say that the book was a paradigm-changing read. Nevertheless, I have decided to make reviews on most books I read, and this one is not an exception.
The necessity to learn cmake came to me when I changed my language of work from some other popular engineering language, to C++. At the new work place, the project build system was not perfectly organized, and I volunteered to update it to modern cmake.
Naturally, I searched for some homework reading about cmake, and although official documentation existed, I still wanted something more narrative. (Indeed, this happened to be a fairly standard approach of mine, to learning new areas.)
Craig Scott’s book is quite famous, easily google-able, and has positive reviews. Why not, I thought.
The book structure
The book can be roughly partitioned into three parts.
The first part gives the reader an general overview of the tool, describes several most common usage patterns, provides a short historical notice.
The second part describes the main area of cmake’s expertise – building projects, that is assembling a pile of C++ (mostly C++, although other C-related languages are supported), into a working system.
The third part, on top of the second one, provides an overview of things that cmake can do, but which are less known. For example, cmake has a built-in tool for testing, CTest, and a tightly related testing results dashboard, CDash.
At the first glance it may seem that the book is merely restating facts from the official documentation. Unfortunately, that is true to a large extent.
Obviously, it is hardly possible to make a technical book about a certain artefact (a piece of software), entirely without referring to the official documentation, but I feel that “Professional CMake” is overdoing it.
Compared to, say, “Autotools: a Practitioner’s Guide”, the amount of excerpts from the official documentation is much larger.
However, this is not what we are usually reading technical books for. We are reading them to get a working intuition – “how to use what you know and find out what you do not know”.
On the other hand, obviously realising this necessity, Professional Cmake is equipped with “Recommended Practices” sections at the end of each chapter. Those are purely opinionated, and are, supposedly, aimed at that intuition development.
The author obviously likes cmake. He praises its policy system, which allows compatibility feature tweaking, and the ease of adding functions to the code base, partly to its good readability.
I, however, am much more a supporter of the idea that a good language is not made by piling a feature on top of a feature. Obviously, any build system cannot be done without certain idiosyncratic components, catering to particular systems, and dirty hacks. And in my opinion cmake overdoes it. Perhaps, not as much as GNU Automake does, but the effort spent on writing heuristics could have been spend rather on improving the cmake language itself.
Yes, you haven’t misread it – cmake is, first and foremost, a programming language. Yet another language introduced into the C/C++ ecosystem.
Do we need another language in the toolbox? Okay, it may be said that POSIX Shell, and especially how it is used in Autotools is a horrible language. However, cmake’s own language is also far from being robust and semantically consistent. Even having lists delimited by semicolons is a queer idea.
But what is more of that – and what is perhaps, the biggest drawback of the book, the author does not seem to realise those drawbacks, and speaks very little of them. A huge miss for someone trying to create a professional book!
To me personally the most disappointing was the fact that, seemingly, the author does not really understand not just how macros are different from functions, but what they even exist for.
“Professional CMake” does the job. If you need a not-so-quick introduction into cmake, which would be more in-depth than a randomly googled howto, but less heavyweight than crunching the original documentation, read it. It is not a bad choice. You are also less likely to write “old, hard to maintain”-style cmake code if you follow the book’s tutorials.
Just do not expect that this book will make you a CMake expert, or even warn you about the actually hard cmake trickery.
Subscribe and donate if you find anything in this blog and/or other pages useful. Repost, share and discuss, feedback helps me become better.
I also have: