[CMake] CMake and Lua

Brandon Van Every bvanevery at gmail.com
Thu Feb 28 14:01:56 EST 2008


On Thu, Feb 28, 2008 at 9:53 AM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> Brandon Van Every wrote:
>
>  >
>  > Only thing problematic I could see, is if someone's getting clever and
>  > using CMake script to generate CMake script.  I think it would be
>  > reasonable to make such people untangle their metaprogramming.
>  >
>  That's crazy, no one would do something like that...

That's my point.  It's an extreme corner case that I seriously doubt
anyone's worried about.

>  But even if they
>  did, I would not want to invalidate there effort by obsoleting the
>  language they programmed in.

That's contradictory.  You don't bog yourself down with enormous
support burdens for some teeny weeny percentage of people who do
something really weird.  Software *is* invalidation of effort.  Stuff
gets written, stuff gets changed, stuff gets maintained.

>  >>  It would be much safer and easier to continue
>  >>  to support it in the core of CMake.
>  >
>  > It's 2x work to support CMake script and Lua indefinitely.
>
>  Actually, I don't agree with you here, and it would be me and the CMake
>  team maintaining it and not you.

It's 2x work for the community.

>  I believe backwards compatibility is
>  key to adoption of software.  For a good read see here:
>  http://www.joelonsoftware.com/articles/APIWar.html
>  See the part about how the DOS game SimCity had a bug, and Microsoft
>  worked around that bug.  If something does not build with CMake, then
>  CMake will get blamed. If a translator fails CMake will get blamed.

What's stopping you from putting if(IMPORTANT_BUT_STUPID_APP) code in
CMake, if some CMake user is so important?  What's stopping them from
doing it?  This is open source.  Microsoft was intervening on behalf
of extremely popular proprietary apps.  They certainly didn't
intervene on behalf of no-names, such apps had to break and follow the
new rules same as everyone else.

>  It is a valid concern but has nothing to do with the using Lua or not.
>  Translators don't work for 100% of the cases, that is a fact!

*Software* doesn't work for 100% of the cases.

> You of all people should realize that.

The article you quoted above cites plenty of examples of Microsoft
importing old data silently and correctly, until a certain point in
their history.  I'm not seeing this big problem with CMake script -->
Lua translation that you're glooming and dooming about.  Need I remind
you that CMake is a trivial language?  Automake + GMake --> CMake is
much harder, it's got lotsa weird $< variables and $(call blah)
operators and general shell programming going on.

> However, supporting both languages is an option.

It's good that you think so.  I don't think that was your position a
few months ago.  I still think migrating to a new paradigm is better
than supporting 2 paradigms indefinitely.

>  Also, please refrain from calling me a liar.
>  There are no hidden motives or invented excuses.
>  You may not agree with me, but that does not mean I am inventing
>  excuses.

I haven't called you a liar.  It is true that I've said you're making
excuses.  "It could have a bug!  It won't be 100%!  Something could go
wrong!  Someone could blame us!"  That's the order of the day in
software.  In open source, these are not insoluble problems.  I'm
rather stability minded.  I talked about automated translators proving
themselves for 2 years before dumping CMake script.  That's a high bar
to meet.  I say, if a bar can be met, then move on.  Most commercial
applications behave this way.  They don't maintain old file formats
forever, they expect you to run them through their translators.

>  If this is how you treated the Chicken maintainer, he may have
>  dropped CMake just to get you off his mailing list....

I'm willing to call a spade a spade.  I'm also willing to confront
people when I have a problem with them.  If that breaks the
relationship, that does not trouble me.  Better than giving lots of
free work to someone who isn't really using it.  That doesn't apply to
our discussion here.  What does apply: you made a snarky comment about
the unprovability of whether things work 100%.  It's a comment that
invites resistance.  Why should unprovability be the end of an
engineering discussion?  Most things we do as programmers are not
proven in practice.  We may write test cases and prevent a lot of
things, but we also have mailing lists and bug trackers.  We expect to
do work.  The question is how much work; we aren't owed zero work
indefinitely.

>  I just got back from talking about CMake at FOSDEM, and was very pleased
>  with the reception CMake is getting in the European open source
>  community.  Many folks are using it, and like it.  No one complained
>  about the language.

That's encouraging.

>  One person asked about Lua, and was mildly
>  interested but could talk it or leave it.  I told him we were still
>  evaluating the option and we are.

That's good to hear.  I think I've been pretty objective about Lua.  I
just don't want to see Lua defeated for perceived reasons that don't
hold up under scrutiny.  I'm still waiting to see evidence of major
technical merit.  I think it could be demonstrated in any large build
system using any fullblown language, the example doesn't have to be
Lua.  But I've yet to see such an example.  Doesn't mean it isn't out
there, but I haven't seen it, and nobody's called it to my attention
yet.


Cheers,
Brandon Van Every


More information about the CMake mailing list