Re: CMake and Lua

["Brandon Van Every" <bvanevery@...>]

On Thu, Feb 14, 2008 at 4:11 PM, Eric Tetz <erictetz@gmail.com> wrote:
> On Thu, Feb 14, 2008 at 12:33 PM, Brandon Van Every <bvanevery@gmail.com>
> wrote:
> > We did all have it out recently that some kind of scoping
> > is required, that having everything as a global variable is
>  > not enough anymore.  That's in CMake CVS and people are
> > shaking the bugs out of it.  CMake 2.6 will have function
> > calls with scope available, so that you don't have to use
> > plain macros if you don't want to.  Kitware's attitude is
>  > that they will continue to improve the language as needed.
>
> I think that, in a nut shell, is why tool developers should think long and
> hard before rolling their own languages. CMake is a build tool, why are they
> wasting cycles on language design? Lua (and plenty of other languages) have
> spent years working through these same issues, why duplicate that effort?

You're asking a historical question.  Bill said that when CMake first
started, they had abundant TCL experience and knew they didn't want
that.  I think history has vindicated their decision to blow off TCL,
it has not proven to be that popular as time has gone on.  Ken said
that they didn't know about Lua.  So the question is what benefit is
Lua *now*, not then.  They're working with an extant codebase, they
know how to do things in that codebase, the project team hasn't
changed all that much.  Why would they inherently want to rewrite it
in Lua?  They wouldn't, not unless Lua has a clear programming
paradigm benefit.  And as I've said, that argument hasn't been made.

I do find 1 thing genuinely un-likeable about Lua syntax with respect
to build systems.  Strings would require quotes.  That's a big waste
of time when you're writing strings all the live long day.  I've
proposed modding Lua so that in a CMake script, strings without quotes
are transparently understood in context.  This suggestion was met with
derision, that modding stock Lua was a completely silly, braindead
idea.  But such people haven't thought it through.  The main benefits
of Lua are documentation and marketing.  If it's 95% Lua it's still
pretty much Lua.  If modded Lua and stock Lua can be made to
transparently interoperate, then who cares?  Oh well, I'm used to
having The Right Idea long before other techies are willing to accept
it or even consider it.  The correct diplomatic procedure is to
convert it into *their* idea so *they* can congratulate themselves
about it later, but where's the fun in that?

Similarly, ${table} instead of unpack(table).  Got a lot of tables to
unpack.  Remember this is not for some pure Lua culture.  This is a
migration from CMake to Lua.  CMake users are going to want some
familiar grounding and will resent gratuitously tedious syntax.  If
their needs aren't addressed, they won't migrate and the whole effort
would be for naught.


Cheers,
Brandon Van Every