Dear CMake devs/users,
I wanted to ask your opinion on something that has been troubling me since…
well, ever since I started using CMake. I have not found a single person alive
who would have said:
“The script language of CMake is nice, intuitive and productive. Authoring
scripts is easy, and writing custom macros is not difficult either.”
There are gazillions of scripting languages one could have chosen for CMake
(Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to
reuse existing skills, or learn one that is useful elsewhere, not just in terms
of CMake. These languages have a lot of thought put into them. They are
superior to CMake’s own in just about every regard.
I came up with an idea presented here: http://1drv.ms/1MsufbF
Enhancements such a change could bring about:
The big selling point would be the ability to introduce arbitrary front-ends to
CMake, not just CMakelists.txt. Every developer could choose an input language
that suits their project/needs/skills.
(It would also ease the custom implementations of cmake.exe itself in any
language, but that is just a side-effect.)
It would modularize the internals of CMake in a cleaner fashion
Facilitate the introduction of new languages understood by CMake (such as work
put into C# and Swift currently)
Would allow for configure-time validating of compiler-specific options
Use deferred makefile generation by default (making the implementation of tools
like Cotire for precompiled headers trivial to implement, as well NMake batch
mode, or detecting multiple/cyclic linkage, by making use of global information
about the build process)
Many features could automatically be reused by all generators. (Imagine Swift,
and Fortran libraries being compiled as NuGet packages and publishing them
without any hassle on user side, or having to implement anything in the XCode
generator.)
SIGNIFICANTLY increase interoperability with other tools. Implementing GUI
front-ends (such as in CLion, or Visual Studio (work in progress)) are orders
of magnitude simpler by generating a stateless IR, as opposed to generating a
stateful script.
While it is a refactor of the entire toolchain, it is something that could be
done incrementally, with the existing parts functioning normally.
I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake
users I’ve met say they are “happy” CMake users. The learning curve is steep,
and the skills gained are not reusable. CMake could gain even greater momentum
(not by ditching, but) by offering alternate input languages with entities
(classes, functions, macros, etc.) that feel natural in the given context.
Initial feedback in my vicinity was favorable, even those with zealous CMake
opposition aggreed this were something awesome to pull off (though they
expressed their disbelief in Kitware and the community approving such a radical
change). This mail along with the document only intends to get the ball rolling
and hopefully manifest in something similar, starting with CMake 4.0 perhaps.
Eagerly await the rolling ball.
With all due respect,
Máté
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
