Re: Premake vs. CMake

["Brandon Van Every" <bvanevery@...>]

On Feb 2, 2008 11:44 PM, E. Wing <ewmailing@gmail.com> wrote:
>
> > Aside from emotions there is an economic reason. There is a limited
> > amount of such information one can absorb at a given period of time.
> > Usually projects are complicated enough for its developers information
> > absorbing throughput to be filled to capacitiy. It is always better
> > for the commercial project for its developers to spend time absorbing
> > information related directly to the project itself than related to
> > auxiliary build systems.
>
> I completely agree with this statement. CMake with a Lua scripting
> interface could at least help make the opportunity cost seem
> significantly lower, particularly if Lua is already being used or
> being considered for the future.

Or we could just write some proper docs for CMake's core syntax, so
that people stop thinking this is a big deal.  A build system has a
language and a pile of build capabilities.  It doesn't matter what the
language is, you're still going to have to learn a pile of build
capabilities.  Lua doesn't help with that.  I've outlined what needs
to be done in http://www.cmake.org/Bug/view.php?id=6295 .  I'm going
to buy a copy of the new "Mastering CMake" book when it's available
(any day now), rip off whatever it has to say about syntax, put it up
on the wiki, and get it happening.  Kitware needs to give away a
chapter of their book.  Enough to give newbies an incentive to
continue their learning curve, either by buying the book or getting on
the mailing list.  The mailing list is actually the best resource for
learning everything, but lotsa techies never bother.  They make
evaluations in a vacuum.

> Since there are so many Lua users/experts here, I wanted to mention
> that one of the CMake authors attempted to embed Lua as an experiment
> to see if providing a Lua based interface to the CMake API was even
> possible. After 15 hours of work, it turns out that it is. A simple
> prototype that binds the CMake API functions to Lua was made
> available. It is incomplete though because it doesn't bind the CMake
> variable system. Due to various non-technical reasons, it looks like
> this experiment will not continue,

Yeah... Ken came to the completely illogical conclusion that because
he had demonstrated proof of concept, Kitware shouldn't do it.  :-)
Sounded like me arguing that I couldn't adopt a dog.  I did.

> at least by the official CMake
> authors. But if anybody would like to help keep this experiment alive,
> volunteers/leaders would be welcome.

Syntax, documentation, and marketing aren't compelling reasons to do
it though.  The CMake syntax is plenty simple.  The community is
capable of improving the documentation, and of marketing CMake.  CMake
popularity is going up, not down, and it's mainly a matter of
catalyzing that trend.

Nobody has yet made a successful case that for a large project,
"fullblown" scripting languages can do things that CMake script can't.
 Perhaps that case could be made, and I keep looking around for an
exemplar of it, but it hasn't been made.  I think Kitware would be
receptive to the argument *if* it could be made, but nobody's been
able to make it.  People keep talking about things that Kitware is
capable of addressing by improving CMake in pretty much the form it's
currently in.

Comfort, familiarity with Lua or some such really isn't an argument.
Nor is having something to embed, something you can tweak into a
domain specific language.  CMake already has its script, people
improve and extend it.  The bottom line is, what can Lua do that CMake
script will never be able to do, no matter how much it is improved?

Only thing I can think of is, "be super popular, because it's useful
for multiple technology projects."  CMake script is never going to do
anything other than be useful for a CMake build.  But this is in the
realm of pure marketing, it's not a technical reason to use Lua.


Cheers,
Brandon Van Every