This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Treat plugins as first class citizens
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 14 Mar 2017 14:44:38 +0100
- Subject: Re: RFC: Treat plugins as first class citizens
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <CAFiYyc3rFWLP2E+sYRQ_A00ijd76s21npFuHHE1Xp6X=46hKWQ@mail.gmail.com> <email@example.com>
On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton <firstname.lastname@example.org> 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
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.