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을 기반으로 빌드된 종속 항목 그래프를 준수함 모듈을 마칩니다
Bzlmod의 외부 링크
- bazelbuild/예시의 Bzlmod 사용 예
- Bazel 외부 종속 항목 정비 (원본 Bzlmod 디자인 문서)
- Bzlmod에 관한 BazelCon 2021 대담
- Bzlmod에 관한 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 이전 가이드를 참조하세요.