From: "Aníbal Limón" <anibal.limon@linux.intel.com>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: OpenEmbedded <openembedded-core@lists.openembedded.org>,
saul.wold@intel.com
Subject: Re: [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper
Date: Thu, 30 Mar 2017 10:43:01 -0600 [thread overview]
Message-ID: <58DD3595.1060209@linux.intel.com> (raw)
In-Reply-To: <1490890422.6396.459.camel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]
On 03/30/2017 10:13 AM, Patrick Ohly wrote:
> On Thu, 2017-03-30 at 10:03 -0600, Aníbal Limón wrote:
>>
>> On 03/30/2017 12:02 AM, Patrick Ohly wrote:
>>> On Wed, 2017-03-29 at 15:44 -0600, Aníbal Limón wrote:
>>> ...
>>>> +show_help() {
>>>> + printf "Usage: %s [-o output_log] [-h] LAYER_DIR ...\n" $0
>>>> +}
>>>> +
>>> ...
>>>> +env_dir=$(mktemp -d -t yocto-compat-XXXX)
>>>> +echo "The environment will be setup at $env_dir"
>>>> +echo ""
>>>
>>> The directory gets created, but not removed.
>>
>> I didn't remove the temp directory because may be the user wants to
>> access the dir after the check.
>
> I think that this should be something that the user explicitly needs to
> request. As it is now, accumulating directories in /tmp when invoking
> the script is just unexpected and not the normal behavior of tools
> creating something in /tmp.
Ok, i will add an option to don't delete and change the default behavior
to delete after check.
>
>>>> +echo "Cloning oe-core..."
>>>> +git clone $oe_core_repo $env_dir
>>>> +if [ $? -ne 0 ]; then
>>>> + echo "Failed to clone oe-core repository"
>>>> + exit 1
>>>> +fi
>>>> +
>>>> +echo "Cloning bitbake..."
>>>> +git clone $bitbake_repo $env_dir/bitbake
>>>> +if [ $? -ne 0 ]; then
>>>> + echo "Failed to clone bitbake repository"
>>>> + exit 1
>>>> +fi
>>>
>>> Cloning bitbake and OE-core each time the script runs will be fairly
>>> slow. There's also a chicken-and-egg problem: if you don't have bitbake,
>>> where's the script?
>>>
>>> I'd prefer to use an existing checkout of both, just as for the layers
>>> which are to be tested.
>>
>> I choose to clone the oe-core/bitbake to ensure there are a clean
>> environment, without any previous layer added.
>
> I don't quite get that argument. When using existing bitbake and OE-core
> directories, how can they have layers added to them? I understand that
> the existing checkout might contain additional modifications and/or
> might not match current master, but I consider that a feature. As it
> stands now, the caller of the script cannot test against Yocto 2.3 once
> it is released, because the script will always check out master.
>
> Control over that can of course also be added to the script, but I just
> don't see the need for all this additional complexity. Just my 2 cents.
That's the original issue to create this script, if a user tries to
validate a layer and has modifications in configuration (bblayers,
local, auto), the check will be contaminated in some how.
If you want to run in some previous cloned repository you can use
directly the yocto-compat-layer.py without the wrapper.
>
>> I could add an option to
>> specify a oe-core/bitbake dir if isn't set then clone.
>
> At the very least please do that.
Yes i will do.
Anibal
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2017-03-30 16:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 21:44 [PATCH 1/2] scripts/lib/compatlayer: detect_layers always use realpath's Aníbal Limón
2017-03-29 21:44 ` [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper Aníbal Limón
[not found] ` <1490853745.6396.439.camel@gmx.de>
[not found] ` <58DD2C5B.8010704@linux.intel.com>
2017-03-30 16:05 ` Aníbal Limón
2017-03-30 16:13 ` Patrick Ohly
2017-03-30 16:43 ` Aníbal Limón [this message]
2017-03-30 16:58 ` Joshua Lock
2017-03-30 17:07 ` 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=58DD3595.1060209@linux.intel.com \
--to=anibal.limon@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick.ohly@intel.com \
--cc=saul.wold@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