On Fri, Mar 01, 2019 at 07:09:05PM +0100, Jakub Jelinek wrote: > > > Can't we just detect the old dejagnu and override > > > whatever tcl method is responsible for that? > > > > Not sure. We probably could. But are the new semantics actually > > better? Sometimes you want the testcase flags to override the RUNTESTFLAGS, > > but just as often you don't. So now older dejagnu versions have one > > behaviour (and we will see those for very many years still, certainly on > > Power, where we mostly use slow^Wold^Wenterprise distros), and newer dejagnu > > versions have another behaviour, some things break with the old, some things > > break with the new, and it's all a big mess. > > CCing Jonathan here, as he has I think dealt with this a lot in the > libstdc++ testsuite. > > I believe the new dejagnu behavior is considered the desirable/right one, I > fail to see when the old behavior would be wanted. If a testcase wants to > override something, it should be able to. > > > > Having separate flags for the testcases that say "override the RUNTESTFLAGS" > > gives the best of both worlds. Even with with new dejagnu, where normally > > the RUNTESTFLAGS always wins. > > I thought new dejagnu behavior is RUNTESTFLAGS are placed early on the > command line and dg-options follow.
We are talking about the http://git.savannah.gnu.org/cgit/dejagnu.git/commit/?id=5256bd82343000c76bc0e48139003f90b6184347 change, right? If we choose to require dejagnu with that fix, shouldn't be that hard to apply that one-liner patch if whole dejagnu can't be upgraded. Or just like for libstdc++, document that using --target_board multilib options with older dejagnu is unsupported or has certain limitations. Jakub
