C++ の Hello World とローズゴールドで囲まれた運命の庭園

これは、クロス コンパイルに関する私のシリーズのパート 3 です。最初にパート 1 1 とパート 2 2 をチェックアウトできます!

3 番目の主要な、実際には 2 番目のデスクトップ オペレーティング システムを無視して、Windows および Linux ユーザーのニーズに応えることはできません。

私が話しているオペレーティング システムは、もちろん、Clang を世界に提供した会社として最もよく知られている会社によって開発および商品化されており、(業界のほとんどが Chromium に移行した後) WebKit の維持を主に担当しており、その他のオペレーティング システムも作成しています。 CUPS などの素晴らしいオープン ソース ソフトウェア。

そして、そのことに感謝すべきです。

より良いユーザー エクスペリエンスを提供するために完全に新しいコンパイラを開始するのに苦労した会社は、自社のプラットフォームへのクロスコンパイルを容易にするだろうと考えるでしょう。

ただし。

その会社はアップルです。

Linux や Windows と同様に、3 つの部分を取得してセットアップする必要があります。コンパイラ、いくつかのシステム ヘッダー、libc++ などのライブラリ、およびデスクトップ統合用の Sdk。

以前に OS X の開発を行ったことがある場合は、そのすべてが XCode に含まれていることをご存知でしょう。これは、バンドルされたツールの 5 GB パッケージであり、そのほとんどは必要ありません。

XCode はフリーソフトウェアです。ビールのように。たくさん必要になります。ただし、XCode はプロプライエタリなので問題ありません。

問題は、XCode に添付されている利用規約を読むと、次の条項が見つかることです。

2.7 制限;その他の許可された使用の禁止 本契約に定められた許諾は、Apple ブランド以外のコンピュータまたはデバイスに Apple ソフトウェアまたは Apple サービスをインストール、使用、または実行すること、または他者がそうできるようにすることをお客様に許可するものではなく、またお客様はそれらを行わないことに同意するものとします。

私は弁護士ではありません。しかし、Apple は、技術的な実行可能性に関係なく、ライブラリを使用したクロスコンパイルを積極的に禁止しているように私には思えます。

したがって、この記事の残りの部分で説明するアイデアの一部を適用すると、Apple との契約が無効になる可能性があります。

Apple ID が必要なので、apple.com でアカウントを作成する必要があります。しばらくの間、これほどひどいアカウント作成体験をした覚えはありません。最大の攻撃は、時代遅れのセキュリティ ポリシーです。

その後、確認のためにメールが送信されます。これは素晴らしいことです。ただし、電子メールにリンクが含まれている代わりに、貼り付けることもできず、手動で入力する必要があるコードが表示されます。

次に、XCode を検索します。幸いなことに、善良なサマリア人の中には、2012 年以降 Stackoverflow で有効なダウンロード リンクを維持している方もいます。

これは再び「すべてのソフトウェアはひどい」という暴言に変わりました。すみません。

よりポジティブな点として、誰かが Unix で OsX ツールチェーンの構築を開始するためのスクリプトの素晴らしいコレクションを既にセットアップしています。 Cygwin でも動作します!

クローンを作成する必要があります。cor3ntin/osxcross - Linux、BSD、および Windows 用の OS X クロス ツールチェーン

これは、私がパッチを当てなければならなかった Thomas Pöchtrager の作品からのフォークです。

XCode 7.3 は DMG として出荷されます。これは osx 固有のファイル形式ですが、osxcross にはそれを抽出するスクリプトが付属しており、Darling をうまく利用しています。 .詳細は後述します。

osxcross/tools/gen_sdk_package.sh Xcode_xxx.dmg

残念ながら、オープン ソース コミュニティは、sdk で .dylib を出荷する必要がないように、OSX の新しいバージョンで使用される TBD ファイル v2 をサポートする ld64 リンカーを Apple がリリースするのをまだ待っています。

TBD ファイルはかなりクールです。動的ライブラリに含まれるシンボルの YAML 表現であり、実際のライブラリを出荷する必要がありません。これらは、DLL のビルド時に MSVC によって生成される .lib ファイルと概念がよく似ています。 TBD ファイルはプラットフォーム間で使用できると思いますが、今のところ LLVM はそれらを処理できず (まだ?)、オープンソースの ld64 は新しいバージョンを処理できません.

そのため、10.11 SDK に固執する必要があります。合理的です! XCode の新しいバージョンをパッケージ化するために使用される xip ファイルをサポートするのに苦労しました。おばあさん人形にインスパイアされた形式ですが、代わりに圧縮されたアーカイブが含まれています。残念ながら、XCode 7.3 より新しいものは使用できません。すぐに変わることを願っています!

次に、生成された MacOSX10.11.sdk.tar.xz を osxcross/tarballs に移動し、SDK_VERSION=10.11 ./osxcross/build.sh を起動します。

osxcross/build_llvm_dsymutil.sh も実行する必要があります。

そしてすぐに、i386 と x86_64 の両方に対応する OSX 用の完全なツールチェーンを手に入れることができます (OSX をターゲットとする場合、32 ビットで何かをビルドする理由がまったくない場合でも)。

それは、私の個人的なお気に入りである otool と install_name_tool をビルドします。 OSX で何かを構築したことがあるなら、これらのツールがいかにひどいものであるかをご存知でしょう。というか、OSX ローダーの恐ろしさ。

osxcross に費やされた作業には適切に感銘を受けました .

QBS の構成はかなり簡単ですが、注意すべき点がいくつかあります。

osxcross/target/bin で 、実行:

ln -s x86_64-apple-darwin15-ld ld
cp osxcross-llvm-dsymutil x86_64-apple-darwin15-dsymutil

これは後で適切なツールを見つけるのに役立ちます。複数のツール チェーンをサポートする場合は、ldin をサブフォルダーに配置します

あなたが適応できるよりも私のプロフィール設定はここにあります

qt-project\qbs\profiles\clang-osx-x86_64\qbs\architecture=x86_64
qt-project\qbs\profiles\clang-osx-x86_64\qbs\toolchain=unix,clang,llvm,gcc
qt-project\qbs\profiles\clang-osx-x86_64\qbs\targetOS=macos,darwin
qt-project\qbs\profiles\clang-osx-x86_64\cpp\compilerName=clang++
qt-project\qbs\profiles\clang-osx-x86_64\cpp\driverFlags=--prefix,/home/cor3ntin/dev/cross-compilers/osx/osxcross/target/bin/
qt-project\qbs\profiles\clang-osx-x86_64\cpp\minimumMacosVersion=10.11
qt-project\qbs\profiles\clang-osx-x86_64\cpp\compilerPathByLanguage.cpp=/home/cor3ntin/dev/cross-compilers/osx/osxcross/target/bin/x86_64-apple-darwin15-clang++
qt-project\qbs\profiles\clang-osx-x86_64\cpp\compilerPathByLanguage.c=/home/cor3ntin/dev/cross-compilers/osx/osxcross/target/bin/x86_64-apple-darwin15-clang
qt-project\qbs\profiles\clang-osx-x86_64\cpp\toolchainInstallPath=/home/cor3ntin/dev/cross-compilers/osx/osxcross/target/bin
qt-project\qbs\profiles\clang-osx-x86_64\cpp\systemIncludePaths=/home/cor3ntin/dev/cross-compilers/osx/osxcross/target/SDK/MacOSX10.11.sdk/usr/include/c++/v1
qt-project\qbs\profiles\clang-osx-x86_64\cpp\libraryPaths=/home/cor3ntin/dev/cross-compilers/osx/osxcross/target/SDK/MacOSX10.11.sdk/usr/lib,/home/cor3ntin/dev/cross-compilers/osx/osxcross/target/SDK/MacOSX10.11.sdk/usr/lib/system
qt-project\qbs\profiles\clang-osx-x86_64\cpp\toolchainPrefix=x86_64-apple-darwin15-

-prefix オプションは、clang に適切な ld(ld64) を見つける場所を指示します。これは、システム リンカーが Mach-O アプリケーションをリンクするのに適していないためです。

残りは、qbs に適切な検索パスを与えるだけです。

残念ながら、qbs での .plist のサポートは移植性がないため、エラーが発生します

ERROR: TypeError: Result of expression 'PropertyList' [[object Object]] is not a constructor.
 at JavaScriptCommand.sourceCode
 at Rule.prepare in /opt/qtcreator/share/qbs/modules/cpp/DarwinGCC.qbs:262:18

問題を解決するには、DarwinGCC.qbs のルールをコメントアウトしてください。

もちろん、info.plist ファイルを作成できないことは非常に制限的であり、QBS がこれらのファイルをプラットフォームにとらわれない方法で処理できれば素晴らしいことです。

今のところ、すべての .qbs プロジェクト ファイルで、以下を配置してバンドルを無効にし、Info.plist の生成を無効にします

Depends {
 name: "bundle"
}
bundle.isBundle: false

その時点で、パート 1 で見た単純なコンソールの Hello World を構築できます。

# file helloworld
Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|PIE>

しかし、それは実行できますか?

ああ、ダーリン!

Windows アプリケーションを実行するために、wine を使用しました。かなり最近の取り組みがあります — それは 2012 年に始まり、WINE は 1993 年に始まりました。 Windows 3.1 がリリースされました! — darling. と呼ばれる翻訳レイヤを提供します。 プロジェクトはそれほど成熟しておらず、財政的な支援もないようです。 Darling - Linux 用の macOS 翻訳レイヤー

ダーリンのクローンを作成してビルドできます。github の指示に従ってください。私のマシンでは、全体で 1 時間弱かかりました。インストールすると、約800MBになります。これは、g++、ruby、python、Perl、git、bash、swift、ssh などの通常のツールがすべて付属する完全なシステムであるため、当然のことです。

しかし、ビルドはエラーなしで完了し、驚くべきことに、それは機能し、非常に反応が良いようです。そのワインはより現代的で、コンテナ化されています!

binfmt による魔法の追加

これで mac コマンドを実行できるようになりましたが、魔法を隠すことができたらどうでしょうか?

カーネル機能と systemd サービスを使用して、カーネルが Mach-O ファイルの起動を処理できるように、ファイル /etc/binfmt.d/darling.conf を作成することができました。

:Mach-O 64b:M::\xcf\xfa\xed\xfe::/usr/bin/darling_interpreter:
:Mach-O 32b:M::\xce\xfa\xed\xfe::/usr/bin/darling_interpreter:
:Mach-O FAT:M::\xca\xfe\xba\xbe::/usr/bin/darling_interpreter:

/usr/bin/darling_interpreter darling shell を起動するスクリプトです - 実行可能である必要があります。

#!/bin/bash
/usr/local/bin/darling shell "$1"

最愛のドキュメントは、最愛の が機能するはずだと示唆していますが、機能しません。

binfmt サービスを再起動した後 ( systemctl restart systemd-binfmt )、OSX アプリケーションを透過的に起動できます。

つまり、私たちはこれを行うことができます

ところで、Windows の実行可能ファイルと WINE についても同じことができます。一部のディストリビューションでは、そのまま使用できます。

パート 2 では、Windows を使用せずに Linux に Qt Framework の win32 バージョンをインストールしようとしました。失敗しました。

Mac なしで Qt for Mac を入手できますか?

インストーラーをダウンロードしました。 .dmg です。それは問題ですが、最愛の人の力で、Linux に DMG をマウントできます。全く問題無い。それが私たちがここで行っていることです。

しかし、Qt インストーラー dmg をマウントすると、単純なフォルダーや管理可能なものではなく、バイナリと .dat ファイルが含まれていることがわかります。

おそらく、バイナリはインストーラーです。多分それはダーリンで実行されますか?いいえ。OpenGL フレームワークに大きく依存しています。

使い物にならない安っぽいパッケージにバンドルされた優れたソフトウェアは、繰り返されるテーマのようです。

すべての希望は再び失われましたか?今回は違います。

Windows で試みたように、Mac 用の Qt をビルドできます。しかし、それはうまくいきます。 Mac は make を持っています。これは、clang と gcc を認識しており、多くの点で Linux に非常によく似ています。結局のところ、その下には UNIX があります (しかし、OSX の内部はひどいものであり、優れたユーザー インターフェイスの下に隠されていると常に感じていました。まず、上流のバージョンが GPLv3、10 に移行した後、多数のツールがメンテナンスされていません。数年前).

残念ながら、これは Qt の複雑なビルド システムを扱うことを意味します。 qmake ビルド ファイルのハッキングには時間がかかりました。 Qt は、osx 上のすべてのツールチェーンに xcode が含まれているという恐ろしい仮定を立てています。 xcode はありません。

しかし、システムにインストールされているものに関するすべての自動調査と仮定をバイパスすると…

…あなたはそれを働かせることができます!

#configure -release -opensource -confirm-license -xplatform macx-cross-clang -skip qtwebengine -nomake examples -nomake tests -prefix /home/cor3ntin/dev/cross-compilers/osx/qt5_10
Building on: linux-g++ (x86_64, CPU features: mmx sse sse2)
Building for: macx-cross-clang (x86_64, CPU features: cx16 mmx sse sse2 sse3 ssse3)
Configuration: cross_compile sse2 aesni sse3 ssse3 sse4_1 sse4_2 avx avx2 avx512f avx512bw avx512cd avx512dq avx512er avx512ifma avx512pf avx512vbmi avx512vl compile_examples f16c largefile precompile_header rdrnd shani shared qt_framework rpath release c++11 c++14 c++1z concurrent dbus no-pkg-config reduce_exports stl
Build options:
 Mode ................................... release
 Optimize release build for size ........ no
 Building shared libraries .............. yes
 Using C++ standard ..................... C++1z
 Using ccache ........................... no
 Using gold linker ...................... no
 Using precompiled headers .............. yes
 Using LTCG ............................. no
 App store compliance ................... no
Qt modules and options:
 Qt Concurrent .......................... yes
 Qt D-Bus ............................... yes
 Qt D-Bus directly linked to libdbus .... no
 Qt Gui ................................. yes
 Qt Network ............................. yes
 Qt Sql ................................. yes
 Qt Testlib ............................. yes
 Qt Widgets ............................. yes
 Qt Xml ................................. yes
Qt Network:
 CoreWLan ............................... yes
 .....
Qt Gui:
 FreeType ............................... yes
 Using system FreeType ................ no
 HarfBuzz ............................... yes
 Using system HarfBuzz ................ no
 Fontconfig ............................. no
 Image formats:
 GIF .................................. yes
 ICO .................................. yes
 JPEG ................................. yes
 Using system libjpeg ............... no
 PNG .................................. yes
 Using system libpng ................ no
 EGL .................................... no
 OpenVG ................................. no
 OpenGL:
 Desktop OpenGL ....................... yes
 OpenGL ES 2.0 ........................ no
 Vulkan ................................. no
 Session Management ..................... yes
Qt Widgets:
 GTK+ ................................... no
 Styles ................................. Fusion macOS Windows
Qt PrintSupport:
 CUPS ................................... yes
Qt QML:
 QML interpreter ........................ yes
 QML network support .................... yes
Qt Quick:
 Direct3D 12 ............................ no
 AnimatedImage item ..................... yes
 Canvas item ............................ yes
 Support for Qt Quick Designer .......... yes
 Flipable item .......................... yes
 GridView item .......................... yes
 ListView item .......................... yes
 Path support ........................... yes
 PathView item .......................... yes
 Positioner items ....................... yes
 ShaderEffect item ...................... yes
 Sprite item ............................ yes
Note: Also available for Linux: linux-clang linux-icc

Note: No wayland-egl support detected. Cross-toolkit compatibility disabled.

Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into '/home/cor3ntin/dev/cross-compilers/osx/qt5_10'.

Prior to reconfiguration, make sure you remove any leftovers from
the previous build.

それは道の終わりではありませんでした。依存関係が見つからないため、Qt ウィジェットをビルドできませんでした。 libc++ヘッダーが古すぎるか壊れているため、QtLocationはビルドに失敗しました(OSX SDK内の最新のlibc++バージョンをコピーすることで修正しました。うまくいきました)。その後、std::auto_ptr が定義されていないために QtLocation が不平を言ったので、いくつかのヘッダーをハッキングしました。

qwebengine(chromium) をビルドしようとしましたが、まだ別のビルド システムを使用しており、ビルド システムのハッキングは一晩で十分でした。

しかし、最終的に Qt のほとんどはビルドされました。

そして、私たちが持っているものは、非常に興味深いものです。バイナリはネイティブの Linux ELF ですが、フレームワークとライブラリは Macho-O です。すぐに使えます。

Qt は、OS 統合という点で、基盤となるシステム機能をフルに活用する大きなソフトウェアです。それを構築できれば、ほとんど何でも構築できます。

最初に、mkspec ファイルを darling-clang と呼びました。私は悪名でした。また、それが Mac ビルドであることを qbs が認識できなくなりました。 mkspec の名前を変更して Qt を再構築するのではなく、qbs を変更しました。 qbs-setup-qt のコードは、実際には mkspec の .conf ファイルを正規表現で解析しています。どういうわけか、それは動作します。息を吸わないでください。

最終的に、私たちが mac を扱っていることを理解するために qbs が期待するものを与えると、私は呼び出すことができました

qbs-setup-qt osx/qt5_10/bin/qmake osx-x64-qt510

これにより、適切なプロファイルとモジュールが作成されました。プロファイルを手動でクリーンアップして、clang-osx と osx-x64-qt510 をマージしました

そして、Hello World をコンパイルまたは壮大にすることができます アプリ!

さて、私たちは完全なツールチェーンを持っています。いくつか確認できることはありますか?

他のツールを使用できます。 nm や文字列、恐ろしい install_name_tool など .

残念ながら、Darling はまだリモートでグラフィカルな処理を行うことができないため、アプリを実際に起動するには Mac が必要です。

本物のマック。 Mac 上でない限り、Mac OSX を視覚化することは違法です。いくつかの言葉が思い浮かびます。私のフランス語を想像してみてください。

マックについて話しましょう。 マック .あなたはおそらくそれを知っています。ほとんどの企業はそれを持っています。

以前はボブのものでした。ボブのマックです。しかし、5 年前にボブが亡くなったので、Mac アリスに提供されました。 Alice はその後すぐに会社を辞めました - まったくの偶然でしょう.

まだ Mac 常にMacだった .マスターはありません。人形もありません。 ssh [email protected] で接続できます。パスワードは単純に pass です。どこかの仮想マシンで実行されている他のサーバーと同じ LAN にはありません。とにかく管理されておらず、厳重に保護されたネットワークに便利なバックドアを提供しています.

実行中の場合。一度に何日もダウンすることもあります。人々が気にしないだけでなく、物理的にどこにあるかも知りません。 Mac mini は簡単に紛失します。誰かの机の下で、古い椅子をくさびで囲み、コーヒー テーブルとして使用。

前回墜落したときは、山で大きな猫を追いかけるように、3 日間続けて追跡しなければなりませんでした。ボブの未亡人にさえ電話をかけようとしました。

あなたはついにMacを見つけました キャロルの画面とオックスフォード辞書の間に挟まれています。 800 ドルのモニター スタンドを取り戻したとき、キャロルは「最高の高さでした!」と反論しました。あなたはマックをトレードしました キャロルが見つけた古いイケアのカタログは、Mac-Mini よりも実用的ではないにしても、それ以上のものではありませんでした。

Mac を接続しました 戻って、OSX の最新バージョンである「Cougar」に念入りに更新しました (追跡するのが難しい何か)。

そして数日後、あなたの同僚が新しい車を手に入れ、あなたが家を失ったとき、私は疑問に思いました:無料のセキュリティ修正を適用するためにクレジットカードを要求するのは適切ですか?

しかし、真実は、Mac です 重要な仕事をしています。 Mac でしか実行できないすべてのタスクを実行する .インストーラーに署名し、Mac パッケージを作成し、iOS の作業を行い、ニューヨーク証券取引所を運営しています...よくわかりませんが、結局のところ、それはボブのものです.

OSX を仮想化できたら、人生は違ったものになっていたかもしれません。

私はたまたま、元雇用主からの贈り物である 2011 mac-mini を持っています。その生活は、Mac とは少し異なりました の。愛されることはなく、過去 2 年間は箱の中で過ごしました。この記事のニーズに応じて、その日の生活を見ることができます。出版スケジュールが 4 日遅れているのもそのためです。 High Sierra — 灰色の画面をインストールしようとしました。再フォーマットし、Lion をインストールしてから、El Captain をインストールする必要がありました。だからエルキャプテンは私たちが使用するものです.なんと 2GB のメモリを備えており、システムはその 3/4 を使用しています。

Mac のシステム パラメータで VNC、リモート共有、および SSH を有効にする必要があります。

この記事は少し長くなり始めています。これまでに達成した作業の簡単な視覚的要約を以下に示します:

ふざけるのはやめましょう。

    <リ>

    OSX マシンに Qt の OSX ビルドをコピーします。 scp -r 、 rsync または共有フォルダー (samba 経由) を使用できます

    <リ>

    scp -r を使用して、helloworld-gui をマシンにコピーします。

    <リ>

    クロスコンパイルされた Qt のビルドには macdeployqt が含まれていません。 Qt の公式バージョンを Mac に直接インストールすることで入手できます。これを回避し、install_name_tool の毛むくじゃらの混乱に対処する必要がないように、DYLD_FALLBACK_FRAMEWORK_PATH をセットアップできます。 すべての Qt*.framework を含むフォルダーを指すようにします。 DYLD_FALLBACK_FRAMEWORK_PATH やや正気ですが、機能しない可能性があり、関連するセキュリティリスクがいくつかあります.出荷されたアプリケーションでは使用しないでください。

    DYLD_FALLBACK_FRAMEWORK_PATH をエクスポート =/Users/cor3ntin/dev/cross-compilation/qt5_10/lib

    <リ>

    Windows の場合と同様に、helloworld-gui の隣に qt.conf ファイルを提供して、Qt にプラグインのロード元を指定する必要があります (それ以外の場合、アプリケーションは単に実行されません)。私のはそのように見えます

[Paths]
Prefix=/Users/cor3ntin/dev/cross-compilation/qt5_10/
Plugins=plugins

これで、ssh 経由で Mac に接続され、アプリケーションを実行できます。アプリケーションは、Mac 画面とリモート ディスプレイ/VNC セッションに表示されます。

Clang、LLVM、ld64、および関連ツールはオープン ソース プロジェクトです。これは、オープン ソースのバージョンが Apple が使用しているバージョンと一致するという意味ではありません。

実際、Apple の Clang は適切な Clang の修正バージョンであり、アップストリームより数バージョン遅れています。彼らがプロジェクトを開始したことを考えると、これは皮肉なことです。

LD64 そして、「cctools」は「Apple オープン ソース ライセンス」の下でリリースされます。XCode で使用されるそのツールのバージョンは、オープン ソース コミュニティがアクセスできるバージョンよりも 2 年進んでいます。

フレームワーク自体はオープン ソースではなく、冒頭で述べたように、再配布できません。

そして、現在 Darling の人々によってのみ維持されているオープン ソースの代替 cocotron では不十分です。

いくつか問題があります

    <リ>

    SDK を実際にビルドするためのビルド スクリプトはなく、 .dylib のみをインストールします。これはおそらくかなり簡単に修正できます。

    <リ>

    フレームワークのセットは限られており、そのセットは Qt を構築するには不十分です。 Qt は次のフレームワークを使用します。🍎 で始まるものは Darling にはありません

    • アプリキット
    • アプリケーションサービス
    • 🍎資産ライブラリ
    • AudioToolbox
    • 🍎 AudioUnit
    • 🍎AVFoundation
    • 🍎カーボン
    • ココア
    • 🍎 CoreAudio
    • 🍎 CoreBluetooth
    • コアファウンデーション
    • コアグラフィックス
    • 🍎コアロケーション
    • 🍎コアメディア
    • 🍎コアモーション
    • コアサービス
    • コアテキスト
    • コアビデオ
    • 🍎 fftreal
    • 財団
    • ImageIO
    • 🍎IOBluetooth
    • IOキット
    • 🍎OpenCL
    • クォーツコア
    • セキュリティ
    • 🍎システム構成
    <リ>

    OSX で Qt Framework をコンパイルしてから、Linux マシンにコピーすることもできます。ほとんどの場合、これでうまくいくでしょう。

    <リ>

    公式の SDK ではない SDK を使用すると、Mac でソフトウェアが動作することをテストするためのクロス コンパイルの目的が損なわれます。 Darling で動作することをテストしているだけです。 Darling SDK のヘッダーが公式のものと一致するという保証はありません。 Mingw もその問題に苦しんでいます。

そのため、複雑なアプリケーション (Qt および Qt ベースのものを含む) を Mac on Linux でクロスコンパイルすることは技術的に可能です。非グラフィカル アプリケーションや単体テストを直接かつシームレスに実行することさえ可能です。

しかし、SDK を使用することは違法であり、法律によっては、演習全体が少し無意味になります。オープン ソースの代替手段は存在しますが、十分ではなく、十分に信頼できるものではない可能性があります。

期待はできますが、Apple がこれまで以上に開発者に優しい政治を行うかどうかは疑わしいです。

そして、そのひどい失望を終わらせる時が来ました!