Правильный способ генераторных несколько файлов бережливости для Go

Question

Так что у меня следующие файлы

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

Я хочу, чтобы все эти определения бережливости должны быть созданы в одной библиотеки. В верхней части каждого файла, таким образом:

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" 

Проблема в том, как я создаю все их в один пакет Lib? Он отлично работает для java/cpp/js, но когда я пытаюсь построить для go, это не выход.

С бережливостью вы не можете сделать thrift gen:baz *.thrift, вам нужно делать файлы по одному. Для других языков, мы просто сделать:

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

(заменить соответствующую команду для каждого поколения Ланг)

Для Python это хорошо, потому что он помещает каждый gen'd файл в своей собственной директории на основе filename [ie foo/bar/{filename} /ttypes.py]. Для Java он сбрасывает все файлы в foo/bar /, но каждое имя класса уникально. Для cpp он выгружает все это в каталог gen, но уникально назван в файле trift [so {filename.h}, {filename.cpp}]. Для Go, однако, он сбрасывает все в Foo/бар, как так:

/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 

Проблема есть, ttypes.go и (предположительно) constants.go становятся перезаписаны все, что gen'd последний в течение петля. Есть ли способ обойти это? Он работает на других языках - кажется, что это надзор за Go. Что мне не хватает. У нас есть много файлов Thrift с большим количеством материалов в них - я бы предпочел не объединять все, что находится на одном уровне пакета, в один файл экономии.

Answer 1

Проблема в том, что ttypes.go и (предположительно) constants.go перезаписываются тем, что было gen'd последним в цикле for.

Да, это правда.

Есть ли способ обойти это?

Самая (кросс-язычная) портативная рекомендация - не делать этого. Вместо этого:

• поместить различные файлы IDL в разные пространства имен
• положить все, принадлежащее одному из имен в точности один IDL файл

бережливость компилятор предлагает несколько компиляторов переключателей для Go, которые могут помочь вам в хотя бы частично, (вы получите все возможные варианты для всех языков, введя thrift --help в командной строке)

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) 

Эти опции s используются как в

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

Он работает для других языков - кажется, что это упущение для Go.

Возможно, это будет ваше впечатление, но я бы порекомендовал вам не попробовать, если вас интересует кросс-языковая совместимость. Поведение одинаково с другими языками. Как пример: недавно я исправил (или лучше: работал) проблему with the Erlang tests, где мне пришлось бороться именно с этой самой проблемой.

Answer 2

У меня такая же проблема недавно. Каждый IDL в разных пространствах имен не работает. Код выглядит плохо, разные пространства имен повсюду, что вы должны помнить, раздражая, чтобы добавлять/удалять пространства имен для каждой мелочи.

Я определяю только одно пространство имен, поэтому я пришел с этим. В принципе, объекты находятся в разных файлах, но они написаны так, как они находятся в одном файле. Таким образом, нет импорта, нет ссылок на разные файлы, нет пространств имен в каждом файле. Я помещаю пространства имен в отдельный файл. Затем мой скрипт объединяет все в один большой файл trirft и компилирует его. Это требует, чтобы вы поставили все в нужном порядке, но он работает на нужные мне языки - Go, C# и Java работают нормально.

Для меня это тоже выглядит как недосмотр. Нет никаких оснований для того, чтобы это было так же, как для Go. Может быть, когда-нибудь я отправлю запрос слияния с поведением, который лучше соответствует другим языкам.