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. ;)
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
