Hi, On Tue, 2008-11-04 at 06:58 -0300, Thiago Bastos wrote: > 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.
I would expect this to happen during the cmake run not the make run ? > > > 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). that for me is the least important bit ;-). My Windows builds are batch builds anyway just to check if it works. So besides the Visual Studio Project stuff there still must be a 'Makefile' based way to build it in a useful shell that allows secure remote logins (e.g. cygwin via sshd, the build-in windows shell does not qualify, nor does nmake). > > 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. maybe I never tried ;-), but one curious point would be how cmake handles the fact that some of our generated files must be in the source tree, not the build tree. > > 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... It's trickier than this. You can't even change the toolchain after the first cmake run, you have to restart in a fresh build directory, which btw requires separate build dirs to work > 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. Which kind of dependencies, the following from the cmake faq sounds scary: 'CMake does not preprocess source files while scanning dependencies' I haven't checked the implications. Correct and platform independent constistent dependencies and not just access time based dependencies is the one strong point on the scons side. kind regards, gerrit ------------------------------------------------------------------------- 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
