Lapack: Construire des systèmes

Pour ajouter à la liste, les builds CMake actuellement (semblent) prendre en charge l'option de construire uniquement certaines parties de la bibliothèque (REAL, DOUBLE, COMPLEX et/ou DOUBLE COMPLEX), contrairement aux builds Makefile uniquement. (J'ai modifié les Makefiles dans la copie que nous distribuons avec OpenBLAS et je pourrais produire un PR si vous le souhaitez - il faudrait rediffuser pour omettre certains changements non pertinents ici)

Les builds CMake actuellement (semblent) prendre en charge l'option de construire uniquement certaines parties de la bibliothèque (REAL, DOUBLE, COMPLEX et/ou DOUBLE COMPLEX)

Cette option a fonctionné la dernière fois que je l'ai essayée (vers mai 2020).

Le build CMake a plusieurs options, je liste les plus importantes pour moi ici :

• construire des bibliothèques partagées ou statiques
• tests activés ou désactivés
• Index 64 ou 32 bits
• builds optimisés et de débogage
• options pour la bibliothèque génératrice de matrices (TMG), utilisation d'autres bibliothèques BLAS, BLAS++, LAPACK++...

Bonne idée. Les builds qui fonctionnent sur ma machine avec make mais pas sur le ci avec CMake m'ont rendu fou à plusieurs reprises.

Techniquement, je pense que le Makefile prend également en charge beaucoup de ces options (vous pouvez simplement éditer votre make.inc). Si vous voulez une compilation sans les tests, vous pouvez la compiler avec make lib . Mais surtout, la construction d'une bibliothèque partagée n'est pas prise en charge. La plupart des gens utilisent LAPACK comme bibliothèque partagée, ce qui fait de CMake le grand gagnant pour moi.

Si nous finissons par y aller, je suggère que nous ajoutions des instructions de construction supplémentaires au fichier readme. Comment construire et exécuter les tests, comment ajouter des drapeaux, en particulier le drapeau frécursif. Peut-être même une petite note sur la façon d'utiliser la bibliothèque partagée.

Je soupçonne qu'il y aura déjà de nombreux correctifs (par exemple dans les distributions Linux qui emballent lapack) pour créer des bibliothèques partagées avec gmake. Ne devrait pas être trop compliqué d'ajouter une option BUILD_SHARED à make.inc comme le BUILD_DEPRECATED qui est déjà là (et les deux sont assez obscurs dans le build CMake à moins que l'on sache déjà que ccmake et cmake-gui existent).

Ne devrait pas être trop compliqué d'ajouter une option BUILD_SHARED à make.inc comme le BUILD_DEPRECATED qui est déjà là (et les deux sont assez obscurs dans le build CMake à moins que l'on sache déjà que ccmake et cmake-gui existent).

Il n'est pas nécessaire de travailler avec ccmake pour définir l'une de ces options. Vous pouvez utiliser la ligne de commande similaire au script configure généré par 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

Vous pouvez certainement le faire, mon point est qu'il n'y a pas de documentation évidente à part la lecture du fichier CMakelists.txt (alors que le README pointe vers les fichiers make.inc préconfigurés pour gmake). ccmake et cmake-gui affichent une liste des options disponibles, mais cela sera perdu pour tous ceux qui découvrent cmake.

Si nous écrivons une documentation sur la façon d'utiliser CMAKE, nous pouvons m'utiliser comme utilisateur cobaye puisque je n'ai jamais utilisé CMAKE.

En lisant toute la conversation, j'ai l'impression que le Makefile dans LAPACK n'est là que pour moi. ;)

Eh bien, je ne sais pas.

Oui : le maintien de plusieurs systèmes de build conduit à des incohérences. Donc je vois l'argument pour n'en avoir qu'un. (Que ce soit CMAKE, make ou meson.) (Oh oui, je n'ai jamais utilisé de meson non plus, si vous vous le demandez.)

Je m'inquiète de passer à CMAKE car, non seulement je ne sais pas l'utiliser, mais je ne sais pas comment l'entretenir. Cependant, il semble que nous ayons une merveilleuse communauté qui peut aider, donc ne pas pouvoir travailler sur cette partie du projet ne semble pas un problème, en plus, je devrais probablement apprendre CMAKE.

Tous : Veuillez exprimer votre opinion dans ce fil.

Il semble que la plupart d'entre nous aimerions (1) supprimer make et remove meson; (2) passer à CMAKE uniquement ; (3) ajouter une bonne documentation sur la façon d'utiliser CMAKE. Ça va pour moi.

Je vais envoyer quelques e-mails à d'autres responsables de paquets ici et là pour leur demander comment ils vont et quelle est leur opinion sur cette question.

@martin-frbg : comment ça se fait dans OpenBLAS ?

OpenBLAS a Makefiles comme système de construction "traditionnel" qui est "connu pour fonctionner", et CMAKE comme alternative à l'origine fournie par l'utilisateur qui crache toujours un avertissement indiquant que les fichiers qu'il génère peuvent ne pas correspondre exactement à ce qu'une construction Makefile ferait.
Je n'aime pas beaucoup CMAKE, mais j'ai appris à créer des fichiers de construction cmake fonctionnels (bien que parfois peu orthodoxes). À mon avis, les Makefiles devraient rester (et je pense que gmake est toujours plus répandu que cmake). Je ne connais pas l'historique du support des mésons - _si_ c'était une contribution unique "jetée par-dessus la clôture" que personne ne connaît ou ne se soucie assez de tenir à jour, je suppose qu'il est inutile de la garder.

Je ne connais pas l'historique du support des mésons - s'il s'agissait d'une contribution unique "jetée par-dessus la clôture" que personne ne connaît ou ne se soucie assez de tenir à jour, je suppose qu'il est inutile de la garder.

La construction Meson a été parachutée dans LAPACK dans PR #311.

Hum. S'il était accepté dans la 3.9.0 (même s'il s'agissait simplement d'une preuve de concept), il semblerait un peu étrange de le rejeter à nouveau avec la toute prochaine version...

J'ai contacté @therault pour qu'il nous donne son avis, voici ce qu'en dit

Open MPI utilise uniquement autoconf (automake, autoconf, configure, Makefiles).

Pour PaRSEC et DPLASMA, nous n'utilisons que CMake, et pour aider les utilisateurs habitués à configurer, @abouteiller a réalisé un script qui utilise la syntaxe de configure et appelle CMake avec sa propre syntaxe.

Je connais un projet majeur qui a essayé de maintenir à la fois configure et CMake. Il a lentement évolué dans une situation où 100% des fonctionnalités étaient disponibles dans CMake, et de moins en moins de nouvelles fonctionnalités étaient prises en charge dans configure. Je crois qu'ils ont cessé de maintenir la version de configuration.

Maintenir deux systèmes de build pour un code est difficile : en théorie, le système de build devrait fonctionner avec n'importe quel code, et donc en maintenir deux devrait être possible (avec un coût élevé pour les mainteneurs, pour les garder synchronisés, c'est la raison pour laquelle le configure a été abandonné dans cet autre projet, le mainteneur a décidé qu'il avait mieux à faire avec son temps). En pratique, il est parfois nécessaire d'adapter le code au système de build pour rendre les choses plus propres. Lorsque cela se produit, l'un des deux systèmes de build doit utiliser des solutions de contournement et des hacks pour se comporter comme l'autre et conformément au code.

Au final, CMake ou configure, les deux vous décevront. Nous sommes programmeurs / mathématiciens / nous faisons des algorithmes... Passer du temps à comprendre pourquoi sur cette machine, avec cette combinaison de compilateurs et de drapeaux, le code ne compile pas correctement, personne n'aime ça. Pire, essayer de trouver comment faire telle chose ou telle autre en utilisant CMake ou autoconf vous fera grimper sur le mur :) En travaillant avec les deux, je peux vous garantir que vous vous plaindrez des deux :) Maintenir un seul est un moyen sûr de se plaindre deux fois moins.

Aujourd'hui, je suis en faveur de CMake pour une seule raison : CMake fait un bon travail pour générer des fichiers Ninja au lieu de Makefiles. Ninja compile PaRSEC deux à trois fois plus vite que Make -j. Maintenant, peut-être que configure/autoconf peut aussi générer des fichiers Ninja, je n'ai jamais essayé... Si vous n'avez jamais essayé ninja auparavant, et si LAPACK a une version CMake, je vous suggère d'essayer cmake -G Ninja (après avoir installé Ninja sur votre machine). Pour compiler, vous appelez 'ninja' dans le répertoire où vous avez exécuté cmake au lieu de 'make'. Vous verrez, c'est incroyable :)

Je suis heureux de contribuer à ce script de collage configure-to-cmake à LAPACK si cela vous intéresse.
(pour clarifier, ce script n'est pas basé sur autoconf/m4, c'est un script simple qui convertit configure --with-feature=value en un appel à cmake -DFEATURE=value , avec un peu plus de finition).

LAPACK n'utilise même pas configure - et je suis d'accord qu'il serait probablement pénible de garder un système basé sur autoconf/automake/configure concurrent avec cmake, les autotools eux-mêmes "évoluant" constamment et dépendant des macros m4 et ainsi de suite.

Je m'inquiète de passer à CMAKE car, non seulement je ne sais pas l'utiliser, mais je ne sais pas comment l'entretenir.

C'est une raison majeure de s'en tenir aux Makefiles.

Tous : Veuillez exprimer votre opinion dans ce fil.

La version Meson doit être supprimée. Personne ne l'utilise, personne ne sait comment le maintenir, l'auteur original a soumis une version incomplète et n'est jamais revenu après la fusion de ses modifications. Combien de personnes savaient qu'il y avait une version Meson avant que j'ouvre ce problème ?

CMake est un système de build portable avec une syntaxe simple et des builds entièrement configurables. On peut définir des options spécifiques au fichier, au compilateur ou à la cible (par exemple, pour activer sélectivement des fonctions qui ne sont pas dans la bibliothèque standard C comme gethostname() ). CMake a une gestion de fichiers objet robuste ; cela vous permet de continuer à taper make pour mettre à jour vos builds même si vous avez changé de branche git. CMake interagit bien avec le reste de l'écosystème UNIX : vous pouvez appeler des programmes arbitraires et agir sur leur sortie. Par exemple, vous pouvez appeler pkg-config pour localiser d'autres packages.

La première fois que j'ai utilisé CMake, c'était en 2016 et je l'ai utilisé continuellement depuis pour créer du code pour les systèmes Linux, Mac, iOS et Android, sur des architectures de jeux d'instructions x86, x86-64, armv7 et aarch64. Il est disponible sur toutes les principales distributions Linux et sur tous les supercalculateurs auxquels j'ai accès (Grid 5000, Jean Zay, JUWELS, GRICAD, Eagle II). Les supercalculateurs ont généralement plusieurs versions disponibles, y compris les anciennes versions et les très récentes (3.18+). La seule plate-forme sur laquelle j'ai eu du mal avec la disponibilité de CMake est CentOS 7, mais vous pouvez toujours télécharger une archive tar CMake et utiliser le script d'amorçage à l'intérieur de l'archive tar pour créer CMake uniquement avec GNU Make.

CMake fonctionne juste pour moi.

Mon expérience avec d'autres systèmes de build est la suivante :

• Bazel : un énorme cochon de mémoire, impossible à exécuter sur un Raspberry Pi avec 1 Go de mémoire, insiste pour construire toutes les dépendances et tout lier statiquement
• Autotools : en tant que développeur aucune expérience, en tant qu'utilisateur, le script configure est très pratique car il peut vous montrer toutes les options disponibles (CMake le fait avec ccmake seulement après avoir exécuté cmake une fois que).

Aujourd'hui, je suis en faveur de CMake pour une seule raison : CMake fait un bon travail pour générer des fichiers Ninja au lieu de Makefiles. Ninja compile PaRSEC deux à trois fois plus vite que Make -j.

Super, Ninja ne pouvait pas compiler Fortran dans le passé, cf. ninja #1265 , c'est-à-dire que sur certaines distributions cela ne fonctionnera pas (Debian 9 ?).

Je dirais certainement que les makefiles réguliers sont plus faciles et suffisants dans ce cas.
Maintenir le logiciel dans un cluster HPC Je suis très déçu des utilisations de Cmake.

1. Les développeurs ont du mal à suivre les schémas de nommage standard, ce qui rend la construction difficile en raison d'une lecture excessive de la documentation. Chaque paquet fait quelques "ajustements" de noms qui correspondent à leurs projets. Se retrouvant ainsi dans des schémas de nommage non standard. (un peu vrai pour autoconf+, mais ici les choses se sont plus standardisées)
2. Lorsque des trucs tombent en panne dans cmake, il faut un expert en cmake pour le déboguer, j'ai encore beaucoup de mal à déboguer des trucs... :(
3. Fichiers de configuration difficiles à utiliser (pas de make.inc ), cela force toutes les options de construction à être spécifiées sur la ligne de commande au moment de la construction.

D'un autre côté, cmake fait aussi des choses sympas :

1. Prise en charge simplifiée des fenêtres
2. Gestion plus automatique des dépendances et inclusion de fichiers cmake pour d'autres projets (c'est un avantage appréciable)

Cependant, pour le système de construction très simple de LAPACK, je ne pense pas qu'il y ait de bon et de mauvais. Le système de construction actuel fonctionne depuis des décennies et les gens y sont habitués.
De plus, pour une construction parallèle rapide, cela pourrait être ajouté de manière triviale au système de fichiers makefile actuel ...

Je n'ai pas vraiment de préférence, mais il devrait être absolument clair quelles options sont prises en charge par quel système de construction si d'autres sont prises en charge ...

J'ai l'impression d'être dans la même situation que toi @langou .

Je ne sais pas cmake. Je n'ai réussi à l'utiliser que pour ce projet car toute la configuration était déjà en place et en ouvrant la config travis et en copiant-collant les lignes qu'il exécute. Je ne pense pas que ce soit juste parce que je suis inexpérimenté. Un Makefile est un peu moins magique et se sent plus bas niveau. C'est quelque chose qui résonne probablement avec le genre de personnes qui ont tendance à travailler sur ce projet.
Si c'était uniquement pour mon usage personnel, je continuerais à utiliser gmake, mais nous devrons alors mettre toutes les fonctionnalités qui ne sont actuellement disponibles que dans cmake dans le Makefile. Surtout une cible de bibliothèque partagée.

Cependant, je ne peux pas ignorer toutes les fonctionnalités intéressantes que cmake semble offrir. En fin de compte, je pense que cmake ou gmake conviendra. Nous devons juste en choisir un.

Je suis une voix extérieure, mais en tant que personne qui aide à maintenir lapack dans conda-forge , le fait que le système de construction soit CMake aurait plusieurs avantages (moins de hacky , support natif de Windows, etc.).

Il faut un certain temps pour s'habituer à la syntaxe CMake, mais j'ai l'impression qu'il s'agit d'un logiciel bien entretenu et bien documenté qui a résolu / abstrait avec succès de nombreux problèmes de construction épineux. Je suis également impliqué dans l'empaquetage d'autres bibliothèques et (subjectivement) je vois de plus en plus une évolution vers CMake.

Juste un autre point de données de l'extérieur ; dans notre travail qui implique pas mal de construction C/C++, nous passons à Meson après avoir trop lutté avec CMake. La longue liste de problèmes avec elle est bien documentée ailleurs, donc je les saute.

Dans le projet SciPy, nous essaierons également d'utiliser CMake ou Meson à un moment donné, car Python distutils est en train d'être mis hors service.

Je suis d'accord pour que le maintien de trois systèmes de build entraîne des incohérences et/ou du travail supplémentaire pour les mainteneurs. Cependant, sur la base des commentaires ci-dessus et à mon avis, chaque utilisateur a sa propre façon de créer le code. En particulier, je suis d'accord avec le commentaire de @therault :

Nous sommes programmeurs / mathématiciens / nous faisons des algorithmes... Passer du temps à comprendre pourquoi sur cette machine, avec cette combinaison de compilateurs et de drapeaux, le code ne compile pas correctement, personne n'aime ça. Pire, essayer de trouver comment faire telle chose ou telle autre en utilisant CMake ou autoconf vous fera grimper sur le mur :) En travaillant avec les deux, je peux vous garantir que vous vous plaindrez des deux :) Maintenir un seul est un moyen sûr de se plaindre deux fois moins.

Une idée pour contourner le problème avec plusieurs systèmes de build est :

• Créez plus de configurations dans le CI afin qu'il couvre tous les systèmes de build pris en charge. De cette façon, nous garantissons que tous les systèmes de construction fonctionnent avec les fonctionnalités de base.
• Présentez tout et suggérez l'utilisation de l'un des systèmes de construction dans le README. Ex. : _Nous suggérons l'utilisation de CMake si vous avez besoin de créer des bibliothèques partagées et statiques, ..._, comme mentionné par @martin-frbg, @christoph-conrads et @thijssteel dans ce fil. (Je ne savais pas qu'il y avait le système de construction Meson sur le référentiel. Je pense que nous devrions soit l'ajouter dans le README, soit arrêter de maintenir cette option.)

Pour autant que je sache, le problème avec le drapeau recursive a à voir avec les routines de test xeigtstz (voir https://github.com/Reference-LAPACK/lapack/issues/335# questioncommentaire-485021575). Lorsque ce problème sera réglé, mon avis est que nous déciderons soit de

1. ajouter le drapeau à la configuration par défaut de CMake et partout où il manque, ou
2. supprimez le drapeau des fichiers make.inc.* .

Léger malentendu par rapport à -frecursive Je pense - cela est nécessaire pour le bon fonctionnement du code multithread, il ne doit donc pas être supprimé des fichiers de construction en général. Cependant, un effet secondaire est qu'il place des tableaux locaux sur la pile, qui sont extrêmement volumineux dans le cas xeigtstz. Supprimer cette option (uniquement) du Makefile TESTING/EIG semblerait aider dans le cas simple, mais cela semble être implicite lors de la compilation avec `-fopenmp', ce n'est donc pas une solution générale pour les exigences de limite de pile inhabituellement grandes de ce test.

alors voici le pourquoi.
Je suis d'accord que LAPACK est une bibliothèque "simple" - le simple fait d'avoir un système de fabrication devrait suffire, et cela a suffi pendant longtemps.
Mais mais mais.. il y a Windows.. et seulement à cause de Windows, nous avons dû apporter cmake. A l'origine, les gens de CMake travaillaient sur la configuration, mais maintenant je suppose que nous sommes seuls, et comme @langou , nous ne la
Maintenant, la plupart des logiciels basés sur LAPACK utilisent Cmake et nous savons d'après nos commentaires d'utilisateurs qu'ils l'aiment.

Donc si nous devons choisir un système de build : ce doit être Cmake... malheureusement pour le présent mais heureusement pour le futur.

Mon vote : suivre les conseils de @abouteiller et @ @therault et n'avoir qu'un seul système de build, donc cmake.

Maintenant, la plupart des logiciels basés sur LAPACK utilisent Cmake et nous savons d'après nos commentaires d'utilisateurs qu'ils l'aiment.

J'ai ouvert ce problème et proposé de n'avoir qu'un seul système de construction. Mon hypothèse était que les compétences Makefile et CMake sont réparties à peu près uniformément. Veuillez corriger si je me trompe mais j'ai l'impression que ce n'est pas vrai parmi les contributeurs réguliers de LAPACK : les Makefiles semblent être populaires et la connaissance de CMake ne semble pas forte. De plus, après deux jours de discussion, les drapeaux -frecursive sont apparemment la seule différence entre le build CMake et Makefile et le fait que seul CMake est utilisé dans Travis CI. Cela n'a pas de sens de forcer un système de construction qui rend les utilisateurs heureux s'il éloigne les principaux contributeurs.

(Mon jugement sur qui est un contributeur régulier est basé sur l'examen des cinq premières pages des demandes de tirage acceptées.)

D'accord .. BTW, les drapeaux récursifs sont dans les configurations par défaut CMake et Makefile avec #492. Donc, je pense que nous avons juste besoin d'inclure la version Makefile dans Travis CI.

PR #500 atténue les incohérences entre les systèmes de compilation Makefile et CMake signalés ici. Voir https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment-788164244

Salut @ilayn. Merci pour les informations Meson / CMake / Makefile. C'est formidable d'avoir des commentaires extérieurs et d'obtenir des informations sur ce que font les autres projets. Nous ne pouvons pas prendre en charge les trois systèmes et nous préférons CMake et Makefile pour le moment, nous allons donc probablement mettre Meson hors service. Je ne dis pas que nous n'utiliserons jamais Meson, mais pour l'instant, nous n'avons pas les moyens de le maintenir. C'est mon opinion. Je pense que nous soumettrons bientôt un PR pour le déclassement de Meson. Julien.