주어진 컴파일러와 플랫폼이 무엇을 지원하는지 확인하는 witness 프로그램을 생성한다는 점이 흥미롭다
전통적인 C configure 빌드 체인이 대체로 이런 방식으로 동작한다는 게 꽤 이상하게 느껴지지만, 이 컴파일러, 혹은 트랜스파일러가 그 패턴을 따르는 건 납득됨
“14번째 시도: cilly”라니 대단한 집요함이고, 그런 끈기가 부럽다

비교하자면, Zig 컴파일러 전체를 C로 변환한 버전을 갖고 있는데, 이는 소스에서 빌드하는 일반 절차의 일부임
규모는 460만 줄이라 이 프로젝트보다 거의 정확히 한 자릿수 작다. 생성된 C 코드는 대상별로 달라지지만, 컴파일러별로 달라지지는 않음

시스템 프로그래머는 아니지만, 이런 프로젝트가 Rust와 Zig 중 무엇을 쓸지에 영향을 줄 수 있을지 궁금함
Zig의 장점에는 다양한 교차 컴파일 대상 지원과 자체 호스팅 도구체인, LLVM 선택 의존성이 포함되는데, Rust를 희귀 플랫폼용 C로 컴파일할 수 있다는 약속은 Zig 쪽을 겨냥한 신호처럼도 보임

crustc를 쓰는 것만으로는 그렇지 않음. 변환된 컴파일러도 원래 컴파일러와 같은 컴파일 대상만 지원하기 때문임
다만 다른 Rust 프로젝트를 C로 변환해서 C만 지원하는 대상에서 실행하고 컴파일하는 것은 가능함
그래도 영향을 과대평가하면 안 됨. 아주 틈새 문제를 위한 약간 번거로운 해법에 가깝다. rustc는 이미 대상 지원이 넓고, gcc 백엔드를 통해 더 늘어날 예정임
Zig의 교차 컴파일 도구는 멋지지만, 특히 Zig나 Rust보다 까다로운 C 부분에서 편의성을 높이는 쪽에 가깝고, 더 많은 대상을 지원한다는 의미는 상대적으로 작음
결국 Zig와 Rust의 대상 지원은 이미 꽤 비슷해서 결정적 요인이 되긴 어렵고, 두 언어 사이에는 훨씬 중요한 차이가 많다

멋지긴 한데, 결국 LLVM의 능력에 제한되는 것 아닌가?

왜 그래야 하는지 모르겠음. crustc는 Rust를 C로 바꾸는 도구체인인 cilly가 무엇을 할 수 있는지 보여주는 예시일 뿐임
전체 cilly 도구체인은 사용자의 Rust 코드를 임의의 대상용 C로 컴파일한다. 이 저장소는 가장 화려한 시연이라고 생각해서 컴파일러가 자기 자신을 컴파일하는 모습을 보여주는 것임