ObjC：第三者のライブラリに依存するオプションのクラスを含むスタティックライブラリをコンパイルする方法

Question

オプションのクラスを含む静的ライブラリ（Lib1と呼ぶことができます）をパッケージ化する最良の方法を見つけようとしています（ClassA ）、それ自体は第2の静的ライブラリ（Lib2）を必要とする。つまり、Lib2は、プロジェクトのコードでClassAが参照されている場合にのみ必要です。 Lib1がClassAを使用していない（したがってLib2を含まない）プロジェクトで使用されているのではなく、-ObjCリンカーフラグが必要です（他のプロジェクトの依存関係のために）。

私は次の3つのシナリオのための簡単な解決策を考え出すしようとしている：
1）プロジェクトは、私の静的libが含まれ、）
2 -ObjCフラグを指定していない、オプションのクラスを使用していませんプロジェクトには私の静的なlibが含まれていますが、オプションのクラスは使用されませんが、-ObjCフラグ
が必要です。3）プロジェクトには静的なlib + 2番目の静的ライブラリが含まれています。この点）

2番目の静的ライブラリを必要としないように、私のオプションのクラスを最終プロジェクトアプリから削除するリンカフラグがありますか？私は私の静的なlibの複数のバージョン、オプションクラス（標準的な選択肢）を含んでいないもの、別のもの（-ObjCの要件を持つプロジェクトのためのもの）、またはスタブファイルを提供するものをリリースすることです。 2番目の静的ライブラリから必要なすべてのクラスの空の実装を提供していますか？これは、静的ライブラリの世界で共通の問題になる可能性があるようです...このシナリオのベストプラクティスはありますか？

ありがとうございます！

---

ソリューション：

1）彼らは代わりに-force_load使用することを私の-ObjCユーザーに提案します。 （ありがとうRob！）
2）私はClassAを含まない代替ビルドを持っています。

Answer 1

ベストプラクティスは、常に必要なすべての静的ライブラリ。静的ライブラリを別のものにバンドルしないでください。よく知られている（つまりオープンソースの）静的ライブラリを、あなたが出荷する静的ライブラリに束ねることは絶対に避けてください。これは、同じコードの複数のバージョンで巻き込まれる可能性があるため、最終消費者にとって驚異的な頭痛を引き起こす可能性があります。これから来るバグを追跡することは非常に難しいことです。彼らが運が良ければ、混乱しているコンパイラエラーに遭遇します。彼らが不運な場合、そのコードは予期しない動作をし、ランダムにクラッシュします。

すべての静的ライブラリを別々に出荷してください。さまざまな構成のためにリンクする必要のあるクライアントをクライアントに伝えます。これを避けようとすると、人生は難しくなります。

有用である可能性がある他のいくつかの議論：

• Duplicate Symbol Error: SBJsonParser.o?（彼にこれをやってベンダーに走った顧客の例）
• Linking static libraries, that share another static library
• Why don't iOS framework dependencies need to be explicitly linked to a static library project or framework project when they do for an app project?

---

-ObjCフラグは、自動ストリッピングを防止する必要があります（詳細はTN1490を参照してください）。

特定の状況を除いてClassAが使用されず、領域を節約したい場合は、おそらくClassAを静的ライブラリに移動する必要があります。または条件付きでコンパイルするには#ifdefを使用します。

-ObjCフラグを削除し、-force_loadを使用して、カテゴリのみのコンパイル単位を個別にロードすることができます（これは、問題の場合は-ObjCが使用されます）。