I don't actively use go anywhere, so don't have strong opinion either way,
but from this description it looks like ASSUME_PROVIDED should be supported
as well, if someone manages his "perfectly good Go toolchain" in his
containers/OSs used in OE builds, then replacing it with another prebuilt
"perf
On Fri, Jun 12, 2020 at 01:41:41PM +0100, Ross Burton wrote:
>...
> With preferred provider set this can be used to build our own Go
> toolchain. Yes, we're relying on a prebuilt binary but we're still
> building the tools we actually use, so I don't see this as massively
> different to using a ho
Hi,
Background: Go is written in Go. This obviously presents an
interesting bootstrapping problem.
The current build process is as follows:
1) Build Go 1.4 (from 2014) for native builds (go-native.bb). Go 1.4
was the latest release to be written in C, so this just needs a C
compiler.
2) Using
