How to frame the concept behind CMake?

Question

I'm using CMake for several years now and found that - in the cases where I'm struggling with CMake - I'm still not completely sure about the concept behind CMake (not taking into account CTest, CPack or CDash also shipped with CMake).

When I started I came across Bill Hoffman's presentation on Google Tech Talks and one claim there has stick to my mind:

CMake aims to give C++ compile portability like the compile once and run everywhere of Java, Python and C#

Starting from there and the basic concepts of CMake page, I came to thinking about CMake in terms of the following three major high-level programming concepts:

1. CMake is an abstraction layer for the build and operating systems it's supporting
2. CMake is a high level programming language for build procedure descriptions
3. CMake assists you in cross-platform development by making code parts configurable

I'm fully aware of the complexity of CMake's task, but I hope you can help me nonetheless with:

• As being an abstraction layer it can't/shouldn't expose all functionality of the underlying layer. So why are there so many holes to explore in CMake?
  • Especially commands from the beginning do have bypasses. E.g. add_definitions(): "This command can be used to add any flags, but it is intended to add pre-processor definitions"
  • I see CMake going in the right direction with e.g. target_compile_features() for abstracting compiler flags
• For the cases where I really need a bypass (something I can only accomplish in the native language) why does CMake not provide some generic way of "inline native code" as other high level programming languages do?
  • E.g. like the asm macro/command in C++
• Is it OK in CMake to add another layer of abstraction to CMake itself (to hide the complexity of CMake to the users of my build environments)?
  • I think yes. And since I understand it's a high level programming language, why not?

Thanks in advance for your insights and help with this.

Answer 1

Disclaimer: My experience with CMake is extremely limited, so I could easily be mistaken in some of the following.

As I understand it, CMake is a simply a build system. In particular, it aims to be a build system for cross-platform projects, usable across multiple OSes and compilers.

For solid technical reasons, the CMake developers chose to implement their build system as a layer on top of platform-specific build systems (Visual Studio project files, makefiles, etc.), but this may help explain why presenting a leak-proof abstraction layer is not its primary design goal.

The Architecture of Open Source Applications has a chapter on CMake. It may provide some more insights. For example, they discuss the design of CMake's language:

The CMake language is meant to be very simple. However, it is one of the major obstacles to adoption when a new project is considering CMake. Given its organic growth, the CMake language does have a few quirks. The first parser for the language was not even lex/yacc based but rather just a simple string parser. Given the chance to do the language over, we would have spent some time looking for a nice embedded language that already existed. Lua is the best fit that might have worked. It is very small and clean. Even if an external language like Lua was not used, I would have given more consideration to the existing language from the start.