VPN을 통한 원격 C++ 빌드: 툴체인은 호스트에 두세요
공유 폴더를 마운트하는 것과 원격에서 빌드하는 것은 다릅니다. 어느 호스트가 응답하는지, 어떤 컴파일러가 실행되는지, 디버거와 네트워크가 어디에 있는지 확인하세요.
공유가 마운트되고 편집기가 파일을 열어도 빌드는 여전히 노트북에서 실행됩니다. 아무 오류도 나지 않으며, 바로 그 점이 혼란스럽게 만듭니다.원격 경로는 원격 툴체인이 아니다, 그리고 마운트를 통해 파일을 읽을 수 있는 편집기는 그 파일에 로컬 컴파일러를 기꺼이 호출합니다. 해법은 바이트만이 아니라 작업 공간을 옮기는 것입니다.
마운트된 디렉터리는 작업 공간이 아니다
SSH나 SMB로 마운트하면 경로가 생깁니다. 컴파일러, 빌드 시스템, 디버거가 원격 쪽에서 오는지는 편집기가 그것들을 어디서 실행할지에 달려 있습니다. 많은 설정이 원격 파일을 읽어 로컬에서 컴파일하고, 서버에만 있는 헤더 파일에서 실패합니다.
증상은 미묘합니다. 빌드가 부분적인 결과로 성공하거나, 편집기에서는 맞아 보이는 포함 경로에서 깨집니다.
어느 호스트가 응답하는지 증명하세요
마운트 대신 실제 원격 세션으로 연결한 다음, 그 세션이 주는 터미널에서 읽기 전용 명령 세 개를 실행하세요. VS Code의SSH 안내서는 연결된 원격 창의 터미널이 원격 호스트에서 실행되고 같은 세션이 디버깅도 나른다고 문서화합니다. 조직이 원격 구성 요소를 제한한다면 먼저 승인을 받으세요.
hostname 는 당신이 있는 머신의 이름을 알려 주고, pwd 는 작업 공간이 실제로 어디에 있는지 보여 주며, command -v c++ 는 셸이 실행했을 컴파일러를 출력합니다. 세 답변 모두 노트북이 아니라 서버를 설명해야 합니다.
그것들은 버전이나 빌드 구성이 맞다는 것을 증명하지 않습니다. 그것은 별도 단계로 프로젝트 자체의 지침과 비교하세요.
한 번의 편집을 빌드와 디버깅까지 따라가세요
원격 작업 공간에서 작은 변경을 하고 그곳에 저장하세요. 같은 디렉터리에서 문서화된 빌드를 실행하고 출력이 당신의 변경을 반영하는지, 다른 곳의 오래된 체크아웃이 아닌지 확인하세요. 그다음 같은 원격 세션으로 디버거를 실행하되, 바이너리 경로와 작업 디렉터리가 서버의 빌드 트리를 가리키게 하세요. 소스 경로가 일치하는 것이 중요합니다. 당신의 변경을 노트북 경로로 해석하는 디버거는 다른 파일을 디버깅하고 있기 때문입니다.
디버그 대상이 로컬 홈 디렉터리로 시작하는 경로를 보고하면, 실행 구성은 아직 로컬로 생각하고 있습니다.
네트워크 의존성은 호스트에 남습니다
빌드 호스트에서 시작한 패키지 가져오기, git 작업, 테스트 실행은 당신 노트북의 VPN 세션이 아니라 그 호스트의 네트워크와 자격 증명을 사용합니다. 노트북이 사설 패키지 미러에 닿는다고 해서 서버도 닿을 수 있다는 뜻은 아닙니다. 빌드에 레지스트리가 필요하면 서버에 그곳으로 가는 경로가 필요하며, 그것은 편집기 설정이 아니라 방화벽 논의입니다.
반대 방향도 테스트 애플리케이션에 적용됩니다. 브라우저에서 서버의 서비스에 닿는 것은 별도의 연결이며, 승인된 사설 경로나 제한된 전달이 필요하고 열린 리스너가 아닙니다.
작업을 잃지 않고 연결을 끊으세요
연결이 끊기기 전에 저장하고 commit하거나, 적어도 작업 트리를 기록하세요. 원격 편집 세션은 실행 중인 빌드나 저장하지 않은 버퍼가 네트워크 중단을 견딘다고 약속하지 않습니다. 세션보다 오래 살아야 하는 모든 것에는 프로젝트가 지원하는 작업 또는 세션 워크플로를 사용하세요.
그때 작업 분담은 분명합니다. 노트북은 인터페이스이고, 서버가 작업 공간과 툴체인을 소유하며, VPN이 경로를 제공합니다. 파일을 옮기는 것과 빌드를 옮기는 것은 두 가지 별개의 결정입니다.