Giters

contribsys / faktory_worker_go

Faktory workers for Go

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Windows build

mperham opened this issue · comments

commented

Add an Appveyor Windows CI build to ensure the Go worker process can execute successfully on Windows.

commented

Struggling to get the Go code to build. I'm not sure the Faktory code is packaged according to Go best practices.

commented

@mperham looking at the appveyor build I can't quite tell what you're trying to do. I see:

  1. A checkout of the worker repo
  2. A go get of faktory
  3. A go build of the load tester

I'm guessing you're just wanting to build something that uses the client as a dependency?

If so, your problem is how you're building load tester. The go get is pulling in only the faktory top-level package and all of its dependencies (of which faktory/util is not). The load tester itself relies on some other faktory subpackages, such as faktory/util. Because these haven't been downloaded via go get and only cloned into your go path it's dependencies are not downloaded, hence the failure to find apex/log.

If you want to build the load tester you should either go get it or install its dependencies with dep ensure. Just wondering what you're trying to accomplish with the building of the faktory stuff v just building faktory_worker_go?

commented

I'm building faktory_worker_go, not the load tester. It only uses the Faktory client code but I believe I need to repackage the code in github.com/contribsys/faktory into g.c/c/f/client because a go get tries to build everything "beneath", I suspect.

commented

test/main.go is the example Worker. See the README.

commented

Gotcha, sorry, read the build wrong, just realized test/main was in this repo, you're problem is you need to run go get on the faktory/util package since you're using it directly in the test and it's not referenced in the faktory repos top-level package.

commented

The reason for the failure is the same as stated in the first comment. Cloning faktory into your gopath won't be enough because it won't retrieve its package dependencies without running go get on the specific package you're trying to import.

commented

I've removed the util package reference in the root package test and it still wants to compile the whole thing. I'm thinking it would be clearer to move the whole thing to a client package that can be explicitly pulled as a separate entity.

go get -x -v -n -d -u github.com/contribsys/faktory
github.com/contribsys/faktory (download)
cd .
git clone https://github.com/contribsys/faktory c:\gopath\src\github.com\contribsys\faktory
cd c:\gopath\src\github.com\contribsys\faktory
git submodule update --init --recursive
# cd c:\gopath\src\github.com\contribsys\faktory; git sync/update
go build -x -v -n -i test/main.go
..\faktory\util\logger.go:10:2: cannot find package "github.com/apex/log" in any of:
	C:\go\src\github.com\apex\log (from $GOROOT)
	c:\gopath\src\github.com\apex\log (from $GOPATH)
commented

You're talking about this reference?

https://github.com/contribsys/faktory_worker_go/blob/master/test/main.go#L8

This is the import that's causing you issues. Definitely think that it'd be easier to move everything to a client package though--it'll make versioning easier.

commented

yep, just caught and fixed that. Doh.

commented

Cool, we're now reproducing the actual problem people are reporting. 👍

commented

You'll probably want to shim something like this in https://github.com/mattn/go-isatty/blob/master/isatty_windows.go -- think you could do something like this to make the Windows version of isTTY:

func isTTY(fd int) bool {
	ptrFD := (uintptr)(unsafe.Pointer(&fd))
	return isTerminal(ptrFD) || isCygwinTerminal(ptrFD)
}
commented

Happy to get a PR but util is meant only to be used by the server. The worker process supporting Windows is very different from full server support.

commented

Build now passing on Windows, woot!

Happy to get PRs which add README badges and/or a Travis CI build for Linux.