Robert Osfield wrote:
One thing that does slightly bother me is the yet another script language syndrome. Is there a reason why they dind't adopt Python or Lua?
Python is easily dismissed as a large external language dependency. Many people feel it is desireable to avoid additional dependencies in a build system. For instance, most Autoconf users don't like depending on anything other than what the system already has.
Lua is a better choice for embedding. Why didn't they choose it back in 2000 or whenever they got started on CMake? Who knows, maybe Lua wasn't good enough, or maybe not enough people were using it back then. At any rate, they didn't choose it, and now they have a large, extant implementation that works. It is decidedly non-trivial to rip such a thing up and stick a "proper" scripting language in it. People talk about it every once in awhile, and the CMake people aren't adamantly opposed in principle, but nobody has stepped forward to do the heavy duty work that would be required. Saying "gee I'd like Lua" is a very different proposition than "here is CMake working with Lua, will you take the patch?"
A proper scripting language also adds very little value. As I said before, what you want out of a build system are routines, functionality, and behavior that builds actually need. In short, a build system is more of a library than a script. The idea that you're going to be able to do anything you want with a build, just because you have a scripting language, is an illusion. The core capabilities of the build system are what matter. Again, look at that KDE article. SCons is in Python, clearly a sexier scripting language than what CMake has, but it was inadequate for KDE.
Aside from what goes into CMakeLists.txt, I do very little CMake scripting. I've gotten down to that level only when I've encounted a CMake bug or incapability, and I've needed to hack my way around it. There are a couple of corner cases during installation, and when testing system capabilities, that currently require scripting, I think they shouldn't, so I've made some feature requests. I also plan to submit some CMake scripts for such things when I have the time, but I don't right now. There's a wiki where people put up their scripts. If they're proven in the field enough, they get rolled into CMake and then everyone has the benefit.
A third point: you have to learn the build system. People think they want to have a scripting language they already know, like Python or Lua, so they won't have to learn anything. That just will never work under any build system ever. I guarantee you that even if you know Python, you're still going to have to learn SCons. I can know Bourne shell programming and still need to learn Autoconf.
Another aspect to challange that cmake is trying to sumount is that of tracking the moving goal posts of VS and Xcode. I don't hold out much hope for influencing MS to better support the cmake project itself,
Doesn't seem to be needed. VS is CMake's strong suit, really its raison d'etre. CMake is what GNU Autoconf could have been, actually supporting VS. But the FSF is political. They've refused my offers to gather up 2 extant wrappers for MSVC and integrate them with Autoconf. Their words: "It would harm the GNU Project." The FSF wants MS to die and for everyone to do Unix. In this respect they don't really believe in cross-platform, they believe in Unix everywhere.
but perhaps Apple could be more open to helping making the task of support Xcode through cmake easier. For instance if a new Xcode version comes out and breaks the compatibility then perhaps Apple could release scripts for the new Xcode on the day of release or near after. Perhaps other IDE's could be encouraged to go the same route.
Sure. I don't see any reason to suppose a bad future for CMake and Xcode. Cheers, Brandon Van Every _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
