Re: [meta-arm] Removal of external-arm-toolchain?
Ross Burton <[email protected]>
| Newsgroups | org.yoctoproject.lists.meta-arm |
|---|---|
| Message-ID | <[email protected]> |
On 23 Jan 2025, at 20:00, Denys Dmytriyenko <[email protected]> wrote: > That said, it appears there are some other users of external toolchain - there > was a person from Smile recently fixing some issues with usrmerge support. And > I just received a personal email from one of our customers inquiring about it > as well. In other words - there are other interested parties out there... At the time I asked Smile what their usecase was but I’ve forgotten already. I’ll reach out again. >> Also this is a prime use case for sstate, in particular the >> public yocto state server which can be used to fetch all the native tools, >> not just the compiler. > > This is probably a topic for another thread, but there are some issues with > using sstate like that - public yocto sstate server is very slow and just > checking what is available takes a very long time, plus cross toolchain is not > a native package and from my experience re-use is quite low in other distros. Try again if you haven’t recently: it has sped up a lot and I have a weekly cron job to verify that I can build packages using public sstate for the toolchain. >> So, would anyone seriously object if I sent a patch to remove the >> external-arm-toolchain recipe? This would only be for master, we wouldn’t >> retroactively remove it from the stable branches. > > As one of the meta-arm-toolchain co-maintainers[1], I would not object to > removing external-arm-toolchain support (the Linux side) from the layer. Thank you for being explicit. Copying in Sumit to get his feedback. > But, besides external-arm-toolchain, there are also recipes in the layer for > baremetal compilers, which are not proper cross- recipes, but they pretend > to be native- ones. That's very hacky and there are some drawbacks, while the > only benefit is speed, as those are also binary pre-builds. I was previously > suggesting replacing them with a proper baremetal multiconfig usage, like I > did in meta-ti for K3 platforms. And as I recall, you were interested in that > solution as well. If that's still the case, please let me know if you need any > help with that… That’s literally been an open jira that I filed internally about three days into starting at Arm… I’m still interested in that solution so really should have a look at what meta-ti is doing. Cheers, Ross