"Richard Purdie via lists.openembedded.org"
<[email protected]> writes:
> 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"
Given that this basically ends up in DEPENDS, I think this naming is
going to cause confusion. A variable that begins or ends with DEPENDS
would be more intuitive. Clearly my subjective opinion ofcourse.
> # 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.
/Esben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2097):
https://lists.openembedded.org/g/openembedded-architecture/message/2097
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]]
-=-=-=-=-=-=-=-=-=-=-=-
