Je me suis lancé dans la mise en place d'un nouveau système de compilation pour le source Metafor. Il s'agit de CMake, le système qui est utilisé pour VTK et que j'ai déjà utilisé pour la compilation de stp2e.

CMake est analogue à autoconf sous Unix mis à part qu'il marche aussi sous Windows et qu'il est beaucoup plus moderne. Pour ceux qui ne connaissent pas autoconf, ce type de programme permet de générer des makefiles à partir de modèles et de paramètres spécifiques à la machine sur laquelle on veut compiler. Ces paramètres peuvent être des options de compilation, l'emplacement de bibliothèques, des choix sur les sources à compiler, etc.

Jusqu'à présent, puisque autoconf ne fonctionnait pas sous Windows, Luc mettait à jour un projet Visual Studio qu'il distribuait à tout le monde. Ce projet était une sorte de copie des makefiles générés par autoconf sous Linux. Malheureusement, modifier le projet Visual Studio se fait à la main et vu la complexité croissante du code, il devient de plus en plus compliqué d'assurer une concordance parfaite entre ce qui est fait sous Linux ou Windows. De plus, puisque c'est une opération manuelle à travers une interface graphique, il est très difficile de détecter des fautes.

En résumé, les avantages de CMake sont nombreux:

• Unification des projets Visual Studio et Makefiles Unix: le système CMake est multi-plateforme et peut générer toutes sortes de projets, dont ceux que nous utilisons aujourd'hui.
• A terme, plus besoin du projet de Luc.
• Le programme qmake n'est plus nécessaire sous Windows pour traiter la partie Qt de Metafor (qui s'est étendue aux libs de calcul depuis qu'on utilise les QSet). Ceci facilitera énormément la gestion du projet si quelqu'un améliore l'interface graphique Qt.
• Unification des options de compilation sous Visual Studio (avec le projet actuel, qui peut être sûr que les 45 projets actuels sous Visual sont configurés de la même manière, avec les mêmes options de configuration?).
• Possibilité de changer facilement de compilateur (Intel sous Windows?). J'ai en effet remarqué que passer d'un compilateur à l'autre sous Windows perturbe le projet Visual Studio (il y a des options qui “sautent”). Il est donc important de pouvoir générer 2 projets séparés à partir des mêmes sources. C'est la raison principale pour laquelle je me suis lancé dans ce travail vu mon projet de recherches (parallélisme - FABULOUS).
• Possibilité de générer des projets où certaines options sont désactivées (Metafor sans interface graphique, Avec ou sans solveurs PetSc/Pardiso, Metis, Compression zlib des facs, etc.). Plus tard, on pourrait gérer ainsi les différents modules de Metafor et les désactiver à la demande. Un exemple concret: cette année, j'ai refilé le mailleur Gen4 à B.Mersayeva pour un TFE et j'ai dû créer une solution complètement bidouillée et séparée du projet classique. Avec CMake, il aurait suffit de désactiver tous les modules sauf gen4 et le projet aurait été obtenu très facilement.
• Utilisation de règles d'includes limitées et dynamiques: dans chaque projet, seules les fichiers des libs utiles sont atteignables.
• Possibilité d'ajouter facilement des nouveaux modules. Ça m'intéresse tout particulièrement puisque je compte ajouter très prochainement une nouvelle lib pour le travail d'Arnaud Collet (modèles électro-mécaniques).

Actuellement, le travail n'est pas tout à fait fini (vous n'avez donc rien à faire!). Il ne fonctionne que sous Windows et l'exécutable n'est pas encore configuré pour pouvoir fonctionner correctement. Néanmoins, si certaines personnes veulent tester le système sur leur PC, qu'ils n'hésitent pas.

Procédure graphique:

CMake permet de séparer totalement le source des binaires (c'est pas obligatoire mais c'est recommandé). On va donc suivre cette manière de faire.

1. lancer CMake
2. spécifier oo_meta comme repertoire de source.
3. spécifier oo_metabin (ou autre) comme repertoire des binaires (ce répertoire peut être placé n'importe où, même sur un autre disque!).
4. lancer “Configure”
5. choisir sa plateforme (p. expl. “Visual Studio 2008 x64”)
6. spécifier manuellement tous les chemins que CMake n'a pas trouvé.
7. adapter les options (_WITH_GUI_, _WITH_MKL_, etc)
8. remoulinez tout (bouton “configure”) jusqu'à ce qu'il n'y ait aucune ligne rouge.
9. lancer la génération de la solution

Procédure automatique:

Comme vous pouvez le voir, la procédure de config est longue, surtout si CMake ne trouve pas automatiquement vos libs (sous Windows, il y a peu de chance qu'il y arrive). J'ai donc créé un fichier de config pour ma machine qui convient à tous ceux qui utilisent mes libs (Vinciane, Arnaud Collet et moi)

Sans le répertoire racine de oo_meta:

mkdir oo_metabin
cd oo_metabin
cmake -G "Visual Studio 9 2008 Win64" -C ..\oo_meta\profiles\garfield.cmake ..\oo_meta

et voilà, toutes les valeurs devraient être remplies et le projet créé! Si on veut à ce stade modifier une option, il est possible de lancer l'interface graphique.

L'idée est donc de faire un fichier de type garfield.cmake pour tous les types de machine. On aurait par exemple un corto.cmake pour les utilisateurs des libs de Luc. Les 3 lignes ci-dessus pourraient être facilement mises dans un petit fichier python qui se chargerait de déduire intelligemment la config à charger.

La suite:

• Adaptation du système sous linux.
• Adaptation de Metafor pour qu'il puisse retrouver l'emplacement des sources même s'il est situé loin de celles-ci (dans le répertoire des binaires).
• Suppression des fichiers autoconf.

Ajout de 2 tests du mailleur anisotrope

• apps.qs.gen4aniso1 : flexion 3 pts
• apps.qs.gen4aniso2 : pliage (tombé de bord)

— Romain BOMAN 2010/06/06 09:08