[CMake-Promote] Language barrier

[Brad King]

E. Wing wrote:
> I think the biggest barrier to adoption of CMake is the language. (And
> I struggle with the language myself at times.)

There is a long history behind the state of the current CMake language. 
  The short version of the story is that it was not originally intended 
to be an imperative programming language at all.  It was originally 
meant to be a configuration file format to build a specific project. 
Over time its use was broadened to other projects and the language was 
developed and transformed as needed but had to mostly remain backwards 
compatible.  No one ever sat down to design a programming language.  The 
closest thing to that was when we wrote a real lexer and recursive 
descent parser to solve the parsing prolem and allow multi-line strings.

> It seems that if you had a language that people were familiar with,
> the language argument would go away and CMake would be solely judged
> by its project generation capabilities (where CMake excels).

In the earliest days of CMake when it was still integrated in another 
project other developers suggested using Tcl or Python as the language. 
  Since at the time it was a configuration file format with a 50 line 
parser implementation the idea of bringing in a whole language seemed 
like overkill.  We also didn't want to become dependent on the other 
language's maintainers to support all our platforms and maintain the 
language over time.

> I know this is a non-trivial task, but have you considered adopting a
> secondary language that people can write project descriptions in? For
> example, if you could write CMake descriptions in Python instead of
> the current language, most of the SCons vs CMake discussion would die
> immediately.

I have thought about this idea many times since the use of CMake has 
broadened.  No matter what language we pick there will always be people 
who don't like that choice, but having a more general purpose language 
would be useful.  Lua seems to have a compatible license at first glance.

Another approach would be to follow Kitware's namesake (note "Kit") and 
turn CMake into a build-system generation toolkit (CMTK is taken but 
CMakeTk is not).  We could define a set of objects storing all the 
information needed to generate a build system and define an API to 
construct them.  Another part of the API would control creation and 
execution of generators.  It could even provide callback to support to 
allow customized generation.

Then the API could be wrapped into any number of languages, much like 
Kitware's VTK (www.vtk.org).  The current CMake language itself could be 
one of those languages for backward compatibility and people who like 
it.  The wrapping process could be made part of the client project's 
build so that each project could choose the language in which it wants 
to configure the build system without needing to distribute support for 
all languages with CMake.

We would have to be extremely careful about how the wrapped API would 
communicate with the CMake binary.  It would probably have to run in a 
separate process and use pipes to communicate.  Otherwise all client 
machines would have to be able to compile binaries that are 
dynamic-link-compatible with the CMake binary, which has been a real 
pain for the now little-used loaded command support.  Once pipes are 
used then the client language might be able to communicate with CMake 
without even having a C compiler, as long as the language supports pipes.

-Brad