Pour le développement et la compilation de MEGAchat , nous utilisons principalement CMake comme outil de configuration de projet multiplateforme. Nous utilisons également VCPKG pour gérer les dépendances requises pour créer MEGAchat sur la plupart des plateformes : Windows, MacOS et Linux.
Pour plus de détails sur les outils de création nécessaires pour chaque système d'exploitation, consultez le chapitre Outils de création dans le référentiel MEGA SDK.
Plus d'informations sur la compilation WebRTC Android dans WebRTC pour Android
MEGAchat nécessite certaines dépendances pour fonctionner. La plupart d'entre eux sont automatiquement téléchargés et construits à l'aide de VCPKG pendant la phase de configuration.
Pour Linux, certaines bibliothèques supplémentaires sont nécessaires dans le système afin que VCPKG puisse créer les dépendances. Pour les distributions basées sur Debian, vous pouvez installer les bibliothèques nécessaires à l'aide de la commande suivante :
sudo apt install python3-pkg-resources libglib2.0-dev libgtk-3-dev libasound2-dev libpulse-dev
Les noms des packages peuvent varier selon les différentes distributions Linux, mais ils devraient être construits avec succès avec des packages fournissant les mêmes bibliothèques.
Vous pouvez consulter l'ensemble complet des dépendances dans le fichier vcpkg.json à la racine du référentiel.
MEGAchat a également besoin de la bibliothèque MEGA SDK. Il y a des instructions plus loin dans ce document sur la façon de l'utiliser avec MEGAchat . Le projet MEGA SDK est automatiquement chargé par le MEGAchat CMake, il vous suffit donc de le cloner simplement dans le chemin attendu.
Il n'y a qu'une seule dépendance facultative supplémentaire qui doit être installée sur le système : le framework Qt. Il est uniquement nécessaire de créer l'exemple d'application Qt, mais ce n'est pas requis pour les tests, l'exemple CLI ou la bibliothèque elle-même.
Tout d'abord, préparez un répertoire de votre choix pour travailler avec MEGAchat . Le mega
répertoire sera utilisé comme répertoire de l'espace de travail dans les exemples de ce document.
mkdir mega
cd mega
Après avoir préparé le répertoire, clonez le référentiel MEGAchat pour obtenir le code source MEGAchat .
git clone https://github.com/meganz/MEGAchat
Comme MEGAchat nécessite le MEGA SDK pour fonctionner, clonez le MEGA SDK dans le chemin attendu.
git clone https://github.com/meganz/sdk MEGAchat/third-party/mega
Enfin, clonez le référentiel VCPKG à côté du dossier MEGAchat . Si vous utilisez déjà VCPKG et que vous disposez d'un clone local du référentiel, vous pouvez ignorer cette étape et utiliser le VCPKG existant sur votre système.
git clone https://github.com/microsoft/vcpkg
Les instructions suivantes servent à configurer le projet à partir de l'interface de ligne de commande (CLI), mais cmake-gui ou tout éditeur ou IDE compatible avec CMake devrait convenir si les mêmes paramètres CMake sont configurés.
MEGAchat est configuré comme n'importe quel autre projet CMake classique. Le seul paramètre toujours nécessaire est le répertoire VCPKG pour gérer les dépendances tierces. La dépendance MEGA SDK est construite dans le cadre de la version MEGAchat .
Pour configurer MEGAchat , depuis l'espace de travail ( mega
répertoire), exécutez CMake :
cmake -DVCPKG_ROOT=vcpkg -DCMAKE_BUILD_TYPE=Debug -S MEGAchat -B build_dir
Note 1 : Le -DCMAKE_BUILD_TYPE=<Debug|Release>
peut ne pas être nécessaire pour les générateurs multiconfig, comme Visual Studio.
Remarque 2 Si Qt Framework est installé sur votre système mais que CMake ne parvient pas à le détecter, vous pouvez ajouter -DCMAKE_PREFIX_PATH=</path/to/qt/install/dir>
afin que CMake puisse le localiser. Si Qt n'est pas installé et que vous préférez ne pas l'installer, vous pouvez désactiver l'exemple d'application Qt en définissant -DENABLE_CHATLIB_QTAPP=OFF
. La bibliothèque, l'exemple CLI et les tests seront toujours construits.
Dans la commande cmake ci-dessus, des chemins relatifs ont été utilisés pour plus de simplicité. Si vous souhaitez modifier l'emplacement de VCPKG, MEGAchat ou du répertoire de construction, fournissez simplement un chemin relatif ou absolu valide pour chacun d'entre eux.
Lors de la configuration du projet, VCPKG construira et configurera les bibliothèques nécessaires à la plateforme. Cela peut prendre un certain temps lors de la première exécution, mais une fois les bibliothèques créées, VCPKG les récupérera du cache binaire.
MEGAchat peut être configuré avec différentes options, dont certaines se trouvent dans le fichier chatlib_options.cmake. Les options pour gérer les exemples et les tests se trouvent dans le fichier CMakeLists.txt.
Une fois MEGAchat configuré, construisez simplement le projet complet :
cmake --build build_dir
Vous pouvez spécifier --target=<target>
comme CHATlib
ou megaclc
, ou simplement laisser la commande telle quelle pour construire tous les tagets. De plus, -j <N>
ou --parallel <N>
peuvent être ajoutés pour gérer la concurrence et accélérer la construction.
Une fois la construction terminée, les binaires seront disponibles dans le build_dir
, qui a été spécifié dans la commande de configuration CMake.
Pour abstraire la complexité du code, MEGAchat fournit une couche intermédiaire qui permet de créer rapidement de nouvelles applications.
La documentation est disponible sur src/ MEGAchat api.h
Le modèle de thread MEGAchat est similaire au modèle de thread javascript : tout s'exécute dans le thread principal (GUI), le blocage n'est jamais autorisé et les événements externes (réseau, minuteries, etc., événements webrtc, etc.) déclenchent des rappels sur le thread principal. Pour que cela fonctionne, MEGAchat doit être capable d'interagir avec la boucle d'événements de l'application - il s'agit généralement de la boucle d'événements/messages du framework GUI dans le cas d'une application GUI, ou d'une boucle de messages personnalisée dans le cas d'une application console. Cette boucle de messages étant très spécifique à la plateforme, il est de la responsabilité du développeur de l'application d'implémenter l'interface entre celle-ci et MEGAchat . Cela peut paraître plus compliqué qu'il ne l'est en réalité : l'interface se compose de deux parties. Une partie est l'implémentation de la fonction megaPostMessageToGui(void*)
, qui publie un pointeur void*
opaque vers la boucle de messages de l'application. Cette fonction est normalement appelée par des threads autres que le thread principal, mais peut également être appelée par le thread GUI lui-même. L'autre partie est le code dans la boucle de messages de l'application qui reconnaît ce type de messages et les renvoie à MEGAchat , en appelant megaProcessMessage(void*)
avec ce même pointeur - cette fois dans le contexte du thread principal (GUI). Tout cela est implémenté dans /src/base/gcm.h
et /src/base/gcm.hpp
. Ces fichiers contiennent une documentation détaillée. Un exemple d'implémentation de ceci sous Windows est : megaPostMessageToGui(void*)
ferait un PostMessage()
avec un type de message utilisateur, et le void*
comme lParam ou wParam du message, et dans l'instruction switch
de traitement d'événement, il y aura une entrée pour ce type de message, obtenant le pointeur void*
en convertissant le lParam ou le wParam du message et en le transmettant à megaProcessMessage(void*)
.
MEGAchat s'appuie sur libuv, exécuté dans son propre thread dédié, pour surveiller plusieurs sockets pour les événements d'E/S bruts et pour implémenter des minuteries. Il s'appuie également sur les fonctionnalités d'E/S de niveau supérieur de libuv telles que la résolution DNS et les sockets SSL. Une fine couche au-dessus de libuv, appelée « services » ( /src/base/?services*.*
) est implémentée au-dessus de libuv et du GCM pour avoir des API C++11 asynchrones simples de type javascript pour les minuteries. ( src/base/timer.h
), résolution DNS ( /src/base/services-dns.hpp
), client http ( /src/base/services-http.hpp
). Cette couche a été conçue à l'origine pour avoir un composant de niveau inférieur avec une interface C simple (fichiers cservices*.cpp/h
), afin que les services puissent être utilisés par plusieurs DLL construites avec différents compilateurs, et un C de haut niveau uniquement avec en-tête. Couche ++11 qui est le frontend et contient l'API publique - ce sont les fichiers .hpp.
Toutes les bibliothèques réseau de MEGAchat (libcurl) utilisent libuv pour le fonctionnement du réseau et les minuteries (les bibliothèques C utilisent directement libuv, le code C++ utilise la couche C++11, c'est-à-dire timers.hpp
). Il est fortement recommandé à l'utilisateur du SDK de faire de même, bien qu'il soit possible par exemple d'avoir un thread de travail dédié bloquant sur un socket, et publiant des événements sur le thread GUI via le GCM.
Le modèle d'utilisation est le suivant : un rappel est enregistré pour un certain événement (événement d'E/S de socket, minuterie, etc.), et ce rappel est appelé par le thread libuv lorsque l'événement se produit. Si l'événement peut se propager en dehors de la bibliothèque dont le rappel est appelé, et en particulier vers l'interface graphique, alors, à un moment donné, le traitement des événements doit être marshallé vers le thread de l'interface graphique, à l'aide du mécanisme GCM. Cependant, si l'événement est interne et ne se propage jamais en dehors de la bibliothèque alors il peut être géré directement dans le contexte du thread libuv (à condition qu'il ne le bloque jamais). Cela permet d'économiser le coût de performance lié au marshalling vers le thread de l'interface graphique, et est recommandé si l'événement se produit à une fréquence élevée, par exemple un événement de bloc de données entrant qui n'a besoin que des données ajoutées à un tampon. Une fois le transfert terminé, un événement d'achèvement peut être organisé sur le thread GUI une fois par transfert, combinant les avantages des deux approches.
MEGAchat dispose d'une fonction de journalisation avancée qui prend en charge la journalisation des fichiers et de la console avec couleur, rotation des fichiers journaux, plusieurs canaux de journalisation, chacun avec un niveau de journalisation individuel. Les niveaux de journalisation sont configurés au moment de l'exécution (au démarrage) et non au moment de la compilation (c'est-à-dire pas en désactivant les macros de journalisation). Cela permet à une application intégrée à la version d'activer la journalisation de débogage complète pour tous les canaux. Les canaux de journal sont définis et configurés par défaut dans src/base/loggerChannelConfig.h. Le fichier contient une documentation détaillée. Pour plus de commodité, les macros de journalisation dédiées à chaque canal sont généralement définies dans le code qui l'utilise - voir les macros XXX_LOG_DEBUG/WARN/ERROR dans karereCommon.h pour des exemples. L'utilisateur du SDK est libre de créer des canaux de journal supplémentaires si nécessaire. Un canal de journal GUI est déjà défini. La configuration du canal de journal peut être remplacée au moment de l'exécution par la variable d'environnement KRLOG. Son format est le suivant :
KRLOG=<chan name>=<log level>,<chan name2>=<log level2>...
Les niveaux de journalisation sont « off », « error », « warn », « info », « verbeux », « debug », « debugv ».
Il existe un nom de chaîne spécial : « tout ». La définition du niveau de journalisation de ce canal définit les niveaux de journalisation de tous les canaux. Cela permet par exemple de mettre facilement sous silence tous les canaux sauf un (ou quelques-uns), en :
KRLOG=all=warn,mychannel=debug,myotherchannel=info
Le même canal peut être configuré plusieurs fois, et seul le dernier paramètre sera efficace, ce qui rend l'astuce ci-dessus possible.
MEGAchat nécessite que la fonction karere::getAppDir()
soit définie par l'application au moment de la compilation, afin de savoir où créer le fichier journal et commencer la journalisation le plus tôt possible, avant que main()
ne soit saisie. Si MEGAchat est construit comme une bibliothèque statique, ce n'est pas un problème. Dans le cas d'une bibliothèque dynamique, cette fonction doit être un symbole faible, afin que MEGAchat lui-même puisse se compiler sans l'implémentation de la fonction, et que l'implémentation soit liée lorsque la bibliothèque partagée MEGAchat est chargée au démarrage de l'application. Les symboles faibles ne sont pas vraiment portables entre les compilateurs, et cela peut poser un problème. Cependant, ils sont pris en charge à la fois par gcc et par clang. Si aucun symbole faible n'est pris en charge, karer e doit être construit en tant que bibliothèque statique.
base/promise.h
et un exemple d'utilisation, par exemple dans /src/test-promise.cpp
setTimeout()
et setInterval()
dans /src/base/timers.hpp
marshallCall()
rassemble les appels lambda d'un thread de travail vers le thread GUI. Des exemples d'utilisation peuvent être vus par exemple dans /src/webrtcAdapter.h
et à de nombreux endroits différents. Ce mécanisme ne devrait pas être directement nécessaire dans le code de haut niveau qui s'exécute dans le thread GUI./src/chatClient.h;.cpp
megaPostMessageToGui()
, comment démarrer les « services » et comment instancier le client MEGAchat . Montre également comment implémenter la méthode getAppDir()
, qui est un symbole faible nécessaire à la bibliothèque MEGAchat afin de créer le fichier journal et de commencer la journalisation le plus tôt possible, avant la saisie main()
.src/rtcModile/IRtcModule.h
et les en-têtes associésmegaPostMessageToGui()
, mais elle peut avoir n'importe quel nom, à condition que la signature soit extern "C" void(void*)
. Cette fonction est au cœur du mécanisme de transmission de messages (appelé Gui Call Marshaller, ou GCM) sur lequel s'appuie MEGAchat . Vous devez passer un pointeur vers cette fonction à services_init()
.