[OE-core] [PATCH 15/20] classes/populate_sdk_ext: Add OE_SDK_EXT_SILENT env variable
Paul Eggleton
paul.eggleton at linux.intel.com
Tue Feb 2 21:40:09 UTC 2016
On Tue, 02 Feb 2016 15:38:33 Aníbal Limón wrote:
> On 02/02/2016 03:31 PM, Paul Eggleton wrote:
> > On Tue, 02 Feb 2016 15:30:21 Aníbal Limón wrote:
> >> On 02/02/2016 03:25 PM, Paul Eggleton wrote:
> >>> On Tue, 02 Feb 2016 15:23:54 Aníbal Limón wrote:
> >>>> Paul Eggleton wrote:
> >>>>> Rather than adding another variable for this why not just redirect the
> >>>>> output to /dev/null ?
> >>>>
> >>>> Because this is disabled when SDK tests (compatibility) ran using eSDK
> >>>> so sometimes needs to SILENT it when automatic process is working
> >>>> another times don't like when user uses it.
> >>>
> >>> At face value, redirection during automated testing and not when not
> >>> solves
> >>> this.
> >>
> >> We can't only redirect because is a python test that looks for some
> >> output in the sdtout, if we redirect to the /dev/null then lose the
> >> value.
> >
> > Well naturally you would need to redirect the output of the SDK
> > environment
> > setup script only.
> >
> >>>> In this case the SDK tests fails because it looks to stdout and found
> >>>> devtool msg.
> >>>
> >>> Which test failed and why?
> >>
> >> Is this test [1], as i said is an SDK test running on eSDK env.
> >>
> >> [1]
> >> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/meta/lib/oeqa
> >> /sd k/python.py?h=alimon/esdk_testsuite_export#n22
> >
> > OK, but where is the bit that actually runs the environment setup script?
>
> Here [1] and i set the variable in the testsdkext task [2].
>
> [1]
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/meta/lib/oeqa/oe
> test.py?h=alimon/esdk_testsuite#n127 [2]
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/meta/classes/tes
> tsdk.bbclass?h=alimon/esdk_testsuite#n107
Right, so you can trivially redirect the output of the env setup command
(before the ';') to /dev/null. It also won't affect the standard SDK testing so
we should be safe there as well.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-core
mailing list