C++11 : Jenkins et ses slaves, Travis
Pour l'instant tous les dév C++11 sont sur la branche c++11. Avant de passer sur master, il faudra que nos systèmes d'intégration continue prennent tout cela...
... et ce n'est pas si facile: par exemple, sur Travis, le gcc par défaut est 4.6 Voir http://gearchicken.com/wordpress/?p=105
(copié depuis tâche C++11) Mikaël : CentOS 6 (maintenue jusqu'en 2017) embarque gcc 4.4 qui a un support limité de C++11 (pas de lambda fonctions par exemple) : https://gcc.gnu.org/gcc-4.4/cxx0x_status.html
Mathieu: Oui... et on trouvera plein d'autres systèmes stables sans bon support C++11. Je propose qu'on ne revienne pas sur la décision : on va basculer sur C++11. Par contre, il faut trouver un moyen correct d'avoir notre intégration continue.
Trois solutions :
- on arrive à installer un gcc correct sur CentOS 6 : http://www.necessaryandsufficient.net/2014/07/c11-on-centos/
- on met plutôt un slave CentOS 7
- on enlève CentOS des slaves !
Comment détecter s'il faut passer l'option -std=c++0x ou -std=c++11 au compilateur et le mettre automatiquement dans le Makefile ? Sur les différents slaves on n'aura pas forcément les mêmes versions des compilateurs (et ce n'est pas nécessairement souhaitable). Alors on pourrait, dans la config de Jenkins, mettre une option à la main. Mais ce n'est pas super portable et ça nécessite que l'utilisateur sache s'il doit passer l'option c++0x ou c++11 ce qui n'est pas gagné d'avance…
Bien sûr les autotools font ça :)
Mmm... si tu veux faire du autotoools (autoconf suffit ?), vas-y sur une autre tâche...
Notons que, sur un système très (trop) récent, il n'y a besoin d'aucun flag, héhé.
Sans mettre une option à la main, on ne peut pas tout simplement définir la variable d'environnement CXXFLAGS à la main sur chaque slave une fois pour toute ? Oui c'est manuel, mais de toute façon l'installation d'un bon gcc est aussi manuelle...
Sur quel système récent il n'y a pas besoin de flag ? Pour gcc 9.2 (dernière version stable), il faut toujours le flag. La version par défaut est c++98.
La variable d'environnement solutionnerait le problème pour les slaves mais pas pour les utilisateurs extérieurs utilisant le programme (savoir compiler un programme ne veut pas dire savoir quelle option passer à gcc).
L'utilisation d'autotools était une boutade. Mais c'est vrai que si on peut utiliser autoconf seul ça pourrait être intéressant : ce n'est pas la seule dépendance qu'on a (zlib, c++11, unzip, wget, tar).
Pour la gestion du flag C++11, une piste peut être de tester la version de gcc dans le Makefile : http://stackoverflow.com/a/5188472/1192742
Le module json n'a pas seulement besoin de C++11 mais d'un gcc >= 4.8 (mars 2013). L'inconvénient c'est que c'est très récent, l'avantage c'est que l'option de compilation est forcément -std=c++11
Remonté. Bloquant pour parser C+11.
(aïe, Travis est sur gcc 4.6.3 pour l'instant)
non, c'est bon, sur la branche c++11-new Travis est bien sur 4.8.1
Ubuntu 12.04 : c'est bon !
En s'inspirant de http://askubuntu.com/questions/271388/how-to-install-gcc-4-8
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.8 g++-4.8
### sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 50 ### pas fait !
puis make CXX=g++-4.8 (ou make CXX=g++-4.8 CXXFLAGS="-std=c++11" si on a enlevé d19e410f)
Les tests should passent (après enlevage de compilation, les flags ne passent pas dans make test)
Les derniers développements de Marc (parser, puis matrice distance) ont lieu sur c++11-new. Il faut merger à un moment.
Proposition :
- la release 2015.06 sera la dernière non - c++11
- en contrepartie, on va diffuser ensuite des binaires (- et... si on y tient, on pourrait toujours backporter des bugs sur 2015.06)
Implémentation :
- juste après la release 2015.06, on merge c++11-new.
- cela cassera certains slaves, on verra ce que l'on fait. Installer g++-4.8 dessus ou... supprimer des slaves. On supporte au moins les deux LTS Ubuntu en service, et on arrivera bien à supporter quelques autres.
« juste après la release 2015.06, on merge c++11-new. » Non. Ne garder que des slaves ubuntu a peu d'intérêt. C'est la diversité qui apporte de l'intérêt et permet de débusquer des bugs. Ça nous est arrivés plusieurs fois d'avoir certains slaves qui plantent mais pas tous.
Ne garder que des slaves ubuntu a peu d'intérêt
Tout a fait d'accord. On essaiera de mettre à jour d'autres slaves, le but est d'avoir de la diversté... Mon post d'avant n'était pas pour dire que c'était fini, juste que en y passant un peu de temps, on peut tout à fait installer g++-4.8 sur d'anciens trucs (j'ai pris la 12.04 exprès). D'où la proposition de faire cela en début de mois, après la release, on a un mois, ou même plus, pour mettre à jour les slaves (on a déjà vécu avec "all slaves" qui ne foncitonne pas 2 semaines !)
Je propose la motion "on ne fera pas de release suivante tant qu'on a pas réussi à configurer des slaves sur au moins 3 distribs différentes (ubuntu, xxx, xxx)". Les 3 différentes ne seront pas nécessairement les slaves actuels, on verra.
Autant passer « un peu de temps » avant le merge qu'après alors. Avoir un build cassé pendant 2 semaines n'est pas une situation normale.
Il faut aussi que les distribs soient suffisamment différentes (si c'est pour avoir Ubuntu, Debian et Linux Mint, ça n'apporte pas grand chose). freebsd, centos/fedora et ubuntu/debian semble un bon compromis. Je tiens particulièrement à freebsd qui n'est pas (trop ?) GNU à l'inverse des autres. Cela permet de nous alerter quand on utilise des choses spécifiques à GNU.
Si on arrive à avoir un compilateur plus récent (gcc 4.9) sur une distrib, ça serait bien aussi.
Mon gcc est en fait... "Apple LLVM version 6.0 (clang-600.0.56)" Un clang, si possible sans pomme, ce serait bien.
Oui ça existe aussi sous Linux, ça serait bien
ok. On résume :
au moins 3 distribs suffisament différentes : freebsd, centos/fedora et ubuntu/debian g++-4.8 idéalement un g++-4.9 et un clang quelque part
CentOS 6.3 : c'est bon, sur les deux slaves
wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
yum install devtoolset-2-gcc devtoolset-2-binutils devtoolset-2-gcc-c++
scl enable devtoolset-2 bash # Open a shell running devtools
(au passage, /etc/yum.repos/epel* ne marchaient plus, j'ai du les enlever temporairement le temps de faire cela)
Il y a déjà un clang (non utilisé) sur freebsd, ça peut être un bon client…
les nouveaux gcc installés sont-ils les compilateurs par défaut sur les slaves ?
non, il ne vaut mieux pas vu qu'on n'est pas les seuls à utiliser les slaves. Il faut forcer :
- CentOS : "scl enable devtoolset-2 bash"
- Ubuntu : "make CXX=g++-4.8"
Avec la mise à jour de freebsd (9.2) on a gcc4.8 (pas par défaut) et clang 3.3, compatibles C++11.
Au passage la mise à jour m'a affiché ce message pour gcc (à voir si c'est utile) : « To ensure binaries built with this toolchain find appropriate versions of the necessary run-time libraries, you may want to link using
-Wl,-rpath=/usr/local/lib/gcc48 »
Comment gérer le fait d'avoir des commandes différentes à rentrer pour compiler sur certains slaves ?
vu ensemble: suite de tests directement dans Jenkins
meccano: installé g++-4.8 (en suivant doc/algo.org, pas par défaut) Essayé de lancer avec "export CXX=g++-4.8", ne marche pas récursivement partout.
Bon, j'ai tout cassé avant de partir en we On a eu une après-midi où tous les jobs Jenkins refonctionnaient :-)
freebsd :
cd /builds/workspace/Vidjil (all slaves)/label/freebsd
gmake CXX='clang++ -stdlib=libc++' MAKE=gmake
gmake CXX='g++48' MAKE=gmake (ou g++49, installé aussi)
ne toruve pas iostream, ou d'autres choses
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193528 Ajouter l'option -D_GLIBCXX_USE_C99 dans les CXXFLAGS
debian squeeze : ok
doc/algo.org reflète ce qu'on a actuellement.
à voir si on supprime / déplace vers un autre job Jenkins les 2 slaves qui ne fonctionnent pas...
« Je propose la motion "on ne fera pas de release suivante tant qu'on a pas réussi à configurer des slaves sur au moins 3 distribs différentes (ubuntu, xxx, xxx)". Les 3 différentes ne seront pas nécessairement les slaves actuels, on verra. » On ne peut pas vraiment dire qu'on a 3 distribs différentes (ubuntu et debian sont très proches).
Certes... et c'était déjà le cas pour la release d'il y a trois mois...
Ok pour FreeBSD avec g++ (je n'arrive pas à compiler avec clang…). Fedora upgradé à Fedora 19 → passe avec g++ mais utilisation de clang 3.3 (pour la diversité)
8 mois après et 36 messages plus tard, on a fini !
Bravo pour l'excellence de cette intégration continue :-)