¿Cómo manejarían los gestores de paquetes de Linux los módulos C ++ 20?

Estamos en 2020 ahora y se acerca C ++ 20, junto con la tan esperada función de módulos C ++. Pero después de ver algunas charlas sobre CppCon, encuentro que los módulos C ++ están en un lugar extraño, especialmente para los administradores de paquetes de Linux (pacman, apt, emerge, etc.)

Por lo que he aprendido, los módulos C ++ son

Dependiente del compilador
- No puedes usar un módulo creado por GCC en Clang
- Los módulos GCC 9.1 no funcionarán en GCC 9.2
Puedes tener muchas versiones diferentes del mismo módulo
- Siempre que no se exporten al mismo alcance
Necesita reconstruir un módulo si sus dependencias se actualizan

Mi problema es que, en todas las distribuciones de lanzamiento continuo, los compiladores se actualizan todo el tiempo y el usuario puede tener su propia compilación. Actualmente uno solo puede actualizar el compilador o también actualizar libstdc++. Pero con los módulos, parece sugerir libstdc++que debe actualizarse cuando se actualiza el compilador.

¿Cómo manejaría el administrador de paquetes la actualización, por ejemplo, el STL cuando se actualiza el compilador? No creo que sea factible construir todas las versiones del módulo STL para cada versión del compilador. Tampoco es una buena idea que el usuario tenga que construir su propio módulo STL.

— Mary Chang
fuente

" No puede usar un módulo creado por GCC en Clang " No puede usar los resultados compilados de un módulo construido por GCC en Clang.

— Nicol Bolas

No puedo entender el problema. Es posible distribuir los archivos de módulo precompilados, pero no es obligatorio. Cada usuario puede compilarlos una vez para cada compilador / versión y todo está bien. Si el paquete de distribución entrega esos archivos precompilados, solo guarda una compilación única que actualmente hacemos en cada compilación. ¿Dónde está el beneficio de entregar módulos precompilados? La descarga / instalación puede llevar más tiempo como compilación una vez.

— Klaus

¿Qué tipo de respuesta imaginas que no sería pura especulación?

— n. 'pronombres' m.

@Klaus Exactamente, no hay beneficio. Pero la mayoría de las aplicaciones se dividen en 2 partes. Una interfaz y el núcleo lib. Para que las personas puedan interactuar con la funcionalidad central directamente. Toma yosys por ejemplo. Se escupe en libyosys y yosys. Si libyosys decide usar módulos para compilaciones más rápidas, libyosys debe ser creado por cada usuario. Convierte efectivamente a cada administrador de paquetes en AUR o emerge.

— Mary Chang

@ n.'pronouns'm. Esperaba que un desarrollador de administrador de paquetes viera la pregunta y explicara cómo están resolviendo el problema.

— Mary Chang

Por ahora (10 de enero de 2020), el sistema de módulos se considera más una característica interna del proyecto en lugar de un reemplazo de la distribución de encabezado / lib. Como sugieren los muchachos de la comunidad Clang, aunque hay una propuesta para crear un formulario AST independiente del compilador, ni Clang ni Gcc ni Microsoft tienen planes de hacerlo. Entonces adivinas sobre

Puedes tener muchas versiones diferentes del mismo módulo

es correcto y se mantendrá quieto por algún tiempo.

Como aspecto de la plataforma de administración de paquetes, la resolución aún es desconocida, pero dado que el sistema de módulos es más una característica interna del proyecto, el peor de los casos es que la forma de "encabezado / lib" todavía tendrá lugar.

PD: Creo que stackoverflow no es un buen lugar para preguntas como estas, si realmente quieres una respuesta, consulta esta lista de correo.

— ravenisadesk
fuente