Re: [PATCH 0/4] Rework isar-apt

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2018-02-01 17:54, Alexander Smirnov wrote:
> 
> 
> On 02/01/2018 07:25 PM, Jan Kiszka wrote:
>> On 2018-02-01 17:22, Alexander Smirnov wrote:
>>> On 02/01/2018 07:14 PM, Jan Kiszka wrote:
>>>> On 2018-02-01 12:29, Alexander Smirnov wrote:
>>>>> Hi all,
>>>>>
>>>>> this series intended to make buildchroot able to work with isar-apt.
>>>>> I've tried to add extended comments to each patch.
>>>>>
>>>>> Impact: with this series I'm able to build 'example-hello' <->
>>>>> 'libhello'
>>>>> without any hacks. So the deps are installed automatically.
>>>>>
>>>>> NOTE: I've migrated to bitbake [lockfiles] mechanism, don't know how
>>>>> robust it
>>>>> is, but build in the loop started in the evening didn't fail during
>>>>> the night.
>>>>>
>>>>
>>>> I can happily report: It works as promised also for my use case
>>>> (jailhouse.bb -> linux-jailhouse.bb, both Isar-built).
>>>>
>>>
>>> Thanks! But I've found an issue with events. :-( Our bitbake didn't
>>> handle them for multiconfig, the following patch seems to add this:
>>>
>>> https://patchwork.openembedded.org/patch/141626/
>>>
>>> Events is very good mechanism to clean up Isar build from pending mounts
>>> without headache with build fails, so I think it would be valuable to
>>> try latest bitbake. I'll report the results as soon as build finishes.
>>
> 
> From the first like I like it:
> 
>  - build output looks more user-friendly:
> 0: mc:qemui386-jessie:example-hello-0.2+7bf716d2-r0 do_build - 222s (pid
> 15637)
> 
>  - Yes! Events are now handled by all instances, so no more pending
> mounts. :-)

Even on ^C^C (forced termination)? That would be valuable!

> 
>> Perfect: Claudius just told me we need to update bitbake anyway to have
>> proper multiconfig support (i.e. no more hacky copying of files during
>> isar-init-build-env). Claudius, which version at least?
>>
> 
> Hmm, didn't get what is "hacky copying"...

That we only pick up an use multiconfig/ files from meta-isar, not any
other layer. See
https://groups.google.com/forum/#!msg/isar-users/IjQTuBFLPLo/IqRREtAHBgAJ

> 
>> BTW, why are we copying bitbake in? Wouldn't a submodule make more sense?
>>
> 
> In my opinion not, the main idea is the same as for Yocto - have no
> external dependencies. Isar should be self-contained.

That wouldn't change. You would still have both artifacts in the tree,
after checkout. And you could tar them both together for release
packaging. Or what are the concrete downsides?

I'm not using submodules heavily, but here would be a good use case IMHO.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux