distribution build in the same way that CGO_ENABLED has been supported,
such that net apps built with that configuration of the toolchain would, by
default, not require -tags netgo (which is easy to forget, though
admittedly easy to shell alias). The most general mechanism I can think of
for this is the toolchain, perhaps statically, supporting an arbitrary list
of build tags to consider distribution-wide defaults (even more preferable
if supported on a GOPATH basis, e.g. an appengine enabled GOPATH vs one
that is not appengine enabled).
I suspect that this would require a minor extension to the compiled archive
format to distinguish between a static net library caused by CGO_ENABLED=0,
and one caused by the netgo tag. Alternatively, this could involve
introduction of a NETGO environment variable, though that's clearly not the
direction we were headed. In a more general sense, if compiled archives
contained metadata indicating the build tags used, that alleviate much of
the need for the -a build flag, in addition to avoiding subtle bugs caused
by "false positive builds", which when -a is not used, may link against
package archives that don't correspond to supplied build tags.
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 email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.