On 10/01/2025 15:24, 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 think my only concern here is that 'PREFERRED_*' is treated as a preference rather than a hard dependency. Should we instead be replacing the dependency on virtual/cc with an explicit dependency on 'clang-cross-...' where only clang is supported or 'gcc-cross-...' where only gcc is supported? Thanks, -- Paul Barker
OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2087): https://lists.openembedded.org/g/openembedded-architecture/message/2087 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]] -=-=-=-=-=-=-=-=-=-=-=-
