build: provide a mechanism to disable architectures?

[bradfitz]

For build speed & binary size reasons, I would like to run make.bash with certain architectures disabled.

(my motivation: when I'm cross-compiling an ARM toolchain from Linux for #17105, there's no need for ppc64, mips64, s390x, arm64, 386, or even amd64 in my resulting binaries)

I started a prototype in https://golang.org/cl/29230 which defines build tags like "without_ppc64", "without_386", "without_s390x", etc.

The compiler and linker were easy. I decided to wait on cmd/asm until more discussion.

What do people think of something like this?

/cc @ianlancetaylor @mdempsky @randall77 @robpike @griesemer @josharian @rsc

[randall77]

Sounds ok. I'm surprised it was that easy. The SSA backend for all the architectures is still in there.

[griesemer]

For my own understanding: Such a cross-compiled tool chain for ARM would run on ARM but not be able to cross-compile on ARM for another toolchain anymore, correct?

Seems ok to me.

But I'm doing a double-take looking at the doubly negated build tags: !without_amd64 . Can't we be positive?

[mdempsky]

For the compiler, I would think you only need to touch cmd/compile/main.go. E.g., have

s390x_main.go:

// +build !without_s390x

package main
import "cmd/compile/internal/s390x"
func init() {
    mains["s390x"] = s390x.Main
}

main.go:

package main
var mains[string]func()
func main() {
    mains[obj.GOARCH]()
}

[ianlancetaylor]

(I saw the CL before the issue.)

I think adding build tags everywhere will be hard to maintain over time. mdempsky's idead sounds better to me if it works.

[mdempsky]

Oh, it looks like that's exactly the strategy you used for cmd/link even.

[bradfitz]

For my own understanding: Such a cross-compiled tool chain for ARM would run on ARM but not be able to cross-compile on ARM for another toolchain anymore, correct?

Seems ok to me.

Correct.

But I'm doing a double-take looking at the doubly negated build tags: !without_amd64 . Can't we be positive?

It's a little weird, but I can't think of a better way.

[bradfitz]

Oh, it looks like that's exactly the strategy you used for cmd/link even.

Yeah, I did that style for cmd/compile and cmd/link. I think cmd/asm might need different treatment.

But I wanted to make sure people were okay with this first.

[mdempsky]

I think cmd/asm just needs you to split up cmd/asm/internal/arch.go into GOARCH-specific arch.go files. arch.Set is the choke point there.

I'm okay with the idea if it's minimally intrusive like that. Do you have any numbers on how big a compile-time / executable-size win this is?

[rsc]

Let's punt this to next round.

Also, before committing to doing this, I'd like to see what the numbers are. You mention "build speed & binary size reasons". Please quantify those: how much faster does make.bash get, and how much smaller does the generated $GOROOT/pkg/tool dir get? It may be that the benefit is too small.

[bradfitz]

I agree about timing & need for numbers.

My prototype bitrot with a bunch of compiler changes & deletions, so I deleted my branch.

Can investigate later. I'll kick this to Go1.9Maybe with the understanding that we might close it without action, just so it's off the proposal dashboard.