This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: (patch) hpjyg15: hppah-nat.c & related
- To: Jimmy Guo <guo at cup dot hp dot com>
- Subject: Re: (patch) hpjyg15: hppah-nat.c & related
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 16 Dec 1999 00:50:39 -0700
- cc: Andrew Cagney <ac131313 at cygnus dot com>, gdb-patches at sourceware dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <Pine.LNX.4.10.9912150951120.29808-100000@hpcll168.cup.hp.com>you
write:
> Since I'm splitting apart changes made by HP, in various areas, over 12
> months, into multiple patches, there's a need for me to run indent on
> the patched source to ensure that the GNU coding style in gdb source is
> adhered to. I will make sure that pure formatting changes (line breaks)
> made by HP are not introduced along with real changes.
Well, there may be instances where you have a real change that required a
formatting update. ie consider if you had
if (foo)
blah
And you changed it to
if (foo)
{
bar
blah
}
In that case you do want the formatting change. So you have to be careful
about blindly ignoring whitespace differences.
> However as we've discovered, due to a combination of a potential indent
> program problem and the fact that there're places in snapshot sources
> where formatting is actually necessary, there's another kind of pure
> formatting changes which can come from this combination (and my running
> indent before making the patch). There're several ways to handle this:
>
> 1) generate patch using GNU diff -w option (ignore white space), and
> apply patch using patch -l (--ignore-whitespace) option.
> :: I like this approach and I'll do it if you guys are willing to
> give this a try.
It runs afoul of the problem noted above. And thus will tend to introduce new
formatting problems in the gdb sources. It may be a reasonable thing to do
in limited cases though.
> 2) don't run indent before generating patch, have maintainers do
> that before checking into CVS.
> :: could work. If necessary I can provide a ksh script to do this,
> incorporating the special-case handlings documented by Stan during
> the GDB reformat (so one do not indent a file which is not supposed
> to be indented).
>
> 3) patch submitter manually remove pure formatting change noises from
> patch.
> :: least favored.
You missed another alternative, which I'd tend to favor.
1. Run intent on the gdb source files. Submit that as a patch. That should be
acceptable without problems.
2. Apply the patch from wdb using whatever means are possible (patch -l ?).
3. Re-run indent on the changed files.
4. Submit the patch resulting from diffing the output of steps #1 and #3.
Yes, this is painful. But it avoids introducing new formatting problems in
the sources (in fact via step #1 it will tend to fix formatting problems that
have slipped in accidentally).
Of course we only need to go through this pain as we flush out your old
patches. Newer stuff should be done using GNU standards and this kind of
painful process shouldn't be necessary.
jeff