Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii <eliz@elta.co.il>]

> Date: Sun, 14 Dec 2003 03:25:30 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> And then you will come back and say "go32 does not support running the
> test suite".  And then I will say: okay, fine, can you build gdb on
> go32?  Can you do "break main"?  Can you do a backtrace?  Can you print
> registers?  Can you print a local variable?  Can you set a watchpoint?
> Can you call a function with a double precision argument?
> 
> Can you put all that in a script and post the results to gdb-testers once a
> month?

It should be relatively easy to produce a script like that, assuming
that the tests you listed above constitute the minimal suite of tests
that are required to prove that a GDB port is alive (or at least if
the set of the tests required for that doesn't change too much with
time).  If the set of tests changes too much, tracking them might not
be easy, given my free time (or should I say the lack thereof ;-)[1].

However, running the script once a month (on the then-latest snapshot,
I presume) is not something that I can afford, and I don't see anyone
else stepping forward to do that for me.

Since your proposal for deprecating counts minor releases, would it
be enough to request a run for every such release?

> If nobody does those things for a platform, then I want to obsolete the
> platform.

I think the degree to which such a logic is justified depends on the
platform.  For example, x86 platforms generally benefit from Mark
Kettenis's work and so are expected to bit-rot much slower than some
exotic platform that shares none of the code with others.

Isn't it better to start deprecating only if we know that some code
specific to a platform is broken by a certain change to GDB?  For
example, if some interface is deprecated and no one submitted
replacement code for a specific platform, then declare that platform
heading into obsolescence.

-----------------
Footnotes:

[1] Ironically, I suggested a couple of years ago (in a message I
cannot for the moment find in the archives) to add a script to the
gdb/config/djgpp directory that would run GDB against some subset of
the test suite, only without relying on `expect' and `dejagnu', and
compare the results against the expected ones.  However, both Andrew
and DJ thought the idea was not worth the effort, since simple textual
comparison, a-la "diff -ubBw", would bit-rot too quickly, due to
changes in GDB and local library developments.