Support for stamp in Go binaries

[zombiezen]

While the stamp attribute is there in go_binary, it seems like it doesn't do anything. I would expect it to use the -X flag, but I'm not sure what import path it would use (linker docs).

[pmbethe09]

It would seem like a good idea for the 'stamp' attribute to function similarly to the same on other *_binary rules.

[twpayne]

Would it make sense to specify the import path in a separate attribute to the rule? In addition, it would be nice if part of the value could come from the workspace status command. Something like:

go_binary(
    name = "foo",
    stamp = 1,
    stamp_var = "github.com/my/project.buildStamp",
    stamp_value = "$(BUILD_SCM_REVISION) $(BUILD_SCM_STATUS)",
)

This would pass -X "github.com/my/project.buildStamp=revision status" to go build.

[twpayne]

In case it helps others, while this issue is still open, I'm using a hacky workaround to get the BUILD_SCM_REVISION from tools/buildstamp/get_workspace_status into my Go binary by generating a Go source file containing the string:

genrule(
    name = "genrule-version.go",
    outs = ["version.go"],
    cmd = "BUILD_SCM_REVISION=$$(awk '/^BUILD_SCM_REVISION/ { print $$2 }' bazel-out/volatile-status.txt); echo -en \"package main\n\nvar Version = \\\"$$BUILD_SCM_REVISION\\\"\n\" > $@",
    stamp = 1,
)

[pmbethe09]

That seems like a decent idea. Not even that hacky. Should we consider making that an 'official' solution?

…

On Mon, Jan 16, 2017 at 9:26 AM, Tom Payne ***@***.***> wrote: In case it helps others, while this issue is still open, I'm using a hacky workaround to get the BUILD_SCM_REVISION from tools/buildstamp/get_ workspace_status into my Go binary by generating a Go source file containing the string: genrule( name = "genrule-version.go", outs = ["version.go"], cmd = "BUILD_SCM_REVISION=$$(awk '/^BUILD_SCM_REVISION/ { print $$2 }' bazel-out/volatile-status.txt); echo -en \"package main\n\nvar Version = \\\"$$BUILD_SCM_REVISION\\\"\n\" > $@", stamp = 1, ) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#233 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALF-0nKKeEWf_aIBv1wxzD0VT-gdG2lWks5rS34UgaJpZM4LPawF> .

[twpayne]

Sounds reasonable :)

What should the rule look like? I'm thinking of something like:

go_buildstamp(
  name = "buildstamp",
  out = "buildstamp.go",  # name of generated file
  package_name = "main",  # optional, could default to "main" or the basename of the directory
)

This would generate buildstamp.go that could then be included as a normal Go source file. The generated file could be something like:

package main

const (
    BuildEmbedLabel  = "..."
    BuildUser        = "..."
    BuildHost        = "..."
    BuildTimestamp   = "..."
    BuildSCMRevision = "..."
    BuildSCMStatus   = "..."
)

I'd be happy to have a go at implementing this if it looks reasonable to you.

[pmbethe09]

Well, why not do that for the user? If 'stamp = 1' on the 'go_binary' rule, auto-add a go_buildstamp under the hood for the user.

…

On Wed, Jan 18, 2017 at 6:56 AM, Tom Payne ***@***.***> wrote: Sounds reasonable :) What should the rule look like? I'm thinking of something like: go_buildstamp( name = "buildstamp", out = "buildstamp.go", # name of generated file package_name = "main", # optional, could default to "main" or the basename of the directory ) This would generate buildstamp.go that could then be included as a normal Go source file. The generated file could be something like: package main const ( BuildEmbedLabel = "..." BuildUser = "..." BuildHost = "..." BuildTimestamp = "..." BuildSCMRevision = "..." BuildSCMStatus = "..." ) I'd be happy to have a go at implementing this if it looks reasonable to you. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#233 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALF-0icxTzsctYAVzLxBlOTxBhjwM4wvks5rTf3TgaJpZM4LPawF> .

[zombiezen]

I looked into writing a PR for doing this using the linker options approach, but it seems that it is blocked on bazelbuild/bazel#1054, as Skylark has no access to the workspace status.

For future implementors, I discovered you can use go tool link -X main.NameOfVar=foo to set variables in package main. Note that they must be variables, not constants, for -X to work. Furthermore, the linker will no-op if the variable doesn't exist, so it would be safe to always pass the flags.