(私の質問は以前にここで尋ねられましたが、実際の答えはありません。例: Xcode4 Workspace with Static library project application project )
サードパーティが提供するライブラリを使用しようとしています。これらは、libLibraryName.aファイルをビルドするXCodeプロジェクトを提供します。プロジェクトをサブプロジェクトとして自分のプロジェクトに追加し、製品設定libLibraryName.aファイルをプロジェクト設定の「ライブラリとバイナリをリンク」で説明されているライブラリのセットに追加することをお勧めします。
ライブラリは正しくビルドされます。aファイルが生成されます。ただし、プロジェクトでは、Productsグループの下に赤いlibLibraryName.aファイルが表示されます。黒にならないそして、親プロジェクトは、リンク用のLibraryNameを見つけることができないと言います。
テストとして、XCode 4静的ライブラリテンプレートを使用して新しい静的ライブラリプロジェクトを作成しました。このプロジェクトは同じ動作を示します-.aファイルがビルドされても、製品が「黒」に表示されることはありません。 (Edit:シミュレータではなくデバイス用にビルドすると黒に変わります)。
XCode 4は、デフォルトで共有ファイルに中間ファイルと製品ファイルを配置することを知っています。この設定を試し、ビルド設定で説明されているフォルダーに製品ファイルを配置するように設定を変更しました。どちらの設定も機能しません。
また、シミュレーターではなくデバイス用にビルドすることも提案されています。私はこれを無駄に試しました。
何が得られますか?静的ライブラリプロジェクトを取得して、製品をビルドした場所を認識し、その後、この製品を別のプロジェクトで参照するにはどうすればよいですか?
たくさんのフープジャンピングがありますが、ここでそれが機能するようになった今のメモを示します。
新しい標準のXCode4 iOS「Cocoa Touch Static Library」プロジェクトを作成(およびそれにコードを追加)すると、プロジェクトはすぐに正常にビルドされます。ただし、デバイスビルドを実行すると、製品ファイルlibLibraryName.aが黒になります(赤から、ファイルが存在しないことを示します)。シミュレータビルドでは、実際にはターゲットがビルドされたときにビルドされたことが示されません。
プロジェクトターゲットビルド設定では、「構成ごとのビルド製品パス」はデフォルトで$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
になります。これを他の何かに変更した場合(または$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)$(IPHONEOS_DEPLOYMENT_TARGET)
をデフォルトとして(私は信じています)、製品ファイルlibLibraryName.aは決して黒くなりません。私にとって、これはどこかにXCodeにバグがあるということです。
ビルド後に製品ファイルが黒くなることなく生きることができます(これは素晴らしい指標ですが、ちょっと、何でもです)。しかし、シミュレーターやデバイスのために、ライブラリの正しいビルドを見つけることができるように私の消費プロジェクトが必要です。理想的な世界では、i386/arm6/arm7ビットを含む単一の.aファイルがありますが、これも私のライブラリ/ライブラリプロジェクトではありません。
XCode4 Transition Guide は、私に光を与えたものです。両方のプロジェクトをホストするワークスペースを作成することを規定しており、両方が同じ共有ビルドディレクトリにビルドされます。以前はワークスペースを使用していなかったため、File/Save As Workspaceコマンドを使用して新しいワークスペースファイルを作成しました。次に、ライブラリプロジェクトを追加しました。子としてではなく、プライマリプロジェクトのピアとして配置されるように注意しました。
ビルド出力を共通フォルダーに配置するようにワークスペースが構成されていることを確認する必要がありました。 [ワークスペースの設定]ダイアログで、[ビルドの場所]設定を[派生製品の場所にビルド製品を配置]に設定します
また、[スキームの管理]ダイアログで各プロジェクトの[共有]チェックボックスを必ずオンにする必要がありました。
最後に、メインプロジェクトのライブラリの依存関係を指定するには、ターゲットのビルドフェーズタブの[バイナリをライブラリにリンク]セクションに移動し、[+]をクリックして、libLibraryName.aを選択しました。 ワークスペースフォルダーの下からのファイル。ワークスペースも一般的なビルドディレクトリもなかったときにこれを試したことがあることに注意してください。その結果、XCodeはリンク中に.aファイルを見つけることができませんでした。
すべてが言って完了した、それは魅力のように機能します。私は仕方がありませんが、XCode3にあったと信じているので、もっと簡単にできると思います。
他の誰かのこれに関するすべての経験、または静的ライブラリのリンクをうまく機能させる他の(より簡単な?)方法に関するフィードバックを読んでうれしいです。
ここで私の答えをチェックして、それがあなたを助けるかどうか見てください:
XCode 4で静的ライブラリをiOSプロジェクトにリンクする
これらは、自分のライブラリーに対する私の指示に基づいています。元のプロセスで欠落しているステップは、「ライブラリとバイナリをリンクする」でリンクすると同時に、静的ライブラリをターゲット依存関係としてアプリプロジェクトに追加しないことです(手順3)。また、静的ライブラリプロジェクトによるヘッダーのリンク方法によっては、手順5を実行する必要があります。
静的ライブラリプロジェクトへのクロスプロジェクト参照を持つ独自のアプリでこのプロセスを実行すると、実際にはXcode 3の同等のプロセスよりも1ステップ少なくなります。
私の ソリューションノート と レーダーエントリを開く を見てください。
赤い色の製品ノードはXcodeのバグです。 Projectビルド設定でSDKROOT
を変更することで機能させることができます。 ターゲット IDE表示およびサポート。
後で参照するため。
現在、私の意見はXcodeに変更されていますprojectは複数のプラットフォームを完全に処理することはできません。 複数のプラットフォームを表示できますが、SDKROOT
設定によって画面表示に一度に選択できるプラットフォームは1つだけです。 iOSを選択すると、ビルド製品パスにDebug-iphoneos
などが使用されます。そのため、すべてのMac OS Xターゲットが失われます。 Mac OS Xを選択すると、Debug
のようなものが使用されます。そのため、すべてのiOSターゲットの製品が失われます。
Xcodeにはこれに関連する内部バグがあると思います。 Xcodeを安定させるには長い時間がかかります。
私のチームにも同じ問題がありました。開発者の1人がこの問題に苦しんでいましたが、私のxcodeはヘッダーを適切にコンパイルして検出できました。ところで:すべての「ビルド設定」が適切に構成されました(常にユーザーパス、ユーザーヘッダーパスなどを検索します)。
彼のプロジェクトは、パスにスペースがあるディレクトリにあることに気付きました(../my project/blah.xcodeproj)。それを変更して、Xcodeは同じワークスペース内の静的ライブラリからヘッダーを見つけることができました。
ディレクトリ名に注意してください。私の2セント
詳細を明確にする1つ(ビルド出力を掘り下げてから目をそらし始めた):ライブラリヘッダーがBuild/Products/Debug
とあなたの親プロジェクトはBuild/Products/Debug-iphonesimulator
、ライブラリはiOSではなくOS X用に構築されています。これは、プロジェクト設定の[アーキテクチャ]セクションの[サポートされているプラットフォーム]設定で変更できます。 Vanilla C++の静的ライブラリプロジェクトを作成する場合、OS Xはデフォルト設定のように見えるため、この状況は簡単に発生します。