Re: Will therefore GDB utilize C++ or not?

[Matt Rice <ratmice at gmail dot com>]

On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi <yao@codesourcery.com> wrote:
> On 12/07/2012 04:39 AM, Matt Rice wrote:
>>
>>    If anyone has any particularly large change to an existing source
>> file, and they'd prefer I postpone work on that file until later
>> please let me know, it might save work for one of us or the other.
>
>
> I have a not-small patch series 'rsp async notification' being reviewed
> recently and hopefully give new version V4 next Monday.  I don't want to
> postpone your work.

k

>  How do you change the source tree?

I create a git branch for each type of error message which gets
rebased, write some scripts to create a merge branch to test
compilation and run testsuite, and a branch where self-conflicts go
which contains the lines which are covered by more than one error type.

this allows me a certain amount of flexibility as to how patches are
posted I can either do a series on a specific file/glob e.g. post
[1/?? mi/* error message 'foo'] [2/?? mi/* error message 'bar']

or a series error message 'foo' followed by a series for error message
'bar', this I think is easier for mass review, while the other maybe
better if each maintainer prefers to share the burden of review.

as far as the method, I'm doing a simple/stupid pass of 'fix the error
message robotically', introducing nothing new I don't have to, there
will be obvious cases of eyesores, where we may want to introduce new
types for example. we can consider this pass in bringing those to
light, and getting the other obvious changes out of the way. It will
probably be easier for me to just cherry-pick these later, than to
keep them on their own branch.

>  Are you going to
> post patches one by one to fix compilation errors, and finally turn
> -Wc++-compat on in the last step?

yes but I think that there should be a grace period in between
commiting the final patch to fix compilation errors, and comitting the
patch to turn -Wc++-compat on in order to allow target maintainers to
test *-tdep.c and any macro guarded code which may not be covered by
--enable-targets=all on a platform which I do not have access to.