From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Simon Marchi <simark@simark.ca>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: [PATCH] Unify Solaris procfs and largefile handling
Date: Thu, 30 Jul 2020 15:49:26 +0200 [thread overview]
Message-ID: <ydd36592jvd.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <4d3bf991-c0e5-2136-5935-4c4e47aadbf2@simark.ca> (Simon Marchi's message of "Thu, 30 Jul 2020 08:43:37 -0400")
Hi Simon,
>>> When I run `autoreconf -vf`, I get a lot of changes. Make sure to run
>>> it in any directory you touch that has a configure.ac and add the resulting
>>> changes.
>>
>> I didn't use autoreconf, but ran the appropriate
>> autoconf/autoheader/aclocal/automake dance manually. With one exception
>> (LARGEFILE_CPPFLAGS in gnulib Makefile.in) I'd gotten things right :-)
>>
>> I don't usually include generated files in patch submissions, though:
>> they are heavily frowned upon at least over in GCC because they make
>> review quite difficult, espcially in a case like this where the
>> largefile.m4 change spreads to lots of configure scripts, obscuring the
>> change proper.
>>
>> Does GDB handle things differently here?
>
> I don't think there's a hard rule. If it makes the patch too big for sending on
> the list, then it's fine for sure to not include them. If you don't want
> to include
> them, that's fine with my too, but in either case it's important to say
> that you've
> omitted them on purpose so we know it's not an oversight (otherwise I'll complain
> about them missing :)).
ok, will do.
> Maybe it can be inconvenient for people who read the diff directly to review... I
> personally use meld to review patches, so it's simple to just skip over generated
> files.
I'm using Emacs' Diff mode for that, which does nice highlighting.
However, having to skip over large parts of generated files is
inconvenient to me.
> The patch LGTM, thanks.
Pushed now. Thanks for the review.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
next prev parent reply other threads:[~2020-07-30 13:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 15:15 Rainer Orth
2020-07-01 12:46 ` Nick Clifton
2020-07-09 10:50 ` Rainer Orth
2020-07-20 11:28 ` Rainer Orth
2020-07-28 13:03 ` Rainer Orth
2020-07-28 13:47 ` Simon Marchi
2020-07-28 13:51 ` Rainer Orth
2020-07-28 14:17 ` Simon Marchi
2020-07-29 11:19 ` Rainer Orth
2020-07-29 19:55 ` Simon Marchi
2020-07-30 9:17 ` Rainer Orth
2020-07-30 12:43 ` Simon Marchi
2020-07-30 13:49 ` Rainer Orth [this message]
2020-08-07 15:12 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ydd36592jvd.fsf@CeBiTec.Uni-Bielefeld.DE \
--to=ro@cebitec.uni-bielefeld.de \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox