[CMake] CMake with Lua Experiment

[Jesper Eskilson]

Brandon Van Every wrote:
> On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles <pgquiles at elpauer.org> wrote:
>> As "DSL based on Lua" != Lua, assuming Kitware gets rid of
>> documentation and bugs in the language might be too optimistic. Look
>> for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based
>> DSL for hardware description, like Verilog or VHDL, but it's so
>> different from Ruby you need to produce the whole documentation again.
> 
> So?  So far I'm the only person who has proposed changing Lua syntax.
> I've only listed 2 items: excessive quotes and unpack(table).  Nothing
> would stop anyone from using quotes all over the place or
> unpack(table), i.e. standard Lua would still work.  It may even be
> possible for these minor tweaks to be transparently corrected as far
> as 3rd party Lua libraries are concerned.  If it's 95% Lua it's still
> Lua.  We're talking about a 1 page addendum to the docs, tops.
> 
>> Talking about Ruby, could someone please paste his wishlist about
>> variable scoping for CMake? (ie what would you like to add: local
>> variables which die when you exit the loop, file-scoped variables,
>> directory-scoped variables, project-scoped variables, what?). It's
>> quite difficult to fix a problem we have not properly defined (at
>> least, I have never seen a proper wishlist about this).
> 
> I just want scope, i.e. I don't want global variable names crapping
> all over each other.  I don't care about any fancy dancy Computer
> Science ways of adding extra programmatic features.  Other people may
> see heavy duty OO or tweaky FP constructs as beneficial for their
> build system.  At present I don't.  

No offense, but you're not really in a position to determine what
constructs are benefitial for people in their own build systems. Build
systems look very different in different places, and assuming that you
know whats best for everybody is a good way to make people want to move
away from CMake.

Many systems (even the *really* large ones) are actually very simple to
their layout; projects are often isomorphic so that each CMakeLists.txt
is more or less just a list of files to compile. But other systems (both
large and small) are simply to complicated to maintain a build system
for without a proper language at your disposal. GCC and the Linux kernel
are good examples of the latter (neither of which actually do have a
good build system language, but that's another story).

> But there's clearly a need for
> more structure than CMake script has got.  As far as I'm concerned the
> fancy dancy stuff is just an artifact of the embedded language that
> you get "for free," whether it's Lua, Ruby, or Python.  None of that
> has been enough to propel SCons into the limelight.

No, but having (or being) a real programming language is still one of
the main benefits of using SCons (IMO). Still, I went with CMake for our
build system, primarily due to the superior support for generating
Studio project files, and the fact that SCons has *major* performance
issues, especially on Windows.

I would like to claim that the input to the build systems (Makefiles,
SConsctruct, CMakeLists.txt, etc.) should be considered as source code,
with all the implications that has: checked into version control,
subject to code quality standards, subject to code review, etc. Given
that standpoint, having a real programming language in your build system
is very natural.

--
/Jesper