[CMake] CMake IR

Matt McCormick matt.mccormick at kitware.com
Wed Jul 29 08:58:18 EDT 2015


Hi Máté,

There is some on-going work along the lines of separating out state.
See this thread for more information:

  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658

You may want to have further discussions on the cmake-developers list.

Cheers,
Matt

On Wed, Jul 29, 2015 at 3:49 AM, Nagy-Egri Máté Ferenc <cmake at cmake.org> wrote:
> 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


More information about the CMake mailing list