[CMake] Lua in a nutshell

[Brandon Van Every]

On Tue, Mar 4, 2008 at 7:52 AM, Fernando Cacciola
<fernando.cacciola at gmail.com> wrote:
>  >
>  > Nutshell: is it strategically a good idea to implement Lua support for
>  > CMake?
>  >
>  > - CMake script must be maintained indefinitely for a small percentage
>  > of users no matter what the migration strategy

BTW, this point is intended to mean that CMake script must always be
supported, even under the most wildly optimistic migration strategy.
One can debate how many CMake script users will have to be supported
indefinitely in practice, but there will always be some.  We can add
languages, but we can't really take them away, not without a fork of
the CMake code and community.

>  OK, time to see what Lua is...

Or maybe see what Python is.  Just because SCons uses Python 1.5 and
Waf uses Python 2.3, doesn't mean CMake couldn't use it.  The Python
license is fine, it's just slower and not as easy to embed as Lua.
What if Python finally speeds up and Jython goes somewhere?  An
article that appeared today:
"Sun hires Python pros in dynamic languages push"
http://www.news.com/8301-10784_3-9884267-7.html?tag=head

>  > - too much programmability may cause people to treat CMake as more of
>  > a library or build component, rather than a standard end user tool
>  >
>  People always find the way to shoot themselves in the foot. I say don't
>  worry about that and trust the programmer.

If I had a reason to be confident that multiple languages could be
used seamlessly with equal engineering quality, maybe it wouldn't be
so insane.  Last night I thought about what the OO version of CMake
would look like, for marketing not technical reasons.  Why not
target.add_dep(dep1 dep2 dep3 ...) ?  The swizzle of transforming
command(object ...) to object.command(...) is straightforward.
Mainstream programmers probably would be more comfortable with
object.keyword(...) to set some state.  A lot of the CMake command set
is well defined, field proven, and stable.  I don't think anyone would
have a problem mentally translating back and forth, the commands of
the CMake interface that are actually crystal clear.  It's things like
separate_arguments() that need to be put to death, with type safety
and so forth.  I suppose that's a liability of language choice: not
all languages are equally type safe.  Still, all of this suggests a
Virtual Machine approach to CMake.  The open source universe certainly
clamors for it, so if it could be done to a high level of engineering
quality, maybe it is not so stupid.

On the other hand, maybe typed, named arguments are sexy.  Sexier than KEYWORD.

Another thing to consider is, getting more people under your tent is
not necessarily a bad thing.  It doesn't work for SCons because there
doesn't seem to be that much of a business model over there.  I don't
know how much money is locked up in SCons, they do have some
noteworthy commercial users like VMWare, but SCons seems to be a
well-meaning volunteer outfit.  Hard to move aggressively on $0.
Meanwhile, Kitware is much more mature as a business.  What if at the
logical extreme you had someone as large as Sun dumping money into
CMake development?  At the macroeconomic scale, CMake script is too
parochial and not what the marketplace wants as The One True Build
Language.  In fact the marketplace may not want The One True Build
Language at all; they might be amenable to the one true build engine.
Someone like Sun could dump money into making a lot of options work
well together.  That's what these big companies love to do: go to war
with competing Virtual Machines.


Cheers,
Brandon Van Every