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