On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton <ni...@redhat.com> wrote: > Hi Richard, > >>> I was thinking that it would be nice to make plugins a "first-class >>> citizen" in the gcc world by having a proper directory structure and >>> integration into the rest of gcc. > >> I believe plugins are currently a hack due to the lack of a clearly defined >> API to access GCC internals. Unless that is resolved somehow, see various >> half-way finished patch prototypes from two (or three?) years ago treating >> them as "first class" would be a blatant labeling lie. It's at most >> "first class mess". > > One of the goals of this proposal is to help combat this mess by making > plugins > a respected and official part of gcc. Such that, when the plugins fail to > build, > test or install, the problem would be considered a blocker and it would have > to > be fixed before the sources are released. > > At the moment nobody (well almost nobody) cares about > > >> The most obvious "proof" of the broken current state is that plugins are >> broken >> all the time because at make install time we forget to install another >> of the GCC internal headers. The bug is of course that we need those at all. > > Presumably you are talking about the ability to build plugins using an > installed > version of gcc ? This is separate from this proposal which is about building > and > installing plugins at the same time that gcc is built and installed. One > possible > way to address this problem is to state that plugins should not be built > outside of > a gcc build tree. Or at least any plugins that require intimate access to > gcc's > internal headers.
If you build sth as part of GCC then why is it a plugin in the first place? >> I'm still convinced that 99% of all (valid) plugin uses involve only >> introspection or well-defined instrumentation. > > I agree, and I would like to see a move towards officially accepting these > plugins > into gcc's ecosystem. I'd not like to have a "python plugin" but instead a well-defined C API to GCC internals that supports introspection. And then at some point extend it with instrumentation. Heck, such interface should be compiler-agnostic, so a smoke test for the API sanity is to implement it ontop of LLVM as well so you can share introspection plugins. Richard. > Cheers > Nick > >
