gddo
gddo copied to clipboard
golang
Ability to choose GOOS and GOARCH
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 :)
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?
@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.
What Gary said. I'd appreciate your help but let's do it right.
On 21 February 2015 at 08:26, Gary Burd [email protected] wrote:
Please discuss the design before writing code.
— Reply to this email directly or view it on GitHub https://github.com/golang/gddo/issues/188#issuecomment-75322054.
@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: https://github.com/golang/go/issues/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!
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).
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 https://github.com/golang/gddo/pull/343.
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?
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
Okay, https://godoc.org/golang.org/x/sys/windows is now a Windows-only package and it renders nicely. (As "nicely" as an auto-generated syscall package can look, at least.)
Here is another use case where a GOARCH-aware godoc.org would be helpful: https://godoc.org/github.com/dolmen-go/endian (see #455)
Here's another broken one:
https://godoc.org/golang.zx2c4.com/wireguard/tun/wintun/setupapi only shows one file, whereas https://git.zx2c4.com/wireguard-go/tree/tun/wintun/setupapi shows quite a few.
https://github.com/Microsoft/go-winio is pretty broken here too, unfortunately :(
This issue has been kinda dead for a while but I'd be interested in helping work towards a solution for this, especially because I've been working across multiple platforms pretty regularly lately, and it would be nice to see platform caveats without diving through packages locally (even if I manually need to ?GOOS=(windows|freebsd) or similar.
https://github.com/Microsoft/go-winio is pretty broken here too, unfortunately :(
What is broken?
https://godoc.org/github.com/microsoft/go-winio looks fine to me
This issue has been kinda dead for a while but I'd be interested in helping work towards a solution for this
Sorry I don't know who makes decisions here. Maybe @dmitshur will help.
Alex
https://godoc.org/github.com/microsoft/go-winio/vhd vs https://github.com/microsoft/go-winio/blob/master/vhd/mksyscall_windows.go is one example.
https://godoc.org/github.com/microsoft/go-winio/vhd vs https://github.com/microsoft/go-winio/blob/master/vhd/mksyscall_windows.go is one example.
The problem with this package is that zvhd.go file will build as part of "any" OS. If you make it windows only, I think, you will be able to see everything in godoc,org properly.
Alex
https://godoc.org/golang.zx2c4.com/wireguard/tun/wintun/setupapi with this one I assume the issue is mksyscall is missing the Windows-only annotation as well?
I assume the issue is mksyscall is missing the Windows-only annotation as well?
Yes, mksyscall.go will be built for every single OS. Including Linux. I suspect godoc.org runs Linux. I suspect godoc.org application always runs help for native OS, if it is available. So, for golang.zx2c4.com/wireguard/tun/wintun/setupapi package, godoc.org will display no symbols, since Linux version contains just mksyscall.go file, and mksyscall.go has no symbols.
If you use latest Go version (the one that has 41df5aeb7f02a47ff7ccf5002140b70b04a4fd46 ), you should be able to add // +build generate line, and then mksyscall.go should be only visible to go generate command.
Alex