Re: gengtype improvements for plugins, completed! patch 1/N [declprog]

[Basile Starynkevitch <basile at starynkevitch dot net>]

On Thu, Sep 09, 2010 at 10:23:15AM +0300, Laurynas Biveinis wrote:
> 2010/9/9 Basile Starynkevitch <basile@starynkevitch.net>:
> > On Thu, 9 Sep 2010 09:35:55 +0300
> 
> > In particular, I find strong the requirement of explaining
> > any temporary fix which will be dismantled by the next patch. And such
> > fixes are implied by the requirement of making gengtype still work as
> > before at every piece of the patch set.
> 
> Oh. I might be wrong, but I don't think that's necessary. You have a
> set of patches which are interdependent. I think it is fine for an
> arbitrary subset of these patches to break something as long as the
> end result is OK. Can you point to where you were told to make sure
> that gengtype works as before _at every step_?

In http://gcc.gnu.org/ml/gcc/2010-08/msg00353.html Ian Taylor wrote in
a reply to my questions

>> An ideal sequence of patches is a series of patches which may be applied
>> in order.  At each stage the tree should be buildable.  The patches
>> don't have to be independent--they can be applied in a specific
>> order--but they should each work.

I understood the above paragraph from Ian as requirement that gengtype
should always work at every stage, i.e. _at every step_ to quote
Laurynas. 

Maybe I misunderstood, or took as a requirement what is just an ideal
wish, that is something which is not realistically achievable but just
wanted in a Platonic world which does not exist in GCC.




And believe me, gengtype, even with our patch set, is *very far* from
being ideal. It will remain crappy forever

  because garbage collection is a *global* property of a program, and
  there is still no consensus within the GCC community about it; my
  "purist" view is that the GCC community should require every
  dynamically allocated data to be garbage collected with almost no
  exceptions, and then implement the tools [GC support à la Ggc but
  better, code generators much better than gengtype] to make that
  happen.  But I do know that most people disagree with my disruptive
  & extreme position.  Notice that transition to C++ could help and be
  an incentive for better garbage collection (C++ permit virtual
  functions as marking routines and could wrap nicely local GC-ed
  pointers).  But in general, as long as there is no strong consensus
  on any *global* property of GCC, we won't be able to implement it
  cleanly and robustly.  This is true of every *global* property or
  feature of GCC, e.g. memory management, organization of passes, code
  formatting style, or GCC documentation.
 

Cheers.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***