From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28329 invoked by alias); 11 Dec 2012 06:25:44 -0000 Received: (qmail 28307 invoked by uid 22791); 11 Dec 2012 06:25:42 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Dec 2012 06:25:35 +0000 Received: by mail-la0-f41.google.com with SMTP id m15so3005556lah.0 for ; Mon, 10 Dec 2012 22:25:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.105.33 with SMTP id gj1mr16228531lab.49.1355207133859; Mon, 10 Dec 2012 22:25:33 -0800 (PST) Received: by 10.112.32.1 with HTTP; Mon, 10 Dec 2012 22:25:33 -0800 (PST) In-Reply-To: <50C1EE0B.3040905@codesourcery.com> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F8FD047.6030702@codesourcery.com> <20121204141708.GA28600@host2.jankratochvil.net> <201212041444.qB4EiG4L025312@glazunov.sibelius.xs4all.nl> <20121204145144.GA30509@host2.jankratochvil.net> <50C1EE0B.3040905@codesourcery.com> Date: Tue, 11 Dec 2012 06:25:00 -0000 Message-ID: Subject: Re: Will therefore GDB utilize C++ or not? From: Matt Rice To: Yao Qi Cc: Jan Kratochvil , Mark Kettenis , gdb@sourceware.org, tromey@redhat.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-12/txt/msg00044.txt.bz2 On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi 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.