[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