Xcodeのおける高度なプロジェクト設定

Xcodeのおける高度なプロジェクト設定

より複雑なXcodeプロジェクトを扱っていますか? そうした場合に最適な機能があります。複数のAppleプラットフォーム用にビルドするためにプロジェクトを設定する方法、プラットフォームごとにコンテンツをフィルタリングする方法、カスタムビルドルールやファイル依存関係の作成方法などを紹介します。マルチプラットフォームのフレームワークターゲット、プロジェクトとスキームの構成を最適化する方法、構成設定ファイルの効果的な利用方法などを詳しく説明します。パラレルビルド、暗黙の依存関係、スクリプトフェーズ、カスタムビルドルール、入出力ファイルの依存関係の設定、ビルドフェーズのファイルリスト、アグリゲートターゲットによる作業の重複排除など、スキームの設定について説明します。最後に、ビルド設定エディタ、レベルの仕組み、構成設定ファイルの構文についてもお伝えします。

リソース
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC21
- M1搭載Macにおける優れたiPad/iPhone Appの条件
ダウンロード

♪ （Xcodeにおける高度なプロジェクト設定）ようこそ "Xcodeにおける高度なプロジェクト設定" へ私はJakeです同僚のPrachiと一緒に Xcodeプロジェクトのビルド構成のほとんどを作成する戦略とテクニックについて議論しましょう３つの主要なトピック領域を取り扱いますまず PrachiがMultiplatformプロジェクトと Multiplatformフレームワークターゲットに対するXcode 13の新サポートを説明します次にモデリングとスキームターゲットの設定と依存関係の管理そしてビルドフェーズとルールを介してプロジェクトの構成成功事例について説明します最後にPrachiはさらにビルド設定を深く掘り下げていきますここでは以下の構造と動作について説明しますプロジェクトエディタのUI 構成設定ファイルとその構文そしてもっとたくさんです！このトークを通して私たちは Frutaと呼ばれるMultiPlatform Appプロジェクトを使用しこの手法が実際のプロジェクトにどのように適用されるかを示しますここで Prachiに渡しましょう MultiPlatformフレームワークについて説明してくれます Prachi Pai Asnodkar：ありがとう Jake Xcode 13の新機能の１つは MultiPlatformフレームワークのサポートです MultiPlatformフレームワークにより複数のフレームワークを１つに統合することが可能になります簡素化されたターゲット管理する1セットのビルドフェーズ及び管理する1セットのビルド設定を提供します Fruta Appを見てみましょうこの機能を利用するようにプロジェクトを更新しますこれがFruta AppですこれはmacOS iOS watchOS用に構築された MultiPlatform Appですまた３つのフレームワークターゲットがあります Appにより使われる共有コードのセットを含むプラットフォーム毎に１つずつです３つの別々のフレームワークを維持するためには課題が伴う可能性がありますビルド設定の同期を維持することやコンパイルソースのビルドフェーズにすべてのソースファイルが適切に追加されていることを確認することなどですこれらの課題に取り組むためにフレームワークの１つを MultiPlatformフレームワークに変換することから始めますここに１つのプラットフォームごとに３つのフレームワークがありますこれらのターゲットはすべて同一ですただしmacOS上でのみビルドされるファイルがありますまずmacOSフレームワークターゲットのプロジェクトナビゲータでタブに移動します次にビルド設定の Supported Platformsに Any Platformを選択しすることによってすべてのプラットフォームのためにフレームワークを構成しますまたAllow Multiplatform Buildsが自動的に「はい」が設定されていることが分かりますこれは必要に応じてサポートされるプラットフォームごとにこのターゲットを１回ビルドするようにビルドシステムに通知しますこれがMultiPlatformターゲットになりました元のmacOSフレームワークには macOS用にビルドする場合のみビルドする必要がある追加のファイルが１つあったことを思い出してくださいこれを行うようにフレームワークを構成するにはプラットフォームフィルタを追加してこのファイルを macOS用にのみビルドするように指定できますこれを行うには最初にタブに移動し次にCompile Sources ビルドフェーズを展開します最後にアイテムをクリックし以外のすべてのチェックを外して macOS専用にビルドするように Ingredient+macOS.swiftを構成しますこれで新しいMultiPlatform ターゲットが構成されましたそれらはもはや必要ないのでフレームワークの他の２つのバリアントを削除できますさらにフレームワークターゲットが１つしかないためこの新しいターゲットをリンクして埋め込むようにすべてのAppを構成する必要があります macOSのものから始め MultiPlatformターゲットを設定したためmacOS Appはすでに構成されています iOS AppとwatchOS Appに新しいフレームワークを追加できます各Appターゲットのタブに移動してフレームワークとライブラリの構築フェーズへフレームワークを追加します要約するとmacOSフレームワークのターゲットを採用し iOSとwatchOS用にビルドできるようにしました macOSのみのソースファイル用プラットフォームフィルタを使いフレームワークをカスタマイズしました最後にAppのターゲットを新しい単一MultiPlatform フレームワークターゲットをリンクして埋め込み構成しましたそれはXcodeのMultiPlatform ターゲットですでは Jakeに戻しましょう Jakeがこれからプロジェクト構成をより深く説明してくれますありがとう Prachi Xcodeプロジェクトのモデリング及び構成についての成功事例について説明しますまたビルドのパフォーマンスと正確さを向上するためのできることをいくつか示しますまずスキームのビルドオプションを見てみましょうスキームピッカーをクリックし次にセクションに移動しますここで構成できる簡単なことがいくつかありますビルド順序の場合依存関係のオーダーを選択することをお勧めしますこれによりプロジェクトにターゲットが発生し依存関係グラフに従って並行して構築しますこれでマルチコアビルドのパフォーマンスを大幅に向上させることができますまた継続的インテグレーションからより速い結果が得られます対照的に手動オーダーの選択は良くないので推奨されませんこのオプションを使用するとビルドが遅くなりサイクルエラーを引き起こす可能性がありますスキームにリストされているターゲットオーダーの場合プロジェクトの依存関係と矛盾していますスキームビルドオプションのもう１つの重要な設定は Find Implicit Dependenciesですこのオプションをチェックすると Xcodeにプロジェクトの情報に基づいてターゲット間のビルド設定のリンカフラグビルドフェーズでリンクされたライブラリの名前などの依存関係の自動的な追加が許可されますこれは関連するターゲットが異なるプロジェクトにあり通常明示的なターゲット依存関係を追加できない場合特に便利ですさまざまなプロジェクト間で明示的なターゲット依存関係を追加できないために特定の順序でターゲットを構築するために手動依存関係オーダーを使用している場合暗黙的な依存関係の検索を有効にして依存関係オーダーの選択と併せて多くの場合より良い解決策です次にスクリプトフェーズとビルドルールについて説明しますプロジェクトのターゲットリストから SmoothieKitターゲットを選択します次にタブを選択しますここにProcess Recipes スクリプトフェーズがありますこれにカスタムビルドロジックが含まれていますその責務の１つは入力ごとに1つの出力を持つ多数のレシピファイルからコードを生成しそれを順番に処理することです今あなたはこれらの計算値が互いに完全に独立していることに気づくでしょうこれはそれらを並行しての実行を利用できることでパフォーマンス最適化の機会を提供しますビルドルールを使用するとまさにそれを実行できますこの作業をビルドルールに抽出する方法を見てみましょうフレームワークのプロジェクトエディタのタブに移動しプラスボタンをクリックして新しいビルドルールを追加します次にファイルパターン「*.recipe」を入力しますこれはこのルールで処理したいファイルタイプのファイル拡張子に対応します次にこのルールに依存関係を追加しますビルドルールに入力を追加する必要はありません処理する各入力ファイルを入力として自動的に取得するためですただし処理するファイルごとにルールが生成する出力ファイルのパスをビルドシステムに通知する必要があります新しい出力ファイルを追加して入力するにはプラスボタンをクリックし $（DERIVED_ FILE_ DIR） / $（INPUT_ FILE _BASE） .compiledrecipeと入力します DERIVED_FILE_DIRの下に生成されたファイルを書き込むことをお勧めですこれはビルドシステムによって管理されている適切な場所を指すためですソースルートの下に出力ファイルの生成は避けてくださいこれはソース管理に干渉する可能性があります複数のビルドを同時に実行する場合に競合につながりますもちろんスクリプトフェーズコードをルールにコピーする必要がありますスクリプトフェーズに戻り各ファイルを処理したコードをコピーします次にルールに戻ってそれを貼り付けますルールは処理する入力ごとに１回実行されることに注意してくださいそこでforループを削除し $RECIPEを $SCRIPT_INPUT_FILEに置き換えますこれは処理中の入力ファイルの絶対ファイルパスに対応します $DERIVED_FILE_DIR / $RECIPE.compiledrecipeを $SCRIPT_OUTPUT_FILE_0で置き換えますこれは以下の「Output Files」セクションに入力した出力ファイルのパスを指しますファイルパス内のスペースやその他の特殊文字が正しく処理されるように変数を引用することを忘れないでください素晴らしいここでルールで構成することがもう１つありますルールは処理する入力ごとに１回実行されることを説明しましたデフォルトではターゲットがコンパイルしているアーキテクチャごとにも１回も実行されますたとえば Mac Appターゲットルールはarm64と x86_64の場合の実行回数は１回かける入力数です４つの入力に２つアーキテクチャを掛けたものがある場合ルールは８回呼び出されますこれはオブジェクトコードなどアーキテクチャに依存したルールの出力時に役立ちますただしこの場合私のルールは基盤のCPUアーキテクチャから独立した出力を生成しますそこでアーキテクチャごとに１回実行のチェックを外します最後にビルドシステムがビルドルールへの入力ファイルに伝播するためにすべての.recipeファイルをフレームワークターゲットのコンパイルソースビルドフェーズに追加する必要があります Build Phasesに戻り Compile Sourcesを展開しプラスボタンを使用してレシピファイルを追加します
それではスクリプトフェーズに戻りましょうこれが行う残りの作業は複数のテキストファイルの内容を私たちのAppでより効率的に実行時にロードできる単一のファイルにマージすることですそしてより良いソース管理経験を持つためにスクリプトをプロジェクトファイルの外部に保持しここでインラインスクリプトエディタから呼び出しますではpackage.shへの参照に従ってコードを見てみましょうこの場合ビルドルールは適切ではありませんすべての入力を１つに結合するためにすべての入力を１度に処理する必要がありますなので並行して実行できる分離されたユニットに分割する方法はありませんだからこの作業をスクリプトフェーズで維持することは理にかなっていますしかしこれで私たちは最も重要なポイントの１つに導かれますスクリプトには指定された入力と出力の依存関係がありませんこれによりルドタスクが間違った順序で実行される可能性がありビルドが遅くなります Xcodeは他のタスクを並行して実行することに関してより保守的でなければならないからですスクリプトフェーズで使用可能性のあるファイルがわからないためですなので入力と出力の依存関係を追加することが重要ですスクリプトフェーズによってビルド内の他のタスクと比較して正しい順序で実行される作業が確実に行われるようにするためですこの特定のスクリプトでは多数の入力がありますこれらをプロジェクトファイルに１つずつ入力する代わりに xcfilelistを使いこの入力リストを外部ファイルを介してこの入力リストを管理できます先に進んでプロジェクトに１つ追加します > に移動しセクションでを選びます
このスクリプトフェーズでは処理される入力ファイルのリストを 1行に1つずつ貼り付けます。必要であればポンド記号で行を開始することでコメントを書くこともできますこれはコンテキストを追加するのに最適です次にスクリプトフェーズからこのxcfilelistを参照しますスクリプトフェーズに戻り入力ファイルリストで xcfilelistへのパスを指定します
最後にビルドルールの場合と同様に出力コンテンツが書き込まれるファイルパスを指定して出力の依存関係を指定します
言及すべきことがもう1つありますビルドルールと同様にスクリプトフェーズで提供されるいくつかの重要な環境変数があります package.shに戻って詳しく見てみましょうソースでは SCRIPT_INPUT_FILE_LIST_COUNTを参照していますこれはスクリプトフェーズに渡された入力ファイルリストの総数を指します SCRIPT_INPUT_FILE_LIST_n; これはn番目のインデックスにある入力ファイルリストの解決された絶対ファイルパスを参照しますそして SCRIPT_OUTPUT_FILE_0; これは最初の（この場合のみ）出力ファイルの解決された絶対ファイルパスを参照しますこれはクリプトフェーズに提供されるいくつかの主要な環境変数の概要ですターゲットのビルド設定はスクリプトフェーズ環境でも利用できるようになりますこれはビルドルールに固有のいくつかの環境変数とあまり一般的ではない変数の概要ですスクリプトフェーズと同様にターゲットのビルド設定はビルドルール環境でも利用できるようになりますさてここでプロジェクトをビルドしようとすると問題が発生します
ビルドログに移動して詳しく見てみましょう SmoothieKitはMultiPlatform のターゲットであるため OS用とwatchOS用に２回ビルドされますこれはこれらの各ビルドが同じパスでスクリプトフェーズの出力を生成しようとしていることを意味しますしかしこれは許可されていませんなぜならビルドシステムではビルド全体で1つのタスクのみが特定のパスで出力を生成することしかできないからですこれを解決する方法はいくつかあります簡単な解決策の１つはスクリプトフェーズの出力パスを変更してターゲットがビルドされるたびにユニークになるようにすることですこの場合別のビルド設定を使用することを検討できますプラットフォーム固有の DERIVED_FILE_DIRのようにパスを十分にユニークにして競合を解決しますただしスクリプトフェーズで実行されている実際の作業が各ターゲットのコンテキスト内で同一である場合それは単に同じ作業が２回行われる原因になりますその場合共有フレームワークターゲットが依存する新しい集約ターゲットにスクリプトフェーズを移動することをお勧めしますそれが私のプロジェクトのためにやろうとしていることです開始するにはプラスボタンをクリックしますターゲットリストの下部にあるタブを選択しを選択しますこれをリソースと呼びます次に新しいスクリプトフェーズを追加し名前スクリプトソース入力フレームワークターゲットからの出力をコピーします
最後に元のスクリプトフェーズをフレームワークターゲットから削除し新しい集計ターゲットで追加します
このように作業は１回のみ行われるため出力ファイルの競合はありません iOSとwatchOSの両方でのフレームワークのバリアントはそのスクリプトフェーズに対して正しい順序でビルドされますビルドが成功しましたさてここでPrachiに戻しますビルド設定について教えてくれますありがとう Jake さてビルド設定とは何でしょうか？これはXcodeターゲットに適用できる構築の側面を設定するためのプロパティです Xcodeはビルド設定を構成するために２つの主要なメカニズムを提供します１つ目はビルド設定エディタを使用する方法です２つ目は構成設定ファイルまたは.xcconfigファイルを使用する方法ですプロジェクト内の設定を管理するビルド設定エディタの機能を確認することから始めましょうビルド設定エディタを起動するにはまずプロジェクトナビゲータでプロジェクトを選択する必要があります次に設定するターゲットを必ず選択してください最後にタブバーのタブをクリックしますここから新しいビルド設定を追加または既存のものを変更しますクイックヘルプインスペクタを開けば選択したビルド設定の追加情報を見つけられますビルド設定は複数のレベルで定義されますこれは定義のスタックと考えることができます実際レベルフィルタをクリックすればこれらのレベルは視覚化できます各列は異なるレベルを表しビルド設定はそこで定義できそれらは右から左に評価されます最下位レベルから開始してデフォルト値があり現在選択されているSDKによって定義されていますプロジェクトレベルの構成設定ファイル Xcodeプロジェクトファイルからのプロジェクトレベルの設定構成設定ファイルで定義されたターゲット設定 Xcodeプロジェクトファイルで定義されたターゲットレベル設定そして最後にビルド設定の解決された値です太字の設定が表示されている場合は注意してくださいこれはレベルにビルド設定用の明示的な値があることを示します Xcodeが提供の他のメカニズムビルド設定を管理するための構成設定ファイルまたは .xcconfigファイルです xcconfigファイルの複数の利点は次のとおりですより良いソース管理管理ターゲットまたは構成間での設定の共有ビルド設定の高度な構成および開発環境またはテスト環境に基づく追加のxcconfigファイルを含める機能です xcconfigファイル内のビルド設定を作成する方法を見てみましょう最も基本的なレベルではビルド設定は名前代入演算子と値で構成されています条件付き構文を使用しビルド設定の値を絞り込むことができます条件付き設定は角括弧を使用して定義されますサポートされている条件には次のものがあります構成アーキテクチャおよびSDKです SDK条件で示されているようにワイルドカードはマッチングの目的で使用できますおなじみのダブルスラッシュ構文を使用しコメントも追加できますビルド設定はドルパレンス構文を使用した別のビルド設定の値を設定できますこの例では MY_OTHER_BUILD_SETTINGが YESに設定されています MY_BUILD_SETTING_NAMEの値は MY_OTHER_BUILD_SETTINGのドルパレンス構文を使用して評価しますここでもMORE_SETTINGSで見られるように複数の値を評価できますそして最後にビルド設定の既存の値 $(inherited) 値とともに使用できますこれによりビルド設定に追加の値を既存の値をすべて保持しながら追加できますこれはあなたもビルド設定名 APPEND_TO_EXISTING_SETTINGSを使うことができるので便利なフォームですビルド設定評価構文の別の使用法は他のビルド設定のセットからビルド設定を一緒に構成することですまず制御設定 IS_BUILD_SETTING_ENABLED から始めます MY_BUILD_SETTING_NOと MY_BUILD_SETTING_YESの２つの追加ビルド設定の場合この設定の値をサフィックスとして使用します最後にMY_BUILD_SETTINGと IS_BUILD_SETTING_ENABLEDの両方で構成される値を持つ MY_BUILD_SETTINGを定義しますビルド設定の評価は裏返しに行われるため最も内側の設定が評価されます IS_BUILD_SETTING_ENABLEDの値であるNOを返します最後に構成された BUILD_SETTING_NOは -use_this_oneの値に評価されますビルド設定を評価する場合値変換の基本として提供され使用できる演算子のセットがあります演算子の３つの分類は次のとおりです文字列演算子パス演算子および交換演算子ですサポートされている文字列演算子は引用符で文字列内の文字を中断します文字の大文字と小文字を変換するlowerとupper さまざまな形式で文字列を有効な識別子に変換する識別子ディレクトリを取得するための一連のパス演算子を提供しますファイル名ベース名サフィックスと標準化パスですパス演算子ごとに値の一部を置き換えることができる置換演算子がありますビルド設定が空の場合の置換値を提供するデフォルトの演算子もありますそれ以外の場合はビルド設定の既存の値を使用します最後に確認する項目は他のxcconfigファイル内の xcconfigファイル含める機能です利用できるメカニズムは２つあります最初に必要なものは次のとおりですこれにはxcconfigファイルがディスク上の存在が必要ですファイルが見つからない場合コンパイラエラーが発生します２番目はオプションのincludeですディスク上に存在する場合 xconfigファイルを含めますファイルが存在しない場合でもエラーにはなりません Xcodeプロジェクトファイルの場所に対しパスは相対的であることに注意してくださいこのすべての情報を実際のシナリオでどうまとめていくかを見てみましょうこの例では以下の問題を解決する方法を見ていきます私たちの開発マシンではコンパイラは式について積極的に警告する必要があるためタイプチェックに時間がかかりすぎますただしCIマシンは低速ですそこで式のチェックにかかる時間を増やす必要があります私たちのソリューションでは３つの構成設定ファイルがあります debug　common およびci.xcconfigですデバッグxcconfigファイルはデバッグビルドに使用されますそして複数の追加のフラグを OTHER_SWIFT_FLAGS ビルド設定を介して Swiftコンパイラに渡します共通のxcconfigファイルはオプションでci.xcconfig ファイルが含まれますまた型式の警告を制御する OTHER_SWIFT_FLAGS設定も定義します他のフラグ設定は $(inherited)を利用し debug.xcconfigファイルやデフォルト値が200の MAX_EXPRESSION_TIMEのビルド設定評価など含まれていることを確認します cixcconfigファイルは MAX_EXPRESSION_TIMEの場合のオーバーライド値を定義します最後にXcodeにサポートされる構成レベルの１つにこれらのxcconfigファイルを適用する方法を通知する必要がありますこれはプロジェクトエディタを介して行われそれが私たちがここで見ているものですセクションから定義されたビルド構成のプロジェクトレベルまたはターゲットレベルのいずれかでプロジェクトから任意の設定ファイルを適用できますここでFrutaのデバッグ構成用にプロジェクトレベルで適用の debug.xcconfigファイルを確認できますまたcommon.xcconfigファイルがプロジェクト内のターゲットごとに設定されますソリューションを要約するためにデフォルトの演算子が使用され MAX_EXPRESSION_TIMEのデフォルト値を定義します ci.xcconfigファイルはオプションで含まれていました CIシステムにのみ存在するためですそしてMAX_EXPRESSION_TIME デフォルト値のオーバーライドは ci xcconfigファイルで使用されましたこれで実際の例は終わりですそれではJakeに戻して私たちが扱ったすべてを確認しましょうありがとう Prachi 要約しましょう MultiPlatformフレームワークとそしてそれがビルド設定とビルドフェーズを管理する MultiPlatformプロジェクトでどのように簡単な方法を提供するかについて学びましたターゲットを並行して構築することでパフォーマンスを構築しプロジェクト構成を改善する方法を依存関係の順序に従ってビルドルールとビルドフェーズを適切に使用する方法をそして依存関係を指定することの重要性を見てきました最後にビルド設定について構成設定ファイルの使用方法とそれらをより簡単に管理しそれらの構文を探りそしてそれが提供するすべての構成要素深く掘り下げましたこのレッスンが一連の便利ツールを提供すること開発経験を最大限に活用するのに役立つことを願っていますご覧いただきありがとうございます！ ♪

7:38 - Shell Script - Output Files
```
$(DERIVED_FILE_DIR)/$(INPUT_FILE_BASE).compiledrecipe
```

"$SRCROOT/Scripts/gen-code.sh" "$SCRIPT_INPUT_FILE" "$SCRIPT_OUTPUT_FILE_0"

10:15 - Shell Script - code

# Package up the recipes.

echo "packaging..."

for i in $(seq 0 $(expr ${SCRIPT_INPUT_FILE_LIST_COUNT} - 1)) ; do
    infile_="SCRIPT_INPUT_FILE_LIST_$i"
    eval infile=\$$infile_

    while IFS= read -r file; do
        cat "$file" >> "$SCRIPT_OUTPUT_FILE_0"
    done < "$infile"
done

11:34 - XCFileList

$(SRCROOT)/Recipes/Instructions/berry-blue.md
$(SRCROOT)/Recipes/Instructions/carrot-chops.md
$(SRCROOT)/Recipes/Instructions/hulking-lemonade.md
$(SRCROOT)/Recipes/Instructions/kiwi-cutie.md
$(SRCROOT)/Recipes/Instructions/lemonberry.md
$(SRCROOT)/Recipes/Instructions/love-you-berry-much.md
$(SRCROOT)/Recipes/Instructions/mango-jambo.md
$(SRCROOT)/Recipes/Instructions/one-in-a-melon.md
$(SRCROOT)/Recipes/Instructions/papas-papaya.md
$(SRCROOT)/Recipes/Instructions/pina-y-coco.md

11:57 - Shell Script - Input File Lists
```
$(SRCROOT)/FileList.xcfilelist
```
12:11 - Shell Script - Output Files
```
$(PROJECT_TEMP_DIR)/instructions.mdarchive
```

12:50 - Environment Variables - Script Phases

// These environment variables are available in script phases:

SCRIPT_INPUT_FILE_COUNT // This specifies the number of paths from the Input Files table.
SCRIPT_INPUT_FILE_n // This specifies the absolute path of the nth file from the Input Files table, with build settings expanded.

SCRIPT_INPUT_FILE_LIST_COUNT // This specifies the number of input file lists.
SCRIPT_INPUT_FILE_LIST_n // This specifies the absolute path of the nth "resolved" input file list with contained paths made absolute, build settings expanded, and comments removed.

SCRIPT_OUTPUT_FILE_COUNT // This specifies the number of paths from the Output Files table.
SCRIPT_OUTPUT_FILE_n // This specifies the absolute path of the nth file from the Output Files table, with build settings expanded.

SCRIPT_OUTPUT_FILE_LIST_COUNT // This specifies the number of output file lists.
SCRIPT_OUTPUT_FILE_LIST_n // This specifies the absolute path of the nth "resolved" output file list with contained paths made absolute, build settings expanded, and comments removed.

* n in the above examples refers to a 0-based index.

13:00 - Environment Variables - Build Rules

// These environment variables are available in build rules:

SCRIPT_INPUT_FILE // This specifies the absolute path of the main input file being processed by the rule.

OTHER_INPUT_FILE_FLAGS // This specifies custom command line flags defined for the input file in the Compile Sources build phase.

SCRIPT_INPUT_FILE_COUNT // This specifies the number of paths from the Input Files table.
SCRIPT_INPUT_FILE_n // This specifies the absolute path of the nth file from the Input Files table, with build settings expanded.

SCRIPT_OUTPUT_FILE_COUNT // This specifies the number of paths from the Output Files table.
SCRIPT_OUTPUT_FILE_n // This specifies the absolute path of the nth file from the Output Files table, with build settings expanded.

SCRIPT_HEADER_VISIBILITY // This is set to "public" or "private" if the input file being processed is a header file in a Headers build phase, and its Header Visibility is set to one of those values.

HEADER_OUTPUT_DIR // This specifies the output directory to which the input file should be copied, if the input file being processed is a header file in a Headers build phase.

* n in the above examples refers to a 0-based index.

18:17 - Build setting definition
```
MY_BUILD_SETTING_NAME = "A build setting value"
```

18:30 - Build setting definition with conditions

MY_BUILD_SETTING_NAME = "A build setting value"
MY_BUILD_SETTING_NAME[config=Debug] = -debug_flag
MY_BUILD_SETTING_NAME[arch=arm64] = -arm64_only
MY_BUILD_SETTING_NAME[sdk=iphone*] = -ios_only

19:50 - Build setting composition

IS_BUILD_SETTING_ENABLED = NO
MY_BUILD_SETTING_NO = -use_this_one
MY_BUILD_SETTING_YES = -use_this_instead
MY_BUILD_SETTING = $(MY_BUILD_SETTING_$(IS_BUILD_SETTING_ENABLED))

21:08 - Build setting evaluation operators (paths)

$(MY_PATH:dir)
$(MY_PATH:file)
$(MY_PATH:base)
$(MY_PATH:suffix)
$(MY_PATH:standardizepath)

21:21 - Build setting evaluation operators (replacement)

$(MY_PATH:dir=/tmp)
$(MY_PATH:file=/better.swift)
$(MY_PATH:base=another)
$(MY_PATH:suffix=m)
$(MY_PATH:default=YES)

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC21