xiaonanln / goworld

Scalable Distributed Game Server Engine with Hot Swapping in Golang
Apache License 2.0
2.53k stars 450 forks source link

move workspace out of goworld directory #82

Open eidng8 opened 4 years ago

eidng8 commented 4 years ago

This PR serves as an early preview, and fire up the talk about the subject.

Currently all documentations and the goworld build tool suggest working directly inside the goworld repo directory. I've started to modifying the build tool to support Go work flow and directory structure.

So far I have modify the build process to follow go module rules. It now supports building projects outside of the goworld directory. Further, I can make customization possible to gate, dispatcher, and game. Making them all can live outside of goworld directory. So it'll be possible for others to just use this package as a dependency, and customize the actual work flow as they want.

However, as the imports are hard-linked to the original repo, I have no way of further testing the whole process. I've tried copying the chat demo from examples directory. Place it in various directories, inside and outside of GOPATH. It seems the building process goes fine. Until I actually add the go.mod file to the demo. Which rquires the v0.1.6 version of the original goworld. And that version doesn't work well with redis cluster v1. I've tried switching to a commit from master with no success.

Please share your thoughts regarding my approach. More importantly, do you think it's necessary to make this package usable as pure dependency, instead of working directly inside it?