This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC - Refactor tree.h

On 08/21/2013 05:13 PM, Mike Stump wrote:
that should include the tree-core.h file as well as the tree-api.h file.
No…  I don't see a client for tree-api.  Logically, you can segregate them down at the bottom of tree-core.h.

We are then left with this tree-api.h file which will be included from 2 places.. tree.h and gimple.h.   As files are converted to the new gimple form, any functions which use to have 'tree' in the prototype are going to be converted to GimpleType or whatever, and the tree prototype(s) will be removed from tree-api.h.  At that point, the prototype(s) will be put in an appropriate header file, creating one if need be, and included as needed.
One can move them from tree-core.h or to any other home as appropriate.
OK, I see what you are saying, and it makes sense.

I was thinking there would be other uses for the tree-api.h file and didn't want to pollute tree-core.h... for instance, the tree-builder inline functions are going to need to be accessible in files which have been converted as well, but I'll worry about that when I get to it... I will likely create gimple object routines to do the equivalent anyway. And I'll deal with anything else as it arises.

so we would have:
- tree-core.h which has the tree structure's first, then all the prototypes at the end of that file which would have been in tree-api.h In theory, these eventually all find better homes.
- tree.h  which includes tree-core.h, then all the macros and such.

I can live with that, it enables what I need to do and has minimal impact.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]