[CMake] improve the CMake language?

[Gonzalo Garramuño]

Brandon Van Every wrote:
> 
> 1) licenses that are unfriendly to unfettered commercial development,
> often don't get accepted by commercial developers.  

Not really.

cmake is a stand-alone utility.  With any of the scripting language 
licenses, you can still ship cmake with your own, say, proprietary 
non-open source IDE.

For a utility like cmake that has very little use outside development, 
licensing is not going to be the main issue in making it more or less 
popular.  The main reason will be how good it is (or isn't).

If cmake was a popular C library on the other hand... the type of OSI 
licensing would indeed matter *much* more.

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

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

> 
> 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.  That way, I don't really have to make a commitment to a 
scripting language that can fall out of flavor later on.
I'd also rather offer people several options and let the best language 
arise naturally from that choice.  SWIG allows you to do that with the 
least pain, even if the project is under heavy development like cmake.

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.  Make cmake a *library* to the scripting languages.  That is 
(for ruby):

require 'cmake'
include CMake

generator = 'Unix Makefiles'
cxx_flags = "-W 3"
sources   = %w( hello.cpp )

add_executable( :hello, :sources => sources )
run


>> Sure.  That's from your POV.  For me, a language without good and easy
>> OO is a no-no as experience tells me it will sooner or later run into
>> scalability and maintainability issues.  That makes TCL and Lua to me
>> only minimally better than cmake's language in the long run.
> 
> 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.
cmake's source code in terms of .cmake files is already at the tipping 
point of begging for OO.

 > The main ./configure

Err... by your own standard, you can't use that.  That is GPL only.

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

> 
> Well that doesn't sound like the dumbest technical trick I've heard.
> Could it help with parallel builds?
> 

Nope.  Parallel builds in cmake are handled by your make program, not 
cmake.


-- 
Gonzalo Garramuño
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy