Re: [Fuego] [PATCH 4/4] rt: search for the binary if the build phase is skipped

> -----Original Message-----
> From: [email protected] <[email protected]>
> 
> Hi Tim,
> 
> > -----Original Message-----
> > From: [email protected] <[email protected]>
> [..]
> > I was thinking of something like:
> > prefer_host_test_programs=true|false
> > in fuego.conf.
> >
> > This would be PREFER_HOST_TEST_PROGRAMS as an environment variable or dynamic variable.
> >
> > The effect of the flag would be to just change the search order in get_program_path from:
> >  board test dir, alternate dirs., PATH
> > to
> >  PATH, alternate dirs., board test dir
> 
> Exactly what I was thinking.
> 
> > I still am not sure where the programs that you plan to install (outside of deploy) will reside.  It sounds like you plan to put them into
> > $BOARD_TESTDIR/fuego.$TESTDIR, but that would that mean you always have to set --preclean to false when doing ftc run-test.
> 
> No, no. This must be a misunderstanding. We install the tests into the typical path (/usr/loca/bin etc).

OK - thanks.

> 
> [...]
> > Should I whip up an implementation.  I have the successor to get_program_path done, but would still need to do the config variable
> > handling.
> >
> > Having said all that, if you don't think you'll set the config variable, I'd rather not add the implementation for it.  Fuego already has a
> > large number of somewhat idiosyncratic behaviors, and I'd like to avoid adding more unless there's a real use case for them.
> 
> I think the main use case for the variable is to select what binary to run when you have 2 (one in the system path and another one in
> $BOARD_TESTDIR/fuego.$TESTDIR. We do not have this use case (we only install one test).
> 
> I think that Venkata's main concern was on the order of the search (first system path and second $BOARD_TESTDIR/fuego.$TESTDIR).
> Perhaps modifying the order would be a good idea. However, this will only affect users who have 2 test binaries on the same host and that
> is not our use case.
> 
> The main use case for having 2 binaries on the same board would be comparing results between 2 versions of the same test. Or at least that
> is my guess.
> 
> Concluding:
> - we don't need the global variable
> - perhaps it's better to change the search order (first fuego's and second the host)

OK - sorry this took so long to get back to.

I decided to forego the configuration variable, and I changed the search order to:
 $BOARD_TESTDIR/fuego.$TESTDIR
 extra directories (if specified)
 PATH directories

I also changed the implementation to require less 'cmd' operations on the board
(this is nicer for boards where the ssh latencies are noticeable).  For
boards where TRANSPORT=local, this should not improve the speed much, but
get_program_path should be pretty fast in either case.

I changed Benchmark.Dhrystone to use get_program_path, as we previously
discussed.  This means that this test is already primed to be used in your use
case (which I'll call the "pre-deployed test programs" use case).

Please try it out and let me know if you see any problems.  I wrote a unit test
for get_program_path(), called Functional.fuego_function_gpp_check.  If you encounter
any problems, please run that test, with FUEGO_LOGLEVELS=run:debug, and send
the console log for the test.

Thanks for the original patch and the idea for the feature.

Regards,
 -- Tim