Re: Il etait une fois Transformers et la Build Farm... - Transformers

29 Aug 2006

(Copies envoyées aux listes projects et transformers du labo, pour
informer/faire participer les personnes concernées.)

SIGOURE Benoit &lt;sigoure.benoit(a)lrde.epita.fr&gt; writes:

...
  Yop

 Depuis deux jours, la BF ne build plus generic-tools. Y'a eu 3
 revisions depuis, et elle a toujours l'impression d'avoir builde la
 derniere revision (1566) alors qu'elle a 3 revisions de retard
 (generic-tools est bloque sur 1563).

 J'ai l'impression que c-tools et cxx-tools viennent de se bloquer
 sur la revision 1565. 
Arg.

...
  Sinon antalya ne build rien, alors qu'elle devrai
builder (entre autres)
 Transformers (et d'autres projs). 
Je pense que le cron-job est suspendu ; il faut qu'on voie avec
Geoffroy.

...
  Enfin je pense que j'ai trouve pourquoi certaines
revisions ne sont
 pas buildees par la BF. La build de Transformers prends assez
 longtemps (surtout le make check en fait) et si la build prends plus
 de 1 heure, les revisions commitees entre temps ne seront pas
 buildes. Ce qui pose probleme puisque la derniere rev ne sera
 buildee tant qu'un NOUVEAU commit ne sera pas fait. Je m'explique:

 Je commit la rev N.
 La BF commence a builder la rev N.
 Je commit la rev N+1.
 La BF build toujours la rev N... ca prends longtemps.
 Le crontab update les svn et passe donc a la rev N+1.
 La BF build toujours la rev N.
 Le crontab du worker se declanche et se rsync sur la derniere copie
 de travaille
 a la rev N+1.
 Mais le worker est encore en train de builder la rev N.
 La build de la rev N termine.
 La build de la rev N+1 n'aura jamais lieu car il n'y a pas d'update a faire:
 tout le monde est deja a jour, donc rien a rebuilder! 
Je ne suis pas sûr que ça fonctionne comme ça ; notamment, il me
semble qu'il existe un mécanisme (primitif) de verrou pour empêcher
la mise à jour de la copie de travail d'un worker pendant qu'il
compile.

Il faut qu'on se plonge dans les détails du script.

...
  Je pense que ca se passe comme ca ce qui fait que meme
apres
 plusieurs heures, la BF ne build pas les dernieres revisions.

 Cela dit quand des commits sont espaces sur plusieurs jours et que
 ca build toujours pas la derniere rev (comme c'est le cas pour
 generic-tools) je pense qu'il y a un autre probleme. 
Oui, je pense aussi.

...
  Voila pour finir je pense qu'on peu optimiser un
peu la build de
 "transformers" (le paquet complet). Le passage le plus long a l'air
 d'etre le make check de cxx-tools. On pourrait dire que
 "transformers" depends de generic-tools, c-tools et cxx-tools et
 demander a la BF de ne pas make distchecker "transformers" mais
 simplement de le make dist'er. En effet (P) si le make distcheck de
 generic-tools, c-tools et cxx-tools passe, alors le make distcheck
 de transformers passera, pas la peine de prendre plusieurs heures a
 le re-tester. La proposition (P) ne peut etre fausse que si un
 fichier necessaire au top-level de transformers n'est pas distribue,
 hors le top-level de transformers est vraiment vide, il s'agit
 vraiment juste de gluer les 3 packages sous jacant ensemble. 
En fait, je proposerais bien l'inverse : compiler generic-tools,
c-tools et cxx-tools sans lancer les tests (ni `check', ni
`distcheck'), mais un faire un `distcheck' du paquet transformers
(voire un `check'). En effet, c'est le paquet transformers que vous
distribuez (et pas ses composants, individuellement), aussi les
tests devraient porter sur celui-ci, si on veut réduire leur nombre.

...
  Voila donc si c'est possible de faire ca, ca
economisera des heures
 de make distcheck pour rien. J'ai mis les make check en --verbose 0,
 mais faut savoir que avant ca prenait 5 heures. Je sais pas combien
 de temps ca prends maintenant en --verbose 0 mais surement plus
 d'une heure. Donc voila ca fait du temps de gagne. 
Ok, cool !

...
  Et puis compiler transformers apres
{generic,c,cxx}-tools c'est
rapide grace a ccache :D 
Oui !

...
  Bon sinon autre question: est-ce qu'on pourrait
effacer le dossier
 _build en cas de build successful? Les _build de
 {generic,c,cxx}-tools me prennent pres d'1Go (parfois plus) et tu
 sais que l'espace libre est rare sur mon / (bien que j'ai fait de la
 place). 
Dans le cas général, je ne sais pas si c'est une bonne chose à faire
(en fait, je suis preneur d'avis). En revanche, c'est quelque chose
qu'on peut mettre en place facilement par machine,

- soit dans une tâche lancée par cron (mais comme c'est asynchrone
  avec le build, ça risque de compromettre des compilations ; sauf si
  on utilise le verrou posé par le script de build, mais ça commence à
  tendre vers faire un édifice fragile...) ;

- soit à la fin du script warszaw (solution qui a ma préférence).

...
  Pour finir est-ce qu'on pourrait tenter de builder
(sans make check)
 transformers avec le compilo Intel? Pas besoin de faire aussi les
 *-tools ni de faire de make check, juste de faire une build pour
 voir si ca compile. 
Oui, sans problème. En revanche, il faut qu'on jette un oeil au statut
de ICC sur les machines de la build farm.  On peut peut-être essayer
de le mettre dans /lrde/dev/linux-x86. Cependant :

- mon expérience personnelle de l'installation de ICC me faire dire
  que c'est pas gagné ; en effet, j'avais installé ICC 9.1 dans un
  sous-répertoire de /work sur brasilia il y quelques temps[1] et il
  avait réussi à me coller également des fichiers dans /opt et dans
  $HOME...

- la toute dernière version de ICC, la 9.1 (nécessaire pour compiler
  TC, notamment), n'est pas encore disponible en version « non
  commercial » ; seule une offre « evaluation » est disponible sur le
  site d'Intel, et elle est limité dans le temps (un mois IIRC).

...
  L'ideal serait meme de faire intervenir cette
 build apres celle avec gcc et entre les deux de faire un find _build
 -name '*.o' -exec rm -f {} ';' pour que le make ne refasse que la
 compilation du binaire (et ainsi economiser le temps de compilation
 Stratego -> C qui est non negligable). 
Arg, tu veux modifier le build tree et le reconfigurer sans faire de
`distclean' avant ! C'est pas sain.  Le build ICC de Vaucanson est un
projet indépendant de celui avec GCC ; je propose de faire pareil avec
Transformers. Si c'est l'espace disque qui pose problème, on peut
supprimer les produits des builds entre chaque projet si nécessaire.

Notes: 
[1]   Le temps de la licence d'évaluation, en fait.