[cmake-developers] CMake IR

[Nagy-Egri Máté Ferenc]

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é
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150729/ed65552c/attachment.html>