This is the mail archive of the
mailing list for the GCC project.
Re: plugins header file
- From: Jeff Law <law at redhat dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Tue, 14 Oct 2014 21:57:58 -0600
- Subject: Re: plugins header file
- Authentication-results: sourceware.org; auth=none
- References: <54172D7D dot 80908 at redhat dot com> <543D7C17 dot 5000906 at redhat dot com>
On 10/14/14 13:40, Andrew MacLeod wrote:
I don't see either being particular better than the other. So, whatever
seems to be easiest is fine with me. But then again, I've never written
a plugin. Perhaps ask David directly -- he may miss this thread, but I
wouldn't be surprised if he can give some relevant advice.
On 09/15/2014 02:18 PM, Andrew MacLeod wrote:
During the re-architecture session at Cauldron, I mentioned the
possibility of introducing a plugin-headers.h.
This would be a file which plugins could use which would protect them
somewhat from header file restructuring. The idea is that it includes
all the common things plugins need, (like gimple.h, rtl.h,
most-of-the-world.h, etc etc),. When header files are restructured,
that file would also be adjusted so that the correct include order is
still maintained. This could also give plugins a little more
stability across releases since header files do come and go..
I am about to start another round of flattening and shuffling, so
figured this might be a good time to introduce it. Any of you plugin
users have a list of includes you want to see in it, or better yet,
provide me with a plugin-headers.h? ( Out of curiosity, is there a
reason gcc-plugins.h doesn't include a pile of these common things? or
is that simply to avoid bringing in the world?) Or would you rather
just continue to deal with the pain of header file name
changing/content shuffling? or is there a different solution proposal?
Not a lot of response... just one...
so I'll ask a different question before I check in the function.h
flattening patch which has been approved...
Rather than a new file, is there any reason not to include most of the
gcc world that we care might about in the current gcc-plugin.h file? it
so I presume most plugins include this file. if we added a set of
includes to this (even just the minimal required to compile the file
being flattened) , flattening might be transparent to most plugins...