Fuchsia 통합 테스트

Fuchsia는 약 200만 줄의 Rust 코드로 이루어진 오픈 소스 운영 체제입니다.¹ Fuchsia는 과거에 많은 회귀를 잡아냈으며, 이후 CI에 포함되었습니다.

Fuchsia 작업이 실패하면 어떻게 해야 합니까?

fuchsia 핑 그룹에 연락하여 도움을 요청하십시오.

@rustbot ping fuchsia

CI에서 Fuchsia 빌드하기

Fuchsia는 풀 리퀘스트가 병합되기 전에 실행되는 bors 테스트 모음의 일부로 빌드됩니다.

풀 리퀘스트가 Fuchsia 빌더를 망가뜨릴까 걱정되어 bors 큐에 제출하기 전에 테스트해 보고 싶다면, Fuchsia 통합을 빌드하는 try 작업을 실행하도록 bors에 요청하기만 하면 됩니다: @bors try jobs=x86_64-fuchsia.

로컬에서 Fuchsia 빌드하기

Fuchsia는 Rust 이외의 언어도 사용하기 때문에 빌드 시스템으로 Cargo를 사용하지 않습니다. 또한 툴체인 빌드가 특정한 방식으로 구성되어 있어야 합니다.

Fuchsia를 빌드하는 권장 방법은 Fuchsia를 체크아웃하고 빌드를 실행해 주는 Docker 스크립트를 사용하는 것입니다. 이전에 Docker 테스트를 실행해 본 적이 있다면, Rust 체크아웃에서 이 명령을 실행하기만 하면 로컬 Rust 툴체인을 사용하여 Fuchsia를 다운로드하고 빌드할 수 있습니다.

src/ci/docker/run.sh x86_64-fuchsia

Docker로 작업을 실행하고 디버깅하는 방법에 대한 자세한 내용은 Docker로 테스트하기 장을 참고하십시오.

Fuchsia 체크아웃은 용량이 크다는 점에 유의하십시오. 이 글을 쓰는 시점 기준으로 체크아웃과 빌드에 46G의 공간이 필요하며, 짐작하시겠지만 완료하는 데 시간이 꽤 걸립니다.

로컬에서 Fuchsia를 빌드하려는 주된 이유는 회귀를 조사해야 하기 때문입니다. Docker 빌드를 실행하고 나면 Rust 체크아웃의 obj/fuchsia 디렉터리 안에서 Fuchsia 체크아웃을 찾을 수 있습니다. build-fuchsia.sh 스크립트의 KEEP_CHECKOUT 줄을 KEEP_CHECKOUT=1로 수정하면, 필요에 따라 체크아웃을 변경하고 위의 빌드 명령을 다시 실행할 수 있습니다. 이렇게 하면 이전의 빌드 결과를 모두 재사용합니다.

Fuchsia 체크아웃을 사용자 지정하는 더 많은 옵션은 build-fuchsia.sh 스크립트에서 찾을 수 있습니다.

Fuchsia 빌드 사용자 지정하기

Rust CI에서 Fuchsia를 빌드하는 데 사용되는 옵션에 대한 자세한 정보는 build-fuchsia.sh가 호출하는 build_fuchsia_from_rust_ci.sh 스크립트에서 찾을 수 있습니다.

Fuchsia 빌드 시스템은 Ninja 파일을 생성한 다음 빌드 실행 작업을 Ninja에 넘기는 메타빌드 시스템인 GN을 사용합니다.

Fuchsia 개발자는 빌드를 실행하고 기타 개발 작업을 수행하는 데 fx를 사용합니다. 이 도구는 Fuchsia 체크아웃의 .jiri_root/bin에 있습니다. 일부 워크플로에서는 이 경로를 $PATH에 추가해야 할 수도 있습니다.

관련된 fx 하위 명령이 몇 가지 있으며, 다음과 같습니다:

fx set은 빌드 인자를 받아 out/default/args.gn에 기록한 뒤 GN을 실행합니다.
fx build는 Ninja를 사용하여 Fuchsia 프로젝트를 빌드합니다. 빌드 인자가 변경되면 이를 자동으로 반영하여 GN을 다시 실행합니다. 기본적으로 모든 것을 빌드하지만, 특정 타깃을 빌드하기 위해 타깃 경로를 받을 수도 있습니다(아래 참고).
fx clippy는 특정 Rust 타깃(또는 모든 타깃)에 대해 Clippy를 실행합니다. Rust CI 빌드에서는 대부분의 Rust 타깃에 대한 코드 생성을 피하기 위해 이 명령을 사용합니다. 내부적으로는 fx build와 마찬가지로 Ninja를 호출합니다. clippy 결과는 출력되기 전에 빌드 출력 디렉터리 안의 json 파일에 저장됩니다.

타깃 경로

GN은 빌드 타깃을 식별하기 위해 다음과 같은 경로를 사용합니다.

//src/starnix/kernel:starnix_core

맨 앞의 //는 체크아웃의 루트를 의미하며, 나머지 슬래시로 구분된 부분은 디렉터리 이름입니다. : 뒤의 문자열은 해당 디렉터리의 BUILD.gn 파일에 정의된 타깃의 타깃 이름입니다.

타깃 이름이 디렉터리 이름과 같으면 생략할 수 있습니다. 즉, //src/starnix/kernel은 //src/starnix/kernel:kernel과 같습니다.

이러한 타깃 경로는 BUILD.gn 파일 안에서 의존성을 참조하는 데 사용되며, fx build에서도 사용할 수 있습니다.

컴파일러 플래그 수정하기

타깃에 추가되는 GN config 안에 사용자 지정 컴파일러 플래그를 넣을 수 있습니다. 간단한 예시는 다음과 같습니다.

config("everybody_loops") {
    rustflags = [ "-Zeverybody-loops" ]
}

rustc_binary("example") {
    crate_root = "src/bin.rs"
    # ...existing keys here...
    configs += [ ":everybody_loops" ]
}

이렇게 하면 example 타깃을 빌드할 때 rustc에 -Zeverybody-loops 플래그가 추가됩니다. 해당 타깃에 의존하는 모든 타깃에 config를 추가하려면 public_configs를 사용할 수도 있다는 점에 유의하십시오.

빌드 내 모든 Rust 타깃에 플래그를 추가하려면 //build/config:compiler config나 그 파일에서 참조하는 OS별 config에 rustflags를 추가하면 됩니다. Rust 타깃에서는 cflags와 ldflags가 무시된다는 점에 유의하십시오.

ninja 및 rustc 명령 직접 실행하기

한 단계 더 내려가 보면, fx build는 ninja를 호출하고, ninja는 결국 rustc를 호출합니다. 모든 빌드 작업은 out 디렉터리 안에서 실행되며, 이 디렉터리는 보통 Fuchsia 체크아웃 안의 out/default입니다.

타깃의 소스 파일 중 하나에 구문 오류를 추가하는 등의 방법으로 명령이 실패하도록 만들면, ninja가 실제로 호출하는 명령을 출력하게 할 수 있습니다. 명령을 얻은 뒤에는 출력 디렉터리 안에서 해당 명령을 실행할 수 있습니다.

툴체인 자체를 변경한 후에는 fx build나 ninja가 모든 Rust 타깃을 다시 빌드하도록 out/default/args.gn의 빌드 설정 rustc_version_string을 변경해야 합니다. 이 작업은 텍스트 편집기로 할 수 있으며, 빌드할 때마다 값이 바뀌기만 하면 문자열의 내용은 중요하지 않습니다. build_fuchsia_from_rust_ci.sh는 툴체인 디렉터리를 해싱하여 이 작업을 대신 수행합니다.

Fuchsia 웹사이트에 빌드 시스템에 대한 더 자세한 문서가 있습니다.

기타 팁과 요령

build_fuchsia_from_rust_ci.sh를 사용할 때는 첫 실행 후 fx set 명령을 주석 처리하여 매번 GN이 다시 실행되지 않도록 할 수 있습니다. 이렇게 하는 경우 version_string 줄도 주석 처리하여 몇 초를 절약할 수 있습니다.

첫 빌드 이후 ninja 시작 시간을 단축하려면 export NINJA_PERSISTENT_MODE=1을 실행하십시오.

Fuchsia 타깃 지원

Fuchsia 타깃 지원에 대해 자세히 알아보려면 rustc 책의 Fuchsia 장을 참고하십시오.

2024년 6월 기준으로 Fuchsia에는 tokei로 집계한 결과(주석과 빈 줄 제외) 약 200만 줄의 자체 Rust 코드와 거의 같은 양의 서드파티 코드가 있었습니다. ↩

Rust 컴파일러 개발 가이드