Libelektra: Reliures de rouille

Je ne connais pas grand-chose à Rust, mais je suppose que les liaisons générées par rust-bindgen ne peuvent être utilisées que dans unsafe Rust ? Si tel est le cas, ce serait bien d'avoir un wrapper autour de ceux avec une API Rust plus idiomatique.

AFAIK, la plupart des liaisons Rust ont une caisse *-sys pour le mappage 1:1 de l'API C et une autre caisse avec l'API que la plupart des utilisateurs utiliseraient réellement dans Rust. S'il existe un moyen de dire à Rust d'invoquer automatiquement keyDel , ksDel et ses amis si nécessaire, ce serait vraiment bien.

Si tel est le cas, ce serait bien d'avoir un wrapper autour de ceux avec une API Rust plus idiomatique.

Oui, c'est le plan. Et ce faisant, comparez également avec l'API C et trouvez peut-être des améliorations dans l'API C (au moins dans le docu).

@PhilippGackstatter Comme discuté : découvrez également comment télécharger sur https://crates.io/ et comment intégrer la liaison dans notre système CMake.

@PhilippGackstatter des progrès ? Nous avons quelqu'un qui pourrait également être intéressé par l'extension des fixations Rust.

@markus2330 J'ai commencé il y a quelques jours, mais je lisais principalement sur bindgen, cmake et comment l'intégrer dans le projet, donc il n'y avait rien à montrer. Mais j'ai les deux premières choses prêtes maintenant (voir # 2826). Je travaille pleinement sur le projet maintenant.

Pour répondre aux questions de #2826 (veuillez préférer poser des questions dans les problèmes car les PR ont tendance à être confus pour les discussions qui ne sont pas directement liées au code) :

L'un est, pour quels en-têtes dans src/include je dois générer des liaisons. Au moins kdb.h, mais y en a-t-il d'autres dont j'ai besoin pour l'API de bas niveau, sans prise en charge des plugins ?

Non, l'API de bas niveau est uniquement dans kdb.h

L'autre est, dois-je changer tous les scripts docker pour installer rustup (qui est utilisé pour installer cargo et rustc) ?

Oui, vous devez modifier les scripts docker et peut-être aussi le fichier Jenkins. Mais vous n'avez pas besoin de tous les changer, si vous construisez pour des distributions récentes, c'est suffisant.

Ce serait bien si vous pouviez également le faire compiler avec le rouille natif compilé fourni dans Debian Buster. Le fichier docker Debian Buster n'est pas encore fusionné #2819

Je suppose qu'il n'y a pas de moyen automatisé de le faire.

Il y a quelques idées pour le faire : #730

Rust-bindgen propose deux façons de générer des liaisons. L'un se fait via la ligne de commande, qui est donc un processus manuel et doit être répété si quelque chose change dans l'API C. L'autre se fait via un script de construction, qui est exécuté à chaque fois que la construction de cargaison s'exécute. Cela signifie que les liaisons sont régénérées à chaque build. C'est ce qui est actuellement mis en œuvre. Cependant, il faut que tous ceux qui utilisent les fixations aient les en-têtes nécessaires dont elekra a besoin. J'imagine que si quelqu'un installe simplement elektra mais ne l'a pas compilé, il peut ne pas répondre à toutes les exigences nécessaires. Peut-être est-il plus judicieux de régénérer les en-têtes de temps en temps, manuellement, puisque la C-API ne change plus beaucoup ?

La régénération sur chaque build semble être la bonne solution, les autres liaisons fonctionnent également de cette façon (elles nécessitent l'installation de swig). Vous pouvez simplement installer les fichiers d'en-tête générés pour éviter les problèmes que vous décrivez.

Oui, c'est le plan. Et ce faisant, comparez également avec l'API C et trouvez peut-être des améliorations dans l'API C (au moins dans le docu).

Jusqu'à présent, j'ai trouvé quelques opportunités mineures d'amélioration

• keyGetBinary : En tant que code d'appel, je ne peux pas savoir si une valeur de retour de -1 signifie maxSize is 0 ou type mismatch , ou autre chose. Étant donné que Rust utilise une gestion explicite des erreurs dans ses arguments de retour, j'aimerais pouvoir faire correspondre la non-concordance de type à une erreur et les erreurs "liées à la taille maximale" à une autre. Mais actuellement, je dois utiliser une erreur plus générique. Je pourrais vérifier moi-même une incompatibilité de type, mais keyGetBinary fait, donc j'ai la même vérification deux fois.
  keySetName fait quelque chose de similaire, faisant correspondre deux erreurs différentes à -1. Dans les deux cas, il y a des erreurs qui sont des bogues (nom invalide) et des erreurs qui peuvent se produire dans les programmes sonores (clé déjà dans le jeu de clés), donc je peux en quelque sorte comprendre la décision. Mais pourquoi ne pas utiliser -2 pour être explicite et éviter la double vérification ?
• Grammaticalement, keyIsDirectBelow ne devrait-il pas être keyIsDirectlyBelow 🙂 ? Si oui, dois-je corriger cela dans l'API Rust ?

Autre question : keyRel n'est pas implémenté dans les liaisons CPP. Dois-je également l'omettre dans Rust ?

Excellent travail, d'après vos questions, il est évident que vous avez déjà regardé profondément dans l'API.

Je pourrais vérifier moi-même une incompatibilité de type, mais keyGetBinary le fait, j'ai donc la même vérification deux fois.

Peut-être pouvez-vous même utiliser le typesystem pour éviter les mauvais appels ? (keyGetBinary n'est autorisé que sur les clés binaires)

Mais pourquoi ne pas utiliser -2 pour être explicite et éviter la double vérification ?

La raison en était la compatibilité : les API ne renvoyaient initialement que -1 et il n'est pas possible d'ajouter d'autres codes d'erreur sans casser les programmes existants (qui pourraient avoir ==-1 pour vérifier les erreurs). Mais avec la prochaine version (0.9), nous pouvons à nouveau casser l'API. Et nous pourrions éviter le problème de compatibilité en déclarant que toute valeur inférieure à 0 indique des erreurs. Je suis tout à fait d'accord pour dire que les liaisons devraient générer des erreurs précises.

Voulez-vous résoudre ces problèmes d'API ?

Si oui, dois-je corriger cela dans l'API Rust ?

L'orthographe des API ne doit pas différer. Si nous le réparons, nous devrions le réparer dans l'API C et toutes les liaisons (en fait, seuls Java et Go doivent être adaptés à la main, les autres seront régénérés correctement de toute façon).

keyRel n'est pas implémenté dans les liaisons CPP. Dois-je également l'omettre dans Rust ?

Oui, comme vous l'avez peut-être déjà remarqué, keyIs(Direct)Below et keyRel ont des fonctionnalités qui se chevauchent. L'idée de keyRel était de garder l'API petite (et donc la bibliothèque petite). Mais keyRel tel quel n'est pas utilisable et aussi lent. Nous allons donc très probablement le supprimer dans 0.9. Voir doc/todo/FUTURE pour les autres candidats à supprimer.

Peut-être pouvez-vous même utiliser le typesystem pour éviter les mauvais appels ? (keyGetBinary n'est autorisé que sur les clés binaires)

C'est une bonne idée. Je pourrais avoir BinaryKey et StringKey et seul le premier aurait une méthode get_binary() et seul le second aurait une méthode get_string() , et ainsi de suite. Je vais me renseigner.

Voulez-vous résoudre ces problèmes d'API ?

Je peux le faire. Cela dépend de ce que la priorité devrait être pour moi. Après avoir terminé l'API sécurisée pour Rust, vous avez dit que ce serait bien d'avoir également l'API du plugin dans Rust. Vous pouvez décider ce qui est le plus important.

C'est une bonne idée. Je pourrais avoir BinaryKey et StringKey et seul le premier aurait une méthode get_binary() et seul le second aurait une méthode get_string(), et ainsi de suite. Je vais me renseigner.

Merci. Cela peut nécessiter trop de moulages, alors voyons si c'est une bonne idée. Un autre type peut également être utile pour les clés dans les ensembles de clés (où setName n'est pas autorisé).

Je peux le faire. Cela dépend de ce que la priorité devrait être pour moi. Après avoir terminé l'API sécurisée pour Rust, vous avez dit que ce serait bien d'avoir également l'API du plugin dans Rust. Vous pouvez décider ce qui est le plus important.

Oui, terminez d'abord l'API Rust à partir de kdb.h, puis nous verrons combien d'heures il nous reste à passer.

OMI, la liaison Rust (et toute liaison d'ailleurs) devrait avoir deux versions. Un qui reflète l'API C aussi près que possible et un autre qui est plus idiomatique pour le langage qui s'appuie sur la première version. Dans la version idiomatique, utiliser le système de types avec BinaryKey et StringKey (ou même des génériques) est probablement une bonne idée, si cela facilite l'utilisation de l'API de Rust.

@kodebach je suis d'accord. Et cela semble également être fait avec les caisses elektra et elektra-sys.

@kodebach je suis d'accord. Et cela semble également être fait avec les caisses elektra et elektra-sys.

Oui je pense aussi. Si l'API Rust sûre a des limitations qui doivent être contournées, vous pouvez importer elektra_sys et appeler directement la fonction de liaison C un-à-un.

Merci. Cela peut nécessiter trop de moulages, alors voyons si c'est une bonne idée. Un autre type peut également être utile pour les clés dans les ensembles de clés (où setName n'est pas autorisé).

Cela a très bien fonctionné pour la mise en œuvre de la clé. Cependant, pour les KeySets, j'ai rencontré un obstacle. Pour toutes les méthodes qui renvoient une clé, elle doit se conformer à l'interface commune que j'ai créée. J'ai implémenté une méthode get_value qui a un paramètre de retour générique. Pour BinaryKeys, ce sont des octets, pour StringKeys, ce sont des chaînes. Mais qu'est-ce que la version rouillée de ksNext renvoie maintenant ? Un objet qui satisfait à "l'interface clé", mais avec quelle valeur ? Je dois en choisir un.
Voici à quoi doit ressembler la signature, où Valeur est le type que renvoie get_value . Je ne peux spécifier que des octets ( Vec<u8> ) ou une chaîne.
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

Je pourrais donc l'unifier en octets, mais l'utilisateur doit ensuite convertir lui-même en chaîne. Étant donné que la seule différence entre StringKey et BinaryKeys réside dans leur implémentation de set_value et get_value , ce changement supprimerait ce caractère explicite et je n'ai à nouveau que des clés.

Je suppose que le vrai problème est que KeySet dans l'implémentation actuelle n'est pas explicite sur le type de clés qu'il contient, mais les *keys le sont. Mais permettre à une instance de KeySet de ne contenir que StringKey ou BinaryKey est une restriction trop importante, je suppose.
Je pense que Key et KeySet doivent être explicites sur ce qu'ils contiennent ou aucun d'entre eux. Je me penche maintenant vers Key et KeySet génériques, juste pour être cohérent avec le reste d'elektra.
Des pensées?

Du point de vue de la convivialité, il serait logique de renvoyer la clé qui a un getter pour une chaîne, car il s'agit de la variante la plus souvent utilisée. Le setter pour le nom doit être désactivé (si cela est facilement possible), car nous savons déjà que cette clé (renvoyée par next) fait partie d'un KeySet.

En général, le système de typage doit aider l'utilisateur et ne pas le gêner. Alors restez aussi simple que possible. Les erreurs les plus courantes sont :

1. essayer de changer le nom des clés pour une clé qui se trouve dans un jeu de clés.
2. essayer de changer les clés de métadonnées (ou d'autres clés const).
3. duplication confuse de Key/KeySet et de leurs références.
4. itérer sur les KeySets qui sont également utilisés pour découper les clés de manière à ce que l'itération ne fonctionne plus correctement.
5. oublier de libérer un Key/KeySet

Donc, si le système de types peut aider là-bas, ce serait formidable. 5. ne sera, espérons-le, pas possible par conception, pour 1. et 2. votre abstraction devrait vous aider.

La confusion binaire/chaîne est en fait une erreur assez rare (car les clés binaires sont très atypiques : elles sont surtout utilisées pour contenir des pointeurs de fonction).

D'ailleurs. si vous souhaitez rédiger une décision de conception sur les utilisations sûres des API, veuillez continuer (doc/décision)

Du point de vue de la convivialité, il serait logique de renvoyer la clé qui a un getter pour une chaîne, car il s'agit de la variante la plus souvent utilisée.

Mais toutes les séquences d'octets ne sont pas valides en UTF-8, donc ce ne serait plus vraiment typé, n'est-ce pas ?

AFAIK, le système de macros de Rust est très puissant, il existe peut-être un moyen d'écrire une fonction qui renvoie toujours le type correct. Par exemple, dans Kotlin, il existe une technique pour que les cartes encodent le type de valeur dans la clé. La référence de l'API ici est un exemple.

Alternativement, un StringKeySet qui n'accepte que les StringKey s pourrait avoir du sens, car les clés binaires sont si rares et ne sont généralement pas utilisées dans les configurations.

Du point de vue de la convivialité, il serait logique de renvoyer la clé qui a un getter pour une chaîne, car il s'agit de la variante la plus souvent utilisée. Le setter pour le nom doit être désactivé (si cela est facilement possible), car nous savons déjà que cette clé (renvoyée par next) fait partie d'un KeySet.

Mais il est toujours possible, bien que rare, d'avoir un KeySet avec des clés mixtes. Ensuite, toujours renvoyer une StringKey et appeler get_string serait une erreur, mais le système de types non seulement le permet mais vous guide vers elle, car il n'y a pas get_binary méthode

Avant de faire cela, je suggère de rendre KeySet générique et de l'instancier en tant que KeySet<StringKey> si l'utilisateur est sûr qu'il n'y a que des StringKeys à l'intérieur (pour les KeySets ne provenant pas de Rust). Ensuite, il est tout à fait naturel que l'itération dessus ne produise que des StringKeys.
Cela imposerait également que les KeySets soient homogènes via le système de types, du moins ceux créés par les utilisateurs de Rust, ce qui serait globalement plus sûr.
Dans les rares cas où une clé binaire est attendue, l'utilisateur devrait vérifier avec is_binary et is_string , puis convertir, ce qui serait un appel de méthode sûr.

duplication confuse de Key/KeySet et de leurs références.

Je pense que la seule chose que je puisse faire est de promouvoir l'utilisation du double plutôt que le nombre de références. Cela peut être pire pour les performances, mais keyDel est invoqué automatiquement par Rust, tandis que le comptage des références est entièrement manuel. Ainsi, la duplication est certainement plus facile à réaliser que le comptage des références.

itérer sur les KeySets qui sont également utilisés pour découper les clés de manière à ce que l'itération ne fonctionne plus correctement.

Voulez-vous dire modifier le jeu de clés tout en itérant dessus ?

D'ailleurs. si vous souhaitez rédiger une décision de conception sur les utilisations sûres des API, veuillez continuer (doc/décision)

Quel en serait le contenu ?

AFAIK, le système de macros de Rust est très puissant, il existe peut-être un moyen d'écrire une fonction qui renvoie toujours le type correct.

Je pense que la conception "actuelle" de KeySet qui peut contenir n'importe quoi et des types de clés concrets ne fonctionne pas ensemble, du moins pas bien. Mais je vais regarder dans les macros.

Mais toutes les séquences d'octets ne sont pas valides en UTF-8, donc ce ne serait plus vraiment typé, n'est-ce pas ?

Ni les chaînes ni la valeur binaire d'Elektra ne doivent être UTF-8. Elektra décide uniquement entre chaîne et binaire (peut contenir 0 octet).

AFAIK, le système de macros de Rust est très puissant, il existe peut-être un moyen d'écrire une fonction qui renvoie toujours le type correct. Par exemple, dans Kotlin, il existe une technique pour que les cartes encodent le type de valeur dans la clé. La référence de l'API ici est un exemple.

Il faut aussi veiller à mettre l'effort sur les fonctionnalités qui sont utiles. Les clés binaires sont rares.

Alternativement, un StringKeySet qui accepte uniquement les StringKeys peut avoir du sens, car les clés binaires sont si rares et ne sont généralement pas utilisées dans les configurations.

Oui, mais je verrais StringKeySet comme le KeySet normal.

Mais il est toujours possible, bien que rare, d'avoir un KeySet avec des clés mixtes. Ensuite, toujours renvoyer une StringKey et appeler get_string serait une erreur, mais le système de types non seulement l'autorise mais vous guide vers elle, car il n'y a pas de méthode get_binary sur ce type.

Oui, mais comme dit c'est un problème mineur. Les personnes qui stockent des données binaires (comme des adresses de fonction) découvriront comment lancer la clé (s'il existe un document à ce sujet).

Avant de faire cela, je suggère de rendre KeySet générique et de l'instancier en tant que KeySetsi l'utilisateur est sûr qu'il n'y a que des StringKeys à l'intérieur (pour les KeySets ne provenant pas de Rust). Ensuite, il est tout à fait naturel que l'itération dessus ne produise que des StringKeys.

Ce ne serait qu'une fausse sécurité car les KeySets proviennent de KDB (en externe) et ils pourraient contenir des données binaires dans tous les cas. Ainsi, je préfère avoir KeySet non générique.

Si vous voulez jouer avec les génériques, fournissez des getters et des setters qui convertissent les KeySets en structures de données (génériques). Par exemple, un tableau Elektra d'entiers à Vec<i32> .

Voulez-vous dire modifier le jeu de clés tout en itérant dessus ?

Oui cut modifie le KeySet. En général, les itérateurs peuvent le faire en toute sécurité, mais de nombreuses personnes ont des problèmes pour bien faire les choses.

Quel en serait le contenu ?

Un résumé de ce dont nous discutons ici et de la façon dont vous l'avez conçu.

Je pense que la conception "actuelle" de KeySet qui peut contenir n'importe quoi et des types de clés concrets ne fonctionne pas ensemble, du moins pas bien.

Je suis d'accord.

Mais je vais regarder dans les macros.

Merci de ne pas lui accorder la priorité.

Ni les chaînes ni la valeur binaire d'Elektra ne doivent être UTF-8.

Ensuite, nous devrions utiliser OsString ou CString au lieu de String selon une recherche rapide.

Ni les chaînes ni la valeur binaire d'Elektra ne doivent être UTF-8.

Ensuite, nous devrions utiliser OsString ou CString au lieu de String selon une recherche rapide.

En ce moment, je convertis le String Rust (qui est UTF-8) en CString avant de le transmettre à elektra. La raison en est que String est la chaîne par défaut et que la plupart des autres bibliothèques s'attendent à fonctionner avec cela.
Je peux à la place demander à l'API de haut niveau de demander et de retourner des CString , de sorte que l'utilisateur devra gérer le code de conversion, s'il a besoin d'un String . Cela permettrait une API plus fine et moins de gestion des erreurs à traiter. Je suppose que cela dépend de la façon dont la plupart des utilisateurs voudront utiliser l'API, ce que je n'ai pas tellement de perspicacité.

Je suis d'accord qu'il est préférable de renvoyer le type String le plus courant des langues. Les chaînes non UTF8 devraient être rares (peut-être même plus rares que les binaires).

Je suis d'accord qu'il est préférable de renvoyer le type String le plus courant des langues. Les chaînes non UTF8 devraient être rares (peut-être même plus rares que les binaires).

J'essaie de trouver la meilleure façon de gérer la direction Rust -> C, en passant de UTF-8 à une chaîne C. Les chaînes UTF-8 sont autorisées à contenir zéro octet, mais le seul point de code où cela apparaît est le caractère NUL, pas autrement . Je pense qu'il serait raisonnable d'indiquer cela comme condition préalable dans la documentation de liaison, que les chaînes ne sont pas autorisées à contenir l'octet zéro. Si c'est le cas de toute façon, le code panique à ce stade.

L'autre possibilité est de renvoyer une erreur de toutes les fonctions définies qui prennent une chaîne. Mais alors les utilisateurs doivent faire face à ce NulError tout le temps et il n'est pratiquement jamais retourné.

keyNew peut renvoyer un pointeur NULL en cas d'erreur d'allocation. Dans Rust, je peux soit renvoyer des erreurs explicites, soit une panique, mais pas un null implicite. Le document rust sur les erreurs de signalisation considère le manque de mémoire comme une erreur catastrophique et la stdlib abort s dans ce cas. La liaison Java semble ne pas gérer ce cas, donc je suppose qu'elle quitterait également le processus, car un NullPointerException est lancé.
Êtes-vous d'accord pour dire qu'il est préférable d'appeler la panique ici (l'abandon ne permet pas aux destructeurs de s'exécuter) ?

Je pense qu'il serait raisonnable d'indiquer cela comme condition préalable dans la documentation de liaison, que les chaînes ne sont pas autorisées à contenir l'octet zéro. Si c'est le cas de toute façon, le code panique à ce stade.

Oui, c'est raisonnable.

Êtes-vous d'accord pour dire qu'il est préférable d'appeler la panique ici (l'abandon ne permet pas aux destructeurs de s'exécuter) ?

Oui, il est logique de paniquer si un malloc échoue. (Dans le cas de Rust, la stdlib ferait la même chose. En C, la stdlib n'abandonne pas, donc C-Elektra n'abandonne pas non plus).

Maintenant que les liaisons Rust sont fusionnées dans master, j'aimerais les publier sur crates.io.
Je suggère de les publier avec la version définie sur (par défaut) 0.1.0 , au lieu d'être liée à elektra, simplement parce que la maturité des liaisons et elektra lui-même diffèrent. Êtes-vous d'accord @markus2330 ?

La publication sur https://crates.io nécessite un compte GitHub. La propriété des caisses peut être transférée entre les comptes, je peux donc utiliser la mienne pour le moment. Ou quelqu'un d'autre pourrait se connecter et m'envoyer le jeton API requis pour la publication.

Merci de les avoir publiés sur crates.io :sparkle:

Je lierais la version directement à Elektra, car elles font partie des dépôts d'Elektra. Mais ce n'est pas vraiment important : si crates.io a généralement des schémas de version spécifiques, mieux vaut s'en tenir à ce qui y est commun.

Ou quelqu'un d'autre pourrait se connecter et m'envoyer le jeton API requis pour la publication.

Je me suis connecté en autorisé. Je vous enverrai le jeton API.

Je lierais la version directement à Elektra, car elles font partie des dépôts d'Elektra. Mais ce n'est pas vraiment important : si crates.io a généralement des schémas de version spécifiques, mieux vaut s'en tenir à ce qui y est commun.

Le problème majeur avec ceci est, selon le contrôle de version sémantique, si nous devons faire un changement de rupture dans les liaisons, nous ne pouvons pas simplement mettre à niveau la version en conséquence. Nous ne pouvions donc faire des changements de rupture que lorsqu'elektra les fait.

Selon le contrôle de version sémantique, vous pouvez effectuer n'importe quel changement radical tant que la version commence par 0 . Si nous sortons Elektra 1.0 il est de notre intérêt de garder également les fixations stables. Et même si nous ne parvenons pas à le faire, nous aurons également à l'avenir la possibilité de rendre les versions indépendantes (augmenter simplement la version majeure de la liaison Rust). Je pense donc qu'il est sûr d'utiliser simplement la version d'Elektra maintenant.

Vous avez raison, je n'ai pas pensé à augmenter les versions majeures plus tard.

À l'heure actuelle, le wrapper.h spécifie #include "kdb.h" pour inclure l'en-tête kdb et générer des liaisons pour celui-ci. Mais clang ne trouve pas l'en-tête (dans ubuntu:18.10 , par exemple). Je dois donc explicitement dire à clang d'inclure /usr/include/elektra pour qu'il soit construit.
Elektra est-il toujours installé dans /usr/include/elektra afin que cette solution fonctionne pour la plupart des distributions ?

Elektra est-il toujours installé dans /usr/include/elektra afin que cette solution fonctionne pour la plupart des distributions ?

Oui, car il existe une autre bibliothèque (je pense de Kerberos) qui utilise /usr/include/kdb.h .

Pour l'instant, /usr/include/elektra doit faire partie du chemin d'inclusion, mais AFAIK, nous voulons changer cela afin que #include <elektra/kdb.h> puisse être utilisé à la place.

Elektra est-il toujours installé dans /usr/include/elektra afin que cette solution fonctionne pour la plupart des distributions ?

Par défaut, c'est /usr/local/include/elektra mais la plupart des distributions utiliseront /usr/include/elektra mais il n'y a aucune garantie. C'est pourquoi les systèmes de construction ont généralement un certain support pour localiser les fichiers d'en-tête. Elektra prend en charge cmake et pkg-config.

Pouvez-vous donner un peu de contexte sur l'endroit où vous en avez besoin ?

peut être utilisé à la place.

doit être utilisé à la place. Le PR pertinent est #2880

Le passage à #include <elektra/kdb.h> fonctionne définitivement sous Ubuntu. Alors je vais changer pour ce chemin au lieu d'inclure /usr/include/elektra .

Le passage à #include <elektra/kdb.h> fonctionne définitivement sous Ubuntu. Alors je vais changer pour ce chemin au lieu d'inclure /usr/include/elektra .

Cela ne fonctionnera probablement pas pour tous les en-têtes, certains dépendent du fait que /usr/include/elektra se trouve dans le chemin d'inclusion.

La meilleure chose à faire (si possible pour vous) serait probablement d'utiliser pkg-config ou cmake --find-package pour trouver les fichiers Elektra (IMO cmake fonctionne mieux).

Pouvez-vous donner un peu de contexte sur l'endroit où vous en avez besoin ?

Donc, si un utilisateur compile elektra sur sa machine, alors il n'a besoin que de rouille/charge et peut utiliser les fixations. Mais l'autre cas d'utilisation, pour lequel crates.io devrait être utilisé, est celui où quelqu'un installe elektra (et les en-têtes) via son gestionnaire de packages. Ensuite, la bibliothèque et les en-têtes sont disponibles. Maintenant, cet utilisateur inclut elektra dans ses dépendances et la cargaison ira chercher la caisse elektra-sys . Il s'appuie uniquement sur le script de construction et clang pour générer les liaisons. Mais clang a besoin de trouver kdb.h manière ou d' #include ... .

La meilleure chose à faire (si possible pour vous) serait probablement d'utiliser pkg-config ou cmake --find-package pour trouver les fichiers Elektra (IMO cmake fonctionne mieux).

Je peux essayer d'ajouter pkg-config ou cmake en tant que dépendance de construction et trouver kdb.h cette façon. Je vais me renseigner. Je suis d'accord que c'est le moyen le plus fiable.

Oui, vous pouvez essayer d'appeler pkg-config dans votre script de construction. Si pkg-config n'est pas disponible, vous pouvez essayer des chemins codés en dur comme /usr/include/elektra et /usr/local/include/elektra. (Si crates.io ne nécessite pas que pkg-config soit disponible.)

Vous pouvez essayer cette caisse

Oui, vous pouvez essayer d'appeler pkg-config dans votre script de construction. Si pkg-config n'est pas disponible, vous pouvez essayer des chemins codés en dur comme /usr/include/elektra et /usr/local/include/elektra. (Si crates.io ne nécessite pas que pkg-config soit disponible.)

J'ai ajouté pkg-config comme dépendance facultative. S'il est ajouté, il recherchera elektra et utilisera l'includeir fourni. Sinon, il recherchera dans les deux répertoires que vous avez nommés.

Les liaisons sont maintenant publiées : elektra et elektra-sys :smiley:

En raison de la dépendance système manquante de libelektra dans l'environnement de construction docs.rs, la documentation n'a pas été construite. De plus, ils modifieront l'environnement de construction le 30 septembre.
J'ai soumis une demande pour ajouter libelektra en tant que dépendance afin qu'il se construise correctement le 30 septembre. Il a également ajouté le package à l'environnement existant, les docs sont donc désormais disponibles :+1 :

Je pense qu'après la fusion de #2980, ce problème peut être fermé.

Très sympa, ils ont réagi super vite. Est-ce que ce sera un problème qu'ils le construisent avec un libelektra assez ancien ? (Je n'ai pas vérifié quelle version mais s'ils l'incluent à partir du gestionnaire de packages, il sera définitivement plus ancien que 0.9.)

Aucun problème pour la caisse elektra , puisqu'il ne s'agit que de documentation. elektra-sys Je pense qu'il contient la version d'elektra contre laquelle il a été généré au lieu de la version actuelle. Mais je pense que presque personne n'utiliserait les reliures brutes au lieu des emballages. Donc, un petit compromis pour avoir des documents automatiquement construits.

Pouvez-vous ensuite ajouter les liens vers le docu dans notre repo ?

Il semble que elektra-sys soit presque inutilisable de toute façon. Il montre des centaines de symboles qui n'ont rien à voir avec Elektra. De plus, il n'y a pas de document sur les fonctions individuelles, par exemple

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

Pouvez-vous ensuite ajouter les liens vers le docu dans notre repo ?

Oui, je vais l'ajouter au PR existant

Il semble que elektra-sys soit presque inutilisable de toute façon. Il montre des centaines de symboles qui n'ont rien à voir avec Elektra.

Je vais me renseigner.

De plus, il n'y a pas de document sur les fonctions individuelles, par exemple

Il est courant que les caisses -sys n'aient pas de docu (par exemple openssl-sys ), car ce sont des traductions un à un de l'équivalent C. Il faut donc rechercher directement la doc C. Je devrais également copier à la main tous les documents, ce qui ajoute un autre fardeau de maintenance. Je peux cependant créer un lien vers

Il semble que elektra-sys soit presque inutilisable de toute façon. Il montre des centaines de symboles qui n'ont rien à voir avec Elektra.

Je vais me renseigner.

C'est corrigé dans #2980, et sera corrigé sur docs.rs la prochaine fois que nous publierons la caisse.

Je peux cependant créer un lien vers

Oui bonne idée!