[CMake] CMake IR

[David Cole]

And I wouldn't give up just yet on building support for this into
CMake, if not building the entire thing into a future CMake. Perhaps
there are valid objections, or perhaps people just need convincing.

D


On Wed, Jul 29, 2015 at 8:51 AM, Nagy-Egri Máté Ferenc <cmake at cmake.org> wrote:
> Hi Nico,
>
> thank you for the idea. That idea occured to me too, trying to generate the
> CMakelists.txt script from the desired front-end. Having taken a deep dive
> into XML schemas, hardcore people even criticise W3C XML Schemas for not
> having a mathematical foundation which make it difficult to reason about
> backward compatibility of change to the schema. Using the CMake script, a
> stateful, imperative script language as an intermediate introduces even more
> threats, than using a not so well defined, but at least stateless
> datastructure like XML.
>
> Seeing that people want this idea as a seperate project more than a part of
> CMake, I thought of:
>
> defining the XML Schema of building a C++ application
> defining the XML Schema of a particluar compiler toolchain
> write a front-end in a script language of choice
> write a generator for a back-end of choice
> provide a prototype of a CMakelists.txt >> XML front-end as a
> proof-of-concept
>
>
> That way CMakelists.txt files could be used in a completeley alternate
> toolchain.
>
> Feladó: Nicolas Desprès
> Elküldve: ‎szerda‎, ‎2015‎. ‎július‎ ‎29‎. ‎13‎:‎43
> Címzett: Nagy-Egri Máté Ferenc
> Másolat: cmake at cmake.org
>
> Hi Máté,
>
> One way of doing would be to write a tool using whatever language you like,
> reading an input script written in whatever language you like, that
> generates cmake code. In such case, the modification to cmake would be
> smaller but not that simple.
>
> You can see this thread from the archive for further details:
> http://www.cmake.org/pipermail/cmake-developers/2014-May/010450.html
>
> Cheers,
> Nico
>
>
> On Wed, Jul 29, 2015 at 9: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
>
>
>
>
> --
> Nicolas Desprès
>
> --
>
> 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