Build problem under MSVC

[GoogleCodeExporter]

What steps will reproduce the problem?
1. build the osg wrapped lib
2.
3.

What is the expected output? What do you see instead?

the compile phase of the generated 
bail out with:

 fatal error C1128: object file format limit exceeded : more than 65,279
sections

What version of the product are you using? On what operating system?

svn trunk 169, osg 2.6 windows XP, VisualStudio 2003 v 7.1.3088

Please provide any additional information below.

The compilation phase of osg takes forever, with many warnings 
(one new warning is " warning C4101: 'e' : unreferenced local variable"
cause by generated expression Swig::DirectorException &e)

Really not knowing how to resolve: either grab previous svn or find a way
to slit the osg wrap process into smaller pieces: osgPYTHON_wrap.cxx has
grow up to 330000 lines 

Original issue reported on code.google.com by luigi.ca...@gmail.com on 1 Oct 2008 at 3:52

[GoogleCodeExporter]

Yes, this is going to be major brain surgery, I need to unwind all the wrappers 
into
separate interface files.

Original comment by hartmut on 8 Oct 2008 at 12:29

[GoogleCodeExporter]

Uh... brain surgery usually dangerous... do you foresee a workaround?
Can we haelp in some way?
This sound as a major rewrite, are you going to branch the project to allow to 
have a
"stable" branch and a main trunk?

We are developing a post-processing tool form max-exported models on osgswig, 
(http://code.google.com/p/virtualrome/source/browse/trunk/py_code/py25_apps/code
/VirtualRome)
We can either freeze osgswig version to the latest working and eventually keep 
some
local patches.
A better approach for us would be to use a stable fork for our application and 
from
time to time to test the head trunk

Original comment by luigi.ca...@gmail.com on 8 Oct 2008 at 2:41

[GoogleCodeExporter]

With major brain surgery I mean that I might use static interface wrapper files
individual for each header. This way I think osgSWIG can be better maintained 
and is
probably easier to debug as well. But as you can imagine this is nothing easy 
done. 

I will try to fix osgSWIG to get a "stable" release for 2.6 and then bit by bit
convert over to a new wrapping scheme.

Another group in our lab now also uses osgSWIG and they might can spare a 
student to
help with this. But any additional pairs of hands and eyes are welcome.

Original comment by hartmut on 9 Oct 2008 at 1:14

[GoogleCodeExporter]

Ok, great to know, as far as I know this is the only actively mantained wrapper 
for
OSG and I think that interpreted access is key component in getting accptance: 
(look
at Ogre python wripping). A sound wrapper feature seems to me a real miss for 
OSG
If you can give me some hints on how to try to solve current build problem, it' 
ll
really help us, otherwise I have to stick to old code.
If you have some example of the foreseen future wrapper, let me know, I can 
test it
and try to extend, I' m not at all a C++ or python guru but can help on cmake 
side, a
colleague of mine is much better in C++ and python. 

Original comment by luigi.ca...@gmail.com on 9 Oct 2008 at 10:35

[GoogleCodeExporter]

Hi Luigi,

as a workaround you might want to disable the Director exceptions in, meaning 
the 
code below in osg.i. You do not need it for day-to-day use, it makes code a 
little
slower, but it is essential in tracing bugs in your python->C++->python director
callback constructions. Perhaps we can introduce a build FLAG to disable this 
by default.

%include exception.i       

// Macros to insert file and line debugging prints into swig-generated C++ 
wrappers
#define SWIG__FILE__ __FILE__
#define SWIG__LINE__ __LINE__

%exception {
    try {
        $action
    } catch (Swig::DirectorException &e) {
    printf("Caught Swig::DirectorException(%s)\n", e.getMessage());
    printf(" [file %s, line %d] in $decl \n", SWIG__FILE__, SWIG__LINE__ );
    SWIG_exception(SWIG_RuntimeError,"Director Exception");
    } catch(...) {
    printf("Caught Unknown exception\n");
    printf(" [file %s, line %d] in $fulldecl \n",  SWIG__FILE__, SWIG__LINE__);
        SWIG_exception(SWIG_RuntimeError,"Unknown exception");
    }
}

// director exceptions

%feature("director:except") {
    if ($error != NULL) 
    {
    printf("Throw Swig::DirectorMethodException [file %s, line %d]\n", SWIG__FILE__,
SWIG__LINE__);
        throw Swig::DirectorMethodException("osg_i_DirectorMethodException");
    }
}

Original comment by gerwinde...@gmail.com on 14 Oct 2008 at 12:17

[GoogleCodeExporter]

On VS 2005, the message is "[...]\osgpython_wrap.cxx(54270) : fatal error C1128:
number of sections exceeded object file format limit : compile with /bigobj".

When I manually added /bigobj to CMAKE_CXX_FLAGS, the project compiled.  Could 
you
add the flag in the appropriate cmake file?  I haven't tried the output yet, 
but I
expect it to work.  Could you at least add /bigobj to CMAKE_CXX_FLAGS for 
Visual Studio?

Original comment by randolph...@gmail.com on 25 Nov 2008 at 6:17

[GoogleCodeExporter]

Additional note: /bigobj only works on VS 2005 and later.  I think limiting VS 
build
support to VS 2005 and later is reasonable, YMMV.

MS's page on /bigobj is at:   
  http://msdn.microsoft.com/en-us/library/ms173499(VS.80).aspx

Original comment by randolph...@gmail.com on 25 Nov 2008 at 6:20

[GoogleCodeExporter]

We decided only to support Python 2.6 for the time being on the Windows 
platform.
Python 2.6 and later use Visual Studio 2008. We need to do more cleanup to 
avoid more
warnings and refactor things into seperate interface files. However, there is 
the
question if we really use SWIG for that purpose.

Original comment by hartmut on 12 Jan 2009 at 12:09

• Changed state: Started

[GoogleCodeExporter]

It turns out that numpy (and, therefore, scipy) isn't supported on Windows 
Python
2.6.  This is a pretty big deal; pyOpenGL uses numpy, so I'm not going to be
abandoning Python 2.5 anytime soon.

Original comment by randolph...@gmail.com on 12 Jan 2009 at 5:33

[GoogleCodeExporter]

Is it possibly for you to maintain a Python 2.5 version on Windows also, or
are the fundamental difficulties with building the wrappers for that version?  
As Randolph points out, Python 2.5 is still so widely used on Windows, that
forcing people to upgrade to 2.6 can be problematic. 

At least for my employer, it is not currently an option (under Windows).

Original comment by dahl.joa...@gmail.com on 16 Apr 2009 at 10:00