기술 · 실용 가이드
GNU make jobserver unavailable? -j를 더하기 전에 재귀 경계를 증명하세요
자식 make가 조정 채널을 상속하지 못해 한 작업으로 후퇴했습니다. 첫 부모 레시피나 래퍼를 추적하고 실제 인식 경계만 고친 뒤 공유 한도를 측정하세요.
GNU make의 “jobserver unavailable: using -j1”은 자식 make가 부모 jobserver 연결을 충분히 상속하지 못해 순차 실행한다는 뜻입니다. 컴파일러 실패나 모든 계층에 독립 -j가 필요하다는 증거가 아닙니다.
조정이 처음 사라진 경계를 찾으세요. 실제 재귀 make 레시피에는 $(MAKE), 인식에 필요한 경우만 +를 쓰고, 래퍼는 프로토콜 구현 시에만 인식을 선언한 뒤 하나의 최상위 한도로 검증하세요.
1. 처음 손실된 경계를 수집하세요
원래 최상위 명령으로 통제 빌드를 한 번 실행하고 첫 경고, 중첩 단계, 부모 명령, 버전, 생성기, 프로세스 트리와 MAKEFLAGS 형태를 보존하세요. 뒤 경고보다 최초 손실점이 소유 경계입니다.
make를 직접 실행하는 레시피, 셸 스크립트, CMake 사용자 명령, 언어 래퍼와 컨테이너 진입점을 구분하세요. 살아 있는 설명자를 보고하거나 새 명령에 복사하지 마세요.
2. 경고를 조정 실패로 해석하세요
GNU make는 MAKEFLAGS로 접근 정보를 제공하고 시작한 각 명령에 암시적 슬롯 하나를 예약합니다. 인식된 재귀 make는 최상위 작업 한도를 함께 지킵니다.
부모가 다른 make라고 판단하지 못하면 자식 정보가 불완전합니다. 파이프 방식은 설명자를 잃어 경고를 내고 -j1 순차 실행으로 계속합니다.
3. 직접 재귀 make 레시피를 고치세요
자식이 make라면 리터럴 make 대신 레시피에서 $(MAKE)를 직접 사용하세요. 부모를 시작한 실행 파일과 GNU make의 재귀 의미도 유지됩니다.
선행 +는 간접 재귀 호출을 표시할 수 있지만 dry-run, touch, question 동작도 바꿉니다. MAKE가 직접 나타나지 않거나 래퍼가 실제 지원할 때만 쓰세요.
4. 래퍼와 CMake를 명시적으로 다루세요
래퍼가 자식을 시작하면 MAKEFLAGS 문자열뿐 아니라 실제 채널도 보존하는지 확인하세요. --jobserver-auth를 만들거나 부모 밖에서 설명자 번호를 재사용하지 마세요.
CMake는 지원 Makefile 생성기에서 JOB_SERVER_AWARE를 적용할 수 있습니다. 올바르게 참여하는 명령에만 설정하고 Ninja 등은 다른 병렬 체계로 다루세요.
5. 독립 중첩 -j를 기본 해결책으로 쓰지 마세요
경고를 없애려고 모든 자식 make에 -jN을 넣지 마세요. 강제 숫자 -j는 공유 모드를 끄고 중첩 트리가 CPU나 메모리 한도를 넘게 할 수 있습니다.
가능하면 병렬 결정은 최상위에 두세요. 외부 래퍼가 독립 한도를 요구하면 소유 경계, 생성기, 버전과 자원 한도를 기록하세요.
6. 공유 한도와 빌드를 검증하세요
고정 최상위 -j로 같은 깨끗한 대상을 다시 실행하세요. 첫 경고가 사라지고 작업이 실제 겹치며 최대 프로세스가 한도 안인지 확인하고 속도만 정답으로 보지 마세요.
일반 테스트와 CI 동등 또는 저메모리 빌드를 실행하고 dry-run 동작을 확인하세요. 전후 명령, 정리된 MAKEFLAGS 구조와 로그를 보존하세요.
