Aujourd'hui, Transformers compile intégralement sur la build farm (sur
IA-32), de même que Vaucanson (sur IA-32) et le projet Tiger (sur
IA-32 et Sparc 64). C'est la fête !
Merci à Geoffroy et à Tsuna pour leur aide !
>>> "Roland" == Roland Levillain <roland(a)lrde.epita.fr> writes:
> We now use Nix from /lde/dev/<arch>/nix instead of maintaining our
> copy of Stratego/XT.
Very nice!
(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.
On 2006-08-24, Nicolas Pouillard <nicolas.pouillard(a)gmail.com> wrote:
> On 8/24/06, Roland Levillain <roland(a)lrde.epita.fr> wrote:
>> Tsuna <tsuna(a)warszawa.lrde.epita.fr> writes:
>>
>> > On 2006-08-23, Roland Levillain <roland(a)lrde.epita.fr> wrote:
>>
>> [...]
>>
>> >> + # If it fails, extract a fresh copy of the project.
>> >> + if test $? -ne 0; then
>> >> + rm -rf "$package.new"
>> >> + svn checkout -q "$url" "$package.new"
>> >> + mv -f "$package" "$package.old"
>> >> + mv -f "$package.new" "$package"
>> >> + rm -rf "$package.old"
>> >
>> > j'aurai verifie que svn checkout marche ou fait un truc du genre:
>> > svn checkout -q "$url" "$package.new" && \
>> > mv -f "$package" "$package.old" && \
>> > mv -f "$package.new" "$package" && \
>> > rm -rf "$package.old"
>>
>> Oui, mais bof. Sans un système qui permet de vérifier le comportement
>> de update_unpacked (logs, envoi d'e-mail au mainteneur de la build
>> farm, etc.) ça ne change pas grand'chose.
>>
>> Et a priori, `svn checkout', ça marche dans tous les cas (à la
>> différence de `svn update'), surtout lorsque le répertoire cible a été
>> supprimé juste avant. En fait, il faut comprendre que `svn checkout',
>> c'est juste une solution lorsque `svn update' ne marche plus. Il
>> faudrait vraiment que le build maintainer soit averti lorsque les deux
>> ne fonctionnent plus (ce qui est rare).
>
> Si il n'y a plus besoin svn update il n'y a peut être plus besoin
> d'une working copy ?
> Dans ce cas un svn export serais plus efficace.
>
Si si on fait des svn up pour avoir des mise a jour incrementielles et ne pas
bourriner trop le serveur SVN. Dans certains cas malheureusement, la working
copy se lock, et alors dans ce cas seulement, on la rm et puis on re checkout.
--
SIGOURE Benoit aka Tsuna
_____
/EPITA\ Promo 2008.CSI Rock & tRoll
On 2006-08-23, Roland Levillain <roland(a)lrde.epita.fr> wrote:
> We now use Nix from /lde/dev/<arch>/nix instead of maintaining our
> copy of Stratego/XT.
>
>
> 2006-08-17 Roland Levillain <roland(a)lrde.epita.fr>
>
> Index: buildfarm_worker/marvejols.fns
>===================================================================
> --- buildfarm_worker/marvejols.fns (revision 296)
> +++ buildfarm_worker/marvejols.fns (revision 297)
> @@ -1,28 +1,20 @@
> +# Add Nix binaries to the path.
> +export PATH="/home/build/.nix-profile/bin:$PATH"
> +# Add some programs from /lrde/bin to the PATH.
> +export PATH="/lrde/dev/linux-x86/sarge/autoconf-2.60/bin:$PATH"
> +export PATH="/lrde/dev/linux-x86/sarge/bison-2.2/bin:$PATH"
>
Ajouter juste ~/.nix-profile/bin au PATH est pas forcement super, le mieux
c'est de sourcer /nix/etc/profile.d/nix.sh, au moins ca creer le
~/.nix-profile si il existe pas. L'avantage c'est que nix.sh exporte aussi
d'autres variables (ou pas) enfin bref, autant le sourcer...
--
SIGOURE Benoit aka Tsuna
_____
/EPITA\ Promo 2008.CSI Rock & tRoll