Re: [rfc][00/37] Eliminate builtin_type_ macros

["Ulrich Weigand" <uweigand@de.ibm.com>]

Mark Kettenis wrote:

> > As to *testing*, I agree that having to apply 37 patches in sequence
> > is a pain, which is why I sent -in addition to the broken-out series-
> > a single cumulative patch as well.
> 
> Yes, that was a good thing to do.  I apologize for sending the message
> I sent yesterday evening before reading all my mail.

No problem -- I appreciate the feedback.

> > In the end, this is simply a large set of changes (the cumulative patch
> > is 8000 lines, the broken-out patches total 10000 lines) spread out
> > across many parts of GDB (the patch set touches 97 files) -- if you have
> > suggestions how to present a change like this in a way that's easier to
> > review, those would certainly be welcome.
> 
> I don't think there is much you can do about it.  A large set of
> fairly mechanical changes is simply a large set of mechanical changes.
> It's probably good if people have a look at part of the diff, but in
> the end we'll just have to trust that the job was done properly and
> that it gets committed (preferably after people have tested it).

The thing is, parts of the patch set (e.g. the -tdep.c changes) are
indeed completely mechanical changes.  However, in other places I am
making definite design choices (e.g. should an expression really be
something architecture-neutral, or explicitly platform-specific?).

One important reason for splitting the patch set up is in fact to
avoid such design choices being swamped and overlooked within a
single large, mostly mechanical patch ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com