Table of Contents

Transfert des nouveaux développements sous Unix

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:

Vérifier la batterie de test

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 :

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.

Commit

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 :

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