|
From: Ashley P. <as...@pi...> - 2009-07-07 11:33:31
|
All, I'm looking at spending a couple of days fixing up the regtests so they work with VPATH builds, this is probably going to end up being moderately intrusive however. Is there anything I need to know before I start hacking away at the code, are all the tests driven from "make regtest" for example or are there other ways of driving them that I need to preserve? One thing that springs to mind is that platform_test could be removed and the logic rolled back into vg_regtest for example, is there any reason why I shouldn't do this? Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-07 11:56:02
|
On Tue, Jul 7, 2009 at 8:01 PM, Ashley Pittman<as...@pi...> wrote: > > I'm looking at spending a couple of days fixing up the regtests so they > work with VPATH builds, this is probably going to end up being > moderately intrusive however. > > Is there anything I need to know before I start hacking away at the > code, are all the tests driven from "make regtest" for example or are > there other ways of driving them that I need to preserve? The arguments to vg_regtest can be entire directories or individual test files (with or without the .vgtest suffix). So all these kinds of invocations must be preserved: perl tests/vg_regtest memcheck/ perl tests/vg_regtest memcheck/addressable.vgtest perl tests/vg_regtest memcheck/addressable > One thing that springs to mind is that platform_test could be removed > and the logic rolled back into vg_regtest for example, is there any > reason why I shouldn't do this? Not that I can see; vg_regtest seems to be the only user of platform_test. Nick |
|
From: Ashley P. <as...@pi...> - 2009-07-07 12:02:44
|
On Tue, 2009-07-07 at 21:55 +1000, Nicholas Nethercote wrote: > On Tue, Jul 7, 2009 at 8:01 PM, Ashley Pittman<as...@pi...> wrote: > > > > I'm looking at spending a couple of days fixing up the regtests so they > > work with VPATH builds, this is probably going to end up being > > moderately intrusive however. > > > > Is there anything I need to know before I start hacking away at the > > code, are all the tests driven from "make regtest" for example or are > > there other ways of driving them that I need to preserve? > > The arguments to vg_regtest can be entire directories or individual > test files (with or without the .vgtest suffix). So all these kinds > of invocations must be preserved: > > perl tests/vg_regtest memcheck/ > perl tests/vg_regtest memcheck/addressable.vgtest > perl tests/vg_regtest memcheck/addressable Ok, I got that. How do the nightly test emails work, I assume they parse the stdout of "perl tests/vg_regtest memcheck ..." so that needs to be preserved as well. > > One thing that springs to mind is that platform_test could be removed > > and the logic rolled back into vg_regtest for example, is there any > > reason why I shouldn't do this? > > Not that I can see; vg_regtest seems to be the only user of platform_test. That should simplify things a bit. I notice a lot of the scripts call other scripts using ./ notation, I might find I need to put "$(top_srcdir)/$dir" on PATH and removing the ./ prefix from these scripts. Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-07 12:07:20
|
On Tue, Jul 7, 2009 at 10:02 PM, Ashley Pittman<as...@pi...> wrote: > > Ok, I got that. How do the nightly test emails work, I assume they > parse the stdout of "perl tests/vg_regtest memcheck ..." so that needs > to be preserved as well. nightly/bin/nightly (in the standard case) invokes "make regtest" but the output is just copied to the report file, there's no parsing. Nick |