コンパイラを置き換えない仕組みについて

[yossi-tahara]

コンパイラを置き換えない仕組みについて

[yossi-tahara]

Visual Studio 2017がCMakeをサポートしたらしいので、後日トライしてみます。
この環境でIDEをそれなりに使えるようなら、コンパイラを置き換えない仕組みに対応できる可能性があると思います。

Visual Studio 2017をインストールしてみました

ファイル(F)から開く(O)のフォルダー(D)を選択して、CMakeLists.txtのあるフォルダを指定すると、

CMake -G "Visual Studio 15 2017 Win64" -DCMAKE_INSTALL_PREFIX:PATH="中略\install" --DCMAKE_BUILD_TYPE="Release" "ソース・フォルダ"

が実行されました。
これにより、ユーザ・フォルダのAppData\Local\CMakeBuildの更に下の方に通常のCMakeのビルド・フォルダが作られ、その中に*.sln（ソリューション・ファイル）ができてます。
それをダブルクリックすると、通常通りVisual Studio 2017が起動し、マルチ・コンフィグ型の通常通りのソリューションが開きました。

残念ながら、通常のmakefile型のプロジェクトになるわけでなく、単純にCMakeジェネレータを自動的に呼び出すようになったような感じでした。

コンパイラを置き換えない仕組みをVisual Studioで実現するにはやはりMS-Buildに組み込む必要があるようです。

なお、CMakeはVisual Studio 2017 RCをサポートしている3.7.2をインストールして実験しました。

[yossi-tahara]

この件に着手します。
まずはMS-Buildの仕組みを調査します。
課題を明確化できたら「クラウド・ワークス」にて依頼することも視野に入れて進めます。

もし、他に優先して進めた方が良いものがありましたら、ここ、もしくは、ユーザ登録不要なサポート掲示板にてご意見頂けると幸いです。

[yossi-tahara]

MinGWとgcc用については、予想外に簡単に対応できました。
THEOLIZERConfig.cmakeでCMAKE_CXX_COMPILERを置き換え、元のコンパイラをTheolizerDriverへ教えるための--theolizer-compilerオプションを指定することで成功しました。

Visual Studioは予想通り苦労していますが、光が見えてきました。
llvmはtoolsetを定義し、その中でExecutablePath先頭にllvmのcl.exeのあるフォルダを指定することで、llvmのcl.exeを呼ばせています。
同様な方法を検討していたのですが、CMake 3.8.0で追加されたVS_USER_PROPSを使うことでllvm同様ExecutablePathにtheolizerドライバをcl.exeへリネームしたものを保存したフォルダを追加することができました。
こちらの方法なら、Theolizerを用いるプロジェクトのみへの影響だけ済みますので安心して使えると思います。

細かい部分の問題修正、従来のreplace/restore機能の削除、各種テストの見直し、および、ドキュメントの修正を行います。

[yossi-tahara]

CMake 3.8.0でVS_USER_PROPSが追加されありがたいのですが、CMake 3.8.0からCTestが文字化けさせる機能を実装してます。テスト対象プログラムの出力を強制的にUTF-8として解釈し、画面出力する際にShift-JISへ変換しています。
Windows: Use UTF-8 for pipes in CMake, CTest and CPackが3.8.0以降で採用されたことが原因と思います。
「ユーザ・プログラムは必ずUTF-8で出力しろ、コマンド・プロンプト向けへの変換は任せとけ」は、テストツールの仕様としては好ましくないと考えています。
検討できないか、リクエストしてみました。

リクエストを受け付けて貰えるかどうか分からないので、別途対策を検討します。
Visual Studioの出力を英語に切り替える方向で考えています。

[yossi-tahara]

この件、実装完了しました。
マニュアルの修正等まだ少し作業が残っていますので、それらが完了したらv1.1.1としてリリースします。（本体機能のバージョンアップではないので最下位の桁のみ更新）

仕組み

次の３つがポイントです。

1. ビルド・システムにTheolizerドライバをコンパイラとして起動させる
2. Theolizerドライバにソース自動生成が必要であることを伝達する
3. Theolizerドライバに元コンパイラのパスを伝達し、元のコンパイラへ処理を引き継げるようにする

1. Theolizerドライバをコンパイラとして起動させる

1-1. Visual Studioの場合

ビルドのために必要なオプションを全てTheolizerドライバへ伝達するために、従来は、元コンパイラ自身をリネームし、そこにTheolizerドライバをコピーすることで、ビルド・システムがTheolizerドライバをコンパイラとして起動するようにしていました。

Theolizerのインストール先フォルダにmsbuild-binフォルダを追加し、そこへTheolizerドライバをcl.exeのファイル名で保存します。
そして、コンパイル時のPATH先頭に上記フォルダを追加することで、Visual StudioがTheolizerドライバをコンパイラとして起動するようにしました。
これはclangで使われている仕組みと同じです。

1-1-1. コンパイル時のPATH先頭にmsbuild-binフォルダを追加する

CMake 3.8.0にて、VS_USER_PROPSと言う、ビルド・ターゲットに付加するプロパティが追加されました。
これを使ってターゲットのプロジェクト・ファイル（*.vcxproj）に<Import Project>キーを追加し、theolizer.propsをインクルードしました。
theolizer.propsにて、コンパイル時に使われるPATHとなる<ExecutablePath>の先頭にmsbuild-binフォルダを追加しました。

1-2. その他（gcc/mingw)の場合

対象のプロジェクトのCMAKE_CXX_COMPILERにTheolizerドライバのフルパスを設定しました。
これは普通にmakefileのCCに反映されますので、呼び出すコンパイラを変更できます。
（Visual Studioはmakeではなく、マイクロソフト独自のMSBuildでビルドするためこの方法が機能しませんでした。）

2. Theolizerドライバにソース自動生成が必要であることを伝達する

CMakeでTHEOLIZER_DO_PROCESSマクロをコンパイラ・オプションで定義するようにしまた。
このマクロがオプションで指定された時、Theolizerドライバはソース自動生成処理を行います。
そうでない時は、単純に元コンパイラへパススルーします。

3. Theolizerドライバに元コンパイラのパスを伝達する

コンパイラ・オプションで伝達しました。
マクロ定義（/Dや-D）で伝達するべきか、CMakeが知らないオプション（--theolizerXXXX）で伝達するのか悩ましかったです。

3-1. MSVCの場合

CMakeは*.rspファイルに全てのオプションを記述してコンパイラへ渡します。
その為、--theolizerXXXXを使った場合、Theolizerドライバでそのオプションを削除して元コンパイラへ引き継ぐことが難しいです。
ですので、マクロ定義（/Dtheolizer_original_compiler=<元コンパイラのパス>）で伝達するようにしました。

3-2. その他（gcc/mingw)の場合

CMakeはgcc/mingw用にはコンパイルとリンクを分解してg++を呼び出します。
リンクの時ldを直接呼ぶわけでなく、g++にリンク指定して呼び出します。
どちらの場合もTheolizerドライバが起動されまことになります。
そして、リンク動作時は-Dオプションは渡ってきませんでした。マクロ定義はコンパイラのみ必要なオプションですので適切な処理と思います。
しかし、その結果、リンク時に起動されたTheolizerドライバが元コンパイラのパスを得ることができず、元コンパイラをパススルー起動できません。

そこで、msvc以外の時は、--theolizer_original_compiler=<元コンパイラのパス>オプションで元コンパイラのパスを伝達するようにしました。

4. 実現

上記はfind_packageで用いるTHEOLIZERConfig.cmake内部で対応しています。
ですので、ユーザ・プログラム用のCMakeLists.txtは従来のままで使用できます。
コンパイラのリプレース操作が不要になるだけです。
ただし、Visual Studioをお使いの場合は、CMakeを3.8.0以上へアップデートする必要があります。

（なお、Theolizerドライバど各種テスト・スクリプトも修正していますが使うだけなら影響ありません。）

5. CMake 3.8.0について

CMake 3.8.0以降について、CMakeに含まれるCTestの文字コードについて仕様変更されています。
この対応も行いました。詳しくはIssue #37へ記載しています。

[yossi-tahara]

特に問題なさそうなのでクローズします。