Proposal: GOTAGS env var

[Kevin Gillette]

Problem: it is sometimes desirable to set default build tags, such as netgo, without needing to write command aliases or wrappers to supply a -tags option.

Proposal: introduce toolchain support for a GOTAGS environment variable. This is parsed and handled identically to the -tags option, and is overridden by -tags on a tag-by-tag basis.

Examples:

`GOTAGS=netgo go build` is equivalent to `go build -tags netgo`

`GOTAGS='appengine netgo' go build -tags '!netgo'` is equivalent to `go build -tags 'appengine !netgo'`

[Jan Mercl]

On Tue, Mar 4, 2014 at 9:52 PM, Kevin Gillette
<extempor...@gmail.com> wrote:

Don't like the idea. Global state etc. vs semantics of tags: dynamic
compiler knobs. Can also break existing automatization tools. Who
knows how much of them run in the wild.

-j

[Ian Lance Taylor]

As we've seen with GOROOT, environment variables that affect tool
behaviour are problematic. We shouldn't add them unnecessarily, and I
don't see why this case is necessary.

Ian

[Kevin Gillette]

That's fair. The problem still stands: the toolchain seems unable to determine what tags were used to build an installed package, requiring the use of -a when a different set of tags are used.

[Ian Lance Taylor]

On Wed, Mar 5, 2014 at 9:58 AM, Kevin Gillette
<extempor...@gmail.com> wrote:
>
> That's fair. The problem still stands: the toolchain seems unable to
> determine what tags were used to build an installed package, requiring the
> use of -a when a different set of tags are used.

I did not understand that to be the problem. I agree that it would be
nice to fix that. Is there an issue open for it?

Ian

[Kevin Gillette]

Issue 3172 seems to be a subset of this issue.