Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/sys/windows: godoc is useless again #16509

Open
bradfitz opened this issue Jul 27, 2016 · 6 comments
Open

x/sys/windows: godoc is useless again #16509

bradfitz opened this issue Jul 27, 2016 · 6 comments
Assignees
Milestone

Comments

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jul 27, 2016

The godoc for https://godoc.org/golang.org/x/sys/windows is empty, probably because of https://go-review.googlesource.com/24952

Maybe this is a gddo problem too. (Or maybe gddo can help or have better heuristics over which build context to use)

/cc @alexbrainman @adg @broady @shantuo @alandonovan

@alexbrainman

This comment has been minimized.

Copy link
Member

@alexbrainman alexbrainman commented Jul 30, 2016

Unfortunately I don't have any bright ideas.

I am sure it is because of CL 24952. I can revert the change. But then we need to find different solution to issue #16368.

Alternatively we can hard code golang.org/sys/windows (and some others) in gddo to display these as windows packages. But this is very error prone. And what about other similar packages?

Maybe we could come up with some new gddo rule for that. Compare different GOOS / GOARCH versions of the package - number of global variables, functions, types and so on - and show version with most of these.

What do you think?

Alex

@broady

This comment has been minimized.

Copy link
Member

@broady broady commented Jul 30, 2016

Maybe, until godoc can recognize build tags, we need a special build tag for godoc.

//+build godoc to force godoc for a file.

It's ugly, but is it bad?

@bradfitz

This comment has been minimized.

Copy link
Contributor Author

@bradfitz bradfitz commented Jul 30, 2016

  1. The quickest easy fix is hard-coding specific packages (this one) to use a different build context. We could to that immediately while we do the next step:

  2. Try Linux/amd64 build context first. If it yields any exported symbols at all, stop and use it. If it's totally blank, then do a more intensive scan looking for which build context is best.

@minux

This comment has been minimized.

Copy link
Member

@minux minux commented Jul 30, 2016

@alexbrainman

This comment has been minimized.

Copy link
Member

@alexbrainman alexbrainman commented Aug 1, 2016

  1. The quickest easy fix is hard-coding specific packages (this one) to use a different build context. ...

Like this https://go-review.googlesource.com/#/c/25353 ?

Alex

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Aug 1, 2016

CL https://golang.org/cl/25353 mentions this issue.

gopherbot pushed a commit to golang/gddo that referenced this issue Sep 8, 2016
Updates golang/go#16509

Change-Id: Id0dd8f1aee82a45375363e32682e85868eea4765
Reviewed-on: https://go-review.googlesource.com/25353
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.