[CMake] CMake and Lua

Bill Hoffman bill.hoffman at kitware.com
Sun Mar 2 11:40:31 EST 2008


James Mansion wrote:
> Bill Hoffman wrote:
>> James Mansion wrote:
>> So, C++ is the language we picked/like.  You are welcome to contribute 
>> one in C++.  Imagine if you could develop generators (I assume that is 
>> what you mean by emitters) in any language!  You wouldn't even be able 
>> to share them.
> Bill, I like C++ as much as anyone, but I also work in other languages.  
> What youu wrote above is such utter bullshit that its hard to credit.
> 

Wow this thread is really getting out of hand!  Please refrain from 
swearing....
> If I have a project that is largely in a more convenient language - 
> whether Java or Python or C# (or even Lua) - and it has material 
> components in C++ for performance or reuse reasons, then it is clearly 
> reasonable to ship something that can make a good stab at building the 
> DLLs and running SWIG (and I think CMake reasonably can do this) *and* 
> to expect the target user base to have the runtime for the other 
> language concerned.
> 
> You are inventing this paranoid fantasy of a 'tower of babel' effect 
> poisoning the centrally maintained CMake.  And that's just not justified.
> 
I don't agree, having multiple language bindings for CMake would be a 
mistake.   As I have said perhaps two languages someday.  But no more 
than that.

.
> 
>> If you did use an arbitrary language bound to CMake core, people 
>> building your project would have to build/get something different than 
>> potentially any other CMake based project.
> So?  Is that a problem in *every* context?
Overall, I think it would be bad.
> 
>>  Wow, now I need CMake, Ruby, Python,  and Tcl just to build this set 
>> of software.  This is just the type of thing CMake was designed to avoid.
> Then probably that is because those projects use Ruby AND Python AND Tcl 
> - so I have to have them anyway.  Hey, lets all use C89.  Everyone has 
> that, right?
> 
What if they only use the Ruby, and Python for the build system parts. 
What if people want to share build system stuff wrapped in different 
languages.

> I like CMake.  But the language is impenetrable, verbose, and basically 
> poor - it can't quite decide whether to declaratve/functional or 
> imperative, has limited data type or structure support - or modularity 
> or reuse support.  It has the appearence of something that had modest 
> objectives to start with and has evolved.  That's quite natural, but 
> eventually you have to say 'Enough!'.
> 
I don't think I have to say Enough.  It has evolved, and built some 
pretty impressive stuff.  I am not completely happy with it, but it 
works.   I also don't think dropping support for it is an option.
> I like CMake for what it does, but not the way it does it.  If you are 
> saying that compatibility with the naivety of the past when the macro 
> language was being used for less ambitious things then fine.  But don't 
> expect that to stop us thinking that a) the language design sucks and b) 
> of all the alternatives, Lua would seem to be the best fit in terms of 
> its own dependencies and the cleanliness of the language itself.

OK, now you are talking about one language again.  I was trying to say 
that having a swig like any language support was bad.   I am also saying 
that we will support the current language as long as there is a CMake. 
We may or may not add Lua.   But, I don't think we will be providing a 
swig style java, c#, Lua, python, tcl language binding to the CMake make 
generation system.   I also feel pretty confident that the core 
generation system will stay in C++.

So, a summary seems in order in hopes of getting this discussion back on 
track.

1. CMake may add support for an additional language.  Right now Lua 
seems to be the best candidate for that.  It is small and easy to embed. 
The Lua stuff would have to work well/exist with the current CMake 
language.  I am still not convinced about this, but it is an option.

2. It does not make sense to use SWIG to open up bindings to any 
arbitrary language for CMake.  There should be one binary the CMake 
users can download/install to build any project that uses CMake as a 
build system.  It should not depend on any outside stuff.  It should 
require a C/C++ compiler to build.

-Bill


More information about the CMake mailing list