(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.
