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
Build errors on Windows w/go 1.15 and 1.16 #10
Comments
You need to manually tell Go to use the latest version of the w32 library. It will use tag 1.0.0 by default which is very old. I know this because I just got this comment on another repository :-) Modules, yes, a subject I have been staying away from for as long as I could. I did not think it would be a problem for people. My way of working so far was that I keep all my repositories up to date and Now that modules are enabled by default I am afraid it is time for me to add module support to all my repositories. Please excuse me for not being all over this new feature. While I know from experience that reproducible builds from multiple repos is a problem, I think the module solution is very complex and I do not like the I have long bookmarked this Go blog article about how to use modules but it is a five part, 10000 word article. I have read the Go spec and it is now 27000 words. Is modules a third of the complexity of the whole programming language? Anyway, rant mode off, I will, in the not-too-distant future, read up on modules, get used to them and add module support for my active repositories. Probably some vendor folders will fall prey to this update process. P.S.: rant mode on again, I also hate the new pkg.go.dev website for online docs! It will not show some of my repos where I forgot a license file. Thus I only get an error and if I add a license it will not know about it. On godoc.org I had an "update this repo" link which would just get the latest changes. For pkg.go.dev I have to trigger some server or proxy or whatever and ARE YOU KIDDING ME?! Rant mode off for good now. |
Also change FILETIME.ToUint64() to just FILETIME.Uint64() which is more common in Go.
Hey, I'm relatively new to golang itself, didn't mean to wave anybody's flag re modules. There seems to be a bare-minimum entry-level option for them where you can "go mod init; go mod tidy" and be done which captures the state of dependencies you built with. After that you wade into deeper waters but presumably mostly for corporate dev environments. I have mentally side-lined modules as "like python requirements.txt". But then, I've read the blog article 2x and understood it 0x, and I'm not even sure I know what the v2 thing is (I thought that was some fancy semantic-versioning thing). I was really just alluding to the basic go.mod file and I have no horses in the race :) |
(Closed because you provided the info necessary to build :) |
Alright but now you've triggered me, I am already up to my knees in modules and have already encountered some problems. It seems this feature really IS as complex as I thought. I have always liked how easy Go makes everything, but this is annoying. Still, I am on my way to make all of my repositories module-proof so it is a good thing you got me started on it. Thanks for the feedback! :-) |
If you blog about that adventure, I hope you'll drop a link here? Most of my initial headaches seemed to anchor around stuff getting cached. I have to give most of the credit to GoLand, tho :) (I'm usually a vim/vs/vsc type person, but GoLand far exceeds the threshold of critically-useful functionality I set for using an additional tool) |
No blogging for now, I just moved a bunch of my repos over. My w32 and wui libraries now have a v2 folder which I quite honestly do not like very much. I followed rsc's advice and copied all the .go files over to a new sub-folder That is the |
From the command line, you can find copies in history with -C, but a thought: maybe you can move the files and copy them back, since you'll be working on the copied versions. Anyway, please accept my humble apologies and gratitude for tackling this. |
What version of go is wanted/desired? It might be worth adding a go.mod file (
go mod init
) so you can specify the go and dependency versions inline?Steps to reproduce:
I tested with the built-in Windows Sandbox feature (if not enabled, hit start, type enough of 'turn windows features on' to get a completion, and enable 'Windows Sandbox' in the list of optional features). Could also be done with a virtual machine.
Install latest git: https://github.com/git-for-windows/git/releases/download/v2.30.1.windows.1/Git-2.30.1-64-bit.exe
Install go 1.16: https://golang.org/dl/go1.16.windows-amd64.msi
Open a Powershell session (I'm a linux/bash guy, powershell is based on the same spec as bash so it's a little more natural to me)
-- hit start
-- type 'powershell'
ensure git and go are installed (note: powershell supports completion on flags and arguments)
create a local go project:
initialize local go module
create a simple test file
import "github.com/gonutz/prototype/draw"
func main() {
draw.RunWindow("Test", 640, 480, update)
}
func update(window draw.Window) {
window.DrawLine(100, 100, 440, 380, draw.Blue)
}
install dependencies
attempt to run
PS C:\Users\WDAGUtilityAccount\go\local\scratch> go run .
# github.com/gonutz/prototype/draw
....\pkg\mod\github.com\gonutz\prototype@v0.0.0-20210219081453-295a54f2a887\draw\window_windows.go:93:8: undefined: w32.UnregisterClassAtom
....\pkg\mod\github.com\gonutz\prototype@v0.0.0-20210219081453-295a54f2a887\draw\window_windows.go:442:7: undefined: w32.WM_MOUSEHWHEEL
....\pkg\mod\github.com\gonutz\prototype@v0.0.0-20210219081453-295a54f2a887\draw\window_windows.go:515:10: cannot use style & ^w32.WS_OVERLAPPEDWINDOW (type int32) as type uint32 in argument to w32.SetWindowLong
The text was updated successfully, but these errors were encountered: