Libelektra: Ataduras de óxido

No sé mucho sobre Rust, pero supongo que los enlaces generados por rust-bindgen solo se pueden usar en unsafe Rust? Si ese es el caso, sería bueno tener una envoltura alrededor de aquellos con una API Rust más idiomática.

AFAIK, la mayoría de los enlaces de Rust tienen una caja *-sys para el mapeo 1: 1 de la API C y otra caja con la API que la mayoría de los usuarios usarían en Rust. Si hay una manera de decirle a Rust que invoque automáticamente a keyDel , ksDel y amigos cuando sea necesario, sería muy bueno.

Si ese es el caso, sería bueno tener una envoltura alrededor de aquellos con una API Rust más idiomática.

Si, este es el plan. Y mientras lo hace, compare también con la API de C y tal vez encuentre mejoras en la API de C (al menos en el documento).

@PhilippGackstatter Como se discutió: también descubra cómo cargar en https://crates.io/ y cómo integrar el enlace en nuestro sistema CMake.

@PhilippGackstatter ¿ algún progreso? Tenemos a alguien que también podría estar interesado en ampliar las fijaciones de Rust.

@ markus2330 Empecé hace un par de días, pero principalmente estaba leyendo sobre bindgen, cmake y cómo integrarlo en el proyecto, así que no había nada que mostrar. Pero tengo las primeras dos cosas listas ahora (vea el n. ° 2826). Ahora estoy trabajando completamente en el proyecto.

Para responder las preguntas del n. ° 2826 (prefiera hacer preguntas sobre temas, ya que los RP tienden a confundirse en las discusiones que no están directamente relacionadas con el código):

Una es, para qué encabezados en src / include necesito generar enlaces. Al menos kdb.h, pero ¿hay otros que necesito para la API de bajo nivel, sin compatibilidad con complementos?

No, la API de bajo nivel solo está en kdb.h

La otra es, ¿tengo que cambiar todos los scripts de la ventana acoplable para instalar rustup (que se usa para instalar cargo y rustc)?

Sí, necesita cambiar los scripts de la ventana acoplable y tal vez también el archivo Jenkins. Pero no es necesario cambiarlos todos, si los compila para distribuciones recientes, es suficiente.

Sería bueno si también pudiera compilarlo con el rust nativo compilado incluido en Debian Buster. El archivo de la ventana acoplable Debian Buster aún no se ha fusionado # 2819

Supongo que no hay una forma automatizada de hacerlo.

Hay algunas ideas para hacer esto: # 730

Rust-bindgen ofrece dos formas de generar enlaces. Una es a través de la línea de comandos, que por lo tanto es un proceso manual y debe repetirse si cambia algo en la C-API. La otra es a través de un script de compilación, que se ejecuta cada vez que se ejecuta la compilación de carga. Eso significa que los enlaces se regeneran en cada compilación. Esto es lo que está implementado actualmente. Sin embargo, requiere que todos los que usan los enlaces tengan los encabezados necesarios que necesita elekra. Me imagino que si alguien simplemente instala elektra pero no lo compiló, es posible que no cumpla con todos los requisitos necesarios. ¿Quizás tenga más sentido regenerar los encabezados de vez en cuando, manualmente, ya que la C-API ya no cambia mucho?

La regeneración en cada compilación parece ser la solución adecuada, las otras fijaciones también funcionan de esa manera (requieren que se instale un trago). Simplemente puede instalar los archivos de encabezado generados para evitar los problemas que está describiendo.

Si, este es el plan. Y mientras lo hace, compare también con la API de C y tal vez encuentre mejoras en la API de C (al menos en el documento).

Hasta ahora, he encontrado algunas pequeñas oportunidades de mejora.

• keyGetBinary : Como código de llamada, no puedo saber si un valor de retorno de -1 significa maxSize is 0 o type mismatch , o algo más. Dado que Rust utiliza un manejo de errores explícito en sus argumentos de retorno, me gustaría poder hacer coincidir la falta de coincidencia de tipos con un error y los errores "relacionados con maxSize" con otro. Pero actualmente tengo que usar un error más genérico. Yo mismo podría comprobar si el tipo no coincide, pero keyGetBinary hace eso, así que tengo el mismo control dos veces.
  keySetName hace algo similar, haciendo coincidir dos errores diferentes con -1. En ambos casos, hay errores que son errores (nombre no válido) y errores que pueden ocurrir en programas de sonido (la clave ya está en el conjunto de claves), por lo que puedo entender la decisión. Pero, ¿por qué no utilizar -2 para ser explícito y evitar la doble verificación?
• Gramaticalmente, ¿no debería keyIsDirectBelow ser keyIsDirectlyBelow 🙂? Si es así, ¿debería corregir esto en la API de Rust?

Otra pregunta: keyRel no está implementado en los enlaces CPP. ¿Debería omitir esto también en Rust?

Buen trabajo, a partir de sus preguntas es obvio que ya miró profundamente en la API.

Yo mismo podría verificar si hay una falta de coincidencia de tipos, pero keyGetBinary lo hace, por lo que tengo la misma verificación dos veces.

¿Quizás incluso pueda usar el sistema de tipos para evitar llamadas incorrectas? (keyGetBinary solo está permitido en claves binarias)

Pero, ¿por qué no utilizar -2 para ser explícito y evitar la doble verificación?

El motivo fue la compatibilidad: las API inicialmente solo devolvieron -1 y no es posible agregar otros códigos de error sin romper los programas existentes (que pueden tener ==-1 para buscar errores). Pero con la próxima versión (0.9) podemos romper la API nuevamente. Y podríamos evitar el problema de compatibilidad indicando que cualquier valor por debajo de 0 indica errores. Estoy totalmente de acuerdo en que las uniones deberían producir errores precisos.

¿Quieres solucionar estos problemas de API?

Si es así, ¿debería corregir esto en la API de Rust?

Las API no deben diferir en la ortografía. Si lo arreglamos, deberíamos arreglarlo en la API de C y todos los enlaces (en realidad, solo Java y Go deben adaptarse a mano, los demás se regenerarán correctamente de todos modos).

keyRel no está implementado en los enlaces CPP. ¿Debería omitir esto también en Rust?

Sí, como quizás ya haya notado, keyIs (Direct) Below y keyRel tienen funciones superpuestas. La idea de keyRel era mantener la API pequeña (y por lo tanto la biblioteca pequeña). Pero keyRel tal cual no se puede usar y también es lento. Así que lo más probable es que lo eliminemos dentro de 0.9. Ver doc / todo / FUTURE para otros candidatos a ser eliminados.

¿Quizás incluso pueda usar el sistema de tipos para evitar llamadas incorrectas? (keyGetBinary solo está permitido en claves binarias)

Es una gran idea. Podría tener BinaryKey y StringKey y solo el primero tendría un método get_binary() y solo el segundo tendría un método get_string() , y así sucesivamente. Voy a investigar esto.

¿Quieres solucionar estos problemas de API?

Yo puedo hacer eso. Depende de cuál deba ser la prioridad para mí. Después de terminar la API segura para Rust, dijiste que sería bueno tener también la API del complemento en Rust. Puedes decidir qué es más importante.

Es una gran idea. Podría tener BinaryKey y StringKey y solo el primero tendría un método get_binary () y solo el segundo tendría un método get_string (), y así sucesivamente. Voy a investigar esto.

Gracias. Es posible que requiera demasiados yesos, así que veamos si es una buena idea. También otro tipo podría ser útil para claves en conjuntos de claves (donde no se permite setName).

Yo puedo hacer eso. Depende de cuál deba ser la prioridad para mí. Después de terminar la API segura para Rust, dijiste que sería bueno tener también la API del complemento en Rust. Puedes decidir qué es más importante.

Sí, primero finalice la API de Rust de kdb.h y luego veremos cuántas horas más tenemos para gastar.

En mi opinión, la encuadernación de Rust (y cualquier encuadernación para el caso) debería tener dos versiones. Uno que refleja la API de C lo más cerca posible y otro que es más idiomático para el lenguaje que se basa en la primera versión. En la versión idiomática, utilizar el sistema de tipos con BinaryKey y StringKey (o incluso genéricos) es probablemente una buena idea, si facilita el uso de la API de Rust.

@kodebach estoy de acuerdo. Y esto parece que también se hace con las cajas elektra y elektra-sys.

@kodebach estoy de acuerdo. Y esto parece que también se hace con las cajas elektra y elektra-sys.

Yo tambien pienso lo mismo. Si la API segura de Rust tiene limitaciones que deben solucionarse, se puede importar elektra_sys y llamar directamente a la función de enlace C uno a uno.

Gracias. Es posible que requiera demasiados yesos, así que veamos si es una buena idea. También otro tipo podría ser útil para claves en conjuntos de claves (donde no se permite setName).

Funcionó muy bien para la implementación clave. Sin embargo, para KeySets, me he topado con un obstáculo. Para cualquier método que devuelva una clave, debe ajustarse a la interfaz común que he creado. Implementé un método get_value que tiene un parámetro de retorno genérico. Para BinaryKeys son bytes, para StringKeys son cadenas. Pero, ¿qué devuelve ahora la versión oxidada de ksNext ? Un objeto que satisface la "interfaz clave", pero ¿con qué valor? Tengo que elegir uno.
Así es como debe verse la firma, donde Value es el tipo que devuelve get_value . Solo puedo especificar bytes ( Vec<u8> ) o String.
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

Entonces podría unificarlo en bytes, pero luego el usuario tiene que convertirlo en una cadena. Dado que la única diferencia de StringKey y BinaryKeys son su implementación set_value y get_value , este cambio eliminaría esa explicidad y básicamente solo tengo Keys nuevamente.

Supongo que el problema real es que KeySet en la implementación actual no es explícito sobre qué tipo de claves contiene, pero las * claves sí lo son. Pero permitir que una instancia de KeySet solo contenga StringKey o BinaryKey es una restricción demasiado grande, supongo.
Creo que tanto Key como KeySet tienen que ser explícitos sobre lo que contienen o ninguno de ellos. Me estoy inclinando hacia Key y KeySet genéricos ahora, solo para ser consistente con el resto de elektra.
¿Alguna idea?

Desde el punto de vista de la usabilidad, tendría sentido devolver la clave que tiene un captador para una cadena, ya que esta es la variante más utilizada. Setter para el nombre debe estar deshabilitado (si es posible), ya que sabemos que esta clave (devuelta por next) es parte de un KeySet.

En general, el sistema de tipos debe ayudar al usuario, no interponerse en su camino. Así que manténgalo lo más simple posible. Los errores más comunes son:

1. tratando de cambiar el nombre de las claves para una clave que está en un conjunto de claves.
2. tratando de cambiar las claves de metadatos (u otras claves constantes).
3. confusa duplicación de Key / KeySet y referencias a ellos.
4. iterando sobre KeySets que también se usan para cortar claves de una manera que la iteración ya no funciona correctamente.
5. Olvidar liberar un Key / KeySet

Entonces, si el sistema de tipos puede ayudar, sería genial. 5. Es de esperar que no sea posible por diseño, ya que 1. y 2. su abstracción debería ayudar.

La confusión binario / cadena es en realidad un error bastante raro (porque las claves binarias son muy atípicas: se usan principalmente para contener punteros de función).

Por cierto. si desea redactar una decisión de diseño sobre usos seguros de las API, continúe (documento / decisión)

Desde el punto de vista de la usabilidad, tendría sentido devolver la clave que tiene un captador para una cadena, ya que esta es la variante más utilizada.

Pero no todas las secuencias de bytes son UTF-8 válidas, por lo que ya no sería seguro para los tipos, ¿verdad?

AFAIK, el sistema de macros en Rust es muy poderoso, tal vez haya una manera de escribir una función que siempre devuelva el tipo correcto. Por ejemplo, en Kotlin existe una técnica para que los mapas codifiquen el tipo de valor en la clave. La referencia de API aquí es un ejemplo.

Alternativamente, un StringKeySet que solo acepta StringKey s podría tener sentido, ya que las claves binarias son muy raras y la mayoría de las veces no se usan en configuraciones.

Desde el punto de vista de la usabilidad, tendría sentido devolver la clave que tiene un captador para una cadena, ya que esta es la variante más utilizada. Setter para el nombre debe estar deshabilitado (si es posible), ya que sabemos que esta clave (devuelta por next) es parte de un KeySet.

Pero aún es posible, aunque raro, tener un KeySet con claves mixtas. Entonces siempre devolver una StringKey y llamar a get_string sería un error, pero el sistema de tipos no solo lo permite, sino que lo guía hacia él, ya que no hay get_binary método

Antes de hacer eso, sugiero hacer KeySet genérico y instanciarlo como KeySet<StringKey> si el usuario está seguro de que solo hay StringKeys adentro (para aquellos KeySets que no provienen de Rust). Entonces es natural que iterar sobre él produzca solo StringKeys.
También impondría que los KeySets sean homogéneos a través del sistema de tipos, al menos los creados por los usuarios de Rust, lo que en general sería más seguro.
En casos raros donde se espera una clave binaria, el usuario tendría que verificar con is_binary y is_string y luego convertir, lo que sería una llamada a un método seguro.

confusa duplicación de Key / KeySet y referencias a ellos.

Creo que lo único que puedo hacer es promover el uso de duplicados en lugar del recuento de referencias. Puede que sea peor para el rendimiento, pero Rust invoca automáticamente keyDel, mientras que el recuento de referencias es completamente manual. Por lo tanto, la duplicación es ciertamente más fácil de hacer bien que el conteo de referencias.

iterando sobre KeySets que también se usan para cortar claves de una manera que la iteración ya no funciona correctamente.

¿Te refieres a modificar el conjunto de claves mientras se itera sobre él?

Por cierto. si desea redactar una decisión de diseño sobre usos seguros de las API, continúe (documento / decisión)

¿Cuál sería el contenido de eso?

AFAIK, el sistema de macros en Rust es muy poderoso, tal vez haya una manera de escribir una función que siempre devuelva el tipo correcto.

Creo que el diseño "actual" de KeySet que puede contener cualquier cosa y tipos de claves concretos no funciona en conjunto, al menos no muy bien. Pero miraré las macros.

Pero no todas las secuencias de bytes son UTF-8 válidas, por lo que ya no sería seguro para los tipos, ¿verdad?

Ni las cadenas ni el valor binario de Elektra deben ser UTF-8. Elektra solo decide entre cadena y binario (puede contener 0 bytes).

AFAIK, el sistema de macros en Rust es muy poderoso, tal vez haya una manera de escribir una función que siempre devuelva el tipo correcto. Por ejemplo, en Kotlin existe una técnica para que los mapas codifiquen el tipo de valor en la clave. La referencia de API aquí es un ejemplo.

También debemos tener cuidado para esforzarnos en las funciones que son útiles. Las claves binarias son raras.

Alternativamente, un StringKeySet que solo acepta StringKeys podría tener sentido, ya que las claves binarias son muy raras y, en su mayoría, no se usan en configuraciones.

Sí, pero vería StringKeySet como el KeySet normal.

Pero aún es posible, aunque raro, tener un KeySet con claves mixtas. Entonces siempre devolver una StringKey y llamar a get_string sería un error, pero el sistema de tipos no solo lo permite, sino que lo guía hacia él, ya que no hay un método get_binary en ese tipo.

Sí, pero como dije, este es un problema menor. Las personas que almacenan datos binarios (como direcciones de funciones) descubrirán cómo emitir la clave (si hay algún documento al respecto).

Antes de hacer eso, sugiero hacer KeySet genérico y crear una instancia como KeySetsi el usuario está seguro de que solo hay StringKeys adentro (para aquellos KeySets que no provienen de Rust). Entonces es natural que iterar sobre él produzca solo StringKeys.

Sería solo una seguridad falsa porque los KeySets provienen de KDB (externamente) y pueden contener datos binarios en cualquier caso. Por lo tanto, prefiero tener KeySet no genérico.

Si desea jugar con genéricos, proporcione captadores y definidores que conviertan KeySets en estructuras de datos (genéricas). Por ejemplo, una matriz Elektra de números enteros hasta Vec<i32> .

¿Te refieres a modificar el conjunto de claves mientras se itera sobre él?

Sí cut modifica el KeySet. En general, los iteradores son seguros para hacerlo, pero muchas personas tienen problemas para hacerlo bien.

¿Cuál sería el contenido de eso?

Un resumen de lo que discutimos aquí y cómo lo diseñó.

Creo que el diseño "actual" de KeySet que puede contener cualquier cosa y tipos de claves concretos no funciona en conjunto, al menos no muy bien.

Estoy de acuerdo.

Pero miraré las macros.

Por favor, no le dé prioridad.

Ni las cadenas ni el valor binario de Elektra deben ser UTF-8.

Entonces deberíamos usar OsString o CString lugar de String según una búsqueda rápida.

Ni las cadenas ni el valor binario de Elektra deben ser UTF-8.

Entonces deberíamos usar OsString o CString lugar de String según una búsqueda rápida.

Ahora mismo estoy convirtiendo entre String Rust (que es UTF-8) a CString antes de pasarlo a elektra. La razón es que String es la cadena predeterminada y la mayoría de las otras bibliotecas esperan trabajar con eso.
En su lugar, puedo hacer que la API de alto nivel solicite y devuelva CString s, de modo que el usuario tenga que lidiar con el código de conversión, si necesita un String . Sería una API más delgada y menos manejo de errores que debe tratarse. Supongo que todo se reduce a cómo la mayoría de los usuarios querrán usar la API, de la que no tengo tanta información.

Estoy de acuerdo en que es mejor devolver el tipo de cadena más común de los idiomas. Las cadenas que no son UTF8 deberían ser raras (tal vez incluso más raras que los binarios).

Estoy de acuerdo en que es mejor devolver el tipo de cadena más común de los idiomas. Las cadenas que no son UTF8 deberían ser raras (tal vez incluso más raras que los binarios).

Estoy tratando de descubrir la mejor manera de manejar la dirección Rust -> C, pasando de UTF-8 a una C-string. Las cadenas UTF-8 pueden contener cero bytes, pero el único punto de código donde aparece es el carácter NUL, no de otra manera . Creo que sería razonable establecer esto como una condición previa en la documentación vinculante, que las cadenas no pueden contener el byte cero. Si lo hace de todos modos, el código entra en pánico en ese momento.

La otra posibilidad es devolver un error de todas las funciones establecidas que toman una cadena. Pero luego los usuarios tienen que lidiar con este NulError todo el tiempo y prácticamente nunca se devuelve.

keyNew puede devolver un puntero NULL en caso de error de asignación. En Rust puedo devolver errores explícitos o pánico, pero no un nulo implícito. El documento rust sobre errores de señalización considera que la falta de memoria es un error catastrófico y el stdlib aborta en este caso. El enlace de Java parece no manejar este caso, así que supongo que también saldría del proceso, ya que se lanza un NullPointerException .
¿Está de acuerdo en que llamar al pánico aquí es lo mejor (abortar no permite que se ejecuten los destructores)?

Creo que sería razonable establecer esto como una condición previa en la documentación vinculante, que las cadenas no pueden contener el byte cero. Si lo hace de todos modos, el código entra en pánico en ese momento.

Sí, es razonable.

¿Está de acuerdo en que llamar al pánico aquí es lo mejor (abortar no permite que se ejecuten los destructores)?

Sí, tiene sentido entrar en pánico si falla un malloc. (En el caso de Rust como stdlib haría lo mismo. En C, stdlib no aborta, por lo que C-Elektra tampoco aborta).

Ahora que las encuadernaciones de Rust se fusionaron en master, me gustaría publicarlas en crates.io.
Sugiero publicarlos con la versión configurada en (la predeterminada) 0.1.0 , en lugar de estar vinculada a elektra, simplemente porque la madurez de las vinculaciones y elektra en sí difieren. ¿Estás de acuerdo @ markus2330?

Publicar en https://crates.io requiere una cuenta de GitHub. La propiedad de las cajas se puede transferir entre cuentas, por lo que podría usar la mía por ahora. O alguien más podría iniciar sesión y enviarme el token de API que se requiere para publicar.

Gracias por publicarlos en crates.io: sparkle:

Vincularía la versión directamente a Elektra, ya que son parte de los repositorios de Elektra. Pero no es realmente importante: si crates.io generalmente tiene algunos esquemas de versión específicos, es mejor que se ciña a lo que es común allí.

O alguien más podría iniciar sesión y enviarme el token de API que se requiere para publicar.

Me conecté a un. Te enviaré el token de la API.

Vincularía la versión directamente a Elektra, ya que son parte de los repositorios de Elektra. Pero no es realmente importante: si crates.io generalmente tiene algunos esquemas de versión específicos, es mejor que se ciña a lo que es común allí.

El principal problema con esto es que, de acuerdo con el control de versiones semántico, si tenemos que hacer un cambio importante en los enlaces, no podemos simplemente actualizar la versión en consecuencia. Por lo tanto, solo podríamos hacer cambios importantes cuando elektra los hace.

De acuerdo con el control de versiones semántico, puede hacer cualquier cambio importante siempre que la versión comience con 0 . Si liberamos Elektra 1.0 , es nuestro interés mantener también estables las uniones. E incluso si fallamos al hacerlo, también tenemos en el futuro la opción de hacer que las versiones sean independientes (simplemente aumentar la versión principal del enlace de Rust). Entonces creo que es seguro usar simplemente la versión de Elektra ahora.

Tienes razón, no pensé en aumentar las versiones principales más adelante.

En este momento, wrapper.h especifica #include "kdb.h" para incluir el encabezado kdb y generar enlaces para él. Pero clang no encuentra el encabezado (en ubuntu:18.10 , por ejemplo). Así que tengo que decirle explícitamente a clang que incluya /usr/include/elektra para que se compile.
¿Elektra siempre está instalado en /usr/include/elektra para que esta solución funcione para la mayoría de las distribuciones?

¿Elektra siempre está instalado en / usr / include / elektra para que esta solución funcione para la mayoría de las distribuciones?

Sí, porque hay otra biblioteca (creo que de Kerberos) que usa /usr/include/kdb.h .

Por ahora /usr/include/elektra tiene que ser parte de la ruta de inclusión, pero AFAIK queremos cambiar eso para que se pueda usar #include <elektra/kdb.h> su lugar.

¿Elektra siempre está instalado en / usr / include / elektra para que esta solución funcione para la mayoría de las distribuciones?

Por defecto es / usr / local / include / elektra pero la mayoría de las distribuciones usarán / usr / include / elektra pero no hay garantía. Es por eso que los sistemas de compilación suelen tener algún soporte para localizar archivos de encabezado. Elektra es compatible con cmake y pkg-config.

¿Puede darnos un contexto sobre dónde lo necesita?

se puede utilizar en su lugar.

debe utilizarse en su lugar. El PR relevante es # 2880

Cambiar a #include <elektra/kdb.h> definitivamente funciona en Ubuntu. Entonces cambiaré a esa ruta en lugar de incluir /usr/include/elektra .

Cambiar a #include <elektra/kdb.h> definitivamente funciona en Ubuntu. Entonces cambiaré a esa ruta en lugar de incluir /usr/include/elektra .

Probablemente no funcione para todos los encabezados, algunos dependen de que /usr/include/elektra esté en la ruta de inclusión.

Probablemente lo mejor que puede hacer (si es posible para usted) sería usar pkg-config o cmake --find-package para encontrar los archivos de Elektra (IMO cmake funciona mejor).

¿Puede darnos un contexto sobre dónde lo necesita?

Entonces, si un usuario compila elektra en su máquina, entonces solo necesita óxido / carga y puede usar los enlaces. Pero el otro caso de uso, para el que debería usarse crates.io, es si alguien instala elektra (y encabezados) a través de su administrador de paquetes. Entonces la biblioteca y los encabezados están disponibles. Ahora ese usuario incluye elektra en sus dependencias y cargo buscará la caja elektra-sys . Solo se basa en el script de compilación y el sonido metálico para generar los enlaces. Pero clang necesita encontrar kdb.h alguna manera. Por lo tanto, puedo pasar rutas de inclusión adicionales codificadas en el script de compilación o modificar la instrucción #include ... directamente.

Probablemente lo mejor que puede hacer (si es posible para usted) sería usar pkg-config o cmake --find-package para encontrar los archivos de Elektra (IMO cmake funciona mejor).

Puedo intentar agregar pkg-config o cmake como una dependencia de compilación y encontrar kdb.h esta manera. Voy a investigar esto. Estoy de acuerdo que esta es la forma más confiable.

Sí, puede intentar llamar a pkg-config en su script de compilación. Si pkg-config no está disponible, puede probar rutas codificadas como / usr / include / elektra y / usr / local / include / elektra. (Si crates.io no requiere que pkg-config esté disponible).

Podrías probar esta caja

Sí, puede intentar llamar a pkg-config en su script de compilación. Si pkg-config no está disponible, puede probar rutas codificadas como / usr / include / elektra y / usr / local / include / elektra. (Si crates.io no requiere que pkg-config esté disponible).

Agregué pkg-config como una dependencia opcional. Si se agrega, buscará elektra y usará el includedir provisto. De lo contrario, buscará en los dos directorios que nombró.

Los enlaces ahora están publicados: elektra y elektra-sys : smiley:

Debido a la falta de dependencia del sistema de libelektra en el entorno de compilación docs.rs, la documentación no se compiló. Además, cambiarán el entorno de construcción el 30 de septiembre.
Envié una solicitud para agregar libelektra como dependencia para que se compile correctamente el 30 de septiembre. También agregó el paquete al entorno existente, por lo que los documentos ahora están disponibles: +1:

Creo que después de fusionar el n. ° 2980, este problema se puede cerrar.

Muy bien, reaccionaron súper rápido. ¿Será un problema que lo construyan con una libelektra bastante antigua? (No verifiqué qué versión, pero si la incluyen desde el administrador de paquetes, definitivamente será anterior a la 0.9).

No hay problemas para la caja elektra , ya que es solo documentación. elektra-sys Creo que contiene cualquier versión de elektra contra la que se generó en lugar de la actual. Pero creo que casi nadie usaría las encuadernaciones sin procesar en lugar de las envolturas. Entonces, una pequeña compensación por tener documentos construidos automáticamente.

¿Puede agregar los enlaces al documento dentro de nuestro repositorio?

Parece que elektra-sys es casi inutilizable de todos modos. Muestra cientos de símbolos que no tienen nada o poco que ver con Elektra. Además, no hay documentación para las funciones individuales, p. Ej.

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

¿Puede agregar los enlaces al documento dentro de nuestro repositorio?

Sí, lo agregaré al PR existente

Parece que elektra-sys es casi inutilizable de todos modos. Muestra cientos de símbolos que no tienen nada o poco que ver con Elektra.

Voy a mirar en esto.

Además, no hay documentación para las funciones individuales, p. Ej.

Es típico que las cajas -sys no tengan documento (por ejemplo, openssl-sys ), porque son traducciones uno a uno del equivalente de C. Entonces uno tiene que buscar el documento C directamente. También tendría que copiar a mano todo el documento, lo que agrega otra carga de mantenimiento. Sin embargo, puedo vincularme a https://doc.libelektra.org/api/current/html/index.html en la página principal del documento.

Parece que elektra-sys es casi inutilizable de todos modos. Muestra cientos de símbolos que no tienen nada o poco que ver con Elektra.

Voy a mirar en esto.

Está corregido en # 2980 y se corregirá en docs.rs la próxima vez que publiquemos la caja.

Sin embargo, puedo vincularme a https://doc.libelektra.org/api/current/html/index.html en la página principal del documento.

¡Sí, buena idea!