[CMake] CMake and Lua
ewmailing at gmail.com
Sun Feb 24 13:37:57 EST 2008
On 2/24/08, Brandon Van Every <bvanevery at gmail.com> wrote:
> On Sun, Feb 24, 2008 at 12:56 PM, E. Wing <ewmailing at gmail.com> wrote:
> > On 2/24/08, Brandon Van Every <bvanevery at gmail.com> wrote:
> > >
> > > So are you going to write this framework for us, that makes all the
> > > work of supporting multiple languages magically go away?
> > If you bothered actually reading my comments, you might have noticed
> > the paragraph where I said it's not immediately obvious how to
> > refactor these things. But by finishing the Lua integration, I believe
> > there is a chance this will become more clear, and one of two things
> > will happen. 1) It becomes obvious how to refactor things so people
> > can write their own language bridges. 2) It becomes obvious
> > refactoring is not so easy, and the way to bridge is directly through
> > the Lua runtime, similar to how Obj-C/Cocoa is bridged.
> It's lotsa extra work to support lotsa extra languages. We've all got
> things to do, we're not made of time and money. Selling people on a
> Lua migration is difficult enough as it is. Why don't you concentrate
> on *that* agenda, before bothering with even loftier stuff?
I am in agreement with you here. Again, part of my discussion of the
Obj-C bridging was the fact that the community wrote it all, not
Apple. Apple did not need to know or care what bridges were existence.
However, they saw the benefit in the bridges and decided to make
bridging even easier for people to write by introducing
To draw the analogy, I would say CMake could benefit if language
bridging was something that was manageable. But Kitware won't have to
write or support all the bridges that might come.
But I agree that starting with just Lua to begin with is a good
strategy. But as a side effect of completing a fully functional Lua
binding, I believe it will become more obvious on how to support
bridging in general. Then if anybody in the community is interested in
different languages, they have a starting point and proof it can be
> > > > People who want
> > > > to use CMake (the project generator) should be able to decide for
> > > > themselves what language they want to write in.
> > >
> > > No they shouldn't. They can pay for that kind of support.
> > That's a nonsensical statement to me.
> The point is, they can either implement the multi-language support
> themselves, or pay people to implement it for them.
Yes, I don't expect Kitware to implement and support any additional
languages beyond Lua. (And even Lua is in question right now.) I fully
expect additional language support will be a grass-roots effort
outside of Kitware. However, with a working Lua binding, that may
become the basis for future bridges as there will either be source
code showing how it's done, or somebody will bridge Lua.
More information about the CMake