On Tue, Mar 4, 2008 at 7:52 AM, Fernando Cacciola <[EMAIL PROTECTED]> wrote: > > > > Nutshell: is it strategically a good idea to implement Lua support for > > CMake? > > > > - CMake script must be maintained indefinitely for a small percentage > > of users no matter what the migration strategy
BTW, this point is intended to mean that CMake script must always be supported, even under the most wildly optimistic migration strategy. One can debate how many CMake script users will have to be supported indefinitely in practice, but there will always be some. We can add languages, but we can't really take them away, not without a fork of the CMake code and community. > OK, time to see what Lua is... Or maybe see what Python is. Just because SCons uses Python 1.5 and Waf uses Python 2.3, doesn't mean CMake couldn't use it. The Python license is fine, it's just slower and not as easy to embed as Lua. What if Python finally speeds up and Jython goes somewhere? An article that appeared today: "Sun hires Python pros in dynamic languages push" http://www.news.com/8301-10784_3-9884267-7.html?tag=head > > - too much programmability may cause people to treat CMake as more of > > a library or build component, rather than a standard end user tool > > > People always find the way to shoot themselves in the foot. I say don't > worry about that and trust the programmer. If I had a reason to be confident that multiple languages could be used seamlessly with equal engineering quality, maybe it wouldn't be so insane. Last night I thought about what the OO version of CMake would look like, for marketing not technical reasons. Why not target.add_dep(dep1 dep2 dep3 ...) ? The swizzle of transforming command(object ...) to object.command(...) is straightforward. Mainstream programmers probably would be more comfortable with object.keyword(...) to set some state. A lot of the CMake command set is well defined, field proven, and stable. I don't think anyone would have a problem mentally translating back and forth, the commands of the CMake interface that are actually crystal clear. It's things like separate_arguments() that need to be put to death, with type safety and so forth. I suppose that's a liability of language choice: not all languages are equally type safe. Still, all of this suggests a Virtual Machine approach to CMake. The open source universe certainly clamors for it, so if it could be done to a high level of engineering quality, maybe it is not so stupid. On the other hand, maybe typed, named arguments are sexy. Sexier than KEYWORD. Another thing to consider is, getting more people under your tent is not necessarily a bad thing. It doesn't work for SCons because there doesn't seem to be that much of a business model over there. I don't know how much money is locked up in SCons, they do have some noteworthy commercial users like VMWare, but SCons seems to be a well-meaning volunteer outfit. Hard to move aggressively on $0. Meanwhile, Kitware is much more mature as a business. What if at the logical extreme you had someone as large as Sun dumping money into CMake development? At the macroeconomic scale, CMake script is too parochial and not what the marketplace wants as The One True Build Language. In fact the marketplace may not want The One True Build Language at all; they might be amenable to the one true build engine. Someone like Sun could dump money into making a lot of options work well together. That's what these big companies love to do: go to war with competing Virtual Machines. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
