Xcode 4のワークスペースで機能する暗黙の依存関係をどのように取得しますか？
他のプロジェクトから参照できる共有コードを含むCocoaTouch静的ライブラリプロジェクトでXcode4を使用して、ワークスペース内のプロジェクトを管理したいと思います。 WWDC2010のビデオとXcode4のドキュメントによると、Xcode 4のワークスペースには「暗黙の依存関係」の機能があります。これを機能させようとしていますが、あまり成功していません。
サンプルワークスペース： DependenciesInXcode4.Zip
非常に基本的なサンプルプロジェクトには、Library1とLibrary2という名前の2つの静的ライブラリプロジェクトがあります。次に、PrimaryAppと呼ばれるiPhoneプロジェクトから参照する各プロジェクトに1つのクラスがあります。 importステートメントを追加するとCodeSenseからサポートを受けますが、ビルドが失敗します。
依存関係が見つからないためにビルドがどのように失敗するかを確認できます。
これらの問題を解決するために、Library1プロジェクトとLibrary2プロジェクトを手動でリンクして追加しました。
また、これらのプロジェクトへのパスをヘッダー検索パスとして追加する必要がありました。
両方の依存関係ライブラリをビルドしてからiPhoneシミュレーターでPrimaryAppを実行すると、ビルドが正常に実行されます。依存関係プロジェクトが必要なときに構築されるとは限らないことがわかりました。これは明らかに手動のプロセスです。 Xcodeのビデオとドキュメントはそれが機能するはずであることを示唆しているので、これは私が「暗黙の依存関係」と考えるものではありません。もっと具体的な例を探していましたが、今のところ運がありません。ここStackoverflowでさえ、私はまだ満足のいく答えを見ていません。
開発者は古い手法にフォールバックしており、新しい「暗黙の依存関係」機能を実際に使用していないようです。
「暗黙の依存関係」を取得してXcode4のワークスペースで機能させる方法を理解するのに役立つ情報をいただければ幸いです。
これが私の質問です：
- 「暗黙の依存関係」は、ワークスペースを備えたXcode 4でどのように機能するはずですか？
- Libary1とLibrary2のコードがPrimaryAppで自動的に見つからないのはなぜですか？
- ワークスペースで依存関係を機能させるには、追加の変更が必要ですか？
私は2日間の大部分をプロジェクトの構築と再構築に費やし、まさにこの問題に苦しんでいます。私は今、正しくビルドしてリンクし、コードセンスが機能しているプロジェクトを持っていますが、それはちょっとしたハックのようで、「自動暗黙的依存関係」の概念に確かに適合しないため、ステップの1つに100％満足していません。
FWIWは私が取ったステップです：
- Xcodeで新しいワークスペースを作成します。
- 静的ライブラリのワークスペースに新しいプロジェクトを追加します。既存のプロジェクトを追加することもできますが、これも機能することがわかりました。
- ライブラリが期待どおりにビルドされることをテストします。
- メインプロジェクトのワークスペースに新しいプロジェクトを追加します。ここでも、既存のものを追加することができましたが、重要なことに、ライブラリにリンクされているビルド設定がまだありませんでした。新しいプロジェクトを追加する場合は、既存のソースファイルをプロジェクトに追加するだけでかなり簡単です。私の特定の状況は、再構築したくない非常に大きな既存のSVNリポジトリによって複雑になりました。
- この段階では、ソースコードに静的ライブラリからのヘッダーのインポートがすでに含まれていると想定します。
- メインプロジェクトのビルドフェーズで、[バイナリとライブラリのリンク]セクションを展開し、[+]記号をクリックします。静的ライブラリプロジェクトからターゲットを選択します。
- この段階で必要な場合は、メインプロジェクトをビルドして、ヘッダーインポートの「そのようなファイルはありません...」エラーのあるOPスクリーンショットに示されているように失敗することを確認できます。
- 今、これは私が本当に好きではないビットです。メインプロジェクトで新しいグループを作成し、それを依存ヘッダーなどと呼びます。 project navigatorで、使用済みのヘッダーを静的プロジェクトからこの新しいグループにドラッグします。オプションポップアップで、デフォルト設定のままにしました。
- また、メインプロジェクトを静的ライブラリで使用される依存ライブラリにリンクする必要がある場合もあります。たとえば、静的ライブラリはlibxml2とCFNetworkを使用しており、メインプロジェクトでは直接使用していませんが、「ライブラリとバイナリをリンクする」ビルドフェーズに追加しなかった場合、コンパイルエラーが発生しました。
- これで、メインプロジェクトが（うまくいけば）ビルドされるはずです。
手順8と9は本当に好きではありません。これは、XCodeが宣伝されていることを実行していないように感じます。ただし、修正された場合、少なくともこれらの手順はかなり簡単に取り消すことができるため、正しく機能します。
「暗黙の依存関係」は、ステップ6、おそらくステップ5を通過する必要なしに機能するはずですが、それは多くの人の好みには少し自動すぎるかもしれません。
これは、ビルドプロセス中のXcodeによる暗黙的な依存関係の処理のバグのようです。
2つのプロジェクトがあるワークスペースで、プロジェクトAにプロジェクトBのクラスを表示させ、プロジェクトBのクラスの.hヘッダーファイルをプロジェクトAのディレクトリにコピーすることで正常にビルドすることができました。 注：XcodeでプロジェクトAに追加しませんでした FinderのプロジェクトAのディレクトリに配置しただけです。
これは、ワークスペーススキームやどちらのプロジェクトのビルド設定も変更する必要がないため、他の場所で概説したよりもはるかに簡単なソリューションです。 Xcodeは、プロジェクトAのディレクトリにある.hファイルを使用して、プロジェクトAのプロジェクトBへの暗黙的な依存関係をすべて自動的に検出して解決することができました。
残念ながら、.hファイルを「XcodeBugWorkaroundHeaderFiles」という独自のサブディレクトリに配置することはできません。それらは、プロジェクトがすでに.hファイルを読み取っているディレクトリにある必要があります。また、エイリアスは機能しませんが、シンボリックリンクは機能するため、SymLinksを使用することで、古いコピーについて心配する必要はありません。
とはいえ、ビルドビルドが失敗する「ステルス」.hファイルを用意するのが良い考えかどうかはわかりません。バグがXcodeで修正されるまでは、Xcodeで確認できるように、プロジェクトに追加するのがおそらく最善です。
ユーザーヘッダー検索パスのスペースに関する問題を解決するには、次を使用します。
"${BUILT_PRODUCTS_DIR}"
もう1つのオプションは、各「サブプロジェクト」のルートを再帰的なヘッダーパスとして含めることです。たとえば、AcmeLibがある場合は、メインプロジェクトのビルドオプションに移動し、再帰オプションを有効にして、AcmeLibへのパスをユーザーヘッダー検索パスに追加できます。次に、AcmeLibのヘッダーファイルが自動的に検索されます。
開発者間のパスの独立性を維持するために、ソースディレクトリ変数（たとえば$ ACME_LIB）を基準にしてパスを作成できます。これは、各開発者がXCode設定の[ソース]ペインでデバイス化できます。
したがって、新しいプロジェクトでAcmeLibを使用するには、プロジェクトをドラッグして、ヘッダー検索パスに$ ACME_LIBを追加するだけで、準備は完了です。 XCodeの暗黙的なリンクは、依存関係をフックする必要があります。
これが1つのすべての指示です Googleドキュメントドキュメント 。
私はこれを次のようにして機能させました。 1.ライブラリを2番目のプロジェクトとしてワークスペースに追加します。 2.バイナリをライブラリにリンク>静的ライブラリを追加します。
-重要な部分-
ビルド設定の「ヘッダー検索パス」に以下を追加します
$ {BUILT_PRODUCTS_DIR}
これにより、ビルドされたヘッダーファイルがプロジェクトにリンクされます。ビルドエラーはもうありません。