[OE-core] [PATCH 2/4] classes/testsdk: Move the removal of bitbake PATH to eSDK context only
Aníbal Limón
anibal.limon at linux.intel.com
Mon Feb 22 16:37:29 UTC 2016
On 02/22/2016 10:23 AM, Randy Witt wrote:
> On 02/22/2016 08:09 AM, Aníbal Limón wrote:
>>
>>
>> On 02/22/2016 09:54 AM, Randy Witt wrote:
>>> On 02/22/2016 07:03 AM, Aníbal Limón wrote:
>>>> From: Aníbal Limón <limon.anibal at gmail.com>
>>>>
>>>> The removal of bitbake and scripts PATH is only needed by eSDK tests
>>>> so move to eSDK context only.
>>>>
>>>> This also it's a support for eSDK update test because it needs to
>>>> execute oe-publish-sdk from scripts.
>>>>
>>>> Signed-off-by: Aníbal Limón <limon.anibal at gmail.com>
>>>> ---
>>>> meta/classes/testsdk.bbclass | 9 ++++-----
>>>> meta/lib/oeqa/oetest.py | 22 +++++++++++++++++++++-
>>>> 2 files changed, 25 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/meta/classes/testsdk.bbclass
>>>> b/meta/classes/testsdk.bbclass
>>>> index 7e245e9..01d37c4 100644
>>>> --- a/meta/classes/testsdk.bbclass
>>>> +++ b/meta/classes/testsdk.bbclass
>>>> @@ -96,11 +96,10 @@ def testsdkext_main(d):
>>>> # extensible sdk use network
>>>> export_proxies(d)
>>>>
>>>> - # extensible sdk shows a warning if found bitbake in the path
>>>> - # because can cause problems so clean it
>>>> - paths_to_avoid = ['bitbake/bin', 'poky/scripts',
>>>> - d.getVar('STAGING_DIR', True),
>>>> - d.getVar('BASE_WORKDIR', True)]
>>>> + # extensible sdk can be contaminated if native programs are
>>>> + # in PATH, i.e. use perl-native instead of eSDK one.
>>>> + paths_to_avoid = [d.getVar('STAGING_DIR', True),
>>>> + d.getVar('BASE_WORKDIR', True)]
>>>> avoid_paths_in_environ(paths_to_avoid)
>>>>
>>>> pn = d.getVar("PN", True)
>>>> diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
>>>> index 3e2ea0f..cd1e7e0 100644
>>>> --- a/meta/lib/oeqa/oetest.py
>>>> +++ b/meta/lib/oeqa/oetest.py
>>>> @@ -21,6 +21,7 @@ import logging
>>>> import oeqa.runtime
>>>> import oeqa.sdkext
>>>> from oeqa.utils.decorators import LogResults, gettag, getResults
>>>> +from oeqa.utils import avoid_paths_in_environ
>>>>
>>>> logger = logging.getLogger("BitBake")
>>>>
>>>> @@ -128,7 +129,26 @@ class oeSDKTest(oeTest):
>>>> return subprocess.check_output(". %s > /dev/null; %s;" %
>>>> (self.tc.sdkenv, cmd), shell=True)
>>>>
>>>> class oeSDKExtTest(oeSDKTest):
>>>> - pass
>>>> + def _run(self, cmd):
>>>> + output = None
>>>> +
>>>> + paths = os.environ['PATH']
>>>> +
>>>> + # extensible sdk shows a warning if found bitbake in the path
>>>> + # because can cause contamination, i.e. use devtool from
>>>> + # poky/scripts instead of eSDK one.
>>>> + paths_to_avoid = ['bitbake/bin', 'poky/scripts']
>>>> + avoid_paths_in_environ(paths_to_avoid)
>>>> +
>>>> + try:
>>>> + output = subprocess.check_output(". %s > /dev/null;
>>>> %s;" % \
>>>> + (self.tc.sdkenv, cmd), shell=True)
>>>
>>> Just pass env to the check_output call, then you won't have to worry
>>> about resetting the parent process' env back to the original value.
>>
>> Could be but then we need the code for generate the env line so for
>> practically the result is the same.
>
> Modify avoid_paths_in_environ() to instead return the environment rather
> than modify it as a side effect. Then the code reads more easily and
> prevents future bugs where someone uses avoid_paths_in_environ, but
> forgets to reset the os.environ.
I agree with you to modify avoid_paths_in_environ for return the new
PATH variable is better than only modify it internally but for
simplicity i will maintain the os.environ['PATH'] set/restore instead of
generate the environment line.
>
>>
>>>
>>>> + except:
>>>> + os.environ['PATH'] = paths
>>>> + raise
>>>> +
>>>> + os.environ['PATH'] = paths
>>>> + return output
>>>>
>>>> def getmodule(pos=2):
>>>> # stack returns a list of tuples containg frame information
>>>>
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160222/9614fcc1/attachment-0002.sig>
More information about the Openembedded-core
mailing list