Xcode 4とXcode 3.2でうまく機能するネストされたプロジェクトには、無数の問題があります。ここに私が解決できない非常に基本的なものがあります:
私はソースを持っている別のココアフレームワークを必要とするココアフレームワークを構築しています。したがって、通常の手順を実行します。
.xcodeproj
ファイルをメインフレームワークプロジェクトにドラッグします${BUILT_PRODUCTS_DIR}
に設定されており、それらがDerivedData/Debug(またはリリース)の場所にあることを通知します次に、[CMD] + Bを押してビルドすると、ネストされたフレームワークのヘッダーファイルが見つからないことがわかります。設定を確認すると、ユーザーヘッダー検索パスはDerivedData/Debugへのパスを含み、内部にはバージョン/ A/Headers。
私はここに座っています、誰かが私が間違っていることを知っていますか?
ユーザーヘッダーの検索パスを${BUILT_PRODUCTS_DIR}/MyFramework.framework/Headers
に変更すると、Debugのビルド時に問題がなくなります。ただし、Distributionを構築する場合、フレームワークはリリース設定を使用し、最終的に別のサブディレクトリに格納されるため、これは機能しません...
私の一時的な解決策は、ネストされたプロジェクトのDistribution構成も定義することです。これにより、ヘッダーが検出され、リンカーが正常にリンクできます。
これまでの私の総合的な知識は次のとおりです。
Xcodeでpublicヘッダー全体を忘れてください。これはPITAであり、アプリをアーカイブするときに正しく機能しません。代わりに、すべての静的ライブラリヘッダーファイルをprojectレベルにし、アプリにそれを見つける場所を伝えます。
すべてのターゲットがビルド構成と同じ名前を持っていることを確認することで苦痛を和らげます(つまり、「AdHoc」および「Deployment」構成を静的ライブラリに追加します)。
ビルド設定で、Header Search Paths(_#include <file.h>
_を使用する場合)またはUser Header Searchをポイントします静的ライブラリプロジェクトのディレクトリへのパス(_#include "file.h"
_を使用する場合)。静的ライブラリプロジェクトがアプリディレクトリ内の場合、これを使用します。
"$(PROJECT_DIR)"
(recursiveenabled)
A)静的ライブラリプロジェクトとb)アプリを含むディレクトリがある場合、これは動作するはずです:
"$(PROJECT_DIR)/.."
(recursiveenabled)
サブモジュールにコンパイル済みライブラリが含まれている場合、Library Search Pathsを次のように設定します。
"$(TARGET_BUILD_DIR)"
使用するすべての静的ライブラリプロジェクトで、Skip InstallがYES
に設定されていることを確認してください。
繰り返しますが、どの静的ライブラリにもパブリックヘッダーファイルはありません(ビルドフェーズ"ヘッダーのコピー)。そうしないと、Xcodeはアプリをアーカイブできません。
このTech DocのAppleから のように、Xcodeに静的ライブラリをビルドするタイミングを必ず指定してください。
古い答え:
静的ライブラリを使用した場合、この問題の本当の解決策はまだ見つかりません。私のために働くのは:
$(BUILT_PRODUCTS_DIR)
をアプリケーションのユーザーヘッダー検索パスに追加します(recursiveチェック付き)->これはアプリの実行時に使用されますこれは機能し、アプリはヘッダーファイルを見つけて自分自身をビルドし、アプリバンドルとしてDerivedData // Build/Products/AdHoc-iphoneos /に配置されます。 TestFlightApp.comから これらの簡単な指示 (デッドリンク)をたどって、このアプリをIPAにパックして送信できます。 XcodeからアプリをArchiveに選択するだけでは、ヘッダーが本当にAdHoc-iphoneosビルドディレクトリにある場合でも、ヘッダーが見つかりません。
(Xcode 5.1以降)
サブプロジェクトがXCodeによってビルドされると、サブプロジェクトのヘッダーファイルがビルドディレクトリにコピーされます。アーカイブすると、このコピー先ディレクトリはヘッダー/インクルード検索パスに追加されないようです。ビルド設定に移動して追加する必要があります
$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include
アーカイブに使用するスキームの「ヘッダー検索パス」に移動します。
アーカイブにどのスキームが使用されているかわからない場合は、[製品]-> [スキーム]-> [スキームの編集]に移動し、左側の列で[アーカイブ]を探します。
サードパーティのフレームワークがメインプロジェクトに"グループ"として追加されていることを確認してください。そうすれば、プロジェクトの階層でそれを見ることができます...
「アドホック」という名前の設定で同じ問題が発生していました( http://help.testflightapp.com/customer/portal/articles/402782-how-to-create-an- ipa-xcode-4 )そして、メインプロジェクトは、ネストされたプロジェクトからヘッダーの一部を見つけることができませんでした。プロジェクトの名前を「AdHoc」(スペースなし)に変更すると、問題はなくなりました。場合によっては、スペースがヘッダーの検索パスを台無しにする可能性があるように見えますが、それがいつ起こるのか、なぜ起こるのかについての詳細は把握していません。
静的ライブラリを構築したネストされたプロジェクトでこの問題が発生していました。私はこのドキュメントをリンゴのサイトで見つけて、私の命を完全に救いました。
派生したデータパスをいじる必要がなかったのはとてもうれしいことです。
ここでも同じ問題が発生し、「ビルドの場所」を設定してビルド製品をターゲットで指定された場所に配置することで問題を解決できました。
この問題が発生しました:デバッグ構成とApp Store構成の両方を作成できましたが、アドホックは作成できませんでした。アドホックの構築では、ネストされたプロジェクトに必要な.hファイルが見つからなかったため、エラーが発生しました。
リリース構成で期限切れのプロビジョニングが残っていたことが判明しました。そのプロビジョニングリンクを更新し、アドホックをビルドし、アーカイブ機能を使用してパッケージ化できるようになりました。
それを理解するのに何時間もかかった!私の考えでは、.hファイルの欠落から、それ自体のプロビジョニングエラーへのジャンプはありませんでした。 =)不足しているプロビジョニングについて不平を言っているエラーまたは警告があった可能性がありますが、そうであれば、それは何百もの.h関連エラーに埋もれていました。
私にとっては、これはGITのマージ後に発生し、多くの競合が発生し、そのうちの1つはプロジェクトファイルに関連していました。マージ後、プロジェクトファイルの構造が変更されたと確信しています。
私がやったことは、プロジェクト「ビルド設定」に入り、「常にユーザーパスを検索」を探してYes
に変換することでした。
マージによってこのブール値がNo
に変更されたため、プロジェクトはヘッダーファイルの適切な場所を探していなかったようです。