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....