29 Aug
2006
29 Aug
'06
10:51 a.m.
(Copies envoyées aux listes projects et transformers du labo, pour
informer/faire participer les personnes concernées.)
SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> 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.