(Copies envoyées aux listes projects et transformers du labo, pour informer/faire participer les personnes concernées.) SIGOURE Benoit <sigoure.benoit@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.