[GCC-XML] Function bodies
brad.king at kitware.com
Wed Jan 11 09:55:39 EST 2006
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
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.
More information about the gccxml