Fjernbygging av C++ over VPN: behold verktøykjeden på verten
Å montere delingen er ikke det samme som å bygge eksternt. Sjekk hvilken vert som svarer, hvilken kompilator som kjører, og hvor debuggeren og nettverket ligger.
Delingen monteres, editoren åpner filen, og bygget kjører fortsatt på den bærbare. Ingenting feiler, og nettopp det gjør det forvirrende. En ekstern sti er ikke en ekstern verktøykjede, og en editor som kan lese en fil gjennom en montering, kaller gjerne den lokale kompilatoren på den. Løsningen er å flytte arbeidsområdet, ikke bare bytene.
En montert mappe er ikke et arbeidsområde
Montering over SSH eller SMB gir deg en sti. Om kompilatoren, byggesystemet og debuggeren kommer fra fjernsiden, avhenger av hvor editoren velger å kjøre dem. Mange oppsett leser eksterne filer og kompilerer dem lokalt, og feiler så på en header som bare finnes på serveren.
Symptomet er subtilt: bygget lykkes med delvise resultater, eller bryter på en include-sti som ser riktig ut i editoren.
Bevis hvilken vert som svarer
Koble til med en ekte ekstern økt i stedet for en montering, og kjør deretter tre skrivebeskyttede kommandoer i terminalen økten gir deg. VS Codes SSH-veiledning dokumenterer at en terminal i et tilkoblet eksternt vindu kjører på den eksterne verten, og at samme økt bærer feilsøkingen. Be om godkjenning for fjernkomponentene først hvis organisasjonen begrenser dem.
hostname navngir maskinen du er på, pwd viser hvor arbeidsområdet faktisk ligger, og command -v c++ skriver ut kompilatoren skallet ville kjørt. Alle tre svarene bør beskrive serveren, ikke den bærbare.
De beviser ikke at versjonen eller byggekonfigurasjonen er riktig. Sammenlign det med prosjektets egne instruksjoner som et eget steg.
Følg én endring gjennom bygg og feilsøking
Gjør en liten endring i det eksterne arbeidsområdet og lagre den der. Kjør det dokumenterte bygget fra samme mappe og bekreft at utdataene gjenspeiler endringen din og ikke en eldre kopi et annet sted. Start deretter debuggeren gjennom samme eksterne økt, med binærstien og arbeidsmappen pekende inn i serverens byggetre. Sammenfallende kildebaner betyr noe, fordi en debugger som løser endringen din til en sti på den bærbare, feilsøker en annen fil.
Hvis feilsøkingsmålet rapporterer stier som begynner med din lokale hjemmemappe, tenker startkonfigurasjonen fortsatt lokalt.
Nettverksavhengigheter blir værende på verten
En pakkehenting, en git-operasjon eller en testkjøring startet på byggverten bruker den vertens nettverk og påloggingsinformasjon, ikke den bærbares VPN-økt. At den bærbare når et privat pakkespeil, sier ingenting om hvorvidt serveren kan. Hvis bygget trenger et register, trenger serveren en rute dit, og det er en brannmursamtale, ikke en editorinnstilling.
Det samme gjelder omvendt for testapplikasjoner. Å nå en tjeneste på serveren fra nettleseren er en egen forbindelse som krever en godkjent privat sti eller en begrenset videresending, ikke en åpen lytter.
Koble fra uten å miste arbeidet
Lagre og commit, eller registrer i det minste arbeidstreet, før forbindelsen faller. En ekstern redigeringsøkt lover ikke at et kjørende bygg eller en ulagret buffer overlever et nettverksbrudd. For alt som må leve lenger enn økten din, bruk prosjektets støttede jobb- eller øktflyt.
Arbeidsdelingen er da tydelig: den bærbare er et grensesnitt, serveren eier arbeidsområdet og verktøykjeden, og VPN-en leverer ruten. Å flytte filer og å flytte bygget er to separate beslutninger.