[CMake] CMake and Lua

[Brandon Van Every]

On Sun, Mar 2, 2008 at 9:10 AM, James Mansion
<james at mansionfamily.plus.com> wrote:
>  >
>  > Well, I suppose you don't have to use CMake.  Perhaps scons would be a
>  > better fit for your tastes.
>  >
>  In a Python-based system, yes.
>
>  But if I have a C++ code and a variety of value added components aimed
>  at different users, then I can hardly tell Java customers to use Scons,
>  any more than I could reasonably ask Python customers to use ant.

I don't agree with you in the case of Java.  JRake is based on JRuby
and is used to build Java apps.  I'm not quite sure I understand the
build problems of the Java universe.  They are certainly not the same
as the C/C++ universe, as the behavior of Java implementations is far
more unified.  I have read that Ant suffers from a lack of
scriptability.  It was written in an era where everyone thought XML
was God, and it turns out in practice that people need more
traditional scripted control constructs.  I think they currently have
some ugly way of hacking it into Ant.  Meanwhile, JRake is fulfilling
an open niche with a better design.  I think it makes a difference
that Ruby is perceived as a "better" language than Java.  CMake script
would be perceived as a "worse" language.  Actually from a language
sales standpoint it would be more strategic to move CMake to Ruby
rather than Lua.  The liabilities of Ruby are that it's the slowest of
the popular scripting languages, it's not reputed to be particularly
easy to embed, and it's Artistic Licensed.  Lua on the other hand is
the fastest of the popular scripting languages, is designed to be easy
to embed, and is MIT licensed.

>  >  Wow, now I need CMake, Ruby, Python,  and Tcl just to build this set
>  > of software.  This is just the type of thing CMake was designed to avoid.
>
>  Then probably that is because those projects use Ruby AND Python AND Tcl
>  - so I have to have them anyway.  Hey, lets all use C89.  Everyone has
>  that, right?

What if it is just C/C++ code?  And the open source author likes
Python better than Lua?  So he does his build in Python, and now I
have to have a Python interpreter just to build his C/C++ code.
Either CMake bloats with an interpreter for every scripting language
out there, or the user has to install Python for not much of a good
purpose.  I think the ease of the end user is more important than the
ease of the developer in this case.

>  I like CMake.  But the language is impenetrable,

I've penetrated CMake script.  The documentation is what needs a
clearer path.  BTW I've bought the current edition of "Mastering
CMake" and have yet to read it.  I don't really need it because I
learned everything the hacker way, through trial and error.  Again,
I'd really love your comments at http://cmake.org/Bug/view.php?id=6295
"Document core syntax in a chapter format."

> verbose,

if(clause) else(clause) endif(clause) is verbose, I'll grant you that,
but Bill just solved that problem to everyone's satisfaction 1 day
ago.  I don't think the KEYWORD arg arg paradigm is verbose, I think
it's descriptive.  It's like having a lot of method calls chained
together in 1 interface rather than typing object-->keyword(arg) all
the time, as one would in an object oriented language.  Perhaps you
don't like foreach(blah) endforeach(blah).  I'll grant you that's
verbose; I suppose it could be relaxed also, if it hasn't been already
by Bill's patch.  Any other items of particular verbosity you're
referring to?

>  and basically
>  poor - it can't quite decide whether to declaratve/functional or
>  imperative,

Even OCaml doesn't have functional purity as a goal.  Viewing the
available CMake script commands as an API, I haven't had an actual,
real world problem with how that API is laid out.  I think because it
has been iteratively refined under years of actual use.

> has limited data type or structure support

I agree that some type safety would be nice.  Especially for lists and
semicolons.

> - or modularity or reuse support.

Well, CMake 2.6.0 does have functions and scope.  What more is needed?

>  It has the appearence of something that had modest
>  objectives to start with and has evolved.  That's quite natural, but
>  eventually you have to say 'Enough!'.

I dunno, I'm still waiting to hear what a Python, Ruby, or Lua based
build system can do that CMake can't.  People perceive that they can
do more, or should be able to do more, but I haven't seen it
demonstrated.  It may be out there, and I'm open to being shown, but I
haven't seen it.  I'm hoping someone will demonstrate it, to push
Kitware towards a decision on Lua.  But if a language is a language is
a language, then it seems reasonable to continue polishing CMake
script.

>  I like CMake for what it does, but not the way it does it.  If you are
>  saying that compatibility with the naivety of the past when the macro
>  language was being used for less ambitious things then fine.  But don't
>  expect that to stop us thinking that a) the language design sucks and b)
>  of all the alternatives, Lua would seem to be the best fit in terms of
>  its own dependencies and the cleanliness of the language itself.

Careful, you may get what you wish for!  I've advocated Lua primarily
for marketing and documentation reasons.  I know, as you do, that lots
of people look at CMake script and say, "this sucks."  One research
item I haven't undertaken, is how many people say Lua sucks?  Are
there things about Lua that drive some users batty enough to jump ship
for something else?  Is Lua wart-free?  Do programmers just like to
complain endlessly no matter what the language?  Are technical
solutions the answer to that problem, or is marketing and
documentation a better answer?  I think these are questions of degree.
 I think any of the mainstream scripting languages will be more
accepted than CMake script.  I caution, however, that if we build it
and expect people to come, these sorts of issues may not go away.
They may have to be handled by marketing and political means.  That's
an avenue that the CMake community has put very little effort into.
I'm not going to point fingers, as I precipitated the cmake-promote
mailing list once upon a time and have done very little since then.
Too busy coding like most programmers are.  I'm just trying to make a
pitch for humanistic rather than technical solutions to some of these
problems.  Techies tend to overlook anything that isn't tech.


Cheers,
Brandon Van Every