Compilare C++ la distanță prin VPN: păstrați lanțul de instrumente pe gazdă

Partajarea este montată, editorul deschide fișierul, iar compilarea rulează în continuare pe laptop. Nimic nu semnalează o eroare, și exact asta încurcă. O cale la distanță nu este un lanț de instrumente la distanță, iar un editor care poate citi un fișier printr-o montare va invoca fără ezitare compilatorul local asupra lui. Soluția este să mutați spațiul de lucru, nu doar octeții.

Un director montat nu este un spațiu de lucru

Montarea prin SSH sau SMB vă oferă o cale. Dacă compilatorul, sistemul de compilare și depanatorul vin din partea îndepărtată depinde de locul unde editorul decide să le ruleze. Multe configurații citesc fișiere la distanță și le compilează local, apoi eșuează pe un fișier antet care există doar pe server.

Simptomul este subtil: compilarea reușește cu rezultate parțiale sau se rupe pe o cale de includere care pare corectă în editor.

Demonstrați ce gazdă răspunde

Conectați-vă cu o sesiune reală la distanță în loc de o montare, apoi rulați trei comenzi numai pentru citire în terminalul pe care acea sesiune vi-l oferă. Ghidul SSH din VS Code documentează că un terminal dintr-o fereastră îndepărtată conectată rulează pe gazda îndepărtată și că aceeași sesiune transportă depanarea. Cereți mai întâi aprobarea pentru componentele la distanță dacă organizația le restricționează.

hostname numește mașina pe care sunteți, pwd arată unde se află de fapt spațiul de lucru, iar command -v c++ afișează compilatorul pe care l-ar rula shell-ul. Toate trei răspunsurile ar trebui să descrie serverul, nu laptopul.

Ele nu dovedesc că versiunea sau configurația de compilare este corectă. Comparați asta cu instrucțiunile proiectului însuși ca pas separat.

Urmați o modificare prin compilare și depanare

Faceți o modificare mică în spațiul de lucru de la distanță și salvați-o acolo. Rulați compilarea documentată din același director și confirmați că ieșirea reflectă modificarea dumneavoastră, nu o copie mai veche în altă parte. Apoi lansați depanatorul prin aceeași sesiune la distanță, cu calea binarului și directorul de lucru îndreptate spre arborele de compilare al serverului. Potrivirea căilor sursă contează, pentru că un depanator care vă rezolvă modificarea la o cale de pe laptop depanează alt fișier.

Dacă ținta de depanare raportează căi care încep cu directorul dumneavoastră principal local, configurația de lansare încă gândește local.

Dependențele de rețea rămân pe gazdă

O descărcare de pachete, o operație git sau o rulare de teste pornită pe gazda de compilare folosește rețeaua și acreditările acelei gazde, nu sesiunea VPN a laptopului. Faptul că laptopul ajunge la o oglindă privată de pachete nu spune nimic despre dacă serverul poate. Dacă compilarea are nevoie de un registru, serverul are nevoie de o rută către el, iar asta este o discuție despre firewall, nu o setare a editorului.

Invers, același lucru este valabil pentru aplicațiile de test. A ajunge de la browser la un serviciu de pe server este o conexiune separată care necesită o cale privată aprobată sau o redirecționare restricționată, nu un ascultător deschis.

Deconectați-vă fără a pierde munca

Salvați și faceți commit, sau cel puțin înregistrați arborele de lucru, înainte ca conexiunea să cadă. O sesiune de editare la distanță nu promite că o compilare în curs sau un buffer nesalvat va supraviețui unei întreruperi de rețea. Pentru tot ce trebuie să trăiască mai mult decât sesiunea dumneavoastră, folosiți fluxul de lucru sau de sesiune acceptat de proiect.

Împărțirea muncii este atunci explicită: laptopul este o interfață, serverul deține spațiul de lucru și lanțul de instrumente, iar VPN-ul furnizează ruta. Mutarea fișierelor și mutarea compilării sunt două decizii separate.