[CMake] CMake script vs. Lua

[Joshua Jensen]

----- Original Message -----
From: Brandon Van Every
Date: 12/14/2007 12:04 PM
> Certain CMake people want to *say* it was conclusive, so that the
> issue will go away, but it wasn't conclusive.  In particular, I have
> to note the self-selecting nature of the CMake community.  If you
> stick around and duke it out with CMake, there's a pretty good chance
> you don't think "completeness" in a build language is important.
> That's why I started asking around in other build system communities,
> to see what they think is important.  Nothing conclusive or
> enlightening to report so far.
>   
Brandon asked me a short while ago to post a response I had made to a 
thread on Sweng-Gamedev.  I don't post this to fan flames or to even 
form an opinion.  It is just my experience in the matter.

<quote>

Cavebug Games uses CMake as its primary build system.  The completely 
out of source builds allow us to have multiple, easily accessible, 
disparate builds of the game.  I admit, though, that I have struggled 
with CMake's scoping and lack of certain programming language features 
that a scripting language often easily provides.  I have also modified 
the CMake codebase to provide certain ease of use features.

I recently converted a huge codebase to Jam.  I love CMake, but when 
push came to shove, Jam's speed and more expressive language (such as 
the variable product expansion ability) won out.  The Jamfiles I wrote 
contain CMake-like constructs that let me build up a .sln/.vcproj setup 
for day-to-day development.  Jam's language has its fair share of 
issues, but IMHO, it deals with strings and lists, both important 
concepts in build systems, in a much nicer fashion than CMake.  I use a 
patched version of Jam made of patches posted to the Jam mailing list 
and Perforce Public Depot.

Now to the Lua part: Just like CMake, Jam has certain lacking language 
features, such as math support.  Lua does this and so much more.  I did 
a proof of concept integration of the LuaPlus library into Jam and even 
allowed direct access to Jam's variables from Lua (ah, the power of a 
nice scripting language) and Lua's variables from Jam (just a bit 
indirectly).  The Lua proof of concept implementation for CMake did not 
provide natural direct access to CMake's variables, though it easily 
could have.  Anyway, I didn't get too far (time constraints), but Lua 
script could be inserted directly into a Jam rule.  The plan was to fix 
up Jam's HDRSCAN so it could call Lua script under the hood where an 
egrep-style scanning expression wasn't appropriate.  Also in the plan 
was to allow Lua script in Jam actions.  But I digress.  There are 
things in Lua that are not as easy as Jam (or possibly, CMake) at, such 
as single-line mass changes to a list or the ease of use of leaving 
filenames unquoted.  Lua lets me use cool things like tables, which 
CMake/Jam doesn't have.

If you only have CMake or only have Jam, you stay within the confines of 
what is allowed.  If you have more power given to you (maybe OO), you 
have a grander toolkit to use to get the job done.

</quote>

Josh