[GCC-XML] Function bodies

[Brad King]

Daniel J. Lauk wrote:
> As for 1) I decided do continue on my own work. I'll release them under either 
> BSD or X/MIT license, not sure yet.
> 
> Could anybody help me on 2) and 3), please?

For #2 you have to get ahold of the "tree" pointer to the FUNCTION_DECL 
corresponding to the function being called.  Then call xml_add_node with 
it and you will be returned the node index number as an integer.

> For 3), this is what I did so far:
> *) I already separated parts of xml.c into xml.h -- works fine.
> *) I have my code in separate .c and .h files.
> What I did not succeed at, is:
> *) Modifying any CMake related files, so that my .c file is built and linked 
> to xml.c.
> *) Modifying the frontend so that a flag would indicate, if or if not to dump 
> the functin bodies.
> 
> Could anybody provide help at this? How is this done the right way? After all 

This looks like a good approach, but here are some suggestions.

The "gccxml" executable should not have to be modified 
(GCC_XML/GXFront).  You should just add a "-fxml-body" flag to the GCC 
code next to the "-fxml=" flag.  I'm not sure which you meant by "frontend".

> I hope, my code will make it into gccxml's CVS some day...

There are some potential licensing issues.  In GCC-XML's early days 
there were concerns from the FSF that we were trying to circumvent the 
GPL and use GCC code with a BSD-license style.  If there is enough 
information dumped to fully represent the translation unit and allow a 
compiler to be written that uses GCC-XML's output instead of parsing the 
code then there may be problems.  This amount of information would be 
considered a "linking layer" and then any program reading the output 
would be bound by the GPL since it "links" to the GCC code.  Once I 
explained that the amount of information dumped is no where near enough 
for this kind of "linking layer" the concerns disappeared and I got 
email from Richard Stallman himself giving the project his blessing.

Note also that the time I can spend related to this effort is minimal. 
When Richard Buchmann did his implementation a few years ago I intended 
at the time to integrate his changes.  I never ended up finding the time 
to do it (for which I apologize, Richard) and now xml.c has moved pretty 
far from the version for which his was written so it would take even longer.

In order for your code to be accepted the following criteria must be met:

1.) We must be able to argue that the amount of information still falls 
short of a linking layer.  Otherwise we have to specify that the output 
is "GPLed" if the -fxml-body flag is used.  I'd prefer not to have this 
confusion.

2.) Please look at the DTD/schema generation code integrated into xml.c 
(it is still under development).  Your dump code should be paired with 
equivalent xml_document_* functions.

3.) The code should be formatted and styled similar to that in xml.c.

4.) The style of the output XML should be in the spirit of the current 
format.  Please send me sample input/output along the way and I'll comment.

5.) There should be no code duplication (xml.h sounds good for this).

6.) You must be willing to distribute the code under the same terms as 
xml.c is right now.  This means I will put the Kitware copyright on top 
of the code, but I will leave whatever copyright you want intact under 
it as long as the license is compatible.  This requirement is not meant 
to take credit from you; your name will still appear in the original 
copyright.  I just don't want to increase the complication of the licensing.

Thanks,
-Brad