Café LoOPS sur Meson

La veille de la réunion, le mardi 5 septembre, LoOPS a tenu son premier café de 2017-2018. Le sujet était Meson, un système de gestion de configuration et de compilation. Il y avait environ 23 personnes dans la salle.

Meson effectue un travail similaire à celui de CMake et des Autotools. Il se destine principalement à des projets écrits dans des langages compilés (C, C++, Fortran…). Sa fonction est de s’assurer que les dépendances de compilation d’un programme sont présentes sur le système hôte, gérer des différences plus ou moins subtiles entre les configurations système supportées (ex: Linux vs OSX, Clang vs GCC, x86 vs ARM…), et générer en sortie des fichiers de configuration pour IDE (XCode et Visual Studio) ou des scripts de compilation (actuellement au format Ninja) permettant d’orchestrer la compilation proprement dite.

Au niveau des utilisateurs, Meson a rencontré un grand succès dans la communauté GNOME (environnement graphique pour Linux), et il est en cours d’intégration dans d’autres grands projets open-source (Xorg, systemd, Wayland/Weston) en tant qu’option de build secondaire. Pour l’instant, il a surtout du succès comme remplacement des Autotools, mais a plus de difficulté à convaincre les utilisateurs de CMake, outil plus récent et plus proche de Meson au niveau des fonctionnalités.

Voici un résumé des principales différences par rapport à CMake:

• L’outil est beaucoup plus jeune, ce qui a ses avantages (évolution rapide, équipe joignable et à l’écoute) et ses inconvénients (certaines fonctions sont peu matures, comme le support des IDE)
• La gestion de dépendances utilise le standard pkg-config plutôt que des scripts ad-hocs de plusieurs milliers de lignes.
• Si une dépendance n’est pas présente, Meson peut en option aller automatiquement la chercher, la compiler et l’installer.
• Les scripts de configuration sont faits pour être faciles à écrire et lisibles par la suite. Ils sont donc écrits dans un langage déclaratif simple, haut niveau, et volontairement non Turing-complet, avec une syntaxe d’inspiration Python.
• La configuration par défaut est optimisée pour une bonne performance de compilation via l’usage de Ninja, de CCache, des en-têtes précompilés; ainsi que l’interdiction d’utiliser des « wildcards » comme *.cpp qui sont pratiques mais ne passent pas à l’échelle.
• Cette configuration par défaut suit aussi un certain nombre de bonnes pratiques comme l’activation des diagnostics de compilateurs (-Wall) et l’usage d’un dossier de compilation dédié.
• Le support des analyses dynamiques de programmes comme la mesure de couverture de code, les « sanitizers » des compilateurs, ou Valgrind est plus poussé que dans CMake, qui se restreint essentiellement au support des builds de debug et des tests unitaires.

Le langage de script mérite quelques mots de plus, car c’est un des points les plus contentieux de la conception de Meson. Voici les principales choses qu’on peut en dire:

• Il est, dans sa syntaxe, inspiré par Python avec quelques changements mineurs pour adapter aux scénarios de compilation (par exemple, on utilise pour le formatage de texte le caractère @ plutôt que les accolades {}, ce qui réduit la nécessité d’utiliser des séquences d’échappement).
• Bien que Meson soit actuellement implémenté en Python, l’équipe se réserve la possibilité de basculer vers un autre langage si des contraintes comme la performance l’exigent. L’équipe essaie donc de ne pas exposer l’implémentation Python dans l’interface, y compris au niveau des scripts de configuration.
• Pour cette raison, et pour éviter de se retrouver face à des monstres tentaculaires de configuration comme ça peut arriver avec les langages Turing-complet comme le Python de SCons et Waf ou le pseudo-script shell de CMake, Meson essaie de s’en tenir à un langage de configuration minimaliste, qui ne fournit que ce qui est strictement nécessaire. L’import de modules Python arbitraire ou la génération de code de configuration à la volée n’est donc actuellement pas à l’ordre du jour.

Dans un contexte LAL, un autre point de comparaison possible était CMT. Par rapport à ce dernier, Meson met moins l’accent sur la possibilité d’effectuer des requêtes sur la configuration de compilation, et sur son origine. Par exemple, on pouvait dans CMT savoir de quelle dépendance provenait un certain paramètre de compilation, ce qui semble plus difficile voire impossible avec Meson.

Une suite de ce café LoOPS sera probablement proposée sous la forme d’un atelier Meson d’un jour en présence d’un ou deux développeurs de l’outil.

Événements à venir

XLDB

L’édition 2017 de la conférence XLDB, qui discute de grandes bases de données avec un accent sur les problématiques de physique des particules et d’astrophysique, se déroulera à Clermont-Ferrand du 10 au 12 octobre.

Cette conférence se déroule habituellement à San Francisco, mais elle a été organisée en France cette année en reconnaissance des contributions du LPC à l’infrastructure de bases de données de LSST.

Les participants actuellement pressentis sont Grigory, Adrien, Antoine et Christian (ce dernier étant financé par LSST).

Séminaire d’architecture matérielle

Hadrien fera une première présentation d’un séminaire d’architecture matérielle le mercredi 13/09 à 10h30. Le contenu sera principalement orienté vers un public de développeurs, mais peut aussi intéresser une partie du groupe exploitation, car il y a une forte synergie sur certains sujets comme la mesure des performances.

Le principe est de présenter en quoi les ordinateurs modernes s’écartent du modèle de Von Neumann qui est souvent utilisé dans l’enseignement de la programmation, pour quelles raisons, et par là même de dévoiler quelques grands principes pour l’obtention de bonnes performances logicielles sur le matériel moderne.

Si ça a du succès, il y a des évolutions possibles, par exemple une diffusion vers un publique plus large (IPN, webinaire RI3, traduction anglaise pour une utilisation au CERN), ou une évolution vers un format plus « TP » présentant quelques exemples classiques de programmes inefficaces et invitant l’apprenant à les optimiser grâce aux connaissances acquises et à des outils de mesure de performance modernes.

École de programmation fonctionnelle et Apache Spark

Christian est en train de préparer une double formation de programmation fonctionnelle et de traitement de données distribué avec Apache Spark. Cette dernière sera, à terme, gérée comme Action Nationale de Formation (ANF) du CNRS, mais pour la première édition, nous tirerons parti d’un créneau de formation de DevLOG qui a dû être annulé.

La formation se composera de deux parties de trois jours, administrativement indépendantes mais pensées pour former un tout cohérent. La première partie présentera des concepts de programmation fonctionnelle en Python ou Scala (langages préférés pour l’interaction avec Spark), et la seconde partie présentera le traitement de données avec Spark à proprement parler.

La première session devrait se tenir au LAL en janvier 2018. L’intervenant de l’école Apache Spark, très apprécié, sera rappelé, avec un budget temps plus confortable (3 jours au lieu de 2).

MOOC ANSSI sur la sécurité informatique

Philippe rappelle que l’ANSSI a récemment lancé un MOOC sur la sécurité de l’information, appelé « SecNum académie », qui sera en libre accès jusqu’à Avril 2019.

Peut-être de quoi faire un peu de concurrence francophone à l’excellent Introduction to Cyber-Security de FutureLearn, qui est souvent un brin trop britannique dans ses discussions légales!

Organisation des réunions

Antoine a profité de cette réunion pour relancer la question de l’ordre du jour. Par choix, les réunions Dev@LAL n’en ont pas, ce qui a des avantages et des inconvénients.

Un inconvénient qui a été mentionné par le passé est que les gens qui ne viennent pas aux réunions n’ont pas un mot à dire sur le contenu, mais on peut légitimement se demander si ils devraient en avoir un. Un autre travers de la parole spontanée est qu’elle favorise l’expression des individus bavards et à l’aise socialement, ce qu’on pourrait éventuellement contrer en ajoutant des règles de prises de parole, mais au prix d’une perte des avantages de la spontanéité.

La question de la valorisation des compte-rendus a été soulevés. Ces derniers demandent pas mal de travail, et on pourrait avoir envie de les diffuser à un public plus large, à définir. Par exemple à tout le SI, voire au-delà. Antoine avertit cependant qu’une diffusion trop large pourrait amener les personnes à surveiller davantage leurs paroles, et donc à perdre en spontanéité.

Au sein du groupe de développement, certaines personnes sont intimidées par le volume de texte. Pour cette raison, nous souhaiterions un format résumé, ce qui sort de la zone de confort d’Hadrien. Après quelques discussions, la parade a été trouvée: une extension WordPress peut générer automatiquement une table des matières des articles, qui pourra être jointe aux mails annonçant la publication du compte-rendu de la réunion. Serge a mis ça en place (merci!).

Philippe s’interrogeait sur les canaux de diffusion possibles pour des séminaires issues du service informatique, ce qui a soulevé quelques commentaires:

• Les cafés LoOPS ne devraient pas être des séminaires, mais des discussions. David a déjà fait face à des situations où une personne refusait d’organiser un café car elle avait le sentiment de « ne pas connaître le sujet assez pour en parler », et souhaiterait éviter que ce type d’auto-censure ne devienne la norme.
• Serge a rappelé qu’il est possible d’organiser des séminaires internes à l’échelle du LAL.
• Antoine a mentionné qu’en creusant la question du changelog automatique, il a découvert que c’était un sujet assez riche pour mériter un séminaire en soi.
• Christian a rappelé qu’il n’y a pas besoin d’être un grand expert pour présenter un séminaire, juste d’en savoir un peu plus que la moyenne.

Antoine voudrait aussi discuter prochainement de nouveaux outils d’analyse de code statique, comme le Better Code Hub, un outil d’analyse de qualité de code qui se branche sur l’API GitHub et compile différents indicateurs, un peu à la manière de Sonarqube:

• Longueur et complexité des routines
• Absence de duplication
• Simplicité des interfaces publiques
• Modules spécialisés et bien séparés
• Architecture équilibrée (pas de composant-dieu)
• Simplicité générale du code
• Tests automatisés et complets…