Libelektra: Rust Bindings

Não sei muito sobre Rust, mas suponho que as ligações geradas por rust-bindgen só podem ser usadas em unsafe Rust? Se for esse o caso, seria bom ter um invólucro em torno daqueles com uma API Rust mais idiomática.

A maioria das ligações do Rust AFAIK tem uma caixa *-sys para o mapeamento 1: 1 da API C e outra caixa com a API que a maioria dos usuários usaria no Rust. Se houver uma maneira de dizer ao Rust para invocar automaticamente keyDel , ksDel e amigos quando necessário, isso seria muito bom.

Se for esse o caso, seria bom ter um invólucro em torno daqueles com uma API Rust mais idiomática.

Sim, este é o plano. E enquanto faz isso, compare também com a API C e talvez encontre melhorias na API C (pelo menos no documento).

@PhilippGackstatter Conforme discutido: Por favor, também descubra como fazer upload para https://crates.io/ e como integrar a vinculação em nosso sistema CMake.

@PhilippGackstatter algum progresso? Temos alguém que também pode estar interessado em estender as ligações Rust.

@ markus2330 Comecei alguns dias atrás, mas estava lendo principalmente sobre bindgen, cmake e como integrá-los ao projeto, então não havia nada para mostrar. Mas eu tenho as primeiras coisas prontas agora (ver # 2826). Estou trabalhando totalmente no projeto agora.

Para responder às perguntas de # 2826 (prefira fazer perguntas em questões, pois os PRs têm a tendência de ficar confusos para discussões não diretamente relacionadas ao código):

Uma é, para quais cabeçalhos em src / include preciso gerar ligações. Pelo menos kdb.h, mas há outros que preciso para a API de baixo nível, sem suporte a plug-ins?

Não, a API de baixo nível está apenas em kdb.h

A outra é: preciso alterar todos os scripts do docker para instalar o rustup (que é usado para instalar o cargo e o rustc)?

Sim, você precisa alterar os scripts do docker e talvez também o Jenkinsfile. Mas você não precisa mudar todos eles, se você construir para distribuições recentes, é o suficiente.

Seria bom se você também pudesse fazê-lo compilar com o rust nativo compilado no Debian Buster. O arquivo docker do Debian Buster ainda não foi mesclado # 2819

Suponho que não haja uma maneira automatizada de fazer isso.

Existem algumas idéias para fazer isso: # 730

Rust-bindgen oferece duas maneiras de gerar ligações. Um é via linha de comando, que, portanto, é um processo manual e precisa ser repetido se houver alguma alteração na API C. A outra é por meio de um script de construção, que é executado sempre que o cargo de construção é executado. Isso significa que as ligações são regeneradas em cada construção. Isso é o que está implementado atualmente. No entanto, exige que todos os que usam as ligações tenham os cabeçalhos necessários de que o elekra precisa. Imagino que se alguém simplesmente instalar o elektra, mas não o compilou, pode não atender a todos os requisitos necessários. Talvez faça mais sentido regenerar os cabeçalhos de vez em quando, manualmente, já que a C-API não muda muito mais?

A regeneração em cada build parece ser a solução adequada, as outras ligações também funcionam dessa forma (elas requerem swig para serem instaladas). Você pode simplesmente instalar os arquivos de cabeçalho gerados para evitar os problemas que você está descrevendo.

Sim, este é o plano. E enquanto faz isso, compare também com a API C e talvez encontre melhorias na API C (pelo menos no documento).

Até agora, encontrei algumas pequenas oportunidades de melhoria

• keyGetBinary : Como código de chamada, não posso saber se um valor de retorno de -1 significa maxSize is 0 ou type mismatch ou outra coisa. Uma vez que o Rust usa tratamento explícito de erros em seus argumentos de retorno, gostaria de poder corresponder a incompatibilidade de tipo a um erro e os erros "relacionados a maxSize" a outro. Mas agora tenho que usar um erro mais genérico. Eu mesmo poderia verificar se há incompatibilidade de tipo, mas keyGetBinary faz isso, então tenho a mesma verificação duas vezes.
  keySetName faz algo semelhante, combinando dois erros diferentes com -1. Em ambos os casos, existem erros que são bugs (nome inválido) e erros que podem ocorrer em programas de som (a chave já está no conjunto de chaves), então posso meio que entender a decisão. Mas por que não usar -2 para explicitar e evitar checagem dupla?
• Gramaticamente, keyIsDirectBelow não deveria ser keyIsDirectlyBelow 🙂? Em caso afirmativo, devo corrigir isso na API Rust?

Outra pergunta: keyRel não está implementado nos Bindings CPP. Devo omitir isso no Rust também?

Bom trabalho, pelas suas dúvidas é óbvio que você já olhou profundamente na API.

Eu mesmo poderia verificar se há uma incompatibilidade de tipo, mas keyGetBinary faz isso, então eu tenho a mesma verificação duas vezes.

Talvez você ainda possa usar o sistema de tipos para evitar chamadas erradas? (keyGetBinary só é permitido em chaves binárias)

Mas por que não usar -2 para explicitar e evitar checagem dupla?

O motivo era a compatibilidade: as APIs inicialmente retornavam apenas -1 e não é possível adicionar outros códigos de erro sem quebrar os programas existentes (que podem ter ==-1 para verificar se há erros). Mas com a próxima versão (0.9) podemos quebrar a API novamente. E poderíamos evitar o problema de compatibilidade declarando que quaisquer valores abaixo de 0 indicam erros. Concordo plenamente que as ligações devem gerar erros precisos.

Você quer consertar esses problemas de API?

Em caso afirmativo, devo corrigir isso na API Rust?

As APIs não devem ser diferentes na ortografia. Se o corrigirmos, devemos corrigi-lo na API C e em todas as ligações (na verdade, apenas Java e Go precisam ser adaptados manualmente, os outros serão regenerados corretamente de qualquer maneira).

keyRel não é implementado nos Bindings CPP. Devo omitir isso no Rust também?

Sim, como talvez você já tenha notado, keyIs (Direct) Below e keyRel têm funcionalidade de sobreposição. A ideia do keyRel era manter a API pequena (e, portanto, a biblioteca pequena). Mas o keyRel no estado em que se encontra não pode ser usado e também é lento. Portanto, provavelmente o removeremos em 0,9. Veja doc / todo / FUTURE para outros candidatos a serem removidos.

Talvez você ainda possa usar o sistema de tipos para evitar chamadas erradas? (keyGetBinary só é permitido em chaves binárias)

Essa é uma ótima ideia. Eu poderia ter BinaryKey e StringKey e apenas o primeiro teria um método get_binary() e apenas o segundo teria um método get_string() , e assim por diante. Vou dar uma olhada nisso.

Você quer consertar esses problemas de API?

Eu posso fazer isso. Depende de qual deve ser a prioridade para mim. Depois de terminar a API segura do Rust, você disse que seria bom ter também a API do plugin no Rust. Você pode decidir o que é mais importante.

Essa é uma ótima ideia. Eu poderia ter BinaryKey e StringKey e apenas o primeiro teria um método get_binary () e apenas o segundo teria um método get_string () e assim por diante. Vou dar uma olhada nisso.

Obrigada. Pode exigir muitos moldes, então vamos ver se é uma boa ideia. Além disso, outro tipo pode ser útil para chaves em conjuntos de chaves (onde setName não é permitido).

Eu posso fazer isso. Depende de qual deve ser a prioridade para mim. Depois de terminar a API segura do Rust, você disse que seria bom ter também a API do plugin no Rust. Você pode decidir o que é mais importante.

Sim, primeiro termine a API Rust de kdb.h e então veremos quantas horas mais temos para gastar.

IMO, a vinculação Rust (e qualquer vinculação nesse sentido) deve ter duas versões. Um que espelha a API C o mais próximo possível e outro que é mais idiomático para a linguagem que se baseia na primeira versão. Na versão idiomática, utilizar o sistema de tipos com BinaryKey e StringKey (ou mesmo genéricos) é provavelmente uma boa ideia, se isso torna o uso da API do Rust mais fácil.

@kodebach eu concordo. E isso parece ser feito também com as caixas elektra e elektra-sys.

@kodebach eu concordo. E isso parece ser feito também com as caixas elektra e elektra-sys.

Sim, eu também acho. Se a API Rust segura tem limitações que precisam ser contornadas, pode-se importar elektra_sys e chamar a função de ligação C um-para-um diretamente.

Obrigada. Pode exigir muitos moldes, então vamos ver se é uma boa ideia. Além disso, outro tipo pode ser útil para chaves em conjuntos de chaves (onde setName não é permitido).

Funcionou muito bem para a implementação principal. No entanto, para KeySets, encontrei um obstáculo. Para qualquer método que retorne uma chave, ela deve estar em conformidade com a interface comum que eu criei. Implementei um método get_value que possui um parâmetro de retorno genérico. Para BinaryKeys isso é bytes, para StringKeys são strings. Mas o que a versão enferrujada de ksNext retorna agora? Um objeto que satisfaça a "interface chave", mas com que valor? Eu tenho que escolher um.
É assim que a assinatura deve se parecer, onde Value é o tipo que get_value retorna. Só posso especificar bytes ( Vec<u8> ) ou String.
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

Então, eu poderia unificá-lo em bytes, mas então o próprio usuário tem que converter para string. Uma vez que a única diferença de StringKey e BinaryKeys é a implementação de set_value e get_value , essa alteração removeria essa explicitação e eu tenho basicamente apenas Chaves novamente.

Acho que o verdadeiro problema é que o KeySet na implementação atual não é explícito sobre o tipo de chaves que contém, mas as * chaves são. Mas permitir que uma instância de KeySet contenha apenas StringKey ou BinaryKey é uma restrição muito grande, suponho.
Acho que Key e KeySet devem ser explícitos sobre o que contêm ou nenhum deles. Estou inclinado para Key e KeySet genéricos agora, apenas para ser consistente com o resto do elektra.
Alguma ideia?

Do ponto de vista da usabilidade, faria sentido retornar a Key que tem um getter para uma String, pois essa é a variante mais usada. O setter para o nome deve ser desabilitado (se for facilmente possível), pois já sabemos que esta chave (retornada por próximo) faz parte de um KeySet.

Em geral, o sistema de tipos deve apoiar o usuário, não atrapalhar. Portanto, mantenha-o o mais simples possível. Os erros mais comuns são:

1. tentando alterar o nome de uma chave que está em um conjunto de chaves.
2. tentando alterar as chaves de metadados (ou outras chaves const).
3. duplicação confusa de Key / KeySet e referências a eles.
4. iteração sobre KeySets que também são usados ​​para cortar chaves de forma que a iteração não funcione mais corretamente.
5. esquecendo de liberar uma chave / conjunto de chaves

Portanto, se o sistema de tipos puder ajudar nisso, seria ótimo. 5. esperançosamente não será possível por design, para 1. e 2. sua abstração deve ajudar.

A confusão binário / string é na verdade um erro bastante raro (porque as chaves binárias são muito atípicas: elas são usadas principalmente para manter ponteiros de função).

Por falar nisso. se você deseja escrever uma decisão de design sobre o uso seguro de APIs, vá em frente (doc / decisão)

Do ponto de vista da usabilidade, faria sentido retornar a Key que tem um getter para uma String, pois essa é a variante mais usada.

Mas nem toda sequência de bytes é UTF-8 válida, então isso não seria mais à prova de digitação, seria?

AFAIK o sistema de macro no Rust é muito poderoso, talvez haja uma maneira de escrever uma função que sempre retorne o tipo correto. Por exemplo, em Kotlin, há uma técnica de mapas para codificar o tipo de valor na chave. A referência da API aqui é um exemplo.

Alternativamente, um StringKeySet que só aceita StringKey s pode fazer sentido, uma vez que as chaves binárias são tão raras e quase sempre não utilizadas nas configurações.

Do ponto de vista da usabilidade, faria sentido retornar a Key que tem um getter para uma String, pois essa é a variante mais usada. O setter para o nome deve ser desabilitado (se for facilmente possível), pois já sabemos que esta chave (retornada por próximo) faz parte de um KeySet.

Mas ainda é possível, embora raro, ter um KeySet com chaves mistas. Então, sempre retornar uma StringKey e chamar get_string seria um erro, mas o sistema de tipos não apenas permite, mas orienta você nessa direção, já que não existe um método get_binary nesse tipo.

Antes de fazer isso, sugiro tornar o KeySet genérico e instanciá-lo como KeySet<StringKey> se o usuário tiver certeza de que há apenas StringKeys dentro (para os KeySets que não vêm do Rust). Então, é natural que iterar sobre ele produza apenas StringKeys.
Isso também faria com que os KeySets fossem homogêneos por meio do sistema de tipos, pelo menos aqueles criados por usuários do Rust, o que seria mais seguro em geral.
Em casos raros onde uma chave binária é esperada, o usuário teria que verificar com is_binary e is_string e então converter, o que seria uma chamada de método segura.

duplicação confusa de Key / KeySet e referências a eles.

Acho que a única coisa que posso fazer é promover o uso de duplicatas em vez de contagem de referências. Pode ser pior para o desempenho, mas keyDel é invocado automaticamente pelo Rust, enquanto a contagem de ref é totalmente manual. Portanto, a duplicação é certamente mais fácil de acertar do que a contagem de referências.

iteração sobre KeySets que também são usados ​​para cortar chaves de forma que a iteração não funcione mais corretamente.

Você quer dizer modificar o conjunto de chaves enquanto itera sobre ele?

Por falar nisso. se você deseja escrever uma decisão de design sobre o uso seguro de APIs, vá em frente (doc / decisão)

Qual seria o conteúdo disso?

AFAIK o sistema de macro no Rust é muito poderoso, talvez haja uma maneira de escrever uma função que sempre retorne o tipo correto.

Eu acho que o design "atual" do KeySet que pode conter qualquer coisa e tipos de Key concretos não funcionam juntos, pelo menos não muito bem. Mas vou olhar para as macros.

Mas nem toda sequência de bytes é UTF-8 válida, então isso não seria mais à prova de digitação, seria?

Nem as strings de Elektra ou o valor binário precisam ser UTF-8. Elektra decide apenas entre string e binário (pode conter 0 bytes).

AFAIK o sistema de macro no Rust é muito poderoso, talvez haja uma maneira de escrever uma função que sempre retorne o tipo correto. Por exemplo, em Kotlin, há uma técnica de mapas para codificar o tipo de valor na chave. A referência da API aqui é um exemplo.

Também precisamos estar atentos para nos esforçarmos em recursos que sejam úteis. Chaves binárias são raras.

Como alternativa, um StringKeySet que aceita apenas StringKeys pode fazer sentido, uma vez que as chaves binárias são muito raras e geralmente não são usadas em configurações.

Sim, mas eu veria StringKeySet como o KeySet normal.

Mas ainda é possível, embora raro, ter um KeySet com chaves mistas. Então, sempre retornar uma StringKey e chamar get_string seria um erro, mas o sistema de tipos não apenas permite, mas orienta você nessa direção, já que não há método get_binary nesse tipo.

Sim, mas como disse, este é um problema menor. Pessoas que armazenam dados binários (como endereços de função) descobrirão como lançar a chave (se houver algum documento sobre isso).

Antes de fazer isso, sugiro tornar o KeySet genérico e instanciá-lo como KeySetse o usuário tiver certeza de que há apenas StringKeys dentro (para os KeySets que não vêm do Rust). Então, é natural que iterar sobre ele produza apenas StringKeys.

Seria apenas uma falsa segurança porque os KeySets vêm do KDB (externamente) e podem conter dados binários em qualquer caso. Portanto, eu prefiro ter um KeySet não genérico.

Se você quiser brincar com genéricos, forneça getters e setters que convertem KeySets em estruturas de dados (genéricas). Por exemplo, uma matriz Elektra de inteiros para Vec<i32> .

Você quer dizer modificar o conjunto de chaves enquanto itera sobre ele?

Sim cut modifica o KeySet. Em geral, os iteradores são seguros para fazer isso, mas muitas pessoas têm problemas para acertar.

Qual seria o conteúdo disso?

Um resumo do que discutimos aqui e como você o projetou.

Eu acho que o design "atual" do KeySet que pode conter qualquer coisa e tipos de Key concretos não funcionam juntos, pelo menos não muito bem.

Eu concordo.

Mas vou olhar para as macros.

Por favor, não dê prioridade a isso.

Nem as strings de Elektra ou o valor binário precisam ser UTF-8.

Então devemos usar OsString ou CString vez de String acordo com uma pesquisa rápida.

Nem as strings de Elektra ou o valor binário precisam ser UTF-8.

Então devemos usar OsString ou CString vez de String acordo com uma pesquisa rápida.

No momento, estou convertendo entre String Rust (que é UTF-8) em CString antes de passá-lo para elektra. O raciocínio é que String é a string padrão e a maioria das outras bibliotecas espera trabalhar com isso.
Em vez disso, posso fazer com que a API de alto nível peça e retorne CString s, de modo que o usuário tenha que lidar com o código de conversão, se precisar de String . Isso tornaria uma API mais fina e menos manipulação de erros que precisa ser tratada. Suponho que se trate de como a maioria dos usuários desejará usar a API, sobre a qual não tenho muitos insights.

Concordo que é melhor retornar o tipo de String mais comum dos idiomas. Strings não UTF8 devem ser raras (talvez até mais raras do que binários).

Concordo que é melhor retornar o tipo de String mais comum dos idiomas. Strings não UTF8 devem ser raras (talvez até mais raras do que binários).

Estou tentando descobrir a melhor maneira de lidar com a Rust -> direção C, indo de UTF-8 para uma string C. Strings UTF-8 podem conter zero bytes, mas o único ponto de código onde aparece é o caractere NUL, não de outra forma . Acho que seria razoável declarar isso como uma pré-condição na documentação de vinculação, que as strings não podem conter o byte zero. Se assim for, o código entra em pânico nesse ponto.

A outra possibilidade é retornar um erro de todas as funções definidas que usam uma string. Mas então os usuários têm que lidar com esse NulError o tempo todo e ele praticamente nunca é devolvido.

keyNew pode retornar um ponteiro NULL no erro de alocação. Em Rust, posso retornar erros explícitos ou pânico, mas não um nulo implícito. O documento ferrugem sobre erros de sinalização considera falta de memória um erro catastrófico e o stdlib aborta neste caso. A vinculação de java parece não lidar com esse caso, então presumo que também saia do processo, já que NullPointerException é lançado.
Você concorda que chamar o pânico aqui é o melhor (abortar não permite a execução de destruidores)?

Acho que seria razoável declarar isso como uma pré-condição na documentação de vinculação, que as strings não podem conter o byte zero. Se assim for, o código entra em pânico nesse ponto.

Sim, é razoável.

Você concorda que chamar o pânico aqui é o melhor (abortar não permite a execução de destruidores)?

Sim, faz sentido entrar em pânico se um malloc falhar. (No caso do Rust, o stdlib faria o mesmo. No C, o stdlib não aborta, então C-Elektra também não aborta).

Agora que as ligações Rust foram mescladas no master, gostaria de publicá-las em crates.io.
Eu sugiro publicá-los com a versão definida para (o padrão) 0.1.0 , em vez de ser vinculado a elektra, simplesmente porque a maturidade das ligações e a própria elektra diferem. Você concorda @ markus2330?

Publicar em https://crates.io requer uma conta GitHub. A propriedade das caixas pode ser transferida entre contas, então eu poderia usar a minha por enquanto. Ou outra pessoa pode fazer o login e enviar-me o token de API necessário para publicar.

Obrigado por publicá-los em crates.io: sparkle:

Eu vincularia a versão diretamente à Elektra, já que eles fazem parte dos repositórios da Elektra. Mas não é realmente importante: se crates.io geralmente tem algum esquema de versão específico, é melhor manter o que é comum lá.

Ou outra pessoa pode fazer o login e enviar-me o token de API necessário para publicar.

Eu loguei em um autorizado. Vou enviar a você o token de API.

Eu vincularia a versão diretamente à Elektra, já que eles fazem parte dos repositórios da Elektra. Mas não é realmente importante: se crates.io geralmente tem algum esquema de versão específico, é melhor manter o que é comum lá.

O maior problema com isso é, de acordo com o controle de versão semântico, se tivermos que fazer uma alteração significativa nas ligações, não podemos simplesmente atualizar a versão de acordo. Portanto, só podemos fazer alterações significativas quando elektra as faz.

De acordo com o controle de versão semântico, você pode fazer qualquer alteração significativa, desde que a versão comece com 0 . Se liberarmos o Elektra 1.0 , é nosso interesse também manter as ligações estáveis. E mesmo se falharmos em fazer isso, também temos no futuro a opção de tornar as versões independentes (simplesmente aumentar a versão principal da ligação Rust). Portanto, acho que é seguro simplesmente usar a versão da Elektra agora.

Você está certo, não pensei em aumentar as versões principais mais tarde.

No momento, wrapper.h especifica #include "kdb.h" para incluir o cabeçalho kdb e gerar ligações para ele. Mas o clang não encontra o cabeçalho (em ubuntu:18.10 , por exemplo). Portanto, tenho que dizer explicitamente ao clang para incluir /usr/include/elektra para que ele seja compilado.
A elektra está sempre instalada em /usr/include/elektra para que esta solução funcione para a maioria das distribuições?

O elektra está sempre instalado em / usr / include / elektra para que esta solução funcione para a maioria das distribuições?

Sim, porque há outra biblioteca (acho que do Kerberos) que usa /usr/include/kdb.h .

Por agora /usr/include/elektra tem que fazer parte do caminho de inclusão, mas AFAIK queremos mudar isso para que #include <elektra/kdb.h> possa ser usado em seu lugar.

O elektra está sempre instalado em / usr / include / elektra para que esta solução funcione para a maioria das distribuições?

Por padrão, é / usr / local / include / elektra, mas a maioria das distribuições usará / usr / include / elektra, mas não há garantia. É por isso que os sistemas de construção geralmente têm algum suporte para localizar arquivos de cabeçalho. Elektra suporta cmake e pkg-config.

Você pode dar algum contexto sobre onde você precisa disso?

pode ser usado em seu lugar.

deve ser usado em seu lugar. O PR relevante é # 2880

Mudar para #include <elektra/kdb.h> definitivamente funciona no Ubuntu. Então, vou mudar para esse caminho em vez de incluir /usr/include/elektra .

Mudar para #include <elektra/kdb.h> definitivamente funciona no Ubuntu. Então, vou mudar para esse caminho em vez de incluir /usr/include/elektra .

Provavelmente não funcionará para todos os cabeçalhos, alguns contam com /usr/include/elektra no caminho de inclusão.

Provavelmente, a melhor coisa a fazer (se possível para você) seria usar pkg-config ou cmake --find-package para encontrar os arquivos Elektra (IMO cmake funciona melhor).

Você pode dar algum contexto sobre onde você precisa disso?

Portanto, se um usuário compilar elektra em sua máquina, ele só precisa de ferrugem / carga e pode usar as amarrações. Mas o outro caso de uso, para o qual crates.io deve ser usado, é quando alguém instala elektra (e cabeçalhos) por meio de seu gerenciador de pacotes. Em seguida, a biblioteca e os cabeçalhos estão disponíveis. Agora que o usuário inclui elektra em suas dependências e a carga irá buscar a caixa elektra-sys . Ele depende apenas do script de construção e do clang para gerar as ligações. Mas o clang precisa encontrar kdb.h alguma forma. Portanto, posso passar caminhos include adicionais codificados no script de compilação ou modificar a instrução #include ... diretamente.

Provavelmente, a melhor coisa a fazer (se possível para você) seria usar pkg-config ou cmake --find-package para encontrar os arquivos Elektra (IMO cmake funciona melhor).

Posso tentar adicionar pkg-config ou cmake como uma dependência de compilação e encontrar kdb.h desta forma. Vou dar uma olhada nisso. Eu concordo que essa é a maneira mais confiável.

Sim, você pode tentar chamar pkg-config em seu script de construção. Se pkg-config não estiver disponível, você pode tentar caminhos codificados como / usr / include / elektra e / usr / local / include / elektra. (Se crates.io não exigir que o pkg-config esteja disponível.)

Você poderia tentar esta caixa

Sim, você pode tentar chamar pkg-config em seu script de construção. Se pkg-config não estiver disponível, você pode tentar caminhos codificados como / usr / include / elektra e / usr / local / include / elektra. (Se crates.io não exigir que o pkg-config esteja disponível.)

Eu adicionei pkg-config como uma dependência opcional. Se for adicionado, ele pesquisará por elektra e usará o includedir fornecido. Caso contrário, ele pesquisará nos dois diretórios nomeados.

As ligações foram publicadas: elektra e elektra-sys : smiley:

Devido à falta de dependência do sistema de libelektra no ambiente de compilação docs.rs, a documentação não foi compilada. Além disso, eles mudarão o ambiente de construção em 30 de setembro.
Enviei uma solicitação para adicionar libelektra como uma dependência para que seja compilado corretamente em 30 de setembro. Ele também adicionou o pacote ao ambiente existente, então os documentos agora estão disponíveis: +1:

Acho que depois que o # 2980 for mesclado, esse problema pode ser resolvido.

Muito bom, eles reagiram super-rápido. Será um problema que eles o construam com um libelektra bastante antigo? (Eu não verifiquei qual versão, mas se eles incluírem do gerenciador de pacotes, será definitivamente mais antigo do que 0.9).

Sem problemas para a caixa elektra , pois é apenas documentação. elektra-sys Acho que contém qualquer versão do elektra em que foi gerado, em vez da atual. Mas acho que dificilmente alguém usaria as ligações brutas em vez dos invólucros. Portanto, uma pequena compensação por ter os documentos criados automaticamente.

Você pode então adicionar os links para o documento em nosso repositório?

Parece que o elektra-sys está quase inutilizável de qualquer maneira. Mostra centenas de símbolos que nada / pouco têm a ver com Elektra. Além disso, não há documento para as funções individuais, por exemplo

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

Você pode então adicionar os links para o documento em nosso repositório?

Sim, vou adicioná-lo ao PR existente

Parece que o elektra-sys está quase inutilizável de qualquer maneira. Mostra centenas de símbolos que nada / pouco têm a ver com Elektra.

Eu vou olhar para isso.

Além disso, não há documento para as funções individuais, por exemplo

É típico que as caixas -sys não tenham docu (por exemplo, openssl-sys ), porque são traduções um-para-um do equivalente em C. Portanto, é necessário consultar o documento C diretamente. Eu também teria que copiar manualmente todo o documento, o que adiciona outra carga de manutenção. Posso criar um link para https://doc.libelektra.org/api/current/html/index.html na página principal do docu.

Parece que o elektra-sys está quase inutilizável de qualquer maneira. Mostra centenas de símbolos que nada / pouco têm a ver com Elektra.

Eu vou olhar para isso.

Ele foi corrigido no # 2980 e será corrigido no docs.rs na próxima vez que publicarmos a caixa.

Posso criar um link para https://doc.libelektra.org/api/current/html/index.html na página principal do docu.

Sim, boa ideia!