I don't disagree with your comments too, Manuel. I spent some years developing plugin framework for pass selection and reordering, and later we managed to get minimal hooks to mainline GCC based on our needs. Of course, I personally would like to see a coherent and stable API for most of the parts of GCC, but as you said it will not happen itself. Still I believe that through gradual API-zation of different parts of GCC, there will be an eventual convergence to the global and stable API ...
Cheers, Grigori -----Original Message----- From: ctuning-discussi...@googlegroups.com [mailto:ctuning-discussi...@googlegroups.com] On Behalf Of Manuel Lopez-Ibanez Sent: Tuesday, July 06, 2010 6:42 PM To: Grigori Fursin Cc: ctuning-discussi...@googlegroups.com; Joern Rennecke; David Brown; gcc@gcc.gnu.org Subject: Re: Plug-ins on Windows On 6 July 2010 17:54, Grigori Fursin <gfur...@gmail.com> wrote: >>I view the current plug-in mechanism as a prototype. I think that we >>should be working toward a much more robust mechanism, similar to >>plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks. >>I certainly see no reason that plug-ins cannot work on any system that >>has something roughly equivalent to dlopen (which Windows and OS X >>certainly do). There's lots of prior art here. >> >>The key change we need to make is that instead of the current >>"unstructured" approach where we essentially expose the entirety of the >>GCC internals, we provide a stable, documented API that exposes a >>portion of the internals. (It's fine with me if there's an expert mode >>in which you can do anything you want, but it should be easy to stay >>within the stable API if you want to do that.) I would start with an >>API for "observing" (rather than modifying) the internal representation, >> and add modification later. "We need to make"? Are there any plans (or even interest) on designing such an API in the future? My understanding is that we hope an API will slowly arise from the requirements of external tools. So plugins' authors should not wait for such an API but instead start proposing it, ideally, with patches. >>With observation alone, you could start to build interesting >>static-checking tools, including, for example, domain-specific tools >>that could check requirements of the Linux kernel. This would be a >>powerful and exciting feature to have in GCC. > > Agree with this vision, but it will take some time I guess ;) ... I don't think it requires time. It requires people asking for it and working on it. Current GCC developers do not need this and they will not work on this (as far as I know), so no one should be waiting for such tools to magically appear. However, now that the plugins framework is in-place, anyone is welcome to not only develop such tools but to propose changes that make developing such tools easier. The plugins framework is a statement of the willingness of the GCC community, despite the initial opposition from the FSF, to open the project to external contributions and usages. GCC internals have been (and are still being) renovated, and there is ongoing work to make GCC more modular. However, if there is no one proposing the particular changes required by external usages, those changes won't be made. This is also a warning against working around and second-guessing GCC. Please, don't. Instead contribute the changes (API, code, and documentation) required to make GCC more open and easier to use. I know that this is the hardest route, but it is the only one that makes us progress. Cheers, Manuel. -- You received this message because you are subscribed to the Google Groups "ctuning-discussions" group. To post to this group, send email to ctuning-discussi...@googlegroups.com. To unsubscribe from this group, send email to ctuning-discussions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/ctuning-discussions?hl=en.
