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