[Bf-committers] Linux Users: Questions about build support needs

[Hans Lambermont]

Brecht Van Lommel wrote:

> Hans Lambermont wrote:
> >I then stripped BL_BlenderDataConversion.cpp down to the bare minimum.
> >It then needs only 2 header file include lines :
> >
> >    #include "BL_BlenderDataConversion.h"
> >    #include "RAS_IPolygonMaterial.h"
> >
> >The first two resulting errors are :
> >
> >    /usr/include/c++/3.4/bits/localefwd.h:58:34: macro "isspace" passed 2 
> >    arguments, but takes just 1
> >    /usr/include/c++/3.4/bits/localefwd.h:58: error: `std::isspace' 
> >    declared as an `inline' variable
> 
> These two game engine headers includes other headers that include 
> various c and c++ headers, so probably ctype.h that defines an isspace 
> macro, is included somewhere before a c++ header defining an isspace 
> inline function.

Yes, that's what Kester wrote.

> A solution (as already posted in april 2005) is to #undef the isspace 
> macro. But with all these nested includes it's hard to get a good 
> overview of what is included when, so maybe you could try putting this 
> at the top of the c++ file that has the compile error:
> 
> #include <ctype.h>
> #undef isspace
> 
> ctype.h won't be included again because of the #ifndef _CTYPE_H_ / 
> #define _CTYPE_H_ stuff, so hopefully the isspace macro then won't be 
> defined again either.

I don't consider this a fix. I think we stumbled into a problem that
should not be fixed inside blender (by undef-ing stuff). Unless we can
avoid including one of the lower level header file culprits altogether
as Erwin suggested.

Thanks for digging into this, what do you think of either pinpointing
this inside Python's include files, or trying to avoid including a
problematic header file ?

Hans