----- 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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
