Libelektra: Ikatan Karat

Saya tidak tahu banyak tentang Rust, tapi saya kira binding yang dihasilkan oleh rust-bindgen hanya dapat digunakan di unsafe Rust? Jika itu masalahnya, alangkah baiknya untuk memiliki pembungkus di sekitar mereka yang memiliki API Karat yang lebih idiomatis.

AFAIK sebagian besar pengikatan Rust memiliki satu peti *-sys untuk pemetaan 1:1 dari C API dan peti lain dengan API yang sebenarnya akan digunakan sebagian besar pengguna di Rust. Jika ada cara untuk memberitahu Rust untuk secara otomatis memanggil keyDel , ksDel dan teman-teman bila perlu itu akan sangat bagus.

Jika itu masalahnya, alangkah baiknya untuk memiliki pembungkus di sekitar mereka yang memiliki API Karat yang lebih idiomatis.

Ya, ini rencananya. Dan saat melakukannya, bandingkan juga dengan C API dan mungkin temukan peningkatan di C API (setidaknya di dokumen).

@PhilippGackstatter Seperti yang dibahas: Cari tahu juga cara mengunggah ke https://crates.io/ dan cara mengintegrasikan pengikatan dalam sistem CMake kami.

@PhilippGackstatter ada kemajuan? Kami memiliki seseorang yang mungkin juga tertarik untuk memperpanjang binding Rust.

@ markus2330 Saya mulai beberapa hari yang lalu, tapi saya kebanyakan membaca tentang bindgen, cmake dan bagaimana mengintegrasikannya ke dalam proyek, jadi tidak ada yang bisa ditampilkan. Tapi saya sudah menyiapkan beberapa hal pertama sekarang (lihat #2826). Saya sepenuhnya mengerjakan proyek sekarang.

Untuk menjawab pertanyaan dari #2826 (harap lebih suka mengajukan pertanyaan dalam masalah karena PR cenderung membingungkan untuk diskusi yang tidak terkait langsung dengan kode):

Salah satunya adalah, header mana di src/include yang saya perlukan untuk membuat binding. Setidaknya kdb.h, tetapi apakah ada yang lain yang saya perlukan untuk api tingkat rendah, tanpa dukungan plugin?

Tidak, API tingkat rendah hanya ada di kdb.h

Yang lainnya adalah, apakah saya harus mengubah semua skrip buruh pelabuhan untuk menginstal rustup (yang digunakan untuk menginstal kargo dan rustc)?

Ya, Anda perlu mengubah skrip buruh pelabuhan dan mungkin juga file Jenkins. Tetapi Anda tidak perlu mengubah semuanya, jika Anda membangun untuk distribusi terbaru, itu sudah cukup.

Akan lebih baik jika Anda juga bisa mengkompilasinya dengan rust asli yang dikompilasi dibundel dalam Debian Buster. File buruh pelabuhan Debian Buster belum digabungkan #2819

Saya kira tidak ada cara otomatis untuk melakukan itu.

Ada beberapa ide untuk melakukan ini: #730

Rust-bindgen menawarkan dua cara untuk menghasilkan binding. Salah satunya adalah melalui commandline, yang karenanya merupakan proses manual dan perlu diulang jika ada perubahan di C-API. Yang lainnya adalah melalui skrip build, yang dijalankan setiap kali build kargo berjalan. Itu berarti binding dibuat ulang pada setiap build. Inilah yang saat ini diterapkan. Namun, ini mengharuskan setiap orang yang menggunakan binding untuk memiliki header yang dibutuhkan oleh elekra. Saya membayangkan, jika seseorang hanya menginstal elektra tetapi tidak mengkompilasinya, dia mungkin tidak memenuhi semua persyaratan yang diperlukan. Mungkin lebih masuk akal untuk membuat ulang header sesekali, secara manual, karena C-API tidak banyak berubah lagi?

Regenerasi pada setiap build tampaknya menjadi solusi yang tepat, binding lainnya juga berfungsi seperti itu (mereka membutuhkan swig untuk diinstal). Anda cukup menginstal file header yang dihasilkan untuk menghindari masalah yang Anda gambarkan.

Ya, ini rencananya. Dan saat melakukannya, bandingkan juga dengan C API dan mungkin temukan peningkatan di C API (setidaknya di dokumen).

Sejauh ini, saya telah menemukan beberapa peluang kecil untuk perbaikan

• keyGetBinary : Sebagai kode panggilan, saya tidak tahu apakah nilai balik -1 berarti maxSize is 0 atau type mismatch , atau yang lainnya. Karena Rust menggunakan penanganan kesalahan eksplisit dalam argumen pengembaliannya, saya ingin dapat mencocokkan ketidakcocokan jenis dengan kesalahan, dan kesalahan "berhubungan dengan maxSize" dengan kesalahan lainnya. Tetapi saat ini saya harus menggunakan kesalahan yang lebih umum. Saya dapat memeriksa sendiri ketidakcocokan jenis, tetapi keyGetBinary melakukan itu, jadi saya memiliki pemeriksaan yang sama dua kali.
  keySetName melakukan hal serupa, mencocokkan dua kesalahan berbeda dengan -1. Dalam kedua kasus ada kesalahan yang merupakan bug (nama tidak valid) dan kesalahan yang dapat terjadi pada program suara (kunci sudah di keyset), jadi saya bisa memahami keputusannya. Tetapi mengapa tidak menggunakan -2 untuk kejelasan dan menghindari pemeriksaan ganda?
• Secara tata bahasa, bukankah seharusnya keyIsDirectBelow menjadi keyIsDirectlyBelow ? Jika demikian, haruskah saya memperbaikinya di Rust API?

Pertanyaan lain: keyRel tidak diimplementasikan di CPP Bindings. Haruskah saya menghilangkan ini di Rust juga?

Kerja bagus, dari pertanyaan Anda, jelas bahwa Anda sudah melihat secara mendalam di API.

Saya dapat memeriksa sendiri ketidakcocokan jenis, tetapi keyGetBinary melakukan itu, jadi saya memiliki pemeriksaan yang sama dua kali.

Mungkin Anda bahkan dapat menggunakan sistem tipe untuk menghindari panggilan yang salah? (keyGetBinary hanya diperbolehkan pada kunci biner)

Tetapi mengapa tidak menggunakan -2 untuk kejelasan dan menghindari pemeriksaan ganda?

Alasannya adalah kompatibilitas: API awalnya hanya mengembalikan -1 dan tidak mungkin menambahkan kode kesalahan lain tanpa merusak program yang ada (yang mungkin memiliki ==-1 untuk memeriksa kesalahan). Tapi dengan rilis berikutnya (0.9) kita bisa memecahkan API lagi. Dan kita dapat menghindari masalah kompatibilitas dengan menyatakan bahwa setiap nilai di bawah 0 menunjukkan kesalahan. Saya sepenuhnya setuju bahwa binding harus menghasilkan kesalahan yang tepat.

Apakah Anda ingin memperbaiki masalah API ini?

Jika demikian, haruskah saya memperbaikinya di Rust API?

API tidak boleh berbeda dalam ejaan. Jika kami memperbaikinya, kami harus memperbaikinya di C API dan semua binding (sebenarnya hanya Java dan Go yang perlu diadaptasi secara manual, yang lain akan dibuat ulang dengan benar).

keyRel tidak diimplementasikan di CPP Bindings. Haruskah saya menghilangkan ini di Rust juga?

Ya, karena Anda mungkin sudah memperhatikan keyIs(Direct)Below dan keyRel memiliki fungsionalitas yang tumpang tindih. Ide keyRel adalah untuk menjaga API tetap kecil (dan dengan demikian perpustakaan kecil). Tetapi keyRel apa adanya tidak dapat digunakan dan juga lambat. Jadi kemungkinan besar kami akan menghapusnya dalam waktu 0,9. Lihat doc/todo/FUTURE untuk kandidat lain yang akan dihapus.

Mungkin Anda bahkan dapat menggunakan sistem tipe untuk menghindari panggilan yang salah? (keyGetBinary hanya diperbolehkan pada kunci biner)

Itu ide yang bagus. Saya dapat memiliki BinaryKey dan StringKey dan hanya yang pertama akan memiliki metode get_binary() dan hanya yang kedua akan memiliki metode get_string() , dan seterusnya. Aku akan melihat ke dalam ini.

Apakah Anda ingin memperbaiki masalah API ini?

Saya bisa melakukan itu. Tergantung pada apa yang harus menjadi prioritas bagi saya. Setelah menyelesaikan API aman untuk Rust, Anda mengatakan akan menyenangkan juga memiliki API plugin di Rust. Anda dapat memutuskan apa yang lebih penting.

Itu ide yang bagus. Saya dapat memiliki BinaryKey dan StringKey dan hanya yang pertama yang memiliki metode get_binary() dan hanya yang kedua yang memiliki metode get_string(), dan seterusnya. Aku akan melihat ke dalam ini.

Terima kasih. Mungkin membutuhkan terlalu banyak gips, jadi mari kita lihat apakah itu ide yang bagus. Juga tipe lain mungkin berguna untuk kunci di set kunci (di mana setName tidak diizinkan).

Saya bisa melakukan itu. Tergantung pada apa yang harus menjadi prioritas bagi saya. Setelah menyelesaikan API aman untuk Rust, Anda mengatakan akan menyenangkan juga memiliki API plugin di Rust. Anda dapat memutuskan apa yang lebih penting.

Ya, selesaikan dulu Rust API dari kdb.h dan kemudian kita akan melihat berapa jam lagi yang harus kita habiskan.

IMO pengikatan Rust (dan pengikatan apa pun dalam hal ini) harus memiliki dua versi. Satu yang mencerminkan C API sedekat mungkin dan satu lagi yang lebih idiomatis untuk bahasa yang dibangun di atas versi pertama. Dalam versi idiomatik menggunakan sistem tipe dengan BinaryKey dan StringKey (atau bahkan obat generik) mungkin merupakan ide yang bagus, jika itu membuat penggunaan API dari Rust menjadi lebih mudah.

@kodebach saya setuju. Dan ini tampaknya juga dilakukan dengan peti elektra dan elektra-sys.

@kodebach saya setuju. Dan ini tampaknya juga dilakukan dengan peti elektra dan elektra-sys.

Ya saya pikir juga begitu. Jika Rust API yang aman memiliki batasan yang perlu diatasi, seseorang dapat mengimpor elektra_sys dan memanggil fungsi pengikatan C satu-ke-satu secara langsung.

Terima kasih. Mungkin membutuhkan terlalu banyak gips, jadi mari kita lihat apakah itu ide yang bagus. Juga tipe lain mungkin berguna untuk kunci di set kunci (di mana setName tidak diizinkan).

Ini berhasil dengan baik untuk implementasi kunci. Namun untuk KeySets, saya mengalami hambatan. Untuk metode apa pun yang mengembalikan Kunci, itu harus sesuai dengan antarmuka umum yang saya buat. Saya telah menerapkan metode get_value yang memiliki parameter pengembalian umum. Untuk BinaryKeys itu byte, untuk StringKeys itu string. Tapi apa versi rust dari ksNext kembali sekarang? Objek yang memenuhi "antarmuka kunci", tetapi dengan nilai apa? Saya harus memilih satu.
Seperti inilah tampilan tanda tangan, di mana Nilai adalah tipe yang dikembalikan oleh get_value . Saya hanya dapat menentukan byte ( Vec<u8> ) atau String.
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

Jadi saya bisa menyatukannya menjadi byte, tetapi kemudian pengguna harus mengonversi ke string sendiri. Karena satu-satunya perbedaan StringKey dan BinaryKeys adalah implementasi set_value dan get_value , perubahan ini akan menghapus ketegasan itu dan pada dasarnya saya hanya memiliki Kunci lagi.

Saya kira masalah sebenarnya adalah bahwa KeySet dalam implementasi saat ini tidak eksplisit tentang jenis kunci apa yang dikandungnya, tetapi *kuncinya. Tetapi membiarkan instance KeySet hanya berisi StringKey atau BinaryKey adalah batasan yang terlalu besar, saya kira.
Saya pikir baik Key dan KeySet harus eksplisit tentang apa yang dikandungnya atau tidak sama sekali. Saya condong ke Key dan KeySet generik sekarang, hanya untuk konsisten dengan elektra lainnya.
Ada pikiran?

Dari sudut pandang kegunaan, akan masuk akal untuk mengembalikan Kunci yang memiliki pengambil untuk sebuah String, karena ini adalah varian yang paling sering digunakan. Setter untuk nama harus dinonaktifkan (jika memungkinkan), karena kita sudah tahu bahwa kunci ini (dikembalikan oleh berikutnya) adalah bagian dari KeySet.

Secara umum, sistem tipe harus mendukung pengguna, tidak menghalangi. Jadi buatlah sesederhana mungkin. Kesalahan yang paling umum adalah:

1. mencoba mengubah nama kunci untuk kunci yang ada di keyset.
2. mencoba mengubah kunci meta-data (atau kunci const lainnya).
3. duplikasi Key/KeySet yang membingungkan dan referensinya.
4. iterasi atas KeySets yang juga digunakan untuk memotong kunci sedemikian rupa sehingga iterasi tidak berfungsi dengan benar lagi.
5. lupa membebaskan Kunci/KeySet

Jadi jika sistem tipe dapat membantu di sana, itu akan sangat bagus. 5. semoga tidak mungkin dengan desain, untuk 1. dan 2. abstraksi Anda akan membantu.

Kebingungan biner/string sebenarnya adalah kesalahan yang agak jarang (karena kunci biner sangat tidak biasa: sebagian besar digunakan untuk menahan pointer fungsi).

Omong-omong. jika Anda ingin menulis keputusan desain tentang penggunaan API yang aman, silakan (doc/decision)

Dari sudut pandang kegunaan, akan masuk akal untuk mengembalikan Kunci yang memiliki pengambil untuk sebuah String, karena ini adalah varian yang paling sering digunakan.

Tetapi tidak setiap urutan byte adalah UTF-8 yang valid sehingga tidak akan benar-benar menjadi typesafe lagi, bukan?

AFAIK sistem makro di Rust sangat kuat, mungkin ada cara untuk menulis fungsi yang selalu mengembalikan tipe yang benar. Misalnya, di Kotlin ada teknik peta untuk mengkodekan tipe nilai dalam kunci. Referensi API di sini adalah contohnya.

Atau StringKeySet yang hanya menerima StringKey mungkin masuk akal, karena kunci biner sangat jarang dan sebagian besar tidak digunakan dalam konfigurasi.

Dari sudut pandang kegunaan, akan masuk akal untuk mengembalikan Kunci yang memiliki pengambil untuk sebuah String, karena ini adalah varian yang paling sering digunakan. Setter untuk nama harus dinonaktifkan (jika memungkinkan), karena kita sudah tahu bahwa kunci ini (dikembalikan oleh berikutnya) adalah bagian dari KeySet.

Tetapi masih mungkin, meskipun jarang, untuk memiliki KeySet dengan kunci campuran. Kemudian selalu mengembalikan StringKey dan memanggil get_string akan menjadi kesalahan, tetapi sistem tipe tidak hanya mengizinkannya tetapi juga memandu Anda ke sana, karena tidak ada metode get_binary pada tipe itu.

Sebelum melakukan itu, saya sarankan membuat KeySet generik dan membuat instance sebagai KeySet<StringKey> jika pengguna yakin hanya ada StringKeys di dalamnya (untuk KeySet yang tidak berasal dari Rust). Maka wajar jika mengulanginya hanya akan menghasilkan StringKeys.
Itu juga akan menegakkan bahwa KeySets homogen melalui sistem tipe, setidaknya yang dibuat oleh pengguna Rust, yang secara keseluruhan akan lebih aman.
Dalam kasus yang jarang terjadi di mana kunci biner diharapkan, pengguna harus memeriksa dengan is_binary dan is_string dan kemudian mengonversi, yang akan menjadi pemanggilan metode yang aman.

duplikasi Key/KeySet yang membingungkan dan referensinya.

Saya pikir satu-satunya hal yang dapat saya lakukan adalah mempromosikan penggunaan duplikat daripada jumlah referensi. Ini mungkin lebih buruk untuk kinerja, tetapi keyDel dipanggil secara otomatis oleh Rust, sementara penghitungan ref sepenuhnya manual. Jadi duplikasi tentu lebih mudah dilakukan daripada penghitungan ref.

iterasi atas KeySets yang juga digunakan untuk memotong kunci sedemikian rupa sehingga iterasi tidak berfungsi dengan benar lagi.

Apakah maksud Anda memodifikasi keyset saat mengulanginya?

Omong-omong. jika Anda ingin menulis keputusan desain tentang penggunaan API yang aman, silakan (doc/decision)

Apa yang akan menjadi konten itu?

AFAIK sistem makro di Rust sangat kuat, mungkin ada cara untuk menulis fungsi yang selalu mengembalikan tipe yang benar.

Saya pikir desain KeySet "saat ini" yang dapat berisi apa saja dan tipe Kunci konkret tidak berfungsi bersama, setidaknya tidak dengan baik. Tapi saya akan melihat ke makro.

Tetapi tidak setiap urutan byte adalah UTF-8 yang valid sehingga tidak akan benar-benar menjadi typesafe lagi, bukan?

Baik string atau nilai biner Elektra tidak perlu UTF-8. Elektra hanya memutuskan antara string dan biner (mungkin berisi 0 byte).

AFAIK sistem makro di Rust sangat kuat, mungkin ada cara untuk menulis fungsi yang selalu mengembalikan tipe yang benar. Misalnya, di Kotlin ada teknik peta untuk mengkodekan tipe nilai dalam kunci. Referensi API di sini adalah contohnya.

Kita juga perlu berhati-hati dalam mengupayakan fitur-fitur yang bermanfaat. Kunci biner jarang terjadi.

Atau StringKeySet yang hanya menerima StringKeys mungkin masuk akal, karena kunci biner sangat jarang dan sebagian besar tidak digunakan dalam konfigurasi.

Ya, tapi saya akan melihat StringKeySet sebagai KeySet normal.

Tetapi masih mungkin, meskipun jarang, untuk memiliki KeySet dengan kunci campuran. Kemudian selalu mengembalikan StringKey dan memanggil get_string akan menjadi kesalahan, tetapi sistem tipe tidak hanya mengizinkannya tetapi juga memandu Anda ke arah itu, karena tidak ada metode get_binary pada tipe itu.

Ya, tapi seperti yang dikatakan ini adalah masalah kecil. Orang-orang yang menyimpan data biner (seperti alamat fungsi) akan mengetahui cara menggunakan Kunci (jika ada beberapa dokumen tentangnya).

Sebelum melakukan itu, saya sarankan membuat KeySet generik dan membuat instance sebagai KeySetjika pengguna yakin hanya ada StringKeys di dalamnya (untuk KeySet yang tidak berasal dari Rust). Maka wajar jika mengulanginya hanya akan menghasilkan StringKeys.

Itu hanya keamanan palsu karena KeySets berasal dari KDB (eksternal) dan mereka mungkin berisi data biner dalam hal apa pun. Jadi saya lebih suka memiliki KeySet non-generik.

Jika Anda ingin bermain-main dengan generik, sediakan getter dan setter yang mengonversi KeySets menjadi struktur data (generik). Misalnya array Elektra bilangan bulat ke Vec<i32> .

Apakah maksud Anda memodifikasi keyset saat mengulanginya?

Ya cut memodifikasi KeySet. Secara umum iterator aman untuk melakukannya tetapi banyak orang memiliki masalah untuk melakukannya dengan benar.

Apa yang akan menjadi konten itu?

Ringkasan dari apa yang kami diskusikan di sini dan bagaimana Anda mendesainnya.

Saya pikir desain KeySet "saat ini" yang dapat berisi apa saja dan tipe Kunci konkret tidak berfungsi bersama, setidaknya tidak dengan baik.

Saya setuju.

Tapi saya akan melihat ke makro.

Tolong jangan diprioritaskan.

Baik string atau nilai biner Elektra tidak perlu UTF-8.

Kemudian kita harus menggunakan OsString atau CString daripada String menurut pencarian cepat.

Baik string atau nilai biner Elektra tidak perlu UTF-8.

Kemudian kita harus menggunakan OsString atau CString daripada String menurut pencarian cepat.

Saat ini saya sedang mengonversi antara String Rust (yang merupakan UTF-8) ke CString sebelum meneruskannya ke elektra. Alasannya adalah, bahwa String adalah string default dan sebagian besar perpustakaan lain berharap untuk bekerja dengan itu.
Saya malah dapat membuat API tingkat tinggi meminta dan mengembalikan CString s, sehingga pengguna harus berurusan dengan kode konversi, jika mereka membutuhkan String . Itu akan membuat API yang lebih tipis dan lebih sedikit penanganan kesalahan yang perlu ditangani. Saya kira itu tergantung pada bagaimana sebagian besar pengguna ingin menggunakan API, yang saya tidak memiliki banyak wawasan.

Saya setuju bahwa yang terbaik adalah mengembalikan tipe String bahasa yang paling umum. String non-UTF8 harus jarang (bahkan mungkin lebih jarang daripada binari).

Saya setuju bahwa yang terbaik adalah mengembalikan tipe String bahasa yang paling umum. String non-UTF8 harus jarang (bahkan mungkin lebih jarang daripada binari).

Saya mencoba mencari cara terbaik untuk menangani arah Rust -> C, beralih dari UTF-8 ke C-string. String UTF-8 diperbolehkan berisi nol byte, tetapi satu-satunya titik kode yang muncul adalah karakter NUL, bukan sebaliknya . Saya pikir masuk akal untuk menyatakan ini sebagai prasyarat dalam dokumentasi penjilidan, bahwa string tidak boleh berisi byte nol. Jika tetap demikian, kode panik pada saat itu.

Kemungkinan lainnya adalah mengembalikan kesalahan dari semua fungsi yang ditetapkan yang mengambil string. Tetapi kemudian pengguna harus berurusan dengan NulError sepanjang waktu dan hampir tidak pernah dikembalikan.

keyNew dapat mengembalikan pointer NULL pada kesalahan alokasi. Di Rust saya bisa mengembalikan kesalahan eksplisit atau panik, tetapi bukan nol implisit. Dokumen rust tentang kesalahan pensinyalan menganggap kehabisan memori sebagai kesalahan bencana dan stdlib abort s dalam kasus ini. Pengikatan Java tampaknya tidak menangani kasus ini, jadi saya berasumsi itu akan keluar dari proses juga, karena NullPointerException dilemparkan.
Apakah Anda setuju bahwa memanggil panik di sini adalah yang terbaik (batalkan tidak memungkinkan destruktor berjalan)?

Saya pikir masuk akal untuk menyatakan ini sebagai prasyarat dalam dokumentasi penjilidan, bahwa string tidak boleh berisi byte nol. Jika tetap demikian, kode panik pada saat itu.

Ya, wajar.

Apakah Anda setuju bahwa memanggil panik di sini adalah yang terbaik (batalkan tidak memungkinkan destruktor berjalan)?

Ya, masuk akal untuk panik jika malloc gagal. (Dalam kasus Rust sebagai stdlib akan melakukan hal yang sama. Dalam C, stdlib tidak dibatalkan, jadi C-Elektra juga tidak dibatalkan).

Sekarang setelah binding Rust digabungkan menjadi master, saya ingin memublikasikannya ke crates.io.
Saya sarankan menerbitkannya dengan versi yang disetel ke (default) 0.1.0 , alih-alih diikat ke elektra, hanya karena kematangan binding dan elektra itu sendiri berbeda. Apakah Anda setuju @markus2330?

Penerbitan di https://crates.io membutuhkan akun GitHub. Kepemilikan peti dapat ditransfer antar akun, jadi saya bisa menggunakan milik saya untuk saat ini. Atau orang lain dapat masuk dan mengirimi saya token API yang diperlukan untuk menerbitkan.

Terima kasih telah memublikasikannya ke crates.io :sparkle:

Saya akan mengikat versi langsung ke Elektra, karena mereka adalah bagian dari repo Elektra. Tapi itu tidak terlalu penting: jika crates.io biasanya memiliki beberapa skema versi tertentu, lebih baik tetap berpegang pada apa yang umum di sana.

Atau orang lain dapat masuk dan mengirimi saya token API yang diperlukan untuk menerbitkan.

Saya login dengan resmi. Saya akan mengirimkan token API kepada Anda.

Saya akan mengikat versi langsung ke Elektra, karena mereka adalah bagian dari repo Elektra. Tapi itu tidak terlalu penting: jika crates.io biasanya memiliki beberapa skema versi tertentu, lebih baik tetap berpegang pada apa yang umum di sana.

Masalah utama dengan ini adalah, menurut versi semantik, jika kita harus melakukan perubahan putus pada binding kita tidak bisa hanya mengupgrade versi yang sesuai. Jadi kita hanya bisa melakukan perubahan break ketika elektra melakukannya.

Menurut versi semantik, Anda dapat melakukan perubahan apa pun selama versi dimulai dengan 0 . Jika kami merilis Elektra 1.0 , kami juga berkepentingan untuk menjaga agar binding tetap stabil. Dan bahkan jika kami gagal melakukannya, kami juga memiliki opsi di masa mendatang untuk membuat versi menjadi independen (cukup tingkatkan versi utama pengikatan Rust). Jadi saya pikir aman untuk menggunakan versi Elektra sekarang.

Anda benar, saya tidak berpikir untuk meningkatkan versi utama nanti.

Saat ini, wrapper.h menetapkan #include "kdb.h" untuk menyertakan header kdb dan menghasilkan binding untuknya. Tetapi dentang tidak menemukan tajuk (dalam ubuntu:18.10 , misalnya). Jadi saya harus secara eksplisit memberi tahu dentang untuk memasukkan /usr/include/elektra untuk membuatnya dibangun.
Apakah elektra selalu dipasang di /usr/include/elektra sehingga solusi ini dapat bekerja untuk sebagian besar distribusi?

Apakah elektra selalu dipasang di /usr/include/elektra sehingga solusi ini dapat berfungsi untuk sebagian besar distribusi?

Ya, karena ada perpustakaan lain (saya pikir dari Kerberos) yang menggunakan /usr/include/kdb.h .

Untuk saat ini /usr/include/elektra harus menjadi bagian dari jalur penyertaan, tetapi AFAIK kami ingin mengubahnya sehingga #include <elektra/kdb.h> dapat digunakan sebagai gantinya.

Apakah elektra selalu dipasang di /usr/include/elektra sehingga solusi ini dapat berfungsi untuk sebagian besar distribusi?

Secara default adalah /usr/local/include/elektra tetapi sebagian besar distribusi akan menggunakan /usr/include/elektra tetapi tidak ada jaminan. Itu sebabnya sistem build biasanya memiliki beberapa dukungan untuk menemukan file header. Elektra mendukung cmake dan pkg-config.

Bisakah Anda memberikan beberapa konteks tentang di mana Anda membutuhkan ini?

dapat digunakan sebagai gantinya.

harus digunakan sebagai gantinya. PR yang relevan adalah #2880

Mengubah ke #include <elektra/kdb.h> pasti berfungsi di Ubuntu. Jadi saya akan mengubah ke jalur itu alih-alih memasukkan /usr/include/elektra .

Mengubah ke #include <elektra/kdb.h> pasti berfungsi di Ubuntu. Jadi saya akan mengubah ke jalur itu alih-alih memasukkan /usr/include/elektra .

Mungkin tidak akan berfungsi untuk semua header, beberapa bergantung pada /usr/include/elektra berada di jalur sertakan.

Mungkin hal terbaik untuk dilakukan (jika memungkinkan bagi Anda) adalah menggunakan pkg-config atau cmake --find-package untuk menemukan file Elektra (IMO cmake bekerja lebih baik).

Bisakah Anda memberikan beberapa konteks tentang di mana Anda membutuhkan ini?

Jadi jika pengguna mengkompilasi elektra pada mesinnya, maka ia hanya membutuhkan karat/kargo dan dapat menggunakan binding. Tetapi kasus penggunaan lainnya, yang harus digunakan crates.io, adalah jika seseorang menginstal elektra (dan header) melalui manajer paket mereka. Kemudian perpustakaan dan header tersedia. Sekarang pengguna menyertakan elektra dalam dependensinya dan kargo akan mengambil peti elektra-sys . Itu hanya bergantung pada skrip build dan dentang untuk menghasilkan binding. Tetapi dentang perlu menemukan kdb.h entah bagaimana. Jadi saya dapat meneruskan jalur penyertaan hardcoded tambahan dalam skrip build atau memodifikasi pernyataan #include ... secara langsung.

Mungkin hal terbaik untuk dilakukan (jika memungkinkan bagi Anda) adalah menggunakan pkg-config atau cmake --find-package untuk menemukan file Elektra (IMO cmake bekerja lebih baik).

Saya dapat mencoba menambahkan pkg-config atau cmake sebagai dependensi build dan menemukan kdb.h dengan cara ini. Aku akan melihat ke dalam ini. Saya setuju ini adalah cara yang paling dapat diandalkan.

Ya, Anda dapat mencoba memanggil pkg-config di skrip build Anda. Jika pkg-config tidak tersedia, Anda dapat mencoba jalur hard-code seperti /usr/include/elektra dan /usr/local/include/elektra. (Jika crates.io tidak memerlukan pkg-config tersedia.)

Anda bisa mencoba peti ini

Ya, Anda dapat mencoba memanggil pkg-config di skrip build Anda. Jika pkg-config tidak tersedia, Anda dapat mencoba jalur hard-code seperti /usr/include/elektra dan /usr/local/include/elektra. (Jika crates.io tidak memerlukan pkg-config tersedia.)

Saya menambahkan pkg-config sebagai dependensi opsional. Jika ditambahkan maka akan mencari elektra dan menggunakan includeir yang disediakan. Jika tidak, ia akan mencari di dua direktori yang Anda beri nama.

Binding sekarang diterbitkan: elektra dan elektra-sys :smiley:

Karena ketergantungan sistem yang hilang dari libelektra di lingkungan build docs.rs, dokumentasi tidak dibuat. Selain itu, mereka akan mengubah lingkungan build pada 30 September.
Saya mengajukan permintaan untuk menambahkan libelektra sebagai dependensi sehingga akan dibangun dengan benar pada tanggal 30 September. Dia juga menambahkan paket ke lingkungan yang ada, sehingga dokumen sekarang tersedia :+1:

Saya pikir setelah #2980 digabungkan, masalah ini dapat ditutup.

Sangat bagus, mereka bereaksi sangat cepat. Apakah akan menjadi masalah jika mereka membangunnya dengan libelektra yang cukup lama? (Saya tidak memeriksa versi mana tetapi jika mereka memasukkannya dari manajer paket, itu pasti lebih tua dari 0.9.)

Tidak ada masalah untuk peti elektra , karena ini hanya dokumentasi. elektra-sys Saya pikir berisi versi elektra apa pun yang dihasilkan daripada yang sekarang. Tapi saya pikir hampir tidak ada orang yang akan menggunakan binding mentah alih-alih pembungkusnya. Jadi pertukaran kecil karena memiliki dokumen yang dibuat secara otomatis.

Bisakah Anda menambahkan tautan ke dokumen di dalam repo kami?

Sepertinya elektra-sys itu hampir tidak dapat digunakan. Ini menunjukkan ratusan simbol yang tidak ada hubungannya dengan Elektra. Selanjutnya tidak ada dokumen untuk fungsi individu, misalnya

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

Bisakah Anda menambahkan tautan ke dokumen di dalam repo kami?

Ya, saya akan menambahkannya ke PR yang ada

Sepertinya elektra-sys itu hampir tidak dapat digunakan. Ini menunjukkan ratusan simbol yang tidak ada hubungannya dengan Elektra.

Saya akan melihat ke dalam ini.

Selanjutnya tidak ada dokumen untuk fungsi individu, misalnya

Biasanya peti -sys tidak memiliki docu (misalnya openssl-sys ), karena mereka adalah terjemahan satu-ke-satu dari C yang setara. Jadi kita harus mencari dokumen C secara langsung. Saya juga harus menyalin semua dokumen, yang menambah beban pemeliharaan lain. Saya dapat menautkan ke https://doc.libelektra.org/api/current/html/index.html di halaman dokumen utama.

Sepertinya elektra-sys itu hampir tidak dapat digunakan. Ini menunjukkan ratusan simbol yang tidak ada hubungannya dengan Elektra.

Saya akan melihat ke dalam ini.

Itu diperbaiki di #2980, dan akan diperbaiki di docs.rs saat berikutnya kami menerbitkan peti.

Saya dapat menautkan ke https://doc.libelektra.org/api/current/html/index.html di halaman dokumen utama.

Ya, ide yang bagus!