[CMake] CMake and Lua

Sebastien BARRE sebastien.barre at kitware.com
Sun Mar 2 12:23:23 EST 2008


At 3/2/2008 09:10 AM, James Mansion, wrote:

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

*Your* target user base. You focused here on your problem, which is a 
specific scenario, whereas we, at Kitware, have to think about a 
larger picture, and that includes making the majority of people using 
CMake "happy", as well as make sure the time and/or money they 
invested over the past 5/7 years doesn't go down the drain. The line 
has to be drawn somewhere and CMake is a build system, not a 
language; the problem of dependencies has been debated more than a 
few times, and it is not just a matter of asking "hey, please add my 
favorite language to the mix, it rocks".

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

Then probably that is because they don't. etc. You can go either way.

>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!'. [...]

Or you can just sit down, get it done, and move on because it's not 
that complicated after all. Please consider that people haven't 
waited for you to build complex and ambitious projects for years, 
where writing CMake scripts sometimes seemed like vacation in 
comparison. The KDE project recently switched over to CMake without 
anybody jumping off a German bridge. It has been done, it's being 
done, and it's working mostly fine.

It's not a beauty pageant contest, it's getting software to build; 
ultimately, as much as you can marvel at your carefully crafted lines 
of autoconf or CMake, what matters is what said software is going to 
do, being high-end scientific visualization, medical imaging or 
surfing the web, and in that regards CMake has enabled a lot of 
people to get that software up and running in less time/money, 
directing resources to what matters, the software itself. The long 
term choices we are making, the decision Bill is talking about, are 
meant to prevent this build process to become impossible to learn 
and/or maintain.

>   If you are saying that compatibility with the naivety of the past

No, it is said because people are running businesses, don't grow 
money trees and have no personal access to time machines. A huge 
number of lines of CMake have been written already, and not just by 
us of course. Backward compatibility and maintenance are extremely 
important. That's why that suggestion to force a switch to LUA is 
non-sense. That's why maintaining two or more languages, to my 
opinion, will only provide more headaches to people who want to get 
their software to build and focus on the software, in scenarios that 
may involve complex code and a lot of people participating. This is 
not building for the sake of building. 




More information about the CMake mailing list