[GCC-XML] VC mode?
brad.king at kitware.com
Thu Jan 5 20:07:50 EST 2006
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.
More information about the gccxml