[CMake] improve the CMake language?

Brandon Van Every bvanevery at gmail.com
Thu Nov 8 15:57:51 EST 2007


On Nov 8, 2007 7:01 AM, Gonzalo Garramuño <ggarra at advancedsl.com.ar> wrote:
>
> If cmake was a popular C library on the other hand... the type of OSI
> licensing would indeed matter *much* more.

What if I just want to rip a chunk of code out of Ruby and reuse it
somewhere?  I'll have the PITA of carrying the entire original Ruby
with me.

> > 2) I don't personally make a habit of investing in software that
> > encumbers me.  MIT / BSD / zlib-libpng licenses allow me...
>
> Right... I'll let it slide that your main platform of development is
> Windows.

Show me a larger game market with fewer restrictions on the indie game
developer.

> > And I agree with Juan, Lua sounds more
> > compelling than Ruby.
>
> Brandon, my understanding is that you don't know neither ruby nor lua.
> Before you make that kind of statement, you actually might want to spend
> some time actually using both languages first.

I've watched Lua vs. Ruby in the game industry for many years.

> > 3) Your license choices are fine for your own use, but you'd need to
> > talk to Kitware about what they actually want.
> >
>
> Now, that could be a fair point.  If I was interested in having Kitware
> distribute cmake with ruby.  Which albeit I like the idea, I don't think
> I pushed for it.
> As I said, I'm more interested in having a cmake have a language API or
> swig wrappings.

The last time we had a language API debate, Kitware said no way.
Check the archives.  My $0.02: where's the profit in it?  Doing a lot
of work to entertain everyone's pet language agenda isn't core to
building software.  Mr. Miyagi in The Karate Kid said something along
the lines of "better to know 1 kick well."

> That way, I don't really have to make a commitment to a
> scripting language that can fall out of flavor later on.

I don't know what you're worrying about.  Python and Lua are here to
stay, they've proven themselves in their domains.  I'd be surprised if
Ruby's going anywhere, unless Perl 6 finally ships and destroys it
somehow.  Seems pretty low odds of that happening, seems like Ruby's
already inherited the Perl 6 audience.  TCL is on the wane which is
why I'm against TCL.  CMake doesn't need the negative perceptions; in
particular, it doesn't need to look like "old software."  Anyways, if
we choose a popular scripting language today, it's going to be 10
years before the sun sets on it.  By then, it's about whether CMake
has cemented itself in the popular consciousness, not the scripting
language.

> Also, you guys are just thinking of embedding the language into cmake.
> I think it is much easier (and less of a license trouble) to do the
> opposite.

There isn't any license trouble with Python or Lua.

> Make cmake a *library* to the scripting languages.  That is
> (for ruby):

Great, now they need a Ruby installation to use CMake in this manner.
We're not on the same page about the goals.

> > What's the biggest build system you've yet written?
>
> Biggest, a custom one for a now defunct company.
> Better one?  Industrial Light and Magic's.  Albeit I did not build it
> myself.  I was more or less consultant and beta tester for it.

ILM is one of the crown jewels of the Python Success Stories.
http://pythonology.org/success&story=ilm  What did they need the OO
for?  And, given they did great with Python, why would they have been
better off doing it in Ruby?

> cmake's source code in terms of .cmake files is already at the tipping
> point of begging for OO.

Dunno.  I'll let others debate that one, as I'm not that familiar with
CMake's code base.  I just poke at it when I need to know something
about bugs or how CMake works, I haven't contributed to it in any way.
 We all agree that CMake script needs some kind of scoping.  That's
been decided and the wheels are turning on it.  But OO?  Dunno.

>  > The main ./configure
>
> Err... by your own standard, you can't use that.  That is GPL only.

I don't use Autoconf or GMake.  I translate them to CMake.

>  > It's not an exotic OO exercise;
> > that would be a waste of time.
>
> If you think OO is a waste of time and not a way to reduce your 400Mb of
> source code into probably 70Mb or less and enforcing consistency and
> readability, well...

Oh, the 400MB is mostly a pile of C++ and Java code.  The build system
is not.  It's about 1200 trivial Makefiles, about a dozen substantial
Makefiles, and one big honkin' ./configure script.  This isn't my
code, I'm merely translating the build system to CMake.  And I'm
saying, it's big and flat, it doesn't need OO.


Cheers,
Brandon Van Every


More information about the CMake mailing list