Ability to choose GOOS and GOARCH

[tiborvass]

It would be very useful to set those envvars for the syscall package for instance. Does not need to be in the UI yet, a simple https://godoc.org/syscall?GOOS=windows would be sufficient.

I'm also not sure if Go has been cross compiled for godoc.org, but it would be great if it were.

Thanks for this awesome tool that I use everyday :)

[nf]

I'm also not sure if Go has been cross compiled for godoc.org, but it would be great if it were.

What does that mean?

[tiborvass]

@nf My bad, I thought for a second that you needed cross compiling, but there is no need for it since godoc just checks the source and the Go source includes all platforms.

Basically a generalization of this feature request would be to allow specifying buildtags. If that makes more sense, feel free to edit the issue title.

[nf]

All good.

[tiborvass]

@nf do you mind if I try implementing this?

[adg]

What Gary said. I'd appreciate your help but let's do it right.

On 21 February 2015 at 08:26, Gary Burd notifications@github.com wrote:

Please discuss the design before writing code.

—
Reply to this email directly or view it on GitHub
#188 (comment).

[tiborvass]

@garyburd @nf Sure no problem.

We could either implement this by setting GOOS and/or GOARCH environment variables, or by being more generic: allowing one buildtag input as defined in http://golang.org/pkg/go/build/#hdr-Build_Constraints however that is not implemented in godoc yet: golang/go#3398.

For the actual interface, I was thinking simple GET parameters: buildtag or GOOS/GOARCH depending on what route you'd like to go. One reason is because it makes it easily compatible with the API endpoints too: api.godoc.org/search?q=syscall&buildtag=windows would return only the packages that match syscall and have windows-specific code.

I don't intend to add UI changes.

Let me know what solution you prefer. Thanks!

[dmitshur]

I just want to point something out.

godoc.org is kinda two slightly different things in one.

One aspect is displaying docs for a specified Go package. Displaying different docs depending on build tags is pretty straightforward and doesn't affect anything. It's a matter of local presentation only.

The other aspect is keeping track of the imports network. Which Go package imports which other Go packages. This affects the package index, and imports/importers pages. Currently, this entire imports graph assumes default linux build tags. However, if you were to use different tags, the imports may change, which would affect the graph. Also, some packages may be Windows-only or Linux-only (via tags), so godoc may not index a given Go package because mis-matched tags were considered. I don't think you'd want to deal with this aspect (because it's hard, computationally expensive).

[dmitshur]

Godoc.org handles Windows-only and Darwin-only packages.

I see, my mistake. It does not handle GOARCH=js-only packages, and I falsely assumed it only handled Linux packages.

Edit: This has since been resolved in #343.

[bradfitz]

We really need to make Windows-only packages render nicely, and by default.

I've been needing to work on https://godoc.org/golang.org/x/sys/windows lately, but linking to its documentation is pretty sad.

@nf, can you see if somebody can work on this?

[bradfitz]

/cc @alexbrainman

[alexbrainman]

Windows-only packages do work very well. But for mixed packages I never even bother to look on godoc.ord (Brad's example above is good). Maybe this does need UI change. Maybe for multi GOOS packages have a button (or some other UI tool to select one of many) to select GOOS view. But, I guess, this would have to keep selected GOOS as you follow links. Sounds complicated for me (non web developer).

Akex