[CMake] CMake IR

Wed Jul 29 09:11:48 EDT 2015

Hi Matt,

I also posted this idea to the dev list at the same time, but it’s awaiting moderation due to the inserted links.

The project you reference is very similar indeed. It facilitates the consuming of CMake for IDEs, but it does not help in integrating it. Unaffecting the internals of CMake (which end-users don’t really care about anyway) is both good and bad at the same time. IDEs consuming this stateless representation of a build help them being a back-end on their own right, but does not help interacting with the build. Introducing a new source file in the IDE still could only be done by altering the script files (by the IDE or the user).

This kind of integration is what CLion is doing, but I’m not sure I would be happy with the kind of features they present here, namely that the IDE ‘plays along’ with someone who comments out critical parts of the generated script. The IDE should have a chance at interacting with CMake at a lower level, that is CMake understanding it’s own generated stuff you mentioned. But if it would understand it, why not use it internally?

Feladó: Matt McCormick
Elküldve: ‎szerda‎, ‎2015‎. ‎július‎ ‎29‎. ‎14‎:‎58
Címzett: Nagy-Egri Máté Ferenc
Másolat: cmake at cmake.org

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