작업
빌드 중에 실행할 명령어입니다. 예를 들어 아티팩트를 입력으로 받아 다른 아티팩트를 출력으로 생성하는 컴파일러를 호출하는 명령어를 들 수 있습니다. 명령줄 인수, 작업 키, 환경 변수, 선언된 입력/출력 아티팩트와 같은 메타데이터를 포함합니다.
참고: 규칙 문서
작업 캐시
실행된 작업과 생성된 출력의 매핑을 저장하는 디스크 캐시입니다. 캐시 키를 작업 키라고 합니다. Bazel의 증분 모델의 핵심 구성요소입니다. 캐시는 출력 기본 디렉터리에 저장되므로 Bazel 서버가 다시 시작되어도 유지됩니다.
작업 그래프
작업 및 이러한 작업이 읽고 생성하는 아티팩트의 메모리 내 그래프입니다. 그래프에는 소스 파일 (예: 파일 시스템)로 존재하는 아티팩트와 BUILD 파일에 언급되지 않은 생성된 중간/최종 아티팩트가 포함될 수 있습니다. 분석 단계에서 생성되고 실행 단계에서 사용됩니다.
작업 그래프 쿼리 (aquery)
빌드 작업에 대해 쿼리할 수 있는 쿼리 도구입니다. 이를 통해 빌드 규칙이 실제 작업 빌드로 어떻게 변환되는지 분석할 수 있습니다.
작업 키
작업의 캐시 키입니다. 작업 메타데이터를 기반으로 계산되며 작업에 따라 작업에서 실행할 명령어, 컴파일러 플래그, 라이브러리 위치 또는 시스템 헤더가 포함될 수 있습니다. Bazel이 개별 작업을 결정적으로 캐시하거나 무효화할 수 있도록 합니다.
분석 단계
빌드의 두 번째 단계입니다. BUILD 파일에 지정된 타겟 그래프를 처리하여 실행 단계 중에 실행할 작업의 순서를 결정하는 메모리 내 작업 그래프를 생성합니다. 이 단계에서는 규칙 구현이 평가됩니다.
아티팩트
소스 파일 또는 생성된 파일입니다. 트리 아티팩트라고 하는 파일 디렉터리일 수도 있습니다.
아티팩트는 여러 작업의 입력이 될 수 있지만 최대 한 작업에서만 생성되어야 합니다.
파일 타겟에 해당하는 아티팩트는 라벨로 주소를 지정할 수 있습니다.
관점
규칙이 종속 항목에서 추가 작업을 만드는 메커니즘입니다. 예를 들어 타겟 A가 B에 종속되는 경우 A에 B에 대한 종속 항목 가장자리를 위로 탐색하고 B에서 추가 작업을 실행하여 추가 출력 파일을 생성하고 수집하는 측면을 적용할 수 있습니다. 이러한 추가 작업은 동일한 측면이 필요한 타겟 간에 캐시되고 재사용됩니다. aspect() Starlark Build API 함수로 생성됩니다. 예를 들어 IDE의 메타데이터를 생성하고 린팅 작업을 만드는 데 사용할 수 있습니다.
참고: 측면 문서
Aspect-on-aspect
측면을 다른 측면의 결과에 적용할 수 있는 컴포지션 메커니즘입니다. 예를 들어 IDE에서 사용할 정보를 생성하는 측면은 proto에서 .java 파일을 생성하는 측면 위에 적용할 수 있습니다.
측면 A가 측면 B 위에 적용되려면 B가 provides 속성에서 광고하는 제공자가 A가 required_aspect_providers 속성에서 원하는 것과 일치해야 합니다.
속성
타겟별 빌드 정보를 표현하는 데 사용되는 규칙의 매개변수입니다.
예를 들어 srcs, deps, copts는 각각 타겟의 소스 파일, 종속 항목, 맞춤 컴파일러 옵션을 선언합니다. 특정 타겟에 사용할 수 있는 특정 속성은 규칙 유형에 따라 다릅니다.
.bazelrc
Bazel의 구성 파일로, 시작 플래그 및 명령어 플래그의 기본값을 변경하고 --config 플래그를 사용하여 Bazel 명령줄에서 함께 설정할 수 있는 공통 옵션 그룹을 정의하는 데 사용됩니다. Bazel은 여러 bazelrc 파일(시스템 전체, 워크스페이스별, 사용자별 또는 맞춤 위치)의 설정을 결합할 수 있으며, bazelrc 파일은 다른 bazelrc 파일의 설정을 가져올 수도 있습니다.
Blaze
Google 내부 버전의 Bazel입니다. Google의 모노 저장소용 기본 빌드 시스템입니다.
BUILD 파일
BUILD 파일은 Bazel에 빌드할 소프트웨어 출력물, 종속 항목, 빌드 방법을 알려주는 기본 구성 파일입니다. Bazel은 BUILD 파일을 입력으로 사용하고 이 파일을 사용하여 종속 항목 그래프를 만들고 중간 및 최종 소프트웨어 출력을 빌드하는 데 완료해야 하는 작업을 파생합니다. BUILD 파일은 BUILD 파일을 포함하지 않는 디렉터리 및 하위 디렉터리를 패키지로 표시하며 규칙으로 만든 타겟을 포함할 수 있습니다. 파일 이름은 BUILD.bazel일 수도 있습니다.
BUILD.bazel 파일
BUILD 파일을 참고하세요. 동일한 디렉터리의 BUILD 파일보다 우선 적용됩니다.
.bzl 파일
Starlark로 작성된 규칙, 매크로, 상수를 정의하는 파일입니다. 그런 다음 load() 함수를 사용하여 BUILD 파일로 가져올 수 있습니다.
그래프 빌드
Bazel이 빌드를 실행하기 위해 생성하고 탐색하는 종속 항목 그래프입니다. 타겟, 구성된 타겟, 작업, 아티팩트와 같은 노드를 포함합니다. 요청된 대상 집합이 종속되는 모든 아티팩트가 최신 상태로 확인되면 빌드가 완료된 것으로 간주됩니다.
빌드 설정
Starlark로 정의된 구성입니다. 전환은 하위 그래프의 구성을 변경하도록 빌드 설정을 설정할 수 있습니다. 사용자에게 명령줄 플래그(빌드 플래그라고도 함)로 노출되는 경우
클린 빌드
이전 빌드의 결과를 사용하지 않는 빌드입니다. 이는 일반적으로 증분 빌드보다 느리지만 일반적으로 더 올바르게 간주됩니다. Bazel은 클린 빌드와 증분 빌드가 항상 올바르다는 것을 보장합니다.
클라이언트-서버 모델
bazel 명령줄 클라이언트는 로컬 머신에서 백그라운드 서버를 자동으로 시작하여 Bazel 명령어를 실행합니다. 서버는 명령어 전반에서 유지되지만 일정 기간 활동이 없으면 자동으로 중지되며 bazel 종료를 통해 명시적으로 중지할 수도 있습니다. Bazel을 서버와 클라이언트로 분할하면 JVM 시작 시간을 분산할 수 있으며 작업 그래프가 명령어 간에 메모리에 유지되므로 더 빠른 증분 빌드를 지원할 수 있습니다.
명령어
명령줄에서 bazel
build, bazel test, bazel run, bazel query와 같은 다양한 Bazel 함수를 호출하는 데 사용됩니다.
명령어 플래그
명령어에만 적용되는 플래그 집합입니다. 명령어 플래그는 명령어 (bazel build <command flags>) 뒤에 지정됩니다. 플래그는 하나 이상의 명령어에 적용할 수 있습니다. 예를 들어 --configure는 bazel sync 명령어 전용 플래그이지만 --keep_going는 sync, build, test 등에 적용할 수 있습니다. 플래그는 구성 목적으로 자주 사용되므로 플래그 값이 변경되면 Bazel에서 메모리 내 그래프를 무효화하고 분석 단계를 다시 시작할 수 있습니다.
구성
규칙이 작업을 생성하는 방식에 영향을 미치는 규칙 정의 외부의 정보입니다. 모든 빌드에는 타겟 플랫폼, 작업 환경 변수, 명령줄 빌드 플래그를 지정하는 구성이 하나 이상 있습니다. 전환은 호스트 도구 또는 교차 컴파일과 같은 추가 구성을 만들 수 있습니다.
참고: 구성
구성 자르기
타겟에 실제로 필요한 구성 부분만 포함하는 프로세스입니다. 예를 들어 C++ 종속 항목 //:c로 Java 바이너리 //:j를 빌드하는 경우 --javacopt를 변경하면 불필요하게 C++ 빌드 캐시 가능성을 손상시키므로 //:c 구성에 --javacopt 값을 포함하는 것은 낭비입니다.
구성된 쿼리 (cquery)
분석 단계가 완료된 후 구성된 타겟에 대해 쿼리하는 쿼리 도구입니다. 즉, select() 및 빌드 플래그 (예: --platforms)가 결과에 정확하게 반영됩니다.
참고: cquery 문서
구성된 대상
구성으로 타겟을 평가한 결과입니다. 분석 단계는 빌드 옵션과 빌드해야 하는 타겟을 결합하여 이를 생성합니다.
예를 들어 //:foo가 동일한 빌드에서 두 가지 서로 다른 아키텍처용으로 빌드되는 경우 구성된 두 가지 타겟(<//:foo, x86> 및 <//:foo, arm>)이 있습니다.
정확성
빌드의 출력이 전이 입력의 상태를 충실하게 반영하는 경우 빌드가 올바른 것입니다. 올바른 빌드를 달성하기 위해 Bazel은 밀폐되고 재현 가능하며 빌드 분석 및 작업 실행을 결정론적으로 만들기 위해 노력하고 있습니다.
종속 항목
두 타겟 간의 유향 에지입니다. //:foo의 속성 값에 //:bar 참조가 포함된 경우 타겟 //:foo는 타겟 //:bar에 대한 타겟 종속 항목을 갖습니다. //:foo의 작업이 //:bar의 작업에서 만든 입력 아티팩트에 종속되는 경우 //:foo에는 //:bar에 대한 작업 종속 항목이 있습니다.
특정 맥락에서는 외부 종속 항목을 참조할 수도 있습니다. 모듈을 참고하세요.
Depset
전이 종속 항목에 관한 데이터를 수집하기 위한 데이터 구조입니다. 매우 큰 depset (수십만 개의 파일)이 있는 경우가 많으므로 depset 병합이 시간과 공간을 효율적으로 사용할 수 있도록 최적화되었습니다. 공간 효율성 때문에 다른 depset을 재귀적으로 참조하도록 구현되었습니다. 규칙 구현은 규칙이 빌드 그래프의 최상위 수준에 있지 않는 한 depset을 목록으로 변환하여 '평면화'해서는 안 됩니다. 대규모 depset을 평탄화하면 메모리 사용량이 엄청나게 증가합니다. Bazel의 내부 구현에서는 중첩 세트라고도 합니다.
참고: Depset 문서
디스크 캐시
원격 캐싱 기능을 위한 로컬 디스크 기반 blob 저장소입니다. 실제 원격 blob 저장소와 함께 사용할 수 있습니다.
Distdir
Bazel이 저장소 규칙을 사용하여 인터넷에서 가져오는 파일이 포함된 읽기 전용 디렉터리입니다. 빌드가 완전히 오프라인으로 실행되도록 합니다.
동적 실행
다양한 휴리스틱에 따라 로컬 실행과 원격 실행 중에서 선택하고 더 빠르게 성공한 메서드의 실행 결과를 사용하는 실행 전략입니다. 특정 작업은 로컬에서 더 빠르게 실행되고 (예: 연결) 다른 작업은 원격에서 더 빠르게 실행됩니다 (예: 고도로 병렬화 가능한 컴파일). 동적 실행 전략은 가능한 한 최적의 증분 및 깔끔한 빌드 시간을 제공할 수 있습니다.
실행 단계
빌드의 세 번째 단계입니다. 분석 단계 중에 생성된 작업 그래프에서 작업을 실행합니다. 이러한 작업은 실행 파일 (컴파일러, 스크립트)을 호출하여 아티팩트를 읽고 씁니다. 스패닝 전략은 이러한 작업이 실행되는 방식(로컬, 원격, 동적, 샌드박스, 도커 등)을 제어합니다.
실행 루트
작업공간의 출력 기본 디렉터리에 있는 디렉터리로, 샌드박스 처리되지 않은 빌드에서 로컬 작업이 실행됩니다. 디렉터리 콘텐츠는 대부분 워크스페이스의 입력 아티팩트의 심볼릭 링크입니다. 실행 루트에는 다른 입력으로서 외부 저장소에 대한 심볼릭 링크와 출력을 저장하는 bazel-out 디렉터리도 포함됩니다. 빌드가 종속되는 패키지의 전이 종료를 나타내는 디렉터리의 심볼릭 링크 포리스트를 만들어 로드 단계에서 준비됩니다. 명령줄에서 bazel info
execution_root를 사용하여 액세스할 수 있습니다.
파일
아티팩트를 참고하세요.
Hermeticity
빌드 및 테스트 작업에 외부 영향이 없는 경우 빌드는 견고하며, 이는 결과가 확정적이면서 정확한지 확인하는 데 도움이 됩니다. 예를 들어 격리된 빌드는 일반적으로 작업에 대한 네트워크 액세스를 허용하지 않고, 선언된 입력에 대한 액세스를 제한하며, 고정 타임스탬프 및 시간대를 사용하고, 환경 변수에 대한 액세스를 제한하며, 랜덤 숫자 생성기에 고정 시드를 사용합니다.
증분 빌드
증분 빌드는 이전 빌드의 결과를 재사용하여 빌드 시간과 리소스 사용량을 줄입니다. 종속 항목 확인 및 캐싱은 이러한 유형의 빌드에 올바른 결과를 생성하는 것을 목표로 합니다. 증분 빌드는 클린 빌드와 반대입니다.
라벨
타겟의 식별자입니다. 일반적으로 @repo//path/to/package:target 형식입니다. 여기서 repo는 타겟이 포함된 저장소의 (표시된) 이름이고, path/to/package는 타겟을 선언하는 BUILD 파일이 포함된 디렉터리의 경로입니다 (이 디렉터리는 패키지라고도 함). target는 타겟 자체의 이름입니다. 상황에 따라 이 문법의 일부가 생략될 수 있습니다.
참고: 라벨
로드 단계
Bazel이 BUILD 파일을 실행하여 패키지를 만드는 빌드의 첫 번째 단계입니다. 매크로 및 glob()와 같은 특정 함수는 이 단계에서 평가됩니다. 빌드의 두 번째 단계인 분석 단계와 교차하여 타겟 그래프를 빌드합니다.
Macro
단일 Starlark 함수 아래에서 여러 규칙 타겟 선언을 함께 컴포지션하는 메커니즘입니다. BUILD 파일에서 공통 규칙 선언 패턴을 재사용할 수 있습니다. 로드 단계 중에 기본 규칙 타겟 선언으로 확장됩니다.
참고: 매크로 문서
니모닉
규칙 작성자가 규칙의 작업이 하는 일을 빠르게 파악할 수 있도록 선택한 사람이 읽을 수 있는 짧은 문자열입니다. Mnemonic은 스폰 전략 선택의 식별자로 사용할 수 있습니다. 작업 니모닉의 예로는 Java 규칙의 Javac, C++ 규칙의 CppCompile, Android 규칙의 AndroidManifestMerger 등이 있습니다.
모듈
버전이 여러 개 있을 수 있으며 각 버전이 다른 모듈에 종속될 수 있는 Bazel 프로젝트입니다. 이는 Maven 아티팩트, npm 패키지, Go 모듈, Cargo 크레이트와 같은 다른 종속 항목 관리 시스템의 익숙한 개념과 유사합니다. 모듈은 Bazel의 외부 종속 항목 관리 시스템의 핵심입니다.
각 모듈은 루트에 MODULE.bazel 파일이 있는 repo에서 지원됩니다. 이 파일에는 모듈 자체에 관한 메타데이터 (예: 이름 및 버전), 직접 종속 항목, 도구 모음 등록 및 모듈 확장 입력을 비롯한 기타 다양한 데이터가 포함됩니다.
모듈 메타데이터는 Bazel 레지스트리에 호스팅됩니다.
참고: Bazel 모듈
모듈 확장
모듈 종속 항목 그래프에서 입력을 읽고 저장소 규칙을 호출하여 repos를 생성하는 데 실행할 수 있는 로직입니다. 모듈 확장 프로그램에는 저장소 규칙과 유사한 기능이 있어 인터넷에 액세스하고 파일 I/O를 실행하는 등의 작업을 할 수 있습니다.
참고: 모듈 확장 프로그램
네이티브 규칙
Bazel에 빌드되고 Java로 구현된 규칙입니다. 이러한 규칙은 네이티브 모듈 (예: native.cc_library 또는 native.java_library)의 함수로 .bzl 파일에 표시됩니다. 사용자 정의 규칙(비네이티브)은 Starlark를 사용하여 만들어집니다.
출력 베이스
Bazel 출력 파일을 저장하는 작업공간별 디렉터리입니다. 작업공간의 소스 트리 (기본 저장소)에서 출력을 분리하는 데 사용됩니다. 출력 사용자 루트에 있습니다.
출력 그룹
Bazel에서 타겟 빌드를 완료할 때 빌드될 것으로 예상되는 파일 그룹입니다. 규칙은 일반적인 출력을 '기본 출력 그룹'에 배치합니다(예: cc_library 타겟의 java_library, .a, .so의 .jar 파일). 기본 출력 그룹은 명령줄에서 타겟이 요청될 때 빌드되는 아티팩트가 있는 출력 그룹입니다.
규칙은 BUILD 파일 (filegroup 규칙) 또는 명령줄(--output_groups 플래그)에서 명시적으로 지정할 수 있는 더 많은 이름이 지정된 출력 그룹을 정의할 수 있습니다.
사용자 루트 출력
Bazel의 출력을 저장하는 사용자별 디렉터리입니다. 디렉터리 이름은 사용자의 시스템 사용자 이름에서 파생됩니다. 여러 사용자가 시스템에서 동시에 동일한 프로젝트를 빌드하는 경우 출력 파일 충돌을 방지합니다. 개별 작업공간의 빌드 출력(출력 기반이라고도 함)에 해당하는 하위 디렉터리를 포함합니다.
패키지
BUILD 파일에 의해 정의된 타겟 집합입니다. 패키지 이름은 repo 루트를 기준으로 한 BUILD 파일의 경로입니다. 패키지에는 하위 패키지 또는 BUILD 파일이 포함된 하위 디렉터리가 포함될 수 있으므로 패키지 계층 구조가 형성됩니다.
패키지 그룹
패키지 집합을 나타내는 타겟입니다. visibility 속성 값에 자주 사용됩니다.
플랫폼
빌드에 참여하는 '머신 유형'입니다. 여기에는 Bazel이 실행되는 머신('호스트' 플랫폼), 머신 빌드 도구가 실행되는 플랫폼 ('exec' 플랫폼), 머신 타겟이 빌드되는 플랫폼 ('타겟 플랫폼')이 포함됩니다.
제공업체
종속 항목 관계를 따라 규칙 타겟 간에 전달할 정보 단위를 설명하는 스키마입니다. 일반적으로 여기에는 컴파일러 옵션, 전이 소스 또는 출력 파일, 빌드 메타데이터와 같은 정보가 포함됩니다. 누적된 전이 데이터를 효율적으로 저장하기 위해 depsets와 함께 자주 사용됩니다. 내장된 제공자의 예는 DefaultInfo입니다.
참고: 제공업체 문서
쿼리 (개념)
빌드 그래프를 분석하여 타겟 속성과 종속 항목 구조를 이해하는 프로세스입니다. Bazel은 query, cquery, aquery라는 세 가지 쿼리 변형을 지원합니다.
query (명령어)
빌드의 로드 후 단계 타겟 그래프에서 작동하는 쿼리 도구입니다. 이 방법은 비교적 빠르지만 select(), 빌드 플래그, 아티팩트 또는 빌드 작업의 영향을 분석할 수 없습니다.
저장소
Bazel 빌드에 사용할 수 있는 소스 파일이 포함되어 있고 루트에 경계 마커 파일이 있는 디렉터리 트리입니다. repo로 줄여서 부르는 경우가 많습니다.
저장소 경계 마커 파일은 MODULE.bazel (이 저장소가 Bazel 모듈을 나타냄을 나타냄), REPO.bazel 또는 기존 컨텍스트에서는 WORKSPACE 또는 WORKSPACE.bazel일 수 있습니다. 모든 저장소 경계 마커 파일은 저장소의 경계를 나타냅니다. 이러한 파일은 디렉터리에 여러 개 공존할 수 있습니다.
기본 저장소는 현재 Bazel 명령어가 실행 중인 저장소입니다.
외부 저장소는 MODULE.bazel 파일에서 모듈을 지정하거나 모듈 확장 프로그램에서 저장소 규칙을 호출하여 정의됩니다. 이러한 파일은 디스크의 사전 지정된 '마법의' 위치에 필요에 따라 가져올 수 있습니다.
각 저장소에는 고유한 상수 표준 이름이 있으며 다른 저장소에서 볼 때 표시되는 이름이 다를 수 있습니다.
참고: 외부 종속 항목 개요
저장소 캐시
Bazel에서 빌드용으로 다운로드한 파일의 공유 콘텐츠 주소 지정 가능 캐시로, 작업공간 간에 공유할 수 있습니다. 초기 다운로드 후 오프라인 빌드를 사용 설정합니다. 일반적으로 http_archive와 같은 저장소 규칙 및 repository_ctx.download와 같은 저장소 규칙 API를 통해 다운로드된 파일을 캐시하는 데 사용됩니다. 파일은 다운로드에 SHA-256 체크섬이 지정된 경우에만 캐시됩니다.
저장소 규칙
Bazel에 저장소를 구체화 (또는 '가져오기')하는 방법을 알려주는 저장소 정의의 스키마입니다. repo rule로 줄여서 부르는 경우가 많습니다.
저장소 규칙은 Bazel에서 내부적으로 호출하여 모듈로 지원되는 저장소를 정의하거나 모듈 확장 프로그램에서 호출할 수 있습니다.
저장소 규칙은 인터넷에 액세스하거나 파일 I/O를 실행할 수 있습니다. 가장 일반적인 저장소 규칙은 인터넷에서 소스 파일이 포함된 보관 파일을 다운로드하는 http_archive입니다.
참고: 저장소 규칙 문서
재현성
빌드 또는 테스트의 입력 세트가 시간, 메서드, 환경과 관계없이 항상 동일한 출력 세트를 생성한다는 빌드 또는 테스트의 속성입니다. 그렇다고 해서 출력이 올바르다거나 원하는 출력이라는 의미는 아닙니다.
규칙
cc_library와 같이 BUILD 파일에서 규칙 타겟을 정의하기 위한 스키마입니다. BUILD 파일 작성자의 관점에서 규칙은 속성 집합과 블랙박스 로직으로 구성됩니다. 로직은 규칙 타겟에 출력 아티팩트를 생성하고 다른 규칙 타겟에 정보를 전달하는 방법을 알려줍니다. .bzl 작성자의 관점에서 규칙은 Bazel을 확장하여 새로운 프로그래밍 언어와 환경을 지원하는 기본적인 방법입니다.
규칙은 로드 단계에서 규칙 타겟을 생성하도록 인스턴스화됩니다. 분석 단계에서 규칙 타겟은 제공자의 형태로 다운스트림 종속 항목에 정보를 전달하고 출력 아티팩트를 생성하는 방법을 설명하는 작업을 등록합니다. 이러한 작업은 실행 단계에서 실행됩니다.
참고: 규칙 문서
규칙 타겟
규칙의 인스턴스인 타겟입니다. 파일 타겟 및 패키지 그룹과는 대조됩니다. 규칙과 혼동하지 마세요.
Runfiles
실행 파일 타겟의 런타임 종속 항목입니다. 일반적으로 실행 파일은 테스트 규칙의 실행 파일 출력이며, 런파일은 테스트의 런타임 데이터 종속 항목입니다. 실행 파일을 호출하기 전에 (bazel 테스트 중에) Bazel은 소스 디렉터리 구조에 따라 테스트 실행 파일과 함께 runfile 트리를 준비합니다.
참고: Runfiles 문서
샌드박스 기능
제한된 임시 실행 루트 내에서 실행 중인 작업을 격리하는 기법으로, 선언되지 않은 입력을 읽거나 선언되지 않은 출력을 쓰지 않도록 합니다. 샌드박스는 기밀 유지를 크게 개선하지만 일반적으로 성능 비용이 발생하며 운영체제의 지원이 필요합니다. 성능 비용은 플랫폼에 따라 다릅니다. Linux에서는 중요하지 않지만 macOS에서는 샌드박스를 사용할 수 없게 만들 수 있습니다.
Skyframe
Skyframe은 Bazel의 핵심적인 병렬, 기능, 점진적 평가 프레임워크입니다.
스탬핑
Bazel로 빌드된 아티팩트에 추가 정보를 삽입하는 기능입니다. 예를 들어 소스 제어, 빌드 시간, 출시 빌드의 기타 워크스페이스 또는 환경 관련 정보에 사용할 수 있습니다.
스탬프 속성을 지원하는 --workspace_status_command 플래그 및 규칙을 통해 사용 설정합니다.
Starlark
규칙 및 매크로를 작성하기 위한 확장 프로그램 언어입니다. 구성 및 성능 향상을 목적으로 하는 (문법적으로 제한된) Python의 제한된 하위 집합입니다. .bzl 파일 확장자를 사용합니다. BUILD 파일은 이전에 Skylark라고 했던 훨씬 더 제한된 버전의 Starlark (예: def 함수 정의 없음)를 사용합니다.
참고: Starlark 언어 문서
시작 플래그
bazel와 명령어 사이에 지정된 플래그 세트입니다(예: bazel --host_jvm_debug build). 이러한 플래그는 Bazel 서버의 구성을 수정하므로 시작 플래그를 수정하면 서버가 다시 시작됩니다. 시작 플래그는 특정 명령어에만 국한되지 않습니다.
타겟
BUILD 파일에 정의되고 라벨로 식별되는 객체입니다. 타겟은 최종 사용자의 관점에서 워크스페이스의 빌드 가능한 단위를 나타냅니다.
규칙을 인스턴스화하여 선언된 타겟을 규칙 타겟이라고 합니다. 규칙에 따라 실행 가능 (예: cc_binary)하거나 테스트 가능 (예: cc_test)할 수 있습니다. 규칙 타겟은 일반적으로 속성 (예: deps)을 통해 다른 타겟에 종속됩니다. 이러한 종속 항목은 타겟 그래프의 기반을 형성합니다.
규칙 타겟 외에도 파일 타겟과 패키지 그룹 타겟이 있습니다. 파일 타겟은 BUILD 파일 내에서 참조되는 아티팩트에 해당합니다. 특수한 경우로, 모든 패키지의 BUILD 파일은 항상 해당 패키지의 소스 파일 타겟으로 간주됩니다.
타겟은 로드 단계 중에 발견됩니다. 분석 단계에서 타겟은 빌드 구성과 연결되어 구성된 타겟을 형성합니다.
타겟 그래프
타겟 및 종속 항목의 메모리 내 그래프입니다. 로드 단계 중에 생성되며 분석 단계의 입력으로 사용됩니다.
타겟 패턴
명령줄에서 타겟 그룹을 지정하는 방법입니다. 일반적으로 사용되는 패턴은 :all (모든 규칙 대상), :* (모든 규칙 + 파일 대상), ... (현재 패키지 및 모든 하위 패키지 재귀적으로)입니다. 조합하여 사용할 수 있습니다. 예를 들어 //...:*는 작업공간의 루트에서 모든 패키지의 모든 규칙 및 파일 타겟을 재귀적으로 나타냅니다.
테스트
테스트 규칙에서 인스턴스화된 규칙 타겟이므로 테스트 실행 파일이 포함됩니다. 실행 파일 완료 시 반환 코드가 0이면 테스트가 성공한 것입니다. Bazel과 테스트 간의 정확한 계약 (예: 테스트 환경 변수, 테스트 결과 수집 메서드)은 테스트 백과사전에 지정되어 있습니다.
도구 모음
언어의 출력을 빌드하는 도구 모음입니다. 일반적으로 도구 모음에는 컴파일러, 링커, 인터프리터 또는 린터가 포함됩니다. 도구 모음은 플랫폼에 따라 다를 수도 있습니다. 즉, 도구 모음이 동일한 언어용이지만 Unix 컴파일러 도구 모음의 구성요소는 Windows 변형에 따라 다를 수 있습니다. 플랫폼에 적합한 도구 모음을 선택하는 것을 도구 모음 확인이라고 합니다.
최상위 타겟
빌드 타겟은 Bazel 명령줄에서 요청된 경우 최상위입니다. 예를 들어 //:foo가 //:bar에 종속되고 bazel build //:foo가 호출되는 경우 이 빌드에서 //:foo는 최상위 수준이고 //:bar는 최상위 수준이 아닙니다. 두 타겟 모두 빌드해야 하지만 최상위 타겟과 최상위가 아닌 타겟의 중요한 차이점은 Bazel 명령줄 (또는 .bazelrc를 통해)에 설정된 명령어 플래그가 최상위 타겟의 구성을 설정하지만 최상위가 아닌 타겟의 경우 전환에 의해 수정될 수 있다는 점입니다.
전환
한 값에서 다른 값으로의 구성 상태 매핑입니다. 동일한 규칙에서 인스턴스화되었더라도 빌드 그래프의 타겟이 서로 다른 구성을 가질 수 있도록 합니다. 전환의 일반적인 사용 사례는 분할 전환으로, 여기서 타겟 그래프의 특정 부분이 각 포크에 대해 고유한 구성으로 포크됩니다. 예를 들어 단일 빌드에서 분할 전환을 사용하여 ARM 및 x86용으로 컴파일된 네이티브 바이너리로 Android APK를 빌드할 수 있습니다.
참고: 사용자 정의 전환
트리 아티팩트
파일 모음을 나타내는 아티팩트입니다. 이러한 파일은 아티팩트가 아니므로 이러한 파일에서 작업하는 작업은 대신 트리 아티팩트를 입력 또는 출력으로 등록해야 합니다.
공개 상태
빌드 시스템에서 원치 않는 종속 항목을 방지하기 위한 두 가지 메커니즘 중 하나입니다. 타겟이 다른 타겟에서 종속될 수 있는지 여부를 제어하는 타겟 공개 상태와 BUILD 또는 .bzl 파일이 지정된 .bzl 파일을 로드할 수 있는지 여부를 제어하는 로드 공개 상태입니다. 일반적으로 맥락이 없는 '표시'는 타겟 표시를 의미합니다.
참고: 표시 문서
작업공간
모든 Bazel 명령어에서 공유하는 환경은 동일한 기본 저장소에서 실행됩니다.
이전에는 '저장소'와 '워크스페이스' 개념이 혼동되었습니다. '워크스페이스'라는 용어는 기본 저장소를 지칭하는 데 자주 사용되었으며 '저장소'의 동의어로 사용되기도 했습니다. 명확성을 위해 이러한 사용은 피해야 합니다.