Agree. But this should IMHO be done on a per-package level (we can
simply sprinkle a ISAR_CROSS_COMPILE=0 into the recipes of the
incompatible packages). We already do this today. This series is
actually tested on -t alltargets :)
>
> If we keep it, the question is what the proper testing scope should be.
> I'm afraid the scope is still full.
Can't we use the -p cross override, maybe by making it a tristate
(0,1,auto) or something like that? The emulated compilation of the
kernels is *horribly* slow, while we at the same time miss targets by
not running the full-ci because it takes too long.
My hope would be, that we can build the whole testsuite in both cross
and no-cross, whereby the recipes internally fall back to emulation if
cross is not supported.
>
> So we probably still need to keep both aspects (cross vs. native, and
> some-targets vs. all-targets) but split them explicitly in the code. The
> exact implementation is open, e.g. separate full-cross / full-native jobs,
> or only full with like TEST_CROSS=1.
Both possible. For me it is important to have a fast CI with broad
coverage of targets. Next week I will send out patches to support
bitbake hash equivalence . This makes the testsuite blazing fast when
re-running in most cases. I'm already running this locally for a couple
of weeks and fine-tuning it. And it only needs ~150GB of sstate cache.
>
> IIRC Anton has been working on this topic, see [1]. It's better to hear
> his opinion as well, he'll be back next week.
Sure! It's not urgent.
PS: feel free to apply patches 1 and 2 already.
Felix
Sounds like a plan. Do you want to implement this - as you already seem
to have a precise idea - or shall I give it a try?
>
> It looks like none of downstreams are using ISAR_CROSS_COMPILE=0 in
> local.conf
> currently.
Same on our end.
Felix
That should be possible. Will send a v2.
Felix
Hi, again the hidden dependencies. I will send a v3 to fix it.
BUT... Can we please get rid of the hidden inter-test dependencies by
simply moving the startvm tests into the build tests? This has bitten
us too many times (or move to pytest which can model inter-test
dependencies).
Felix