Re: CMake and Lua

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

On Thu, Feb 14, 2008 at 6:48 PM, Eric Tetz <erictetz@gmail.com> wrote:
>
>  The paragraph I was responding to:
>
>  "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."
>
>  That just reminded me of Stallman's article, about the lessons learned
>  with Emacs: (to paraphrase) "[Tool X Script] should be a real
>  programming language, designed for writing and maintaining substantial
>  programs.  Because people will want to do that! [Tool X scripts] are
>  often large, complex programs in their own right, and the people who
>  write them deserve the same facilities that other programmers rely
>  on."

On the other hand, CMake made it 7 years before its open source
community groused loud enough to precipitate a change.  I started the
most recent round of grousing and a good number of people chimed in.
I didn't previously believe in scope for CMake script, either.  I had
a change of heart owing to the growing complexity of scripts I was
working on.  Once requested, there was a lively discussion and scope
got added quickly.  1 month after my 1st grouse, it was in CVS.
Maybe less.  I have no idea how doable it would have been at CMake's
inception.  But CMake clearly did fine for many years without it, and
once it was time to do it, the infrastructure was mature enough that
it was quite doable.  I think this is a textbook case of "You Ain't
Gonna Need It."  Until of course, you do need it.

>  So I'm not suggesting CMake should switch to Lua, or even than it
>  should have been created with Lua. I was just making the *general*
>  observation that tool builders should think twice before creating
>  their own language, however minimal their needs of the moment are,
>  because users will inevitably ask more of it than the author
>  originally intended.

Indeed, I've proven that Autoconf + GMake --> CMake translators can be
written entirely in CMake script, relying primarily on CMake's rather
limited regular expression engine.  Bill thought that was unholy or
something.  I say, a regex is a regex is a regex.  It would be nice to
have a better regex engine, but the scripting interface to the regex
engine is irrelevant.  The regex engine is what actually does all the
work.  I probably now have the honor of having written more regexes in
CMake than anyone in the universe.  :-)

>  Hopefully we can agree on that, given that it's
>  Lua's entire reason for existence. It's the reason you might use a
>  language as powerful as Lua merely as a configuration language: future
>  proofing,

You Ain't Gonna Need It is the exact opposite philosophy from future
proofing.  Compare also, Worse Is Better.

> so you don't end up 7 years into development still sweating
>  your language design.

Since when is language design the bottleneck for tool adoption?  Let's
make no mistake, CMake is the best C/C++ cross-platform build tool out
there.  I just don't believe in complacency.  If you're ahead, make
sure you stay ahead.


Cheers,
Brandon Van Every