2016-05-07 12 views
5

私は、App、FrameworkA、FrameworkBという3つのプロジェクトを持つXcode 7.3ワークスペースを持っています。各プロジェクトには1つのターゲットがあります。これはiOSなので、フレームワークターゲットはCocoa Touch Frameworksです。これは、動的にリンクされた共有ライブラリを含むフレームワークを意味します。異なるビルド構成でXcodeプロジェクトの依存関係を設定するにはどうすればよいですか?

アプリケーションは、フレームワークBに依存するフレームワークAに依存します。これらの依存関係は、AがBのビルド製品に適切にリンクし、アプリケーションがフレームワークAとBの両方に適切にリンクして埋め込む限り動作します。 1つのフレームワークが別のフレームワークを埋め込んでいると、アプリケーションバンドルが直接的な依存性と推移的な依存性の両方をリンクして埋め込む必要があるようです)。

しかし、ここに私の問題があります。フレームワークAとBには、通常のビルド構成であるDebugとReleaseがあります。アプリケーションにはビルド設定LocalReleaseがあります。これは、ビルドの実行アクションによってトリガーされ、最適化されたビルド(リリースなど)をビルドするために使用されますが、開発者ID(デバッグなど)でコードされます。

このLocalReleaseビルド設定でアプリケーションをビルドしようとすると、フレームワークAとBの依存関係が破られるため、ビルドが中断されます。これらのフレームワークはLocalReleaseビルド構成を持たないため、 Appと同じようにLocalRelease-iphoneosフォルダに製品を作ります。

私の狭い質問は、非標準ビルド構成名(LocalReleaseなど)を持つプロジェクトが標準ビルド構成名のみを使用する他のプロジェクトに依存できるようにビルド設定を構成するにはどうすればいいですか?スクリプトやxcconfigファイルを追加する必要のない簡単な方法があることを期待していますが、必要な場合はその理由を理解したいと思います。

さらに広い共有のワークスペース内のプロジェクト間の依存関係の円滑なやりとりができないため、一般的に追加のビルド構成を導入するのは悪い考えですか?私は最適化されたローカルビルドを望んでいたため、この3番目の設定を定義しました。私は新しいスキームを定義したくないので、さまざまなビルドアクション(実行、プロファイル、リリース)によって表現されるビルドタイプの選択を望みました。単一のスキーム。

これは間違った方法でした。ビルド構成の名前がビルド製品のディレクトリパスを駆動し、依存するプロジェクトが共有ディレクトリ内で互いのビルド製品を見つける必要がある場合は、プロジェクトに非標準のビルド構成名を導入すると、他のプロジェクトに依存している。

答えて

0

これについてAppleからDeveloper Technical Supportチケットを発行し、WWDCのXcodeエンジニアと話しました。私は(LocalReleaseのような)非標準のビルド構成名のプロジェクトは、標準ビルド構成名を使用し、他のプロジェクトに依存することができるようにビルド設定を設定するのですか、私自身の質問に

回答

回答:できません。

一般的に、共有ワークスペース内のプロジェクト間の依存関係を円滑にやりとりすることができないため、追加のビルド構成を導入することは好ましくありませんか?

回答:はい、これは悪い考えです。

新しい名前付きビルド構成を作成することは、私がやろうとしていたことをやり遂げるためのスマートな方法ではありません。残念なことに、xcconfigファイルを採用してこのような設定ファイルを手動で変更するのが "最も単純な"ソリューションのようです。

関連する問題