Eric Blake <eblake@xxxxxxxxxx> writes: >> The macro was originally added to configure.in on the sug- >> gestion of autoscan which basically means that in a few >> years some well-meaning developer will probably re-run auto- >> scan, re-add the macro and the bug will re-appear. > > Autoscan is primarily designed as a once-only program, only done when > first converting to autotools, and not something you repeatedly run Exactly. It also assumes the worst case, advising you check for things that are pretty much guaranteed to exist on 99.9% of systems these days (so for a typical project, much of autoscan's advice should simply be ignored). Standards conformance is far better these days than it was in 1995, and most people really don't need to port to ye-olde-K&R-only-with-bugs systems... So maybe the best solution is simple: don't run autoscan (again), or if you do, take its advice with a huge grain of salt. [If there _is_ some desire to re-run it periodically to catch mistakes or something, another possible solution would be to keep a simple grep filter to apply to the autoscan output, which lists all the macros autoscan suggested in the past which were determined to actually not be necessary.] -miles -- Year, n. A period of three hundred and sixty-five disappointments. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
