runtime: provide a way to obtain build tags

[dvyukov]

The problem at hand is to determine when you are running under race detector. This is
frequently needed to disable tests, reduce number of iterations or scale timeouts.
See e.g.:
https://golang.org/cl/44180043/diff/60001/src/pkg/runtime/pprof/pprof_test.go
where we have to completely disable the test, while we want to do it only under race
detector.

David noted that this is a more general problem, and proposed to extend it to all build
tags, e.g.:
if runtime.Tag("race") { ... }

[dvyukov]

Comment 1:

David, do you have any other example where this can be useful?

[remyoudompheng]

Comment 2:

It looks tempting but I'm afraid it triggers a #ifdef syndrome which is currently
discouraged by the file-wide scope of build tags.

[dvyukov]

Comment 3:

I understand your concern.
But inside of std lib and dashboard builder you can find quite a lot of code like this:
    if runtime.GOARCH == "amd64" {
        fmt.Printf("warning: running calibration on %s\n", runtime.GOARCH)
        if runtime.GOOS == "windows" {
                fn = os.Getenv("HOMEDRIVE") + os.Getenv("HOMEPATH")
        } else {
                fn = os.Getenv("HOME")
        }
        if runtime.GOOS == "windows" {
                d = `c:\`
        } else {
                d = os.TempDir()
        }
This is quite handy.
It depends on what is the primary aspect of the code and what is the secondary aspect of
the code. In a cross-platform GUI library, you probably want to have separate files for
different platforms with lots of OS-specific code. But if you want to merely "n /= 10"
for race build, adding 2 new files does not look like a good solution. Race-ness is a
minor aspect here, so you don't want to partition your code based on it.
And sometimes aspects overlap, if you have to use different files, you will need N^K of
them.

[dvyukov]

Comment 4:

Right now I would like to disable the hijack benchmark:
http://build.golang.org/log/d083507d943dc974ec46ba9a7df391479af031cd
what should I do?..

[dsymonds]

Comment 5:

I don't think this feature request is anything like #ifdef. Preprocessor macros are bad
because they change how code is compiled based on external controls, and so code may
compile on one system but not another. Adding an API to access build tags is not that;
it can only affect your code's runtime behaviour, just as runtime.GOOS can.
I think it would be a useful supplement to how build constraints are currently working;
they only permit whole-file control when sometimes there is just a trivial little tweak
needed.

[rsc]

Comment 6:

Build tags are for building. I do not want them to be exposed in the runtime. Obviously
if you need to know in your own package you can write different files with different
build tags and different initialized constants or variables. But this is rarely needed.
This is not just adding an API to access build tags. It requires recording them in the
first place, and most will not be used. It's extra cost for little to no gain, and worse
it opens up the possibility for misuse.
Let's leave build tags in the build.

Status changed to WorkingAsIntended.