Vzdálené sestavování C++ přes VPN: nechte nástrojový řetězec na hostiteli
Připojení sdílené složky není totéž jako vzdálené sestavování. Zkontrolujte, který hostitel odpovídá, který kompilátor běží a kde sídlí debugger a síť.
Sdílená složka se připojí, editor soubor otevře a sestavování přesto běží na notebooku. Nic nehlásí chybu, a právě to mate. Vzdálená cesta není vzdálený nástrojový řetězec, a editor, který umí číst soubor přes připojení, na něj ochotně zavolá místní kompilátor. Řešením je přesunout pracovní prostor, ne jen bajty.
Připojený adresář není pracovní prostor
Připojení přes SSH nebo SMB vám dá cestu. Zda kompilátor, systém sestavování a debugger přijdou ze vzdálené strany, závisí na tom, kde je editor rozhodne spustit. Mnohá nastavení čtou vzdálené soubory a kompilují je lokálně, a pak selžou na hlavičkovém souboru, který existuje jen na serveru.
Příznak je nenápadný: sestavení uspěje s částečnými výsledky, nebo se zlomí na cestě k include, která v editoru vypadá správně.
Dokažte, který hostitel odpovídá
Připojte se skutečnou vzdálenou relací místo připojení a pak v terminálu, který vám tato relace dá, spusťte tři příkazy jen pro čtení. VS Code průvodce SSH dokumentuje, že terminál v připojeném vzdáleném okně běží na vzdáleném hostiteli a že stejná relace nese i ladění. Pokud organizace vzdálené komponenty omezuje, nejprve si vyžádejte jejich schválení.
hostname pojmenuje stroj, na kterém jste, pwd ukáže, kde pracovní prostor skutečně leží, a command -v c++ vypíše kompilátor, který by shell spustil. Všechny tři odpovědi mají popisovat server, ne notebook.
Nedokazují, že verze nebo konfigurace sestavení je správná. To porovnejte s pokyny samotného projektu jako samostatný krok.
Proveďte jednu změnu sestavením i laděním
Udělejte malou změnu ve vzdáleném pracovním prostoru a uložte ji tam. Spusťte dokumentované sestavení ze stejného adresáře a ověřte, že výstup odráží vaši změnu, a ne starší kopii někde jinde. Potom spusťte debugger stejnou vzdálenou relací, s cestou k binárce a pracovním adresářem mířícími do stromu sestavení serveru. Shoda cest ke zdrojům je důležitá, protože debugger, který vaši změnu přiřadí cestě na notebooku, ladí jiný soubor.
Pokud cíl ladění hlásí cesty začínající vaším místním domovským adresářem, konfigurace spuštění stále myslí lokálně.
Síťové závislosti zůstávají na hostiteli
Stažení balíčku, operace git nebo spuštění testů na hostiteli sestavení používá síť a přihlašovací údaje tohoto hostitele, ne VPN relaci vašeho notebooku. To, že notebook dosáhne na soukromé zrcadlo balíčků, nic neříká o tom, zda na něj dosáhne server. Pokud sestavení potřebuje registr, server k němu potřebuje trasu, a to je rozhovor o firewallu, ne nastavení editoru.
Totéž platí obráceně pro testovací aplikace. Dostupnost služby na serveru z vašeho prohlížeče je samostatné spojení, které potřebuje schválenou soukromou cestu nebo omezené přesměrování, ne otevřený naslouchač.
Odpojte se, aniž byste ztratili práci
Před pádem spojení uložte a zacommitujte, nebo alespoň zapište stav pracovního stromu. Vzdálená editační relace neslibuje, že běžící sestavení nebo neuložený buffer přežije výpadek sítě. Pro cokoli, co má přežít vaši relaci, použijte projektem podporovaný postup úloh nebo relací.
Dělba práce je pak jasná: notebook je rozhraní, server vlastní pracovní prostor a nástrojový řetězec a VPN dodává trasu. Přesunout soubory a přesunout sestavení jsou dvě oddělená rozhodnutí.