Ralf Wildenhues <[EMAIL PROTECTED]> writes: > I didn't have any such headaches before the patch.
I did. The problem had been bothering me for some time. And when I saw the AC_TRY_COMMAND-related bug report that started this thread, I realized the problem was worse than I thought. > I am slowly running out of time checking whether > the new version now breaks oodles of packages, or not. It is helpful and admirable of you to be doing all this checking against other people's software. But doing all the checking will burn you out -- at least, it would burn _me_ out, and almost anybody else I would think. It would be more efficient to enlist others to help, and in the end, with luck, you'll be saner and will have more time to do more-productive things. For AC_TRY_COMMAND and AC_TRY_EVAL I followed your good suggestion: namely, leave them alone, but keep them undocumented and deprecated, and eventually we can come up with a better approach with new macro names. However, I don't see how this suggestion would generalize well to the multitude of other predefined macros (AC_CHECK_FUNC, AC_CHECK_LIB, etc., etc.). Unlike AC_TRY_COMMAND and AC_TRY_EVAL, these other macros are documented and are quite commonly used. It would be a bit much to rename all these macros simply to fix an obscure shell quoting problem that hardly ever leads to disaster (except when deliberately provoked, alas). So we will have to bite the quoting bullet with these macros anyway. It is only a question of judgment as to whether it's better to do it now (as per the current CVS) or after 2.60 is out (or more likely, after 2.61 or 2.62 or 2.63....). We can try enlisting others to test snapshots, with Debian and the like. If we find further problems you can easily talk me into reverting the eval-quoting changes, but right now I'm still inclined to leave them in.
