Aujourd’hui, pour la première fois depuis la separation entre blink / webkit, les équipes WebRTC de Google et Apple ont eu une session de travail. Comment cela a-t-il été possible? Qu’est ce que cela signifie pour WebRTC? Qu’attendre dans le futur de cette relation renouee. Jetons un coup d’oeuil à tout ça.

Lire la suite →

Les 9 et 10 septembre, une réunion commune intermédiaire des groupes de travail WebRTC et Device API du W3C s’est tenue au siège de Microsoft à Redmond.

Les réunions intermédiaires, également appelées réunions « face-à-face » (quand elles n’ont pas lieu en Chine…), sont des réunions plus petites et plus ciblées qui se déroulent entre les grandes réunions pleinières, avec un programme précis pour faire avancer les choses plus vite. Les réunions IETF (3 par an) sont longues et peuvent être épuisantes. Les réunions du W3C, ou plutôt « la réunion » sans ‘s’ puisque seul le TPAC est technique, sont aussi très longues, mais surtout elles n’ont lieu qu’une seule fois par an. Certains voudraient pouvoir prendre des décisions plus rapidement, notamment quand le programme déborde de nouvelles fonctionnalités demandées par WebRTC 1.0. Ces réunions intermédiaires permettent d’obtenir des retours d’expérience et de prendre des décisions qui sont difficiles voire impossible à prendre par e-mail.

Plus tôt cette année, le groupe de travail WebRTC est arrivé au bout du temps qui lui était alloué et a demandé une extension au W3C. L’extension a été accordée sous la condition que la convergence entre le travail du groupe WebRTC et celui du groupe ORTC devienne plus qu’une réalité. Erik L. (de Hookflash) est devenu un des présidents du nouveau groupe WebRTC et la convergence entre les spécifications a été accélérée.

Cette réunion était dédiée, en particulier, à mettre à jour la liste des fonctionnalités que nous devrions avoir dans la version 1.0 ou à laisser pour plus tard, afin d’avoir une vision claire avant TPAC (fin octobre au Japon), de telle sorte que la réunion du TPAC se résume à la validation des décisions prises et qu’elle s’achève avec une liste stable des fonctionnalités pour la version 1.0.

Beaucoup de nouvelles APIs ont été expérimentées au sein du groupe ORTC (qui était composé de nombreux membres du groupe WebRTC), et Peter T. de Google par exemple est venu avec beaucoup de propositions sur la manière de concevoir ces nouvelles APIs. Celles-ci n’étaient pas trop controversées, étaient relativement petites, et tout s’est bien passé. La plupart des sujets abordés et les présentations correspondantes sont maintenant disponibles ici.

Puis nous avons parlé de simulcast.

La discussion sur simulcast a été…  intéressante. Comment faire pour diffuser sur le fil un même contenu encodé à différentes résolutions et différents débits binaires n’était pas vraiment un problème, quasiment tout le monde est d’accord sur ce qui doit être fait (même si Microsoft et Cisco ont un peu argumenté sur ce sujet). Le but ultime n’a pas non plus été un réel sujet de discussion. tout le monde est d’accord que nous devrions viser  une JS API qui permettrait non seulement le simulcast, mais aussi le codage vidéo scalable (SVC) plus tard, et que cette nouvelle API approuvée un peu plus tôt fasse le boulot. La principale préoccupation était la masse de travail et les efforts devant être mis en œuvre pour l’inclure dans WebRTC 1.0 sans retarder encore plus la version finale.

Il y avait deux aspects à cela. Premièrement, comme le simulcast touche à presque toutes les couches, depuis le fil jusqu’à la signalisation, la masse de travail pour le tester et le débugger sera plus importante qu’à l’habitude et Google était préoccupé sur sa capacité à le finir avant la fin de l’année. Deuxièmement, et en lien avec le premier point, la discussion a porté sur la manière de gérer la signalisation du simulcast.

Ici, nous ne sommes pas en train de parler du Plan B contre le plan Unifié, qui touchent à comment gérer la signalisation de flux multiples dans une seule PeerConnection, mais nous traitons de simulcast, qui est un sous-cas des flux multiples où les flux ne sont pas indépendants les uns des autres mais des variations (différentes résolutions, différents nombres d’images par seconde) de la même source. Le point clé, ici, c’est que vous ne voulez pas que ce soit le navigateur qui traite chacun de ces flux indépendamment. Par exemple, vous ne voulez PAS que le contrôle de congestion de la bande passante du navigateur ou que l’algorithme d’adaptation de la bande passante du codec modifie séparément la résolution du flux. Ce que vous voulez, c’est que, pour s’adapter à une bande passante trop faible, ce soit d’abord la résolution la plus haute qui soit éliminée, voire même que la transmission de la vidéo soit totalement interrompue pour privilégier la transmission du son. Ceci est possible avec des flux multiples indépendants, c’est également possible (conceptuellement) avec simulcast car vous connaissez la dépendance entre les flux.

La principale question à propos de simulcast a porté sur l’intérêt pour WebRTC de réutiliser le travail fait dans le groupe de travail IETF MMUSIC. Ce groupe est en charge du format SDP et il travaille actuellement sur une proposition spécialement conçue pour le simulcast. Pour certains, cela semblerait étrange de ne pas l’utiliser et de refaire leur travail. Mozilla, qui aurait déjà mis cela en œuvre dans Firefox, était un fervent supporter de son utilisation. Pour d’autres, étant donnée l’histoire du groupe MMUSIC, cette proposition risquerait de prendre trop de temps pour arriver à maturité et devenir une spécification. Google était tout particulièrement réticent à ajouter une dépendance normative supplémentaire à la spécification WebRTC sans avoir ni un contrôle ni même une visibilité sur le délai potentiel qui pourrait en résulter. Mettre l’accent sur la date limite pour aboutir à la version 1.0 et ne pas la repousser, surtout d’un délai indéfini. Comme la prochaine réunion IETF doit avoir lieu APRÈS le W3C TPAC, la probabilité que cette question soit traitée à temps pour la version 1.0 est ramenée à 0.

Comme tout le monde était d’accord sur ce qui est la bonne chose à faire, et que la seule inconnue était la capacité du groupe de l’IETF à rendre sa proposition à temps, deux membres du groupe de travail W3C qui sont également présidents du groupe IETF Rtcweb, nommés J. Cullen de CISCO et H. Peter de Google , ont contacté leurs homologues à MMUSIC pour voir si MMUSIC était intéressé pour organiser une réunion intermédiaire suffisamment tôt pour permettre à cette spécification d’aboutir et de la sortir de la liste des préoccupations actives. La réponse de MMUSIC est positive et ils se sont engagés à accélérer le processus sur la spécification SDP de simulcast.

Le chemin restant à parcourir pour avoir simulcast dans webrtc 1.0 reste semé d’embûches. D’abord MMUSIC doit converger sur les spécifications sdp-multicast, avec, espérons-le, un retour d’espérience de la part du groupe WebRTC. Ensuite, le groupe WebRTC du W3C avait accepté d’avoir une réunion virtuelle avant TPAC (dernière semaine d’octobre), avec un retour d’expérience de MMUSIC en main pour décider si on donne le feu vert pour inclure simulcast dans la version 1.0. Finalement, c’est au TPAC que seront présentés les retours d’expérience des premières mises en œuvre de simulcast et que sera prise la décision finale à propos de l’incorporation de simulcast dans WebRTC 1.0. Tout cela dans 5 semaines 😉

La semaine dernière, j’ai donné une formation à CISCO suivie par un hackaton sur OpenWebRTC. Mon ami et collègue au W3C et à l’IETF, Dan Burnett, gérait la partie standards et specifications de la formation (et Dieu sait qu’il est bon pour ça), pendant que je m’occupais de la partie technique : implémentations, stacks, debugging, navigateurs… C’était une session excellente, la dualité entre la théorie et la pratique (toujours différents dans la vrai vie) était excitante, et l’auditoire s’y connaissait en WebRTC, chacun sur une partie du puzzle que représente une solution de communication basée sur WebRTC. Super expérience.

À la fin de la formation, on m’a posé une question à laquelle je n’étais pas préparé : « quelles sont les solutions et applications WebRTC les plus incroyables ? » Hum, question difficile. Tout d’abord, mais ça dépend des goûts, certaines personnes peuvent être impressionnées par une superbe interface utilisateur (et elles adoreront appear.in de Telenor Digital par exemple), alors que d’autres seront emballées par une entreprise qui a fourni une solution à un problème technique qu’elles-même ont été incapables de résoudre (le navigateur bowser d’Ericson ou le plugin Cordova de eFace2Face, chacun des deux pallie l’absence de support WebRTC sur iOS, alors que le projet webrtcinwebkit essaie de régler le même problème à la source).

Le chercheur en moi est toujours impressionné par les gens qui ont une vision et qui non seulement sont capables de voir au-delà de ce qu’il est possible de faire aujourd’hui, mais en plus transforment cette vision en réalité.

Pour cette raison j’aime les présentations de Feross. Ce mec est un passionné, il a une vision, il la met en œuvre, et il a cette capacité rare à transmettre sa passion à son auditoire. Sur un (oui, seulement un, pour plus, vous pouvez le suivre sur twitter) de ses multiples projets supplémentaires, il essaie de développer un bit torrent sur le web supporté directement par les navigateurs internet. J’ai eu la chance de travailler avec lui pendant une demi-journée à Singapour quand il est venu faire une présentation à la JSconf.asia, et de l’écouter de nouveau au « WebRTC meet up » de San Francisco. C’était vraiment des expériences agréables. J’ai hâte de l’entendre de nouveau au « Kranky and geek event » (#webrtclive) plus tard ce mois-ci.

Quand j’étais employé chez Temasys, j’ai eu la chance de travailler avec Thomas Gorissen qui est le meilleur développeur JS de ce côté du globe, organisateur de la « JSconf.asia » et expert en interface utilisateur (UI) / expérience utilisateur (UX) pour Sequoia Capitals parmi (tant) d’autres choses. Je n’ai donc pas eu trop à me soucier de mon code JS, ce qui est bien car les développeurs C++ ne sont, au mieux, que de pauvres développeurs JS 🙂 Ma seule satisfaction est d’avoir réussi à titiller suffisamment sa curiosité sur le WebRTC pour qu’il envisage de travailler dessus. Il ferait partie de mon équipe JS de rêve, avec Feross et Iñaki (voir plus loin).

Il y a certains ingénieurs qui sortent du lot à la fois dans l’écosystème et comme membres de petites équipes tout en continuant à faire la différence. J’ai beaucoup de respect pour le travail de Philipp Hancke et Iñaki Baz Castillo par exemple, et je suis rempli d’humilité devant les connaissance de Victor Pascual Ávila ou Dan Burnett sur les différentes APIs et technologies utilisées. Je vous conseille donc, si ce n’est pas déjà le cas, de les suivre. Je pense qu’Iñaki l’a bien exprimé pour nous tous : « On m’a dit que c’était impossible, donc je l’ai fait ». C’est exactement ma philosophie.

L’avantage de WebRTC c’est que c’est si rapide de s’améliorer, et si facile de commencer à l’utiliser, que je découvre chaque jour des trucs cools. Le projet qui m’excite cette semaine c’est un projet de réseau global p2p par David Dias qui exploite WebRTC. Oui, c’est assez proche de ce que fait Feross et je vois les deux projets comme étant complémentaires, mais ce qui est sympa à propos du projet de David c’est que ses posts de blog sont quasiment des articles de recherche complets. Cela signifie que vous avez toutes les informations du début à la fin avec un aperçu de l’ensemble du domaine des communications p2p (depuis Kazaa), avec des citations, des schémas et ainsi de suite. C’est rafraîchissant de voir quelque chose de bien expliqué et de reproductible. Cela permet aussi à quelqu’un de nouveau dans le domaine (comme moi), mais avec assez de connaissances scientifiques et technologiques, d’emmagasiner assez de connaissances sur les technologies p2p, les signatures électroniques et la sécurité des tables de hachage distribuées utilisées dans les crypto-monnaies comme le Bitcoin par exemple. Je pense qu’il est sur quelque chose et je ne serais pas surpris qu’une entreprise basée aux USA aille le débaucher du Portugal.

Si vous êtes au courant de projets fous qui essaient d’utiliser WebRTC sur des voies non explorées, s’il vous plait faites-le moi savoir, j’ai besoin de ma dose hebdomadaire.

Une version mise-à-jour de ce post est disponible ici.

Lire la suite →

Dans la Silicon vallée, dans le monde du Logiciel innovant, la guerre pour les talents a une signification certaine. J’ai deja parlé de ça dans un post précédent. Toute nouvelle technologie crée une appel d’air et des opportunités pour les ingénieurs.

Lire la suite →

Dans le petit monde du logiciel innovant (Bay Area Fever), les financements ne sont pas difficile à trouver. Il y a beaucoup d’argent autour, BEAUCOUP! Autour de 23% de tout les financements aux USA (47+ milliards) venaient, l’année dernière, de compagnies de SF.

La valeur n’est pas tant associé au capital, mais aux compétences des gens qui vont récupérer ce capital et  faire en sorte que la valeur financière originale soit multipliée. Le capital n’a de valeur que le jour où vous le récupérez, les compétences de l’équipe ont une valeur pour le futur de la compagnie.

L’ingénieur et le chercheur en moi se sent comme à la maison. Si vous faites une différence, vous n’êtes pas un simple employé qui fait son boulot et récupère son salaire, vous êtes quelqu’un qui prends un financement d’un demi million et le transforme en quelque chose qui vaut 20+ millions.

Les chefs intelligents savent ça très bien. Le talent est la clé de la crédibilité, de l’execution et de l’évaluation. Ce n’est pas une surprise que la course aux talents dans la vallée soit devenue une guerre. (ici, ici, ici ). Cela est bon et sain. Les clauses de non concurrence sont par ailleurs illégales en Californie, pour protéger les talents, qui seraient prives d’opportunités. Le temps où Apple et ses concurrents se mettaient d’accord pour ne pas se « piquer » les talents les uns les autres est révolu.

Dans un post précédent, j’ai pointé du doigt certains produits et/ou individus dans l’écosystème webrtc que j’estimais etre exceptionnels. Ca ne surprendra aucun lecteur que l’un des ingénieurs les plus en vu, le numéro un des chercheurs webrtc, hors google et mozilla, Philippe Hancke, ait sauté le pas et ai rejoint Tokbox.

Je voudrais bien croire qu’il a eu peur quand je lui ai dit que nous, à Citrix, allions contester sa suprématie de chercheur en 2016, et qu en reaction il s’est associé avec le numéro 2, je pense que la raison est toute autre. Tokbox a, aujourd’hui, le WebRTC PaaS le plus mature, avec une visibilité totale et en temps réel sur tout ce qui se passe, le genre de visibilité qui permettra à un ingénieur remarquable de faire la différence, ce qui est important pour lui et donc fait rentrer de l’argent, ce qui est important pour Tokbox.

Dans tous les cas, dans la guerre qui se déroule à S.F., illustrée par example au travers de la guerre du sponsoring (je te sponsorise ton event si tu ne laisse pas l autre parler) entre twilio et tokbox pour les événements webrtc en 2015, Tokbox a définitivement gagné cette bataille.

I. Introduction

La plupart des logiciels utilisant libwebrtc ont besoin de pouvoir la modifier pour rajouter des fonctionnalités. Certain vendeurs, comme TokBox, vont  changer les paramètres (flags) de compilation de libvpx par example, pour activer le mode d’encodage par couche (SVC) de VP8 dans leurs SDKs mobiles, our avoir une meilleure qualité video. D’autres, tel que Voxeet, vont ajouter des codecs audio supplémentaires, dans leur cas pour emuler de l’audio 3D et reproduire le positionnement des participants dans une conference. Beaucoup, y compris pristine.io, vont vouloir ajouter H.264 pour etre compatibles avec les cartes graphiques de plus d’ordinateurs et de telephones.

Quel que soit le but, chacun aura besoin d’être capable de modifier de façon cohérente le code source d’une bibliothèque qui change souvent, tout en s’assurant que le nombre de patchs et la manière de les appliquer reste gérable dans le temps.

De plus, comme il s’agit d’un code public, il y a des patchs qu’on va proposer et qui profiteront à tous, mais certains utilisateurs pourraient vouloir créer leurs propres patchs privés et les garder pour eux par se différencier. L’architecture de la méthode de gestion des patchs doit permettre cela.

Finalement, juste pour le plaisir, je voulais disposer d’un mécanisme me permettant d’avoir rapidement des patchs à partir du processus de revue et d’integration de nouvelle fonctionnalistes de Google pour profiter de ces nouvelles fonctionnalités de libwebrtc avant même qu’elles n’apparaissent dans Chrome (ou pour tester ces patchs avec mon système).

Dans ce post, nous allons proposer une manière simple, mais efficace, pour aboutir à ce résultat.

II. Mise en œuvre

1. Commandes spécifiques CMake que nous allons utiliser

CMake dispose de la commande add_subdirectory(). Cette commande permet de parcourir l’arborescence du dossier mentionné en argument et à traiter tous les fichiers CMakeLists.txt qu’y s’y trouvent.

1. add_subdirectory(Patches)

En conditionnant l’appel à cette commande vous pouvez concevoir une belle structure de dossier pour gérer vos patchs, par example selon le type de plateforme :

1. if( APPLE )
2.     add_subdirectory( mac )
3. elseif( WIN32 )
4.     add_subdirectory( win )
5. endif()

2. Création des patchs et conditions spécifiques à libwebrtc

Le code source de libwebrtc est un patchwork de bibliothèques indépendantes qui sont récupérées en fonction des entrees dans le fichier DEPS a la racine. Bien que gclient ait une option pour générer des patchs globaux, nous préférons simplement utiliser git. Ainsi, chaque patch que vous générez est applicable à une arborescence git spécifique et vous devez savoir à quel endroit (racine du patch) l’appliquer.

Nous avons créé une macro CMake pour aider à automatiser cela :

1. set_webrtc_patch_target(
2.     GIT_APPLY_CMD
3.     APPLY_DIR
4.     PATCH
5.     DEPENDS_ON_TARGET
6. )

L’option DEPENDS_ON_TARGET nous permet d’être sûr que les patchs sont appliqués après le téléchargement du code.

Le GIT_APPLY_COMMAND apporte de la flexibilité à la commande git que vous utilisez. Certains vont préfèrer l’approche « git diff » / « git apply », alors que d’autres préfèreront « git format-patch » / « git am ». Dans notre cas nous gardons les choses simples :

1. set(
2.     GIT_APPLY_CMD
3.     git apply –ignore-space-change –ignore-whitespace
4. )

3. Comment exécuter une commande clean/undo

Le problème avec les patchs, c’est qu’ils laissent l’arborescence du code source modifie, ce que git n’aime pas.

Quand on utilise git, une façon de retourner à un état propre est faire un reset : « git reset –hard -q« . Cela ramènera tous les fichiers suivis par git dans un état propre, mais peut laisser des fichiers non suivis par git dans l’arborescence, par exemple si vous ajoutez de nouveaux fichiers ou si vous en supprimez d’autres. « git clean -qfdx »est donc nécessaire si vous voulez vous assurer que l’arborescence du code source est revenue dans l’état que vous souhaitez. Le code ressemble à ça :

1. set( GIT_RESET_CMD git_reset –hard -q )
2. set( GIT_CLEAN_CMD git clean -qfdx )

De plus, vous devez savoir à quel endroit de l’arborescence appliquer ces commandes, donc vous devez noter tous les répertoires où des patchs ont été appliqués. Pour chaque patch, nous allons ajouter dans une liste le répertoire auquel il s’applique. Quand le moment sera venu d’annuler l’application du patch, nous utiliserons cette liste :

1. list(REMOVE_DUPLICATES PATCHED_DIRS) # enlève les doublons
2. add_custom_target(
3.     UNPATCH_ALL
4.     ${CMAKE_COMMAND} -E touch dummy.phony
5. )
6. foreach( dir ${PATCHED_DIRS} )
7.   add_custom_command(
8.     TARGET                                UNPATCH_ALL           POST_BUILD
9.     COMMAND                         ${GIT_RESET_CMD}
10.     COMMAND                         ${GIT_CLEAN_CMD}
11.    WORKING_DIRECTORY   ${WebRTC_SOURCE_DIR}/${dir}
12.    COMMENT                          « Unpatching ${dir} »
    
13.  )
14. endforeach()

4. Comment intégrer mes patchs privés/propriétaires ?

Avec la commande add_subdirectory() les choses sont relativement simples. Le code ci-dessous vérifie s’il existe un sous-répertoire « PvtPatches » et s’il y en a un, rentre dedans. Vous pouvez utiliser les sous-arborescences git, ou la méthode de votre choix, pour avoir dans votre copie locale un tel répertoire, avec un CMakeFiles copié (hum… largement inspiré) de celui dans Patches et tout sera pour le mieux.

1. if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/PvtPatches)
2.     add_subdirectory(pvtPatches)
3. endif()

Notez qu’une attention particulière a été portée à la variable qui contient la liste des répertoires sur lesquels appliquer la commande de reset et de nettoyage, pour que vous puissiez la modifier de l’intérieur des sous-répertoires et qu’elle reste valide. L’option « CACHE » vous assure de la cohérence à travers tout le projet quel que soit le répertoire source. L’option « INTERNAL » est ici pour pour s’assurer que cette variable n’apparaîtra pas dans l’interface graphique qui est distribuée avec CMake.

1. set( PATCHED_DIRS «  » CACHE INTERNAL « Internal variable. »)

Bien entendu, vous êtes susceptible de devoir relancer l’outil de génération de compilation après avoir appliqué les patchs :

1. python /src/webrtc/build/gyp_webrtc.py

III. Conclusion

Vous avez vu dans ce post comment installer un système de patchs simple pour libwebrtc. Bien sûr, ce ne serait pas complet sans quelques examples. Nous laissons a titre d exercice pour le lecteur, l’intégration de quelques patchs Google :

• support pour openH264 (patch)
• support pour les rendus d’images AVFoundation pour Mac (patch)

Cheers.

Alex

I. Introduction

Les bibliothèques précompilées pour la version stable de WebRTC (celles utilisées dans Chrome) ont été souvent réclamées dans la mailing list, mais jusqu’à maintenant personne ne s’est attelé à la tâche de les générer. Un des buts de ce blog est de fournir ces bibliothèques afin de réduire la barrière d’entrée pour ceux qui voudraient construire au-dessus de WebRTC.

Comme je préparais les bibliothèques sous Linux, je suis à nouveau tombé sur le test défaillant que j’ai mentionné dans un post précédent:

« La première erreur semble être liée à une mauvaise allocation mémoire. C’est là que vous réalisez que lancer la compilation sur la plus petite instance possible de Linux dans AWS était probablement une mauvaise idée. Ce problème devrait disparaître lorsque je lancerais le build bot de Linux sur une instance plus grosse. La deuxième erreur est plus subtile, et je ne peux pas la comprendre juste à partir des « logs ». Lorsque j’aurais installé une instance de compilation plus puissante pour Linux, je débuggerais directement dessus. »

En ce qui me concerne, avoir ne serait-ce qu’un seul test défaillant n’est pas acceptable. J’ai donc creusé plus profond. Voici la compilation avant les changements.

II. Investigations

Entre-temps, j’ai déplacé le build bot vers une plus grosse instance (c3.2x). Effectivement, la première erreur, qui était bien un problème d’allocation mémoire provoqué par une instance trop petite, a disparu sans que j’ai eu à m’en occuper.

La deuxième erreur était liée aux tests de partage d’écran, ce qui n’est pas une surprise puisque nous travaillons sur une machine virtuelle sans affichage.

Les tests originaux sont lancés par l’intermédiaire d’un contrôleur de tests écrit en Python. Le code de ce contrôleur, qui est séparé de libwebrtc, peut être trouvé ici. Le fichier principal est ici. Là encore, il s’agit d’un code venant de Chrome qui contient tout un tas de choses inutiles pour tester la version autonome de WebRTC (Chrome sandbox…).

Il fait aussi beaucoup de bonnes choses en terme de vérification de ce qui n’a pas été couvert par les tests précédents, dont certains ont pu échouer. Il y a de nombreuses étapes supplémentaires améliorant la stabilité et le robustesse des tests, ce n’est donc pas si mal.

Pour faire simple, pour résoudre le problème de l’absence d’écran sur une machine virtuelle, vous avez seulement à installer Xvfb et openbox :

1. sudo apt-get install xvfb
2. sudo apt-get install openbox

puis définir un affichage, le créer, et démarrer le gestionnaire de fenêtres openbox avant de lancer votre test (le code ci-dessous est conçu pour rester au plus proche des conditions de test de Google).

1. export DISPLAY=:9
2. Xvbf :9 -screen 0 1024x768x24 -ac -dpi 96&
3. openbox&

Maintenant tous les tests passent !

III. Conclusion

Garder son tableau de bord « tout au vert » est de la plus haute importance. Si le tableau de bord a des voyants au rouge, ça signifie que vous développez les yeux bandés. Garder son tableau de bord « tout au vert » est un défi quotidien. Cela peut être perçu comme trop fastidieux d’avoir à y porter autant d’attention et d’efforts, mais c’est il s’agit en fait du filet de sécurité pour les développeurs qui vous permet de vous concentrer uniquement sur le développement.

Les avantages apportés par CMake ici sont doubles : d’une part abaisser la barrière d’entrée, et d’autre part fournir un tableau de bord collaboratif.

Encore une fois, certains peuvent estimer que les outils de compilation de Chrome, aussi bons et avancés qu’ils soient, sont une surenchère dans le but de produire seulement la libwebrtc autonome. Je crois que cela ralentit l’adoption et la contribution à WebRTC puisqu’il faut d’abord devenir un développeur Chromium, et pour celà la pente d’apprentissage est très raide.

Dans tous les cas, vous pouvez maintenant télécharger les bibliothèques et les en-têtes testés et précompilés pour Linux, Mac ou Windows depuis la page « Tools« . Si ce que vous désirez est juste de développer une application par-dessus libwebrtc qui fonctionne avec le dernier Chrome stable, vous avez tout ce qu’il vous faut maintenant.

Certaines personnes demandent des fonctionnalités qui ne sont pas, ou pas encore, dans WebRTC. Dans un prochain post, j’expliquerais comment faire pour appliquer sans effort un patch à libwebrtc dans le cadre du processus décrit précédemment.

Faites vous plaisir.

I. Introduction

Suite à mon précédent post, j’ai reçu beaucoup d’e-mails concernant l’installation des build bots. Je dois admettre que mon post précédent n’abordait pas ce sujet en détail et que la documentation à ce sujet est peu importante (en quantité) et confuse, tout comme le mode opératoire recommandé a changé dans la communauté cmake au cours des 15 ans des projets (VTK, ITK). Voici donc un post qui décrit, pas à pas, comment installer vos propres bots en quelques heures et comment les gérer à distance avec git sans jamais avoir à vous reconnecter à eux à nouveau (en théorie, en pratique les s#$%^ arrivent et vous pouvez souhaiter vous connecter de temps en temps pour débugguer les problèmes directement).

Garder le build bot séparé du code principal est une bonne politique car ils pourraient contenir des informations sensibles à propos de votre infrastructure. Par exemple, vous pourriez mentionner une clef d’accès pour transférer le résultat de la compilation (paquets de bibliothèques) et il vaut mieux que cette information reste privée. De plus, avec les réglages actuels, n’importe qui réussissant à avoir accès à votre script de compilation sera capable de lancer tout ce qu’il veut en utilisant votre build bot, ce qui est également quelque chose que vous ne voulez pas voir se produire. Dans notre cas, ceci est plus un tutoriel.

II. Écrire un script pour CTest

Jusqu’ci, j’ai présenté deux façons d’utiliser ctest :

• comme une extension de CMake pour gérer les tests directement à partir des fichiers CMake ;
• comme un client CDash, pour lancer CMake et automatiquement envoyer les résultats des étapes de la mise à niveau, de la configuration, de la compilation et des tests vers un serveur CDash

Il y a une troisième façon d’utiliser CTest : à partir de scripts. Vous pouvez écrire un fichier en utilisant la syntaxe CMake pour initialiser à l’avance les variables CTEST_<> qui serviront à lancer CTest d’une manière contrôlée. Vous tapez ensuite la commande « ctest-S » avec votre fichier en argument pour lancer CTest en mode script.

Quelques variables très utiles permettent de définir le cache CTEST,  ou des variables d’environnement, ou encore les compilateurs à utiliser et tout programme donné ou variable CMake. Cela permet, par exemple, de lancer des compilations 32 bits et 64 bits, en version debug et release, sur une même machine. Un autre exemple est d’avoir plusieurs versions de compilateurs sur une machine donnée et d’avoir des scripts CTest pour utiliser un compilateur spécifique à la fois. Un des meilleurs scripts que j’ai vu, écrit par Gaëtan Lehmann, gérait différentes versions de MSVC et Java sous Windows. Chapeau bas.

On peut obtenir plus d’informations à propos des capacités de CTest sur la vieille page écrite à une époque où on utilisait encore Purifier (ici, ici et là), et une version plus récente ici.

III. Qu’en est-il de libwebrtc ?

Pour cet exemple, j’ai utilisé la méthode la plus récente développée pour ITK v4. Vous trouverez ici un rapide aperçu. Cette version était centrée sur git et elle met en place quelques astuces pour gérer différentes branches, ce qui facilite la mise en place de bots pour les branches de développement.

1. Un script générique qui fait tous les travaux lourds

L’idée est d’avoir un script très général qui gère la plupart des problèmes pour vous et de laisser seulement quelques variables à définir par l’utilisateur. J’ai porté le script générique de manière à ce qu’il soit utilisable pour libwebrtc : libwebrtc_common.cmake. Sauf si vous êtes un puriste, je recommande de ne pas le modifier, ni même de le consulter. Il vous permet maintenant de définir un ensemble de paramètres, certaines variables CMAKE ou CTEST habituelles, ainsi que quelques nouvelles variables du tableau de bord, pour contrôler votre compilation.

• dashboard_model = Nightly | Experimental | Continuous
• dashboard_track = chemin optionnel vers lequel soumettre le tableau de bord
  
• dashboard_loop = répéter jusqu’à ce qu’une durée de N secondes se soit écoulée
  
• dashboard_root_name = changer le nom du répertoire « My Tests »
  
• dashboard_source_name = nom du répertoire contenant les sources (libwebrtc)
• dashboard_binary_name = nom du répertoire où seront placés les binaires (libwebrtc-build)
• dashboard_data_name = nom de la zone de stockage des données externes (ExternalData)
• dashboard_cache = contenu initial du fichier CMakeCache.txt
  
• dashboard_do_cache = toujours écrire CMakeCache.txt
• dashboard_do_coverage = True pour activer la couverture de code (par exemple avec gcov)
• dashboard_do_memcheck = True pour activer la recherche des fuites mémoire (par exemple avec valgrind)
• dashboard_no_clean = True pour sauter l’étape d’effacement de l’arborescence de compilation
• dashboard_no_update = True pour sauter la mise à jour de l’arborescence du code source
  
• CTEST_UPDATE_COMMAND = chemin vers le client git ligne de commande
• CTEST_BUILD_FLAGS = arguments pour l’outil de compilation (par exemple : -j2)
• CTEST_BUILD_TARGET = indique une cible particulière à compiler (à la place de toutes les cibles)
• CTEST_DASHBOARD_ROOT = indique où mettre les arborescences du code source et de compilation
• CTEST_TEST_CTEST = précise s’il faut exécuter ou pas les longs tests CTestTest*
  
• CTEST_TEST_TIMEOUT = pour chaque test, précise quelle est la durée du timeout
• CTEST_COVERAGE_ARGS = arguments pour la commande ctest_coverage
  
• CTEST_TEST_ARGS = arguments pour ctest_test (par exemple : PARALLEL_LEVEL 4)
• CTEST_MEMCHECK_ARGS = arguments pour ctest_memcheck (par défaut CTEST_TEST_ARGS)
• CMAKE_MAKE_PROGRAM = chemin vers l’outil « make » à utiliser
• Options pour configurer les compilations du dépôt expérimental de git :
• dashboard_git_url = définition d’une URL spéciale pour git clone url
  
• dashboard_git_branch = définition d’une branche spéciale à suivre
• dashboard_git_crlf = valeur de la variable core.autocrlf pour le dépôt
  

Si vous voulez étendre la capacité de ce script principal, quelques hameçons sont fournis afin de conserver les choses proprement et de manière compartimentée.

• dashboard_hook_init = fin de l’initialisation, juste avant la boucle
• dashboard_hook_start = début du corps de la boucle, avant ctest_start
• dashboard_hook started = après ctest_start
• dashboard_hook_build = avant ctest_build
• dashboard_hook_test = avant ctest_test
• dashboard_hook_coverage = avant ctest_coverage
• dashboard_hook_memcheck = avant ctest_memcheck
• dashboard_hook_submit = avant ctest_submit
• dashboard_hook_end = fin du corps de la boucle, après ctest_submit

2. Un fichier très simple pour définir un bot

Finalement, cela permet effectivement d’écrire un script de compilation effectivement très simplement :

1. set(CTEST_SITE « Bill_._Our_fearless_leader » )
2. set(CTEST_BUILD_NAME « Ubuntu-12.04-32-Deb » )
3. set(CTEST_BUILD_FLAGS -j8 )
4. set(CTEST_DASHBOARD_ROOT « /home/ubuntu/Dashboards » )
5. set(CTEST_TEST_TIMEOUT 1500 )
6. set(CTEST_BUILD_CONFIGURATION Debug )
7. set(CTEST_CMAKE_GENERATOR « Unix Makefiles » )
8. set(dashboard_model Experimental )
9. include(libwebrtc_common.cmake)

Et … voilà ! Vous avez un build bot linux prêt ! Remplacez « Debug » par « Release » et votre compilation en version release est prête. Pour passer de 32 à 64 bits, comme nous utilisons ninja, vous devez positionner la bonne variable d’environnement, mais ce n’est pas difficile non plus :

1. set(CTEST_ENVIRONMENT
2.     « GYP_DEFINES=’target_arch=x64′ » # ou ia32 pour 32 bits
3. )

Vous trouverez le fichier correspondant ici.

Une mise en garde tout de même, installer l’environnement de développement pour libwebrtc est difficile. Premièrement, cela ne marchera quasiment que sous Ubuntu ; deuxièmement, les scripts d’installation de l’environnement semblent ne pas fonctionner donc vous devrez au final installer manuellement quelques bibliothèques avant de pouvoir compiler. La bonne nouvelle c’est que vous ne devrez le faire qu’une seule fois.

3. Comment automatiser tout cela ?

Maintenant vous êtes armés de nombreux fichiers pour chaque compilation que vous voulez lancer. Vous pourriez très bien lancer plusieurs compilations sur la même machine, par exemple 32/64, Debug/Release. Pour des machines sous Linux, vous pouvez également souhaiter faire une compilation croisée avec des binaires Android (plus sur les cibles pour les mobiles dans un prochain post).

Toutefois, vous avez toujours besoin d’accéder à la machine et de lancer manuellement

1. ctest -S My_Build_script.cmake

pour que cela fonctionne.

Une façon de contouner cela consiste à définir un script (shell) qui lance ces commandes pour vous. Cependant, à chaque fois que vous apportez une modification au script, vous devez à nouveau vous connecter à la machine et mettre à jour manuellement le script local avec la nouvelle version, grrrrr.

C’est ici que cron (sur Linux ou Mac) et le planificateur de tâches (sur Windows) sont très pratiques, car ils peuvent lancer une commande à un jour et une heure prédéfinis pour un utilisateur donné. Ici vous avez deux écoles : les premiers utilisateurs de CMake ont tout conçu de telle sorte qu’il soit possible de configurer leurs ordinateurs (qui restent toujours allumés) pour être utilisés pendant les heures de sommeil. Plus récemment, les développeurs ont mis en place soit un build bot dédié, soit un build bot hébergé, et ils réduisent les coûts en éteignant la machine une fois le travail terminé. Je vais illustrer la deuxième solution pour Linux (et Mac) et les fichiers pour Windows seront fournis sur le compte github, pour ceux que ça intéresse. Spécialement pour les build bots Windows, notez qu’il a été démontré qu’il vaut mieux redémarrer la machine une fois par jour dans tous les cas si vous voulez que cela fonctionne…

Démarrer des instances à distance est facile, tous les fournisseurs de cloud proposent une API de ligne de commande, et vous pouvez maintenir un maître (sur la plus petite instance possible) dont le seul travail consiste à réveiller les bots une fois par jour pour qu’ils récupèrent la dernière version du code, qu’ils configurent la compilation, lancent la compilation et les tests et qu’il soumettent les résultats au tableau de bord. Dans AWS EC2, ça veut dire jouer avec IAM, mais rien de trop difficile, de plus c’est très bien documenté. Sous Linux, le démon cron accepte le mot-clé « reboot », qui indique que la tâche correspondante sera exécutée à chaque fois que l’instance est démarrée.

1. @ reboot/home/ubuntu/Dashboards/Scripts/Bill-runall.sh

Finalement, il vous suffit d’utiliser la commande shutdown dans votre script pour arrêter l’instance quand les tâches sont terminées.

1. shutdown -h now

Il ne nous reste plus qu’à automatiser les mises à jour des scripts.

L’astuce utilisée par la communauté ITK est de conserver les scripts (et la table « cron ») dans un dépôt git et de mettre à jour, en premier, ce dépôt. Dans cet exemple, vous pouvez voir depuis le script shell que nous nous attendons à ce que le répertoire ~/Dashboard/Scripts contienne les scripts de compilation, qu’il existe un répertoire ~/Dashboard/Logs, et que la crontable soit mise à jour au passage. Maintenant il me suffit d’effectuer un commit dans mon dépôt git pour que le bot de compilation se mette à jour automatiquement de lui-même. C’est trop bon !

1. # Aller dans le répertoire de travail
2. cd /home/ubuntu/Dashboards/Scripts
3. # Récupérer la dernière version des scripts
4. git pull -rebase -q
5. # Mettre à jour la crontable
6. crontab ./Bill-crontab
7. # Lancer les compilations et les tests
   
8. ctest -S ./Bill-32-Debug.cmake
9. ctest -S ./Bill-32-Release.cmake
10. # Terminé. Arrêtons l’instance pour ne pas payer trop
11. sudo shutdown -h now

Le script complet avec quelques fonctionnalités supplémentaires est disponible ici.

IV. Conclusion

Cela devrait maintenant être assez clair que mettre en place un build bot pour libwebrtc est relativement facile. Le code fourni dans github devrait rendre cette tâche encore plus facile. Vous êtes libres de mettre en place votre propre build bot, y compris avec des paramètres qui ne sont pas encore présents dans les bots contribuant aujourd’hui au tableau de bord, ce qui permettra de contribuer au jeu… Je devrais faire une mise à jour vers un serveur CDash plus gros ce qui permettra très bientôt d’avoir plus de 10 compilations par jour. J’adorerais voir des gens contribuer pour ajouter la compilation pour ARM, Androïd, iOS…

Si vous trouvez ça utile, faites le connaître autour de vous, et sachez que les commentaires sympas sont eux aussi appréciés. 😉