Re: Linux sigtramp detection code moved to its proper place

[Eli Zaretskii <eliz at delorie dot com>]

> Is there anything that the nightly snapshots (short term) and/or
> testsuite (medium/long term) can do to ensure that the relevant
> djgpp files are always up-to-date?

As a matter of fact, there is.  I have todo items for the following
issues:

  - The file config/djgpp/fnchange.lst needs to be updated to include
    the exact version in the file names it maps.  Specifically, that
    file consists of lines which look like this:

      gdb-0321/foo/bar/long-name-foo.c gdb-0321/foo/bar/short-foo.c

    (When DJTAR sees this line, it renames the file whose name is on
    the left to what's on the right.)

    The "gdb-0312" part should be replaced with the actual name of the
    directory which the distribution creates when unpacked, and that
    name includes the version of the snapshot/release.

    What I was thinking was to provide a template whose lines will say
    this:

      gdb-@VER@/foo/bar/long-name-foo.c gdb-@VER@/foo/bar/short-foo.c

    and run Sed on it inside the commands used to tar the
    distribution, to replace that with the actual version (taken from
    the Makefile, for example).

  - If the long names which clash after 8+3 truncation are to stay
    with us for Quite A While (tm), it might make sense to have some
    script or program that will update fnchange.lst whenever a new
    file is added that clashes with some other file name, but is not
    yet covered in fnchange.lst.  Assuming that the files which get
    added are not required for the DJGPP build (since those must
    *never* clash with other file names), what we need is to add an
    entry like this:

      gdb-@VER@/foo/bar/new-long-name-foo.bar

    When DJTAR sees such a line, it skips the named file.

    This looks like a job for a Perl script.  Unfortunately, Perl for
    me is a read-only language.  I could write a C program to do this,
    if this is acceptable, though.

Comments and ideas are welcome.

> As a suggestion from left field, I've wondered if gdb.base/selftest.exp
> should be moved to gdb.wb/selftest.exp (wb == white box) so that people
> can freely add additional white box tests to GDB.  Checking consistency
> between config/djgpp/<that-file> and the GDB sources could be part of
> that testsuite.

Does that mean that you always run the test suite before preparing the
snapshots?  If so, how do you know whether a certain new failure is
grave enough to prevent you from making the snapshot?  I mean, if the
test for consistency in config/djgpp/<that-file> were added, and it
failed, how would you know that this is not some minor regression
(which I assume do happen in other parts of GDB)?