Re: [PATCH v7 3/3] meta: Deploy image build artifacts into distro- and image-specific subdirs

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 25.03.26 17:41, Baurzhan Ismagulov wrote:
> On 2026-03-24 15:48, 'Jan Kiszka' via isar-users wrote:
>>> My earlier explanation regarding the "timestamp" was not accurate. The
>>> timestamp reflects when the BitBake build was started. In a multiconfig
>>> build
>>> where two configs are built in the same command, the timestamp is identical
>>> and therefore cannot be used to distinguish between the two configs.
>>>
>>> OE separates multiconfig builds by using different TMPDIRs, for example by
>>> adding the following to each multiconfig .conf file:
>>>   TMPDIR .= "-${BB_CURRENT_MC}"
>>>
>>> This results in different build directories such as "tmp-qemuarm64" and
>>> "tmp-qemuarm64kerneldebug". Build artifacts with the same names but
>>> different
>>> contents from two configs do not collide with each other.
>>>
>>> If we configure two multiconfig .conf files to use the same TMPDIR,
>>> conflicts
>>> can occur and OE does not handle that. Artifacts with the same name
>>> overwrite
>>> each other, and the build results become incorrect.
>>>
>>> In this way, the logic of the Isar build tmp directory differs from OE.
>>> Do we
>>> need to document these differences in the commit message?
>>
>> This should definitely be documented.
>>
>> But we should also step back and reconsider the strategy here: Are we
>> really addressing all conflicts this way that OE resolves via separate
>> TMPDIRs, or will we have to fix more in the future while OE does not?
>> This here is a path-breaking change, thus should not be taken lightly
>> when it is not the final solution (most likely).
>>
>> Otherwise, it might be safer to "just" adopt the OE pattern and resolve
>> the issue this way. Unless that has other downsides.
> 
> We'll send v8 with more info on this. I'd like to have it merged and proceed
> with the release.
> 
> Regarding the strategy, I still think we should only cover the use cases we
> have right now, because when the potential use cases really occur, a generic
> solution can look differently. This is for sure not the last occasion where we
> change the paths.
> 
> "Different tmp per dtb" is in my opinion an overkill after we've split
> tmp/deploy. A similar approach caused dependency issues in a downstream and our
> current "isar-installer" multiconfig could also be affected by it. In general,
> OE's "split tmp" approach looks like a workaround to avoid dealing with
> multiconfig issues; but in Isar, multiconfigs are a core feature, so I think a
> deviation is justified.

A tmp split would go beyond dtbs. And I still haven't read concretely
what makes Isar so different from OE when it comes to deployment.

Irrespective of that, multiconfig is not as prominently used with Isar
as it is used in Isar itself. The vast majority of downstream
deployments is single config. The only unavoidable use cases are
installer-like scenarios (image-in-image). Whenever you can build
separately, you parallelize, even when duplicating some steps. Only few
downstreams can wait for builds as long as we do in upstream for the
testsuite.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/30fc26f8-c8fc-4647-811e-df76a909ccc7%40siemens.com.