Re: kunit.py should default to --build_dir=.kunit

[Brendan Higgins <brendanhiggins@google.com>]

On Thu, Oct 17, 2019 at 5:51 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Wed, Oct 16, 2019 at 02:04:35PM -0700, Brendan Higgins wrote:
> > > > Should we maybe drop `--build_dir` in favor of `O`?
> > >
> > > Yes, preferably be consistent with the rest of the kernel makefiles.
> >
> > Alright, probably a good idea to make this change fairly soon then
> > before we have to worry about backwards compatibility and such.
>
> I'm not sure how this would work; so something like:
>
>     .../kunit.py run O=/build_dir

Seems reasonable to me.

> Should other flags we can pass in via the makefile processing, such as
> V=1, etc., also work?  What other things can we pass in via after the
> "run" command?

Hmmm...that's a good point. I don't know about V; probably need to
improve how kunit_tool displays build information for that to be
useful. I don't think that W is likely to be useful since I think that
is semantically a different operation than just running KUnit tests.

Probably don't want to forward ARCH, or CROSS_COMPILE or any of those.

Supporting some of these[1] seems useful.

> And if we're going to go this far, maybe we should make "make kunit"
> run tools/testing/kunit/kunit.py?

That seems reasonable. I was holding off on that initially because I
thought it might be a bridge too far in terms of putting KUnit in a
highly visible place. However, in hindsight, I think we crossed that
bridge a long time ago with putting tests is very visible places. So
yeah, now is probably a good time to do that.

> Some minor other nits if you're going to be making changes to
> kunit.py's CLI parsing:
>
> 1) It would be nice if there was a help command so that "kunit.py
>    help" does what kunit.py -h does.

Seems reasonable.

> 2) The top-level help message should indicate that "kunit.py run"
>    takes various optional arguments and the way to find them is
>    "kunit.py run -h".  This was *not* obvious, and the way I figured
>    out there was even --build_dir option was via purusing the source
>    code.  (It wasn't in the documentation that I could find.)

Also reasonable.

> 3) And maybe then "kunit.py help run" should display the help message
>    for "kunit.py urn".  This would make it consistent with other tools
>    that some of us might be familiar with (e.g., gcloud, gsutil, etc.)

That's reasonable, but also a little harder. At that point, I think we
might need to write our own flag library to support all this. So, I
will put this as a TODO, but we probably won't get to it for a while.

> Of course, if the front entry for kunit starts being "make kunit" as
> opposed to ./tools/testing/kunit/kunit.py, then we really need to
> figure out how to pass in the equivalent of --timeout.  (Maybe

Yeah, that's true. We should probably also by default set --timeout to
a reasonable default instead of infinite.

> --raw_output is enabled if we run make kunit V=1?).  And of course,

Hmmm...that seems like a good idea.

> all of this would need to be documented.

Yeah, we very much need to improve our documentation, especially for
the kunit_tool. That is very high on our TODO list.

[1] https://www.gnu.org/software/make/manual/html_node/Options-Summary.html