Rust-rocksdb: Vinculación con el sistema RocksDB

Relacionado con esto, sería genial si estas variables de entorno estuvieran documentadas en el archivo README y los documentos.

¡Esto sería realmente útil!

El archivo de compilación para openssl-sys puede ser un buen lugar para inspirarse aquí.

Estoy trabajando en esto

@lovesegfault ¿Cómo está tu progreso en esto? La construcción de rocksdb es, con mucho, la mayor parte del tiempo de construcción de mi proyecto en este momento: llorar:

¿Cuál es el problema para usar la biblioteca del sistema ahora? AFAIK, funciona bien a través de pkg-config o env variable.

@aleksuss Bueno, en el actual master , si trato de construir librocksdb-sys , todavía genera un montón de instancias de compilador de C ++, aunque tengo rocksdb instalado como una biblioteca de todo el sistema:

$ ls /usr/lib/librocksdb.so*
/usr/lib/librocksdb.so  /usr/lib/librocksdb.so.6  /usr/lib/librocksdb.so.6.5.3

Había dejado de trabajar en esto porque otras cosas tenían prioridad en la oficina. Me iré de vacaciones durante las próximas ~ 2 semanas, así que espero poder retomar esto :)

Tenga en cuenta que el número 354 no agrega ninguna magia de descubrimiento de bibliotecas. Principalmente porque RocksDB no admite pkg-config ni ninguna otra herramienta similar.

En el futuro, se podría agregar fácilmente una cláusula simple que busque las bibliotecas en los lugares habituales en caso de que el envvar correspondiente no esté configurado.

Ah, ya veo, así que si la caja _actualmente_ no encuentra un RocksDB en todo el sistema, ese seguirá siendo el caso. Me pregunto qué lo está haciendo fallar. ¿Quizás busca _exactamente_ la misma versión del .so , no solo una compatible?

Bueno, la caja actual intentará encontrar un sistema rocksdb y un proveedor si no puede. # 354 significa que usted selecciona, a través de una función, si es proveedor o no. Si no es proveedor, debe configurar ROCKSDB_LIB_DIR y, si no lo hace, recibirá un mensaje de error útil.

Puedo agregar un seguimiento que intente encontrar la biblioteca si el envvar no está configurado, generalmente no soy fanático de ese comportamiento.

@lovesegfault ¿ No ROCKSDB_LIB_DIR está _no_ configurado, ¿entonces rocksdb _will_ vendor? Y la _única_ forma de que se vincule con la biblioteca de todo el sistema es estableciendo ROCKSDB_LIB_DIR ?

Tengo curiosidad, ¿por qué estaría en contra de usar la biblioteca del sistema de forma predeterminada? Vendoring trae _ enormes_ tiempos de compilación, y no estoy seguro de cuál es la ventaja.

@jonhoo
Comportamiento actual
librocksdb-sys buscará ROCKSDB_LIB_DIR envvar. Si está configurado, se vinculará al .so en ese directorio. Si no está configurado, ofrecerá rocksdb como alternativa. El mismo comportamiento _exacto_ también ocurre para las bibliotecas de compresión como bzip2 , con la variable BZIP2_LIB_DIR , por ejemplo.

Nuevo comportamiento
librocksdb-sys tiene una función nueva (predeterminada) vendor . Si esa función está habilitada, no intentará buscar ninguna biblioteca del sistema, de ninguna manera. En su lugar, ofrecerá rocksdb y todas las bibliotecas de compresión.

Si la función vendor no está habilitada, entonces librocksdb-sys no intentará, de ninguna manera, vender ninguna biblioteca, incluidas rocksdb y las bibliotecas de compresión. En su lugar, buscará envvars que le informen dónde encontrar las bibliotecas necesarias. Estos envvars tienen el formato LIBNAME_LIB_DIR . No intentará hacer ningún descubrimiento de bibliotecas del sistema, depende de que el usuario las especifique.Si tiene vendor deshabilitado y se olvida de configurar el envvar correspondiente, la compilación fallará con un mensaje que le indicará que configure el envvar.

Posible comportamiento futuro
En el futuro, cuando vendor esté deshabilitado, podríamos intentar hacer el descubrimiento de las bibliotecas del sistema, como alternativa cuando las envvars no estén configuradas. Aún no lo he implementado, pero planeo hacerlo cuando tenga tiempo.

Hacer esto con una característica es un poco extraño, porque significa que si _cualquier_ caja en su árbol de dependencia incluye rocksdb con el conjunto de características vendor , entonces se venderá RocksDB. No hará mucha diferencia para las cajas pequeñas, pero para un binario grande que puede tener múltiples dependencias transitivas en RocksDB, es muy probable que no haya forma de optar por no vender.

@jonhoo Eso es cierto, ¿de qué otra manera imagina que esto funcione?

En mi humilde opinión, no debería haber venta en absoluto, la venta es la raíz de todos los males. Si @aleksuss y otros mantenedores lo permitieran, preferiría deshacerme de la venta por completo.

Estoy de acuerdo con usted: la solución es no ser proveedor. Como mínimo, la venta no debería estar en el conjunto de funciones predeterminado. Una opción es hacer que el proveedor se habilite mediante una variable de entorno.

Eso se podría hacer, @aleksuss @vitvakatu, ¿qué

De hecho, las características son difíciles de controlar en caso de dependencias transitivas, y compilar RocksDB desde la fuente cuesta mucho (para nuestro proyecto, ¡es aproximadamente un 30% de aumento del tiempo de compilación!). Sin embargo, no me gusta la idea de eliminar por completo los proveedores. En algunas plataformas no tenemos disponible la versión más reciente de rocksdb: incluso nos vimos obligados a crear nuestro propio PPA para distribuciones de Ubuntu más antiguas.

Entonces, preferiría guardar el comportamiento actual, pero tal vez mejorarlo (¿búsqueda automática de bibliotecas?). Quizás deberíamos obligar al usuario a habilitar manualmente la venta (a través de env var), pero también sería un poco molesto para las dependencias transitivas.

Bueno, en el maestro actual, si trato de compilar librocksdb-sys, aún genera un montón de instancias del compilador de C ++, aunque tengo rocksdb instalado como una biblioteca para todo el sistema:

Esto también se ve bastante extraño y probablemente debería arreglarse.

@vitvakatu Sí, creo que "invertir" el comportamiento para que los usuarios opten por la venta es probablemente el camino correcto a seguir :)

Esto también se ve bastante extraño y probablemente debería arreglarse.

Tenga en cuenta que no tengo ningún conjunto de vars env, así que creo que este es el comportamiento previsto por hoy.

Muy bien, invertí el comportamiento :)

@lovesegfault Creo que si estamos invirtiendo el comportamiento, entonces probablemente también sea necesario tener build.rs buscar rocksdb en /usr/lib o algo por defecto. De lo contrario, un grupo de usuarios de repente obtendrán errores de compilación, ya que no tienen configurado el var env.

Muy bien, entonces el trabajo pendiente es:

• Descubrimiento de bibliotecas
• Convierta la función vendor en envvar