CubeSuite+ を使って、RX63Tの開発を行っております。
「ビルド・プロジェクト」を行うと、全ファイルがコンパイルされてしまい、非常に時間がかかります。
変更したファイル、影響のあるファイルのみをコンパイルしたいのですが、いい方法があれば教えてください。
バグ製作所さん、こんにちは。NoMaYです。所望の動作になったようですので良かったです。この[外部変数アクセス最適化を行う]というのは、以前の別スレッドの「ビルドが2回繰り返される」件でも関係していたオプションのことですね。ちなみに、[一括ビルド]に戻しても所望の動作が得られるのであれば、先日のじまさんのリプライのリンク先のオンラインヘルプに書かれていたようにファイル毎にコンパイラを起動する時間の無駄が無くなってビルドが速くなる筈ですので、そうしてしまって良いと思います。(以下の補足のように色々見えて来たように思いますので。)[追記] 2017/07/20 01:07すみません。後の投稿でも書いたのですが、このリプライで書き忘れたことがありました。戻した直後の1回目の[ビルド]→[ビルドプロジェクト]の時は、CS+が「何かしらコンパイルオプションが変更されたので兎にも角にも全ファイルをコンパイルし直さなければならない」と判断するようです。なので、2回目(及びそれ以降)の[ビルド]→[ビルドプロジェクト]でのCS+の挙動が変わるかどうかということになります。[補足]試しに、私も手元のプロジェクトの設定を変更して、以下の画面コピーの通り再現させてみました。CS+(というかコンパイラ)のオンラインヘルプも読んでみましたが、察するに、このオプションで[はい(モジュール間で最適化)(-map)]を指定すると「コンパイル・リンクが2回ずつ実施される」上に「2回目のコンパイルでは全ファイルがコンパイルされる」そういうものなのだろうと思われます。[はい(モジュール間で最適化)(-map)]を指定した場合:2回行われるビルドの1回目は変更ファイルのみコンパイルされるが2回目は全ファイルがコンパイルされる-map - CS+ V5.00 オンラインヘルプ ＞ コンパイラ編 ＞ コマンド・リファレンス ＞ オプション ＞ コンパイル・オプション ＞ 最適化オプションここでは他に、[はい(モジュール内で最適化)(-smap)]を指定することも出来るのですが、その場合は以下の画面コピーの通り普通にコンパイル・リンクが1回行われるだけでした。[はい(モジュール内で最適化)(-smap)]を指定した場合:ビルドは1回行われるだけであり変更ファイルのみコンパイルされる-smap - CS+ V5.00 オンラインヘルプ ＞ コンパイラ編 ＞ コマンド・リファレンス ＞ オプション ＞ コンパイル・オプション ＞ 最適化オプションなお、[最適化レベル]の設定を[Max(-optimize=max)]にすると自動的に[外部変数アクセス最適化を行う]の設定が[はい(モジュール間で最適化)(-map)]になりますが、併せて以下の画面コピーのようにリンカの設定も変更されました。そして、1回目のビルドではBLSファイルが生成されていました。
バグ製作所さん、こんにちは。すみません。1つ書き忘れたのですが、戻した直後の1回目の[ビルド]→[ビルドプロジェクト]の時は、CS+が「何かしらコンパイルオプションが変更されたので兎にも角にも全ファイルをコンパイルし直さなければならない」と判断するようです。なので、2回目(及びそれ以降)の[ビルド]→[ビルドプロジェクト]でのCS+の挙動はどうでしょうか？ (実は正直に言うと、リプライしてから暫く経って気付いたのですが、最初のリプライのビルド方法を変更した直後においても同じ話があったのですが、そちらも書き忘れてしまっていました。)2回目(及びそれ以降)でも全ファイルがコンパイルされるのであれば、ちょっと気になりますが、私とバグ製作所さんでCS+(というかCubeSuite+)のバージョンが異なるという話もあったりしますので、3点セットに腰を落ち着けて作業を進められた方が良さそうですね。
バグ製作所さん、こんにちは。結果報告どうもありがとうございました。書き忘れなどしてしまって申し訳なかったです。それから、ルネサスさんへ。別スレッド(リンク先のほやさんの投稿の1つ前の私の投稿の最後の追記の箇所)で思い出したのですが、e2 studioではCC-RXのマニュアル非記載オプションでGCC＋GNUMAKEの依存関係検出メカニズム(.dファイルを介してGCCがGNUMAKEに依存関係情報をフィードバックするメカニズム)と同様なことが行われているようです。ただし、e2 studioでは、過去のしがらみなのかと思いますが、依存関係情報ファイル(.dファイル)生成とコンパイルで2回CC-RXを起動している(且つファイル毎にCC-RXを起動している)こともあり結構時間が無駄になっているようです。その点は、CS+では、一括ビルドで依存関係情報ファイル(.dファイル)生成もコンパイルも同時に行われるようにして時間短縮を図った上で、私達がFAQに気付かなくても所望の動作が得られるようにならないものでしょうか、、、以下、別スレッドでのビルド時(エラー発生時)のログと画面に赤目印を付けたものです。
'Scanning and building file: ../src/r_usb_pcdc_descriptor.c''Invoking: Scanner and Compiler'ccrx -MM -MP -output=dep="src/r_usb_pcdc_descriptor.d" -MT="src/r_usb_pcdc_descriptor.obj" -MT="src/r_usb_pcdc_descriptor.d" -lang=c99 -include="E:\tools\micom\Renesas\CS_~1\CC\CC-RX\V203~1.00/include","C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp","C:\Renesas\cspproj\RX631_RSPI_FIT\r_pincfg","C:\Renesas\cspproj\RX631_RSPI_FIT\r_rspi_rx","C:\Renesas\cspproj\RX631_RSPI_FIT\r_rspi_rx\src","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\src\driver\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\src\hw\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_pcdc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_pcdc\src\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_config" -debug -nomessage -isa=rxv1 -fpu -nologo -define=__RX=1 "../src/r_usb_pcdc_descriptor.c"ccrx -lang=c99 -output=obj="src/r_usb_pcdc_descriptor.obj" -include="E:\tools\micom\Renesas\CS_~1\CC\CC-RX\V203~1.00/include","C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp","C:\Renesas\cspproj\RX631_RSPI_FIT\r_pincfg","C:\Renesas\cspproj\RX631_RSPI_FIT\r_rspi_rx","C:\Renesas\cspproj\RX631_RSPI_FIT\r_rspi_rx\src","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\src\driver\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\src\hw\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_pcdc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_pcdc\src\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_config" -debug -nomessage -isa=rxv1 -fpu -nologo -define=__RX=1 "../src/r_usb_pcdc_descriptor.c"'Finished scanning and building: ../src/r_usb_pcdc_descriptor.c''Scanning and building file: ../src/r_usb_pcdc_echo_apl.c''Invoking: Scanner and Compiler'ccrx -MM -MP -output=dep="src/r_usb_pcdc_echo_apl.d" -MT="src/r_usb_pcdc_echo_apl.obj" -MT="src/r_usb_pcdc_echo_apl.d" -lang=c99 -include="E:\tools\micom\Renesas\CS_~1\CC\CC-RX\V203~1.00/include","C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp","C:\Renesas\cspproj\RX631_RSPI_FIT\r_pincfg","C:\Renesas\cspproj\RX631_RSPI_FIT\r_rspi_rx","C:\Renesas\cspproj\RX631_RSPI_FIT\r_rspi_rx\src","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\src\driver\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\src\hw\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_pcdc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_pcdc\src\inc","C:\Renesas\cspproj\RX631_RSPI_FIT\r_config" -debug -nomessage -isa=rxv1 -fpu -nologo -define=__RX=1 "../src/r_usb_pcdc_echo_apl.c"../src/r_usb_pcdc_apl.h(43):E0520005:Could not open source file "r_sci_rx_if.h"../src/r_usb_pcdc_apl.h(44):E0520005:Could not open source file "r_usb_rsk_sci.h"src/subdir.mk:24: recipe for target 'src/r_usb_pcdc_echo_apl.obj' failedmake: *** [src/r_usb_pcdc_echo_apl.obj] Error 1
ちなみに、生成された依存関係情報ファイル(.dファイル)の1つは以下の通りでした。HardwareDebug\src\r_usb_pcdc_descriptor.d
src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: ../src/r_usb_pcdc_descriptor.c src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\r_usb_basic_if.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\r_usb_basic_if.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\platform.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\platform.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\./board/gr_citrus_rx631/r_bsp.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\./board/gr_citrus_rx631/r_bsp.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/all/r_bsp_common.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/all/r_bsp_common.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_config\r_bsp_config.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_config\r_bsp_config.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/register_access/iodefine.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/register_access/iodefine.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/mcu_info.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/mcu_info.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/mcu_locks.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/mcu_locks.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/locking.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/locking.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/cpu.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/cpu.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/mcu_init.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/mcu_init.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/mcu_interrupts.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\mcu/rx631/mcu_interrupts.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\board/gr_citrus_rx631/gr_citrus_rx631.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\board/gr_citrus_rx631/gr_citrus_rx631.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\board/gr_citrus_rx631/hwsetup.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\board/gr_citrus_rx631/hwsetup.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\board/gr_citrus_rx631/lowsrc.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\board/gr_citrus_rx631/lowsrc.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\board/gr_citrus_rx631/vecttbl.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_bsp\board/gr_citrus_rx631/vecttbl.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\src\driver\inc\r_usb_basic_define.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_usb_basic\src\driver\inc\r_usb_basic_define.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: C:\Renesas\cspproj\RX631_RSPI_FIT\r_config\r_usb_basic_config.h C:\Renesas\cspproj\RX631_RSPI_FIT\r_config\r_usb_basic_config.h: src/r_usb_pcdc_descriptor.obj src/r_usb_pcdc_descriptor.d: ../src/r_usb_pcdc_apl_config.h ../src/r_usb_pcdc_apl_config.h:
ほやさん、こんにちは。NoMaYです。先ほど確認してみたところ以下の2つのことが分かりました。(当方特有の事情でCC-RX V2.04.00以降は試していないです。)(1) CC-RX V2.00.00では-MM、-MP、-MTの依存関係情報ファイルに関するオプションはエラーになる(2) CC-RX(少なくともV2.03.00)では-output=depとすることで複数の依存関係情報ファイルを一括で生成出来るそれで、(1)から思ったのですが、もう既にCC-RXではe2 studioの為に-output=dep=fileオプションを指定した時の動作をe2 studio/CDT/GNUMAKEに都合の良いように微妙に変えることが出来るようなオプション追加が行われている、ということのような気がします。また、(2)から思ったのですが、もしCS+開発者さんから要望があって-output=obj -output=depの同時指定が出来るようにCC-RX開発者さんが改造作業を行う場合の工数は充分現実的な工数の範囲内にあるのではないだろうか、という気がしました。(あと、オブジェクトファイルと依存関係ファイルの同時出力が原理的に可能なものであることは、ほやさんも書かれている通り、GCCで実証済みですね。)[余談]以前から思っているのですが，CS+に[インクルード・ファイルが存在しないソースの扱い]などというオプションがあるのは、そこがCS+(旧CubeSuite+)開発者さんの妥協点(悪く言えば手抜きをした点)であり、コンパイラと同等の条件コンパイル判定処理(それはコンパイラと同等のデファイン処理や条件式構文解析処理を含む)をCS+(旧CubeSuite+)に実装するのは勘弁して欲しい、ということによるのだろうという気がしています。でも、たぶん、勘弁して欲しい、というのはGNUMAKEの開発者さんも同じで、そもそもGCCはコンパイル時に完全な条件コンパイル判定処理を行ってインクルード処理を行っているのだから、そこで依存関係情報を出力することまでして貰って、それをGNUMAKEが読み込むようにするのが一番合理的なのではないか、というような開発者さん同士の話し合いがあったのではないでしょうか。その結果、あのようなGCC＋GNUMAKEの依存関係検出メカニズム(.dファイルを介してGCCがGNUMAKEに依存関係情報をフィードバックするメカニズム)が出来たのではないかと思っています。(AppleやGoogleのような(?)言い回しをすれば、より良いユーザエクスペリエンスを提供することを目指した結果あのようなメカニズムが出来たのではないか、というようなところでしょうか、、、)あと、e2 studioということで言えば、CC-RX用ビルドプラグインはCDTのGCC用ビルドプラグインのソースコードを基にしてRenesasが改変を加えて作ったものです。(それ故に、scanとcompileで2回CC-RXを起動するようなことが出来ている、のだと思っています。) 思うに、e2 studio開発者にその気があれば一括ビルド用makefileをCC-RX用ビルドプラグインで生成させるよう機能拡張することも可能である、ような気がします。(昔のe2 studio(あるいは、その前身のKPIT Eclipse)は自前で依存関係を検出してCC-RXでビルドするmakefileを生成していた筈ですが、そのコードを復活させる必要はありそうですし、更に、今のCC-RXの条件コンパイル判定処理に適合するように改造する必要もあるかも知れませんが。) ただ、もしかすると、そのmakefileは、単独で何時でも使えるmakefileというものでは無くて、その場限りで使い捨てするバッチファイル/シェルスクリプトに過ぎないようなmakefileになるかも知れません。(GNUMAKEの機能でビルドすべきソースファイル名をどんどん変数に連結して行くようなことが出来るか分からなくて何とも言えませんが、それが出来るなら単独で何時でも使えるmakefileを生成するということも出来るとは思います、、、)ただ、その場合、課題になりそうなのが、CC-RXでは一括ビルドの場合、オブジェクトファイルは全て1つのフォルダに生成されるので、e2 studioのソースフォルダ階層に倣ったオブジェクトフォルダ階層にオブジェクトファイルを生成させていくことが出来ない、つまり、異なるソースフォルダに同名であるが内容の異なるソースを置くということが出来なくなる、という非互換性が生じることかと思います。と書いたところで気付いたのですが、満額の一括ビルドでなくてもソースフォルダ毎の一括ビルドという次善の策なら出来ないことは無いかも知れない、と思ったりとか思わなかったりとか、、、最後に、以前、ARM DS-5 （RZ Edition)をインストールしてみて驚いたのですが、デバッグ関係のウィンドウが軒並み見慣れたCDTのウィンドウから改変されていて、面食らった記憶があります。その時に思ったのは、実務で使うにはCDTのウィンドウでは全然力不足で、ここまでしないと駄目だということなのだろうか、ということでした。と同時に、ここまで変えてしまうのもアリなのだな、ということも思いました。それが出来るのも、Eclipse/CDTがオープンソースだから、ということではありますが。
ほやさん、こんにちは。NoMaYです。scandepコマンドが使われる前の時代があったのですよ。調べてみたのですが、scandepコマンドが使われ出したのはe2studio v1.1.0以降のようです。e2studio v1.0.1では使われていませんでした。(Utilities/scandep1.exeは、v1.0.1.14には無く、v1.1.0.30には在りました。私はトラブルに好かれるようだったので、この頃は今の自分も驚くほど几帳面にバックアップを取ってました。)