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
