Brad, Thanks for your response. I've taken a little bit of time to consider your thoughts and here is what I think.
Fair warning: Upstream is not outright opposed to a new language but > it will take a lot to make something like that upstreamable, assuming > we even find time to consider it in depth. > That's perfectly okay. I'm willing to do the work and I've started a folder in my repository for compatibility testing. The tests I've written so far test the interpreter that I've written to match the expected output you'd get with CMake running in script mode. I'm going to be thorough in the compatibility tests in order to make this process easier. A major obstacle to replacing the language is separating the code model > representation from the current language. Some work has been done to > factor it out into a representation that can be used by the generators > that is not tied to the implementation of the current language, but more > work is needed and the original contributor working on that is no longer > active. Search back through the dev list archives for posts by Stephen > Kelly talking about where his work left off. > I'll revisit this when I begin trying to integrate the library I've written with the main CMake project. Hopefully I can pick up where he left off! Currently, it's pretty trivial to add new functions using C++ code. I'm hoping as long as it stays that way, it should be pretty easy to use generator specific functions. If a new input language were to be introduced it should fix some of the > fundamental problems with the current approach. These include: > > * Each directory and its included files must be processed serially > due to the imperative language with side-effects. This means we > can never make the implementation parallel. > > * The imperative form of the language also means that IDEs cannot > easily edit the build specification through GUI actions. If at > least things like a list of sources were doable in a declarative > way that could help. > I agree that the affects of massive amounts of included code can be quite noticeable but I think there's other ways to fix this than to make the language declarative. When thinking about alternative approaches before I've considered > the idea of having most of the build spec be declarative/functional > (no side effects) and then having an imperative part that computes > parameters to evaluate conditions and expressions within the main > spec. The main spec could then be updated by IDEs in a structured > way, evaluated in parallel, etc. while the imperative part could > handle system introspection, configure-time file generation, etc. > Having a purely functional syntax would certainly be much easier to execute in parallel, but I think that change would be too drastic to be a net benefit. I wanted to make the syntax easier for system introspection as well, since that's where it is most complicated. The changes I have in mind are more for existing CMake code, such as whether "()" really need to come after an "endif" keyword. I'm going to make a more thorough survey of the CMake code and draw examples when I write the new specification. The end goal is to make very readable and easily maintainable CMake code, while staying focused as a build system generating language. The library could have facilities to make it easier for graphical front ends to work with. For though, though, my main focus is improving the syntax. On Thu, Jul 5, 2018 at 8:07 AM Brad King <brad.k...@kitware.com> wrote: > On 07/04/2018 01:08 PM, Taylor Holberton wrote: > > I've been thinking about designing a new syntax for CMake > > Fair warning: Upstream is not outright opposed to a new language but > it will take a lot to make something like that upstreamable, assuming > we even find time to consider it in depth. > > > that better expresses some of the functionality that I've seen in > > modern CMake code. I've started a CMake parsing library and plan > > on using it to design the new syntax while maintaining support for > > the traditional syntax as well. > > A major obstacle to replacing the language is separating the code model > representation from the current language. Some work has been done to > factor it out into a representation that can be used by the generators > that is not tied to the implementation of the current language, but more > work is needed and the original contributor working on that is no longer > active. Search back through the dev list archives for posts by Stephen > Kelly talking about where his work left off. > > If a new input language were to be introduced it should fix some of the > fundamental problems with the current approach. These include: > > * Each directory and its included files must be processed serially > due to the imperative language with side-effects. This means we > can never make the implementation parallel. > > * The imperative form of the language also means that IDEs cannot > easily edit the build specification through GUI actions. If at > least things like a list of sources were doable in a declarative > way that could help. > > When thinking about alternative approaches before I've considered > the idea of having most of the build spec be declarative/functional > (no side effects) and then having an imperative part that computes > parameters to evaluate conditions and expressions within the main > spec. The main spec could then be updated by IDEs in a structured > way, evaluated in parallel, etc. while the imperative part could > handle system introspection, configure-time file generation, etc. > > -Brad >
-- 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: https://cmake.org/mailman/listinfo/cmake-developers
