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