5 ms·

Ugh...this is going to make new ports such a pain. I can understand why they're doing it, but this is going to make my life a lot more difficult. If 1.4 is go

Ugh...this is going to make new ports such a pain. I can understand why they're doing it, but this is going to make my life a lot more difficult. If 1.4 is going to become the bootstrap toolset, that also suggests that 1.4 will essentially become "long-term supported", meaning that if new ports require fixes to the bootstrap toolset (even in the cross-compilation) scenario, hopefully they'll accept those changes upstream.

abtinf 12y ago
I'm not sure I understand why this makes ports harder. Shouldn't it be possible to port to a new system simply by porting Go 1.4 to that system? Once that base version is ported, a script can build 1.4, then build 1.5 and any succeeding base versions until the current version is reached. Of course, system-specific features would have to be added for each go release beyond 1.4, but that would have to be done anyway. What am I missing?
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
  - rsc 12y ago
    No no no no no no no no no. THIS IS NOT TRUE. See the discussion with binarycrusader on this very page.
rsc 12y ago
What new ports are you working on? (I'm just curious.) Go is already very good at cross-compiling. That can be used to do a new port (as a trivial example, the fact that the compiler doesn't run on NaCl didn't hurt the NaCl port at all). There is a section in the doc explicitly about this. We are doing new ports too (like power64), and I don't anticipate the bootstrapping change slowing them down appreciably.
- deleted 12y ago
  [deleted]
  - rsc 12y ago
    > But Go only cross-compiles well for platforms and architectures it currently supports ;-) This is an odd thing to say. Go cross-compiles exactly as well as it compiles. If you write a go_YOUROS_YOURARCH_exec script that copies the binary over to your target system and runs it, you can sit at any working system (for concreteness, any x86 system running Linux, OS X, or Windows) and work in a full Go environment. That's actually better than sitting on an unsupported system editing C files and unable to run any program written in Go.
rsc 12y ago
Also, there is no dependency on 1.4 being "long-term supported". I think you have the dependency requirement backward. For the foreseeable future, it must be possible to build the compiler with Go 1.4. That means the compiler must stick to Go 1.4 libraries and constructs (or use build tags for conditional compilation). It says nothing about which version of Go you have to use to build the compiler. If we're working on Go 1.9 and you want to use Go 1.7 as the bootstrap base, that's fine: Go 1.7 will build and run everything that Go 1.4 does. You just can't introduce any Go 1.7-specific code into the compiler. I don't know if you've noticed, but there are very few language changes in each release. We're focused on improvements to performance and reliability more than new features. So I don't anticipate it being a hardship that the compiler is limited to Go 1.4. (And that's still much nicer than C.)
- binarycrusader 12y ago
  Well, if Go 1.4 is the last version almost entirely written in C, then for unsupported architectures/platforms, it seems like it would be the easiest to port first before bootstrapping a new version of Go. Is that not the case? I don't feel like I have this backwards at all. I wasn't commenting on it being a hardship to limit the implementation to Go 1.4's feature set.
  - rsc 12y ago
    I don't see much point to doing two ports (of very different versions of the code base) when you can do one port (of the current version, via cross-compilation) and then copy the result over to your target system and use that as the bootstrap base for future ports. For example, Go 1.4 did not support linux/ppc64, but Go 1.5 will. If you want to build Go 1.5 for linux/ppc64 from source, the simplest thing to do is to cross-compile it on a linux/amd64 system, copy the resulting binaries over to your linux/ppc64 system, and use that toolchain as the bootstrap base for any future work. Doing two ports would work, but the first one is basically wasted effort unless you need to survive every other supported Go system disappearing tomorrow.
    - binarycrusader 12y ago
thomasahle 12y ago
Can't you just write code generation for platform Y while on platform X? I guess you would have to do a bit of copying files around while debugging, but that shouldn't be the main issue when porting a system like this..
codyps 12y ago
I don't understand why you need a bootstrap toolset in C. Does go not support being cross compiled/cross compiling?

abtinf 12y ago

I'm not sure I understand why this makes ports harder. Shouldn't it be possible to port to a new system simply by porting Go 1.4 to that system? Once that base version is ported, a script can build 1.4, then build 1.5 and any succeeding base versions until the current version is reached. Of course, system-specific features would have to be added for each go release beyond 1.4, but that would have to be done anyway. What am I missing?

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
- rsc 12y ago
  No no no no no no no no no. THIS IS NOT TRUE. See the discussion with binarycrusader on this very page.

rsc 12y ago

What new ports are you working on? (I'm just curious.) Go is already very good at cross-compiling. That can be used to do a new port (as a trivial example, the fact that the compiler doesn't run on NaCl didn't hurt the NaCl port at all). There is a section in the doc explicitly about this. We are doing new ports too (like power64), and I don't anticipate the bootstrapping change slowing them down appreciably.

deleted 12y ago
[deleted]
- rsc 12y ago
  > But Go only cross-compiles well for platforms and architectures it currently supports ;-) This is an odd thing to say. Go cross-compiles exactly as well as it compiles. If you write a go_YOUROS_YOURARCH_exec script that copies the binary over to your target system and runs it, you can sit at any working system (for concreteness, any x86 system running Linux, OS X, or Windows) and work in a full Go environment. That's actually better than sitting on an unsupported system editing C files and unable to run any program written in Go.

rsc 12y ago

Also, there is no dependency on 1.4 being "long-term supported". I think you have the dependency requirement backward. For the foreseeable future, it must be possible to build the compiler with Go 1.4. That means the compiler must stick to Go 1.4 libraries and constructs (or use build tags for conditional compilation). It says nothing about which version of Go you have to use to build the compiler. If we're working on Go 1.9 and you want to use Go 1.7 as the bootstrap base, that's fine: Go 1.7 will build and run everything that Go 1.4 does. You just can't introduce any Go 1.7-specific code into the compiler. I don't know if you've noticed, but there are very few language changes in each release. We're focused on improvements to performance and reliability more than new features. So I don't anticipate it being a hardship that the compiler is limited to Go 1.4. (And that's still much nicer than C.)

binarycrusader 12y ago
Well, if Go 1.4 is the last version almost entirely written in C, then for unsupported architectures/platforms, it seems like it would be the easiest to port first before bootstrapping a new version of Go. Is that not the case? I don't feel like I have this backwards at all. I wasn't commenting on it being a hardship to limit the implementation to Go 1.4's feature set.
- rsc 12y ago
  I don't see much point to doing two ports (of very different versions of the code base) when you can do one port (of the current version, via cross-compilation) and then copy the result over to your target system and use that as the bootstrap base for future ports. For example, Go 1.4 did not support linux/ppc64, but Go 1.5 will. If you want to build Go 1.5 for linux/ppc64 from source, the simplest thing to do is to cross-compile it on a linux/amd64 system, copy the resulting binaries over to your linux/ppc64 system, and use that toolchain as the bootstrap base for any future work. Doing two ports would work, but the first one is basically wasted effort unless you need to survive every other supported Go system disappearing tomorrow.
  - binarycrusader 12y ago

thomasahle 12y ago

Can't you just write code generation for platform Y while on platform X? I guess you would have to do a bit of copying files around while debugging, but that shouldn't be the main issue when porting a system like this..

codyps 12y ago

I don't understand why you need a bootstrap toolset in C. Does go not support being cross compiled/cross compiling?