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@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 -- 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
