Using CMake for compilation

[cyrilbouvier]

Ce ticket sert à discuter du changement de waf à CMake comme système de compilation d'Ibex, comme cela a été discuté aux IbexDays 2019.

Prérequis

Les questions auxquelles ils faut répondre avant de faire le changement:

• Comment les plugins intéragissent avec le noyau Ibex ?
• Quels est le statut des opérateurs ? Plugin ou noyau ? Extensible par plugin ?
• ... (à compléter si nécessaire)

Méthode

Je vois deux façon de procéder au changement:

1. Faire une branche où l'on implémente tous et qu'on merge une fois que c'est terminé
2. Faire des changements progressifs dans la branche develop en faisant coexister CMake et waf tant que les scripts CMake ne sont pas terminés.

Je pencherai plutôt pour la deuxième façon, car s'il les changements prennent du temps, le moment où il faudra merger risque d'être compliqué. La deuxième façon permettrai aussi d'ajouter progressivement des tests pour CMake dans Travis afin d'éviter les regressions par rapport au reste du code qui continuera à évoluer.

Features

Voic une liste des features que doit posséder le système de compilation (obtenue en regardant ce que propose la compilation via waf actuellement (./waf --help) et des discussions des IbexDays 2019).
N'hésiter pas à compléter ou à en enlever si nécessaire.
J'ai mis des ❓ sur les features pour lesquels je ne sais pas si il faut les garder ou pas.

Les checkbox validées correspondent à ce qui est déjà fait dans la branche with_cmake_v2.6.5 du fork de @benEnsta (à vérifier, j'ai peut-être raté des features déjà implémentés)

• Compilation de libibex

  • détection des dépendences:
    • flex
    • bison
    • fmemopen
      
      ❓ plus de détails

      
      utilisé dans tests
      Dans la version CMake, il y a du code pour le détecter mais cela n'a pas l'air de marcher: il ne le détecte pas sur ma machine alors qu'il est dispo.
      Un fallback est dispo dans tests/3rd/fmemopen mais n'est pas utilisé par la version CMake
      La fonction fmemopen est utilisée dans trois tests (dont 1 qui pourrait utilisé un fichier), il serait peut être plus simple d'utiliser des fichiers temporaires pour les deux autres tests et enlever cette dépendence
    • cppunittest
  • compilation des sources en libibex.a ou libibex.so
  • tests
  • examples
  • benchmarks
    plus de détails

    Beaucoup de code python/waf pour gérer les benchs, cela risque d'être long/compliqué à traduire en CMake. Je vois deux possibilités: trouver un package CMake qui fait les benchs et adapter ce qui a été fait à ce package ou faire un script python qui fait les benchs (à partir de ce qui existe déjà) et que `make benchmarks` ne fasse que appeler ce script.
  • compilation en mode debug
  • obligation d'avoir c++11 ? (waf l'impose, pas les scripts CMake du fork)
  • flags (waf utilise std=c++11 -O3 -Wno-deprecated -Wno-unknown-pragmas -Wno-unused-variable -Wno-unused-function, les scripts CMake du fork utilisent les flags par défaut)

• Intégration des bibliothèques de calcul d'intervalles

  • gaol
    • utilisée par défaut ou via une option WITH_GAOL
    • possibilité de passer les chemins à CMake pour qu'il trouve la bibliothèque
    • installation automatique si aucune bibliothèque trouvée
  • filib
    • utilisable via une option WITH_FILIB
    • possibilité de passer les chemins à CMake pour qu'il trouve la bibliothèque
    • ❓ installation automatique si demandée et pas trouvée
  • bias
    • utilisable via une option WITH_BIAS
    • possibilité de passer les chemins à CMake pour qu'il trouve la bibliothèque
    • ❓ installation automatique si demandée et pas trouvée
  • direct
    • utilisable via une option WITH_DIRECT

• Intégration des bibliothèques de programmation linéaire (pour le plugin optim)
  Est-ce que cela doit être géré dans le fichier CMake principal ou par le plugin optim ? D'autres plugins utilisent-ils une bibliothèque de programmation linéaire ?

  • clp (pas d'install automatique pour l'intant)
    • utilisable via une option WITH_CLP
    • possibilité de passer les chemins à CMake pour qu'il trouve la bibliothèque
    • ❓ installation automatique si demandée et pas trouvée
  • cplex
    • utilisable via une option WITH_CPLEX
    • possibilité de passer les chemins à CMake pour qu'il trouve la bibliothèque
    • ❓ installation automatique si demandée et pas trouvée
  • soplex
    • utilisable via une option WITH_SOPLEX
    • possibilité de passer les chemins à CMake pour qu'il trouve la bibliothèque
    • ❓ installation automatique si demandée et pas trouvée
  • none
    • par défaut pas de bibliothèque de programmation linéaire

• distribution

  • création automatique de ibex-x.y.z-Source.tar.gz pour le download des sources (automatique avec CPack dans CMake)
  • création automatique de ibex-x.y.z-Linux.tar.gz pour le download de la bibliothèque précompilées (automatique avec CPack dans CMake)
  • création automatique de ibex-x.y.z.deb pour la distribution de paquets debian (devrait être facile à faire avec les outils CPack et CPackDeb de CMake)
  • compilation sous windows de ibex.dll et/ou ibexopt.exe et/ou ibexsolve.exe pour distribuer des exécutables pour windows (cf appveyor de la branche with_cmake et/ou CPack sous windows)
  • compilation des fichiers nécessaires à Pybex (Pybex est il un plugin ou intégré au noyau)

• plugins

  • Faut-il séparer les dépots ou pas ?
  • Chaque plugin doit-il ajouter ses sources au noyau (comme actuellement) pour créer libibex ou chaque plugin doit-il créer un binaire (ibexop, ibexsolve) ou une bibliothèque supplémentaire en utilisant libibex (par exemple libibex-sip)
  • Dans le cas où les plugins sont séparés, il faut créer des macros pour faciliter l'écriture des fichiers CMake des plugins.

• opérateurs

  • plugin ou dans le noyau ?
  • si dans le noyau, un utilisateur doit-il pouvoir ajouter des opérateurs via un plugin ?

[benEnsta]

Salut Cyril,

Merci pour la TODO list !!!

Juste quelques précisions:
La branche la plus à jour et plutôt celle-ci with_cmake. Il me semblait avoir corriger le problème avec fmemopen (à vérifier).
Sinon par rapport à la liste, les tests passaient sur toutes les architectures mais sans solveur linéaire et cppunit est installé automatiquement sous appveyor. Je vais aussi vérifier ça.

Pour flex et bison j'avais aussi ajouté la possibilité utiliser des fichiers déjà générés comme
generated_parser.cpp_ par exemple. Cela évite sous windows de dépendre de flex et bison. A voir si cette façon de faire peut convenir pour la suite.

SInon, Je suis aussi pour la méthode d'intégration numéro 2. Si j'ai le temps ce we, je vais essayer de faire une pull request avec le script cmake sur la branch develop pour servir de base.

[gchabert]

Salut les gars,
Super la TODO list Cyril et merci Benoit pour le boulot déjà fait !

• Pour les benchmarks: c'est pour un usage restreint (en gros : moi). Ça n'a même pas vocation à être diffusé avec ibex donc mon avis est de laisser les scripts python actuel et le dissocier complètement du cmake (vous vous évitez un gros boulot)
• flags : rien d'imposé du moment qu'en mode non-debug, on ait bien au moins -O3 pour l'optimisation du code.
• obligation d'avoir c++11: oui, on utilise désormais du c++11 dans le code
• bias: pas d'installation automatique si demandée et pas trouvée (gaol et filib suffisent amplement). Pas besoin non plus de l'inclure dans les tests automatiques.
• bibliothèque de programmation linéaire: elle doit bien être gérée par le fichier cmake principal. Son usage est au niveau du noyau (et pas restreint au plugin optim).
• clp: pas d'installation automatique si demandée et pas trouvée. Pas besoin non plus de l'inclure dans les tests automatiques.
• Pybex: il faut le voir comme un plugin, comme ibex-java (tout au moins comme un outil dissocié du noyau).
• plugins: j'ai peur qu'il faille séparer tous les dépôts si un système de version séparé est mis en place (c.a.d., les versions des plugins ont une numérotation à part) sinon on va très vite se mélanger les pinceaux avec git.
• Chaque plugin doit-il ajouter ses sources au noyau ou chaque plugin doit-il créer un binaire ? Je ne sais pas! Du moment que le link se fait sans difficulté côté utilisateur, toute solution convient je pense.
• opérateurs: du fait du parseur (qui doit être compilé en un seul bloc), je pense qu'ils sont à traiter à part. De même pour les librairies intevalles de base. Peut-être qu'il faut distinguer 'plugins' (compilés avec le noyau) et 'extensions' (formant des librairies séparées). Les 'plugins' regrouperaient les librairies intervalles, de prog. linéaire et les opérateurs.

Ce ne sont que mes suggestions :) A discuter si vous n'êtes pas convaincu.

[gchabert]

PS: Pour flex et bison, je suis d'accord avec Benoît, c'est une bonne idée pour l'utilisateur lambda d'utiliser les fichiers déjà générés plutôt que de lui faire installer flex/bison. Mais il faut aussi me laisser un moyen simple de continuer à développer le parseur ;-)

[SimonRohou]

Salut Gilles et les Ibexeurs,

Concernant les plugins (il faudrait utiliser un autre mot, disons package pour le moment), il y a deux usages à considérer :

• la partie bibliothèque (pour du dev)
• la partie utilisation

La première fournit les briques métiers du package et leurs headers. Par exemple, pour ibex-solve : la classe Solver ; pour Tubex, un contracteur sur un tube, etc. La seconde (optionnelle) fournit une utilisation de ce package sous forme d'exécutable. Par exemple pour ibex-solve, il s'agit de l'exécutable lié à main/ibexsolve.cpp avec interface minibex.

C'est un découpage classique. En terme de paquets, un développeur roboticien installera :
sudo apt install ibex-lib-dev ibex-solve-dev tubex-lib-dev
s'il souhaite développer un nouveau programme faisant intervenir des fonctions du solveur et des contracteurs sur les tubes. D'un autre côté, un physicien souhaitant uniquement résoudre un problème en utilisant le solveur via minibex lancera :
sudo apt install ibex-solve

Dans le premier cas toutes les bibliothèques nécessaires au développement du roboticien sont installées, avec les headers ; dans l'autre uniquement l'exécutable est demandé.

Je pense qu'il est plus simple d'associer un repo Git par projet (incluant la partie dev et éventuellement la partie utilisation si elle existe). Cela permet de faire clairement apparaître l'état de développement du projet, ses dépendances, les responsables du développement, les issues associées au dev, etc. La page ibex-team ferait donc apparaître tous ces packages.

Exemple d'organisation de dépôts dans la IBEX-team en imaginant les paquet .deb associés :

• ibex-lib (paquets .deb : ibex-lib, ibex-lib-dev)
• ibex-solve (paquets .deb : ibex-solve, ibex-solve-deb)
• ibex-opt (paquets .deb : ibex-opt, ibex-opt-dev)
• tubex-lib (paquets .deb : tubex-lib, tubex-lib-dev)
• etc.

Enfin je pense que les wrappers tels que pyIbex sont à placer dans chaque package à wrapper. Ainsi les développeurs d'un package sont responsables de la mise à jour de l'interface python de ce package.

NB1 : certains projets tels que le noyau d'IBEX (ou Tubex actuellement) sont de pures bibliothèques qui n'intéresseront que des développeurs. Les paquets permettant à un développeur d'utiliser ces librairies (avec accès aux headers) seraient ibex-lib-dev et tubex-lib-dev. Malgré tout, des paquets ibex-lib et tubex-lib (non dev) inclueront des shared libraries qui seront utilisées par des utilisateurs non développeurs. Par exemple, l'installation du paquet ibex-solve engendra l'installation du paquet ibex-lib afin que le solveur exécutable ait accès aux fonctions d'IBEX par la shared library présente dans ibex-lib.

NB2 : les éventuels exemples fournis avec des bibliothèques de dev (tels que ceux d'IBEX) n'ont pas forcément besoin de faire l'objet d'un "paquet utilisateur" si le but de ces exemples et d'illustrer l'utilisation des fonctions de la bibliothèque, plutôt que ses performances.

NB3 : il faudrait que le site web d'IBEX soit présent dans un dépôt Git de la IBEX-team, afin que chacun puisse contribuer à la documentation du site (mise à jour des références vers les publis, ajout de docs comme par exemple "comment compiler IBEX sur un système embarqué", etc.).

NB4 : il faudrait faire un dépôt Git vide d'exemple de package IBEX, et contenant les éléments de base à remplir en terme de CMake, structure soft, documentation, wrapper python, etc.

Qu'en pensez-vous ?

[amarendet]

Salut,

Je me permets juste de dire que je souscris totalement à ce que dit Simon pour l'organisation des plugins/extensions/packages.

• Cette organisation faciliterait le développement de plugins (et leur distribution), en introduisant une architecture classique et lisible par tout le monde,
• elle éviterait l'apparition de dépendances de core envers les plugins,
• elle établirait clairement les responsables de la maintenance des plugins, avec une équipe upstream clairement identifiée pour chaque plugin et pour le core,
• elle séparerait clairement la partie "utilisateur" de la partie "développeur", et encouragerait les développeur à fournir des documentations développeur et utilisateur appropriées pour leurs plugins sans reporter la responsabilité sur Gilles (je dis ça surtout pour moi ^^).

Les seuls désavantages que je vois sont :

• la nécessité d'une gestion de version pour le développeurs de plugins, mais cela devrait être géré facilement par les gestionnaires de paquets (ce qui implique potentiellement un léger surplus de travail pour les mainteneurs de plugins),
• une sorte de fragmentation du développement, mais en pratique aujourd'hui j'ai l'impression que plusieurs personnes développent des choses sur Ibex en utilisant les branches du dépôt Ibex-lib, donc autant utiliser des dépôts séparés.

[gchabert]

Salut Simon et Antoine,

Je souscris également à tout ce que vous dites.

Juste: Pour la doc, elle est déjà sous Github au format reStructuredText sous le répertoire doc/.
Pour info, je remplace dans le tar.gz de chaque release le contenu de ce répertoire par le HTML généré (sauf pour la release 2.8 où j'ai oublié de le faire ...). Par contre, il n'y a pas tout le site web en effet et ce serait peut-être une bonne idée de le mettre quelque part sous Github. Mais cela suppose avant tout de le refaire au propre. Actuellement, c'est un dump très sale de pages HTML générées par Drupal (que j'ai du désinstaller suite à un piratage).
Gilles