[CMake] [cmake-developers] CMake IR

[Eric Wing]

Disclaimer: My name is attached to the failed CMake/Lua attempt.

In principle, I like the idea of what you propose. However, in
practice, I think it might be too big and too ambitious.

Here are some quick thoughts I have:

- I am in the camp that I do not like the CMake language. And it is
often the hardest selling point in my experience, even when you
convince them that CMake can do all the cross-platform stuff. (I’m
seeing more competition from Gyp these days, but in my limited
personal experience, people still have not been able to port highly
complex projects to as many target platforms with Gyp, whereas CMake
could handle them (and the perceived gains of Gyp disappeared in these
complex scenarios)).

	- Along those lines, part of the problem we seemed to hit was that
pure declarative build instructions didn’t hold up well in the complex
case. I haven’t done much with Gyp in this manner, but those around me
that were trying seemed to hit the wall pretty fast in this. But I
have used Ant, and that was a terrible experience for anything that
required conditionals.


- I would definitely like to see better interoperability with IDEs and
tools. I would personally love a simple cross-platform gui project
manager that basically allowed you to create targets, add/remove files
to be compiled to a target, and set specific compile/link flags on a
per-target or per-file basis, sort of like you can do in most IDEs
(but if you tried using CMake, your changes get clobbered in the next
regeneration…though even better would be able to do this directly in
the native IDEs).

- I am little concerned about encouraging people to add on any
arbitrary language. There are two different problems that this could
potentially cause: (1) CMake bloat, (2) Dependency hell

	- CMake currently can bootstrap itself with just a C++ compiler. That
is a good thing. I recently had to get CMake up on a Raspberry Pi. I
was fortunate that CMake had few dependencies and was relatively
small. (Not counting Qt which was an unmitigated disaster.)

	- Building other projects using CMake can be painful depending on
their dependency chain. While this is not technically CMake’s
responsibility, encouraging users to use non-canonical tools can make
things a nightmare. CMake has been pretty good about providing
fundamental mechanisms you need that work on all platforms. But if
users are encouraged to say, “I’ll just use Perl+CPAN or Ruby with
these gems”, instead of the standard CMake mechanisms, things get
awful quickly. (I finally just reproduced a build of JavaScriptCore
for Windows after over a year of trying…it has dependencies on Perl,
Python, Ruby, and a bunch of other things I can’t remember, all of
which are a terrible pain to get working on Windows.)

- In that same line of thought, the reason Lua was a good candidate is
because it its tiny which avoids adding bloat, it is pure ANSI C,
which means it compiles everywhere CMake already compiles, and it was
designed to be an embedded scripting language doing the exact type of
things that the current CMake language is asked to do. (Dr. Ken Martin
said they were impressed with Lua and would have used it if they had
known about it originally.)

(By the way, if you haven,t already, I encourage you to read through
the old Lua threads circa 2008.)

	- Incidentally, the Lua table is pretty much the same
concept/pre-cursor to JSON in JavaScript. Lua lends it self to both
data driven formats as well as custom DSLs pretty well. If Lua were
part of the core, you could build a  the data-oriented format files
without any additional dependencies.


- I don’t think the IR will help anything related to the work of
adding new languages like Swift. The hard part there is not really the
CMake language as much as understanding the overall system
design/architecture. No matter what language you pick, that part will
always be hard.


- Mostly, I’m concerned that this project is too big and ambitious in
scope to see completion unless you have funding and a team to drive
it. The Lua attempt is a failure, but not for technical reasons. It
was a manpower problem. Dr. Ken Martin proved the concept could work
in something like 13 hours. But at the time Kitware said they weren’t
going to go down that road, so anybody still interested in it was left
to make it happen ourselves. We gave it a shot, but none of us really
had the time to commit to finish the task, which is much smaller than
the one you are proposing. (Granted, we wasted a lot of time trying to
bridge CVS (which CMake was still using at the time) with DVCS, so you
at least won’t have to worry about constant merge-hell.)


-Eric