0

環境

Bazel内で protobuf code-gen を実行しようとしていますが、最終的にrules_proto_grpcを使用していますが、内部コアはrules_protoを使用しており、今すぐこれらに集中できます。

一般的な考え方は、複数の API インスタンス化を含むmonorepoを構築し、すべてが共通のベース/コア APIを共有/特殊化することです。

単純化すると、次のようになります。

generic-api/

    service.proto

        import "generic-api/service_impl/service_info.proto"

        service Service {
          rpc ServiceInfo(RequestServiceInfo) returns (ResponseServiceInfo) {}
        }    

  service_impl/

      service_info.proto

          // Modelling this import is probably the core issue! 
          import "generic-api/specific_impl/X/specific_service_info.proto";

          message RequestServiceInfo {}

          message ResponseServiceInfo {
            repeated SpecificServiceInfo specific_info = 1;
          }


  specific_impl/

      service_a/

          specific_service_info.proto

              message SpecificServiceInfo {
                string sometext = 1;
              }                

      service_b/

          specific_service_info.proto

              message SpecificServiceInfo {
                bytes somebytes = 1;
              }

ゴール

service_aビルド プロセスでは、両方の ( + service_b) インスタンス化に必要なターゲットを準備する必要があります。

  • 最終的には、( message の)汎用部分とservice_a特殊化を含む言語 X コードが必要になります。SpecificServiceInfo
  • 最終的には、( message の)汎用部分とservice_b特殊化を含む言語 X コードが必要になります。SpecificServiceInfo

これらの 2 つの出力は独立しています。彼らはこのコアを共有し、同じリポジトリに住んでいます。

ベゼルなし

Bazelほど厳密ではない単純なツールチェーンは、基本部分の a-prioriの 2 つのコピーを2 つの分離されたディレクトリに準備し、特定の実装を追加し、それらの両方をインスタンス化/コンパイルするだけです。

ある時点で物事がより複雑になるため、最初の目標はbazel内でこれを表現することであるという事実を除いて、それに関する問題はないと思います。

試行/問題

うーん...実際、どこから始めればいいのかさえわかりません。

上記の分離されたコピーアプローチをシミュレートしようとしましたが、これを行うことができませんでした。私はマクロgenruleのいくつかの組み合わせを試しました (コピーのようなアプローチは、genruleの背後にあるビルド時の固定ファイル カーディナリティの考え方に反して機能します) が、あらゆる種類の問題が発生したため、いくつかの基本的な概念を見逃しているようです。

コアの問題は、直接接続されていない次の 2 つを同期しているようです。

  • bazel ターゲットのような管理 (例: base + service_a を全体として表現)
  • importsWITHIN それらの.protoファイルが機能する ようにパス構造を維持する
    • 特に:import "generic-api/specific_impl/X/specific_service_info.proto";service_info.proto

WORKSPACE 相対インポートで動作するようにrules_proto設計されているようです。相対インポートなしでそれらのインポートでvsを指定するのは面倒に見えるので、これはこれをより難しくしているようです。service_aservice_b

import_prefix役立つかどうか、またはstrip_import_prefix役立つかどうかはわかりません。import public / exportsも成分かもしれませんが、サポートされていないJava免責事項(protobufページ)が怖いです。

このようなことを達成する方法についてアイデアを持っている人はいますか? マクロ/ジャンル パスは可能か、それともより複雑なアプローチが必要か?

4

0 に答える 0