Re: [Opensg-core] Circular Dependencies and scons

[Gerrit V. <vo...@ca...>]

Hi,

On Sun, 2007-08-26 at 19:57 -0500, Dirk Reiners wrote:
> 	Hi Gerrit,
> 
> Gerrit Voss wrote:
> > 
> >
> 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.

roughly. I don't really have an absolute fixed rule. 

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

sure but my confusion was how do you drag System into this equation ? 


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

Hmm I'm still confused, as you say FileIO does this mean using the
SceneFileHandler interface or directly calling any of the loaders ?



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

Or they have to be loaded during startup.

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

And this is correct. SystemTest has nothing to do with Util and nothing
in Util should be tested in SystemTest. It should go to UtilTest.

> (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.

My feeling is this way you go back to the 1.x one lib to rule them all
layout.

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

I understand where you are coming from, 

but my biggest concern is you won't get anywhere no matter how hard you
try and now matter how much pain you are willing to take, especially if
you take your confused user argument into this.

Because you are looking at the wrong platform right now. Confused user
easily means Windows and the whole link it to your program and it
will be there assumption is going to break down fast (It doesn't even
work now). 

So if you really want to solve this, solve it on windows first with
the current library layout. This gives you a good idea what the
worst case solution is going to look like. Once you have this my
current guess is you won't need to change anything for Unix anymore.
Another guess is it won't be along the lines of more or less libs
unless you go back to the full blown system lib.



kind regards,
  gerrit