Hi there,
Yes and no, I guess one thing we would loose was the possibility to
> just add files and have the make system figure out to include them.
> I don't know if this would still be working with a cmake based system.
>
Well, CMake supports file globbing out-of-the-box if that's what you meant.
I do use it to automatically gather project files.
> If you are willing to give it a try, I can help. Once a developer has
> > ported the build script, it is also very easy for the other developers
> > to follow.
>
> also yes and no, I have seen weired cmake behaviour where after
> configure some directory entries were set back but the generate output
> still carried the correct, old directories. So every time you changed
> something else you had to reset these directories to get the correct
> makefiles.
Hmmm CMake does a lot of caching (which is good, since one of the top
complaints about SCons is that it's too slow).
All the weird problems I've seen until now were solved by deleting
"CMakeCache.txt", which forces CMake to ignore & re-cache everything.
The only usability hindrance about CMake (in comparison with SCons) is that
you have to run CMake at least once once before you can run 'make', since
CMake is a makefile generator.
But that aside, I prefer CMake's usability all the way around. It has
generators of all sorts, and does a *really* good job generating Visual
Studio projects (Xcode integration is really good as well, I hear).
Anyway in general I would first like to see all the dynamic generations
> (fcd, scanner/parser, osg-config, OSGConfigured) working correctly
> before starting to seriously consider it, but I guess if KDE is able
> to get it working with QT (in particular moc) there should be a way
> to get it done. Just that we should start with them first.
I bet it'll be much easier than it was with SCons.
Also I would like to have a similar easy integration of cross compile
> targets, e.g. by just flipping a (single) switch. One problem that is
> still left with this is currently cmake only supports one tool chain for
> the build tree but for environments like the PPC/Cell combination you
> need at least two.
I don't have any experience with cross compile, but CMake is very
configurable and modular. I guess in the worst scenario you could simply
have a CMake script that calls another CMake script multiple times, with
different settings for different tool chains. But that's just a guess...
> The nice thing of cmake though would be that enabling contrib packages
> would be in a central place (and they finally have a gui for X11 ;-)).
There are many other nice things. Handling dependencies will get much
easier. Handling distribution/installations will get much easier. Build
times will drop substantially. The build scripts will be much simpler and
modular (no more gigantic SConstruct file). We will have really good native
integration with VisualStudio and Xcode. And if needed also much better
support from Kitware...
Kind regards,
Thiago
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
