외부 종속 항목 개요

문제 신고 소스 보기 1박 · 7.2 · 7.1 · 7.0 · 6.5 · 6.4

Bazel은 사용되는 외부 종속 항목, 사용되는 소스 파일 (텍스트 및 바이너리)을 지원합니다. 빌드에서 실행되어야 합니다 예를 들어, GitHub 저장소, Maven 아티팩트 또는 로컬 실행할 수 있습니다

Bazel 6.0부터 Bazel을 사용한 외부 종속 항목을 관리하는 방법에는 두 가지가 있습니다. 저장소 중심의 기존 WORKSPACE 시스템 최신 모듈 중심 MODULE.bazel 시스템 (코드명: Bzlmod --enable_bzlmod 플래그로 사용 설정) 두 시스템을 사용하여 Bzlmod가 향후 Bazel에서 WORKSPACE 시스템을 대체할 예정입니다. 출시하는 경우 Bzlmod 이전 가이드에서 마이그레이션할 수 있습니다

이 문서에서는 외부 종속 항목 관리와 관련된 개념을 설명합니다. Bazel의 기본 개념을 살펴봤습니다.

개념

저장소

루트에 경계 마커 파일이 있고 소스를 포함하는 디렉터리 트리 Bazel 빌드에서 사용할 수 있는 여러 파일을 제공합니다 종종 repo로 축약됩니다.

저장소 경계 마커 파일은 MODULE.bazel일 수 있습니다 (이 저장소가 Bazel 모듈), REPO.bazel (아래 참고) 또는 기존 컨텍스트는 WORKSPACE 또는 WORKSPACE.bazel입니다. 모든 저장소 경계 마커 파일 저장소의 경계를 나타냅니다. 같은 파일에 여러 개의 파일이 를 참조하세요.

기본 저장소

현재 Bazel 명령어가 실행되고 있는 저장소입니다.

작업공간

모든 Bazel 명령어에서 공유하는 환경은 동일한 기본 저장소에서 실행됩니다.

역사적으로 '저장소'의 개념은 및 'workspace' CANNOT TRANSLATE 뒤섞여 있습니다. '작업공간'이라는 용어 자주 사용되는 표현은 때로는 'repository'의 동의어로 사용되기도 합니다.

표준 저장소 이름

저장소 주소 지정이 가능한 표준 이름입니다. 맥락 안에서 각 저장소에는 하나의 표준 이름이 있습니다. 저장소 내부의 대상 라벨로 처리할 수 있는 표준 이름인 canonical_name @@canonical_name//pac/kage:target (이중 @에 유의)

기본 저장소에는 항상 빈 문자열이 표준 이름으로 표시됩니다.

명확한 저장소 이름

다른 특정 저장소의 컨텍스트에서 저장소 지정이 가능한 이름입니다. 이는 저장소의 '닉네임'이라고 생각할 수 있습니다. 저장소 컨텍스트에서 michael의 이름은 mike일 수 있습니다. alice이지만 저장소 컨텍스트에서는 이름이 mickey일 수 있습니다. bob입니다. 이 경우 michael 내부의 대상은 라벨로 처리될 수 있습니다. alice의 컨텍스트에서 @mike//pac/kage:target (단일 @에 주목).

반대로 이는 저장소 매핑, 즉 각 저장소 '명확한 저장소 이름'의 매핑을 유지함 '표준 저장소 이름'으로 변경합니다

저장소 규칙

Bazel에 저장소를 구체화하는 방법을 알려주는 저장소 정의의 스키마입니다. 저장소 예: '특정 URL에서 zip 보관 파일을 다운로드 또는 "특정 Maven 아티팩트를 가져와 java_import target'을 사용하거나 단순히 '로컬 디렉터리를 심볼릭 링크로 연결'할 수 있습니다. 모든 저장소는 적절한 수의 인수로 저장소 규칙을 호출하여 defined를 만들 수 있습니다.

작성 방법에 대한 자세한 내용은 저장소 규칙을 참조하세요. 자체 저장소 규칙을 만듭니다

지금까지 가장 일반적인 저장소 규칙은 http_archive: 보관 파일을 다운로드합니다. 추출한 다음 local_repository는 로컬 디렉터리를 생성합니다

저장소 가져오기

연결된 저장소를 실행하여 로컬 디스크에서 저장소를 사용할 수 있도록 하는 작업입니다. repo 규칙을 만듭니다. 작업공간에 정의된 저장소는 로컬 디스크에서 사용할 수 없습니다. 데이터를 가져올 수 있습니다

일반적으로 Bazel은 저장소에서 무언가가 필요할 때만 저장소를 가져옵니다. 저장소를 아직 가져오지 않은 것입니다 저장소를 이미 가져온 경우 정의가 변경된 경우에만 Bazel을 다시 가져옵니다.

fetch 명령어를 사용하면 저장소의 프리페치를 시작할 수 있습니다. 대상 또는 모든 빌드를 수행하는 데 필요한 모든 저장소를 생성할 수 있습니다 이러한 기능은 --nofetch 옵션을 사용하여 오프라인 빌드를 사용 설정합니다.

--fetch 옵션은 네트워크 액세스를 관리하는 역할을 합니다. 기본값은 true입니다. 하지만 false (--nofetch)로 설정하면 명령어가 존재하지 않는 경우 명령어는 다음과 같은 결과를 얻습니다. 있습니다

자세한 내용은 가져오기 옵션을 참고하세요. 가져오기 제어에 대한 정보

디렉터리 레이아웃

가져온 후에는 이 저장소의 external 하위 디렉터리에서 저장소를 찾을 수 있습니다. 출력 베이스입니다.

다음 명령어를 실행하여 표준 이름 canonical_name:

ls $(bazel info output_base)/external/ canonical_name

REPO.bazel 파일

REPO.bazel 파일은 디렉터리 트리의 최상위 경계를 표시하는 데 사용됩니다. 저장소가 있습니다 저장소 역할을 하기 위해 아무것도 포함할 필요가 없습니다. 경계 파일 몇 가지 공통 속성을 지정하는 데 사용할 수도 있습니다. 를 사용하도록 설정합니다.

REPO.bazel 파일의 문법은 BUILD 파일과 비슷하지만 load 문이 지원되며 단일 함수 repo()만 지원됩니다. 있습니다. repo()은 package()와 동일한 인수를 사용합니다. 함수(BUILD 파일의 형식) 반면 package() 패키지 내의 모든 빌드 대상에 공통 속성 repo()를 지정합니다. 저장소 내부의 모든 빌드 대상에 대해 이 작업을 수행합니다.

예를 들어 다음을 수행하여 저장소의 모든 대상에 공통 라이선스를 지정할 수 있습니다. 다음 REPO.bazel 파일이 포함됩니다.

repo(
    default_package_metadata = ["//:my_license"],
)

Bzlmod로 외부 종속 항목 관리

새로운 외부 종속 항목 하위 시스템인 Bzlmod가 저장소에서 직접 작동하지 않음 정의할 수 있습니다 대신 모듈에서 종속 항목 그래프를 빌드하고 다음을 실행합니다. 확장을 사용하고 그에 따라 저장소를 정의합니다.

Bazel 모듈은 여러 개의 컨테이너가 있을 수 있는 Bazel 프로젝트입니다. 각 버전은 종속된 다른 모듈에 관한 메타데이터를 게시합니다. 을 탭합니다. 모듈의 저장소 루트에 MODULE.bazel 파일이 WORKSPACE 파일. 이 파일은 이름을 선언하는 모듈의 매니페스트이며 버전, 종속 항목 목록 등이 포함됩니다. 다음은 Google Cloud의 예:

module(name = "my-module", version = "1.0")

bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")

모듈은 Bzlmod가 조회하는 Bazel 레지스트리 - 기본적으로 Bazel Central 등록처. 등록처는 종속 항목 MODULE.bazel 파일: Bazel이 전체 파일을 탐색할 수 있습니다. 전이 종속 항목 그래프를 확인합니다.

버전 확인 후에는 모듈별로 하나의 버전이 선택됩니다. Bazel이 레지스트리에 다시 컨설트하여 각 모듈의 저장소를 정의하는 방법을 알아봅니다. (대부분의 경우 http_archive 사용)

모듈은 태그라고 하는 맞춤설정된 데이터도 지정할 수 있습니다. 태그 모듈 결정 후 모듈 확장 프로그램에 의해 소비됨 추가 저장소를 정의합니다 이러한 확장 프로그램은 저장소와 유사한 기능을 제공합니다. 파일 I/O 및 네트워크 전송과 같은 작업을 수행할 수 있도록 합니다. 있습니다 무엇보다도 Bazel이 다른 패키지와 상호작용할 수 있도록 해 줍니다. 관리 시스템을 유지하면서 Bazel을 기반으로 빌드된 종속 항목 그래프를 준수함 모듈을 마칩니다

WORKSPACE로 저장소 정의

이전에는 WORKSPACE (또는 WORKSPACE.bazel) 파일. 이 파일의 구문은 다음과 유사합니다. BUILD 파일: 빌드 규칙 대신 저장소 규칙을 사용합니다.

다음 스니펫은 http_archive repo 규칙을 WORKSPACE 파일:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "foo",
    urls = ["https://example.com/foo.zip"],
    sha256 = "c9526390a7cd420fdcec2988b4f3626fe9c5b51e2959f685e8f4d170d1a9bd96",
)

이 스니펫은 표준 이름이 foo인 저장소를 정의합니다. WORKSPACE에 있음 기본적으로 저장소의 표준 이름은 확인할 수 있습니다

다음에서 사용 가능한 함수의 전체 목록을 참조하세요. 파일 WORKSPACE개.

WORKSPACE 시스템의 단점

WORKSPACE 시스템이 도입된 이후 몇 년 동안 사용자는 다음과 같은 많은 고충사항이 있습니다.

  • Bazel은 종속 항목의 WORKSPACE 파일을 평가하지 않으므로 전이 종속 항목은 기본 코드의 WORKSPACE 파일에 정의되어야 합니다. repo도 제공합니다
  • 이 문제를 해결하기 위해 프로젝트에서 'deps.bzl'을 채택했습니다. 인코더-디코더 패턴에 매크로를 정의하고 WORKSPACE 파일에서 이 매크로를 호출합니다.
    • 여기에는 자체 문제가 있습니다. 매크로가 다른 .bzl 파일을 load할 수 없으므로 문제가 있습니다. 이 프로젝트에서는 프로젝트의 전이 종속 항목을 'deps' 매크로를 사용하거나 사용자가 여러 번 계층화된 'deps' 매크로가 포함되어 있습니다.
    • Bazel은 WORKSPACE 파일을 순차적으로 평가합니다. 또한 종속 항목은 URL이 있는 http_archive를 사용하여 지정됩니다. 버전 정보 즉, 신뢰할 수 있는 방법이 없으므로 다이아몬드 종속 항목의 경우 버전 확인 (A은 B 및 C B 및 C 모두 D의 서로 다른 버전에 종속됩니다.

WORKSPACE의 단점으로 인해 Bzlmod는 기존 WORKSPACE 시스템에 대한 액세스 권한 자세한 내용은 Bzlmod 이전 가이드를 참조하세요.