Une fois vos nouvelles fonctionnalités ajoutées à votre version locale de Metafor, il faut s'assurer que celle-ci fonctionne toujours sous Unix. Vous pouvez aussi avoir besoin de vous faire une version Unix pour lancer une série de calculs avec votre nouvelle version sur les stations. Dans ces deux cas, il faut transférer vos sources:

• Zippez vos sources (répertoires oo_meta, oo_nda) ⇒ dev.zip
• Transférez ce zip sur une station Unix (avec WinSCP, Filezilla, …).
• Ouvrez un terminal sur cette machine (avec Putty)
• Utilisez comp.py (si vous avez correctement configuré votre ~/bin voir + haut).
• Suivez les instructions à l'écran

A tout moment, il est possible de lancer la batterie de tests sur une des plateformes et de visualiser l'étendue des dégâts dans sa version de développement. Il est conseillé de lancer cette batterie régulièrement histoire de ne pas avoir trop de surprises lorsqu'il s'agira de fusionner sa version avec la version officielle.

La batterie de tests de Metafor DOIT être vérifiée à chaque modification du source avant la création d'une nouvelle version (commit).

Elle est multi-plateforme. Grâce à ça :

• On peut tester la validité des tests sur différentes plate-formes/compilateurs et donc s'assurer de la portabilité maximale.
• On peut quantifier les rapports de puissances en jeu (du genre cette machine est 2x moins rapide en moyenne que celle-ci) sur de vrais tests.

La procédure est assez simple pour éviter de passer plus de temps à lancer la batterie qu'à développer du code. Il suffit de compiler Metafor et lancer le script de batterie (dans oo_meta - batterie.py).

On suppose ici que Bacon/Gmsh/Triangle/Matlab/etc sont accessibles dans le PATH. Sous Windows par exemple, dans la fenêtre cmd, pour lancer la batterie avec 4 CPU :

cd oo_meta\oo_metaBin\bin\Release
python battery.py -j 4
[attendre]
python battery.py diff
[un fichier HTML ''diff'' est créé dans oo_meta/apps/verif]

Sous Unix, il est possible d'utiliser le script comp.py. Ce script automatise la procédure et permet, par exemple, de lancer Bacon sur une autre machine que celle sur laquelle on lance la batterie (ce n'est plus utile aujourd'hui puisque Bacon est installé sur toutes les machines).

Il faut le copier à partir de oo_meta/toolbox dans son ~/bin et ensuite le lancer

comp.py
[suivre les instructions du menu]

Le script dézippe vos sources, les compile et lance la batterie en arrière plan. A chaque étape, il vous envoie un mail pour vous tenir au courant de son avancement. Au final (en général après une nuit), on retrouve dans sa boite mail un résumé des éventuels problèmes.

Une fois qu'on a des beaux développements qui marchent bien et qui vont vite, il est certainement temps de penser à “commiter ses trucs”, c'est-à-dire de fusionner sa version de développement avec la version officielle. Pour ce faire, il suffit de suivre ces points :

• Faire un “svn update” pour être à jour et gérer les éventuels conflits.
• lancer la batterie sur toutes les machines (linux-32, linux-64, PC).
• Récolter les temps cpu et mettre à jour le tableau des temps CPU si nécessaire.
• Vérifier que vous avez “svn add/remove” tous vos nouveaux fichiers ou les fichiers que vous avez supprimés.
• Faire un “svn commit” (sous Windows).
• Commiter les fichiers verifs de la batterie sous linux : dans le répertoire oo_meta/apps/verif/.
  • “svn commit *-Linux64-icc.txt” (blueberry)
  • “svn commit *-Linux64-gcc.txt” (gaston)
• Ecrire une petite page web sur ce site pour informer les autres.

Pour plus de détails sur comment commiter de façon systématique, il existe un document: Mémos de PP.