Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney <cagney@gnu.org>]

> Any change needs to be a natural part of the development cycle:
> 
>     modify
>     build
>     test
>     submit
>     review
>     commit
> 
> The existing deprecate works because looking for deprecated is a relatively natural part of the patch review phase (and the issue is trivially addressed by contributors before they post their submition - if you look over the mailing lists you'll see a very high success rate and few problems with new contributors).
> 
> Given that the ARI takes a measurable amount of time to run, it can't be addeded to the build process.  However, as part of the testsuite might be more interesting:
> 
> FAIL: number of occurances increases
> KPASS: number of occurances decreased
> PASS: something is zero
> KFAIL: number of occurances remained static

Two PSs:

Even cheaper / simpler is to have financially driven corporations trying 
to squeeze the last drop out ofcontracts involving the maintenance of 
legacy code just create an internal "deprecated.h" file that contains 
hacks like:
	#define deprecated_npc_regnum npc_regnum
and then #include that.  While personally I'd just track the deprecated 
names, this is certainly a cheep option.

My moving deprecated tests to the testsuite or build process the quality 
of code expected from GDB contributors is significantly reduced - the 
acceptance criteria is that they don't increase the deprecated count - 
_not_ that deprecated code is cleaned up as one goes.

(But note this is speaking generally and not in relation to STREQ)