Отдалечено изграждане на C++ през VPN: задръжте веригата от инструменти на хоста
Монтирането на споделената папка не е същото като отдалечено изграждане. Проверете кой хост отговаря, кой компилатор се изпълнява и къде живеят дебъгерът и мрежата.
Споделената папка се монтира, редакторът отваря файла, а изграждането все още върви на лаптопа. Нищо не дава грешка и точно това обърква. Отдалечен път не е отдалечена верига от инструменти, а редактор, който може да прочете файл през монтиране, с удоволствие ще извика локалния компилатор върху него. Решението е да преместите работното пространство, а не само байтовете.
Монтирана папка не е работно пространство
Монтирането през SSH или SMB ви дава път. Дали компилаторът, системата за изграждане и дебъгерът идват от отдалечената страна, зависи от това къде редакторът реши да ги изпълнява. Много настройки четат отдалечени файлове и ги компилират локално, после се провалят на заглавен файл, който съществува само на сървъра.
Симптомът е фин: изграждането успява с частични резултати или се чупи на път за включване, който изглежда правилен в редактора.
Докажете кой хост отговаря
Свържете се с истинска отдалечена сесия, а не с монтиране, после изпълнете три команди само за четене в терминала, който тази сесия ви дава. Ръководството за SSH на VS Code документира, че терминал в свързан отдалечен прозорец работи на отдалечения хост и същата сесия носи дебъгването. Първо получете одобрение за отдалечените компоненти, ако организацията ги ограничава.
hostname показва машината, на която сте, pwd показва къде наистина живее работното пространство, а command -v c++ отпечатва компилатора, който обвивката би изпълнила. И трите отговора трябва да описват сървъра, не лаптопа.
Те не доказват, че версията или конфигурацията за изграждане е правилна. Сравнете това с инструкциите на самия проект като отделна стъпка.
Проследете една промяна през изграждане и дебъгване
Направете малка промяна в отдалеченото работно пространство и я запазете там. Изпълнете документираното изграждане от същата папка и потвърдете, че изходът отразява вашата промяна, а не по-старо копие някъде другаде. След това стартирайте дебъгера през същата отдалечена сесия, като пътят до двоичния файл и работната папка сочат в дървото за изграждане на сървъра. Съвпадащите пътища на изходния код са важни, защото дебъгер, който съотнася промяната ви към път на лаптопа, дебъгва друг файл.
Ако целта за дебъгване съобщава пътища, започващи с локалната ви домашна папка, конфигурацията за стартиране все още мисли локално.
Мрежовите зависимости остават на хоста
Изтегляне на пакет, git операция или пускане на тест на хоста за изграждане използва неговата мрежа и идентификационни данни, а не VPN сесията на лаптопа ви. Това, че лаптопът достига частно огледало на пакети, не казва нищо за това дали сървърът може. Ако изграждането има нужда от регистър, на сървъра му трябва маршрут до него и това е разговор за защитна стена, а не настройка на редактора.
Същото важи в обратна посока за тестови приложения. Достигането до услуга на сървъра от браузъра ви е отделна връзка, която изисква одобрен частен път или ограничено пренасочване, а не отворен слушател.
Прекъснете, без да загубите работата
Запазете и фиксирайте промените, или поне запишете работното дърво, преди връзката да падне. Отдалечената сесия за редактиране не обещава, че работещо изграждане или незапазен буфер ще преживеят прекъсване на мрежата. За всичко, което трябва да надживее сесията ви, използвайте поддържания от проекта работен процес за задания или сесии.
Разделението на труда тогава е ясно: лаптопът е интерфейс, сървърът притежава работното пространство и веригата от инструменти, а VPN осигурява маршрута. Преместването на файлове и преместването на изграждането са две отделни решения.