Brandon J. Van Every wrote:
Chris Osborn wrote:
>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'll tell you, furthermore, I'm having to do a lot of mucking about with
Autoconf right now, so that the Autoconf and CMake builds can be shipped
in the same tarball. The autotools --> ./configure --> make turnaround
time is exceedingly slow compared to CMake, even with --config-cache
supplied. The shell scripting that ./configure is based on is just
inherently slower than what CMake does. Autoconf checks for way too
much impertinent stuff. Hm, my CMake build doesn't check for nearly as
much stuff, only what actually would affect the build. If I porked out
CMakeLists.txt with all those useless tests, maybe CMake would slow down
also? But maybe not, because I don't think it's throttled by the speed
of a shell. It would be interesting to benchmark the two, at any rate.
People have had some dependency issues in CMake that slow things down.
For large projects with lotsa dependencies, it's noticeable. There are
so-called /fast targets to speed things up, that don't do buildwide
dependency checking. However, in CMake 2.4.2 those targets weren't made
available in all build directories, thus limiting their utility. Can't
remember whether this already addressed in 2.4.3, or if it's done in CVS
and will ship in 2.4.4. I'm not as well versed in such issues because
Chicken is a relatively small project, comprising only 2 Makefiles.
Anyways, performance issues are noticed by the CMake authors, and they
are dealt with.
Cheers,
Brandon Van Every
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
