flatbuffers
flatbuffers copied to clipboard
[go] add go module support for go flatbuffers
As title mentioned. This can bring flatbuffers directory to outside GOPATH and make gopls
works as expected.
I think it just place go.mod
inside go
directory and it done.
What exactly is involved in this? @rw
as pom.xml for java / package.json for JS go.mod is golang deps ( golang modules ) define go module that go module via version number.
for me, I fork github.com/google/[email protected] to github.com/tsingson/[email protected] to add go.mod
use like this go.mod in my go project
module github.com/tsingson/xxxxxxxx
go 1.13
replace github.com/google/flatbuffers v1.11.0 => github.com/tsingson/flatbuffers v1.11.1
require (
emperror.dev/errors v0.4.3
github.com/AlecAivazis/survey/v2 v2.0.4
github.com/BurntSushi/toml v0.3.1
..............
if flatbuffers add go.mod , my project use like
module github.com/tsingson/xxxxxxx
go 1.13
require (
github.com/google/flatbuffers v1.11.0
emperror.dev/errors v0.4.3
github.com/AlecAivazis/survey/v2 v2.0.4
github.com/BurntSushi/toml v0.3.1
..............
@wingyplus it's not as simple as just putting the go.mod file in root.
What exactly is involved in this? @rw
@aardappel I'm close to publishing a PR with this feature.
The biggest pain point for me has been the following:
Basically if all you do is add a go.mod file then a bunch of the go test code will not be able to execute.. e.g anything that references tests/MyGame/Example/Any.go ... It turns out that this generated file (and a few others) import another generated package ("MyGame/Example2"
). So once go.mod is in root, the import statement for "MyGame/Example"
now needs to have an absolute path from root (where the root is "github.com/google/flatbuffers").
So instead of,
import "MyGame/Example"
it needs to be prepended with gomod-root during flatc generation like:
import "github.com/google/flatbuffers/MyGame/Example"
So before we can even add go.mod to root, we need flatc to be able to prepend the appropriate gomod path during generation. We have two options for this:
- Add yet another user flag to flatc telling it exactly what to prepend whenever it has to.
- Have flatc be programmatically aware of whether it is in a Go Module supported project/context, and to have flatc automatically know the right gomod path to prepend. It may achieve this by:
a. Searching for go.mod in parent file tree then parsing it.
b. Leveraging the go command
go list -m
/go list -m -f={{.Dir}}
. This would require calling the go command from C++ and checking that that the command is even available (perhaps checking if$GOROOT
env var is set. c. some other clever method that you're about to tell me? 😏
I have chosen to take approach number1 for now. Since, let's just say for now, my C++ isn't as good as my Go 😉. I am not very satisfied with this so if others can help with something along the lines of approach number2 (if we feel like that's worthwhile) it would be appreciated.
What do y'all think!?
This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.
This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.
.
This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.
.
+1
This fix is needed to use FlatBuffers namespaces in standard Go modules.
Can whoever on here actually knows Go (@tsingson @rw @wingyplus @cgst) review #5739 so we can get it merged?
Sorry for leaving this issue for so long. @somombo Can you rebase #5739. I'll find the time to help review the patch. :)
This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.
This issue was automatically closed due to no activity for 6 months plus the 14 day notice period.