SMF Go generator assumes flatbuffer names and directory structures

[Andrew Psaltis]

Describe the bug

The go code generator within smfc is a nice feature, as it allows for some quick prototyping and use of non-Linux platforms for testing.

That being said, the code generator has some hardcoded paths in it that cause go build to reject the output code. Example failed go build output includes:

# not_a_demo
../not_a_demo/not_demo_service.smf.fb.go:13:24: undefined: smf.Request
../not_a_demo/not_demo_service.smf.fb.go:37:32: undefined: demo
../not_a_demo/not_demo_service.smf.fb.go:48:68: undefined: not_a_demo
../not_a_demo/not_demo_service.smf.fb.go:53:9: undefined: smf.GetRootAsResponse

The first two and the last one appear to be the result of hardcoding for specific expected types that don't always exist (Request, Response, Demo).

The third one uses the same package as the current flatbuffer protocol file to identify a the response flatbuffer type, which is fine if the generated service is in a different package. In my example, below, this is not the case.

To Reproduce

1. Set GOPATH to something appropriate, and mkdir -p $GOPATH/src
2. cd $GOPATH/src, and get dependencies:

cd $GOPATH/src
go get github.com/google/flatbuffers/go
go get github.com/smfrpc/smf-go/src/smf

3. Create the following flatbuffer file (not_a_demo.fbs):

namespace not_a_demo;

table Request1 {
  name: string;
}

table Response1 {
  name: string;
}

rpc_service SmfStorage1 {
  Get(Request1):Response1;
}

3. Invoke flatc and smfc on it (ensure you're in the ${GOPATH}/src directory):

/path/to/flatc --gen-name-strings --gen-object-api --go --force-empty --gen-compare --keep-prefix --json --reflect-names --defaults-json --gen-mutable -o . /path/to/not_a_demo.fbs 

/path/to/smfc --filename not_demo_service.fbs --language=go --output_path=.

4. Make a directory for the "main" module:

mkdir not_a_demo_client

5. Create a not_a_demo_client/main.go file containing the following:

package main

import (
        "fmt"
        "not_a_demo"
)

func main() {
        fmt.Printf("It compiled!")
}

6. cd to not_a_demo_client and attempt a build:

cd not_a_demo_client
go build

The compilation fails as above.

Expected behavior
Output code to contain correct descriptions of types, and thusly, for compilation to succeed.

** Environment Info **

• OS: Ubuntu 16.04
• smf version: git-9dfa658
• smf-go version: git-91025c4
• Compiler: g++-7
• Go Version: 1.11.2

[Łukasz Kurowski]

Can you please upload the code generated?

[Łukasz Kurowski]

https://gist.github.com/crackcomm/4e57ebe7d4c23ef6df31d1e5b26238d8

I'm working on a patch.

[Alexander Gallego]

@nacl confirm. this was automatically closed somehow.

[Alexander Gallego]

I tested this. it seems to compile now.

[Andrew Psaltis]

The code appears to compile properly now (getting the obligatory "unused import" errors), but I haven't tried to use it in a "real" way yet. I'll know more Monday. Thanks!

It seems that commit d20866d causes some behavior differences between smfc and flatc. flatc will generate the directory structure necessary for the go packages in the namespace variable, and smfc no longer does so as of that commit. I believe this what @senior7515 meant in #288.

Some future nice-to-haves could be:

• A full demo in the smf-go project that involves smfc
• smfc split into a repo that doesn't include seastar. That could make it slightly easier to build, since the IDL compiler only seems to need boost and flatbuffers.

Thanks!

[Alexander Gallego]

@nacl let me know if you want to contribute one. I agree we def need it.

I plan on splitting the compiler outside of the seastar impl after seastar merges their cmake support so all the native projects work together w/ a similar build system. should be merged pretty soon.

I'll revert the directory creation patches.

Thanks for testing.

[Alexander Gallego]

@nacl - i reverted the minor directory creation. files seem to compile. let me know if you can test or can submit a quick repo w/ a bash script to get ppl started w/ go. similar to the getting-started-cpp project.