There's a reply to esr by Alexandre Oliva which touches this point. I'll quote what he says:
"That GCC plugin interface is not sufficiently stable for major uncoordinated developments by third-parties is just as true as that Linux's module interface is constantly changing, and complaints about its lack of stability in it are often responded with such phrases as contribute your driver and we'll even help you keep it up-to-date".
I don't know about the subject but it seems a quite reasonable stand and it certainly doesn't hinder the Linux kernel development, I don't see why it wouldn't work in GCC.
I believe he is talking about different kind of plugins. For example, suppose you are an editor and you want to syntax highlight c source code. You could then feed .c files to clang, get back a parsed ast and use that for awesome syntax highlighting.
You can not do that with gcc and the fsf does explicitly not want you to be able to. Because you could then be writing a non-free editor to take advantage of and using gcc as a free front-end.
Oh, I think you are right, esr was talking about using GCC as a plugin and I understood plugins for GCC. Apparently Alexandre Oliva and many of us made the same mistake.
Considering that, I mostly agree with David Kastrup; it doesn't make sense for the FSF to bend its principles and help propietary software in order to get market-share. But, unfortunately, it's also affecting FOSS developers.
Yup, there are many, many times when I want to be able to do simple things with C or C++ code. Writing a little static analyzer tool that can check some internal code for a practice we have found harmful, parse some headers to automatically generate python bindings, documentation stubs, generate really good unit tests stubs with the information the ast give you, grab all of the comments and run your own verification on them, automagically re-write code to not use an old api anymore. And this is all just with using the source parser side of things of llvm
These are the tools I write, they are not big commercial enterprises, most of them are one off projects that are used and tossed away within a year, very few are ever published. Clang makes me more productive because they give me the ability flat out do this type of thing. It doesn't matter what GNU political agenda is, their tool flat out doesn't let me do this like llvm can. As long as this is the case long term I will use llvm more and more over gcc.
"That GCC plugin interface is not sufficiently stable for major uncoordinated developments by third-parties is just as true as that Linux's module interface is constantly changing, and complaints about its lack of stability in it are often responded with such phrases as contribute your driver and we'll even help you keep it up-to-date".
I don't know about the subject but it seems a quite reasonable stand and it certainly doesn't hinder the Linux kernel development, I don't see why it wouldn't work in GCC.