Hi Dirk, > Hi Gerrit, > > Gerrit Voss wrote: >> aeh I'm confused. SceneFileHandler is in System (for exactly this >> reason). And nothing else should depend (and does) on FileIO. So if a >> group uses SceneFileHandler it still only depends on System not on >> FileIO. > > I see what you're saying. The idea is to put the base classes, i.e. external > interfaces, into System and leave everything else in their respective libs. > >>> - Split off the base pieces that are visible from the outside and put them >>> inside System. That's the current version, but it breaks down if those >>> pieces >>> need other libs (which can happen fairly quickly, like FileIO needing >>> GraphOps >>> needing Geo needing pretty much the whole thing...). >> Again confused here FileIO is different from System so why does FileIO >> needing GraphOps needing Drawables make any difference for System ?? > > FileIO uses GraphOps (for the default GraphOps), GraphOps needs Geo (as Merge > and other Graphops manipulate Geometry) etc. > >> Exept that there is a bug in GraphOps, which was not factored correctly >> to the new library structure. If you do it right and take out the pieces >> SceneFileHanlder actually needs you have the high-level glue interface >> that belongs to SystemLib. Everything else goes somewhere else (Util). >> So you don't get additional dependencies for SystemLib. >> >> So I don't see the breakdown (maybe yet)? > > Your changes fixed the immediate problem that I had. > >>> - Split the libs more finely into basic pieces and the parts that need >>> higher >>> level functions. For a node to need FileIO is a fairly unusual thing, IMHO. >> Unusual for sure, actually I would go as far as it never ever should >> happen and if it happens something in the design is really wrong. > > Well, the ProxyGroup doesn't really have a choice, it's designed that way. > >> I still don't see the difference, except probably reorganising the >> directory structure. Could out try again to put ProxyGroup into Groups, >> after I just fixed GraphOps it should work. >> >> Similar I don't see the need for Terrain or Points. I'm cleaning up some >> GeoClipmap Code right now and I did not ran across any problem that >> would prevent it from going into Drawable. >> >> So all in all I'm still not sure if there really is a problem or if it >> was just a porting bug ? > > Your changes fixed the immediate problem but opened another one. > > OpenSG uses static init quite a lot for registration with factories, e.g. for > SceneFileTypes or GraphOps. The way things are set up right now the factories > themselves are in System, so that the interfaces are available, but the > actual > methods are in other libs. So far, so nice. > > The problem is now that those other libs need to be explicitly linked against > the executable, or the factories will never be initialized, and the program > will > fail. Example: if you try to run the system unittests it will complain about > not > being able to run GraphOps, as they are not registered, as Util is not a > dependency of the system tests. (It also won't work for init order reasons, > but > I fixed those.) So to make it work you need to link Util to the executable, > and > you need to know that you have to do that. In this case it wasn't too hard, > but > for a user that could become pretty confusing: the interfaces are there, but > the > features don't work because they didn't know they had to link a few more libs. > > If we had a straight dependency structure we could make the libs depend on > all > the other libs they need. That way linking would fail if something is > missing, > and it would not show as missing features at run time. > > I can see arguments for both cases, but I'm leaning towards preferring link > errors over runtime weirdness. I can see that could get a serious mess trying > to > split the system into libs, but maybe that would help come up with a cleaner > code separation, however painful it may be. ;)
this wont work on windows. We can add some lines of code to osgInit(). Just use the getSharedLibraryFileName() function on http://opensg.vrsource.org/trac/wiki/Dev/PluginsPathes to get the absolute path of the OSGBase.so and than load all OSG*.so in this directory. Andreas > Comments? > > Dirk > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Opensg-core mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-core > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
