開発しているアプリによっては自分たちが管理していないSDKなどを必要とする場合があります。SDKのインストールパスは大体同じ場合が多いと思いますが、任意の場所に置くことが出来る場合、マシンや開発者によって置いている場所が異なる場合があります。
そのようなときに、プロジェクトファイルに直接、検索パスを設定してしまうと、Gitからプロジェクトファイルをプルするたびに検索パスを自分の設定に合わせて変更しなければいけないということになってしまいます。逆に自分がコミットするときには、プロジェクトファイルを含めないように自分で注意するということになってしまいます。
この記事ではこのような事態を回避するための方法を解説します。
ビルド設定ファイルの作成
プロジェクトファイルに設定される値が、環境依存になることが問題の原因です。回避するには、マシンごとに設定値が変わるようにビルド設定ファイルを作成します。
ビルド設定ファイルの作成方法とプロジェクトへの設定方法については、以下の記事を参照してください。

上記の記事を参考に、次の3つのビルド設定ファイルを作成します。
Debug.xcconfig
Release.xcconfig
SearchPath.xcconfig
名前の通り、デバッグビルドにDebug.xcconfig
、リリースビルドにRelease.xcconfig
を設定します。次にDebug.xcconfig
とRelease.xcconfig
に以下の様に入力します。
#include "SearchPath.xcconfig"
検索パスの変更
iOSアプリやmacOSアプリの場合、検索パスというと次の3つが一般的に使われます。
- フレームワーク検索パス
- ヘッダーファイル検索パス
- ライブラリ検索パス
検索パスはビルド設定のSearch Paths
の中に設定項目がまとまっています。

フレームワーク検索パス
フレームワーク検索パスはリンカがフレームワークとリンクするときに、フレームワークを検索するディレクトリパスです。ビルド設定のSearch Paths
のFramework Search Paths
に設定します。
ヘッダーファイル検索パス
ヘッダーファイル検索パスは、C言語、C++、Objective-C/C++のコードからヘッダファイルをインクルードするときに、コンパイラがヘッダーファイルを検索するディレクトリパスです。ビルド設定のSearch Paths
のHeader Search Paths
に設定します。
ライブラリ検索パス
ライブラリ検索パスは、リンカが共有ライブラリ及びスタティックライブラリとリンクするときに、ライブラリを検索するディレクトリパスです。ビルド設定のSearch Paths
のLibrary Search Paths
に設定します。
ビルド設定ファイルを使った変更方法
ビルド設定ファイルを使って、検索パスを指定するには、ビルド設定ファイルで以下の設定にディレクトリパスを設定します。
検索パス | ビルド設定ファイルの設定 |
---|---|
フレームワーク検索パス |
FRAMEWORK_SEARCH_PATHS
|
ヘッダーファイル検索パス |
HEADER_SEARCH_PATHS
|
ライブラリ検索パス |
LIBRARY_SEARCH_PATHS
|
検索パスには複数のディレクトリパスをスペース区切りで指定可能です。ディレクトリパスにスペースが含まれる場合は、クオーテーションマークで囲みます。
ここでは、SearchPath.xcconfig
ファイル内に記述します。例えば、次のように入力します。
FRAMEWORK_SEARCH_PATHS = /usr/local/share/mydevice-sdk/frameworks $(inherited)
HEADER_SEARCH_PATHS = /usr/local/share/mydevice-sdk/includes $(inherited)
LIBRARY_SEARCH_PATHS = /usr/local/share/mydevice-sdk/libs $(inherited)
$(inherited)
を使って、デフォルトや上位で設定している値も継承して使用するようにしましょう。
また、この例では$(inherited)
よりも前に自分の設定を書くことで、継承したディレクトリよりも、ビルド設定ファイルで指定するディレクトリを優先するように指定しています。この例ではデバイスのSDKを使うことを想定しています。本来は重複しない方が良いのですが、SDK側でデフォルトで入っているヘッダファイルと同じ名前のファイルを提供しているかもしれません。それも、SDK専用にカスタマイズされている可能性があります。その場合はSDKの方を優先して使用するべきなので、SDK側を優先するようにしています。
Gitの管理対象から除外する
これだけだと、マシン固有になりません。SearchPath.xcconfig
ファイルは、マシンごとに異なる想定です。そのためにはSearchPath.xcconfig
を.gitignore
に書いて、Gitの管理対象から外してしまいましょう。
そのようにすることで、必ず、マシン毎(クローン毎)にSearchPath.xcconfig
ファイルを作ることを強制できます。
但し、この作成することを強制する方法にはCI(継続的インテグレーション)との組み合わせで問題があるという弱点があります。
CI用のファイルはどうするか?
このようにして、SearchPath.xcconfig
をGitからクローンした環境毎に作成することを強制すると、困ってしまうのがCI(継続的インテグレーション)はどうするかです。
ビルド設定ファイルは、複数回同じ設定項目を設定すると、後から書いた方が優先されるという特徴が有ります。それを利用して次のようにデフォルト値を定義してしまうという方法があります。
(1) SearchPath-default.xcconfig
を作成します。
(2) SearchPath-default.xcconfig
内で検索パスのデフォルト値を定義します。この定義はCIによって使われます。
(3) Debug.xcconfig
とRelease.xcconfig
に次のように入力して、SearchPath-default.xcconfig
を読み込んだ後、SearchPath.xcconfig
を読み込むようにします。
#include "SearchPath-default.xcconfig"
#include? "SearchPath.xcconfig"
SearchPath.xcconfig
を作成することを強制は出来なくなってしまいますが、ローカル環境ではSearchPath.xcconfig
を作成して、SearchPath-default.xcconfig
に書かれている設定を上書きできるようになります。
SearchPath.xcconfig
の方は#include?
というように、?
が付いたインクルード文になっています。#include?
の場合は対象のファイルが無くてもビルドエラーにはなりません。あればインクルードするという動作になります。
上書きする必要がないときはSearchPath.xcconfig
は作成せずにビルドし、CIとは別のディレクトリにSDKを置いているときにはSearchPath.xccconfig
を作成して、設定を上書きして運用するということができるようになります。
デバッグ版とリリース版を分ける
デバッグ版とリリース版とで、ライブラリやフレームワークも切り替えたい場合があります。SDKがデバッグ版のライブラリとリリース版のライブラリを提供しているというときです。
このような場合は、SearchPath.xcconfig
ファイルもデバッグ用とリリース用を作成します。例えば、次のようなファイル名にします。
SearchPath-debug.xcconfig
SearchPath-release.xcconfig
次に、Debug.xcconfig
とRelease.xcconfig
で読み込むファイルを変更します。
Debug.xcconfig
には次のように入力します。
#include "SearchPath-debug.xcconfig"
Release.xcconfig
には次のように入力します。
#include "SearchPath-release.xcconfig"
Xcodeでビルド設定を表示すると、期待通り、デバッグ用とリリース用とで別々の検索パスが設定できていることも確認できます。
