This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/3] Remove spurious exceptions.h inclusions
- From: Doug Evans <dje at google dot com>
- To: Gary Benson <gbenson at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 9 Oct 2014 10:47:21 -0400
- Subject: Re: [PATCH 1/3] Remove spurious exceptions.h inclusions
- Authentication-results: sourceware.org; auth=none
- References: <1409586154-16196-1-git-send-email-gbenson at redhat dot com> <1409586154-16196-2-git-send-email-gbenson at redhat dot com> <CADPb22RcwUGPEwGGc7hG=4R0KvRV9axKDbQ6Nu1PHys5Nk=t8A at mail dot gmail dot com> <20141009094531 dot GB6910 at blade dot nx>
On Thu, Oct 9, 2014 at 5:45 AM, Gary Benson <gbenson@redhat.com> wrote:
> Doug Evans wrote:
>> On Mon, Sep 1, 2014 at 11:42 AM, Gary Benson <gbenson@redhat.com> wrote:
>> > defs.h includes utils.h, and utils.h includes exceptions.h. All
>> > GDB .c files include defs.h as their first line, so no file other
>> > than utils.h needs to include exceptions.h. This commit removes
>> > all such inclusions.
>> >
>> > Doug, I Cc'd you on this one as you asked me to avoid giant
>> > mechanical ChangeLog entries but I couldn't figure out how I'd
>> > rewrite this one.
>>
>> For reference sake,
>> I said that for two reasons:
>> 1) to save you some typing
>> 2) to keep the S/N ratio of the ChangeLog file from dropping, and
>> in this case from dropping significantly. Yikes!
>>
>> > gdb/ChangeLog:
>> >
>> > * ada-lang.c: Do not include exceptions.h.
>> > * ada-valprint.c: Likewise.
>> > * amd64-tdep.c: Likewise.
>> > [...]
>>
>> I realize one of the guidelines for changelogs is to document every
>> file that's changed, but if we can agree that "All callers updated."
>> can apply to all callers in all files, then I don't see why we
>> couldn't be ok with something like the following for this case:
>>
>> * All .c files: Do not include exceptions.h.
>>
>> Yeah, it's not pedantically correct, not all .c files were touched.
>> But I can live with that given the alternative.
>
> I'll use this wording next time.
fwiw, I think anything similarly short in any similar situation should be fine.