Hi David and Marco,
For stepping in an spotting the real cause and potential solution.
From an OSG perspective I'm happy for osgIntrospection to have helper
functions to assist OSG apps. Perhaps the naming library convetions
could be made default along the lines that the OSG uses, but have this
customizable by client applications.
I'm no expect in osgIntrosepction so I'll defer to you guys to decide
on the way forward.
Robet.
On 11/16/06, Marco Jez <[EMAIL PROTECTED]> wrote:
Hi Robert, David, Miguel.
As pointed out by David, the problem is not a compile-time dependency, so
there is no need to modify genwrapper.conf. Instead, the problem is an
unsatisfied run-time dependency between wrappers, which has never been faced
before. Partly, this behaviour is by design, partly it's not. If you're
confused enough, I'm going to explain it better in a moment. :-)
osgIntrospection was designed to be totally independent from OSG, and in
fact it is. One could strip osgIntrospection off OSG without much effort,
and this presupposes a certain degree of genericity of the osgIntrospection
code. This requirement of genericity is what prevents osgIntrospection from
knowing how to load wrapper plugins, because the details of each wrapper
(the file name and location, for example) are only known within the outer
application domain (the OSG domain in this case). In fact, you usually load
introspection wrappers by calling functions that are *not* defined in
osgIntrospection.
Wrappers that reflect OSG classes are, on the contrary, aware of OSG and its
classes (it couldn't be otherwise). So, the best place where dependency
between wrappers could be specified is in the wrappers themselves. Without
thinking too much, a possible solution would be to place into each wrapper a
global variable of some proxy class that automatically loads dependent
wrappers when the DLL is loaded. Genwrapper could be patched to do that
automatically I believe.
Some could argue that this genericity (btw, is "genericity" actually an
english word?) is not required, and that osgIntrospection should be made
OSG-aware. This would give osgIntrospection the means for loading wrappers
dynamically just as osgDB loads reader/writer plugins on demand. Well, I
think this would be a reasonable change, even though it would force external
projects that use osgIntrospection to be conformant to a certain naming
scheme and file-level granularity for introspection wrappers.
Thoughts?
Marco
----- Original Message -----
From: david callu
To: osg users
Sent: Thursday, November 16, 2006 1:59 PM
Subject: Re: [osg-users] osgIntrospection Problems
Hi Robert, Hi Miguel
2006/11/15, Robert Osfield <[EMAIL PROTECTED]>:
Hi Miguel,
On 11/14/06, Miguel Escriva < [EMAIL PROTECTED]> wrote:
I have a problem with osgIntrospection Wrappers. There are no dependencies
between wrapper libraries.
For example, imagine this scenerio:
1.- load osg wrapper
2.- load osgProducer wrapper
3.- Create a instance of osgProducer.Viewer
BOOM! A exception is throw: (type `N5osgGA16GUIActionAdapterE' is declared
but not defined)
The exception happens because osgGA wrapper is not loaded. I think Producer
wrapper should depend from osgGA wrapper.
Thanks for the notification. I have modified the genwrapper/genwrapper.conf
file to include osgGA in osgProducer link line, and uploaded the new
genwrapper to wiki:
Robert, In the genwrapper.conf you do :
configure library "osgProducer"
dependency win32-debug "Producerd.lib"
dependency win32-release "Producer.lib "
- dependency unix
"-losgUtil -losgDB -lProducer -losgGA -losgText"
+ dependency unix
"-losgUtil -losgGA -losgDB -lProducer -losgGA -losgText"
end
so add the -losgGA. But it is already in the osgProducer line.
To solve the Miguel problem, you must include the -losgwrapper_osgGA line,
but this create a dependance between wrapper
First, I think is not the good way.
1) If osgwrapper_osgProducer didn't need to osgwrapper_osgGA to compile or
run well, there are no reason to link osgwrapper_osgProducer with
osgwrapper_osgGA.
2) I think an exception is an run time error (error that can't be handle at
compile time), that the program must catch and give to the user, but that
only the user can resolved.
This could be a good way to say to the user, that the osg file he
loading with osgViewer, require an OpenGL version or extension unavailable
on the system. Then the user could continue or stop the application.
With the wrapper, you could say to the user what is the problem ( try
{ ... } catch(osgIntrospection::Exception & ex) {cout << ex.what() <<
std::endl; }, and he must solved it
or try to parse the ex.what() message to search the wrapper you must
load to solve the problem.
3) If we do dependancies between wrapper, we must do it for all wrapper.
And the only one wrapper indepandent of another wrapper will be the
osgwrapper_osg.
Secondly, perhaps the problem is not in the build dependancies but in
osgIntrospection.
The wrapper must give the possibility to create, use and delete (when it is
possible) an object that it reflect.
If the object you want create is not defined, you can't create this only
because the reflector which do a "new Class" is not loaded.
But if the object you want create is defined, you have the reflector and it
can do a "new Class".
If the class that you create is defined but the sub-class is not, you can
use the class methods and properties, but not the sub-class methodes and
properties.
So If the behavious described is the good, there are a problem in
osgIntrospection.
Marco's help is need here to confirme or not this.
http://www.openscenegraph.org/osgwiki/pmwiki.php/Tasks/GenWrapper
I have also updated the osgWrappers and checked them into CVS. These
changes should fix the above problems, let me know if it doesn't.
I have another problem with getAllMethods method in Type class. For example
you can get a Type for osg::CollectOccludersVisitor and then call
getAllMethods(), the result is a exception. The reason that
osg::CollectOccludersVisitor inherits from osg::CullStack and CullStack is
not exported by osgIntrospection.
There exists a src/osgWrappers/osg/CullStack.cpp, so it would it seem that
osg::CullStack has been exported.
in the genwrapper.conf, there are a line for CullStack:
suppress reflector "osg::CullStack"
So the osg::CullStack is not reflected. I remove this line and try to
understand where is the problem with this reflector.
see you soon
David
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
