[CMake] CMake and Lua

[Brandon Van Every]

On Mon, Mar 3, 2008 at 6:13 PM, James Mansion
<james at mansionfamily.plus.com> wrote:
> Brandon Van Every wrote:
>  >>  Then probably that is because those projects use Ruby AND Python AND Tcl
>  >>  - so I have to have them anyway.  Hey, lets all use C89.  Everyone has
>  >>  that, right?
>  >>
>  >
>  > What if it is just C/C++ code?  And the open source author likes
>  > Python better than Lua?  So he does his build in Python, and now I
>  > have to have a Python interpreter just to build his C/C++ code.
>  >
>  Fine.  Don't use his code.  I try to avoid automake.

Don't you see the problem as far as fragmenting open source builds in
general?  In the current day, avoiding automake is not a realistic
answer as far as the vast majority of open source developers are
concerned.  If you are personally converting every single open source
package out there from automake to CMake, that's commendable, but it's
not a labor we should expect the open source world to habitually
undertake.  If you are not converting anything at all, and simply
avoiding vast tracts of the open source landscape, then you are not
taking into account the concerns of a very large audience.  CMake
cares about that audience and it's part of why the Tower Of Babel
approach is deemed unacceptable.  Other projects, like SCons, do deem
it acceptable; you are certainly free to use those instead.  I've
reported on a number of alternate tools as of late, and given the
state of the competition, I do think that CMake's desire to be 1
standard rather than many standards is reasonable.

>  > Either CMake bloats with an interpreter for every scripting language
>  > out there, or the user has to install Python for not much of a good
>  > purpose.  I think the ease of the end user is more important than the
>  > ease of the developer in this case.
>  >
>  The two are not separable.  The end user is a customer for *all* of the
>  developer's product.
>  If its a real issue, the developer will change.

So first I implement my CMake build in TCL.  Then people scream at me.
 I re-implement my build in Ruby.  People scream at me again,
especially the Python crowd.  So I add a Python build and chug with
both Python and Ruby for awhile, but I'm noticing it's a headache to
bother supporting both.  I'm getting really sophisticated with SWIG
and every single scripting language out there, so I dump everything
and build with Lua, for my own sanity of maintenance.  People scream
again because it isn't their personal favorite language.  By this
point, I've spent so much time futzing with the build system, that I
haven't really developed a product that people care about.  I give up
and swear off of the never-ending open source money pit for good.  I
get a "real job" shoveling Ant.  I hate it but I get paid well.

That's how I see it going down in the real world.  Most open source
projects don't have the luxury of change, change, change.

You're also making the unwarranted assumption that "the developer" is
1 person.  Open source projects are often polyglot.  People war over
these issues.  It causes enormous friction that keeps anything from
getting done.

>  The biggest problem with verbosity is that its not really possible to do
>  subroutines,

Actually it is, even in CMake 2.4.8.  The price is you have to write
these horribly long global variable names, so that your macro
"subroutines" won't collide with higher level macros.  I've written
half of a general purpose Autoconf + GMake --> CMake translator using
nothing more than macro subroutines and regular expressions.  Some
people call that an extreme abuse of CMake script.  I say it worked,
and the macros were only 3 layers deep.  But that was deep enough to
clamor for scope and functions, and we're getting it in CMake 2.6.0.
As far as I'm concerned, this kind of verbosity has been addressed.
I'm probably on the high end of the absurdity scale for what I've
pushed CMake script to do, and I did get through it even with what's
available now.  I pushed CMake script that hard (1) to get paid to
push the limits of CMake script, to find out what really needed to be
improved about it in the worst case, and (2) the hope that by
providing a large example of CMake script doing something non-trivial,
I might help spawn more CMake script gurus.  (1) worked, jury's out on
(2).

>  and the keywords-as-functions just look wrong to me.

But if you have a reason to write enough of it, you quickly get over
it.  People often must have forced reasons to deal with something new
and different.  If your boss says, "I want a pilot build written in
CMake 1 week from today.  We have to know if it's capable of solving
our problems," then you just go do it.  If your boss says, "Well what
do you think about this-or-that build tool?" you have the wiggle room
to complain and carp about whatever you like, and thereby defeat the
use of the tool.  If you don't have any boss, if you're just trying
things out, you have no deadlines at all and you can reject stuff on
any basis you like.  It all depends on what you want to get done, and
what you *have to* get done.

This is a marketing problem and it divides the market into several
segments.  People who think keywords-as-functions are a dealbreaker
are inevitably in the "Casual Builder" segment.  They're not that
serious about reaching a real goal, like supporting Unix and MSVC
seamlessly.  I've learned not to partner with people like that, and to
watch out for projects that aren't serious about cross-platform
support.  Doesn't matter what the wart is, they'll find an excuse to
dump CMake if they're not ideologically committed to GCC + MSVC.  I'd
like CMake to do things that attract more Casual Builders, as I very
much believe in building up volume of users at all levels in order to
make a tool popular and lucrative.  But I know that Hardcore Builders
are the core market, people who really have to get massive
cross-platform builds done and can't afford to dicker about minor
issues.  For the next several years, CMake is going to rise according
to how many big profile huge projects it successfully wins.  Not how
many little guys prefer obj.method(blah) to function(KEYWORD blah) or
some such.

> The language is a long way removed from any common imperative style

But once you get over that prejudice, you realize that command(arg arg
KEYWORD arg) is actually not hard.  There's only 1 thing to learn.
The quotes and escapes are what drive people nuts, not the commands.

> and it seems to me like a growing collection of special cases.

I view the CMake commands as an API.  I think it's laid out reasonably
well as APIs go.  There are some strange functions sprinkled here in
there, too obscure to remember unless you live and breathe CMake all
the time.  I nominate separate_arguments() for that principal honor.
I've never seen an API anywhere for anything that was actually nice
and perfect.  Generally speaking, I hate everyone else's code, I hate
trying to understand other people's APIs, and nowadays I only do it if
there's $$$$$$ in it for me.  I'm saying that, given my revulsion for
APIs in general, CMake's command API is reasonable.  Just don't expect
me to pore over MSDN anymore, I don't do that, no sireee!

>  Perhaps its just that the documentation is still poor.

That's my take on it.  Some docs have improved a lot in the past 2
years, others not so much.  I have to swallow new stuff to get
anything done in computerdom all the time.  Looking up APIs or whatnot
is a drill, it's work, but I know how to do it.  It's when I *can't*
look it up, that I have to learn through the school of hard knocks,
that I know something is definitely wrong.  I also think docs can
minimize the time it takes us to learn new stuff, and I don't think
CMake docs fully do that at present.  You really have to be pretty
motivated.  I've met many people who have rejected CMake on 1st brush,
there was too much of a perceived learning curve they were going to
have to do.  It's not just docs, it's also tutorials, and whitepapers
explaining what you're really going to need out of a build system
wouldn't hurt either.


Cheers,
Brandon Van Every