search

golang / gddo

Go Doc Dot Org
https://godoc.org
BSD 3-Clause "New" or "Revised" License
1.1k stars 266 forks source link

Ability to choose GOOS and GOARCH #188

Open tiborvass opened 10 years ago

tiborvass commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

All good.

tiborvass commented 9 years ago

@nf do you mind if I try implementing this?

adg commented 9 years ago

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 https://github.com/golang/gddo/issues/188#issuecomment-75322054.

tiborvass commented 9 years ago

@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!

dmitshur commented 9 years ago

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 commented 9 years ago

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.

bradfitz commented 8 years ago

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 commented 8 years ago

/cc @alexbrainman

alexbrainman commented 8 years ago

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

bradfitz commented 8 years ago

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.)

dolmen commented 7 years ago

Here is another use case where a GOARCH-aware godoc.org would be helpful: https://godoc.org/github.com/dolmen-go/endian (see #455)

zx2c4 commented 5 years ago

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.

endocrimes commented 5 years ago

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.

alexbrainman commented 5 years ago

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 image

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

paultyng commented 5 years ago

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.

alexbrainman commented 5 years ago

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

zx2c4 commented 5 years ago

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?

alexbrainman commented 5 years ago

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