そのため、AndroidでBoostライブラリの定期的な回帰テストを開始しました。 結果はBoostコミュニティに受け入れられました。 「承認されたテスターのリスト」に追加され、テスト結果が公式の Boost回帰テストページに公開されました(そして自動的に更新されました)。 Boostライブラリの開発者は、状況に応じてCrystaX NDKの問題を報告したり、コードを修復したりして作業を開始しました。
現在、多くのリグレッションがあり、その一部はBoostのバグが原因であり、一部はCrystaX NDKのバグが原因です。 当然、そこで停止することなく動作し続けるため、ファイルの数は時間とともに減少します。 それにもかかわらず、これはかなり重要なステップです。 テストプロセスは完全に確立され、自動モードで動作するため、AndroidでBoostを完全にサポートすることは、比較的単純な技術タスクであり、時間の問題です。 すべての関係者に回帰に注意を促し、原因がCrystaX NDKのバグである場合は、チケットを開始することをお勧めします。 もちろん、私たちもこれを行っていますが、より多くの人々が参加することで効果は明らかに高くなります。
私たちは、CrystaX NDKの助けを借りてこの結果を達成しました。CrystaXNDKは、Androidのネイティブ開発用の本格的なツールセットを作成することが主なタスクです。 ネイティブは必ずしもC / C ++ではありません。 C、C ++、POSIXなどの標準への最大限の準拠を確保するために取り組んでおり、他のプログラミング言語、フレームワーク、およびライブラリ(他のPOSIXプラットフォームで既に実装されている)のサポートが大幅に促進されます。 D、Erlang、Lisp、Ocaml、名前を付けてください-Androidのプログラミングにこれらの言語を使用することを妨げる基本的な制限はありません。 明らかに、基本ライブラリ(libcなど)の高品質な実装を提供することにより、これらの言語のランタイムおよび標準ライブラリのAndroidへの移植を大幅に促進します。 これは、既存のアプリケーションライブラリ(ffmpeg、libpng、opensslなど)にさらに当てはまります。これは、通常、プログラミング言語のランタイムよりも移植が難しくないためです。
この観点から、CrystaX NDKを使用した自動Boostテストは、Boostだけでなく、プロジェクトにとっても重要です。 下位レベルのレイヤー(libc、libmなど)のBoostライブラリは複雑で要求が厳しいため、システムライブラリの標準的な動作のテストセットとして適切であり、すべてのBoostテストに合格すると、CrystaX NDKの標準の完全なサポートについて自信を持って話すことができます。 明らかに、これはAndroidやその他の非Boostプロジェクトへの移植に役立ちます。
私は2009年にこのプロジェクトを開始し、それから自由な時間にそれを主導しました。 2012年、私の良き友人であるAlexander Zhukovが私に加わり、それ以来私たちは一緒にプロジェクトに取り組んできました。 多数の商業プロジェクトのカスタム作業を行ってお金を稼ぎ、CrystaX NDKに費やしました。 それにも関わらず、このモードでも、CrystaX NDKはGoogleのAndroid NDKよりもずっと「機能豊富」であり続けています。 主な理由は、GoogleはネイティブのAndroid開発に関心がなく、どの年に膨大な数の開発者のニーズが無視されるかです。 これは、Androidが携帯電話だけではないという事実に照らして特に興味深いものになります。 今日ではすでに非常に強力なタブレット、スマートテレビ、カーナビゲーターです。つまり、プラットフォーム間でのコードの簡単な移植性に対する要求がますます高まっています。 Googleが推奨する方法-AndroidでJavaですべてを書き換える-は、まったく軽薄です。
8か月前、すべてのサードパーティ契約を拒否し、フルタイムモードでCrystaX NDKの作業を開始しました。 私たちのプロジェクトをAndroidの完全な開発の基盤にすることができると確信しています。今日のように、Javaを強制的に使用することなく、理想的にはどの言語でも可能です。 フルタイムモードでの効率は明らかです。この8か月で、過去3年以上に進歩しました。 私たちは継続したいと考えており、膨大な数のプログラマーの間でサポートが得られると確信しています。
ご質問にお答えします。