Rust-rocksdb: システムRocksDBとのリンク

これに関連して、これらの環境変数がREADMEとドキュメントに記載されていると便利です。

これは本当に便利です！

openssl-sysの

私はこれに取り組んでいます

@lovesegfaultこれについての進捗状況はどうですか？ rocksdbのビルドは、現時点での私のプロジェクトのビルド時間の最大の部分です：cry：

現在システムライブラリを使用する際の問題は何ですか？ AFAIK、それはpkg-configまたはenv変数を介してうまく機能します。

@aleksussええと、現在のmaster 、 librocksdb-sysをビルドしようとすると、システム全体のライブラリとしてrocksdbがインストールされていても、C ++コンパイラインスタンスの束が起動します。

$ ls /usr/lib/librocksdb.so*
/usr/lib/librocksdb.so  /usr/lib/librocksdb.so.6  /usr/lib/librocksdb.so.6.5.3

オフィスでは他のことが優先されたので、私はこれに取り組むのをやめました。 私は次の約2週間休暇に行くので、うまくいけばこれを取り戻すことができます:)

＃354はライブラリ発見の魔法を追加しないことに注意してください。 RocksDBがpkg-configまたは他の同様のツールをサポートしていないことが主な理由です。

将来的には、対応する環境変数が設定されていない場合に備えて、通常の場所でライブラリを検索する簡単な句を簡単に追加できます。

ああ、なるほど、クレートが_currently_でシステム全体のRocksDBを見つけられなかった場合でも、それは引き続き当てはまります。 何が失敗しているのだろうか。 互換性のあるバージョンだけでなく、同じバージョンの.soを_正確に_探しているのではないでしょうか。

さて、現在のクレートは、それができない場合、システムrocksdbとベンダーを見つけようとします。 ＃354は、ベンダーにするかどうかを機能を通じて選択することを意味します。 ベンダーでない場合は、 ROCKSDB_LIB_DIRを設定する必要があります。そうしないと、役立つエラーメッセージが表示されます。

環境変数が設定されていない場合にライブラリを見つけようとするフォローアップを追加できます。私は一般的にその動作のファンではありません。

@lovesegfault正しく読んでいるかROCKSDB_LIB_DIRが設定されていない場合、rocksdbはベンダーになりますか？ そして、それをシステム全体のライブラリとリンクさせる_唯一の_方法は、 ROCKSDB_LIB_DIRです。

私は興味があります-なぜデフォルトでシステムライブラリを使用することに反対するのですか？ Vendoringは_巨大な_コンパイル時間をもたらします、そして私は利点が何であるかわかりませんか？

@jonhoo
現在の動作
librocksdb-sysはROCKSDB_LIB_DIR envvarを探します。 設定されている場合は、そのディレクトリの.soにリンクします。 設定されていない場合は、代わりにrocksdbをベンダーします。 _exact_同じ動作は、 bzip2などの圧縮ライブラリでも発生します。たとえば、変数はBZIP2_LIB_DIRです。

新しい動作
librocksdb-sysは、新しい（デフォルトの）機能vendorます。 その機能が有効になっている場合、システムライブラリを検索しようとはしません。 代わりに、 rocksdbとすべての圧縮ライブラリをベンダーします。

vendor機能が有効になっていない場合、 librocksdb-sysは、rocksdbや圧縮ライブラリなどのライブラリのベンダー化を試みません。 代わりに、必要なライブラリがどこにあるかを通知するenvvarを探します。 これらのenvvarは、 LIBNAME_LIB_DIR形式です。 システムライブラリの検出は試行されず、ユーザーがそれらを指定する必要があります。 vendor無効にしていて、対応するenvvarの設定を忘れた場合、ビルドは失敗し、設定するように指示するメッセージが表示されます。 envvar。

考えられる将来の動作
将来、 vendorが無効になると、envvarsが設定されていない場合のフォールバックとして、システムライブラリの検出を試みることができます。 私はまだこれを実装していませんが、時間があるときに実装する予定です。

機能を使用してこれを行うのは少し奇妙です。依存関係ツリーの_any_crateにvendor機能セットを含むrocksdbが含まれている場合、RocksDBがベンダーになります。 小さなクレートでは大きな違いはありませんが、RocksDBに複数の推移的な依存関係がある可能性がある大きなバイナリの場合、ベンダーをオプトアウトする方法がない可能性が非常に高くなります。

@jonhooそれは本当です、他にどのようにこれが機能すると思いますか？

私見では、ベンダーはまったく存在しないはずです。ベンダーはすべての悪の根源です。 @aleksussや他のメンテナがそれを許可するなら、私はベンダーを完全に排除したいと思います。

私はあなたに同意します-解決策はベンダーではないことです。 少なくとも、ベンダーはデフォルトの機能セットに含まれるべきではありません。 1つのオプションは、環境変数を使用してベンダーをオプトインさせることです。

@aleksuss @vitvakatuあなたたちはどう思いますか？

推移的な依存関係の場合、機能を制御するのは確かに難しく、ソースからRocksDBをコンパイルするには多くのコストがかかります（私たちのプロジェクトでは、ビルド時間が約30％増加します！）。 しかし、私はベンダーを完全に削除するという考えは好きではありません。 一部のプラットフォームでは、最新のrocksdbバージョンを利用できません。古いUbuntuディストリビューション用に独自のPPAを作成することを余儀なくされました。

したがって、現在の動作を保存したいのですが、おそらくそれを改善します（自動ライブラリ検索？）。 おそらく、ユーザーに（env varを介して）手動でベンダーを有効にするように強制する必要がありますが、一時的な依存関係についても少し面倒です。

さて、現在のマスターでは、librocksdb-sysをビルドしようとすると、システム全体のライブラリとしてrocksdbがインストールされていても、C ++コンパイラインスタンスの束が起動します。

これもかなり奇妙に見えるので、おそらく修正する必要があります。

@vitvakatuええ、ユーザーがベンダーにオプトインするように動作を「反転」するのがおそらく正しい方法だと思います:)

これもかなり奇妙に見えるので、おそらく修正する必要があります。

私はenv変数を設定していないので、これは今日の意図された動作だと思いますか？

了解しました。動作を反転しました:)

@lovesegfault動作を逆にする場合は、 /usr/libなどでrocksdbをデフォルトでbuild.rs検索する必要もあると思います。 そうしないと、env varが設定されていないため、多数のユーザーが突然コンパイルエラーを受け取ることになります。

了解しました。保留中の作業は次のとおりです::

• 図書館の発見
• vendor機能を環境変数に変換します