Community Translated by MoTa_728816 Version: **
ModusToolbox™ のビルドシステムはプロジェクトを makefile に含まれている情報をもとに作成します。このドキュメントは makefile を管理してよくある作業を達成する方法について述べます。このドキュメントは質問と回答の形式をとっています。回答においては一般的なユースケースにおいて目的の作業を達成するために必要な知識と、簡単な抜粋例を提供します。
このドキュメントでは以下の用語を使用します：
・メイクファイルディレクトリ： makefile を含むフォルダ；サンプルコード (スターターアプリケーション) やあなたのプロジェクト等
・プロジェクトディレクトリ： プロジェクトの生成プロセス中に作成されるフォルダ； makefile のコピー及び、プロジェクトの全てのファイルを含みます。
・.lib ファイル： GitHub レポジトリの URL 及び特定のコミット用のタグ(tag)かSHA を含むテキストファイル
・自動検索：ビルドシステムが自動的にファイルを見つけ出すために使用するプロセス
ModusToolbox のビルドシステムを使用してプロジェクトを作成すると、プロジェクトに必要な全てのファイルはプロジェクトディレクトリの中にコピーされます。その中にはサンプルコード (スターターアプリケーション) のオリジナルの makefile も含まれます。
1. makefile とは何ですか、そしてどのように使うのですか？
makefile にはプロジェクトを作成してビルドする方法が記述されています。どのファイルを使用するか、どのライブラリをインクルードするか、どのビルドツールを使用するか、等の情報が含まれています。この makefile は ModusToolbox のビルドシステム専用のものです。コマンドラインインターフェースの一般的は背景や関連情報については、Running ModusToolbox from the Command Line をご参照ください。
Cypress は スターターアプリケーションとも考えていただける、多数のサンプルコードを GitHub で提供しています。それそれがそのアプリケーション用の makefile とソースファイルを含んでいます。サンプルコードは自己完結型ではありません。ModusToolbox IDE の New Application ウィザードや Project Creator ツールを使用すると、ビルドシステムが起動され、プロジェクトに必要とされる全てのファイルがプロジェクトディレクトリに現れます。ModusToolbox IDE を使用している場合、このフォルダはあなたの Eclipse ワークスペースにあります。Project Creator を使用している場合、プロジェクトディレクトリはあなたが指定した場所になります。その後、ご希望のファイルを追加したり、コマンドラインから作業したりすることが可能です。
makefile はプロジェクトの生成とビルドプロセスをコントロールします。プロジェクトディレクトリの makefile はサンプルコードのオリジナル makefile の複製です。
2. サンプルコードに含まれる makefile とプロジェクトディレクトリに含まれる makefile のどちらを編集すべきですか？
通常、プロジェクトはサンプルコードから作成されます、その為あなたのプロジェクトディレクトリ内になる makefile を編集してください。この変更はあなたのプロジェクト内だけで有効になります。
しかし、GitHub からサンプルコードをローカルコピーとしてダウンロードすることも可能です。もしあなたのローカルコピーのサンプルコード内の makefile を編集した場合、そのサンプルを元に作成したすべてのプロジェクトにその変更が反映されます。
他の質問と回答では、このドキュメントではメイクファイルディレクトリを指します。サンプルコードのオリジナルの makefile はプロジェクトディレクトリ内に複製されます。
3. 自動検索が見つけられるようにプロジェクトにファイルを追加するにはどうすれば良いでしょうか？
ビルドシステムは自動的にメイクファイルディレクトリにある全てのソースファイルを見つけます。これには .c, .cpp, .h, .S, .s, .o 及び .a ファイルが含まれます。
結果として、簡単な方法はそのファイルをメイクファイルディレクトリに追加することです。検索は再帰的に行われますので、メイクファイルディレクトリツリー内のどこにでもファイルを追加することが可能です、そして make ビルドコマンドはその追加されたファイルを見つけます。
しかし、一般的なユースケースで追加したいファイルがメイクファイルディレクトリ外にある場合；例えば会社のサーバーに置かれているソースのコレクション等。
ビルドシステムで検索されない場所にあるソースやヘッダーを手動で追加する場合には SOURCES と INCLUDES 変数をご使用ください。
SOURCES の内容はスペースで区切られた個々のファイル名となります。ファイルの場所を指定するパスは絶対パスでもメイクファイルディレクトリからの相対パスでも可能です。複数のファイルを検索するためにワイルドカードを含む検索パターンも作成できます。
SOURCES=$(wildcard ../MySource1/*.c) $(wildcard ../MySource2/*.c)
ヘッダーファイルを含むフォルダを指定するのには INCLUDES 変数をお使いください。内容はスペースで区切られたそれぞれのディレクトリへの相対パスとなります。
INCLUDES=../MySource1 ../MySource2
特定のファイルやフォルダを無視するように設定することも可能です。7. どうすれば自動検索に特定のファイルを無視させるようにできますか？ を参照してください。
4.スペース(空白)を含むパスを指定するのにはどうしたら良いですか？
多くのビルドツールにとってパスに含まれたスペースは問題の原因になりますので、可能な限りそのようなパスの使用は避けてください。もしスペースを含むパスの使用が不可避の場合には、スペースを含むパスを適切に回避するために $(wildcard ) 機能を使用してください。
INCLUDES=$(wildcard ../My Source/)
CY_COMPILER_PATH=$(wildcard C:/Program Files (x86)/IAR Systems/Embedded Workbench 7.3/arm/bin)
5. 変数が値として相対パスを要求する場合に絶対パスを使用するのにはどうしたら良いですか？
追加したいファイルが会社のサーバーやローカルマシンの特定の場所にあるかも知れません。絶対パスは容易に対応することが可能です。この場合、make の変数で絶対パスに設定されたものを作成して、「相対」パスの一部として使用することが可能です。
ABS_PATH=C:/<path_to_source>/ExternalSourceFiles/
SOURCES=$(ABS_PATH)/external_source.c
6.ビルドシステムではスラッシュはどのように扱うのでしょうか？
Windows上の ModusToolbox は Cygwin の make を内部で使用しています。Cygwin は POSIX互換の環境です。POSIX のパスはスラッシュ ( / ) をセパレータとして使用します。その為、makefile 内でパスを指定する場合にはスラッシュ( / )を使用しなくてはなりません。
Windowsのパス名はセパレータにバックスラッシュ ( \ ) を使用しています。長い絶対パスが使用される場合、バックスラッシュ ( \ ) を スラッシュ ( / ) に置き換える必要があります、この変換を容易にするために $(subst ) 機能が使用できます。
WIN_PATH=C:\Users\<some_long_path>\HeaderFiles
HEADER_FILE=$(subst \,/,$(WIN_PATH))
INCLUDES=$(HEADER_FILE)
7. どうすれば自動検索に特定のファイルを無視させるようにできますか？
例えば、テストやベリフィケーションに使用されるファイルを含んだサブフォルダがあり、アプリケーションの実行形にそれらを含んでコンパイルさせたくない場合。
CY_IGNORE 変数を使用してください。変数の値はスペース(空白)で区切られた自動検索に無視させたいフォルダおよびファイルのリストです。メイクファイルディレクトリからの相対パスを使用してください。複数のファイルを無視させるためにワイルドカードを含むパターンを作成することが可能です。
CY_IGNORE=./filename.c ./TestFolder
CY_IGNORE+=$(wildcard ./lib/lib1/tests/*.c)
8. テキストファイル .lib を使用して外部のライブラリを追加するのにはどうしたら良いですか？
ModusToolbox のビルドシステムは git バージョンコントロールシステムを使用します。通常 .lib ファイルは git レポジトリへの URL とレポジトリ中の特定のコミットを示すテキスト一行のファイルです。Cypress から提供されている .lib ファイルは通常 GitHub 上の、公開されている Cypressが所有するレポジトリを指しています。例えば、この .lib ファイルは ペリフェラルドライバーライブラリ (PDL) の最新版をプロジェクトにインポートします。
https://github.com/cypresssemiconductorco/psoc6pdl/#latest-v1.X
ご自分のライブラリを追加するのには、gitリポジトリを指す .lib ファイルを作成してください。その .lib ファイルをメイクファイルディレクトリに置いてください。例えば：
https://gitrepos.company.com/mylibrary/#52fac15a7c06ecac951bc67fff94097e9f671efb
make gitlibs コマンドは全ての .lib ファイルを見つけて処理し git コマンドを使用して適切なコードを複製もしくはプルします。そして、その .lib ファイルにリストされている特定のハッシュやタグをチェックします。ソースファイルはプロジェクトフォルダのルートにある libs フォルダの中にコピーされます。ModusToolbox の new project フローや Library Manager は自動的に make gitlib を実行します。
9. 外部のライブラリをファイルやファイルパスを指定して追加するのにはどうしたら良いですか？
3. 自動検索が見つけられるようにプロジェクトにファイルを追加するにはどうすれば良いでしょうか？を参照してください。
10. 自分のプロジェクトにプリコンパイルされたバイナリを追加するのにはどうしたら良いですか？
ビルドシステムは自動的にメイクファイルディレクトリにある .o や .a ファイルを見つけ出します。簡単な方法は追加したいファイルをメイクファイルディレクトリに置くことです。
しかし、一般的なユースケースではバイナリファイルはメイクファイルディレクトリの外にあることが普通です。アプリケーション毎のプリコンパイルドバイナリを指定するのには LDLIBS 変数を使用してください。LDLIBS の値はスペースで区切られた該当ファイルのリストです。ファイルの位置を指定するのにはメイクファイルディレクトリからの相対パスを使用してください。複数ファイルの検索用にワイルドカードを使ったサーチパターンを作成することも可能です。これらのファイルはリンクプロセス時に統合されます。
LDLIBS=../MyBinaryFolder/binary.o
LDLIBS+=$(wildcard ../lib/*.a)
もし、そのバイナリファイル用のヘッダーファイルをインクルードする必要がある場合には、INCLUDES 変数を使用してください。3. 自動検索が見つけられるようにプロジェクトにファイルを追加するにはどうすれば良いでしょうか？を参照してください。
11. ビルドツールはどのように指定したら良いですか？
makefile はデフォルトでは ModusToolbox 2.0 のパッケージに含まれている GCC Arm® 7.2.1 を使用します。makefile の内部では、変数の TOOLCHAIN と CY_COMPILER_PATH の組み合わせがお使いになりたいビルドツールを指定するのに使用されます。
他のサポートされているツールチェーンには ARM コンパイラと IAR コンパイラがあります、これらは別途インストールする必要があります。
TOOLCHAIN 変数で設定できるオプションには：
・TOOLCHAIN=GCC_ARM (ModusToolbox IDE に含まれている GCC 7.2.1 を使用します)
・TOOLCHAIN=ARM (ARM コンパイラを使用します)
・TOOLCHAIN=IAR (IAR コンパイラを使用します)
選択されたコンパイラによって、CY_COMPILER_PATH変数にコンパイラのバイナリディレクトリの絶対パスを指定してください。
CY_COMPILER_PATH=$(wildcard C:/Program Files (x86)/IAR Systems/Embedded Workbench 7.3/arm/bin)
CY_COMPILER_PATH=$(wildcard C:/Keil/ARM/ARMCC/bin)
12. ビルドシステムにカスタムビルドツールの場所を指定するのにはどうしたら良いですか？
ModusToolbox が直接サポートしていないツールチェーンを使用する場合には次に手順に従ってください：
1. プロジェクトディレクト内の以下のディレクトリに移動してください
libs\psoc6make\make\toolchains\
注意：これらのファイルはオリジナルのサンプルコードフォルダには含まれていません。
これらはビルドシステムがプロジェクトを作成するときにプロジェクトに追加されます。
2. <NEW_TOOLCHAIN>.mk というファイルを新規に作成してツールチェーンの設定を追加します。
3. BSPディレクトリ内の TARGET_<BSP>\linker\ へ移動して、TOOLCHAIN_<NEW_TOOLCHAIN> というディレクトリを作成します。そのディレクトリに当該ツールチェーン用のlinker scriptを追加します。接頭の「TOOLCHAIN_」が重要なことに注意してください。
4. BSPディレクトリ内の TARGET_<BSP>\startup\ へ移動して、そのディレクトリに当該ツールチェーン用の startup ファイルを追加します。
5. 11. ビルドツールはどのように指定したら良いですか？ に記載されている手順を行ってください。
6. アプリケーションをビルドしてください。
ModusToolbox BSPにはサポートされているツールチェーン用の startup と linker ファイルが含まれています。もしお使いになるツールチェーンが異なるファイルを必要とする場合には、別途ご用意していただく必要があります。
13. コンパイラのフラグはどのように指定したら良いでしょうか？
CFLAGS と CXXFLAGS 変数を C と C++ それぞれにコンパイラフラグを追加するのに使用してください。有効なオプションについては当該ツールチェーンのドキュメントを参照してください。
例：GNU ARM ツールチェーンのコンパイラ用のさまざまなオプションは ここで参照いただけます。オプションは下記のように設定できます：
CFLAGS=-Wall -O2
CXXFLAGS=finline-functions
各変数の値はスペースで区切られたコンパイラがサポートしているフラグのリストです。
変更が有効であることを確認するのには、makefile 内の変数 VERBOSE の値を'1'に設定してください。これでビルドを実行時に全コマンドラインが表示されます。
コンパイラフラグが正確にどこで現れるかはお使いのツールチェーンや IED に依存します。また makefile ではなく IDE を使用して VERBOSE オプションを設定することも可能です。例えば、図1のように ModusToolbox IDE では、project properties を開いて、C/C++ Build のパネルをアクセスします。ここで Build command 項目内で VERBOSE=1 を設定することが出来ます。
図 1. Build Command
変更を保存するために Apply and Close をクリックして、アプリケーションをビルドしてください。IDE で行われた変更は makefile に反映されないことにご注意ください。
同様に、コマンドラインを使用している場合、「 make build VERBOSE=1 」と指定することで、ビルド時の全コマンドラインを表示させることが可能です。
14. カスタムビルドコンフィグレーションはどのようにしたら作成できますか？
ModusToolboxは、デフォルトはツールチェーン毎のデバッグ(Debug)とリリース(Release)のビルドコンフィグレーションを提供しています。それらは lib\psoc6make\make\toolchains 内の該当する <TOOLCHAIN>.mk で定義されています。独自のビルドコンフィグレーションを作成したい場合には、CONFIG 変数に値を設定してください。例：
CONFIG=MyBuild
また、ビルドシステムは CONFIG 変数をプロジェクトフォルダ内の build\<BSP>\ に生成する出力ディレクトリ名に使用します。
この変数の値を空(null)にしてはいけません。
15. リンカフラグはどのように指定したら良いですか？
リンカフラグを独自に追加する場合には LDFLAGS を使用してください。有効なオプションについては当該ツールチェーンのドキュメントを参照してください。
例：GNU ARM ツールチェーンのさまざまなオプションはここで参照いただけます。
LDFLAGS=-nodefaultlibs
値はスペースで区切られている必要があります。
16. 独自のリンカスクリプトを使用するにのにはどのようにしたら良いですか？
ビルドシステムは自動的にデフォルトのリンカスクリプトを使用します。
デフォルトのリンカスクリプトはボードサポートパッケージ(BSP) にサポート対象のツールチェーン (Arm, GCC, IAR) 用のものは含まれています。
独自のリンカスクリプトを使用するためには、LINKER_SCRIPT 変数の値に当該ファイルを指定してください。値は makefile からリンカスクリプトへの相対パスにしてください。
LINKER_SCRIPT=../../MyFiles/myLinkerScript.ld
スクリプトはご使用のツールチェーンと互換性がなくてはいけません。(.sct, .ld, .icf)
17. プリ-ビルドタスクはどのように指定したら良いですか？
プリ-ビルドコマンドの指定は PREBUILD 変数を使用します。各コマンドはセミコロン ( ; ) を使用して分けてください。ファイルの場所指定はメイクファイルディレクトリからの相対パスで指定してください。
PREBUILD=../prebuild1.bat; python prebuild2.py
18. ポスト-ビルドタスクはどのように指定したら良いですか？
プリ-ビルドコマンドの指定は PREBUILD 変数を使用します。各コマンドはセミコロン ( ; ) を使用して分けてください。ファイルの場所指定はメイクファイルディレクトリからの相対パスで指定してください。
POSTBUILD=$(CY_COMPILER_PATH)/bin/arm-none-eabi-objcopy.exe -O ihex $(CY_CONFIG_DIR)/$(APPNAME).elf $(CY_CONFIG_DIR)/$(APPNAME).hex; python sample.py
19. スタティックライブラリをビルドするのにはどのようにしたら良いですか？
ビルドシステムは実行形かライブラリの作成をサポートしています。もしプロジェクトが実行形をビルドする場合には、APPNAME 変数がセットされ、LIBNAME 変数が空(Empty)になります。
ライブラリをビルドするには、APPNAME 変数が空(Empty) で、LIBNAME 変数にライブラリ名が設定されていることを確認してください。
20. コンポーネント (COMPONENT) とは何ですか？
コンポーネントはファイルのコレクションを含むフォルダです。通常コンポーネントはアプリケーション内の何らかの特長や機能を実装する複数のファイルで構成されています。例えば、Cypress BSPでは、ハードウェアの設計が BSP_DESIGN_MODUS という名称のコンポーネントに含まれています。それには design.modus ファイルと場合によって BSP に関連するハードウェアの設定ファイルが含まれます。
コンポーネントは追加したり無効にしたりすることが可能です。
21. 独自のコンポーネントを作成してアプリケーションに追加するのにはどうしたら良いですか？
「COMPONENT_<NAME>」という名称のフォルダを作成してください。自動検索が見つけられる場所であればどこにでも作成することが可能です。そのコンポーネント用のファイルをそのフォルダに置いてください。フォルダ名の接頭は「COMPONENT_」である必要があることに注意してください。
その後、当該コンポーネントをアプリケーション追加するのには
COMPONENTS+=<NAME>
を使用してください。フォルダ名の接頭語が使われていないことに注意してください。例えば、COMPONENT_MY_COMPONENT
というフォルダを作成した場合、アプリケーションに当該コンポーネントを追加するのには makefile 内で下記のように記述してください：
COMPONENTS+=MY_COMPONENT
22. コンポーネントを無効にするのにはどうしたら良いですか？
DISABLE_COMPONENTS+=<NAME> を使用してコンポーネントを無効にしてください。
例えば：
DISABLE_COMPONENTS+=MY_COMPONENT
23. BSPのデフォルトの design.modus ファイルを無効にするのにはどうしたらよいですか？
プロジェクトに独自のハードウェアコンフィグレーションを適用したくなるかも知れません。
- design.modus ファイルはデフォルトの BSP_DESIGN_MODUS コンポーネントの一部です。これを行うためには、デフォルトのコンポーネントを無効にして、新しい独自のコンポーネントを追加します。
この作業の詳細はいくつかの BSP の BSP User Guide に含まれています。これが 例 です。Overriding the BSP design.modus File という章を見つけてください。
ModusToolbox IDE か Project Creator ツールを使用してプロジェクトを作成すると、このファイルのローカルコピーが得られます。このファイルを直接変更することも可能です；無効にする必要はありません。しかし、makefile を使用して新しいアプリケーションを再構築した場合、変更は新しいアプリケーションに反映されません。もし BSP のヴァージョンを更新した場合、ウォーニングを無視すると先に施した変更は失われてしまうかも知れません。この危険性を回避するために、BSP内のデフォルトコンポーネントを無効にすることが可能です。
このためには、独自のコンポーネントを作成してください。例えば、デフォルトのコンポーネントを複製して名称を変更してから、そのコンポーネントに意図する変更を施すことが可能です。BSP ドキュメントに正確な詳細が記載されています。
その後、makefile 内で、デフォルトを無効にして、独自の代替を使用するようにコードを記述します。例えば、「CUSTOM_DESIGN_MODUS」という名のコンポーネントを設計した場合、アプリケーション用の makefile には下記内容が含まれます：
# Disable default component
DISABLE_COMPONENTS+=BSP_DESIGN_MODUS
# Add my custom component
COMPONENTS+=CUSTOM_DESIGN_MODUS
24. 独自の BSP を作成するのにはどうしたら良いですか？
プロジェクトが Cypress のキットを使用しない場合、独自の BSP が必要になります。正確には、この話題は makefile となんら関係はありません。しかし、ひとたび独自の BSP を手に入れた場合、独自の BSP を使用するために makefile を修正しなくてはなりません。
コマンドラインから新規の BSP を作成することが可能です。アプリケーションかプロジェクトのディレクトリから、make bsp TARGET_GEN=<BoardName> を使用してください。
現在の BSP を元に BSP が作成されます。現在のプロジェクトと異なるデバイスを指定したり、無線のようなデバイスを追加することも可能です。例えば：
make bsp TARGET_GEN=MyBoard DEVICE_GEN=CY8C624ABZI-D44 ADDITIONAL_DEVICES_GEN=CYW4343WKUBG
その後、プロジェクトの必要に応じて新しい BSP 内の任意のファイルを修正することが可能です。新しい BSP は指定されたデバイス用のデフォルト リンカスクリプトと startup ファイルを含みます。
この作業を手動で行うための詳細情報は BSP のドキュメントに含まれています。PSoC 6 MCU BSP 用であれば、各 BSP の BSP User Guide に含まれています。これが 例 です。Creating a BSP for Your Board という章を見つけてください。
Bluetooth SDK で使用されている BSP については、その情報は wiced_btsdk ReadMe ファイルの Using BSP(platforms)の章にあります。同じ情報が各デモアプリケーションの ReadMe ファイルにも含まれています。
25. 自分のアプリケーションに独自の BSP を使用するのにはどうしたら良いですか？
恐らく Cypress キットではないハードウェア用にプロジェクトを作成していると思います。その基板をサポートしている独自の BSP を使用します。独自の BSP は TARGET_<BSP_NAME> というフォルダに入っています。makefile 内で、TARGET 変数をその基板に合うように設定してください。
例えば、もし BSP の名称が「MyBoard」の場合、BSP の内容は TARGET_MyBoard というフォルダ内にあります、そして makefile は以下のようになります：
# Target board/hardware
TARGET=MyBoard
make getlibs を実行すると、当該プロジェクト内の TARGET_MyBoard というフォルダの中に BSP ファイルが現れます。