From: "Aníbal Limón" <anibal.limon@linux.intel.com>
To: Joshua Lock <joshua.g.lock@linux.intel.com>,
Patrick Ohly <patrick.ohly@intel.com>
Cc: saul.wold@intel.com,
OpenEmbedded <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper
Date: Thu, 30 Mar 2017 11:07:49 -0600 [thread overview]
Message-ID: <58DD3B65.9020503@linux.intel.com> (raw)
In-Reply-To: <1490893081.1227.5.camel@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]
On 03/30/2017 10:58 AM, Joshua Lock wrote:
> On Thu, 2017-03-30 at 10:43 -0600, Aníbal Limón wrote:
>>
>> 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.
>
> Those are all build-directory state, not items which are tracked in the
> git repository.
>
> Rather than cloning repositories to ensure clean state your script
> could ensure a unique/new build directory by sourcing oe-init-build-env
> with a non-standard build directory, perhaps checking whether the
> directory exists first and adding random characters until you get
> something new?
That's a very good idea, i can generate tmp build directory and in this
way we can delete the logic for clone a new repository, so if anyone
reject, i'll do that.
Anibal
>
> Joshua
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2017-03-30 17:04 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
2017-03-30 16:58 ` Joshua Lock
2017-03-30 17:07 ` Aníbal Limón [this message]
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=58DD3B65.9020503@linux.intel.com \
--to=anibal.limon@linux.intel.com \
--cc=joshua.g.lock@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.