Le système de compilation de Chromium / Chrome / WebRTC

I. Introduction.

Cet article est une introduction au système de compilation et de gestion du code utilisé par Google dans beaucoup de projets avec une attention particulière sur la compilation de WebRTC. Je ne prétend pas que le contenu soit exhaustif mais cela devrait vous donner une vue d’ensemble sur les étapes à suivre, vous permettant ensuite de creuser plus profond et débuguer plus vite si il y a un problème. Cet article pose aussi les bases pour un article suivant qui traitera de l’automatisation de la compilation. Finalement, vous trouverez ici quelques conseils sur comment modifier le code source vous-même, et re-compiler ensuite. Un article séparée complet sera écrit sur les détails de ce dernier point.

II. depot_tools

« depot_tools » est le nom d’une collection d’outils, utilises via des scripts python, utilisés par l’équipe chrome pour manipuler tout leur processus de développement: gestion des codes sources, tests, infrastructure, etc. Même si pour les étapes simples, comme obtenir le code, tout se résume à des commandes git ou svn, chrome et par extension WebRTC ont une façon dynamique de manipuler les dépendances et les marqueurs de compilation. Il est enfouis dans de multiples fichiers interdépendants (DEPS, gip, gipy, …) et vous devriez *vraiment* éviter de modifier ces fichiers avant d’avoir un besoin spécifique, et de savoir ce que vous faite.

[Mise a Jour] Depuis Decembre 2016, la gestion des projets de compilation est faite via GN et non plus GYP. Les fichiers correspondant sont donc .gn and .gni

Pour approfondir:

  • https://www.chromium.org/developers/how-tos/depottools [OLD]
  • http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depottools.html

III. « Fetch » et les recettes (recipes).

Le site officiel (webrtc.org) répertorie les dependences et est une lecture obligatoire avant toute experimentation. Ils recommandent de simplement lancer la ligne de commande « fetch » et de laisser faire. Pour une compilation simple de la dernière version de webrtc cela peut être suffisant mais pour la plupart des utilisations, c’est un peu léger.

Un coup d’oeil au code source de fetch (fetch.py) vous montrera qu’il appelle juste une « recette » (recipe). Les recettes utilisent des valeurs codées en dur comme arguments de commandes internes. Dans le cas de la recette webrtc, la commande fetch va juste écrire ces valeurs dans un fichier .gclient sur le disque, ce qui aura le même résultat qu’un appel à « client config » avec les bons paramètres, puis exécutera l’équivalent d’un appel à « client sync » qui téléchargera le code.

Nous pensons que cela a plus de sens d’appeler explicitement la commande gclient et de garder le contrôle sur ce que nous faisons. Cela permet de rajouter des options, soit pour optimiser soit pour adapter le processus. Par example, pour utiliser une version particulière de webrtc, et non pas la toute dernière.

IV. Configuration gclient et fichier gclient.

Vous pouvez obtenir le même résultat que « fetch » en lançant la ligne de commande suivante:

  1. gclient config -name src https://chromium.googlesource.com /external/webrtc.git

A la base, le code source de webrtc était géré via SVN et webrtc utilisait « trunk » comme nom du repertoire racine. Lors de la migration vers git, le code de libwebrtc c’est rapproche de celui de chrome, et le nom de la racine DOIT être « src » maintenant. Ceci explique la partie « -name src » de la ligne de commande.

Maintenant, si vous regardez le fichier .gclient généré par la recette webrtc de fetch, ou celui généré par la commande ci-dessus vous allez remarquer qu’une ligne manque:

  1. ‘with_branch_heads’: True,

Cette ligne sers a récupérer les informations de synchronisation avec chrome. Ca n’est utile que si vous souhaitez utiliser une version précédente de libwebrtc, synchronisee avec une version de chrome (par example, 57). Malheureusement, cela rajoute 1/2 GB de code a telecharger. La plupart du temps ce n’est pas nécessaire.

Finalement, il y a aussi deux recettes pour iOS et android qui ne font que rajouter une ligne simple au fichier .gclient:

  • « target_os = [ios,mac] »
  • « target_os = [android,unix] »

Cela permet de compiler pour iOS sur un mac, et pour android sur unix (en fait, seulement ubuntu est supporte).

Cela peux parfois valoir la peine d’ajouter la ligne target_os et une ligne de plus: « target_os_only=true » pour réduire la quantité de code a telecharger. Il n’y a aucun paramètre en ligne de commande de gclient pour faire ça (pour le moment), vous devez modifier le fichier .gclient directement vous-même.

Pour plus d’info:

Un fichier .gclient peut effectivement être très complexe comme beaucoup de choses dans webrtc/chrome, beaucoup d’entre elles sont écrites à la main. Le fichier chromium.gclient  code en dur dans le code de WebRTC est un example parfait. Vous pouvez voir que les dépendances personnalisées ont été définies comme un moyen de couper les dépendances originales de chrome. Les développeurs de chrome justifient auprès des développeurs webrtc qui se plaignent du temps que prend de fetch webrtc que cela serait deux fois pire avec webkit activé :-).

Pour ceux qui ont du temps pour optimiser leur version de WebRTC pourraient rechercher ce qu’ils pourraient supprimer pour une construction de production.

[Mise a Jour] – L’équipe de chrome ayant cree des miroirs git pour toutes les dependences, Henrik a enleve la partie chromium et les dependences sont maintenant gérées individuellement et proprement depuis décembre 2016. Cela marque la fin de la migration vers GIT.

V. gclient sync

gclient sync est une commande intéressante avec beaucoup d’options (grep/search pour « CMDsync » dans le fichier client.py). Son rôle principal est d’obtenir le code depuis le lien GIT fourni dans le fichier .gclient, puis d’analyser le fichier DEPS. Si le fichier DEPS contient des commandes additionnelles (hooks), il peut aussi les lancer directement.

Dans notre cas, on préfère séparer les commandes additionelles de la synchronisation. Il y a plusieur raison pour cela, beaucoup d’entre elles seront décrites dans de prochains articles, mais une raison simple est d’être capable d’illustrer combien de temps prend le code webrtc par rapport au temps que prend le code chrome. [Mise a jour] – Obsolete, le code de chrome n’est plus telecharge.

Le résultat de cette analyse de DEPS est le fichier .gclient_entries qui contient des paires de dossiers: une paire contient en premier le nom d’un repertoire local (ici « src ») et le lien GIT original, puis toutes les dépendances. Si vous êtes sous windows, il y aura une dépendance additionnelle à winsdk.

Il y a beaucoup d’options mais nous allons garder les choses simples. Nous allons utiliser -r pour fixer une révision pour que notre construction de production soit plus stable. Nous utiliserons -D pour couper les répertoires qui ne sont plus utilisés. Enfin nous allons utiliser -n pour éviter d’utiliser les commandes additionelles pendant l’étape de synchronisation.

  1. gclient sync -n -D -r 88a4298

La révision marquée ici la signature du commit GIT spécifique avant que l’équipe Google ne change sciemment la gestion des threads, ce qui a casse beaucoup d’implementations exterieures. C’est la réalité du travail avec la dernière version de webrtc, et pourquoi nous allons parler dans d’autres posts de comment tester webrtc une fois compile  avant de l’utiliser en production.

 

VI. gclient runhooks

Les commandes additionnelles (hooks), sont indiquées dans le fichier DEPS.

  • check_root_dir.py    # vérifie juste si vous utilisez « trunk » ou pas pour Rétrocompatibilité.
  • sync_chromium.py # celui que vous allez apprendre à détester. Il faut 40min depuis Mountain View, CA avec 89MB DL.
  • setup_links.py          # regardez ci-dessous.
  • download_from_google_storage   # récupère les fichiers tests.
  • src/webrtc/build/gyp_webrtc.py   #  génère les fichiers de construction – voir ci-dessous.

sync_chromium.py est juste une enveloppe étendue pour « gclient sync ». Puisque le fichier .gclient est présent dans le dossier /chromium, « gclient config » est inutile, et on peux passer directement a « gclient sync ». Il faut noter que cela modifie la variable d’environnement de GYP_DEFINES pour supprimer la NACL tool suite de chrome. Comme vous pouvez le voir, il y a une multitude de façons de faire les choses, elles sont toutes enchevêtrées dans le code source, ce qui le rend assez difficile a manipuler.

setup_links.py est ici pour traiter la compatibilité ascendante. SVN à un (seul?) avantage sur git: vous pouvez directement récupérer les sous répertoires. Quand chrome et webrtc utilisaient svn, quelques sous répertoires de chrome étaient directement récupérés et insérés dans la disposition de webrtc. Maintenant que tout que tout est passé à GIT ce n’est plus possible. Au lieu de modifier le code et les inclusions pour refléter la mise en page (avec tout le code chrome sous le /chromium dir), les ingénieurs de google ont décidé de choisir l’approche rétrocompatible de la création de liens symboliques pour chacun des dossiers insérés précédemment. La mise en page est alors la même et il y a donc continuité. C’est ce que fait setup_links.py. Malheureusement, il en coûte de lancer cette commande comme un administrateur sous windows, qui est une charge supplémentaire.

/src/webrtc/build/gyp_webrtc.py est un fichier très important. C’est le fichier qui va générer les fichier de base de construction dans le gyp et les fichiers gypi d’un côté, de l’autre et quelques variables d’environnement de l’autre. Par défaut, les fichiers ninja seront créés respectivement dans src/out/Debug et src/out/Release. Si vous partez sur une construction automatisée, vous devriez utiliser la version par défaut. Maintenant, si vous voulez être capable de débuguer dans un IDE comme Xcode ou MSVC, il y a des petites étapes supplémentaires a ajouter au processus. Vous povez suivre la page officielle (official page) pour cela à la section build.

Si vous modifiez n’importe lequel des fichiers gyp ou gypi pour ajouter des options de compilateur ou ajouter des projets, vous aurez a relancer gyp_webrtc. Si vous changez le générateur vous devrez aussi le relancer. D’habitude, « gclient runhooks » fait ça pour vous.

VII. Construction.

Cette étape dépend de du choix que vous avez fait avec le respect de vos générateurs gyp. Ici nous allons assumer ninja car le principal but est d’ouvrir un chemin à la compilation automatique (oh oui, et aussi parce que google ne supporte presque que ninja…)

Quelques notes pratiques à propos de ninja et webrtc.

Chaque fichier gyp génèrera, plus ou moins, un fichier .ninja. Si vous regardez le répertoire racine, appelé /out/Debug dans notre cas, vous verrez un fichier principal ninja « build ninja » et tout le reste est dans le sous répertoire obj dont la mise en page interne reflète la disposition de la source webrtc. Une fois la construction faite, les bibliothèques résultantes et les exécutables seront sous la racine pour mac, et où leurs fichirs correspondants .ninja résident sous windows. Ceci fait des plateformes croisées de paquets de codes… Intéressant à écrire. ninja prend en charge la compilation incrémentielle. Donc si vous modifiez un fichier gyp pour ajouter un fichier source, ajouter un projet, etc, vous pouvez régénérer les fichiers ninja et relancer pour compiler seulement ce dont vous avez besoin. Toutefois, si vous faites d’autres modifications, comme changer les paramètres de compilation, ninja ne va pas recompiler si le binaire est toujours présent, et vous devrez le retirer manuellement. Dans la pratique, si le temps n’est pas un vrai problème, pour être sûr, on pourrait vouloir enlever le /out/directory avant de régénérer les fichier ninja et recompiler.

Dans notre cas.

La ligne de commande suivante lance la compilation pour la version Debug de la librairie.

  1. ninja -C /out/Debug

autres lectures

  • https://martine.github.io/ninja/manual.html

C’est facile de parler. Montre moi ton code.

quote-talk-is-cheap-show-me-the-code-linus-torvalds-273528

WebRTC par Dr. ALEX est un blog au sujet de …. WebRTC (surprise!), la technologie elle meme et la communauté qui l’entoure. Comme WebRTC en est à ses débuts, il y a besoin d’un suivi continu, de rapports sur les avancées ainsi que des posts bien documentés sur les développements, déploiements et produits principaux.

En suivant une approche scientifique, autant que possible, toutes les opinions exprimées ici seront appuyées par des données vérifiables / reproductibles. Les sources seront citées de façon appropriée. Nous voulons faire de ce blog un endroit ou la communauté pourra avoir des discussions et échanger des informations au travers des commentaires, nous accueillerons les défis, les idées, les opinions et les oppositions documentés à partir du moment où c’est fait d’une façon polie et courtoise. Pour maintenir le site a jour et la precision du contenu, les articles seront mis à jour, corrigés, amendés et améliorés si de nouvelles informations deviennent disponibles ou si les déclarations originales sont invalidées. Les contributions extérieures seront toujours mentionnées, les auteurs remercies.

Ce blog ne concerne aucun produit commercial et aucune companie même si quelques unes sont citées ou font l’objet de post ce sera pour l’usage de leur technologie. Beaucoup d’opinions exprimées ici sont celles de l’auteur et en aucun cas celles d’une corporation ou d’une affiliation a quelque organisme que ce soit. Si l’auteur a un quelconque conflit d’intérêt, celui-ci sera dévoilé dans le post correspondant.

#WebRTC: Les entreprises se tournent vers l’Asie pour leur croissance.

CafeX a fait une annonce ce week-end au sujet de leur nouveau partenariat au Japon, leur permettant d’augmenter leur ventes en Asie du Sud-Est et du Nord. J’avais terminé mon « Rapport sur WebRTC en Asie » avec un paragraphe special sur le Japon. Ce paragraphe incluait l’analyse de l’approche de « Dialogic » et de « Twilio » pour pénétrer le marche Japonais. Cette nouvelle annonce apporte de l’eau a mon moulin et souligne l’importance de l’Asie pour les fournisseurs de WebRTC, et l’importance du Japon pour rayonner ensuite sur le reste de l’Asie.

INTRODUCTION

Pour l’écosystème autour de WebRTC, CaféX n’est pas un inconnu. Ils ont mis l’accent dès le début sur des solutions qui s’installent et tournent chez le client (« on-premises »), leur permettant d’approcher les entreprises bancaires et autres companies dont l’activité se doit d’être sécurisés et/ou ne peux pas utiliser le cloud public. Ils ont aussi très finement place leurs solution dans la nouvelle vague « omnichannel », qui consiste a multiplier les moyens pour les utilisateurs de contacter l’entreprise. Vous avez un problème avec un produit Darty? Appelez, envoyez un e-mail, discutez avec nous en ligne, ou meme maintenant, faite un appel audio/video directement depuis notre site internet. Récemment, ils ont mis beaucoup en avant leur solution d’aide et de support « LiveAssist ».

L’ASIE COMME RELAIS DE CROISSANCE

La majorité des fournisseurs de solutions WebRTCse concentrent sur l’Amérique du Nord ou l’Union Européenne qui ont un P.I.B. avoisinant les 20 millions de milliards (U.S.D.) pour une population de 506 (A.N.) et 326 (U.E.) millions de personnes. Les vendeurs se battent pour se différencier sur un marché très compétitif desservi par un grand nombre de fournisseurs, ce qui est loin d’être ideal. Ce que ces entreprises voudraient vraiment, en tant que fournisseur WebRTC, ce sont des pays pourvus d’une forte population, d’un grand pouvoir d’achat et d’une connectivité a internet stable et rapide. Donc, la vrai question est: ou aller pour générer de la croissance? L’Asie du nord et une partie de l’Australie/Nouvelle Zélande semblent correspondre …. a premiere vue ….

La chine est un marché énorme avec 1.3 milliards d’habitants et un P.I.B. de 11 millions de milliards (U.S.D.), mais il a ses réglementations propres et un internet ….. « regule ». [Aller faire de business en chine  est une aventure très spécifique, a la fois techniquement et légalement, qui nécessite un grand investissement en temps et en argent]. Pas nécessairement la croissance recherchée.

L’Inde arrive en deuxième position en termes de population avec 1.1 milliard de personnes. De grandes entreprises telles que Google n’ont pas fait de secret sur leur intention de tirer parti de cela pour obtenir une part énorme des futurs 1B utilisateurs. Cependant, les statistiques démographiques cachent le fait que l’Inde n’est pas un marché complètement homogène et que ses infrastructures ne sont pas développées de façon régulière sur tout le territoire. La meilleure illustration de cela est que les Philippines, comptant prés de 10 fois moins de population en âge de travailler, est passé devant l’Inde, dès 2011, pour ce qui est de la sous-traitance et n’ont cessé d’accroître cette avance depuis. En outre, le P.I.B. par habitant (plus proche approximation du pouvoir d’achat moyen par individu dans une nation) est seulement de 1.6K (U.S.D.) alors que le reste de l’Asie du Sud-est est à 4k de moyenne, la Chine à 8K, la Malaisie à 10K, la Corée du Sud et le Japon autour de 30K.

Le Japon a une population bien moins importante que l’Inde ou la Chine avec 126 Millions d’habitants. Par contre il est doté d’une économie très forte avec 4M de P.I.B.. Pour comparaison il compte 10 fois moins d’habitants que l’Inde mais une économie deux fois plus importante! C’est aussi un pays d’affaire très occidental et homogène (non le kansaï-ben n’est pas une vrai langue sauf si vous êtes un inconditionnel des kinki-kids). De plus, la proximité de la Corée du Sud et la facilité a trouver des personnes parlant couramment les deux langues permettent à beaucoup de traiter les deux marchés comme un seul (pour 48M d’habitans de plus; 1.4 milliards (U.S.D.) d’économie). Tout ceci fait du Japon un très bon point de depart pour une extension en Asie.

L’extension suivante est toutefois habituellement plus difficile a choisir.

L’Association des nations de l’Asie du Sud-Est (A.S.E.A.N), qui a débuté seulement récemment, pèse 630 millions d’habitants soit plus que l’U.E. ou l’Amerique du Nord pour un P.I.B. bien plus faible 2.5 Milliard (U.S.D.), mais toujours plus que l’Inde. L’A.S.E.A.N. représente le P.I.B. cumulé du Mexique et du Canada.

L’un des plus gros problème de l’A.S.E.A.N. est l’énorme disparité entre chaque membre de l’association. Alors que les statistiques de l’Indonésie la placent près du Mexique avec près de 1M de P.I.B., elle est loin devant le deuxième groupe de pays (Thaïlande, Malaisie, Philippines et Singapour; dans l’ordre) qui représentent chacun 0.3M de P.I.B.. Comme je l’explique plus en détail dans mon rapport, on ne peut pas couvrir tous ces pays avec un bureau et un stratégie unique. Comme « Wavecell jobs offers » (voir « ventes ») ou « Nexmo » avant eux l’illustrent, alors que vous aurez certainement un QG soit à Hong-Kong soit à Singapour pour des raisons linguistiques, juridiques et fiscales; vous devez avoir une équipe de vente dans chaque pays pour être vraiment en mesure de vendre et créer de la croissance.

ANNONCE DU CAFEX SUR SA STRATEGIE ASIATIQUE

Alors que le choix du japon comme premier point d’entr’e en Asie a beaucoup de sens, l’annonce indique également que: « la Chine, y compris Taywan, Hong-Kong et Macao, Singapour, la Malaisie, la Thaïlande et l’Australie » seront couverts par le même accord. Ce serait une vrai gageure sans compter sur la taille de leur partenaire Japonais ITOCHU. Avec plus de 4 000 employés et plus de 100 bureaux à travers le monde, ITOCHU Corporation a les épaules pour permettre a CafeX d’avoir les moyens de sa croissance. Sa division ICT et services financiers, en particulier, fournit des solutions RTC et VoiP à de nombreuses entreprises, y compris les centres d’appels, et est le véhicule ideal pour le portfolio technique de CafeX. Apres avoir vendu les produits CafeX pour le japon uniquement, ITOCHU a fait un investissement stratégique dans CafeX en décembre 2016 dont l’annonce contient une analyse intéressante du business WebRTC au japon et A.P.A.C.. La dernière annonce du week-end est juste dans la continuité de cet accord global.

CONCLUSION

Comme prévu, les fournisseurs WebRTC se tourne vers l’Asie pour la croissance. Alors que les marchés WebRTC asiatiques sont globalement inexploités, la plupart des fournisseurs se rendent compte que de se lancer seul est difficile et nécessite une véritable stratégie. Certains CPaaS, comme Nexmo ou Twilio, ont étés dans l’obligation d’y aller seuls, mais pour des raisons lie a leur execution. CPaaS, ils dependent de la connection avec les réseaux des opérateurs téléphoniques, et ont donc des le debut de leurs operations affectes des responsable telco (« carrier manager »), qui n’avait pas une fonction de vente, mais plus une fonction de liaison technique. La mise en place de partenariats et de collaborations comme effectuée par CafeX, est un très bon moyen d’aborder la vente sur les marchés asiatiques de manière douce, en particulier pour PaaS (qui ne dépendent pas directement des télécoms). Avec Itochu, CafeX a définitivement marque un grand coup.