3 ms·
> 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 pro
by umvi 7y ago
> 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.?
add_library(foo SHARED
foo.cpp
bar.cpp
)
vs.
import cmake
cmake.add_library(name="foo", shared=True, sources=[
"foo.cpp",
"bar.cpp",
])
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.
- MaxBarraclough 7y ago> 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. [0] http://wiki.flightgear.org/Nasal_scripting_language http://wiki.flightgear.org/Nasal_scripting_language