On Mon, 2025-01-13 at 14:29 +0000, Paul Barker wrote:
> 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?
What then happens with a new compiler which isn't clang or gcc? I'm
leaning to a generic mechanism and some include files which force a
given recipe to/away from a particular compiler. Yes, you will be able
to misconfigure it but you'd hopefully have to explicitly do it once we
have the right exclusion lists sorted out.
I agree the "preferred" naming isn't ideal but it is the existing
mechanism and I think it would be more confusing to rename it or add a
second level of indirection.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2089):
https://lists.openembedded.org/g/openembedded-architecture/message/2089
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]]
-=-=-=-=-=-=-=-=-=-=-=-
