Re: plugins header file

[David Malcolm <dmalcolm at redhat dot com>]

On Tue, 2014-10-14 at 15:40 -0400, Andrew MacLeod wrote:
> 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?
> >
> >
> >  Andrew
> 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 
> includes:
> #include "config.h"
> #include "system.h"
> #include "coretypes.h"
> #include "highlev-plugin-common.h"
> #include "hashtab.h"
> 
> 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...

That sounds reasonable to me.

> Otherwise I'm just going ahead shortly with the flattening patch as is, 
> and we can deal with any fallout the same way as last year.  my 
> intention/hope is to get cgraph.h and basic-block.h flattened as well.

Have you tried rebuilding some non-trivial plugins with the proposed
change?
e.g. my gcc-python-plugin:
  https://fedorahosted.org/gcc-python-plugin/

It supports gcc 4.6 - 4.9, via an increasingly "fun" set of preprocessor
hackery and compat functions.   At this point I'm kind of resigned to
the fact that every 4.n release of gcc is going to require compat
changes within my plugin, but I suspect that your "include everything
from gcc-plugin.h, in the right order" approach is a good one, in-so-far
as it saves every plugin author from having to independently figure out
what order to include the headers in.

Richi suggested to me at Cauldron that maybe I could generalize the JIT
API to *also* be a plugin API (i.e. one with some kind of useful API and
ABI guarantees) [1], and I think that might be do-able based on some
experiments I've now done - though the close of stage1 is beginning to
loom...

Hope this is helpful
Dave

[1] at a first approximation, this is 
  sed "s/gcc_jit_/gcc_/g"
to the public header libgccjit.h (renaming it to e.g. gcc-api.h or
somesuch), plus various new accessor and iterator entrypoints.   The
underlying implementation of the methods of gcc_jit_context become
virtualized, so we get different implementation for a jit context vs a
plugin context.  GC/GTY is hidden from the client code; we don't want to
inflict that on casual developers.