Compilació remota de C++ per VPN: mantingueu la cadena d’eines al servidor

El recurs compartit es munta, l’editor obre el fitxer i la compilació continua executant-se al portàtil. No surt cap error, i això és precisament el que desconcerta. Un camí remot no és una cadena d’eines remota, i un editor que pot llegir un fitxer a través d’un muntatge invocarà sense problemes el compilador local sobre el fitxer. La solució és moure l’espai de treball, no només els bytes.

Un directori muntat no és un espai de treball

Muntar per SSH o SMB us dona un camí. Que el compilador, el sistema de compilació i el depurador vinguin del costat remot depèn d’on decideixi executar-los l’editor. Moltes configuracions llegeixen fitxers remots i els compilen localment, i després fallen en un fitxer de capçalera que només existeix al servidor.

El símptoma és subtil: la compilació té èxit amb resultats parcials, o es trenca en un camí d’inclusió que a l’editor sembla correcte.

Demostreu quin amfitrió respon

Connecteu-vos amb una sessió remota real en lloc d’un muntatge i després executeu tres ordres només de lectura al terminal que us dona aquesta sessió. La guia SSH del VS Code documenta que un terminal en una finestra remota connectada s’executa a l’amfitrió remot i que la mateixa sessió porta la depuració. Obteniu abans l’aprovació dels components remots si l’organització els restringeix.

hostname anomena la màquina on sou, pwd mostra on viu realment l’espai de treball i command -v c++ imprimeix el compilador que executaria l’intèrpret d’ordres. Les tres respostes haurien de descriure el servidor, no el portàtil.

No demostren que la versió o la configuració de compilació siguin correctes. Compareu-ho amb les instruccions del propi projecte com a pas separat.

Seguiu un canvi a través de la compilació i la depuració

Feu un canvi petit a l’espai de treball remot i deseu-lo allà. Executeu la compilació documentada des d’aquest mateix directori i confirmeu que la sortida reflecteix el vostre canvi i no una còpia més antiga en un altre lloc. Després inicieu el depurador per la mateixa sessió remota, amb el camí del binari i el directori de treball apuntant a l’arbre de compilació del servidor. Que els camins d’origen coincideixin importa, perquè un depurador que resol el vostre canvi a un camí del portàtil està depurant un fitxer diferent.

Si l’objectiu de depuració informa de camins que comencen pel vostre directori personal local, la configuració d’inici encara pensa en local.

Les dependències de xarxa es queden a l’amfitrió

Una descàrrega de paquets, una operació de git o una execució de tests iniciada a l’amfitrió de compilació fa servir la xarxa i les credencials d’aquest amfitrió, no la sessió VPN del portàtil. Que el portàtil arribi a un mirall privat de paquets no diu res sobre si el servidor hi pot arribar. Si la compilació necessita un registre, el servidor necessita una ruta cap a ell, i això és una conversa de tallafocs, no un paràmetre de l’editor.

El mateix passa a l’inrevés amb les aplicacions de prova. Arribar a un servei del servidor des del navegador és una connexió separada que necessita un camí privat aprovat o un reenviament restringit, no un port d’escolta obert.

Desconnecteu sense perdre la feina

Deseu i feu commit, o com a mínim anoteu l’arbre de treball, abans que caigui la connexió. Una sessió d’edició remota no promet que una compilació en curs o un buffer no desat sobrevisqui una interrupció de xarxa. Per a tot allò que hagi de durar més que la sessió, feu servir el flux de treball o de sessions admès pel projecte.

La divisió de feina és llavors explícita: el portàtil és una interfície, el servidor posseeix l’espai de treball i la cadena d’eines, i la VPN forneix la ruta. Moure fitxers i moure la compilació són dues decisions separades.