[CMake] improve the CMake language?
Gonzalo Garramuño
ggarra at advancedsl.com.ar
Thu Nov 8 07:01:48 EST 2007
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
More information about the CMake
mailing list