Proposal for adding new GOARCH and GOOS

[minux]

Hi gophers,

In the Go 1.5 cycle we will introduce three new GOARCHes values:

     arm64, ppc64, ppc64le

From experience, introducing new GOARCHes or GOOSes has always

been problematic for our users and us:

Older releases don't recognize the new GOARCH, GOOS, which means

we can't use those GOOS/GOARCH in file names (we have to add

explicit build tags). This affects the x/sys repos mostly. And also we risk

conflict of custom build tags used by the users (this happened at least

once, for the android GOOS).

I filed #10165 to reserve common architectures as GOARCHes (CL 9644),

Brad brought up the question of reserving GOOSes. Unlike architectures,

the world of OS is much more diverse, so it's impossible to reserve all

possible GOOSes that Go is willing to support. Because we can't predict

the future, reserving known GOOS/GOARCH approach is not going to be

scalable.

Instead of reserving known GOOSes and GOARCHes, I propose that

we reserve the prefix "os-" and "arch-", and never add new GOOS or

GOARCH to the go/build package without such prefixes from Go 1.6

and on.

For example, suppose we accept a port for minix3, we will add os-minix3

to the list of GOOSes, and filenames and build tags will need to use "os-minix3" instead of just "minix3".

When used in $GOOS/$GOARCH or runtime.GOOS/GOARCH, because

there won't be any ambiguity, the non-prefixed form will be used.

For consistency, go/build package will also accept "os-" and "arch-" prefix

for existing GOOSes/GOARCHes. This will simplify build tag generation,

as you can always prepend "os-"/"arch-" (of course, it's still preferable to

use the unprefixed forms if we need to support older Go releases).

This is a late proposal for Go 1.5, but I think it will solve a problem in the

long run and as we're introducing a lot more GOARCHes in this cycle,

reserving the "os-" and "arch-" prefix is better done in the same cycle to

avoid disruption.

What do you think?

Sincerely,

Minux

[Andrew Gerrand]

An observation: putting a dash in an GOOS or GOARCH value will certainly break code that splits OS-ARCH on dashes, of which there is much.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aram Hăvărneanu]

Putting a newgoos build tag in foo_newgoos.go solves the problem,
since the old releases won't have the newgoos tag enabled.

--
Aram Hăvărneanu

[minux]

On Tue, May 5, 2015 at 6:19 PM, Aram Hăvărneanu <ara...@mgk.ro> wrote:

Putting a newgoos build tag in foo_newgoos.go solves the problem,
since the old releases won't have the newgoos tag enabled.

But the user might have that build tag and go build/install -tags applies to

all packages being built (think android for an example, the problem of which

prompted us to refine the filename rules in Go 1.4). The main part of the

proposal is to reserve the prefixed space for future additions.

[Aram Hăvărneanu]

I highly doubt people have minix3 and qnx build tags. I think android
was an exception.

--
Aram Hăvărneanu

[minux]

On Tue, May 5, 2015 at 6:15 PM, Andrew Gerrand <a...@golang.org> wrote:

An observation: putting a dash in an GOOS or GOARCH value will certainly break code that splits OS-ARCH on dashes, of which there is much.

I'll refine the prefix, let's use "os." and "arch.".

This is compatible with the current build tag rules.

[minux]

On Tue, May 5, 2015 at 6:31 PM, Aram Hăvărneanu <ara...@mgk.ro> wrote:

I highly doubt people have minix3 and qnx build tags. I think android
was an exception.

The problem also occurs the other way around.

Having a file_minix3.go will suddenly be excluded when we introduce a port

to minix3.

[Aram Hăvărneanu]

If a user has a file named file_minix3.go, I have no sympathy.

--
Aram Hăvărneanu

[minux]

BTW, the original proposal was for os_ and arch_, but I think it might

lead to ambiguity in filename parsing.

[Ian Lance Taylor]

But using dots is concerning to. On the well known Go operating
system we have

foo-os.go.go

Ian

[minux]

It will be foo_os.go.go, or if we use "os_" as prefix, foo_os_go.go, i think neither looks

good, but we can't keep growing the GOOS list unconstrained either. Not to mention

that having a go build tag is much worse than os-go, os_go or os.go.

[Russ Cox]

There are lots of ways to write code that depends on something added in (say) Go 1.5. Writing a file called x_arm64.go and expecting it to build only on arm64 is just one of those ways. (Others include using new API or expecting behavior introduced this cycle from existing routines.) There is a general solution that handles all these cases: add a "// +build go1.5" build tag if you need to keep working with older versions.

I am not in favor of trying to future-proof the specific case of GOOS/GOARCH. Given the triviality of the existing solution, changes here are a lot of churn for very little added benefit.

Russ

[minux]

On Tue, May 5, 2015 at 7:55 PM, Russ Cox <r...@golang.org> wrote:

There are lots of ways to write code that depends on something added in (say) Go 1.5. Writing a file called x_arm64.go and expecting it to build only on arm64 is just one of those ways. (Others include using new API or expecting behavior introduced this cycle from existing routines.) There is a general solution that handles all these cases: add a "// +build go1.5" build tag if you need to keep working with older versions.

I am not in favor of trying to future-proof the specific case of GOOS/GOARCH. Given the triviality of the existing solution, changes here are a lot of churn for very little added benefit.

The only problem of adding "// +build go1.5" build tag is if you want to conditionally

include .syso files (which, by definition, will be GOOS/GOARCH dependent.)

This future-proof of GOOS/GOARCH problem arises when we discussed reserving

GOOS values too, but couldn't come up with a list. Reserving GOARCH values is

fairly straightforward, and the current list should suffice for a long time.