Compiling against Ogre CVS?

Would one expect problems compiling PyOgre against Ogre CVS (dagon)? I am using Ogre CVS for the recent "off-axis projection" patches to the camera code. These are necessary for doing correct stereo rendering ...

Yes, there should be problems with this. I have not updated pyogre to the dagon branch. That usually doesn't take more than a few hours of work, but it really depends on how much they have changed in the codebase.

I wasn't planning on updating to dagon yet. 1.0.6 is supposed to be released around the 20th, and dagon is a ways off.

I don't mind starting the branch early, but things are now stacking up on my todo list. =)

Surprisingly not that many errors. Although I guess this is only showing methods/functions that have been removed from the API. It doesn't indicate new methods/functions which aren't described in the swig interface files.

Would it not be preferable to have the PyOgre subversion trunk tracking the Ogre CVS head? That and a separate branch for the current stable Ogre release? Or is Dagon so far out in front as to be unusable? (Rhetorical really - the demos all seem to work.)

Here's SVN PyOgre compiling against CVS Ogre using Visual Studio .NET 2003.

Compiling...
ogre_wrap.cxx
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(192) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(2084) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(4999) : error C2440: 'type cast' : cannot convert from 'const Ogre::TextureUnitState::UVWAddressingMode' to 'Ogre::TextureUnitState::TextureAddressingMode'
No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5201) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5235) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5265) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5464) : error C2039: 'getStandardProjectionMatrix' : is not a member of 'Ogre::Frustum'
c:\Packages\ogrenew\OgreMain\include\OgreFrustum.h(61) : see declaration of 'Ogre::Frustum'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5523) : error C2039: 'setAnimationName' : is not a member of 'Ogre::AnimationState'
c:\Packages\ogrenew\OgreMain\include\OgreAnimationState.h(46) : see declaration of 'Ogre::AnimationState'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5531) : error C2039: 'setValue' : is not a member of 'Ogre::AnimationState'
c:\Packages\ogrenew\OgreMain\include\OgreAnimationState.h(46) : see declaration of 'Ogre::AnimationState'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5532) : error C2039: 'getValue' : is not a member of 'Ogre::AnimationState'
c:\Packages\ogrenew\OgreMain\include\OgreAnimationState.h(46) : see declaration of 'Ogre::AnimationState'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5540) : error C2039: 'setUseShortestRotationPath' : is not a member of 'Ogre::AnimationTrack'
c:\Packages\ogrenew\OgreMain\include\OgreAnimationTrack.h(57) : see declaration of 'Ogre::AnimationTrack'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5541) : error C2039: 'getUseShortestRotationPath' : is not a member of 'Ogre::AnimationTrack'
c:\Packages\ogrenew\OgreMain\include\OgreAnimationTrack.h(57) : see declaration of 'Ogre::AnimationTrack'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5542) : error C2039: 'setAssociatedNode' : is not a member of 'Ogre::AnimationTrack'
c:\Packages\ogrenew\OgreMain\include\OgreAnimationTrack.h(57) : see declaration of 'Ogre::AnimationTrack'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5543) : error C2039: 'getAssociatedNode' : is not a member of 'Ogre::AnimationTrack'
c:\Packages\ogrenew\OgreMain\include\OgreAnimationTrack.h(57) : see declaration of 'Ogre::AnimationTrack'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5549) : error C2039: 'setTranslate' : is not a member of 'Ogre::KeyFrame'
c:\Packages\ogrenew\OgreMain\include\OgreKeyFrame.h(47) : see declaration of 'Ogre::KeyFrame'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5550) : error C2039: 'getTranslate' : is not a member of 'Ogre::KeyFrame'
c:\Packages\ogrenew\OgreMain\include\OgreKeyFrame.h(47) : see declaration of 'Ogre::KeyFrame'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5551) : error C2039: 'setScale' : is not a member of 'Ogre::KeyFrame'
c:\Packages\ogrenew\OgreMain\include\OgreKeyFrame.h(47) : see declaration of 'Ogre::KeyFrame'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5552) : error C2039: 'getScale' : is not a member of 'Ogre::KeyFrame'
c:\Packages\ogrenew\OgreMain\include\OgreKeyFrame.h(47) : see declaration of 'Ogre::KeyFrame'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5553) : error C2039: 'setRotation' : is not a member of 'Ogre::KeyFrame'
c:\Packages\ogrenew\OgreMain\include\OgreKeyFrame.h(47) : see declaration of 'Ogre::KeyFrame'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5554) : error C2039: 'getRotation' : is not a member of 'Ogre::KeyFrame'
c:\Packages\ogrenew\OgreMain\include\OgreKeyFrame.h(47) : see declaration of 'Ogre::KeyFrame'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5661) : error C2039: 'isHardwareSkinningEnabled' : is not a member of 'Ogre::Entity'
c:\Packages\ogrenew\OgreMain\include\OgreEntity.h(71) : see declaration of 'Ogre::Entity'
c:\Packages\pyogre\pyogre\ogre\ogre_wrap.cxx(5935) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data
c:\Packages\ogrenew\OgreMain\include\OgrePredefinedControllers.h(158) : fatal error C1903: unable to recover from previous error(s); stopping compilation

Would it not be preferable to have the PyOgre subversion trunk tracking the Ogre CVS head? That and a separate branch for the current stable Ogre release? Or is Dagon so far out in front as to be unusable? (Rhetorical really - the demos all seem to work.)
Eventually that may be the case. Right now I'm trying to get hardware buffers working (currently in a branch of its own) before I branch off dagon.

Keeping up-to-date with the head of the development version of Ogre is time consuming work. The initial version is not hard, but all of the cvs update, build, migrate deps, build/fix cycle starts to be a lot of work, especially when theres a lot of work left to be done on the library.

We usually start this a few weeks before dagon is released (thankfully sinbad informs the MVPs early).

As I said earlier, I don't mind starting the Dagon branch early. However it's going to have to wait until I have HardwareBuffers in some symbollance of working. If you are dying to get it going I'll allways accept a patch to start a working dagon branch, but I need to do this one thing at a time or nothing will get done.

Other than futnuh's special case needs, IMHO it's going to be better to get the 1.0.5 PyOgre very solid rather than chasing a moving target just to have all the latest features available. I'd much rather see a mature and complete PyOgre than one that is not feature complete but compiles against CVS OGRE.

$.02

Even I agree fully I'll look at applying the off-axis projection patch to the upcoming release version of Ogre and then what minor changes (if any) this requires to PyOgre.

This illustrates one of the main "problems" with hand crafting bindings, namely, trying to keep them up to date. Having introspection built into the scenegraph would make life so much easier. Imagine, for example, being able to query the scenegraph about all of its functions, enumerations and classes. And for each class being able to programmatically discern methods, call signatures, allowed values for parameters, etc. Writing bindings for any language becomes easy. And the bindings are 100% in tune with the library, as well as lightweight (can be determined at run-time). Introspection also makes it easy to write sceregraph editors, serialize objects for network transport or persistent storage, and more.

If you look at the OpenSG scenegraph (http://www.opensg.org/), the introspection infrastructure is built-in. It's probably too late though for Ogre to adopt this ...

I really should clarify what I said earlier.

Other than futnuh's special case needs, IMHO it's going to be better to get the 1.0.5 PyOgre very solid rather than chasing a moving target just to have all the latest features available. I'd much rather see a mature and complete PyOgre than one that is not feature complete but compiles against CVS OGRE.

$.02
I completely agree. The HardwareBuffer (and related classes) are very neccissary for a 3D engine, and they were on the todo list for 1.0.* anyway. This is just a nice kick in the rear to get me started on it.

I have mixed feelings on dagon. I do want pyogre to compile against the most recent Ogre head. This was a goal for me at the beginning (to have Ogre head in the trunk, the current stable branch in a branch). I wasn't planning on starting this until I marked PyOgre as "stable", which I'm pretty close to doing.

The real question is how soon to do it and when to update it. My general idea is to start sooner than later so I have all of the kinks worked out of the system when it becomes difficult to use it. I am also planning on only making dagon compilable, and NOT adding any of the new features/classes that it adds. After making it compilable, anyone who wishes to use it is free to do so (and submit patches against it), but I would not be wrapping any new functionality/classes until a few weeks before a new version's release.

So now you know the master plan. Making dagon compilable should only take 3-4 hours, and doing so was a design goal of mine anyway. I'm open to suggestions, comments, what-have-you.

Edit: And yes, it's way too late for Ogre to do anything like that. I can't even convince Sinbad to turn on RTTI in the Windows build to help out, even though I've shown it to have absolutely no impact on the library outside of filesize. The chances of adding something like that would be impossible to get past the talk stage.