보조 도구 정책

T-compiler의 임무는 정상적으로 동작하는 Rust 컴파일러(rustc)를 출시하는 데 필요한 일을 하는 것이지만, rustc는 단독으로 동작한 적이 없습니다. 컴파일러 툴체인과 함께 제공되든 환경에서 기대되든, 항상 사용에 추가 도구를 필요로 했습니다. 다음은 rustc와 그것이 함께 사용되거나 요구할 수 있는 도구들에 대한 기대사항 일부를 명확히 하고, 이미 암묵적으로 존재하는 몇 가지 기대사항을 명시적으로 드러내려는 시도입니다.

정의

• 컴파일 환경(compilation environment) - 제공된 도구가 실행되는 호스트 시스템으로, 파일시스템 및 환경 변수와 같은 일시적 상태를 포함합니다.
• 실행(invoke) - 프로세스 생성, 라이브러리 로딩, 또는 컴파일 환경이 지원할 수 있는 다른 수단을 통해 어떤 아티팩트의 코드를 실행하는 것입니다.
• 중간 산출물(intermediates) - 컴파일러 도구를 실행하여 출력된, 컴파일러 도구에 입력으로 제공될 아티팩트입니다.
• 컴파일러 도구 - Rust 툴체인의 일부로 제공되는 산출물로서, 코드를 컴파일하고 바이너리 코드 객체로 링크하는 과정의 일부로 호출되는 것입니다.
• 바이너리 도구(binary tool) - 바이너리 코드 객체를 생성하거나 편집하는 데 사용되는 컴파일러 도구입니다.
• 제공 도구 - T-compiler와 T-release의 지원을 받아 Rust 툴체인의 일부로 배포되는 바이너리 도구 또는 컴파일러 도구입니다. 여기에는 특히 rustc, rust-lld, rust-objcopy와 같은 바이너리 도구가 포함됩니다.
• 보조 도구(supplemental tool) - 컴파일러 팀과 릴리스 팀이 배포하지는 않지만, 제공된 도구와 함께 사용될 수 있는 컴파일러 도구입니다. 여기에는 특히 ld.bfd, link.exe, llvm-bolt, 그리고 “링커 스크립트”(Link Editor Command Language로 작성된 프로그램)와 같은 바이너리 도구가 포함됩니다.

보조 도구의 사용

rustc를 포함한 어떤 제공된 도구든, 명시적인 사용자 입력을 요구하지 않고도 보조 도구를 암묵적으로 실행할 수 있습니다. 제공된 도구는 어떤 도구를 실행할지 결정하기 위해 컴파일 환경을 조사할 수 있습니다.¹ 보조 도구가 실행될 때 컴파일 환경은 관례적이거나 특이한 방식으로 구성되어 있을 것으로 기대될 수 있습니다.

관례적 기대의 예로는 다음이 있습니다

• link.exe라는 이름의 실행 파일이 인자로 주어진 경로에 위치한 바이너리 코드 객체를 링크하는 작업을 수행할 것으로 기대되는 경우, 또는
• 유닉스 도구가 POSIX에서 지정한 방식으로 인자를 따를 것으로 기대되는 경우, 또는
• $CC와 같은 환경 변수가 C 컴파일러 경로를 담고 있을 것으로 기대되는 경우입니다.

특이한 기대는 관례적 기대와 비슷해 보이지만 이를 부당하게 적용하는 경우로, 예를 들어 유닉스 시스템(macOS까지 포함하여)이 GNU 사용자 영역을 가진 리눅스 시스템과 유사하다고 가정하는 것입니다. 또는 순전히 가정된 것일 수도 있는데, 예를 들어 컴파일 환경 내 데이터가 Rust 툴체인의 다른 제공 도구에 의해 생성되거나 수정되었다고 가정하는 경우가 그렇습니다.

이러한 기대는 컴파일 환경의 내용물이 사용하기에 안전한지, 올바르게 작동하는지, 올바르게 명명되었는지를 판별할 필요가 없다는 데까지 확장됩니다. 파일시스템은 특정 방식으로 구성되어 있을 것으로 기대될 수 있으며, 파일에 부여된 어떤 이름이든 올바른 레이블로서 암묵적으로 신뢰될 수 있습니다. 보조 도구를 기대되는 경로에서 찾고, 우리가 어떤 도구에 어떤 방식으로 의존하는지 문서화하려는 합리적인 시도가 이루어져야 하지만, 이것이 필수는 아닙니다. 환경으로부터 보조 도구를 계속 실행할 필요조차 없는데, 이는 릴리스 팀과 컴파일러 팀의 재량으로 제공된 도구가 확장되어 환경에서 발견된 보조 도구를 대체하는 명시적 목적으로 사용될 수 있기 때문입니다.

제공된 도구가 보조 도구를 실행해야 하며 그 출력이 컴파일 과정의 다른 부분을 위한 중간 산출물로 사용된다고 판단한 경우, 그 결과 출력은 해당 도구가 출력하는 형식을 엄격히 준수할 것으로 기대될 수 있습니다. 또한 링크 가능하거나 로드 가능하거나 심지어 실행 가능한 바이너리 코드 객체여야 한다거나, 단순히 Rust 툴체인이 기대하는 추가 메타데이터 섹션을 유지해야 한다는 등 다른 요구 사항을 충족해야 할 것으로 기대될 수도 있습니다.

제공된 도구에 대한 어떤 기대도 위반되지 않았다고 가정할 때, 제공된 도구는 실행 가능하거나 동적으로 로드 가능한 바이너리 코드 객체를 생성할 때 최소한 해당 객체의 바이너리 형식 명세를 준수하는 객체를 생성해야 합니다. 중간 산출물은 대개 어떤 바이너리 형식을 준수하더라도 올바르게 포맷되어 있지 않을 수 있습니다. 문서화가 부족한 바이너리 형식의 경우, 준수 여부는 컴파일러 팀이 원하는 대로 해석될 수 있습니다.

컴파일러 팀 입장에서, 이는 대체로 원하는 대로 환경에서 항목들을 호출하는 것을 의미합니다. 예를 들어 소스에 정의되지 않은 동작이 없다고 가정하고, 그저 출력이 올바르게 나오도록 하려고 시도합니다. 이상적으로는 디버거 등을 포함한 “네이티브” 툴체인이 우리 코드와 잘 작동할 만큼 충분히 준수하고 싶지만, 사용하고 싶을 수 있는 도구의 목록은 무한합니다.

보조 도구 이슈 트리아지하기

보조 도구에 관한 이슈를 해결하기 전에, 우리 툴체인이 의존하는 기대 사항이 “당연“하지 않다면 문서화되어야 합니다. 예를 들어 최소 도구 버전에 대한 의존성, 특히 그것이 운영 체제에 기본으로 딸려 오는 버전보다 높은 경우가 그렇습니다. 당연하지 않은 기대 사항만 문서화하는 이유는 이 문서 도입부의 장황한 정의의 정의 때문입니다. 아무것도 전제하지 않는다면 컴파일러가 어떻게 작동하는지 설명하기에 충분한 어휘를 정의하는 데 오랜 시간이 걸릴 수 있습니다.

누군가 컴파일러 플래그나 설정을 통해 보조 도구를 능동적으로 포함시킨 뒤 버그를 신고했다면, 보조 도구 없이도 해당 객체가 올바른 형식인지 판단해 보십시오. 그러한 경우라면, 보통은 고치려 하지 말고 이슈를 종료해야 합니다

때로는 rustc가 암묵적으로 호출했기 때문에 보조 도구가 관련되는 경우가 있습니다. 툴체인이 기능적으로 이를 대체할 수 있는 제공 도구를 갖추고 있다면, 이슈를 해결하기 전에 그렇게 하는 편이 바람직합니다.

문제가 특정 운영 체제의 지역적 관례 준수에 관한 것이라면, 이를 위한 별도의 타깃이 있는 한 그에 대응하기 위한 어느 정도의 노력을 기울일 수 있습니다. 자원이 그렇게 하기에 개방적이고 이용 가능하다면, 보통은 참여를 시도해야 합니다.

1. 이는 이름으로 어떤 도구든 OS가 제공하는 실행이 가능하거나 선호된다는 사실에서 비롯되는 기능적 결과이며, 그것은 곧 암묵적으로든 명시적으로든 $PATH를 뒤진다는 것을 의미합니다. ↩