Linux、私はRaspberry Piを使っているが、そのC++でのクロス開発をVisual Studioをフロントエンドで行うことができたので、それに関しての覚書。
VS Codeをフロントエンドとしたクロス開発ができる拡張があるようだったのだが、Raspberry Pi Zeroは対応していなかったり、やはりVS CodeのインテリセンスよりVisual Studioのインテリセンスの方が賢いので、Visual Studioをフロントエンドにできたのはよかった。
インストール
基本的にはここを見れば大体いける。
リモート接続をするための設定の画面が英語版だったので、日本語版では以下のような感じになる。
場所的には下の方。
プロジェクト作成の前にやること
Visual Studio側のインテリセンスを賢くさせるため、Linux側で使用可能なヘッダーファイルを取り込む必要がある。
これは、設定-クロスプラットフォーム-接続マネージャー-リモートヘッダーIntelliSenseマネージャーから読み込みを行う必要がある。
上記設定画面で、リモートマシンを接続マネージャーで登録しておき、更新ボタンで、登録されているリモートマシン側のヘッダーをWindows側に取り込むことになる。
取り込んだファイル群は、AppData\Local\Microsoft\Linux\HeaderCacheの下に保存されるようだ。
プロジェクトの作成
クロス開発で選択できるプロジェクトは、以下のような感じになる。
上記プロジェクトのひな形では、静的・動的ライブラリは作成できず、共有プロジェクトで作るしかない。
CMakeプロジェクトであればできそうな感じはするが、まだそこまでは調べていない。
また、共有プロジェクトを利用するプロジェクトでは、リモートデバッグができなくなる問題があったので、注意が必要。
これについては一応対応策がある。
共有プロジェクトを使うプロジェクトのデバッグ
デバッグは、リモートマシン側でgdbを起動し実施するが、操作はVisual Studio側で行う。
そのためGUI上で操作を行うことができるので、便利。
ただ、共有プロジェクトを参照しているプロジェクトの場合、実行モジュールの配置が、想定している場所から変わるため、ちょっと工夫が必要。
共有プロジェクトを参照していない場合、Linux上の配置は次のようになる。
- Visual Studioのプロジェクト構成
- Linux上の配置
~/projectsがリモートマシン側のベースとなるディレクトリーとなり、その下にプロジェクト名、そしてその下のbinに実行モジュールが配置される。
共有プロジェクトを参照している場合は、次のようになる。
- Visual Studioのプロジェクト構成
Gphoto2というのが参照している共有プロジェクトになる。 - Linux上の配置
共有プロジェクトがない場合、この直下にbinがあったのだが、さらにCameraControlというプロジェクト名のディレクトリーが作成され、その下に保存されるようになった。
なお、デバッガが要求する実行モジュールの位置は、共有プロジェクトがない場合の位置になる。
そのため、共有プロジェクトを参照している場合、以下の様にデバッガが起動できないという結果になる。
現状の回避方法としては、プロジェクトの設定を以下の様にすることで対応可能。
ビルドイベント-リモートのビルド後イベントのコマンドラインに以下を入れる。
test -d $(RemoteRootDir)/$(ProjectName)/bin || ln -s -r $(RemoteRootDir)/$(ProjectName)/$(ProjectName)/bin $(RemoteRootDir)/$(ProjectName)/この解決方法は、以下に記載があった。
コメント