Disagree. If you design your framework with language-portability in mind, you're going to have to trade off on a lot of other things you care about. You'll have to go with lowest-common-denominator design-decisions, rather than making a language with its own idioms.
LLVM itself, for instance, is a C++ API which also exposes a C API. People generally favour the C++ API. Idiomatic C++ is nicer to work with.
There's plenty wrong with CMake, but the lack of Python bindings isn't the problem. CMake's scripting language is clunky and error-prone, with documentation that is very complete, but surprisingly unhelpful for doing real work. That's the problem. The lack of choice isn't.
CMake gets all the hard stuff right. I really don't think it would be that hard to overhaul its usability, but I doubt it will happen.
> CMake's scripting language is clunky and error-prone, with documentation that is very complete, but surprisingly unhelpful for doing real work. That's the problem.
And wouldn't one solution be to use an alternate front-end with less clunky and error-prone syntax (say, python) that has doc strings so you can hover over an API in your IDE and read what it does, get auto-complete, etc.?
People know how to do stuff in python. Stuff like loops and if statements and string operations. Nobody knows how to do that in CMake. The benefits of allowing arbitrary language bindings are immense.
> And wouldn't one solution be to use an alternate front-end with less clunky and error-prone syntax (say, python) that has doc strings so you can hover over an API in your IDE and read what it does, get auto-complete, etc.?
You're right of course that there are great advantages to using existing languages with familiar syntax and good existing tools. I agree that CMake should have gone with an existing language rather than inventing a bad one of their own. Same applies more generally to projects that roll their own language for no clear reason, such as FlightGear. [0]
For me the question is how much work it would be. If they could introduce a decent Python frontend, in addition to supporting their existing language, I agree it could improve things greatly.
> The benefits of allowing arbitrary language bindings are immense.
Arbitrary languages? If that's the end-goal, presumably they'd really just be exposing a C API (the way LLVM does), or a machine-friendly text interface (LLVM supports this approach too with its own assembly language). I don't think that would be the way to go, but I can see the case for supporting one language well. Python3 would be a fine choice.
LLVM itself, for instance, is a C++ API which also exposes a C API. People generally favour the C++ API. Idiomatic C++ is nicer to work with.
There's plenty wrong with CMake, but the lack of Python bindings isn't the problem. CMake's scripting language is clunky and error-prone, with documentation that is very complete, but surprisingly unhelpful for doing real work. That's the problem. The lack of choice isn't.
CMake gets all the hard stuff right. I really don't think it would be that hard to overhaul its usability, but I doubt it will happen.