[GCC-XML] VC mode?

[dave at boost-consulting.com]

brad --

on a plane right now; can you get the attention of Paul Mensonides?  Posting about the pp lib to the boost list shoulld do it.


-----Original Message-----

From:  Brad King <brad.king at kitware.com>
Subj:  Re: [GCC-XML] VC mode?
Date:  Thu Jan 5, 2006 3:07 pm
Size:  2K
To:  "Drumheller, Michael" <michael.drumheller at boeing.com>
cc:  gccxml at gccxml.org, David Abrahams <dave at boost-consulting.com>

Drumheller, Michael wrote:
> I recently sent "Message 2" (below) to c++-sig at python.org and received
> the suggestion in "Message 3" from Dave Abrahams below that I ask the
> GCCXML community about VC compatibility mode.  
> 
> Basically, I seem to be in VC compatibility mode but do know why, or how
> to undo it.
> Can anyone help?

GCC-XML is designed to dump out the interface in a translation unit the 
way a given compiler would see it.  This is needed for wrapper 
generators to make sure the same system library types (like STL) that 
get dumped by GCC-XML are used when compiling the generated code.  In 
order to achieve this the preprocessor simulates the native compiler and 
uses its headers.  This means all the native compiler's preprocessor 
macros must be defined by GCC-XML.

In your case pyste is trying to generate wrappers to be compiled with 
MSVC so it is asking GCC-XML to simulate MSVC.  GCC-XML is trying to 
give pyste a description of the *interface* the way MSVC sees it.  An 
unfortunate side effect of this design is that when preprocessor 
definitions are tested to switch among different *implementations* 
things may break.  Usually the different implementations are intended to 
work-around various parsing inconsistencies/bugs among compilers (this 
is done alot by boost).

Of course GCC-XML is using GCC's parser not MSVC's so the preprocessor 
should really produce the interface as seen by MSVC with an 
implementation parsable by GCC.  This means GCC-XML should really be 
viewed as another compiler when using the preprocessor to implement 
syntax work-arounds.  When I realized this I added to GCC-XML a simple 
feature: the macro __GCCXML__ is defined when the preprocessor runs. 
This gives the user code a chance to distinguish GCC-XML from the native 
compiler being simulated.

Dave, I think the proper fix is to make Boost aware of GCC-XML.  During 
preprocessing boost should choose the GCC alternative for parser 
work-arounds when __GCCXML__ is defined.  Most of the changes would 
probably be in boost/config.  If a specific GCC parser version needs to 
be known for a given work-around it can be identified because __GCCXML__ 
is defined with the GCC-XML version number (encoded as 
major*10000+minor*100+patchlevel).  Each GCC-XML version comes with a 
specific GCC parser version, so a simple mapping is available.

One last detail is that GCC-XML version 0.6 was released before the 
__GCCXML__ feature was added in the development version.  The 
work-around for this is for pyste to add -D__GCCXML__=600 to the command 
line when it invokes gccxml 0.6.

-Brad


--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com