On Tue, Sep 14, 2010 at 15:22, Basile Starynkevitch <bas...@starynkevitch.net> wrote:
> I'm just trying to figure out what are the features in 4.6 which will > be useful to my work. I know that in a couple of weeks, they are frozen > (since 4.6 is ending stage 1). The gengtype patch series No. End of October. > http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01029.html I am trying to > push with Jeremie Salvucci is also almost needed for MELT (and for any > plugin using GTY). I have no idea if it will make into 4.6, because I > still don't understand which *reviewer* is interested by them. If you are trying to install a patch, that makes *you* the interested party. Laurynas has been making great review work for the patches you've posted so far. Although I have not reviewed the patches, I have not heard anything against them. Incidentally, this is an issue I would like to address. We need someone interested in maintaining the GC machinery. Any volunteers? Laurynas? > I really do not understand the philosophy of: work hard for one or two > years making a plugin, and the GCC community will perhaps eventually > consider -and only after the work is completed- adding the tiny hook > which would have saved you 6 months of work. [I am speaking of course > of small hooks which can be incorporated into the trunk by a single > small patch and which have no measurable effect on GCC performance when > not used] You are blowing things out of proportion. You also belong to this community, so do not make it an us-vs-them problem. You started the thread with a hypothetical use case scenario. We clearly we don't want to add these hooks just because they may be useful. It is true that you are perhaps the biggest user of plugins at a time where everything related to internal APIs is in a state of flux. So, you can imagine what the external APIs look like. You *must* expect challenges here. This work that you are doing, must it be based on plugins for a fundamental reason? Given your interest in plugins, why not do the following: 1- Do your work in a branch, adding all the hooks and facilities that you think are needed. 2- Develop the plugin against that branch and solve the API issue in that branch. 3- Keep the rest of the community in the loop. In particular, I am interested in having a working plugin facility. But I *know* that we cannot get to that without solving our API issues. Want to work with me on that? Diego.
