[CMake] Re: CMake script vs. Lua

Brandon Van Every bvanevery at gmail.com
Sat Dec 15 04:16:37 EST 2007


On Dec 14, 2007 10:57 PM, Rodolfo Lima <rodolfo at rodsoft.org> wrote:
> Brandon Van Every escreveu:
>
> > Most of my concerns about nicety of
> > language are strategic, not tactical.
>
> Let's not forget that cmake is being used by KDE, I think they wouldn't
> change again their build system :)

By hand, no.  But fully automated transformation is a different
strategy.  I suppose it does require a string of guinea pigs to prove
that an automated translation actually accomplishes its miracles.
Wouldn't expect KDE to volunteer for the bleeding edge.

Actually, it begs a question of who would.  Maybe it's better to
auto-translate non-CMake builds, develop that core technology, then
eventually apply it to legacy CMake builds.

> > There's a whole 'nother tack that one could take about this stuff.
> > That the language is good enough; it's the documentation which lacks.
>
> Maybe the documentation is poor because kitware sells the book Mastering
> CMake?

I'm sure it affects what they invest their time in.  But the reality
is they're not currently selling Mastering CMake, they're sold out.  I
think Kitware realizes the free docs have to be "good enough" to keep
people interested in CMake when they first try it out.

> > I think we have to go explore the other build systems and find out
> > what they do better.  I don't think we've really done that.  I don't
> > think that kind of information has been brought to the debate.
>
> This discussion made me want to kill the monster that jam (and bjam)
> became for me. People at boost are very influential and knowledgeable
> about systems design and implementation, they *might* be right by
> choosing bjam, but I can't see how. Try to cross compile boost, doing a
> linux -> win32 build... My attempts worked until version 1.33.1, then no
> more. They're also known to be stubborn about bjam... just try to
> mention cmake there hehehe...

That's odd.  I heard a rumor that they were considering CMake.  But I
never followed up on that with anyone official.

> > Kitware ain't in this for religious zealotry, they're in it because
> > the open source business model works for them.  If I thought I could
> > make lotsa money setting up a Mercurial repository, mirroring CMake
>
> Alright, the world isn't good as we'd expect, but it doesn't change the
> fact that the last opinion is theirs, for the bad or the good.

Their opinion counts for what they choose to do.  What do *you* choose
to do?  How badly do you want Lua?  Is it actually worth money to you?
 Figuring out what's worth money is an important question.  There's
tons of open source projects out there with a handful of unpaid guys,
with a predictable lack of support.  The lofty goals of the project
fall behind when the unpaid guys get tired of $0.  But if you can
figure out where the money is in something, that's different.

> The problem is that
> cmake now is being actively used, too late for language change.

Nonsense.  People write build systems from scratch all the time.  Or
they translate from legacy systems that aren't CMake.  There are far
more people who don't use CMake than do.  They'll use whatever looks
like the best tool for the job.  And, even legacy CMake builds are
capable of slowly migrating forwards in some instances.

My experience is that migration is a question of political will.
There are dangers in allowing 2 different build systems, or 2
different build system approaches (i.e. CMake script and Lua script),
to exist side by side.  People who really didn't have to sacrifice
anything for the new build system, will clamor about wanting to retain
the old.  If you do too good a job of maintaining old and new systems
/ approaches side-by-side, then people have no incentive to ever
really move forwards.  Politically, it's far better if you can get
people to dump the old system and fully commit to the new one.  That's
not always possible.  But if you can marshal the political will in
that direction, you're in much better shape.


Cheers,
Brandon Van Every


More information about the CMake mailing list