Lapack: Construir sistemas

Para agregar a la lista, las compilaciones de CMake actualmente (parecen) admiten la opción de compilar solo partes seleccionadas de la biblioteca (REAL, DOBLE, COMPLEJO y / o DOBLE COMPLEJO), mientras que las compilaciones solo de Makefile no lo hacen. (He cambiado los Makefiles en la copia que distribuimos con OpenBLAS y podría producir un PR si lo deseara; tendría que volver a realizar la transferencia para omitir algunos cambios que no son relevantes aquí)

Las compilaciones de CMake actualmente (parecen) admiten la opción de compilar solo partes seleccionadas de la biblioteca (REAL, DOBLE, COMPLEJO y / o DOBLE COMPLEJO)

Esta opción funcionó la última vez que la probé (alrededor de mayo de 2020).

La compilación de CMake tiene varias opciones, aquí enumero las más importantes para mí:

• construir bibliotecas compartidas o estáticas
• pruebas habilitadas o deshabilitadas
• Índices de 64 o 32 bits
• compilaciones optimizadas y de depuración
• opciones para la biblioteca del generador de matrices (TMG), uso de otras bibliotecas BLAS, BLAS ++, LAPACK ++ ...

Buena idea. Construir trabajando en mi máquina con make pero no en el ci con CMake me ha vuelto loco algunas veces.

Técnicamente, creo que Makefile también admite muchas de esas opciones (puede editar su make.inc). Si desea una compilación sin las pruebas, puede compilar con make lib . Pero, lo que es más importante, no se admite la creación de una biblioteca compartida. La mayoría de la gente usa LAPACK como biblioteca compartida, por lo que CMake es el claro ganador para mí.

Si terminamos haciéndolo, sugiero que agreguemos algunas instrucciones de compilación adicionales al archivo Léame. Cómo construir y ejecutar las pruebas, cómo agregar banderas, especialmente la bandera frecursiva. Quizás incluso alguna pequeña nota sobre cómo usar la biblioteca compartida.

Sospecho que ya habrá muchos parches flotando (por ejemplo, en distribuciones de Linux que empaquetan lapack) para construir bibliotecas compartidas con gmake. No debería ser demasiado complicado agregar una opción BUILD_SHARED para make.inc como el BUILD_DEPRECATED que ya está allí (y ambos son bastante oscuros en la compilación de CMake a menos que uno ya sepa que existen ccmake y cmake-gui).

No debería ser demasiado complicado agregar una opción BUILD_SHARED para make.inc como el BUILD_DEPRECATED que ya está allí (y ambos son bastante oscuros en la compilación de CMake a menos que uno ya sepa que existen ccmake y cmake-gui).

No es necesario trabajar con ccmake para configurar ninguna de estas opciones. Puede usar la línea de comando similar al script configure generado por autotools:

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

Ciertamente puede, mi punto es que no hay documentación obvia excepto la lectura de CMakelists.txt (mientras que README apunta a los archivos make.inc preconfigurados para gmake). ccmake y cmake-gui muestran una lista de opciones disponibles, pero cualquiera que sea nuevo en cmake la perderá.

Si escribimos una documentación sobre cómo usar CMAKE, podemos usarme como usuario de conejillo de indias ya que nunca he usado CMAKE.

Al leer toda la conversación, siento que el Makefile está en LAPACK solo para mí. ;)

Bueno no lo sé.

Sí: mantener varios sistemas de compilación genera inconsistencias. Entonces veo el argumento de tener solo uno. (Ya sea CMAKE, make o meson.) (Oh, sí, nunca he usado meson, si te lo preguntas).

Me preocupa pasar a CMAKE porque, no solo no sé cómo usarlo, no sé cómo mantenerlo. Sin embargo, parece que tenemos una comunidad maravillosa que puede ayudar, por lo que no poder trabajar en esta parte del proyecto no parece un problema, además, probablemente debería aprender CMAKE.

Todos: Por favor, exprese su opinión en este hilo.

Parece que a la mayoría de nosotros le gustaría (1) eliminar make y eliminar meson; (2) pasar a CMAKE solamente; (3) agregue buena documentación sobre cómo usar CMAKE. Bien por mi.

Voy a enviar algunos correos electrónicos a otros mantenedores de paquetes aquí y allá para preguntarles cómo les está yendo y cuál es su opinión sobre este tema.

@ martin-frbg: ¿cómo se hace esto en OpenBLAS?

OpenBLAS tiene Makefiles como su sistema de compilación "tradicional" que "se sabe que funciona", y CMAKE como una alternativa originalmente aportada por el usuario que todavía muestra una advertencia de que los archivos que genera pueden no corresponder exactamente a lo que haría una compilación de Makefile.
No me gusta mucho CMAKE, pero he aprendido a crear archivos de compilación de cmake que funcionen (aunque quizás a veces sean poco ortodoxos). En mi opinión, los Makefiles deberían permanecer (y creo que gmake todavía está más extendido que cmake). No conozco la historia del soporte de mesones - _si_ esta fue una contribución única "arrojada por la valla" que nadie conoce o se preocupa lo suficiente como para mantenerla actualizada, supongo que no tiene mucho sentido mantenerla.

No conozco la historia del soporte de mesón - si esta fue una contribución única "arrojada por la valla" que nadie conoce o se preocupa lo suficiente como para mantenerla actualizada, supongo que no tiene mucho sentido mantenerla.

La construcción de Meson se lanzó en paracaídas en LAPACK en PR # 311.

Hm. Si fuera aceptado en 3.9.0 (incluso si solo es una prueba de concepto), parecería un poco extraño desecharlo nuevamente con la próxima versión ...

Me comuniqué con @therault . ¡Gracias @therault!

Open MPI usa solo autoconf (automake, autoconf, configure, Makefiles).

Para PaRSEC y DPLASMA, solo usamos CMake, y para ayudar a los usuarios que están acostumbrados a configurar, @abouteiller hizo un script que usa la sintaxis de configure y llama a CMake con su propia sintaxis.

Sé de un proyecto importante que intentó mantener tanto configure como CMake. Evolucionó lentamente en una situación en la que el 100% de las funciones estaban disponibles en CMake y cada vez se admitían menos funciones nuevas en la configuración. Creo que han dejado de mantener la versión de configuración.

Mantener dos sistemas de compilación para un código es difícil: en teoría, el sistema de compilación debería funcionar con cualquier código y, por lo tanto, debería ser posible mantener dos (con un alto costo para los mantenedores, mantenerlos sincronizados, razón por la cual el configure se eliminó en ese otro proyecto, el mantenedor decidió que tenía mejores cosas que hacer con su tiempo). En la práctica, a veces es necesario adaptar el código al sistema de compilación para hacer las cosas más limpias. Cuando eso sucede, uno de los dos sistemas de compilación necesita usar soluciones y trucos para comportarse como el otro y de acuerdo con el código.

Al final, CMake o configure, ambos decepcionarán. Somos programadores / matemáticos / hacemos algoritmos ... Dedicar tiempo a entender por qué en esa máquina, con esta combinación de compiladores y banderas, el código no se compila correctamente, eso a nadie le gusta. Peor aún, tratar de encontrar cómo hacer esa cosa u otra usando CMake o autoconf te hará subir la pared :) Trabajando con ambos, puedo garantizar que te quejarás de los dos :) Mantener uno solo es una forma segura de quejarse dos veces menos.

Hoy, estoy a favor de CMake por una única razón: CMake hace un buen trabajo generando archivos Ninja en lugar de Makefiles. Ninja compila PaRSEC dos o tres veces más rápido que Make -j. Ahora, tal vez configure / autoconf también pueda generar archivos Ninja, nunca lo intenté ... Si nunca antes probaste ninja, y si LAPACK tiene una versión de CMake, te sugiero que pruebes cmake -G Ninja (después de instalar Ninja en tu máquina). Para compilar, llame a 'ninja' en el directorio donde ejecutó cmake en lugar de 'make'. Verás, eso es increíble :)

Me complace contribuir con dicho script de pegamento configure-to-cmake a LAPACK si eso es algo que le interesa.
(para aclarar, ese script no está basado en autoconf / m4, es un script simple que convierte configure --with-feature=value en una llamada a cmake -DFEATURE=value , con un poco más de pulido).

LAPACK ni siquiera usa configure, y estoy de acuerdo en que probablemente sería una molestia mantener un sistema basado en autoconf / automake / configure concurrente con cmake, con las herramientas automáticas en constante "evolución" y siendo dependientes de macros m4 y todo eso.

Me preocupa pasar a CMAKE porque, no solo no sé cómo usarlo, no sé cómo mantenerlo.

Esta es una de las principales razones para ceñirse a Makefiles.

Todos: Por favor, exprese su opinión en este hilo.

La construcción de Meson debe eliminarse. Nadie lo está usando, nadie sabe cómo mantenerlo, el autor original envió una compilación incompleta y nunca regresó después de que se fusionaron sus cambios. ¿Cuántas personas sabían que había una compilación de Meson antes de que abriera este número?

CMake es un sistema de compilación portátil con sintaxis simple y compilaciones totalmente configurables. Se pueden establecer opciones específicas del archivo, del compilador o específicas del destino (por ejemplo, para habilitar selectivamente funciones que no están en la biblioteca estándar de C como gethostname() ). CMake tiene una sólida gestión de archivos de objetos; esto le permite seguir escribiendo make para actualizar sus compilaciones incluso si cambió las ramas de git. CMake interactúa muy bien con el resto del ecosistema UNIX: puede llamar a programas arbitrarios y actuar sobre su salida. Por ejemplo, puede llamar a pkg-config para localizar otros paquetes.

La primera vez que usé CMake fue en 2016 y lo he usado continuamente desde entonces para compilar código para sistemas Linux, Mac, iOS y Android, en arquitecturas de conjuntos de instrucciones x86, x86-64, armv7 y aarch64. Está disponible en todas las principales distribuciones de Linux y en todas las supercomputadoras a las que tengo acceso (Grid 5000, Jean Zay, JUWELS, GRICAD, Eagle II). Las supercomputadoras suelen tener varias versiones disponibles, incluidas versiones antiguas y muy recientes (3.18+). La única plataforma en la que tuve problemas con la disponibilidad de CMake es CentOS 7, pero siempre puedes descargar un tarball de CMake y usar el script de arranque dentro del tarball para construir CMake solo con GNU Make.

CMake simplemente funciona para mí.

Mi experiencia con otros sistemas de compilación es la siguiente:

• Bazel: un gran consumidor de memoria, imposible de ejecutar en una Raspberry Pi con 1 GB de memoria, insiste en construir todas las dependencias y vincular todo estáticamente
• Autotools: como desarrollador sin experiencia, como usuario, el script configure es muy conveniente porque puede mostrarle todas las opciones disponibles (CMake hace eso con ccmake solo después de ejecutar cmake una vez).

Hoy, estoy a favor de CMake por una única razón: CMake hace un buen trabajo generando archivos Ninja en lugar de Makefiles. Ninja compila PaRSEC dos o tres veces más rápido que Make -j.

Genial, Ninja no pudo compilar Fortran en el pasado, cf. ninja # 1265 , es decir, en algunas distribuciones esto no funcionará (¿Debian 9?).

Definitivamente diría que los archivos MAKE regulares son más fáciles y suficientes en este caso.
Mantenimiento de software en un clúster de HPC Estoy muy decepcionado con los usos de Cmake.

1. Los desarrolladores tienen dificultades para seguir los esquemas de nomenclatura estándar, lo que dificulta la construcción debido a la lectura excesiva de documentación. Cada paquete hace algunos "retoques" de nombres que se ajustan a sus proyectos. Terminando así en esquemas de nomenclatura no estándar. (un poco cierto para autoconf +, pero aquí las cosas se han estandarizado más)
2. Cuando algo se rompe en cmake, se requiere un experto en cmake para depurarlo, todavía me cuesta mucho depurar cosas ... :(
3. Archivos de configuración difíciles de usar (no make.inc ), esto obliga a que todas las opciones de construcción se especifiquen en la línea de comandos en el momento de la compilación.

Por otro lado, cmake también hace cosas buenas:

1. Soporte de Windows más sencillo
2. Más manejo automático de dependencias e inclusión de archivos cmake para otros proyectos (este es un buen beneficio)

Sin embargo, para el sistema de compilación muy simple de LAPACK, no creo que haya algo bueno y malo. El sistema de construcción actual ha funcionado durante décadas y la gente está acostumbrada.
Además, para una construcción paralela rápida, esto podría agregarse trivialmente al sistema actual de archivos MAKE ...

Realmente no tengo una preferencia, pero debería quedar absolutamente claro qué opciones son compatibles con qué sistema de compilación si se admiten más ...

Siento que estoy en una situación similar a la tuya @langou .

No sé cmake. Solo logré usarlo para este proyecto porque toda la configuración ya estaba en su lugar y al abrir la configuración de travis y copiar y pegar las líneas que ejecuta. No creo que sea solo porque no tenga experiencia. Un Makefile es un poco menos mágico y se siente más bajo. Eso es algo que probablemente resuena con el tipo de personas que tienden a trabajar en este proyecto.
Si fuera solo para mi uso personal, seguiría usando gmake, pero luego tendríamos que poner todas las características que actualmente solo están disponibles en cmake en el Makefile. Especialmente un objetivo de biblioteca compartida.

Sin embargo, no puedo ignorar todas las buenas características que parece ofrecer cmake. En última instancia, creo que cmake o gmake funcionarán bien. Solo tenemos que elegir uno.

Soy una voz externa, pero como alguien que ayuda a mantener lapack en conda-forge , tener el sistema de compilación CMake tendría varias ventajas (menos hacky , soporte nativo de Windows, etc.).

Se necesita algo de tiempo para acostumbrarse a la sintaxis de CMake, pero mi impresión es que es un software bien mantenido y bien documentado que ha resuelto / abstraído con éxito muchos problemas complicados de construcción. También estoy involucrado en empaquetar otras bibliotecas y (subjetivamente) veo cada vez más un cambio a CMake.

Solo otro punto de datos del exterior; en nuestro trabajo que involucra bastante construcción de C / C ++, nos estamos moviendo a Meson después de luchar demasiado con CMake. La larga lista de problemas está bien documentada en otros lugares, así que me los estoy saltando.

En el proyecto SciPy también intentaremos usar CMake o Meson en algún momento ya que Python distutils está siendo retirado.

Estoy de acuerdo en que mantener tres sistemas de construcción genera inconsistencias y / o trabajo adicional para los encargados del mantenimiento. Sin embargo, según los comentarios anteriores y en mi opinión, cada usuario tiene su propia forma de crear el código. Particularmente, estoy de acuerdo con el comentario de @therault :

Somos programadores / matemáticos / hacemos algoritmos ... Dedicar tiempo a entender por qué en esa máquina, con esta combinación de compiladores y banderas, el código no se compila correctamente, eso a nadie le gusta. Peor aún, tratar de encontrar cómo hacer esa cosa u otra usando CMake o autoconf te hará subir la pared :) Trabajando con ambos, puedo garantizar que te quejarás de los dos :) Mantener uno solo es una forma segura de quejarse dos veces menos.

Una idea para evitar el problema con varios sistemas de compilación es:

• Cree más configuraciones en el CI para que cubra todos los sistemas de compilación compatibles. De esta manera garantizamos que todos los sistemas de compilación funcionan con las características básicas.
• Presente todo y sugiera el uso de uno de los sistemas de compilación en el archivo README. Ej .: _ Sugerimos el uso de CMake si necesita construir bibliotecas compartidas y estáticas, ..._, como lo mencionan @ martin-frbg, @ christoph-conrads y @thijssteel en este hilo. (No sabía que existía el sistema de compilación Meson en el repositorio. Creo que deberíamos agregarlo en el archivo README o dejar de mantener esta opción).

Hasta donde tengo entendido, el problema con la bandera recursive tiene que ver con las rutinas de prueba xeigtstz (ver https://github.com/Reference-LAPACK/lapack/issues/335# número comentario-485021575). Cuando se solucione este problema, mi opinión es que decidiremos si

1. agregue la bandera a la configuración predeterminada de CMake y donde sea que falte, o
2. elimine la bandera de los archivos make.inc.* .

Ligero malentendido wrt -frecursive Creo que esto es necesario para el funcionamiento correcto del código multiproceso, por lo que no debe eliminarse de los archivos de compilación en general. Sin embargo, un efecto secundario es que coloca matrices locales en la pila, que resultan ser extremadamente grandes en el caso xeigtstz. Eliminar esta opción de (solo) el Makefile TESTING / EIG parecería ayudar en el caso simple, pero parece estar implícito cuando se compila con `-fopenmp ', por lo que esta no es una solución general para los requisitos de límite de pila inusualmente grandes de esa prueba.

así que aquí está el por qué.
Estoy de acuerdo en que LAPACK es una biblioteca "simple": tener un sistema de creación debería ser suficiente, y fue suficiente durante mucho tiempo.
Pero pero pero ... hay Windows ... y solo por Windows, tuvimos que traer cmake. Originalmente, la gente de CMake trabajaba en la configuración, pero ahora creo que estamos solos y, como @langou , en realidad no lo estamos dominando.
Ahora la mayoría de los softwares basados ​​en LAPACK están usando Cmake y sabemos por los comentarios de nuestros usuarios que les gusta.

Entonces, si tenemos que elegir un sistema de construcción: este tiene que ser Cmake ... desafortunadamente para el presente pero afortunadamente para el futuro.

Mi voto: seguir los consejos de @abouteiller y @ @therault y tener un solo sistema de compilación, por lo tanto, cmake.

Ahora la mayoría de los softwares basados ​​en LAPACK están usando Cmake y sabemos por los comentarios de nuestros

Abrí este número y propuse tener un solo sistema de compilación. Mi suposición fue que las habilidades de Makefile y CMake se distribuyen de manera uniforme. Por favor, corrija si me equivoco, pero mi impresión es que esto no es cierto entre los colaboradores habituales de LAPACK : los Makefiles parecen ser populares y el conocimiento de CMake parece no ser fuerte. Además, después de dos días de discusión, las banderas -frecursive son aparentemente la única diferencia entre la compilación de CMake y Makefile y el hecho de que solo se usa CMake en Travis CI. No tiene sentido forzar un sistema de compilación que haga felices a los usuarios si ahuyenta a los contribuyentes principales.

(Mi juicio sobre quién es un colaborador habitual se basa en mirar las primeras cinco páginas de las solicitudes de extracción aceptadas).

De acuerdo ... Por cierto, los indicadores recursivos están en las configuraciones predeterminadas de CMake y Makefile con # 492. Entonces, creo que solo necesitamos incluir la compilación Makefile en Travis CI.

El PR # 500 mitiga las inconsistencias entre los sistemas de compilación Makefile y CMake que se informan aquí. Ver https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244

Hola @ilayn. Gracias por la información de Meson / CMake / Makefile. Es genial tener comentarios externos y obtener información sobre lo que están haciendo otros proyectos. No podemos admitir los tres sistemas y preferimos CMake y Makefile por ahora, por lo que es probable que desmantelemos Meson. No digo que nunca usaremos Meson, pero por ahora, no tenemos el recurso para mantenerlo. Esta es mi opinión. Creo que pronto presentaremos un PR para el desmantelamiento de Meson. Julien.