FAQ
This less about the build tags, but drawing the distinction between
"language version" and "compiler version". Where for the golang `gc`
these two definitions may be the same. Though for `gccgo` the
"language version" may be 'go1.2.1' and the compiler version is gccgo
(GCC) 4.9.1.

Perhaps, the provision for this is an addition to runtime.Version(),
which ought to stay as the language/API version, that we have a
runtime.CompilerVersion() which could be easily updated with build
tags to be provided by the respective compilers.

Thoughts?


vb
On Fri, Oct 24, 2014 at 10:37 PM, Carlos Castillo wrote:
Can't you use a build tag to determine the api version of go?

If you are looking to change behaviour based on the version of go, it is the
best way, since it also provides conditional compilation which is very
important to satisfy all static compilation checks.

If you are looking for a string to print out (similar to what "go version")
provides, then I could see some value for such a feature (eg: for logging),
provided it was used, and documented as such, for display purposes only, and
not for program logic.

On Friday, October 24, 2014 10:06:13 AM UTC-7, Vincent Batts wrote:

Hey all,

In working with gccgo, I discovered that there is no god way to derive the
go API that is provided by the compiler. Since runtime.Version() is actually
the version of the gcc that is providing gccgo (which is also helpful, but
not the information I'm looking for).

After chatting with iant about this, he recommend we open this up for
larger conversation, as there are now more compilers than just `gc` and
`gccgo`.


Should we provide something parallel to runtime.Version that shows a
compiler version number separate from a version number that corresponds to
gc releases?


Thanks for your feedback,
vb
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+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.

Search Discussions

  • Peter Collingbourne at Oct 28, 2014 at 6:43 pm
    If someone is using the "gccgo" toolchain, the "go" tool should provide
    build tags corresponding to the compiler's language version. It currently
    does not do so, and this problem prevents me from bootstrapping llgo with
    newer versions of the "go" tool, as that tool provides the go1.4 build tag,
    which is used by some parts of go.tools to compile different code for Go
    1.4, while llgo is currently on Go 1.3.

    The problem to be solved is that there is currently no mechanism for the
    compiler to communicate its build tags to the "go" tool. I think there
    should be such a mechanism. I propose that "go" request a set of compiler
    tags from "gccgo" toolchains by executing "$GCCGO -dumpgotags" and reading
    the tags from stdout. For backwards compatibility with existing versions of
    gccgo/llgo, the "go" tool's built-in set of compiler tags would continue to
    be used if the exit status is non-zero.

    This will probably have to wait until after the 1.4 release, but it would
    be unfortunate if it were difficult/impossible to bootstrap llgo with 1.4.

    Peter
    On Tue, Oct 28, 2014 at 7:14 PM, Vincent Batts wrote:

    This less about the build tags, but drawing the distinction between
    "language version" and "compiler version". Where for the golang `gc`
    these two definitions may be the same. Though for `gccgo` the
    "language version" may be 'go1.2.1' and the compiler version is gccgo
    (GCC) 4.9.1.

    Perhaps, the provision for this is an addition to runtime.Version(),
    which ought to stay as the language/API version, that we have a
    runtime.CompilerVersion() which could be easily updated with build
    tags to be provided by the respective compilers.

    Thoughts?


    vb
    On Fri, Oct 24, 2014 at 10:37 PM, Carlos Castillo wrote:
    Can't you use a build tag to determine the api version of go?

    If you are looking to change behaviour based on the version of go, it is the
    best way, since it also provides conditional compilation which is very
    important to satisfy all static compilation checks.

    If you are looking for a string to print out (similar to what "go version")
    provides, then I could see some value for such a feature (eg: for logging),
    provided it was used, and documented as such, for display purposes only, and
    not for program logic.

    On Friday, October 24, 2014 10:06:13 AM UTC-7, Vincent Batts wrote:

    Hey all,

    In working with gccgo, I discovered that there is no god way to derive
    the
    go API that is provided by the compiler. Since runtime.Version() is
    actually
    the version of the gcc that is providing gccgo (which is also helpful,
    but
    not the information I'm looking for).

    After chatting with iant about this, he recommend we open this up for
    larger conversation, as there are now more compilers than just `gc` and
    `gccgo`.


    Should we provide something parallel to runtime.Version that shows a
    compiler version number separate from a version number that corresponds
    to
    gc releases?


    Thanks for your feedback,
    vb
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+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.
    --
    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.
  • Michael Hudson-Doyle at Oct 28, 2014 at 9:01 pm
    'Peter Collingbourne' via golang-dev <golang-dev@googlegroups.com>
    writes:
    If someone is using the "gccgo" toolchain, the "go" tool should provide
    build tags corresponding to the compiler's language version. It currently
    does not do so, and this problem prevents me from bootstrapping llgo with
    newer versions of the "go" tool, as that tool provides the go1.4 build tag,
    which is used by some parts of go.tools to compile different code for Go
    1.4, while llgo is currently on Go 1.3.
    Yes. I filed https://code.google.com/p/go/issues/detail?id=8851 about
    this recently.
    The problem to be solved is that there is currently no mechanism for the
    compiler to communicate its build tags to the "go" tool. I think there
    should be such a mechanism. I propose that "go" request a set of compiler
    tags from "gccgo" toolchains by executing "$GCCGO -dumpgotags" and reading
    the tags from stdout. For backwards compatibility with existing versions of
    gccgo/llgo, the "go" tool's built-in set of compiler tags would continue to
    be used if the exit status is non-zero.
    The above issue links to a really terrible patch of mine that sort of
    implements this. Ian's suggestion that ReleaseTags just be emptied when
    you use the -compiler flag would be a trivial patch and while it would
    put the onus on the invoker to know which version of the language the
    compiler they are using implements, at least the would be *able* to do
    that!

    Cheers,
    mwh
    This will probably have to wait until after the 1.4 release, but it would
    be unfortunate if it were difficult/impossible to bootstrap llgo with 1.4.

    Peter
    On Tue, Oct 28, 2014 at 7:14 PM, Vincent Batts wrote:

    This less about the build tags, but drawing the distinction between
    "language version" and "compiler version". Where for the golang `gc`
    these two definitions may be the same. Though for `gccgo` the
    "language version" may be 'go1.2.1' and the compiler version is gccgo
    (GCC) 4.9.1.

    Perhaps, the provision for this is an addition to runtime.Version(),
    which ought to stay as the language/API version, that we have a
    runtime.CompilerVersion() which could be easily updated with build
    tags to be provided by the respective compilers.

    Thoughts?


    vb

    On Fri, Oct 24, 2014 at 10:37 PM, Carlos Castillo <cookieo9@gmail.com>
    wrote:
    Can't you use a build tag to determine the api version of go?

    If you are looking to change behaviour based on the version of go, it is the
    best way, since it also provides conditional compilation which is very
    important to satisfy all static compilation checks.

    If you are looking for a string to print out (similar to what "go version")
    provides, then I could see some value for such a feature (eg: for logging),
    provided it was used, and documented as such, for display purposes only, and
    not for program logic.

    On Friday, October 24, 2014 10:06:13 AM UTC-7, Vincent Batts wrote:

    Hey all,

    In working with gccgo, I discovered that there is no god way to derive
    the
    go API that is provided by the compiler. Since runtime.Version() is
    actually
    the version of the gcc that is providing gccgo (which is also helpful,
    but
    not the information I'm looking for).

    After chatting with iant about this, he recommend we open this up for
    larger conversation, as there are now more compilers than just `gc` and
    `gccgo`.


    Should we provide something parallel to runtime.Version that shows a
    compiler version number separate from a version number that corresponds
    to
    gc releases?


    Thanks for your feedback,
    vb
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+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.
    --
    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.
  • Vincent Batts at Dec 22, 2014 at 8:33 pm
    This thead has taken a couple of healthy directions regarding a consistent
    experience on gccgo. While the build tags workflow needs to be addressed, on
    the simpler topic of having information passed through for developers to pass
    up information, would it make sense to have a runtime.Version() and
    runtime.CompilerVersion()? Where the go compiler, these two may be the same,
    but for gccgo and others, Version() would be the go-api implemented and
    CompilerVersion() would be the gcc version.

    vb

    On Tue, Oct 28, 2014 at 5:01 PM, Michael Hudson-Doyle
    wrote:
    'Peter Collingbourne' via golang-dev <golang-dev@googlegroups.com>
    writes:
    If someone is using the "gccgo" toolchain, the "go" tool should provide
    build tags corresponding to the compiler's language version. It currently
    does not do so, and this problem prevents me from bootstrapping llgo with
    newer versions of the "go" tool, as that tool provides the go1.4 build tag,
    which is used by some parts of go.tools to compile different code for Go
    1.4, while llgo is currently on Go 1.3.
    Yes. I filed https://code.google.com/p/go/issues/detail?id=8851 about
    this recently.
    The problem to be solved is that there is currently no mechanism for the
    compiler to communicate its build tags to the "go" tool. I think there
    should be such a mechanism. I propose that "go" request a set of compiler
    tags from "gccgo" toolchains by executing "$GCCGO -dumpgotags" and reading
    the tags from stdout. For backwards compatibility with existing versions of
    gccgo/llgo, the "go" tool's built-in set of compiler tags would continue to
    be used if the exit status is non-zero.
    The above issue links to a really terrible patch of mine that sort of
    implements this. Ian's suggestion that ReleaseTags just be emptied when
    you use the -compiler flag would be a trivial patch and while it would
    put the onus on the invoker to know which version of the language the
    compiler they are using implements, at least the would be *able* to do
    that!

    Cheers,
    mwh
    This will probably have to wait until after the 1.4 release, but it would
    be unfortunate if it were difficult/impossible to bootstrap llgo with 1.4.

    Peter
    On Tue, Oct 28, 2014 at 7:14 PM, Vincent Batts wrote:

    This less about the build tags, but drawing the distinction between
    "language version" and "compiler version". Where for the golang `gc`
    these two definitions may be the same. Though for `gccgo` the
    "language version" may be 'go1.2.1' and the compiler version is gccgo
    (GCC) 4.9.1.

    Perhaps, the provision for this is an addition to runtime.Version(),
    which ought to stay as the language/API version, that we have a
    runtime.CompilerVersion() which could be easily updated with build
    tags to be provided by the respective compilers.

    Thoughts?


    vb

    On Fri, Oct 24, 2014 at 10:37 PM, Carlos Castillo <cookieo9@gmail.com>
    wrote:
    Can't you use a build tag to determine the api version of go?

    If you are looking to change behaviour based on the version of go, it is the
    best way, since it also provides conditional compilation which is very
    important to satisfy all static compilation checks.

    If you are looking for a string to print out (similar to what "go version")
    provides, then I could see some value for such a feature (eg: for logging),
    provided it was used, and documented as such, for display purposes only, and
    not for program logic.

    On Friday, October 24, 2014 10:06:13 AM UTC-7, Vincent Batts wrote:

    Hey all,

    In working with gccgo, I discovered that there is no god way to derive
    the
    go API that is provided by the compiler. Since runtime.Version() is
    actually
    the version of the gcc that is providing gccgo (which is also helpful,
    but
    not the information I'm looking for).

    After chatting with iant about this, he recommend we open this up for
    larger conversation, as there are now more compilers than just `gc` and
    `gccgo`.


    Should we provide something parallel to runtime.Version that shows a
    compiler version number separate from a version number that corresponds
    to
    gc releases?


    Thanks for your feedback,
    vb
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+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.
    --
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 28, '14 at 6:14p
activeDec 22, '14 at 8:33p
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase