[libre-riscv-dev] [Bug 316] bperm TODO

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=316

--- Comment #58 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #55)
> (In reply to Cole Poirier from comment #54)
> > Ah yes, appreciated, I will grep first in the future. For clarification, the
> > way to run the tests is by cd'ing to the soc/decoder directory then running
> > 'python3 test/{test_file.py}' for each of the files in the tests directory?

because i run ctags in one directory (usually the top level or close to it)
and stay there.

i generally run e.g. python3 fu/alu/test/test_pipe_caller.py or something.
constantly doing "cd" i find very annoying.

to find previously-run commands is a matter of running "history" followed by
!inserthistorynumber

this saves typing the command out repeatedly - also very annoying.

lots of annoyingness... :)

> > Or do I cd to the top level soc directory, and run 'sudo python3 setup.py
> > test'?
> 
> Definitely don't use `sudo`.

yep.  it will result in test output that, on return as the ordinary user,
you will not be able to overwrite.  to "fix" that, do this:

soc/src$ sudo bash
soc/src# chown -R colepoirier .
soc/src# exit
soc/src$

that will ensure that all files are owned by you (not root) in the entire soc
locally checked out repository.

a "dumb" way to achieve the same effect is to completely destroy the entire
checkout.  this is wasteful of both time and bandwidth.

> I cd to the top level and run either `python3 setup.py test` or `nosetests`.

this runs every single test, which consumes a lot of time however is a good
idea.

to get a "faster development cycle" i tend to run only the test that is needed.
delays in that cycle - by running tests that have nothing to do with the task
at
hand - i also find annoying.

however *after* that fast-iterative cycle (explicitly running only the relevant
test), it is kinda important to run more (nosetests3, python3 setup.py test)
just
to make absolutely sure you didn't break anything unrelated.  don't tell no-one
i tend not to do that very often... :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.