Re: [meta-arm] External toolchain support

["Denys Dmytriyenko" <denis@denix.org>]

On Fri, Jun 12, 2020 at 01:34:02AM -0400, Denys Dmytriyenko wrote:
> On Thu, Jun 11, 2020 at 07:44:26PM +0530, Sumit Garg wrote:
> > On Thu, 11 Jun 2020 at 07:31, Denys Dmytriyenko <denis@denix.org> wrote:
> > >
> > > and no public review
> > > of Linaro-originated changes by using internal gerrit instead of public
> > > mailing list. The last one I didn't realize until later time. Often I would
> > > get an unnoticed run-time breakage introduced by some recent change in the
> > > recipe that didn't account for all our extensive downstream use cases. As
> > > there were no patches on the list, no reviews, no heads-up, I would scramble
> > > around in order to fix new breakages and in most cases would try to submit the
> > > fix upstream. Only to get them broken later due to the mentioned process
> > > downsides. I did mention couple of such instances recently [6][7]...
> > 
> > I guess it would have been better if you had added a complete feature
> > in upstream (say to support SDK or native compilation) instead which
> > could be tested standalone using external-toolchain recipe rather than
> > fragile dependencies that could only be tested with your downstream
> > project.
> 
> Well, it's not like I didn't try... :)
> 
> Some things were more straightforward and I had those upstreamed for the most 
> part. But other things were more controversial, when I was discussing those 
> back in the day, like external runtime + internal compiler or OE-built SDK + 
> external compiler. From OE perspective external toolchains are evil (or at 
> least a very foreign concept), so once you start mixing things, people get 
> upset, hence the pushback. That made those features scattered between upstream 
> and downstream, unfortunately.

Oh, forgot to mention! To support those extra features, changes had to be made 
outside of external-toolchain recipe, which may have contributed to them being 
considered controversial...

For example, external-arm-toolchain recipe only packages runtimes (headers, 
libs, stubs, target binaries), but not the host/cross binaries, as it 
basically extends glibc-package.inc from OE-Core. I have an additional recipe 
called external-arm-sdk-toolchain (not the best name), that packages prebuilt 
gcc, gdb, binutils binaries from EAT into proper *-cross-canadian-$ARCH 
packages, which could then be easily pulled into SDK.

We've been using meta-toolchain way of building SDKs from the early days, 
before "<rootfs> -c populate_sdk" was introduced. Some of the toolchain/SDK 
interaction and processing was added there, like packaging SDK w/o the 
toolchain, or establishing some symlinks between OE compiler and EAT runtime. 
Those don't make sense for the rootfs, hence meta-toolchain based SDK remained 
in use for us. Plus we build multiple rootfs images with different content, 
but a single complete SDK to cover them all, so "<rootfs> -c populate_sdk" to 
match the rootfs didn't make sense for our product...

I don't mean this to block a more appropriate re-implementation upstream, if 
needed, of course. I'm open to collaboration and re-design, but would like 
this to be a two-way road. Thanks.


> Plus I had some setbacks with aforementioned breakages...
> 
> But I still plan to contribute and if we find a consensus, I'd be happy to get 
> the rest of the features upstreamed.

-- 
Denys