Zig: 모든 패키지 관리 기능을 컴파일러에서 빌드 시스템으로 이동

2 hours ago 1

Zig는 build.zig와 빌드 시스템을 별도 프로세스로 분리한 흐름에 맞춰, 패키지 관리 로직을 컴파일러 실행 파일 밖의 maker 프로세스로 옮김
zig build, zig fetch, zig init, zig libc가 maker 쪽으로 이동하면서 HTTP, TLS, Git, 압축, build.zig.zon 처리 코드가 소스 형태로 배포됨
이 구조에서는 컴파일러 재빌드 없이 패키지 관리 기능을 고칠 수 있고, maker가 ReleaseSafe로 컴파일되어 네트워킹 작업의 안전성 검사도 활성화됨
원래 목적은 build server protocol을 노출해 ZLS를 막고 있던 --build-runner 변경 문제를 푸는 것이며, 새 프로세스 트리에서는 maker가 configurer의 부모로 남아 설정 재실행을 더 안정적으로 처리할 수 있음
사용자 영향은 크지 않지만 Zig 실행 파일은 14.1MiB에서 13.5MiB로 4% 줄고, --maker-opt와 --zig-lib-dir는 각각 ZIG_DEBUG_MAKER, ZIG_LIB_DIR 환경 변수로 대체됨

패키지 관리 로직의 이동

Zig는 사용자 build.zig 스크립트와 빌드 시스템 자체가 별도 프로세스로 분리된 뒤, 패키지 관리 로직도 빌드 시스템 쪽에 두는 구조로 바꿈
maker 프로세스로 이동한 하위 명령은 다음과 같음
- zig build
- zig fetch
- zig init
- zig libc

원래 동기는 build server protocol을 노출해 ZLS를 막고 있던 문제를 해소하는 것이었음
이전 구조에서는 zig build가 컴파일러와 패키지 관리자를 함께 담당하고, 그 아래 builder가 사용자 build.zig 로직과 빌드 시스템 구현을 담았음
maker/configurer 분리 이후 구조는 다음과 같았음
- zig build: 컴파일러 + 패키지 관리자
- configurer: 사용자 build.zig 로직
- maker: 빌드 시스템
이 구조에서 오래 실행되는 zig build --watch는 build.zig나 관련 파일 변경을 감지하면 configurer를 다시 실행해야 했고, 이를 위해 maker가 종료되어 zig build가 패키지 관리 로직을 반복할 기회를 줘야 했음
새 구조에서는 zig build가 컴파일러만 맡고, 그 아래 maker가 빌드 시스템과 패키지 관리자를 담당하며, configurer는 maker의 자식 프로세스가 됨
설정을 다시 실행해야 할 때도 maker가 부모 프로세스로 계속 살아 있을 수 있음
예정된 build server에서는 서버 종료 후 클라이언트가 다시 연결하는 대신, 클라이언트에 설정 변경을 알리는 구조가 가능해짐

대부분 비호환 변경은 아니지만, 사용자가 볼 수 있는 차이가 있음
- Zig 실행 파일 바이너리 크기: LLVM 없는 ReleaseSmall 기준 14.1MiB에서 13.5MiB로 줄어 4% 감소
- --maker-opt 플래그는 ZIG_DEBUG_MAKER 환경 변수로 대체됨
- --zig-lib-dir 플래그는 ZIG_LIB_DIR 환경 변수로 대체됨