Run in another directory
Systemverilog Unit Test Framework
Brought to you by:
bryan_morris,
nosnhojn
Menu
▾
▴
#62 Run in another directory
It'd be nice to be able to tell SVUnit to run from another directory, so that all auto-generated files, binaries, logs, etc. created by the simulator aren't polluting the test directory (which is a pain for source control). From what I can see, buildSVUnit hard-codes $pwd as the starting point, so I can't do something like "cd $WORK_DIR; runSVUnit $TEST_DIR".
Discussion
Anonymous
Been thinking of this for a while now bc I new it would become an issue for some. I'll let things settle with this new release first, then will likely get to this.
taking a stab at this tonight. plan is to add a '-o|--out
Not sure what kind of source control the original poster is using.
Most source control software has a file that allows you to setup files or file types to ignore
for example cvs has cvsignore http://cvsnt.org/manual2/html/cvsignore.html
and git has gitignore https://help.github.com/articles/ignoring-files
Neil addressed the ignore files below...
The other reason for the separation of output and source is that you often want to keep the source on a backed-up network volume, and dump all output/binaries to some kind of local scratch disk that's (1) faster, (2) bigger, and (3) can be wiped out at any time.
agreed, but I can see the point of this. even with the ignore files, if you don't realize there's all the temp files, you're going to make the mistake of committing them at least once :)
Stan, I'm about to release this in v3.3. please try it and let me know if this is what you're after. basically, it comes down to the addition of an -o|--out
-neil
Thanks, Neil! I only had a few minutes to try it... However, while it did do what it should, i.e. all output was in the directory specified with -o, none of the tests ran. It compiled and executed the ./simv, but nothing happened inside the simulation. Taking out the -o did run my tests, so I think my setup is fine. I'll try to find more time in the next couple of days to debug what happened.
One other minor thing is that the script was looking for the file specified with -f <file> in the output directory instead of the one I ran the runSVUnit from, so I had to specify the full path to it.</file>
ok... the hint here may be "executed the ./simv" in that I don't have a vcs license in my regression suite (I run everything through questa and ius and everything looks fine).
just to confirm, you're running runSVUnit where you'd normally run it (i.e. in your source dir) with the -o <elsewhere> switch? The files are being generated and run in <elsewhere> but there are no tests running in the testsuite? assuming yes and yes, then we have a problem :).</elsewhere></elsewhere>
...and to your last point... yes, abs paths in your .f files (or paths relative to <elsewhere>) are necessary. trying to account for that was going to get too hairy and I figured people would just get used to full paths if that's the direction they were going.</elsewhere>
thanks for the quick test. let me know if/what you figure out. If you can send me the generated hidden files, I can take a look, too.
-neil
That's right, running from the usual place, and files are generated <elsewhere> and no tests ran. I'll let you know what I find out!</elsewhere>
As for the .f file... The full paths inside the .f files are fine, that's generally the way to go to support "build in any directory" anyway, but I wouldn't expect to need the full path on the command line. I.e. just like I can run
vcs -f files.f
... I would expect to be able to run...
runSVUnit -f test.f
... instead of ...
runSVUnit -f
pwd/test.fI think running all the file parameters through abs_path() before 'cd'-ing into the output dir ought to fix that relatively painlessly.
ah! I misread your email... then found a flaw in the test I had the ran the -o with -f switch. fixed the test, then updated the abs_path as you suggested. v3.4 released.
Ok, I've looked into the problem... What happens is that testsuites are being created, but testrunner isn't (and hence no tests running :) ). The problem is that buildTestRunner is looking for testsuites in the current directory instead of the $outdir, where they were generated.
Changing line 104 in buildSVUnit from '..., qw( . ));' to '..., $outdir);' fixed the problem, and I got tests running again.
The other thing here is that runSVUnit ignores the return code from buildSVUnit -- it was returning 1 as it couldn't find any tests suites, but runSVUnit happily kicked off the tests anyway :).
-f works great in 3.4, btw!
Nuts. Obvious now. The tests I added for this put the o directory inside the source dir instead of a peer. Can't believe I did that. I'll ship a 3.5 Sunday night and hopefully we can move on to the next thing. Thanks a lot for your help with this. I was a little careless here so I appreciate the fast feedback.
Neil
v3.5 shipped yesterday morning. thanks again for the help.
-neil
I've confirmed that 3.5 works here -- thanks!