Date: Tue, 22 Aug 2006 18:02:55 +0200 (MEST) From: Luigi Calori <[EMAIL PROTECTED]>
> I'm going to go ahead and start on Eric's To-do list. I'll repost > that here: > - Need to place CMakeLists.txt directly into the source tree (to mimic > current GNUMakefile layout) It would be great... but do you have commit access to OSG repository? this was the main reason to keep the folders separate
Only Robert and Don have access. But I think we need to write it as it were going to be committed because it is easy to start using relative paths within scripts and if the layout changes, that will have to be fixed. If we can agree to a stable layout, then we could request getting committed early as the CMakeLists.txt don't conflict with anything. Meanwhile, I'm just using find/tar (or zip) to help me isolate the components: (From inside the OSG_OP_OT directory) find . -name "CMakeLists.txt" -o -name "*.cmake" | tar zcvf OSGCMAKE.tar.gz -T - find . -name "CMakeLists.txt" -o -name "*.cmake" | zip OSGCMAKE.zip -@ or maybe tar zcvf OSGCMAKE3.tar.gz -T <(find . -name "CMakeLists.txt" -o -name "*.cmake" ) Then to put them back into a tree, you just extract in that same directory.
> - Change the current clever file glob into a boring/dumb manual opt-in > to build Do you mean writing explicitly the .cpp in the CMakeLists? OSG has such an ordinate source tree that one can count on the fact that all the sources are relevant
And headers :) I really do like the slickness of your macro/function. I've been struggling with whether this is the best approach or if the dumb-explicit thing is the best approach. The big problem is when you're working in a non-stable or non-rc source. On several occasions I have spotted source code that resided in the tree that was not supposed to be built. (And sometimes I add files myself when doing internal development, but they are not compile ready.) I think it's safer to explicitly opt-in because of this. There are no surprises in this case. There is a secondary thing I like about having all the files listed explicitly. Doing so makes the CMakeLists.txt somewhat self-documenting and easy to search. I know when I was going through the prototype scripts, I was searching for where the osg core files were added, but I couldn't find it initially because I was expecting a large list of filenames I recognized. Since the prototype system only worked on Windows and I was on OS X, I started operating under the assumption that it wasn't written yet. It wasn't until much later I figured out what was really going on. So I think having this information explicit in the scripts would be useful to newcomers that are not familiar with our build system.
> - Finish adding all components (examples, plugins, etc) I was able to build almost all the examples and plugins, there are some problems for dependencies for some image stuff there are cmake for building the libraries, but no one working for GDal, there is also some FInd Macros. I' ve also tried to build a Use file for Using CMake OSG builds into other projects, such as osgToys.
I'm not familiar with Use files. How do these differ from the Findosg*.cmake files?
> - Add gui/configuration options to control which components are built > - Add detection for optional components > - Add platform specific options (OS X framework or .dylib, etc) > - Add preference support (built static or dynamic, 32-bit or 64-bit > (or obese in OS X?),etc) > - Doxygen support > > Secondary stuff: > - CMake/CTest/nightly dashboard? > - Packaging / installers Well .. that' s secondary but is probably something really useful being OSG a really active project where many users use latest CVS
I think I've figured out how to support Doxygen. Maybe there's a more elegant way though. (I've sent a horribly incomplete snapshot of what I've been working on to Jacob.) I have something for OpenThreads and Producer. OSG has multiple Doxyfiles and a footer.html file which I haven't figured out what to do with yet. Detection for optional components is kind of necessary for the osgplugins, especially on the non-OS X Unices (and maybe Windows too) because it is hard to know what's actually installed on these systems. For example, a GIF library may not be installed on the system. We need to know not to build the osgdb gif plugin. The other stuff that responds to user configuration might be secondary, but I'm worried that because there are enough options, it will impact the design of our CMake scripts which is why I bring it up now. (I can imagine every CMake command will either be surrounded by (multiple) IF cases or contain variables in the command or both.) Thanks, Eric _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
