7

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

次の 3 つのシナリオに対する簡単な解決策を
考え出そうとしています
。オプションのクラスを使用しますが、-ObjC フラグが必要です
3) プロジェクトには私の静的ライブラリ + 2 番目の静的ライブラリが含まれており、オプションのクラスを使用します (この時点では -ObjC フラグは気にしません)。

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

ありがとう！

解決：

1) 私の -ObjC ユーザーに、代わりに -force_load を使用するよう提案してください。(Rob に感謝します!)
2) 1 ができないユーザーのために、ClassA を含まない代替ビルドを用意します。

4

1 に答える 1

7

ベスト プラクティスは、必要なすべての静的ライブラリを常に最終的なバイナリ リンクにすることです。ある静的ライブラリを別の静的ライブラリにバンドルしないでください。よく知られている (つまり、オープンソースの) 静的ライブラリを、出荷する静的ライブラリに決してバンドルしないでください。これは、最終消費者が同じコードの複数のバージョンで終わる可能性があるため、信じられないほどの頭痛の種になる可能性があります。これから発生する可能性のあるバグを追跡することは非常に困難です。運が良ければ、紛らわしいコンパイラ エラーが発生するだけです。運が悪いと、コードは予測できない方法で動作し、ランダムにクラッシュします。

すべての静的ライブラリを個別に出荷します。さまざまな構成のためにリンクする必要があるものをクライアントに伝えます。これを避けようとすることは、彼らの生活を困難にするだけです。

役に立つかもしれないその他の議論:

-ObjC フラグはClassA、使用されているかどうかに関係なく、完全に自動削除されないようにする必要があります (詳細については、 TN1490を参照してください)。

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

-ObjCまたは、フラグを削除して、-force_loadカテゴリのみのコンパイル単位を個別にロードするために使用できます (これは、対処するため-ObjCに使用される問題です)。

于 2012-09-27T21:25:48.717 に答える