Mike Jackson wrote:
http://openscenegraph.org/archiver/osg-users/2006-August/0590.html
is the beginning of the relevant thread.
Chris Osborn wrote:
>While the script writing was easy to learn, I quickly found myself
>limited by its API. Anytime I needed a new feature, if CMake didn't
>support it out-of-the-box, I was out of luck :( Delta3D ended up moving
>to SCons since I could write normal Python code to add in any special
>features it lacked. CMake's extensibility may have been improved in
>recent months, so the point may be moot.
I can say that CMake 2.4.x is scads better than 2.2 was. I had problems
getting things done in 2.2. The CMake development team is really super
sharp and super responsive to users' needs. Basically they got rid of
all my major issues in 2.4 and reduced my worries to minor details.
CMake development is rapid. On the good side, that means new features
come; on the bad side, the documentation lags. But the mailing list is
a great resource, people answer questions readily, and that very much
makes up for any documentation problems.
>And just in case everyone didn't already know, MS VisualStudio projects
>generated with CMake still use CMake under the hood. So users wanting to
>compile the OSG would always need CMake installed somewhere. It would be
>nice if a tool actually generated a totally native project. SCons is the
>same way... :(
Your frowny face is misplaced. Once you generate that native project,
you are *not* done. I *guarantee* you that you're going to change
something about your CMakeLists.txt, because you're going to think
better of this-and-that as you work on your build system. When you
make those changes, you're going to need to regenerate your native
project. The hook into CMake allows this regeneration to happen
automagically most of the time. Not all of the time; when I'm in doubt,
I kill the generated build tree and start clean. But most of the time,
under either MinGW or MSVC, things just work. If you didn't have the
hook, then you'd always be forgetting that you modified CMakeLists.txt
but didn't regenerate, and you'd be most annoyed. Also, the hook
usually allows just the necessary dependencies to be regenerated. If,
for instance, you change your INSTALL system, it's not going to force
you to rebuild everything, although you'll get a lot of relinking.
People have a misperception that having to install anything, no matter
how trivial, is bad. This is mirrored by the strange perception that
relying on shell scripting for everything is somehow good. It's
actually rather fragile, as anyone with serious ./configure experience
can attest. Unixen tend to think it's fine because they're used to it,
whether it's reliable or not. But non-Unixen have a more pressing
problem: shell scripts aren't portable. One of the main values of CMake
is it'll do stuff under any major OS, not just a Unix shell. CMake also
has a scripting language. It is not as full featured as a Python or
Ruby or Perl or whatnot, but it runs everywhere and it gets the job done.
Really, what is needed in a build system, is not so much the best /
nicest language in the world. What's needed are build capabilities that
actually work and actually do the things people need to do with builds.
CMake has all of that. And what it doesn't have, the CMake team can be
persuaded to produce. The KDE people switched from SCons for these 2
major reasons, capabilities *and* responsiveness. They weren't getting
the job done with SCons, and the SCons developers weren't helping them
out. Here again is the article about the KDE switch,
http://lwn.net/Articles/188693/ .
Cheers,
Brandon Van Every
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
