RE: plugin includes for MELT

["Dave Korn" <dave dot korn at artimi dot com>]

On 27 February 2008 18:26, Basile STARYNKEVITCH wrote:

> I'm trying to understand how other "plugin" related effort deals with
> this. Perhaps nobody really cares, but I tend to believe that any plugin
> effort should install the right *.h files outside of the source or build
> directories, for plugins...
> 
> Of course, I do know that plugin might mean to some people (not to me) a
> stability in the GCC in the internal API level. I don't care about this yet.

  I think you already have the answer.  Usually public plugin-APIs have to go
to great lengths to make the interface completely stable, then the plugins can
be distributed as object files.  On the other hand, you aren't planning on
offering a stable API (and that would be quite difficult considering how
quickly and significantly gcc internals change from version to version), so
there is no advantage in distributing the headers separately from the specific
gcc that they were used to build.

  So, since you are planning to compile the plugin during cc1 execution
anyway, why not just say that

 - plugins are distributed as source
 - the compiler keeps the gcc-private headers in its private libexec include
subdir, thus automatically making the correct headers go along with the
correct version+host+target compiler
 - when cc1 runs, it compiles any plugins needed (possibly caching the
compiled objects in another libexec subdir) and dlopens them.


  Then, as you gain experience with MELT and it becomes clearer to you which
parts of gcc's internal api are stable enough to be exposed, you can gradually
build up to a public, SDK-like header file, which exposes only those details
of the internals that you are either confident enough will not change, or that
you feel would not be too difficult to provide a backward-compatibility shim
layer for if they do change.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....