On Fri, 2025-01-10 at 15:24 +0000, Richard Purdie via lists.openembedded.org
wrote:
> I've been thinking about how we could neatly handle the various
> "provider selection" challenges that multiple toolchains in OE brings.
>
> We currently have the concept of virtual/X providers but they're locked
> in on a global configuration level. For example "virtual/cc" would have
> one provider for all recipes. With clang, we really want a way to say
> whether that would be provided by clang or gcc on a per recipe basis.
>
> PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}cc = "gcc-cross-XXX"
> PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}cc:pn-bash = "clang-cross-XXX"
>
> I suspect (but haven't demonstrated with working code) that just
> handling virtual/XXX on a per recipe basis could be made to work. The
> code would effectively iterate DEPENDS after parsing and expand
> virtual/ references on a per recipe basis using PREFERRED_PROVIDER.
>
> There would be some interesting corner cases and it may be best to have
> a specific list of which virtual providers were expected to work on a
> per recipe basis but that idea should be manageable.
>
> Obviously this does throw some extra complexity into an already complex
> system but it might also make the clang integration much simpler.
>
> Thoughts? Worth exploring?
I've been giving this a bit more thought and I'm not sure we actually
need bitbake's help to implement this.
Firstly, I'm starting to wonder if we should simplify
"virtual/${TARGET_PREFIX}gcc" to something like "virtual/cc" and for
the sdk, "virtual/sdk-cc". I have such a patch basically working with
the exception of multilib which would involve throwing a MLPREFIX in
there or more neatly if optimistically, making the class extension code
tweak the providers for the current multilib.
You might ask the question, why not "virtual/nativesdk-gcc" and the
reason is that is a different compiler. "virtual/cross-cc" and
"virtual/cross-sdk-cc" would probably be the most accurate, if a bit
longer winded. I'm starting to lean to this more explicit version.
With that done, you can add some code like this to base.bbclass:
RECIPE_VIRTUAL_PROVIDERS = "virtual/cc"
# Handle recipe level PREFERRED_PROVIDERs
depends = (d.getVar("DEPENDS") or "").split()
virtprovs = (d.getVar("RECIPE_VIRTUAL_PROVIDERS") or "").split()
newdeps = []
for dep in depends:
if dep in virtprovs:
newdep = d.getVar("PREFERRED_PROVIDER_" + dep)
if not newdep:
bb.fatal("Error, recipe virtual provider PREFERRED_PROVIDER_%s not
set" % dep)
newdeps.append(newdep)
else:
newdeps.append(dep)
d.setVar("DEPENDS", " ".join(newdeps))
and at that point you expand "virtual/cc" into the PREFERRED_PROVIDER
on a per recipe basis at parse time.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2088):
https://lists.openembedded.org/g/openembedded-architecture/message/2088
Mute This Topic: https://lists.openembedded.org/mt/110536181/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
