"Richard Purdie via lists.openembedded.org"
<richard.purdie=linuxfoundation....@lists.openembedded.org> writes:
> 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?
Addition of new compilers seems to be very rare in OE.
> I'm leaning to a generic mechanism
If there is a simpler solution right now, it might be better to go with
that for now. If/when a new compiler appears, a better solution could be
implemented. And until then, I think it is safe to assume that a lot of
people would be happy if we could avoid making things more complicated.
> 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.
/Esben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2096):
https://lists.openembedded.org/g/openembedded-architecture/message/2096
Mute This Topic: https://lists.openembedded.org/mt/110536181/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
