From: "Aníbal Limón" <anibal.limon@linux.intel.com>
To: Randy Witt <randy.e.witt@linux.intel.com>,
openembedded-core@lists.openembedded.org
Cc: paul.eggleton@linux.intel.com, "Aníbal Limón" <limon.anibal@gmail.com>
Subject: Re: [PATCH 2/4] classes/testsdk: Move the removal of bitbake PATH to eSDK context only
Date: Mon, 22 Feb 2016 10:37:29 -0600 [thread overview]
Message-ID: <56CB3949.5030804@linux.intel.com> (raw)
In-Reply-To: <56CB35E8.6060301@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4132 bytes --]
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@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@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
>>>>
>>>
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2016-02-22 16:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 15:03 [PATCH 0/4] Add extensible SDK update test Aníbal Limón
2016-02-22 15:03 ` [PATCH 1/4] classes/testsdk: Move code for avoid PATHs to oeqa.utils Aníbal Limón
2016-02-22 15:03 ` [PATCH 2/4] classes/testsdk: Move the removal of bitbake PATH to eSDK context only Aníbal Limón
2016-02-22 15:54 ` Randy Witt
2016-02-22 16:09 ` Aníbal Limón
2016-02-22 16:23 ` Randy Witt
2016-02-22 16:37 ` Aníbal Limón [this message]
2016-02-22 16:48 ` Burton, Ross
2016-02-22 17:05 ` Aníbal Limón
2016-02-22 17:27 ` Randy Witt
2016-02-22 17:47 ` Aníbal Limón
2016-02-22 18:04 ` Aníbal Limón
2016-02-22 15:03 ` [PATCH 3/4] classes/testsdk: Pass tcname to SDK and SDKExt contexts Aníbal Limón
2016-02-22 15:03 ` [PATCH 4/4] oeqa/sdkext: Add sdk_update.SDKUpdateTest class Aníbal Limón
2016-02-22 16:18 ` Randy Witt
2016-02-22 16:26 ` Aníbal Limón
2016-02-22 16:36 ` Randy Witt
2016-02-22 17:10 ` Aníbal Limón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CB3949.5030804@linux.intel.com \
--to=anibal.limon@linux.intel.com \
--cc=limon.anibal@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
--cc=randy.e.witt@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox