search

toeb / cmakepp

An Enhancement Suite for the CMake Build System
Other
432 stars 37 forks source link

Project dead? #136

Open hinell opened 1 year ago

hinell commented 1 year ago

Anyone?

Tonnes of efforts were put into this project. Wouldn't it be much better to implement a frontend to the cmake and create better scripting language like meson, but which is much faster?

toeb commented 1 year ago

You could say the project is dead - I wrote this as a student and haven’t used cmake a lot since working. I am sorry for not supporting it more. Personally I think there should be a standard build system for c++ and like it or not it has been cmake . But due to cmake being very lacking partially I developed this project . The idea for me was that cmake is a root dependency you could use a vanilla machine to install everything you need , from compiler of any language to 3rd party packages for compilation. Everything could bootstrap itself and this project supported some of these ideas. Anyway no more rants from me - and use this project if you find it useful:)

hinell commented 1 year ago

I am sorry for not supporting it more

Nothing to be sorry about. You made a great job we all appreciate. If it's ever used in any commercial project you should get rewarded.

Personally I think there should be a standard build system for c++

Same here. I think CMake scripting isn't perfect, but that's what we have. I think in future it would be best if it's split into a frontend and a backend so front-end scripting language can be easily switched and upgraded.

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.

If you are interested in how cmake works, see this link: https://aosabook.org/en/v1/cmake.html#footnote-1

hinell commented 1 year ago

Btw. If you don't maintain this project often, you can make a notices at the top of REDME.md so users will quickly get idead whether to use it or not. Thanks!

andry81 commented 1 year ago

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:

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/

hinell commented 1 year ago

@andry81 I wasn't talking about creating a parser by using CMake language. I was talking about implementation of a "parser" written in C++ that cmake uses to parse its CMakeListst.txt. Cmake doesn't use parser-generators cause it was striving for simplicity since day 0 of its creation. That's the reason its language is so primitive by modern standards.