C++ op afstand bouwen via VPN: houd de toolchain op de host

De share wordt gemount, de editor opent het bestand en de build draait nog steeds op de laptop. Niets geeft een fout, en dat maakt het juist verwarrend. Een pad op afstand is geen toolchain op afstand, en een editor die een bestand via een mount kan lezen, roept daar met plezier de lokale compiler op aan. De oplossing is de werkruimte verplaatsen, niet alleen de bytes.

Een gemounte map is geen werkruimte

Mounten via SSH of SMB geeft je een pad. Of de compiler, het buildsysteem en de debugger van de externe kant komen, hangt af van waar de editor ze laat draaien. Veel opstellingen lezen externe bestanden en compileren die lokaal, en stranden dan op een header die alleen op de server bestaat.

Het symptoom is subtiel: de build slaagt met gedeeltelijke resultaten, of breekt op een includepad dat er in de editor correct uitziet.

Bewijs welke host antwoordt

Verbind met een echte externe sessie in plaats van een mount en voer daarna drie alleen-lezen commando's uit in de terminal die die sessie je geeft. De SSH-gids van VS Code documenteert dat een terminal in een verbonden extern venster op de externe host draait en dat dezelfde sessie het debuggen draagt. Vraag eerst goedkeuring voor de externe componenten als de organisatie ze beperkt.

hostname noemt de machine waarop je zit, pwd laat zien waar de werkruimte echt staat, en command -v c++ drukt de compiler af die de shell zou uitvoeren. Alle drie de antwoorden zouden de server moeten beschrijven, niet de laptop.

Ze bewijzen niet dat de versie of de buildconfiguratie klopt. Vergelijk dat als aparte stap met de instructies van het project zelf.

Volg één wijziging door build en debug

Maak een kleine wijziging in de externe werkruimte en sla die daar op. Voer de gedocumenteerde build uit vanuit dezelfde map en bevestig dat de uitvoer je wijziging weerspiegelt en niet een oudere kopie ergens anders. Start daarna de debugger via dezelfde externe sessie, met het pad naar de binary en de werkmap die in de buildboom van de server wijzen. Overeenkomende bronpaden maken uit, want een debugger die je wijziging aan een laptop-pad koppelt, debugt een ander bestand.

Als het debugdoel paden meldt die met je lokale thuismap beginnen, denkt de startconfiguratie nog steeds lokaal.

Netwerkafhankelijkheden blijven op de host

Een pakketophaling, een git-bewerking of een testrun die op de buildhost start, gebruikt het netwerk en de inloggegevens van die host, niet de VPN-sessie van je laptop. Dat de laptop een private pakketspiegel bereikt, zegt niets over of de server dat kan. Als de build een registry nodig heeft, heeft de server een route ernaartoe nodig, en dat is een firewallgesprek, geen editorinstelling.

Omgekeerd geldt hetzelfde voor testapplicaties. Een dienst op de server bereiken vanuit je browser is een aparte verbinding die een goedgekeurd privépad of een beperkte doorsturing nodig heeft, geen open listener.

Verbreek de verbinding zonder het werk te verliezen

Sla op en commit, of leg op zijn minst de werkboom vast, voordat de verbinding wegvalt. Een externe bewerksessie belooft niet dat een lopende build of een niet-opgeslagen buffer een netwerkonderbreking overleeft. Voor alles wat je sessie moet overleven, gebruik de door het project ondersteunde taak- of sessieworkflow.

De werkverdeling is dan expliciet: de laptop is een interface, de server bezit de werkruimte en de toolchain, en de VPN levert de route. Bestanden verplaatsen en de build verplaatsen zijn twee aparte beslissingen.