Hi, On Fri, 2008-12-19 at 14:30 -0600, Dirk Reiners wrote: > Hi Gerrit, hi Carsten, > > Carsten Neumann wrote: > > Hi Gerrit, > > > >> - osg1.x compat, deprecated support > >> - fcd/lex/bison recreation of src files > > > > personally I don't care too much about this being part of the build, > > having a (python) script that regens them is fine for me. > > I would prefer to have it as part of the build, but given that it's a > nontrivial problem that really only shows up extremely rarely, and then > only for people who know what they're doing, a script is probably the > better solution.
I don't think it's not trivial. Lex/Bison and QT support are there for cmake so adding fcdEdit should not be that difficult. I just did not have time to look into it in detail. Priority was that it compiles for win64 which the current scons system did not. And the FAQ has some sections on how to add the results of external programs to the build. > >> - osg-config / FindOSG.cmake > > > > trivial remark, but we should call it FindOpenSG.cmake to avoid clash > > with OpenSceneGraph ;) > > Yup! :) ;-) > > would you mind if I do some reorganization on the build? The thing I > > don't like a lot is that it is hard to figure out which dir goes into > > which lib, because the information is spread over the different files. > > How about putting files CMakeLists.Lib.<name>.txt in Source/ that list > > all directories that belong to that lib (it would also centralize the > > logic for excluding directories depending on available 3rd party > > libs/config options)? The toplevel CMakeLists.txt would just glob for > > those and include them, so adding a new lib does not require changing > > files, just adding one - probably most interesting for contrib stuff. hmm, partially yes, having a named cmakelists file for the part that setups the library/project seems helpful. I still like the automatic collection of subdirs but I guess I could live without. Well I guess the best is give it a try and see how it looks ;-). One small warning/hint though if you glob for cmake files that contain the project/lib setup there is a dependency on the traversal order of directories. For example the one issuing the install rule must go last, if you don't provide a separate binary dir (Took me while to figure out why nothing got installed on my first try ;-))). AFAIS that mainly means do the CMakeLists.Lib.OSGSystem.txt explicitly first and collect the rest. > > Also, IMHO we don't gain much be actually scanning for sources, > > because the generated make build does not automatically trigger a > > rescan, right? So, if we did things a bit more like everybody else > > using cmake we'd actually gain that adding a new source to a > > CMakeLists.txt triggers a regen of the build system. I have a very > > simple python script that generates the file lists, so you could just > > run that to update them. hmm, what is the difference between running an external python script or running cmake for that ? Except that on platforms that don't come with python you have to install it ? kind regards, gerrrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
