This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: (patch) hpjyg15: hppah-nat.c & related



  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]