[CMake] Re: CMake script vs. Lua

[Brandon Van Every]

On Dec 14, 2007 8:45 PM, Alexander Neundorf <a.neundorf-work at gmx.net> wrote:
> On Friday 14 December 2007, Brandon Van Every wrote:
> > On Dec 14, 2007 2:38 PM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> > > It really boils down to this:  There is no way we can ever stop
> > > supporting the current cmake language.   It would be a huge break in
> > > backwards compatibility.
> >
> > Gee I'm getting paid to migrate a huge build system, from ancient
>
> You're writing this since quite some time already to this list, still not
> done ? I hope you're not fiddling around with trying to use cmake as a
> programming language...

I'm not trying, I'm succeeding.  A primitive translator is simply a
pile of regular expressions.  I paved over many of the deficiencies in
CMake's regular expressions several months ago, using only CMake
script.  For instance, I implemented a word negation operator.  Once
CMake has PCRE, that sort of thing won't be needed.

> > crufty GNU Autoconf / GMake crap to CMake.  Writing a translator to go
> > from CMake script to Lua script, both under Kitware's control, would

BTW, this doesn't imply the translator would be written in CMake
script.  It's simply easier to have CMake script, Lua script, and a
CMake script --> Lua translator all under one roof, no matter what
language the translator is done in.  It could be done in Lisp, OCaml,
or Haskell if those turned out to be appropriate.

> Don't try to write a converter from some buildsystem to cmake *in* cmake.

Why not?  Just because you don't think it can or should be done,
doesn't make it so.  I had 4 motives to do it that way.  (1) I was
only planning to use regular expressions to do the translation,
nothing more sophisticated than that.  CMake script is perfectly
adequate in that regard.  One regex interface is pretty much as good
as another, the real programming work is done with the regex strings
themselves.  (2)   I knew CMake script and C++, not some other
scripting language.  I don't see C++ as particularly appropriate to
the problem, as it has no inherent regex support and compile-debug
cycles are slow compared to scripting.  (3)  A large body of CMake
script could serve as a political inroad with the client.  They might
realize the extent to which they could use CMake to do system things,
instead of Perl or Python or Ruby or whatever people think you're
"supposed to" use to solve problems.  (4) The choice of language was a
throwaway.  The most important end product is the new build, not the
method used to attain the build.  So if CMake script proved to be a
really good solution, that's great.  If it didn't, no big loss.

Of these motives, (3) the political one, was my strongest.  Why
improve Ruby when I could improve CMake script?

> While not as fluent as in
> cmake it took me half an hour to do it, in cmake it would have been more
> complicated.

I've programmed the translator for a few months, not a few hours.  If
the ruby code you're talking about is what I looked at on the wiki,
what I've done is way, way beyond that.

> Conclusion: use cmake to build programs, not for writing programs

You have no idea what I've done.  There's no conclusion to draw.  I
don't think what I wrote is that great from a long term maintenance
standpoint.  If I were going to refactor it for ever-more-generalized
translation, I'd want the PCRE capabilities.  I might even want to use
a completely different form of pattern matching, and just reuse the
overall design rather than the specific components.  But I do believe
my approach was cost effective, in terms of dollars spent for
translations accomplished.


Cheers,
Brandon Van Every