[cmake-developers] Alternative CMake Syntax
brad.king at kitware.com
Thu Jul 5 11:07:26 EDT 2018
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.
More information about the cmake-developers