[CMake] CMake IR

[Nicolas Desprès]

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*
> <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 <https://github.com/sakra/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150729/5d4a2865/attachment.html>