PyOgre 1.2 on VS 7.1

ogre_wrap.cxx is so large now that in order to get VS 7.1 to compile it without a "fatal error C1128: object file format limit exceeded"
I will need to write some sort of script to split the file.

So I need to know if people require VS 7.1 support, before I start to create a workaround that possibly no one will use.

You could always just add a flag for the compiler to up the amount supported.

VS 8 has a flag /bigobj but I can't find anything similar in the VS 7.1 documentation. If I am missing something, please point me in the right direction.

I use 7.1 and ran into that error before, this was a year ago though. I am pretty sure I did not break up the files but rather just added a flag, don't recall what it is and don't have that project around anymore. I will look through MSDN when I get home tonight and look around again if you don't find it before then.

I use 7.1 and ran into that error before, this was a year ago though. I am pretty sure I did not break up the files but rather just added a flag, don't recall what it is and don't have that project around anymore. I will look through MSDN when I get home tonight and look around again if you don't find it before then.

I think you want to take a look on next article:
http://support.microsoft.com/default.as ... -us;883655

It might be a pain, but supporting VC++ 2003 may be necessary. Both the old and new Python releases are based on it.

http://mail.python.org/pipermail/python ... 46834.html

Otherwise, Python 2.4 and 2.5 won't run PyOgre out of the box without a few extra DLLs. Getting this to work smoothly on a standard machine without VC++ 2005 could be equally hard...

Why not configure SWIG in a way that generates manageable files?

Alex

I am really trying to make that work. But the way pyOgre is set up seems to make it difficult to split it into smaller units.

There are interdependencies between different classes and interface files that are difficult to determine except by trial and error.
I have made numerous attempts to split pyOgre, but always end up chasing some obscure bugs.

And the limited free time that I do have to work on pyOgre makes this all the more difficult.
But I think that this is a priority issue, since doing the monolithic build for every tiny change is extremely time consuming.

I would love any help/insight/pointers that people are willing to give.

I have to confess I don't know much about SWIG, but I'll look into the generated C code to see if there's anything that can be done...

Alex

Perhaps something like this can be done in SWIG, but this is how it can be done in boost::python, using pseudo-classes:


#import <theusual.h>

BOOST_PYTHON_EXPORT(_Ogre)
{
using namespace boost::python;

class_<Quaternion> clsQuat("Quaternion");
clsQuat
.def(self+self)
.def(etc...)
;

class_<Vector3>("Vector3")
.def(self+self)
.def(self-self)
.def("dot", &Vector3::dot)
.def(self*Quaternion)
.def(etc...)
;

clsQuat
.def(self+Vector3)
.def(etc...)
;
}


And of course, to split it up you can just make a base function that defines a ton of classes at a global scope accessible elsewhere using external, and *just* declare them using """g_clsQuaternion = class_<Quaternion>("Quaternion");""" then call other function defined in other files to build them up so it does not overwhelm smaller compilers.

And as stated above, with VC7.1 you can add a switch to up the limit.

And as stated above, with VC7.1 you can add a switch to up the limit.

You're thinking of VC8.0, the 2005 edition. It definitely does not work with 2003...


Wrt to the dependencies problem, I think this is a symptom of the lack of layering in Ogre itself.

From what I can tell so far, maybe the easiest is to have one big .H file (maybe even a .PCH), but have the implementation of the classes in separate .C files that generate small .obj.

Alex

You're thinking of VC8.0, the 2005 edition. It definitely does not work with 2003...
I'm pretty sure I've done it in VC7.1 as well when I started out writing that type of code...


From what I can tell so far, maybe the easiest is to have one big .H file (maybe even a .PCH), but have the implementation of the classes in separate .C files that generate small .obj.
That is exactly what I do, have a single header for those things that contain one master function signiture and many other function signiture's. Each function is then implemented in it's own cpp file, with the master function calling them all in turn. I will also toss in the odd extern to hold a class definition longer so a function in a different file can use the definition.

@Istari:
If your still planning on splitting pyOgre into smaller units why not create a separate temp branch with what you've done so far, say dev-1.2.0-split. This will allow other people to work on this. I for one will.

I have created the branch dev-1.2.0-split
It does not currently compile.
It's possible that the interface files should be organised differently into the different modules.
It seems that classes that use dynamic cast need to be in the same module.

Module interface files are named ogre_split_*.i
I have only modified the scons build scripts, so using any other method will not do anything useful.

Ok thanks, I had an initial stab at this. I submitted a patch with the changes I made. It compiles and runs a simple demo, though there is still a lot of work to be done.