FAQ
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

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Andrew Gerrand at May 5, 2015 at 10:16 pm
    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.
    On 6 May 2015 at 07:55, minux wrote:

    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 <https://goto.google.com/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 <https://goto.google.com/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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Aram Hăvărneanu at May 5, 2015 at 10:19 pm
    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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at May 5, 2015 at 10:28 pm

    On Tue, May 5, 2015 at 6:19 PM, Aram Hăvărneanu 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Aram Hăvărneanu at May 5, 2015 at 10:31 pm
    I highly doubt people have minix3 and qnx build tags. I think android
    was an exception.

    --
    Aram Hăvărneanu

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at May 5, 2015 at 10:39 pm

    On Tue, May 5, 2015 at 6:31 PM, Aram Hăvărneanu 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Aram Hăvărneanu at May 5, 2015 at 10:40 pm
    If a user has a file named file_minix3.go, I have no sympathy.

    --
    Aram Hăvărneanu

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at May 5, 2015 at 10:35 pm

    On Tue, May 5, 2015 at 6:15 PM, Andrew Gerrand 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at May 5, 2015 at 10:41 pm

    On Tue, May 5, 2015 at 6:34 PM, minux wrote:
    On Tue, May 5, 2015 at 6:15 PM, Andrew Gerrand 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.
    BTW, the original proposal was for os_ and arch_, but I think it might
    lead to ambiguity in filename parsing.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at May 5, 2015 at 10:48 pm

    On Tue, May 5, 2015 at 3:41 PM, minux wrote:
    On Tue, May 5, 2015 at 6:34 PM, minux wrote:
    On Tue, May 5, 2015 at 6:15 PM, Andrew Gerrand 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.
    BTW, the original proposal was for os_ and arch_, but I think it might
    lead to ambiguity in filename parsing.
    But using dots is concerning to. On the well known Go operating
    system we have

    foo-os.go.go

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at May 5, 2015 at 11:10 pm

    On Tue, May 5, 2015 at 6:48 PM, Ian Lance Taylor wrote:
    On Tue, May 5, 2015 at 3:41 PM, minux wrote:
    On Tue, May 5, 2015 at 6:34 PM, minux wrote:
    On Tue, May 5, 2015 at 6:15 PM, Andrew Gerrand 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.
    BTW, the original proposal was for os_ and arch_, but I think it might
    lead to ambiguity in filename parsing.
    But using dots is concerning to. On the well known Go operating
    system we have

    foo-os.go.go
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at May 5, 2015 at 11:55 pm
    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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at May 6, 2015 at 1:02 am

    On Tue, May 5, 2015 at 7:55 PM, Russ Cox 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedMay 5, '15 at 9:55p
activeMay 6, '15 at 1:02a
posts13
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase