[OE-core] [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper

[Aníbal Limón]

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
> 

-------------- 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/20170330/b08b25a6/attachment-0002.sig>