Re: [meta-ti][master/kirkstone][PATCH] bsp: multiconfig: k3r5: allow customization by donwstream layers

[Ricardo Salveti <ricardo@foundries.io>]

On Mon, Jan 30, 2023 at 2:57 PM Jose Quaresma <quaresma.jose@gmail.com> wrote:
> Denys Dmytriyenko <denis@denix.org> escreveu no dia segunda, 30/01/2023 à(s) 17:18:
>>
>> On Mon, Jan 30, 2023 at 11:02:25AM -0600, Ryan Eatmon via lists.yoctoproject.org wrote:
>> >
>> >
>> > On 1/30/2023 9:20, Jose Quaresma wrote:
>> > >This patch adds the possibility to change some bitbake variable
>> > >that cannot be changed anywhere else, one of then is the TMPDIR.
>> > >
>> > >Using the same TMPDIR it is very sensitive and prone to several errors
>> > >when used in more complex situations.
>> > >This configuration forces that all native packages have to be the same between all
>> > >machines and this requirement is very easy to break.
>> > >Suppose you use a macinhe override somewhere on a native recipe
>>
>> Even w/o multiconfig, this will break for multi-machine builds. Native
>> packages are for the build host and have no knowledge about the target.
>> You should probably look into cross packages instead of native ones for
>> this use case.
>>
>> Altering native packages between different targets will cause them to
>> rebuild, which they shouldn't. Moreover, it will mess up your sstate
>> and lead to weird issues down the road when trying to re-use your
>> sstate mirror/cache.
>
> Is that the issue of rebuilding some native packages that I am trying to avoid.
> But it is very hard to fix this in OE-core and everything else layers what happens.
>
> For your information I have some other issues with multiconfig and native packages
> that have the source files provided on the layer. this two recipes don't work with the
> rm_work bbclass because the in one of the machines
> texinfo-dummy-native gettext-minimal-native
>
> Another issue is that sometimes one of the machines uses the SOURCE_DATE_EPOCH_FALLBACK
> and the other uses  SOURCE_DATE_EPOCH and this also triggers a rebuild of one of the machines.
>
> Recently a new issue with the rm_work and the spdx
> comes in https://lists.openembedded.org/g/openembedded-core/message/174276
> where I have the steps to reproduce.
>
> All of these issues can be solved easily with TMDIR for each machine,
> but because I understand it can be invasive I submit this patch that doesn't change anything
> in meta-ti but can add the possibility to use a different TMPDIR for each machine.
>
> A different TMPDIR for each machine is also referenced in the official documentation
> "Minimally, each configuration file must define the machine and the temporary directory BitBake uses for the build. Suggested practice dictates that you do not overlap the temporary directories used during the builds."
> https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-intro.html#executing-a-multiple-configuration-build
>
>> > >and this requirement is no longer met.
>> > >Many of these anomalies can be verified with the use of the rm_work and
>> > >create-spdx bitbake classes.
>> > >
>> > >A previous attempt [1] had already been made but was refused
>> > >but this way it can be done without side effects for other users.
>> > >
>> > >[1] https://lists.yoctoproject.org/g/meta-ti/message/14767
>> >
>> >
>> > So the difference between this patch and the previous one, is that
>> > you are now included a file that is not there normally so that you
>> > can put the contents of the previous patch in the new include file
>> > to get around the issue in the archiver.
>
> The archiver issue is fixed but it will be very easy to break again.
> Myself recently broke it again so I added a test to help there
> https://git.yoctoproject.org/poky/commit/?id=b5baa7dc8bd1c0d2d78c532d97a44120346b5edd
>
>> >
>> > I'm not saying I'm opposed to this approach (yet), I'm just trying
>> > to understand the entire story.
>> >
>> > Did you find anything in looking at fixing the archiver to better
>> > support the multi-config issue?
>
> The issue now is different and is related with spdx and rm_work
> https://lists.openembedded.org/g/openembedded-core/message/174276
>
> With this patch I can set a new TMPDIR folder for each machine and
> can build successfully.

If you don't have spdx enabled then these sort of issues happen less
often, but after the above patch was merged in oe-core (and also
backported to kirkstone), we cannot build multiconfig targets from
meta-ti anymore with spdx enabled.

This is special to spdx because of the way the task dependencies are
done, which requires it to be executed before rm_work. This is OK when
a machine specific TMPDIR is used and explodes quite quickly (due
races) when sharing TMPDIR because of the parallel rm_work tasks that
end up removing stuff that is still required by other parallel tasks.

Cheers,
-- 
Ricardo Salveti