[CMake] CMake with Lua Experiment

Brandon Van Every bvanevery at gmail.com
Wed Nov 28 14:35:11 EST 2007


On Nov 28, 2007 1:28 PM, Alexander Neundorf <a.neundorf-work at gmx.net> wrote:
> On Wednesday 28 November 2007, Brandon Van Every wrote:
> > On Nov 28, 2007 3:17 AM, E. Wing <ewmailing at gmail.com> wrote:
> > > Right now I think it's just an experiment to see how things might
> > > work, how much effort would be involved, and how much of an impedance
> > > mismatch there will be with how things are currently done. It sounds
> > > like things may not progress any further unless a real long term
> > > vision for CMake is developed and embraced.
> >
> > Gee you want one of those?  :-)  Here's one: happy, shiny programmers
> > using a happy, shiny, fullblown programming language to implement
> > entire build systems
>
> I for one really don't want that.
> I don't want a full blown programming language in my build scripts. I don't
> want to understand actual programs when looking at build files. IMO it is ok
> that the cmake language is limited, this way you don't end up with programs
> as build files.
> This is what can happen if you use scons, then you have programs as build
> scripts. And everybody can program something more fancy. IMO this is wrong
> for a build system.
>
> Still having some type of variable scoping would be nice to have :-)

I somewhat agree with you.  I'm not a fan of "here's this tweaky thing
you can do in Lua or Ruby."  The few times I've tried to be "helpful"
when a group was trying to get their build system off the ground (was
it OpenSceneGraph or G3D, I forget?) I railed against programmatic
approaches.  It's way easier for me to understand straight CMake
script than a pile of gratuitous abstractions that some programmer
thought would be kewl.

*However*, the need for robust scoping has been proven in my own and
other people's work.  As far as I'm concerned it's not just a "nice to
have" item.   Strategically, over the next 10 years, it is an
essential item to have.  Or CMake will someday be regarded as an
unacceptable toy, incapable of meeting the complexity requirements of
the software of the day.  CMake is currently ahead of the competition
in terms of capabilities; over the long haul, that happy fact is not
guaranteed.  Just as we all hate Autoconf now, if CMake is not
forwards-looking as far as capabilities, someday we will all hate
CMake. [*]

Because I see the need for scoping at present, I'm willing to concede
the possibility that Object Orientation, or some other higher level
organizational paradigm, may be needed in the future.  I don't know at
what point in the future, and I expect later rather than sooner, but
nevertheless technology marches on.  ASM code gave way to C code, C
code gave way to C++ code, C++ code gave way to Java code.  Each
generation of programmers claimed a lack of need, and each generation
is consistently proven to be partly wrong.  The old technologies and
paradigms persist, but new technologies and paradigms emerge and
capture large chunks of programmer marketshare.

I'm sensitive to the imperatives of marketshare.  I want more money in
CMake consulting.  I want more money in Open Source cross-pollenation
between Unix and Windows.  So, if "fancier programming constructs"
make a tool vastly more popular, I take that into consideration.

[*] Frankly some people hate CMake now, and they don't make it a secret.


Cheers,
Brandon Van Every


More information about the CMake mailing list