Proper way to gen multiple Thrift files for Go

So I have the following files

/src/baseService.thrift
    /baseTypes.thrift
    /baseSecurity.thrift

I want all of these thrift definitions to be created into one library. The top of each file is thus:

baseService.thrift
==================
namespace java foo.bar
namespace cpp foo.bar
namespace js foo.bar
namespace go foo.bar

import "baseTypes.thrift"

baseTypes.thrift
================
namespace java foo.bar
namespace cpp foo.bar
namespace js foo.bar
namespace go foo.bar

baseSecurity.thrift
===================
namespace java foo.bar
namespace cpp foo.bar
namespace js foo.bar
namespace go foo.bar

import "baseTypes.thrift"

The problem is, how to I create all of these into one lib package? It works fine for java/cpp/js but when I try to build for go it's a no go.

With thrift, you can't do a thrift gen:baz *.thrift, you have to do the files one at a time. For the other languages, we just do a:

for f in `find *.thrift`; do
   thrift -o myGenDir --gen go $f"
done

(substitute appropriate gen command for each lang)

For Python this is fine because it puts every gen'd file in it's own dir based on the filename [ i.e. foo/bar/{filename}/ttypes.py]. For Java it dumps all of the files in foo/bar/ but every class name is unique. For cpp, it dumps it all into the gen dir, but uniquely named per thrift file [so {filename.h}, {filename.cpp}]. For Go, however, it dumps everything into foo/bar like so:

/foo/bar/constants.go
/foo/bar/service.go
/foo/bar/service-remote/
/foo/bar/baz/  [for anything that has a namespace of foo.bar.baz]
/foo/bar/ttypes.go

The problem is, the ttypes.go and (presumably) constants.go are getting overwritten by whatever is gen'd last in the for loop. Is there a way around this? It works for the other languages - seems like it's an oversight for Go. What am I missing. We've got lots of Thrift files with lots of stuff in them - I'd rather not have to combine everything that's at the same package level into one thrift file.

> The problem is, the ttypes.go and (presumably) constants.go are getting overwritten by whatever is gen'd last in the for loop.

Yes, that's true.

> Is there a way around this?

The most (cross-language) portable recommendation is to not do this. Instead:

• put different IDL files into different namespaces
• put everything belonging to one namespace into exactly one IDL file

The Thrift compiler offers a few compiler switches for Go that may help you at least partially, (you get all available options for all languages by typing thrift --help on the command prompt)

 go (Go):
   package_prefix=  Package prefix for generated files.
   thrift_import=   Override thrift package import path (default:git.apache.org/thrift.git/lib/go/thrift)
   package=         Package name (default: inferred from thrift file name)

These options are used like in

 thrift -gen go:package=mypack,package_prefix=myprefix

> It works for the other languages - seems like it's an oversight for Go.

It might be your impression but I'd recommend not to try it, if you are interested in cross-language compatibility. The behaviour is the same with other languages. Just as an example: I recently fixed (or better: worked around) a problem with the Erlang tests, where I had to fight exactly this very same issue.

Had the same problem recently. Every IDL in different namespaces just doesn't work. Code looks bad, different namespaces everywhere that you have to remember, annoying to add/remove namespaces for every little thing.

I only define a single namespace so I come with this. Basically, objects are in different files but they're written as they're in a single file. So no imports, no cross-file references, no namespaces in every file. I put namespaces in a separate file. Then my script joins everything into one big thirft file and compiles it. It does require you to put everything in the right order but it works for languages I need - Go, C# and Java worked fine.

For me it too looks like an oversight. There is no reason for it to be like that just for Go. Maybe some day I will send a merge request with behaviour that better matches other languages.