Libelektra: 錆びたバインディング

Rustについてはよくわかりませんが、 rust-bindgenによって生成されたバインディングはunsafe Rustでのみ使用できると思いますか？ その場合は、より慣用的なRustAPIを使用するラッパーを用意しておくと便利です。

AFAIKのほとんどのRustバインディングには、C APIの1：1マッピング用に1つの*-sysクレートがあり、ほとんどのユーザーがRustで実際に使用するAPIを備えた別のクレートがあります。 RustにkeyDel 、 ksDel 、そして必要に応じて友達を自動的に呼び出すように指示する方法があれば、それは本当に素晴らしいことです。

その場合は、より慣用的なRustAPIを使用するラッパーを用意しておくと便利です。

はい、これが計画です。 そして、そうしている間、C APIと比較して、おそらくC APIの改善点を見つけてください（少なくともドキュメントでは）。

@PhilippGackstatterとしては、議論：にアップロードする方法もを見つけるしてくださいhttps://crates.io/とどのように私たちのCMakeのシステムに結合するのを統合します。

@PhilippGackstatter何か進歩はありますか？ Rustバインディングの拡張にも興味があるかもしれない誰かがいます。

@ markus2330数日前に始めましたが、bindgen、cmake、およびそれをプロジェクトに統合する方法についてほとんど読んでいたので、何も表示されませんでした。 しかし、私は今、最初のいくつかの準備ができています（＃2826を参照）。 私は今、プロジェクトに完全に取り組んでいます。

＃2826からの質問に答えるには（PRはコードに直接関係しない議論を混乱させる傾向があるため、問題について質問することをお勧めします）：

1つは、src / includeのどのヘッダーのバインディングを生成する必要があるかです。 少なくともkdb.hですが、プラグインをサポートせずに、低レベルのAPIに必要なものは他にありますか？

いいえ、低レベルAPIはkdb.hにのみあります

もう1つは、rustup（cargoとrustcのインストールに使用される）をインストールするために、すべてのDockerスクリプトを変更する必要がありますか？

はい、Dockerスクリプトを変更する必要があります。Jenkinsfileも変更する必要があります。 ただし、すべてを変更する必要はありません。最近のディストリビューション用にビルドすれば十分です。

DebianBusterにバンドルされているネイティブのrustコンパイル済みをコンパイルすることもできれば素晴らしいと思います。 Debian Buster dockerファイルはまだマージされていません＃2819

それを自動化する方法はないと思います。

これを行うためのいくつかのアイデアがあります：＃730

Rust-bindgenは、バインディングを生成する2つの方法を提供します。 1つはコマンドライン経由であるため、手動プロセスであり、C-APIのいずれかが変更された場合は繰り返す必要があります。 もう1つは、カーゴビルドが実行されるたびに実行されるビルドスクリプトを介したものです。 これは、ビルドごとにバインディングが再生成されることを意味します。 これが現在実装されているものです。 ただし、バインディングを使用するすべての人が、elekraが必要とする必要なヘッダーを持っている必要があります。 誰かがelektraをインストールしただけでコンパイルしなかった場合、必要なすべての要件を満たしていない可能性があると思います。 C-APIはあまり変更されていないので、ヘッダーを手動で時々再生成する方が理にかなっているのではないでしょうか。

すべてのビルドでの再生成が適切な解決策のようですが、他のバインディングもそのように機能します（スウィッグをインストールする必要があります）。 生成されたヘッダーファイルをインストールするだけで、説明している問題を回避できます。

はい、これが計画です。 そして、そうしている間、C APIと比較して、おそらくC APIの改善点を見つけてください（少なくともドキュメントでは）。

これまでのところ、私は改善のためのいくつかのマイナーな機会を見つけました

• keyGetBinary ：呼び出しコードとして、戻り値-1がmaxSize is 0またはtype mismatch 、あるいは他の何かを意味するかどうかはわかりません。 Rustは戻り引数で明示的なエラー処理を使用するため、タイプの不一致をエラーに一致させ、「maxSize関連」エラーを別のエラーに一致させたいと考えています。 しかし、現在、私はより一般的なエラーを使用する必要があります。 自分で型の不一致をチェックすることもできますが、 keyGetBinaryがそれを行うので、同じチェックを2回行います。
  keySetNameは同様のことを行い、2つの異なるエラーを-1に一致させます。 どちらの場合も、バグ（無効な名前）であるエラーとサウンドプログラム（すでにキーセットにあるキー）で発生する可能性のあるエラーがあるので、私は決定をある程度理解することができます。 しかし、明示性と二重チェックの回避のために-2を使用してみませんか？
• 文法的に、 keyIsDirectBelowはkeyIsDirectlyBelowであるべきではありません🙂？ もしそうなら、Rust APIでこれを修正する必要がありますか？

別の質問： keyRelはCPPバインディングに実装されていません。 Rustでもこれを省略する必要がありますか？

すばらしい作業です。質問から、APIをすでに深く調べていることは明らかです。

自分で型の不一致をチェックすることもできますが、keyGetBinaryがそれを行うので、同じチェックを2回行います。

たぶん、型システムを使用して間違った呼び出しを回避することもできますか？ （keyGetBinaryはバイナリキーでのみ許可されます）

しかし、明示性と二重チェックの回避のために-2を使用してみませんか？

その理由は互換性でした。APIは最初は-1しか返さず、既存のプログラム（エラーをチェックするために==-1がある可能性があります）を壊さずに他のエラーコードを追加することはできません。 しかし、次のリリース（0.9）では、APIを再び壊すことができます。 また、0未満の値はエラーを示していると述べることで、互換性の問題を回避できます。 バインディングによって正確なエラーが発生することに完全に同意します。

これらのAPIの問題を修正しますか？

もしそうなら、Rust APIでこれを修正する必要がありますか？

APIのスペルに違いはありません。 修正する場合は、C APIとすべてのバインディングで修正する必要があります（実際には、JavaとGoのみを手動で調整する必要があり、その他はとにかく正しく再生成されます）。

keyRelはCPPバインディングには実装されていません。 Rustでもこれを省略する必要がありますか？

はい、ご存知かもしれませんが、keyIs（Direct）BelowとkeyRelの機能は重複しています。 keyRelのアイデアは、APIを小さく（したがってライブラリを小さく）保つことでした。 ただし、keyRelをそのまま使用することはできず、速度も遅くなります。 したがって、おそらく0.9以内に削除します。 削除される他の候補については、doc / todo / FUTUREを参照してください。

たぶん、型システムを使用して間違った呼び出しを回避することもできますか？ （keyGetBinaryはバイナリキーでのみ許可されます）

いい考えだ。 BinaryKeyとStringKeyを使用でき、最初のメソッドのみがget_binary()メソッドを使用し、2番目のメソッドのみがget_string()メソッドを使用します。 これを調べます。

これらのAPIの問題を修正しますか？

私はそれを行うことができます。 私にとって優先順位がどうあるべきかによります。 Rustの安全なAPIを完成させた後、RustにプラグインAPIもあるといいとおっしゃいました。 何がより重要かを決めることができます。

いい考えだ。 BinaryKeyとStringKeyを持つことができ、最初のメソッドだけがget_binary（）メソッドを持ち、2番目のメソッドだけがget_string（）メソッドを持つというようになります。 これを調べます。

ありがとう。 キャストが多すぎるかもしれないので、それが良いアイデアかどうか見てみましょう。 また、別のタイプがキーセットのキーに役立つ場合があります（setNameは許可されていません）。

私はそれを行うことができます。 私にとって優先順位がどうあるべきかによります。 Rustの安全なAPIを完成させた後、RustにプラグインAPIもあるといいとおっしゃいました。 何がより重要かを決めることができます。

はい、最初にkdb.hからRust APIを終了してから、あと何時間費やす必要があるかを確認します。

IMO the Rustバインディング（およびその問題に関するバインディング）には、2つのバージョンが必要です。 1つはCAPIを可能な限り反映し、もう1つは最初のバージョンに基づいて構築された言語に対してより慣用的なものです。 BinaryKeyとStringKey （またはジェネリック）の型システムを利用する慣習的なバージョンでは、RustのAPIを簡単に使用できるのであれば、おそらく良い考えです。

@kodebach同意します。 そして、これはelektraおよびelektra-sysクレートでも行われているようです。

@kodebach同意します。 そして、これはelektraおよびelektra-sysクレートでも行われているようです。

私もそう思います。 安全なRustAPIに回避する必要のある制限がある場合は、 elektra_sysをインポートして、1対1のCバインディング関数を直接呼び出すことができます。

ありがとう。 キャストが多すぎるかもしれないので、それが良いアイデアかどうか見てみましょう。 また、別のタイプがキーセットのキーに役立つ場合があります（setNameは許可されていません）。

これは、主要な実装に最適でした。 ただし、KeySetについては、障害が発生しました。 キーを返すメソッドの場合、キーは私が作成した共通のインターフェースに準拠している必要があります。 汎用のreturnパラメーターを持つメソッドget_valueを実装しました。 BinaryKeysの場合はバイト、StringKeysの場合は文字列です。 しかし、さびたバージョンのksNext今何を返しますか？ 「キーインターフェイス」を満たすオブジェクトですが、どのような値がありますか？ 私は1つを選ばなければなりません。
これは署名がどのように見える必要があるかです。ここで、Valueはget_valueが返すタイプです。 指定できるのはバイト（ Vec<u8> ）または文字列のみです。
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

したがって、バイトに統合することはできますが、ユーザーは自分で文字列に変換する必要があります。 StringKeyとBinaryKeysの唯一の違いは、それらのset_valueとget_value実装であるため、この変更により、その明示性が削除され、基本的にはKeysだけになります。

本当の問題は、現在の実装のKeySetが、含まれているキーの種類について明示的ではないが、*キーは明示的であるということだと思います。 しかし、KeySetのインスタンスにStringKeyまたはBinaryKeyのみを含めることを許可することは、私が思うに制限が大きすぎます。
KeyとKeySetの両方が、それらに含まれるものについて明示的であるか、含まれていないかを明示する必要があると思います。 私は今、他のエレクトラと一貫性を保つために、汎用のKeyとKeySetに傾倒しています。
何かご意見は？

使いやすさの観点から、これは最も頻繁に使用されるバリアントであるため、文字列のゲッターを持つキーを返すことは理にかなっています。 このキー（nextによって返される）がKeySetの一部であることがすでにわかっているため、名前のセッターは無効にする必要があります（簡単に可能な場合）。

一般に、型システムは邪魔になるのではなく、ユーザーをサポートする必要があります。 したがって、可能な限りシンプルにしてください。 最も一般的なエラーは次のとおりです。

1. キーセットにあるキーのキー名を変更しようとしています。
2. メタデータキー（または他のconstキー）を変更しようとしています。
3. Key / KeySetの紛らわしい複製とそれらへの参照。
4. 反復が正しく機能しなくなる方法でキーを切り出すためにも使用されるKeySetを反復します。
5. キー/キーセットを解放するのを忘れている

ですから、型システムがそこで役立つのであれば、それは素晴らしいことです。 5.設計上、1。および2.の場合、抽象化が役立つことを願っています。

バイナリ/文字列の混乱は、実際にはかなりまれなエラーです（バイナリキーは非常に一般的ではないため、関数ポインタを保持するために主に使用されます）。

ところで。 APIの安全な使用に関する設計上の決定を記述したい場合は、先に進んでください（ドキュメント/決定）

使いやすさの観点から、これは最も頻繁に使用されるバリアントであるため、文字列のゲッターを持つキーを返すことは理にかなっています。

しかし、すべてのバイトシーケンスが有効なUTF-8であるとは限らないため、実際にはタイプセーフではなくなりますね。

Rustのマクロシステムは非常に強力です。常に正しい型を返す関数を作成する方法があるかもしれません。 たとえば、Kotlinには、マップがキーの値型をエンコードするための手法があります。 APIリファレンスこっちは一例です。

代わりにStringKeySetのみ受け入れることStringKeyバイナリキーは非常にまれであり、ほとんどの構成で使用されていないことから、sのかもしれないメイクセンスを。

使いやすさの観点から、これは最も頻繁に使用されるバリアントであるため、文字列のゲッターを持つキーを返すことは理にかなっています。 このキー（nextによって返される）がKeySetの一部であることがすでにわかっているため、名前のセッターは無効にする必要があります（簡単に可能な場合）。

ただし、まれではありますが、キーが混在するKeySetを使用することは可能です。 次に、常にStringKeyを返し、 get_stringを呼び出すとエラーになりますが、型システムにはget_binaryメソッドがないため、型システムはそれを許可するだけでなく、それに向かってガイドします。

その前に、KeySetを汎用化し、ユーザーがStringKeyのみを内部に持っていると確信している場合はKeySet<StringKey>としてインスタンス化することをお勧めします（RustからのものではないKeySetの場合）。 その場合、それを繰り返すとStringKeysのみが生成されるのは当然のことです。
また、KeySetは、少なくともRustユーザーによって作成された型システムを介して同種であることが強制され、全体的に安全になります。
まれに、バイナリキーが予想される場合、ユーザーはis_binaryとis_stringを確認してから変換する必要があります。これは、安全なメソッド呼び出しです。

Key / KeySetの紛らわしい複製とそれらへの参照。

私にできることは、refcountではなくduplicateの使用を促進することだけだと思います。 パフォーマンスが低下する可能性がありますが、keyDelはRustによって自動的に呼び出されますが、参照カウントは完全に手動です。 したがって、重複は、参照カウントよりも確実に正しく取得するのが簡単です。

反復が正しく機能しなくなる方法でキーを切り出すためにも使用されるKeySetを反復します。

キーセットを繰り返しながら変更するという意味ですか？

ところで。 APIの安全な使用に関する設計上の決定を記述したい場合は、先に進んでください（ドキュメント/決定）

その内容は何でしょうか？

Rustのマクロシステムは非常に強力です。常に正しい型を返す関数を作成する方法があるかもしれません。

何でも具体的なキータイプを含めることができるKeySetの「現在の」設計は、少なくともうまく機能しないと思います。 しかし、私はマクロを調べます。

しかし、すべてのバイトシーケンスが有効なUTF-8であるとは限らないため、実際にはタイプセーフではなくなりますね。

Elektraの文字列またはバイナリ値はUTF-8である必要はありません。 Elektraは、文字列とバイナリのどちらかのみを決定します（0バイトを含む場合があります）。

Rustのマクロシステムは非常に強力です。常に正しい型を返す関数を作成する方法があるかもしれません。 たとえば、Kotlinには、マップがキーの値型をエンコードするための手法があります。 ここにあるAPIリファレンスは一例です。

また、便利な機能に力を入れるように注意する必要があります。 バイナリキーはまれです。

あるいは、StringKeysのみを受け入れるStringKeySetが理にかなっている場合があります。これは、バイナリキーが非常にまれであり、構成ではほとんど使用されないためです。

はい。ただし、StringKeySetは通常のKeySetと見なされます。

ただし、まれではありますが、キーが混在するKeySetを使用することは可能です。 その場合、常にStringKeyを返し、get_stringを呼び出すとエラーになりますが、その型にはget_binaryメソッドがないため、型システムはそれを許可するだけでなく、それに向かってガイドします。

はい、しかし言ったようにこれは小さな問題です。 バイナリデータ（関数アドレスなど）を格納する人は、キーをキャストする方法を見つけるでしょう（それに関するドキュメントがある場合）。

その前に、KeySetを汎用化し、KeySetとしてインスタンス化することをお勧めします。ユーザーが内部にStringKeyのみがあると確信している場合（RustからのものではないKeySetの場合）。 その場合、それを繰り返すとStringKeysのみが生成されるのは当然のことです。

KeySetは（外部から）KDBから取得され、いずれの場合もバイナリデータが含まれている可能性があるため、これは偽の安全性にすぎません。 したがって、私はKeySetを非ジェネリックにすることを好みます。

ジェネリックスを試してみたい場合は、KeySetを（ジェネリック）データ構造に変換するゲッターとセッターを提供してください。 たとえば、整数のElektra配列からVec<i32> 。

キーセットを繰り返しながら変更するという意味ですか？

はいcutはKeySetを変更します。 一般に、イテレータは安全に実行できますが、多くの人がそれを正しく行うのに問題があります。

その内容は何でしょうか？

ここで説明する内容と、それをどのように設計したかについての要約。

何でも具体的なキータイプを含めることができるKeySetの「現在の」設計は、少なくともうまく機能しないと思います。

同意します。

しかし、私はマクロを調べます。

優先しないでください。

Elektraの文字列またはバイナリ値はUTF-8である必要はありません。

次に、クイック検索によると、 String代わりにOsStringまたはCStringを使用する必要があります。

Elektraの文字列またはバイナリ値はUTF-8である必要はありません。

次に、クイック検索によると、 String代わりにOsStringまたはCStringを使用する必要があります。

現在、RustのString （UTF-8）をCStringに変換してから、elektraに渡します。 理論的根拠は、 Stringがデフォルトの文字列であり、他のほとんどのライブラリはそれで動作することを期待しているということです。
代わりに、高レベルAPIにCString要求して返すようにすることができます。これにより、ユーザーがStringを必要とする場合に、変換コードを処理する必要があります。 これにより、APIが薄くなり、処理する必要のあるエラー処理が少なくなります。 ほとんどのユーザーがAPIをどのように使用したいかにかかっていると思いますが、これについてはあまり洞察がありません。

言語の最も一般的な文字列型を返すのが最善であることに同意します。 非UTF8文字列はまれである必要があります（おそらくバイナリよりもさらにまれです）。

言語の最も一般的な文字列型を返すのが最善であることに同意します。 非UTF8文字列はまれである必要があります（おそらくバイナリよりもさらにまれです）。

UTF-8からCストリングに向かって、Rust-> C方向を処理するための最良の方法を見つけようとしています。 UTF-8文字列にはゼロバイトを含めることができますが、それが表示されるコードポイントはNUL文字のみであり、それ以外の場合は含まれません。 文字列にゼロバイトを含めることは許可されていないということを、バインディングドキュメントの前提条件としてこれを述べるのは合理的だと思います。 とにかくそうなると、コードはその時点でパニックになります。

もう1つの可能性は、文字列を受け取るすべての集合関数からエラーを返すことです。 しかし、ユーザーはこのNulError常に処理する必要があり、実際には返されることはありません。

keyNewは、割り当てエラー時にNULLポインターを返す可能性があります。 Rustでは、明示的なエラーまたはパニックを返すことができますが、暗黙的なnullを返すことはできません。 シグナルエラーの錆文書はメモリの致命的なエラーとSTDLIBアウト考慮アボートこの場合は秒。 Javaバインディングはこのケースを処理していないようです。したがって、 NullPointerExceptionがスローされるため、プロセスも終了すると思います。
ここでパニックを呼び出すのが最善であることに同意しますか（中絶はデストラクタの実行を許可しません）？

文字列にゼロバイトを含めることは許可されていないということを、バインディングドキュメントの前提条件としてこれを述べるのは合理的だと思います。 とにかくそうなると、コードはその時点でパニックになります。

はい、合理的です。

ここでパニックを呼び出すのが最善であることに同意しますか（中絶はデストラクタの実行を許可しません）？

はい、mallocが失敗した場合にパニックになるのは理にかなっています。 （Rustの場合、stdlibも同じように動作します。Cでは、stdlibは中止されないため、C-Elektraも中止されません）。

Rustバインディングがmasterにマージされたので、それらをcrates.ioに公開したいと思います。
バインディングとelektra自体の成熟度が異なるという理由だけで、elektraに関連付けられるのではなく、バージョンを（デフォルト） 0.1.0に設定して公開することをお勧めします。 @ markus2330に同意しますか？

https://crates.ioで公開するには、GitHubアカウントが必要です。 クレートの所有権はアカウント間で譲渡できるので、今のところ自分のものを使用できます。 または、他の誰かがログインして、公開に必要なAPIトークンを送ってくれる可能性があります。

それらをcrates.ioに公開していただきありがとうございます：sparkle：

それらはElektraのリポジトリの一部であるため、バージョンをElektraに直接結び付けます。 しかし、それはそれほど重要ではありません。crates.ioに通常、特定のバージョンスキーマがある場合は、そこで一般的なものに固執することをお勧めします。

または、他の誰かがログインして、公開に必要なAPIトークンを送ってくれる可能性があります。

許可されたログインしました。 APIトークンをお送りします。

それらはElektraのリポジトリの一部であるため、バージョンをElektraに直接結び付けます。 しかし、それはそれほど重要ではありません。crates.ioに通常、特定のバージョンスキーマがある場合は、そこで一般的なものに固執することをお勧めします。

これに関する主な問題は、セマンティックバージョニングによると、バインディングに重大な変更を加える必要がある場合、それに応じてバージョンをアップグレードすることはできないということです。 したがって、elektraが変更を行う場合にのみ、重大な変更を行うことができました。

セマンティックバージョニングによると、バージョンが0始まる限り、重大な変更を行うことができます。 Elektra 1.0をリリースする場合、バインディングを安定させることも私たちの関心事です。 また、失敗した場合でも、将来的にはバージョンを独立させるオプションがあります（Rustバインディングのメジャーバージョンを増やすだけです）。 ですから、今はエレクトラのバージョンを使うのが安全だと思います。

そうです、後でメジャーバージョンを増やすことは考えていませんでした。

現在、 wrapper.hは#include "kdb.h"を指定して、kdbヘッダーを含め、そのバインディングを生成します。 しかし、clangはヘッダーを見つけられません（たとえば、 ubuntu:18.10 ）。 したがって、ビルドするために/usr/include/elektraを含めるようにclangに明示的に指示する必要があります。
このソリューションがほとんどのディストリビューションで機能するように、elektraは常に/usr/include/elektraインストールされていますか？

このソリューションがほとんどのディストリビューションで機能するように、elektraは常に/ usr / include / elektraにインストールされていますか？

はい、 /usr/include/kdb.hを使用する別のライブラリ（Kerberosからだと思います）があるためです。

今のところ、 /usr/include/elektraはインクルードパスの一部である必要がありますが、AFAIKでは、代わりに#include <elektra/kdb.h>を使用できるように変更したいと考えています。

このソリューションがほとんどのディストリビューションで機能するように、elektraは常に/ usr / include / elektraにインストールされていますか？

デフォルトでは/ usr / local / include / elektraですが、ほとんどのディストリビューションは/ usr / include / elektraを使用しますが、保証はありません。 そのため、ビルドシステムは通常、ヘッダーファイルを見つけるためのサポートを提供しています。 Elektraはcmakeとpkg-configをサポートしています。

これが必要な場所についてのコンテキストを教えてください。

代わりに使用できます。

代わりに使用する必要があります。 関連するPRは＃2880です

#include <elektra/kdb.h>への変更はUbuntuで間違いなく機能します。 そこで、 /usr/include/elektraを含める代わりに、そのパスに変更します。

#include <elektra/kdb.h>への変更はUbuntuで間違いなく機能します。 そこで、 /usr/include/elektraを含める代わりに、そのパスに変更します。

おそらくすべてのヘッダーで機能するとは限りません。一部のヘッダーは、インクルードパスに/usr/include/elektraが含まれていることに依存しています。

おそらく（可能であれば）最善の方法は、 pkg-configまたはcmake --find-packageを使用してElektraファイルを見つけることです（IMO cmake方が適しています）。

これが必要な場所についてのコンテキストを教えてください。

したがって、ユーザーが自分のマシンでelektraをコンパイルする場合、必要なのはrust / cargoだけで、バインディングを使用できます。 しかし、crates.ioを使用する必要がある他のユースケースは、誰かがパッケージマネージャーを介してelektra（およびヘッダー）をインストールする場合です。 その後、ライブラリとヘッダーが利用可能になります。 これで、ユーザーは依存関係にelektraを含め、貨物はelektra-sysクレートをフェッチします。 バインディングを生成するためにビルドスクリプトとclangのみに依存します。 しかし、clangはどういうわけかkdb.hを見つける必要があります。 したがって、ビルドスクリプトで追加のハードコードされたインクルードパスを渡すか、 #include ...ステートメントを直接変更することができます。

おそらく（可能であれば）最善の方法は、 pkg-configまたはcmake --find-packageを使用してElektraファイルを見つけることです（IMO cmake方が適しています）。

ビルド依存関係としてpkg-configまたはcmakeを追加して、この方法でkdb.hを見つけることができます。 これを調べます。 これが最も信頼できる方法であることに同意します。

はい、ビルドスクリプトでpkg-configを呼び出してみることができます。 pkg-configが利用できない場合は、/ usr / include / elektraや/ usr / local / include / elektraなどのハードコードされたパスを試すことができます。 （crates.ioがpkg-configを利用可能にする必要がない場合。）

この木枠を試すことができます

はい、ビルドスクリプトでpkg-configを呼び出してみることができます。 pkg-configが利用できない場合は、/ usr / include / elektraや/ usr / local / include / elektraなどのハードコードされたパスを試すことができます。 （crates.ioがpkg-configを利用可能にする必要がない場合。）

オプションの依存関係としてpkg-configを追加しました。 追加された場合は、elektraを検索し、提供されたインクルードされたものを使用します。 それ以外の場合は、指定した2つのディレクトリを検索します。

バインディングが公開されました： elektraおよびelektra-sys ：smiley：

docs.rsビルド環境にlibelektraのシステム依存関係がないため、ドキュメントはビルドされませんでした。 さらに、9月30日にビルド環境を変更します。
9月30日に正しくビルドされるように、依存関係としてlibelektraを追加するリクエストを送信しました。 彼はまた、既存の環境にパッケージを追加したので、ドキュメントが利用可能になりました：+1：

＃2980がマージされた後、この問題は解決できると思います。

とてもいいです、彼らは超高速で反応しました。 彼らがかなり古いlibelektraでそれを構築することは問題になるでしょうか？ （私はどのバージョンをチェックしませんでしたが、パッケージマネージャーからそれが含まれている場合、それは間違いなく0.9より古いでしょう。）

elektraクレートはドキュメントにすぎないため、問題はありません。 elektra-sys現在のバージョンではなく、生成されたバージョンのエレクトラが含まれていると思います。 しかし、ラッパーの代わりに生のバインディングを使用する人はほとんどいないと思います。 したがって、ドキュメントを自動的に作成することとのわずかなトレードオフがあります。

次に、リポジトリ内のドキュメントへのリンクを追加できますか？

とにかくelektra-sysはほとんど使用できないようです。 それはエレクトラとは何の関係もない/ほとんど関係のない何百ものシンボルを示しています。 さらに、個々の機能に関する文書はありません。

https://docs.rs/elektra-sys/0.9.0/elektra_sys/fn.keyString.html

次に、リポジトリ内のドキュメントへのリンクを追加できますか？

はい、既存のPRに追加します

とにかくelektra-sysはほとんど使用できないようです。 それはエレクトラとは何の関係もない/ほとんど関係のない何百ものシンボルを示しています。

これを調べます。

さらに、個々の機能に関する文書はありません。

-sysクレートにはdocu（たとえば、 openssl-sys ）がないのが一般的です。これは、Cと同等の1対1の変換であるためです。 したがって、Cドキュメントを直接検索する必要があります。 また、すべてのドキュメントを手作業でコピーする必要があるため、メンテナンスの負担が増えます。 ただし、メインのドキュメントページでhttps://doc.libelektra.org/api/current/html/index.htmlにリンクできます。

とにかくelektra-sysはほとんど使用できないようです。 それはエレクトラとは何の関係もない/ほとんど関係のない何百ものシンボルを示しています。

これを調べます。

これは＃2980で修正されており、次回クレートを公開するときにdocs.rsで修正される予定です。

ただし、メインのドキュメントページでhttps://doc.libelektra.org/api/current/html/index.htmlにリンクできます。

はい、良い考えですね！