Build C++ à distance via VPN : gardez la chaîne d’outils sur l’hôte

Le partage est monté, l’éditeur ouvre le fichier, et la compilation s’exécute toujours sur le portable. Rien ne signale d’erreur, et c’est précisément ce qui rend la situation déroutante. Un chemin distant n’est pas une chaîne d’outils distante, et un éditeur capable de lire un fichier via un montage invoquera volontiers le compilateur local dessus. La solution est de déplacer l’espace de travail, pas seulement les octets.

Un répertoire monté n’est pas un espace de travail

Monter via SSH ou SMB vous donne un chemin. Que le compilateur, le système de build et le débogueur viennent du côté distant dépend de l’endroit où l’éditeur décide de les exécuter. Beaucoup de configurations lisent des fichiers distants et les compilent en local, puis échouent sur un en-tête qui n’existe que sur le serveur.

Le symptôme est subtil : la compilation réussit avec des résultats partiels, ou casse sur un chemin d’inclusion qui semble correct dans l’éditeur.

Prouvez quel hôte répond

Connectez-vous avec une vraie session distante plutôt qu’un montage, puis exécutez trois commandes en lecture seule dans le terminal que cette session vous donne. Le guide SSH de VS Code documente qu’un terminal dans une fenêtre distante connectée s’exécute sur l’hôte distant et que la même session transporte le débogage. Demandez d’abord l’autorisation pour les composants distants si l’organisation les restreint.

hostname nomme la machine sur laquelle vous êtes, pwd montre où vit réellement l’espace de travail, et command -v c++ affiche le compilateur que le shell exécuterait. Les trois réponses devraient décrire le serveur, pas le portable.

Elles ne prouvent pas que la version ou la configuration de build soit correcte. Comparez cela aux instructions du projet lui-même, comme étape distincte.

Suivez une modification à travers la compilation et le débogage

Faites une petite modification dans l’espace de travail distant et enregistrez-la là-bas. Exécutez la compilation documentée depuis ce même répertoire et confirmez que la sortie reflète votre modification et non une copie plus ancienne ailleurs. Lancez ensuite le débogueur via la même session distante, avec le chemin du binaire et le répertoire de travail pointant vers l’arborescence de build du serveur. La correspondance des chemins sources compte, car un débogueur qui résout votre modification vers un chemin du portable débogue un autre fichier.

Si la cible de débogage signale des chemins qui commencent par votre répertoire personnel local, la configuration de lancement pense encore en local.

Les dépendances réseau restent sur l’hôte

Une récupération de paquets, une opération git ou une exécution de tests lancée sur l’hôte de build utilise le réseau et les identifiants de cet hôte, pas la session VPN de votre portable. Que le portable atteigne un miroir de paquets privé ne dit rien de la capacité du serveur à le faire. Si la compilation a besoin d’un registre, le serveur a besoin d’une route vers celui-ci, et c’est une conversation de pare-feu, pas un réglage d’éditeur.

L’inverse vaut aussi pour les applications de test. Atteindre un service sur le serveur depuis votre navigateur est une connexion distincte qui exige un chemin privé approuvé ou une redirection restreinte, pas une écoute ouverte.

Déconnectez sans perdre le travail

Enregistrez et commitez, ou au moins consignez l’arbre de travail, avant que la connexion tombe. Une session d’édition distante ne promet pas qu’une compilation en cours ou un tampon non enregistré survive à une coupure réseau. Pour tout ce qui doit survivre à votre session, utilisez le flux de travail ou de session pris en charge par le projet.

La répartition du travail est alors explicite : le portable est une interface, le serveur possède l’espace de travail et la chaîne d’outils, et le VPN fournit la route. Déplacer des fichiers et déplacer la compilation sont deux décisions distinctes.