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.

1 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.

  • Thanks. That's a very interesting link - I didn't know of - with many insights on "why did we do" this or that in CMake. I still have to do all the reading, but - even if I understand that it may not have been their primary goal - some statements there still point into the abstraction direction: e.g. "In effect, software using CMake is outsourcing the build complications to the CMake team." And I come to think that with a fast growing open source project the goals - and concepts? - may also grow in various directions.
    – Florian
    Oct 15, 2015 at 19:59
  • @Florian - I'm sure that abstracting differences is part of the goal. I'm not sure it's a primary goal, but I could be overstating my case. And I'm sure you're right about goals and concepts changing - there's a good chance this can happen with any 15-year old project, whether open or closed. Oct 15, 2015 at 21:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.