Re: XML output from GCC

["Artem Khodush" <kaa at comail dot ru>]

Brad King wrote:


> A couple weeks ago, I posted to the list the idea of adding support to g++
> to write out information about a program in XML.  I got several positive
> responses, so I decided to look further into the idea.
> 
> Last Thursday I finally got a chance to start on a full implementation
> of the XML output addition to g++.  I've made quite a bit of progress,
> and would like to get some feedback.
> 

Having g++ to produce xml program representation is great. It is good
to see some actual progress along the way.

> 
> I also thought about Artem's suggestion of making this a separate
> front-end, but unfortunately that would require maintenance of a
> separate parser.  By making it part of g++, we get all the template
> specialization and instantiation (along with other nasty things) done
> for us.  

Perhaps I was not clear enough. I was thinking of re-packaging parts of g++ 
(essentially, the parser) into just another one executable, built in the separate
subdirectory parallel to cp, along with some glue code. I was not proposing 
making a separate parser. And it was the estimated size of that glue
code, which has nothing to do with main g++ task - compiling c++, that 
made me think of separate front-end.

> Perhaps instead someone could write a new back-end that
> generates language-independent cross references instead of executable
> code?  I can't imagine right now how it would be done, but who knows?

AFAIK, not all front-ends use gcc tree structures in the designed way, 
suitable for cross-referencing. To me, language-indepentent cross 
referencing seems too far fetching, and besides, it seems that only c++ 
users (and only very few of them :) are lacking good cross-referencing tool.
 
>I'd like to split up the output by namespace
> and class into multiple files (and one index file).  This way if the
> same class is parsed across many translation units, it only has to be
> output once (like istream).
> 

Then you will need to do some make-like timestamp checking to be
sure that already compiled xml file is up to date, and this may be not
enough, because the same file containing the same class can be
compiled twice with different #define settings, producing slightly different
implementations, used in different executables.

> 
> A bit of help, please:
> 
> I'm working with the 2.95.2 source distribution, but have successfully
> run it with a 2.96 snapshot.  There seems to be a problem with some
> function declarations in the 2.95.2 version.
> 
> I just get an empty global namespace as output.  

If I recall correctly, in 2.95 the back-end is called for code generation at the end of
each complete statement, and then the tree is discarded. For 2.96, and currently 
for c++ only, conversion was done to process the tree for a function at once.
This may account for your problems with 2.95. Anyway, I see no point in
making the code to work in 2.95, since that version is not being developed
any more, and for the tools in question (browsers, etc.) the differences in c++
language accepted by 2.95 and 2.96 are negligible, i think. 

> Also, the DECL_SOURCE_LINE for the name of a class results in the line
> of the end of the definition ("};").  

The preprocessor (at least cpplib one) has line and column numbers for each
c++ token. I don't know for sure, but it seems that the only way to get at this 
information after the tree is constructed is to modify tree-building code.

Best regards,
Artem.