環境

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

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

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

ゴール

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ページ）が怖いです。

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

にする方法について一般的な質問がfilegroupありdeclare_directoryます。

だから私が考えることができるのは、 filegroup-> pkg_tar-> untar_to_dir(tarball を に untar するルールdeclare_directory) のようなものです。

それはうまくいくでしょう、そして私はすでにそれを証明しました。ただし、ファイルグループの tar および untar を回避するための他のより適切な方法があるかどうかを知りたいですか?

私が試したアイデアの 1 つは、ファイルごとにdeclare_directoryファイルにコピーすることでしたが、非常に複雑でした。しかし、注意が必要な点は、同じディレクトリ構造を新しいディレクトリに保持することを適切に処理できなかったことです。（mkdir以前はたくさんのサブディレクトリが必要だったようにcp）。

BUILD ファイルに次のエイリアスが定義されています。

「実際の」文字列をこのような関数に渡すにはどうすればよいですか?

私は最も素朴なことを試みていますが、それが文字列ではなくエイリアスであることを理解していません: