generally how good is xbig to wrap orge Plugins & Addons that are based on the Ogre sources? Does xbig provide the the same wrapped object types from ogre4j to use for further wrapping, to avoid same classes that mean the same. For example if I am trying to wrap PagedGeometry, what would be the efford to put in to get it working and how long would it take?
Thanks
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> generally how good is xbig to wrap orge Plugins & Addons that are based on the Ogre sources?
This has never been tested. Basically, when the library you are generating bindings for needs a class named SceneManager, that class must be known during generation.
That means you either have to included the OGRE sources or use a xml description the way we do it for the STL.
Anyway, ogre4j will be regenerated during the generation of the binding for the addon.
You can try to generate without the OGRE classes. When you are lucky the resulting code has just a few compile errors which can be fixed manually.
> if I am trying to wrap PagedGeometry, what would be the efford to put in to get it working
I have never used that plugin and cannot tell how much effort it would be.
> and how long would it take?
I can just say that generation of ogre4j took 12 hours.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you again for your kind reply. I will try to wrap PagedGeometry but I need a little guideline.
If I am understanding it right it should work like this:
1. Generate the Documentation from the c sources with doxygen.
2. Setup XBIG to use this Documentation as a base to wrap it
3. Wrap Sources ( c++ & java code)
4. Check wrapped code for erros (like unsupported stuff)
5. Try to comment errors out
4. build native dll from c++ wrapped sources
5. build jar from wrapped java code
Do you have some sort of document to see how xbig works? Does only needs the documentation created through doxygen without seeing the sources?
-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Do you have some sort of document to see how xbig works?
The INSTALL file includes a short description on what is going on. You may see the testcases for further details.
Basically you are right with your five steps. I would say it like this:
1. Let doxygen parse C++ headers and generate XML output (doxygen has different output formats).
2. Use doxygen's generated combine.xslt to merge all XML files together (we call it all.xml).
3. Use our doxygen2meta.xslt to generate meta.xml (our own format which describes the library).
4. Use meta2java.xslt to generate Java code.
5. Use meta2cpp.xslt to use C++ code.
6. Compile generated Java and C++ code.
Our testcases do all this via ant (plus compile & run a jUnit test which uses the fresh generated code).
> Does only needs the documentation created through doxygen without seeing the sources?
Do you mean without .cpp files? Yes, headers are enough.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok that helps to point some points out. Is there a way to include the wrapped Code from ogre4j as a base to wrap plugins/addons? That could help to speed up the wrapping process a lot.
I have now managed to wrap a simple class as a generic test first. But why does it need the cpp2j-base.dll as a dependency? The ogre4j doesnt have that dependency. Do you have the build.xml configuration to wrap ogre4j in the SVN Repository? That would help me configure it without using the cpp2j-base.dll
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Is there a way to include the wrapped Code from ogre4j as a base to wrap plugins/addons?
No, this is not possible :(
> The ogre4j doesnt have that dependency.
Both are compiled into one library.
> That would help me configure it without using the cpp2j-base.dll
We just copied the cpp2j-base sources into the ogre4j source tree.
> Do you have the build.xml configuration to wrap ogre4j in the SVN Repository?
There is XBiG/tests/Ogre3D but I cannot remember if this one was used to generate ogre4j.
Two more config files to consider:
- XBiG/src/xsl/config.xml
- XBiG/src/xsl/cpp2j/ignore_list.xml
ignore_list.xml is the one used for ogre4j and in XBiG/src/xsl/ is a file called config.xml.ogre4j which was used for ogre4j.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am very near to get it working without rebuilding the complete Ogre sources. First I used the meta.xml from the from the ogre sources ( ogre4j ) and included it to the externalType list ( like the STL ). Then I made a new config.xml for ogre4j dependant plugins. When the plugin gets wrapped ( meta2java ), the generated java classes contain the correct references to the Ogre4j stuff. The only anoying behaivor is that even the externalTypes get builded as java classes, what its not needed because they could be supplied by external jars. As a dirty workaround I can cancel the build process after its finished building the proper plugin classes.
Sadly I probably discovered a bug that happens wrapping PagedGeometry. When the namespace and the classname are the same, the meta2java process does not resolve the correct classname and leaves the C++ type in the Java Class ( like PagedGeometry::PagedGeometry::method() )
Can you point me to the right direction, because I am new to the XSLT stuff ;)
So far I am very happy how XBIG works, its very powerfull and intuitive wrapper.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How does your config look like? What is PagedGeometry::PagedGeometry::BatchedGeometry::SubBatch::QueuedMesh in Java?
And what is it original (class, typedef, ...)?
Does this generally apply to type parameters (i.e. non-STL templates)?
It works i.e. for Ogre::Skeleton::AnimationList
original: typedef std::map<String, Animation*> Ogre::Skeleton::AnimationList
java: public interface IAnimationList extends INativeObject, org.std.Imap< String, org.ogre4j.IAnimation >
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok now I am more certain that the namespace is the root of the problem. I changed the namespace from PagedGeometry to PageGeo and now it works. Seams that if a class has the same name as the namespace that then its not working right with STL templates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I am now trying to exclude the externalTypes
external_types.xml is read during doxygen2meta.xslt at line 246. These types are just copied into meta.xml and meta2java, meta2cpp cannot tell where they are from.
We would need a flag in the copied types which marks them as externalTypes. Then we should have a config option whether code shall be generated for that types.
The simple copy could not be used anymore because that additional flag has to be generated. I would store that flag as an element because it is easier to generate than an attribute.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> The simple copy could not be used anymore because that additional flag has to be generated
I had two other ideas how this could be done but for something as big as ogre4j they might not be useful.
1. Put external types on ignore_list.
2. Write the additional flag into the file from which the types are copied.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 1. Put external types on ignore_list.
I had the same idea to put them into the ignore list, but i didnt figure it out how i could archieve that.
> 2. Write the additional flag into the file from which the types are copied.
Yes thats a good Idea, but better to use your first suggestion for it, to keep it more simple.
Ive got the wrapped plugin working :), but know must try to find a solution for templates in functions. Stupid that they are an essential part of the plugin...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hiho XBig Team,
generally how good is xbig to wrap orge Plugins & Addons that are based on the Ogre sources? Does xbig provide the the same wrapped object types from ogre4j to use for further wrapping, to avoid same classes that mean the same. For example if I am trying to wrap PagedGeometry, what would be the efford to put in to get it working and how long would it take?
Thanks
Alex
> generally how good is xbig to wrap orge Plugins & Addons that are based on the Ogre sources?
This has never been tested. Basically, when the library you are generating bindings for needs a class named SceneManager, that class must be known during generation.
That means you either have to included the OGRE sources or use a xml description the way we do it for the STL.
Anyway, ogre4j will be regenerated during the generation of the binding for the addon.
You can try to generate without the OGRE classes. When you are lucky the resulting code has just a few compile errors which can be fixed manually.
> if I am trying to wrap PagedGeometry, what would be the efford to put in to get it working
I have never used that plugin and cannot tell how much effort it would be.
> and how long would it take?
I can just say that generation of ogre4j took 12 hours.
Thank you again for your kind reply. I will try to wrap PagedGeometry but I need a little guideline.
If I am understanding it right it should work like this:
1. Generate the Documentation from the c sources with doxygen.
2. Setup XBIG to use this Documentation as a base to wrap it
3. Wrap Sources ( c++ & java code)
4. Check wrapped code for erros (like unsupported stuff)
5. Try to comment errors out
4. build native dll from c++ wrapped sources
5. build jar from wrapped java code
Do you have some sort of document to see how xbig works? Does only needs the documentation created through doxygen without seeing the sources?
-
> Do you have some sort of document to see how xbig works?
The INSTALL file includes a short description on what is going on. You may see the testcases for further details.
Basically you are right with your five steps. I would say it like this:
1. Let doxygen parse C++ headers and generate XML output (doxygen has different output formats).
2. Use doxygen's generated combine.xslt to merge all XML files together (we call it all.xml).
3. Use our doxygen2meta.xslt to generate meta.xml (our own format which describes the library).
4. Use meta2java.xslt to generate Java code.
5. Use meta2cpp.xslt to use C++ code.
6. Compile generated Java and C++ code.
Our testcases do all this via ant (plus compile & run a jUnit test which uses the fresh generated code).
> Does only needs the documentation created through doxygen without seeing the sources?
Do you mean without .cpp files? Yes, headers are enough.
Ok that helps to point some points out. Is there a way to include the wrapped Code from ogre4j as a base to wrap plugins/addons? That could help to speed up the wrapping process a lot.
I have now managed to wrap a simple class as a generic test first. But why does it need the cpp2j-base.dll as a dependency? The ogre4j doesnt have that dependency. Do you have the build.xml configuration to wrap ogre4j in the SVN Repository? That would help me configure it without using the cpp2j-base.dll
Thanks
> Is there a way to include the wrapped Code from ogre4j as a base to wrap plugins/addons?
No, this is not possible :(
> The ogre4j doesnt have that dependency.
Both are compiled into one library.
> That would help me configure it without using the cpp2j-base.dll
We just copied the cpp2j-base sources into the ogre4j source tree.
> Do you have the build.xml configuration to wrap ogre4j in the SVN Repository?
There is XBiG/tests/Ogre3D but I cannot remember if this one was used to generate ogre4j.
Two more config files to consider:
- XBiG/src/xsl/config.xml
- XBiG/src/xsl/cpp2j/ignore_list.xml
ignore_list.xml is the one used for ogre4j and in XBiG/src/xsl/ is a file called config.xml.ogre4j which was used for ogre4j.
I am very near to get it working without rebuilding the complete Ogre sources. First I used the meta.xml from the from the ogre sources ( ogre4j ) and included it to the externalType list ( like the STL ). Then I made a new config.xml for ogre4j dependant plugins. When the plugin gets wrapped ( meta2java ), the generated java classes contain the correct references to the Ogre4j stuff. The only anoying behaivor is that even the externalTypes get builded as java classes, what its not needed because they could be supplied by external jars. As a dirty workaround I can cancel the build process after its finished building the proper plugin classes.
Sadly I probably discovered a bug that happens wrapping PagedGeometry. When the namespace and the classname are the same, the meta2java process does not resolve the correct classname and leaves the C++ type in the Java Class ( like PagedGeometry::PagedGeometry::method() )
Can you point me to the right direction, because I am new to the XSLT stuff ;)
So far I am very happy how XBIG works, its very powerfull and intuitive wrapper.
I found out that the "Bug?" only happens when used as templates for the STL classes.
like:
"org.std.Ivector< PagedGeometry::PagedGeometry::BatchedGeometry::SubBatch::QueuedMesh >"
Hope that this is helpfull.
How does your config look like? What is PagedGeometry::PagedGeometry::BatchedGeometry::SubBatch::QueuedMesh in Java?
And what is it original (class, typedef, ...)?
Does this generally apply to type parameters (i.e. non-STL templates)?
It works i.e. for Ogre::Skeleton::AnimationList
original: typedef std::map<String, Animation*> Ogre::Skeleton::AnimationList
java: public interface IAnimationList extends INativeObject, org.std.Imap< String, org.ogre4j.IAnimation >
Ok now I am more certain that the namespace is the root of the problem. I changed the namespace from PagedGeometry to PageGeo and now it works. Seams that if a class has the same name as the namespace that then its not working right with STL templates.
> How does your config look like?
Nothing special, almost like the one from ogre4j to get the correct package names
> What is PagedGeometry::PagedGeometry::BatchedGeometry::SubBatch::QueuedMesh in Java?
Its an IVector from the STL
> And what is it original (class, typedef, ...)?
typedef std::vector<QueuedMesh>
I am now trying to exclude the externalTypes from the meta2java & meta2cpp tasks.
Your help would be appreciated :)
> I am now trying to exclude the externalTypes
external_types.xml is read during doxygen2meta.xslt at line 246. These types are just copied into meta.xml and meta2java, meta2cpp cannot tell where they are from.
We would need a flag in the copied types which marks them as externalTypes. Then we should have a config option whether code shall be generated for that types.
The simple copy could not be used anymore because that additional flag has to be generated. I would store that flag as an element because it is easier to generate than an attribute.
> The simple copy could not be used anymore because that additional flag has to be generated
I had two other ideas how this could be done but for something as big as ogre4j they might not be useful.
1. Put external types on ignore_list.
2. Write the additional flag into the file from which the types are copied.
> 1. Put external types on ignore_list.
I had the same idea to put them into the ignore list, but i didnt figure it out how i could archieve that.
> 2. Write the additional flag into the file from which the types are copied.
Yes thats a good Idea, but better to use your first suggestion for it, to keep it more simple.
Ive got the wrapped plugin working :), but know must try to find a solution for templates in functions. Stupid that they are an essential part of the plugin...