[cmake-developers] CMake alternative language

[Eric Wing]

I am hesitant to add more fuel to the fire for this discussion because
it has been discussed many times before through the years and my sense
is that this isn’t what Brad is really interested in pursuing. I
encourage you search the mailing list history.

I’ll try to summarize (off the top of my head) about why Lua (as
opposed to other languages).

- Lua above all other languages was recommended by me and others
because it satisfied all the constraints:
	- It is tiny and can be included with the CMake source and doesn’t
impact the size of CMake in any significant way
	- Being 100% ANSI C allows it to go everywhere CMake already goes and
satisfies the requirement that only a C++ compiler is needed to
bootstrap it.
	- Lua is a language designed to be embedded, for this very kind of purpose.
	- Lua is sandboxed by default and has a minimal (and optional)
standard library.
		- This means users won’t be encouraged to call all sorts of
non-portable library calls like with some other languages. CMake can
control what APIs are exposed addressing those concerns that a full
programming language may allow too much variance and craziness in the
community.
	- Lua’s liberal license is compatible with CMake’s liberal license.

- Lua is one of the cleanest, simplest mainstream languages out there
and is incredibly easy to learn, yet still supporting a wide range of
higher-level constructs (functions as first class values, closures,
proper tail recursion). Documentation and tutorials are readily
available.
- Lua’s core data structure is the table, which is a extremely similar
to JSON (which it happens to also predate), which makes lists and
declarative data style very easy and natural to do.
- Lua has proven itself in the video game industry in that C/C++
developers are comfortable dealing with it (not a syntax shell shock
to them, say like LISP, or quite frankly CMake)
- Lua being a full, well designed programming language allows for ways
to write things which is currently really hard in CMake’s language.
Additionally, adding features to CMake’s language is hard in that you
have to think about all the potential side-effects, edge cases, and
inconsistencies. Lua takes this burden away and how to use everything
is well known/documented.

- To prove to us that CMake was already too far down the road and
retrofitting Lua into CMake was not practical, Dr. Ken Martin had a
CMake/Lua proof of concept working in like 13 hours. (Oops.)
	- But it was decided that Kitware didn’t want to go down this road.

- We attempted to build off Ken Martin’s experiment to keep it alive,
but that project essentially failed.
	- Lack of time, resources, expertise, etc, and this was back in the
CVS days so keeping up with the mainline was hell since merge tracking
is pretty much non-existent.
	- There was one interesting thing implemented showing that both
existing CMake script and Lua script could co-exist. And I think there
was even a proof a concept that different language scripts could call
one another.



So just on the constraints/requirements issue, I think we convinced
Brad, that *if* anything should be chosen, it should be Lua, which is
why Lua is still in his head. And these constraints are still in play.
I am constantly fighting dependency hell on platforms. It is nice that
CMake has no external dependencies except a C++ compiler and can
bootstrap itself. I recently did a bunch of work on a Raspberry Pi and
I needed to build CMake; no problem. I just tried to build Swift on
the Pi. I got hit by a bug where the build process pulls in the wrong
version of Python (2 vs 3) if both exist on the system. What a mess.
(And a 9+ hour build cycle to retry.) Not to mention the disk space
problem of needing all these dependencies.

But it sounds like Brad is more interesting in a purely declarative
replacement for CMake.
That would be nice for all the editor-assist reasons. Though I’m also
skeptical of pulling that off (though I hope it can be done in a
useful way). There are other systems like that, yet, I’m using CMake
for a reason. I don’t have any real insight on the problem, but I
recall hacking Ant XML files and just to have a simple conditional
(if/else) was a huge PITA. And as these things cascade with more
conditionals, it becomes a major effort. Antidotally, I watched
several projects try to use Gyp even though there was a CMake
description already written (albeit, not working for the platforms we
needed). I watched from the sidelines as those projects failed to get
Gyp working. I don’t have any insight in why unfortunately. For one
project though, I did later come in and did get the CMake description
working.

I try really hard to keep my CMake really simple. But unfortunately,
it always gets complicated. Just the fact that platforms and
environments are so different always impacts my CMake scripts. But I’m
very glad that CMake seems to get the job done. Lua would help me
avoid fighting the CMake language, and that would be very welcome. But
I don’t expect the messiness to ever truly go away…that is the
byproduct of systems/environments being so different and ever
changing.