Openembedded Core Discussions
 help / color / mirror / Atom feed
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 --]

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox