MEGAchat
Version 7.2.1
MEGAchatの開発とコンパイルには、主にクロスプラットフォーム プロジェクト構成ツールとして CMake を使用します。また、VCPKG を使用して、Windows、MacOS、Linux などのほとんどのプラットフォームでMEGAchat構築するために必要な依存関係を管理します。
各オペレーティング システムに必要な構築ツールの詳細については、MEGA SDK リポジトリの「構築ツール」の章を参照してください。
WebRTC for Android の WebRTC Android コンパイルの詳細情報
MEGAchat動作するには、いくつかの依存関係が必要です。それらのほとんどは、構成フェーズ中に VCPKG を使用して自動的にダウンロードされ、ビルドされます。
Linux の場合、VCPKG が依存関係を構築できるように、システムにいくつかの追加ライブラリが必要です。 Debian ベースのディストリビューションの場合、次のコマンドを使用して必要なライブラリをインストールできます。
sudo apt install python3-pkg-resources libglib2.0-dev libgtk-3-dev libasound2-dev libpulse-dev
パッケージ名は Linux ディストリビューションによって異なる場合がありますが、同じライブラリを提供するパッケージを使用して正常にビルドされるはずです。
リポジトリのルートにある vcpkg.json ファイルで依存関係の完全なセットを確認できます。
MEGAchatは MEGA SDK ライブラリも必要です。 MEGAchatで使用する方法については、このドキュメントの後半で説明します。 MEGA SDK プロジェクトはMEGAchat CMake によって自動的にロードされるため、必要なのは、予想されるパスにクローンを作成するだけです。
システムにインストールする必要がある追加のオプションの依存関係は、Qt フレームワークだけです。 Qt サンプル アプリを構築する場合にのみ必要ですが、テスト、CLI サンプル、またはライブラリ自体には必要ありません。
まず、 MEGAchatを使用するための任意のディレクトリを準備します。このドキュメントの例では、 megaディレクトリがワークスペース ディレクトリとして使用されます。
mkdir mega
cd mega
ディレクトリを準備したら、 MEGAchatリポジトリのクローンを作成して、 MEGAchatソース コードを取得します。
git clone https://github.com/meganz/MEGAchat
MEGAchat動作するには MEGA SDK が必要なため、予想されるパスに MEGA SDK のクローンを作成します。
git clone https://github.com/meganz/sdk MEGAchat/third-party/mega
最後に、 MEGAchatフォルダーの隣に VCPKG リポジトリのクローンを作成します。すでに VCPKG を使用していて、リポジトリのローカル クローンがある場合は、この手順をスキップして、システム上の既存の VCPKG を使用できます。
git clone https://github.com/microsoft/vcpkg
次の手順はコマンド ライン インターフェイス (CLI) からプロジェクトを構成するためのものですが、同じ CMake パラメーターが構成されている場合は、cmake-gui または CMake と互換性のあるエディターまたは IDE が適しています。
MEGAchat 、他の通常の CMake プロジェクトと同様に構成されます。常に必要となる唯一のパラメータは、サードパーティの依存関係を管理するための VCPKG ディレクトリです。 MEGA SDK の依存関係は、 MEGAchatビルドの一部として構築されます。
MEGAchat構成するには、ワークスペース ( megaディレクトリ) から CMake を実行します。
cmake -DVCPKG_ROOT=vcpkg -DCMAKE_BUILD_TYPE=Debug -S MEGAchat -B build_dir
注 1 : -DCMAKE_BUILD_TYPE=<Debug|Release> 、Visual Studio などのマルチコンフィグ ジェネレーターには必要ない場合があります。
注 2 Qt Framework がシステムにインストールされているにもかかわらず、CMake がそれを検出できない場合は、 -DCMAKE_PREFIX_PATH=</path/to/qt/install/dir>を追加して、CMake がそれを見つけられるようにすることができます。 Qt がインストールされておらず、インストールしたくない場合は、 -DENABLE_CHATLIB_QTAPP=OFFを設定して Qt サンプル アプリを無効にすることができます。ライブラリ、CLI サンプル、およびテストは引き続きビルドされます。
上記の cmake コマンドでは、わかりやすくするために相対パスが使用されています。 VCPKG、 MEGAchat 、またはビルド ディレクトリの場所を変更する場合は、それらのいずれかに対する有効な相対パスまたは絶対パスを指定するだけです。
プロジェクトの構成中に、VCPKG はプラットフォームに必要なライブラリを構築して構成します。最初の実行には時間がかかる場合がありますが、ライブラリが構築されると、VCPKG はそれらをバイナリ キャッシュから取得します。
MEGAchatさまざまなオプションを使用して構成できます。その一部は chatlib_options.cmake ファイルにあります。例とテストを管理するためのオプションは CMakeLists.txt にあります。
MEGAchatを構成したら、完全なプロジェクトをビルドするだけです。
cmake --build build_dir
CHATlibやmegaclcのように--target=<target>を指定することも、コマンドをそのままにしてすべてのタグを構築することもできます。さらに、 -j <N>または--parallel <N>を追加して、同時実行性を管理し、ビルドを高速化することができます。
ビルドが完了すると、CMake 構成コマンドで指定されたbuild_dirでバイナリが利用可能になります。
コードの複雑さを抽象化するために、 MEGAchat新しいアプリケーションを迅速に作成できる中間層を提供します。
ドキュメントはsrc/ MEGAchat api.hで入手できます。
MEGAchatスレッド モデルは JavaScript スレッド モデルに似ています。すべてがメイン (GUI) スレッドで実行され、ブロックは決して許可されず、外部イベント (ネットワーク、タイマーなど、webrtc イベントなど) によってメイン スレッドでコールバックがトリガーされます。これが機能するためには、 MEGAchatアプリケーションのイベント ループと対話できる必要があります。これは通常、GUI アプリケーションの場合は GUI フレームワークのイベント/メッセージ ループ、コンソール アプリケーションの場合はカスタム メッセージ ループです。このメッセージ ループはプラットフォームに非常に固有であるため、メッセージ ループとMEGAchat間のインターフェイスを実装するのはアプリケーション開発者の責任です。これは実際よりも複雑に聞こえるかもしれません。インターフェイスは 2 つの部分で構成されています。 1 つは、不透明なvoid*ポインターをアプリケーションのメッセージ ループにポストするmegaPostMessageToGui(void*)関数の実装です。この関数は通常、メインスレッド以外のスレッドによって呼び出されますが、GUI スレッド自体によって呼び出すこともできます。もう 1 つの部分は、同じポインタでmegaProcessMessage(void*)を呼び出すことによって、それらのメッセージをMEGAchatに返すアプリケーションのメッセージ ループ内のコードです。これらはすべて/src/base/gcm.hおよび/src/base/gcm.hppに実装されています。これらのファイルには詳細なドキュメントが含まれています。これを Windows で実装する例は次のとおりです。 megaPostMessageToGui(void*)ユーザー メッセージ タイプを使用してPostMessage()実行し、 void*をメッセージの lParam または wParam として使用します。イベント処理のswitchステートメントには、そのメッセージ タイプのエントリ。メッセージの lParam または wParam をキャストしてvoid*ポインタを取得し、それをmegaProcessMessage(void*)に渡します。
MEGAchat 、独自の専用スレッドで実行される libuv に依存して、複数のソケットの生の I/O イベントを監視し、タイマーを実装します。また、DNS 解決や SSL ソケットなどの libuv の上位レベルの I/O 機能にも依存します。 libuv の上にある「サービス」 ( /src/base/?services*.* ) と呼ばれる薄い層が libuv と GCM の上に実装され、タイマー用のシンプルな JavaScript のような非同期 C++11 API が備わっています。 ( src/base/timer.h )、DNS 解決 ( /src/base/services-dns.hpp )、http クライアント ( /src/base/services-http.hpp ) ）。この層は元々、プレーンな C インターフェイス ( cservices*.cpp/hファイル) を備えた下位レベルのコンポーネントを持つように設計されており、異なるコンパイラで構築された複数の DLL と高レベルのヘッダーのみの C でサービスを使用できるようになりました。フロントエンドであり、パブリック API を含む ++11 レイヤー - これらは .hpp ファイルです。
MEGAchatのすべてのネットワーク ライブラリ (libcurl) は、ネットワーク操作とタイマーに libuv を使用します (C ライブラリは libuv を直接使用し、C++ コードは C++11 レイヤー (つまりtimers.hpp ) を使用します)。 SDK ユーザーにも同じことを行うことを強くお勧めします。ただし、たとえば、専用のワーカー スレッドをソケット上でブロックし、GCM 経由で GUI スレッドにイベントをポストすることは可能です。
使用パターンは次のとおりです。特定のイベント (ソケット I/O イベント、タイマーなど) に対してコールバックが登録され、イベントの発生時にそのコールバックがlibuv スレッドによって呼び出されます。イベントが、コールバックが呼び出されるライブラリの外部、特に GUI に伝播する可能性がある場合は、ある時点で、GCM メカニズムを使用してイベント処理を GUI スレッドにマーシャリングする必要があります。ただし、イベントが内部的なものであり、ライブラリの外部に伝播することがない場合は、libuv スレッドのコンテキストで直接処理できます (ブロックしない限り)。これにより、GUI スレッドにマーシャリングするパフォーマンス コストが節約され、イベントが高頻度で発生する場合 (たとえば、データをバッファに追加するだけでよい受信データ チャンク イベントなど) に推奨されます。転送が完了すると、転送ごとに 1 回、完了イベントを GUI スレッド上でマーシャリングし、両方のアプローチの利点を組み合わせます。
MEGAchatには、カラーによるファイルおよびコンソールのログ記録、ログ ファイルのローテーション、それぞれが個別のログ レベルを持つ複数のログ チャネルをサポートする高度なログ機能があります。ログ レベルは、コンパイル時 (つまり、ログ マクロを無効にすることによって) ではなく、実行時 (起動時) に設定されます。これにより、リリースで構築されたアプリであらゆるチャネルの完全なデバッグ ログを有効にすることができます。ログ チャネルは、src/base/loggerChannelConfig.h で定義され、デフォルトで構成されます。このファイルには詳細なドキュメントが含まれています。便宜上、各チャネルの専用ロギング マクロは通常、それを使用するコード内で定義されます。例については、karereCommon.h の XXX_LOG_DEBUG/WARN/ERROR マクロを参照してください。 SDK ユーザーは、必要に応じて追加のログ チャネルを自由に作成できます。 GUI ログ チャネルはすでに定義されています。ログ チャネル構成は、実行時に KRLOG 環境変数によって上書きできます。その形式は次のとおりです。
KRLOG=<chan name>=<log level>,<chan name2>=<log level2>...
ログ レベルは、「off」、「error」、「warn」、「info」、「verbose」、「debug」、「debugv」です。
特別なチャネル名が 1 つあります - 「all」です。このチャネルのログ レベルを設定すると、すべてのチャネルのログ レベルが設定されます。これにより、たとえば、次の方法で 1 つ (または少数) を除くすべてのチャンネルを簡単に沈黙させることができます。
KRLOG=all=warn,mychannel=debug,myotherchannel=info
同じチャンネルを複数回設定でき、最後の設定のみが有効になるため、上記のトリックが可能になります。
MEGAchat 、 main()が入力される前に、ログ ファイルの作成場所を確認し、ログ記録をできるだけ早く開始するために、コンパイル時にアプリケーションによって関数karere::getAppDir()が定義される必要があります。 MEGAchatが静的ライブラリとして構築されている場合、これは問題ありません。動的ライブラリの場合、この関数は弱いシンボルである必要があります。そのため、 MEGAchat自体は関数実装なしでコンパイルでき、アプリの起動時にMEGAchat共有ライブラリが読み込まれるときに実装がリンクされます。弱いシンボルは実際にはコンパイラ間で移植可能ではないため、これが問題になる可能性があります。ただし、これらは gcc と Clang の両方でサポートされています。弱いシンボルがサポートされていない場合は、karer e を静的ライブラリとして構築する必要があります。
base/promise.hの Promise ライブラリと/src/test-promise.cppなどの使用例/src/base/timers.hppのsetTimeout()およびsetInterval()タイマー関数marshallCall()関数は、ワーカー スレッドから GUI スレッドへのラムダ呼び出しをマーシャリングします。使用例は、 /src/webrtcAdapter.hやさまざまな場所で見ることができます。このメカニズムは、GUI スレッドで実行される高レベルのコードでは直接必要ありません。/src/chatClient.h;.cpp内の全体的なクライアント構造megaPostMessageToGui()の実装方法、「サービス」の開始方法、およびMEGAchatクライアントのインスタンス化方法を示します。また、 getAppDir()メソッドを実装する方法も示します。このメソッドは、 main()に入る前にログ ファイルを作成し、できるだけ早くログを開始するためにMEGAchatライブラリで必要となる弱いシンボルです。src/rtcModile/IRtcModule.hのビデオ モジュールのパブリック インターフェイスと関連ヘッダーmegaPostMessageToGui()として参照されますが、署名がextern "C" void(void*)である限り、任意の名前を付けることができます。 。この機能は、 MEGAchat依存するメッセージ パッシング メカニズム (Gui Call Marshaller (GCM) と呼ばれる) の中心です。この関数へのポインタをservices_init()に渡す必要があります。
