Zdalna kompilacja C++ przez VPN: zostaw łańcuch narzędzi na hoście
Zamontowanie udziału to nie to samo co zdalna kompilacja. Sprawdź, który host odpowiada, który kompilator działa i gdzie mieszkają debugger oraz sieć.
Udział jest zamontowany, edytor otwiera plik, a kompilacja nadal działa na laptopie. Nic nie zgłasza błędu i właśnie to dezorientuje. Zdalna ścieżka to nie zdalny łańcuch narzędzi, a edytor, który potrafi czytać plik przez montowanie, chętnie wywoła na nim lokalny kompilator. Rozwiązaniem jest przeniesienie obszaru roboczego, nie tylko bajtów.
Zamontowany katalog to nie obszar roboczy
Montowanie przez SSH lub SMB daje ścieżkę. To, czy kompilator, system kompilacji i debugger pochodzą ze zdalnej strony, zależy od tego, gdzie edytor zdecyduje się je uruchomić. Wiele konfiguracji czyta zdalne pliki i kompiluje je lokalnie, a potem wywala się na pliku nagłówkowym, który istnieje tylko na serwerze.
Objaw jest subtelny: kompilacja kończy się częściowymi wynikami albo wywala się na ścieżce include, która w edytorze wygląda poprawnie.
Udowodnij, który host odpowiada
Połącz się prawdziwą sesją zdalną zamiast montowania, a następnie uruchom trzy polecenia tylko do odczytu w terminalu, który daje ta sesja. Przewodnik SSH w VS Code dokumentuje, że terminal w połączonym zdalnym oknie działa na zdalnym hoście i że ta sama sesja niesie debugowanie. Najpierw uzyskaj zgodę na zdalne komponenty, jeśli organizacja je ogranicza.
hostname nazywa maszynę, na której jesteś, pwd pokazuje, gdzie naprawdę mieszka obszar roboczy, a command -v c++ wypisuje kompilator, który uruchomiłaby powłoka. Wszystkie trzy odpowiedzi powinny opisywać serwer, a nie laptop.
Nie dowodzą, że wersja albo konfiguracja kompilacji jest poprawna. Porównaj to z instrukcjami samego projektu jako osobnym krokiem.
Prześledź jedną zmianę przez kompilację i debugowanie
Wprowadź drobną zmianę w zdalnym obszarze roboczym i zapisz ją tam. Uruchom udokumentowaną kompilację z tego samego katalogu i potwierdź, że wynik odzwierciedla twoją zmianę, a nie starszą kopię gdzie indziej. Następnie uruchom debugger przez tę samą sesję zdalną, ze ścieżką pliku binarnego i katalogiem roboczym wskazującymi drzewo kompilacji serwera. Zgodność ścieżek źródłowych ma znaczenie, bo debugger, który przypisuje twoją zmianę ścieżce na laptopie, debuguje inny plik.
Jeśli cel debugowania zgłasza ścieżki zaczynające się od twojego lokalnego katalogu domowego, konfiguracja uruchomieniowa nadal myśli lokalnie.
Zależności sieciowe zostają na hoście
Pobranie pakietu, operacja git albo uruchomienie testów rozpoczęte na hoście kompilacji korzysta z sieci i poświadczeń tego hosta, a nie z sesji VPN twojego laptopa. To, że laptop dociera do prywatnego lustra pakietów, nie mówi nic o tym, czy serwer może. Jeśli kompilacja potrzebuje rejestru, serwer potrzebuje trasy do niego, a to rozmowa o zaporze ogniowej, nie ustawienie edytora.
Odwrotnie to samo dotyczy aplikacji testowych. Dotarcie do usługi na serwerze z przeglądarki to osobne połączenie, które wymaga zatwierdzonej prywatnej ścieżki albo ograniczonego przekazywania, a nie otwartego nasłuchu.
Rozłącz się bez utraty pracy
Zapisz i zrób commit, albo przynajmniej zarejestruj drzewo robocze, zanim połączenie padnie. Zdalna sesja edycji nie obiecuje, że trwająca kompilacja albo niezapisany bufor przetrwają przerwanie sieci. Dla wszystkiego, co musi żyć dłużej niż twoja sesja, użyj obsługiwanego przez projekt przepływu zadań lub sesji.
Podział pracy jest wtedy jasny: laptop to interfejs, serwer posiada obszar roboczy i łańcuch narzędzi, a VPN dostarcza trasę. Przenoszenie plików i przenoszenie kompilacji to dwie osobne decyzje.