[CMake] Re: CMake script vs. Lua

Rodolfo Lima rodolfo at rodsoft.org
Fri Dec 14 22:57:11 EST 2007


Brandon Van Every escreveu:

> not many, and mine was well, then nobody's gonna follow you.  I'd like
> to see the "renegade improvements" energy ploughed back into the CMake
> community somehow, because Kitware is still clearly "the winning team"
> that people are going to follow.  Most of my concerns about nicety of
> language are strategic, not tactical.  I just don't want people to

Let's not forget that cmake is being used by KDE, I think they wouldn't
change again their build system :)

> 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 once was tempted to buy it... Or am I being to 'evil' thinking
like this? heheh

> 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...

> The problem is, when I talk to most open source developers about
> marketing imperatives, it falls on deaf ears.  The idea of growth in
> order to make lotsa money doesn't inherently appeal to them.  In the

You know what? I prefer to choose languages based on technical merits
than 'trend' or marketing appeal. If I thought otherwise, I'd be
programming Visual Basic, C# and... God forbids... Delphi. But no, C++
is still my preferred language because I can do anything with it. So I
think a build language should do the same... be able to tackle every
build problems that exist or might exist in the future. Trends and
marketing appeal change... technical merits don't change so often.

> 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. If I was
in charge, maybe I'd conduct this differently, maybe spending more time
thinking about the language, what it should achieve. The problem is that
cmake now is being actively used, too late for language change. And
people that embark on cmake with big projects don't want to change their
scripts every time the language changes, so I really respect kitware's
opinion on this subject.

Regards,
rod



More information about the CMake mailing list