Brandon J. Van Every wrote:
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.
Awesome. Glad it has improved :) One CMake developer even contacted me
personally to find out why Delta3D switched to SCons. So they are
definitely active and looking to improve.
>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.
I certainly understand the benefits of being able to seamlessly
regenerate project files. My frown my mostly a reflection of what the
faces of the rest of my team looked like when I told them they had to
modify a CMakeLists.txt instead of using the Visual Studio project
settings GUI. I understand why you need to, but it was hard convincing
VS-only developers.
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.
I definitely agree shell scripts are too fragile to get the job done in
a robust and easily extensible way. Hence me looking at CMake and SCons
to begin with.
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/ .
Yeah I read all about that from the kde side as well the scons-users
list side. I'm glad kde make the switch and it seems to be working out
well so far. Delta3D has not hit the wall yet with SCons, so we're
sticking with it.
As for OSG, I can't wait to try the new CMake system out!
-chris
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
