I learned recently, that CMake was builtin with simplicity in mind, so it doesn't use any sophisticated grammar parsing tools like Bison. Basically, it just evaluates commands.

CMake does not have has builtin containers like lists, dictionaries, maps and so on. For example, the List container is not really a builtin and just based up on the existing set of commands like set which sets a single string value not multiple. Plus multiple issues, like around ;-character discarding and escaping, and so on.

For example:

;-escape list implicit unescaping : https://gitlab.kitware.com/cmake/cmake/issues/18946
string escape sequence depends on macro call nesting level : "\\\${a}" -> "\\\\\\\${a}" -> "\\\\\\\\\\\\\\\${a}" : https://gitlab.kitware.com/cmake/cmake/issues/19281
Not paired ] or [ characters breaks "file(STRINGS" : https://gitlab.kitware.com/cmake/cmake/issues/19156

These issues just a minor example of how is hard to build a simple parser on the cmake language. So they just decided to push out the not minimizable complexity out of the language which brought another complexity in. This rather bad than good.

Or another example with incompleteness, when 3dparty libraries trying to change shared variables like CMAKE_BUILD_TYPE and breaks the entire build:

Or no ability to check whether a library or component support the multiconfig (CMAKE_BUILD_TYPE must not be used) or single config (CMAKE_BUILD_TYPE must be used), because cmake projects with the multiconfig must call only to projects with the multiconfig.

Or system functions hooking is another way of incompleteness in cmake.

I've built my own library up on that and know that I am talking about: https://github.com/andry81/tacklelib/tree/HEAD/cmake/tacklelib/

Project dead? #136

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions