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

Thanks a lot Tim, we will try it soon.
We will also think about the porting to Bullseye and get back to you.

Best regards,
Daniel

> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Thursday, October 7, 2021 10:56 AM
> To: sangorrin daniel(サンゴリン ダニエル □ＳＷＣ◯ＡＣＴ) <[email protected]>; pyla venkata(ＴＳＩＰ)
> <[email protected]>
> Cc: [email protected]; nguyen dat tho(ＴＳＤＶ Ｅｎｇ　１) <[email protected]>
> Subject: RE: [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