VPN 経由のリモート C++ ビルド：ツールチェーンはホストに残す

共有はマウントされ、エディタはファイルを開き、ビルドは依然としてノート PC 上で動いています。エラーは何も出ません。だからこそ紛らわしいのです。リモートのパス名はリモートのツールチェーンではない、マウント越しにファイルを読めるエディタは、そのファイルに対してローカルのコンパイラを喜んで呼び出します。解決策は、バイトではなくワークスペースを移すことです。

マウントしたディレクトリはワークスペースではない

SSH や SMB でのマウントはパス名を与えるだけです。コンパイラ、ビルドシステム、デバッガがリモート側から来るかどうかは、エディタがそれらをどこで実行するかで決まります。多くの設定はリモートのファイルを読んでローカルでコンパイルし、サーバにしかないヘッダーファイルで失敗します。

症状は微妙です。ビルドが部分的な結果で成功するか、エディタでは正しく見えるインクルードパスで壊れます。

どのホストが応答するかを証明する

マウントではなく実際のリモートセッションで接続し、そのセッションが与えるターミナルで読み取り専用のコマンドを三つ実行します。VS Code のSSH ガイドは、接続されたリモートウィンドウのターミナルがリモートホスト上で動き、同じセッションがデバッグも運ぶことを記しています。組織がリモートコンポーネントを制限している場合は、先に承認を得てください。

hostname は自分がどのマシンにいるかを示し、pwd はワークスペースが実際どこにあるかを示し、command -v c++ はシェルが実行するコンパイラを出力します。三つの答えはすべてノート PC ではなくサーバを説明するはずです。

それらはバージョンやビルド設定が正しいことを証明しません。それは別の手順として、プロジェクト自身の指示と照らし合わせてください。

一つの編集をビルドとデバッグまで追う

リモートのワークスペースで小さな変更を加え、そこに保存します。同じディレクトリから文書化されたビルドを実行し、出力が自分の編集を反映していること、どこか別の場所の古いチェックアウトではないことを確認します。次に同じリモートセッションでデバッガを起動し、バイナリのパスと作業ディレクトリをサーバのビルドツリーに向けます。ソースパスの一致が重要なのは、自分の編集をノート PC のパスに解決するデバッガは別のファイルをデバッグしているからです。

デバッグ対象がローカルのホームディレクトリで始まるパスを報告するなら、起動構成はまだローカルで考えています。

ネットワーク依存はホスト側に残る

ビルドホストで開始されたパッケージ取得、git 操作、テスト実行は、自分のノート PC の VPN セッションではなく、そのホストのネットワークと資格情報を使います。ノート PC がプライベートなパッケージミラーに届いても、サーバが届くかどうかは何も語りません。ビルドにレジストリが必要なら、サーバにそこへの経路が必要であり、それはエディタの設定ではなくファイアウォールの話です。

逆もまたテストアプリに当てはまります。ブラウザからサーバ上のサービスに届くことは別の接続であり、承認されたプライベート経路か制限付き転送が必要で、開いたリスナーではありません。

作業を失わずに切断する

接続が切れる前に保存してコミットするか、少なくとも作業ツリーを記録してください。リモート編集セッションは、実行中のビルドや未保存のバッファがネットワーク中断を生き延びることを約束しません。セッションより長く残す必要があるものには、プロジェクトがサポートするジョブまたはセッションのワークフローを使ってください。

分業はこうして明確です。ノート PC はインターフェース、サーバがワークスペースとツールチェーンを所有し、VPN が経路を提供します。ファイルを移すこととビルドを移すことは二つの別の決定です。