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
Post by Brad Kingit 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
Post by Brad Kingrepresentation 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
Post by Brad King* 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
Post by Brad Kingthe 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.
Post by Brad KingPost by Taylor HolbertonI'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.
Post by Taylor Holbertonthat 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
* 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