Re: [ANN] Bou - a Lua-based Build System

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

On Feb 9, 2008 4:45 AM, Taco Hoekwater <taco@elvenkind.com> wrote:
>
> Brandon Van Every wrote:
> >
> > CMake didn't begin life as play.  It had a serious job to do, and it
>
> That may be true, but it suffers from two of the most typical "play
> project" flaws out there: its script syntax is one of the worst cases
> of NIH I have ever seen, anywhere;

The syntax is merely command(arg arg KEYWORD arg blah whatever).  I
have issues with the string / list / quote / escape handling, but not
with the basic command-argument format.  It's as simple as it gets.
It's also reminiscent of Autoconf script.  In that respect it's a
cleanup, you don't need commas.

Kitware actually had a lot of prior experience with TCL and they
deliberately avoided using TCL.  I can't remember the reasons, other
than them thinking TCL sucks for some reason.  It's in the CMake
mailing list archives, along with discussion of Lua pros and cons,
which is what triggered the historical query of "Why did you do it
this way?"

> and its documentation is so
> technical that it is almost imprenetable.

The shipped electronic documentation is still CMake's weakest point.
I've said that quite often.  I file bug reports to improve it.  Lately
they've been getting acted upon.  Nobody's yet exerted the energy to
make a major cleanup of the electronic docs, which is what they really
need.  Kitware did just ship a new edition of the "Mastering CMake"
book, covering CMake 2.6.  I've got copy, I haven't read it yet.  I
don't need it as a reference, I know CMake.  I bought it to use as
source material for improving the shipped electronic documentation,
and to determine how much or how little I should be recommending the
book to others.

CMake has a very helpful mailing list that more than makes up for
substandard "early adopter" documentation.  But many techies never
even bother to get on the mailing list or ask a single question about
what to do.  They evaluate CMake in a vacuum and never realize what
actually makes it such a strong piece of software, the responsiveness
of the people who develop it.  Although it is an annoying
characteristic of many techies that they like to tinker alone, I don't
consider this entirely their fault.  I've said many times that CMake
needs enough documentation to turn a curious newbie into an
intermediate user.  To that end, CMake 2.6 will have proper Start Menu
shortcuts on Windows to the docs and the website.  The docs have
pointers to the mailing list and FAQ.

> Most people won't care about CMake's "industrial capabilites" and
> do not need to write "non-trivial stuff".

"Most?"  All it would take is a few more major projects like KDE, and
indeed "most" would care.  People have jobs too.  Just because there
are lots of small open source projects out there, doesn't mean they're
the be-all end-all of the industrial application of build systems.
But I wouldn't say CMake has conquered the world yet.  We're working
on it.

> On the flip side, I found it
> amazingly hard to write fairly trivial stuff like the stuff you need
> for "toy" projects^* in CMake.
>
> * Like in MPlib, that is using Cweb (preprocessed) sources instead of
> plain C. Even plain Make does a better job than CMake at supporting
> the preprocessing stage and its generated dependencies.

I had to look up Cweb to know what it is.  CMake is a strong C/C++
build system.  You can build anything you like with
add_custom_command, but the built-in bells and whistles are aimed at
C/C++ developers.  Cweb looks esoteric; I find an expectation of
off-the-shelf Cweb support unreasonable.

Have you had trouble building trivial C/C++ programs in CMake?


Cheers,
Brandon Van Every