On Feb 14, 2020, at 11:57 AM, Maciej W. Rozycki <ma...@wdc.com> wrote: > > Mike, Chung-Lin -- > >>> In the end I have decided to use the documented `--tool_exec' option to >>> `runtest' to contain the change within the testsuite's Makefile and its >>> `check' goal, which is inherent to the build tree and as such not supposed >>> to be used in standalone testing, like with `contrib/test_installed'. >> >> >>> I'm assuming Ian will take care of the 3/4 libgo change; OK to apply the >>> remaining ones to the GCC repo? >> >> So, I really, really would like to avoid additional arguments like this. >> I'd prefer that instead you push content into the built site.exp from >> the Makefile, or something else like this, and then use that content as >> you need to. This preserves the ability to go where you need to in the >> tree, and do a runtest without specifying the option. > > Thank you, Mike, for your input. That is what v1 did, but it seems to > clash with some people's expectations, as discussed here: > > <https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00057.html>
I didn't see any clash with expectations. They expect in the build tree testing to work, they expect install testing to work. I expect both, you expect both; I just don't think we differ on this. Where I think things went wrong is there is a change to their testing environment that you didn't fully account for in your patch. You didn't intend to break it, but there is just a little more work to be done to not break it, that's all. So, let step back. You want to change the options to the compiler, right? So, imagine for a second that site.exp has those options, then you can reliably grab them from that file and use them, no? If so, then all you have to do is put the content you need into site.exp, and then once it is there, you can then merely add a little code to grab them and add them, right? So, pick testsuite that fails, and that you broke. Back out the last patch, and instead, in the Makefile (or whatever generate the Makefile, look for the site.exp rule, and instead pilfer the data you want create it up into an existing variable, if relevant to it, and if not, create a new one. For some of these files we see they come from automake, so we google, then we find: http://gnu-automake.7480.n7.nabble.com/Automake-and-dejagnu-s-site-exp-file-td4414.html and presto, a 5 line solution to an existing problem. Is that kinda sort similar to what you want to do? Now that's a 12 year old answer the the problem, I didn't check to see if there is a newer answer. It looks reasonable enough.
