I took a look at what it would take to upgrade to the latest readline 7
patch release.  I have a few questions, mostly about Windows-related
preprocessor defines.

First I diff'd readline 6.2 patch 1 against gdb's readline.
From the history it appears that this is the correct baseline to use.

Then I diff'd readline 6.2 patch 1 against readline 7.0 patch 5.
This is the latest stable release of readline.

Next, for each hunk in the readline-to-gdb diff, I searched for an
equivalent hunk in the readline-to-readline diff.  If the hunk was
found, I removed it.

This left a patch consisting of changes that were made to the gdb
readline but not upstreamed.  They fall into four categories:

* Changes that seem necessary or at least desirable for gdb.  In the
  patch below this includes the configure.in, hsuser.texi, and
  Makefile.in changes.

* Changes that should be retested.  This includes the, emacs_keymap.c,
  and complete.c changes.

* Changes that were simply not upstream.  In general I don't know why.
  This covers the signals.c and xfree.c changes, though perhaps
  signals.c falls into the "re-test" category.  I think for xfree.c I
  can maybe do a bit of patch archaeology to find the reason.

* Changes that are upstream but in a different form.  display.c and
  terminal.c have different #if conditions and input.c has different
  code:

  display.c

  readline upstream:
  +#ifdef __DJGPP__
  
  gdb:
  +#ifdef __MSDOS__
  or
  +#if defined (__GO32__)

  terminal.c
  readline
  +#ifdef __MSDOS__

  gdb:
  +#ifdef __DJGPP__

  input.c, readline:
    +int
    +win32_isatty (int fd)
    +{
    +  return (_isatty (fd) ? ((((long) (HANDLE) _get_osfhandle (fd)) & 3) == 3) : 0);
    +}

  (for gdb see the patch, the gdb version is longer and calls GetConsoleMode)


For most of the differences, I know what to do.  But, I don't know the
difference between __DJGPP__, __MSDOS__, and __GO32__ -- and the sources
also check __MINGW32__, _WIN32, and __CYGWIN__ at places.  So, I am not
sure how to go about merging those parts, and whether changes need to be
sent upstream.

My other question is how best to go about merging.  In the CVS days I
would have done a cvs import on a vendor branch.  I could simulate this
pretty well in an external git repository I suppose.  It's tempting to
switch entirely to git submodules for external dependencies, but maybe
just having a gdb "import area" git repository would be alright.  The
idea being, do the merge work there, but in the end just check in a
giant patch.  Then the next person to do this could re-use the
repository.


I'm attaching my edited readline->gdb patch so you can see the details
if you want.  The readline 6->7 diff is very big but you can see it by
cloning:

git://git.savannah.gnu.org/readline.git

and diffing like

git diff d0a9f21f36b2bf3ac28e1b11c1962bbb2ca0be2c..origin/master

That revision is, I believe, readline 6.2 patch 1.
Maybe this can also be seen online somewhere, I don't know.

Tom