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 "perfectly good Go toolchain" from someone else might be unnecessary step.
On Fri, Jun 12, 2020 at 2:41 PM Ross Burton <r...@burtonini.com> wrote: > 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 go-native, build a modern Go cross compiler (go-cross.bb). > 3) Using go-cross you can now build target Go code. Success! > > However this solution isn't ideal as Go 1.4 only supports a limited > number of hosts: i386, x86-64, and 32-bit Arm. We've 64-bit Arm > machines in the autobuilder cluster, and we've seen people use PowerPC > build hosts too. > > There are other ways to bootstrap Go: > - Prebuilt toolchain. Go make binary releases for Linux on 32- and > 64-bit x86 and Arm. Pros: works on more platforms. Cons: As Go has > the nice feature that any Go compiler can target any > platform/architecture, we're now downloading a full working Go to > rebuild a full working Go. Why not just use this Go? > > - GCCGO. GCC has an optional Go frontend, which can be used to build > Go. Pros: we already have a gcc recipe. Cons: as we don't really want > to require gccgo on the host we'll need to build gcc-native, so why > not just build gcc-cross with Go enabled? > > With the goal of minimal changes I wrote an alternative to go-native > that uses the prebuilt binaries to build our own Go: > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/go&id=4b2a5a12ab2d898ab4b1d8524b90f4e3938d01cf > > 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 host compiler. Does anyone have a strong > objection to bootstrapping our own Go by downloading the prebuilt > tools? I could either replace the existing go-native with this, or > have both available so that users who don't want to rely on binaries > and are happy with the limitation of Go 1.4 can stick with the source > bootstrap. > > But looking forward, at this point we're downloading a perfectly good > Go toolchain to build a Go toolchain. This observation has already > led to meta-go-binary (https://github.com/YoeDistro/meta-go-binary), a > drop-in alternative for the Go recipes that simply use the pre-built > releases. Also modern GCC can also build a Go frontend, so we could > just enable that in gcc-cross as we're always building a cross > compiler anyway. Does anyone have a strong opinion either way on > this? > > Cheers, > Ross > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139439): https://lists.openembedded.org/g/openembedded-core/message/139439 Mute This Topic: https://lists.openembedded.org/mt/74838027/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
