Malayong pag-build ng C++ sa VPN: itago ang toolchain sa host

Naka-mount ang share, binubuksan ng editor ang file, at tumatakbo pa rin ang build sa laptop. Walang error na lumalabas, at iyon ang nakakalito. Ang malayong path ay hindi malayong toolchain, at ang editor na kayang magbasa ng file sa mount ay kusang tatawag ng lokal na compiler dito. Ang solusyon ay ilipat ang workspace, hindi lang ang bytes.

Ang naka-mount na direktoryo ay hindi workspace

Ang pag-mount sa SSH o SMB ay nagbibigay ng path. Kung ang compiler, build system at debugger ay galing sa malayong panig ay depende sa kung saan pipiliin ng editor na patakbuhin sila. Maraming setup ang nagbabasa ng malayong file at nagko-compile nito nang lokal, tapos bumabagsak sa header file na nasa server lang.

Ang sintomas ay banayad: pumapasa ang build na may partial na resulta, o nabibigo sa include path na mukhang tama sa editor.

Patunayan kung aling host ang sumasagot

Kumonekta gamit ang totoong remote session sa halip na mount, tapos patakbuhin ang tatlong read-only na utos sa terminal na ibinibigay ng session na iyon. Ang gabay sa SSH ng VS Code ay nagdodokumento na ang terminal sa konektadong malayong window ay tumatakbo sa malayong host at ang parehong session ang nagdadala ng debugging. Humingi muna ng pahintulot para sa malalayong component kung hinihigpitan ito ng organisasyon.

hostname ay nagpapangalan sa makinang kinalalagyan mo, ipinapakita ng pwd kung saan talaga matatagpuan ang workspace, at ini-print ng command -v c++ ang compiler na patatakbuhin ng shell. Dapat ilarawan ng tatlong sagot ang server, hindi ang laptop.

Hindi nila pinapatunayan na tama ang bersyon o config ng build. Ihambing iyon sa sariling tagubilin ng proyekto bilang hiwalay na hakbang.

Subaybayan ang isang pagbabago sa build at debugging

Gumawa ng maliit na pagbabago sa malayong workspace at i-save doon. Patakbuhin ang dokumentadong build mula sa parehong direktoryo at tiyakin na ang output ay nagpapakita ng pagbabago mo, hindi ng lumang kopya sa ibang lugar. Tapos ilunsad ang debugger sa parehong remote session, na ang binary path at working directory ay nakaturo sa build tree ng server. Mahalaga ang pagtutugma ng source path, dahil ang debugger na nagre-resolve ng pagbabago mo sa path ng laptop ay nagde-debug ng ibang file.

Kung iniuulat ng debug target ang mga path na nagsisimula sa lokal mong home directory, lokal pa rin ang iniisip ng launch config.

Nanatili sa host ang mga dependency sa network

Ang pagkuha ng package, operasyon ng git o pagtakbo ng test na sinimulan sa build host ay gumagamit ng network at kredensyal ng host na iyon, hindi ng VPN session ng laptop mo. Ang pag-abot ng laptop sa pribadong mirror ng package ay walang sinasabi kung kaya ng server. Kung kailangan ng build ng registry, kailangan ng server ng ruta papunta doon, at usapan iyon sa firewall, hindi setting ng editor.

Baliktad man, ganoon din sa mga test application. Ang pag-abot sa serbisyo sa server mula sa browser mo ay hiwalay na koneksyon na nangangailangan ng aprubadong pribadong path o limitadong forward, hindi bukas na listener.

Idiskonekta nang hindi nawawala ang trabaho

I-save at mag-commit, o itala man lang ang working tree, bago mawala ang koneksyon. Ang malayong editing session ay hindi nangangako na ang tumatakbong build o hindi pa naka-save na buffer ay makakaligtas sa pagkawala ng network. Para sa lahat ng dapat tumagal nang higit sa session mo, gamitin ang sinusuportahang workflow ng job o session ng proyekto.

Ang paghahati ng trabaho ay malinaw: ang laptop ay interface, pagmamay-ari ng server ang workspace at toolchain, at ang VPN ang nagbibigay ng ruta. Ang paglipat ng file at paglipat ng build ay dalawang hiwalay na desisyon.