BazelCon 2022는 11월 16~17일에 뉴욕과 온라인에서 개최됩니다.
지금 등록하기

Bazel 용어집

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

작업

빌드 중에 실행할 명령어(예: 아티팩트를 입력으로 사용하고 다른 아티팩트를 출력으로 생성하는 컴파일러에 대한 호출) 명령줄 인수, 작업 키, 환경 변수, 선언된 입력/출력 아티팩트와 같은 메타데이터를 포함합니다.

참고 항목: 규칙 문서

작업 캐시

실행된 작업의 매핑 결과를 사용자가 만든 출력에 저장하는 디스크 상의 캐시입니다. 캐시 키는 작업 키라고 합니다. Bazel의 성과 증분 모델을 위한 핵심 구성요소입니다. 캐시는 출력 기본 디렉터리에 저장되므로 Bazel 서버 재시작 시에도 유지됩니다.

작업 그래프

이러한 작업이 읽고 생성하는 작업아티팩트의 메모리 내 그래프 그래프에는 소스 파일 (예: 파일 시스템)로 존재하는 아티팩트와 BUILD 파일에서 언급되지 않은 생성된 중간/최종 아티팩트가 포함될 수 있습니다. 분석 단계 중에 생성되고 실행 단계에서 사용됩니다.

작업 그래프 쿼리 (쿼리)

빌드 작업을 쿼리할 수 있는 쿼리 도구 이를 통해 빌드 규칙이 실제 작업 빌드로 변환되는 방식을 분석할 수 있습니다.

작업 키

작업의 캐시 키입니다. 작업에 따라 실행할 명령어, 컴파일러 플래그, 라이브러리 위치 또는 시스템 헤더에 포함될 수 있는 작업 메타데이터를 기반으로 계산됩니다. Bazel이 확정적으로 개별 작업을 캐시하거나 무효화할 수 있도록 합니다.

분석 단계

빌드의 두 번째 단계입니다. BUILD 파일에 지정된 타겟 그래프를 처리하여 실행 단계에서 실행할 작업의 순서를 결정하는 메모리 내 작업 그래프를 생성합니다. 규칙 구현이 평가되는 단계입니다.

아티팩트

소스 파일 또는 생성된 파일 'quot;tree아티팩트"'라고도 하는 파일 디렉터리일 수 있습니다. 트리 아티팩트는 Bazel의 블랙박스입니다. Bazel은 트리 아티팩트의 파일을 개별 아티팩트로 취급하지 않으므로 작업 입력 / 출력으로 직접 참조할 수 없습니다. 아티팩트는 여러 작업의 입력일 수 있지만 최대 1개의 작업으로만 생성되어야 합니다.

방향

규칙의 종속 항목에 추가 작업을 만드는 메커니즘입니다. 예를 들어 타겟 A가 B에 종속되면 종속 항목 가장자리를 로 순회하는 A에 가로세로 방향을 적용하고 B에서 추가 작업을 실행하여 추가 출력 파일을 생성하고 수집할 수 있습니다. 이러한 추가 작업은 동일한 측면이 필요한 대상 간에 캐시 및 재사용됩니다. aspect() Starlark Build API 함수로 생성되었습니다. 예를 들어 IDE용 메타데이터를 생성하고 린트 작업을 만드는 데 사용할 수 있습니다.

참고 항목: 변수 문서

관점

가로세로 구성 메커니즘. 다른 측면에 적용할 수 있는 요소 측면 A에서 가로세로 B를 검사하려면 가로세로 A에서 가로세로 B에서 필요한 제공자 (required_aspect_providers 속성 사용)를 선언해야 하며, 가로세로 B에서 반환되는 제공자 (provides 속성 사용)를 선언해야 합니다. 예를 들어 이 속성을 IDE 측면에 사용하여 java_proto_library 측면과 같은 측면에 의해 생성된 정보를 사용하여 파일을 생성할 수 있습니다.

.bazelrc

시작 플래그명령어 플래그의 기본값을 변경하고 --config 플래그를 사용하여 Bazel 명령줄에서 함께 설정할 수 있는 공통 옵션 그룹을 정의하는 데 사용되는 Bazel의 구성 파일입니다. Bazel은 여러 bazelrc 파일(시스템 전체, 작업공간별, 사용자당 또는 맞춤 위치)의 설정을 결합할 수 있으며 bazelrc 파일을 다른 bazelrc 파일에서 설정을 가져올 수도 있습니다.

Blaze

Bazel의 Google 내부 버전입니다. 모노 저장소용 Google의 기본 빌드 시스템입니다.

빌드 파일

BUILD 파일은 Bazel에 빌드할 소프트웨어 출력, 종속 항목, 빌드 방법을 알려주는 기본 구성 파일입니다. Bazel은 BUILD 파일을 입력으로 사용하고 이 파일을 사용하여 종속 항목 그래프를 만들고 중간 및 최종 소프트웨어 출력을 빌드하기 위해 완료해야 하는 작업을 파생합니다. BUILD 파일은 디렉터리와 BUILD 파일을 포함하지 않는 모든 하위 디렉터리를 package로 표시하며, 규칙에 의해 생성된 대상을 포함할 수 있습니다. 파일의 이름은 BUILD.bazel로 지정할 수도 있습니다.

BUILD.bazel 파일

BUILD 파일을 참고하세요. 같은 디렉터리에 있는 BUILD 파일보다 우선합니다.

.bzl 파일

Starlark로 작성된 규칙, 매크로 및 상수를 정의하는 파일입니다. 그런 다음 load() 함수를 사용하여 BUILD 파일로 가져올 수 있습니다.

빌드 그래프

Bazel이 빌드를 실행하기 위해 구성하고 순회하는 종속 항목 그래프입니다. 대상, 구성된 대상, 작업, 아티팩트와 같은 노드를 포함합니다. 요청된 타겟 집합이 종속된 모든 아티팩트가 최신으로 확인되면 빌드가 완료된 것으로 간주됩니다.

빌드 설정

Starlark에서 정의한 구성 전환을 통해 하위 설정을 구성하여 빌드 구성을 변경할 수 있습니다. 사용자에게 명령줄 플래그로 노출되는 경우 빌드 플래그라고도 합니다.

클린 빌드

이전 빌드의 결과를 사용하지 않는 빌드입니다. 일반적으로 증분 빌드보다 느리지만 일반적으로 정확한 것으로 간주됩니다. Bazel은 클린 빌드와 증분 빌드가 항상 정확하도록 보장합니다.

클라이언트-서버 모델

bazel 명령줄 클라이언트는 Bazel 명령어를 실행하기 위해 로컬 머신에서 자동으로 백그라운드 서버를 시작합니다. 서버는 여러 명령어에 걸쳐 유지되지만 일정 기간 (또는 azel 종료를 통해 명시적으로)을 사용하지 않으면 자동으로 중지됩니다. Bazel을 서버 및 클라이언트로 분할하면 JVM 시작 시간을 분할하고 작업 그래프가 명령어 간에 메모리에 남아 있으므로 더 빠르게 증분 빌드를 지원할 수 있습니다.

명령어

명령줄에서 bazel build, bazel test, bazel run, bazel query와 같은 다양한 Bazel 함수를 호출하는 데 사용됩니다.

명령어 플래그

명령어와 관련된 플래그 집합입니다. 명령어 플래그는 명령어 bazel build <command flags> 다음에 지정됩니다. 플래그는 하나 이상의 명령어에 적용할 수 있습니다. 예를 들어 --configurebazel sync 명령어 전용 플래그이지만 --keep_goingsync, build, test 등에 적용할 수 있습니다. 플래그는 구성 목적으로 사용되는 경우가 많으므로 플래그 값을 변경하면 Bazel에서 메모리 내 그래프를 무효화하고 분석 단계를 다시 시작할 수 있습니다.

구성

규칙 정의 외의 정보로 규칙이 작업을 생성하는 방식에 영향을 줍니다. 모든 빌드에는 대상 플랫폼, 작업 환경 변수, 명령줄 빌드 플래그를 지정하는 구성이 하나 이상 있습니다. 전환을 통해 호스트 도구나 크로스 컴파일과 같은 추가 구성을 만들 수 있습니다.

참고 항목: 구성

구성 자르기

타겟에 실제로 필요한 구성만 포함하는 프로세스입니다. 예를 들어 C++ 종속 항목 //:c을 사용하여 자바 바이너리 //:j를 빌드하면 --javacopt를 변경하면 C++ 빌드 캐시 기능이 불필요하게 중단되므로 //:c의 구성에 --javacopt 값을 포함하는 것은 낭비입니다.

구성된 쿼리 (cquery)

분석 대상(분석 단계가 완료된 후)을 쿼리하는 쿼리 도구 즉, select()빌드 플래그 (예: --platforms)가 결과에 정확하게 반영됩니다.

참고 항목: 쿼리 문서

구성된 대상

구성으로 대상을 평가한 결과 이를 위해 분석 단계에서 빌드해야 하는 대상과 빌드 옵션을 결합합니다. 예를 들어 //:foo가 동일한 빌드에서 서로 다른 두 아키텍처에 대해 빌드되면 <//:foo, x86><//:foo, arm>라는 두 개의 대상이 구성됩니다.

정확성

빌드가 전이 입력의 상태를 충실하게 반영하는 경우 빌드는 정확합니다. 정확한 빌드를 위해 Bazel은 밀폐하고 재현하며 빌드 분석작업 실행을 확정할 수 있도록 노력합니다.

종속 항목

타겟 간의 방향 가장자리입니다. //:foo의 속성 값에 //:bar 참조가 포함되어 있으면 타겟 //:foo는 타겟 //:bar타겟 종속 항목이 있습니다. //:foo의 작업이 //:bar의 작업에서 생성된 입력 아티팩트에 종속되는 경우 //:foo//:bar작업 종속 항목이 있습니다.

디셋

전이 종속 항목에 대한 데이터를 수집하기 위한 데이터 구조 매우 큰 Depset (수십만 개의 파일)이 있는 경우가 많기 때문에 Depset 병합이 시간과 공간 효율을 높이도록 최적화되었습니다. 공간 효율성을 위해 다른 디핑을 반복적으로 참조하도록 구현되었습니다. 규칙 구현은 규칙이 빌드 그래프의 최상위 수준에 있지 않는 한 목록을 변환하여 디플렉스하여 평탄화하지 않아야 합니다. 큰 디셋을 평면화하면 메모리가 많이 소비됩니다. Bazel의 내부 구현에서 중첩된 세트라고도 합니다.

참고 항목: Depset 문서

디스크 캐시

원격 캐싱 기능을 위한 로컬 디스크 blob 저장소 실제 원격 blob 저장소와 함께 사용할 수 있습니다.

디스디르

Bazel이 저장소 규칙을 사용하여 인터넷에서 가져오는 파일이 포함된 읽기 전용 디렉터리입니다. 빌드를 완전히 오프라인으로 실행할 수 있게 합니다.

동적 실행

다양한 휴리스틱에 따라 로컬 실행과 원격 실행 중 하나를 선택하고 더 빠르게 성공한 메서드의 실행 결과를 사용하는 실행 전략입니다. 일부 작업은 로컬에서 더 빠르게 실행되며 (예: 링크) 원격으로 더 빠르게 실행되는 작업 및 (예: 매우 병렬화된 컴파일) 작업도 있습니다. 동적 실행 전략은 가능한 한 증분 및 클린 빌드 시간을 제공할 수 있습니다.

실행 단계

빌드의 세 번째 단계입니다. 분석 단계 중에 생성된 작업 그래프작업을 실행합니다. 이러한 작업은 실행 파일 (컴파일러, 스크립트)을 호출하여 아티팩트를 읽고 씁니다. 생성된 전략은 로컬, 원격, 동적, 샌드박스, Docker 등 이러한 작업의 실행 방식을 제어합니다.

실행 루트

샌드박스 빌드에서 로컬 작업이 실행되는 작업공간출력 기본 디렉터리에 있는 디렉터리 디렉터리 콘텐츠는 대부분 작업공간의 입력 아티팩트의 심볼릭 링크입니다. 실행 루트에는 외부 저장소의 심볼릭 링크가 다른 입력으로 저장되고 출력을 저장할 bazel-out 디렉터리도 포함되어 있습니다. 빌드가 종속된 패키지의 전이적 종료를 나타내는 디렉터리의 심볼릭 포레스트를 생성하여 로드 단계 중에 준비됩니다. 명령줄에서 bazel info execution_root으로 액세스할 수 있습니다.

파일

아티팩트를 참고하세요.

밀폐

빌드는 테스트 작업과 테스트 작업에 외부 영향을 미치지 않으면 밀폐형입니다. 이를 통해 결과가 확정적이고 올바른지 확인할 수 있습니다. 예를 들어 밀폐 빌드는 일반적으로 작업에 대한 네트워크 액세스를 금지하고, 선언된 입력에 대한 액세스를 제한하며, 고정된 타임스탬프 및 시간대를 사용하고, 환경 변수에 대한 액세스를 제한하며, 랜덤 숫자 생성기에 고정 시드를 사용합니다.

증분 빌드

증분 빌드는 빌드 시간과 리소스 사용을 줄이기 위해 이전 빌드의 결과를 재사용합니다. 종속 항목 확인 및 캐싱은 이러한 유형의 빌드에 관한 정확한 결과를 생성하는 것을 목표로 합니다. 증분 빌드는 클린 빌드와 반대입니다.

라벨

대상의 식별자입니다. //path/to/package:target과 같은 정규화된 라벨은 작업공간 루트 디렉터리를 표시하고, path/to/package는 타겟을 선언하는 BUILD 파일이 포함된 디렉터리로, :target는 앞서 언급한 BUILD 파일에 선언된 대상 이름으로 구성됩니다. 타겟이 my_repository라는 [외부 저장소]에 선언되었음을 나타내기 위해 @my_repository//<..> 접두어를 추가할 수도 있습니다.

로드 단계

Bazel이 WORKSPACE, BUILD, .bzl 파일을 파싱하여 패키지를 만드는 빌드의 첫 번째 단계입니다. 매크로glob()와 같은 특정 함수는 이 단계에서 평가됩니다. 빌드의 두 번째 단계인 분석 단계로 인터리브 처리되어 타겟 그래프를 빌드합니다.

Macro

단일 Starlark 함수 아래에 여러 규칙 타겟 선언을 함께 구성하는 메커니즘 BUILD 파일에서 공통 규칙 선언 패턴을 재사용할 수 있습니다. 로드 단계 중에 기본 규칙 타겟 선언으로 확장됩니다.

참고 항목: 매크로 문서

니모닉

규칙 작성자가 사람이 읽을 수 있는 짧은 문자열로 규칙의 작업이 하는 작업을 빠르게 파악합니다. 중성어는 분산 전략 선택의 식별자로 사용할 수 있습니다. 액션 연상 문자의 예로는 자바 규칙의 Javac, C++ 규칙의 CppCompile, Android 규칙의 AndroidManifestMerger가 있습니다.

네이티브 규칙

Bazel에 기본 제공되어 자바로 구현된 규칙 이러한 규칙은 .bzl 파일에 네이티브 모듈의 함수 (예: native.cc_library 또는 native.java_library)로 표시됩니다. 사용자 정의 규칙(비 네이티브)은 Starlark를 사용하여 생성됩니다.

출력 기반

Bazel 출력 파일을 저장할 작업공간별 디렉터리입니다. 작업공간의 소스 트리에서 출력을 분리하는 데 사용됩니다. 출력 사용자 루트에 있습니다.

출력 그룹

Bazel이 대상 빌드를 완료할 때 빌드될 것으로 예상되는 파일 그룹입니다. 규칙은 일반적인 출력을 '기본 출력 그룹'(예: cc_library 타겟의 java_library, .a, .so.jar 파일)에 넣습니다. 기본 출력 그룹은 명령줄에서 대상이 요청될 때 아티팩트가 빌드된 출력 그룹입니다. 규칙은 BUILD 파일 (filegroup 규칙) 또는 명령줄(--output_groups 플래그)에서 명시적으로 지정할 수 있는 이름이 지정된 출력 그룹을 더 정의할 수 있습니다.

출력 사용자 루트

Bazel의 출력을 저장할 사용자별 디렉터리입니다. 디렉터리 이름은 사용자의 시스템 사용자 이름에서 파생됩니다. 여러 사용자가 동시에 시스템에서 동일한 프로젝트를 빌드하는 경우 출력 파일 충돌을 방지합니다. 출력 기반이라고도 하는 개별 작업공간의 빌드 출력에 해당하는 하위 디렉터리가 포함됩니다.

패키징

BUILD 파일에서 정의한 대상 집합입니다. 패키지 이름은 작업공간 루트를 기준으로 하는 BUILD 파일 경로입니다. 패키지에는 하위 패키지나 BUILD 파일이 포함된 하위 디렉터리가 포함되어 패키지 계층 구조를 형성할 수 있습니다.

패키지 그룹

패키지 집합을 나타내는 타겟 공개 상태 속성 값에 사용되는 경우가 많습니다.

플랫폼

빌드와 관련된 머신 머신 유형 여기에는 Bazel에서 실행되는 머신(\'quot;host" 플랫폼), 머신 빌드 도구가 실행되는 '(quot;exec" 플랫폼), 머신 타겟 ("target platform")이 포함됩니다.

제공업체

규칙 대상에서 다른 규칙 대상으로 전달되는 정보 집합입니다. 일반적으로 컴파일러 옵션, 전이 소스 파일, 전이 출력 파일, 빌드 메타데이터와 같은 정보를 포함합니다. depsets와 함께 자주 사용됩니다.

참고 항목: 제공업체 문서

쿼리 (개념)

빌드 그래프를 분석하여 타겟 속성 및 종속 항목 구조를 이해하는 프로세스입니다. Bazel은 쿼리, cquery, aquery의 세 가지 쿼리 변형을 지원합니다.

query (명령어)

빌드 후 로드 단계 타겟 그래프에서 작동하는 쿼리 도구입니다. 이는 비교적 빠르지만 select()의 효과, 빌드 플래그, 아티팩트의 효과를 분석하거나 작업을 빌드할 수는 없습니다.

참고 항목: 쿼리 방법, 쿼리 참조

저장소 캐시

Bazel에서 빌드를 위해 다운로드한 파일의 주소 지정 가능한 공유 캐시로, 작업공간 간에 공유 가능합니다. 최초 다운로드 후 오프라인 빌드를 사용 설정합니다. 일반적으로 http_archive과 같은 저장소 규칙 및 repository_ctx.download와 같은 저장소 규칙 API를 통해 다운로드한 파일을 캐시하는 데 사용됩니다. 다운로드에 SHA-256 체크섬이 지정된 경우에만 파일이 캐시됩니다.

재현성

빌드 또는 테스트의 입력 속성은 빌드, 테스트의 입력, 시간, 메서드 또는 환경에 관계없이 항상 동일한 출력 집합을 생성합니다. 출력이 반드시 정확하거나 원하는 출력임을 의미하는 것은 아닙니다.

규칙

입력 아티팩트에서 실행될 일련의 작업을 등록하여 출력 아티팩트 집합을 생성하는 함수 구현. 규칙은 ps의 값을 입력 (예: deps, testonly, name)으로 읽을 수 있습니다. 규칙 대상은 제공자(예: DefaultInfo 제공자) 형태로 다른 규칙 대상에 유용할 수 있는 정보를 생성하고 전달합니다.

참고 항목: 규칙 문서

실행 파일

실행 가능한 타겟의 런타임 종속 항목입니다. 일반적으로 실행 파일은 테스트 규칙의 실행 파일이며 실행 파일은 테스트의 런타임 데이터 종속 항목입니다. bazel 테스트 중에 실행 파일이 호출되기 전에 Bazel은 소스 디렉터리 구조에 따라 테스트 실행 파일과 함께 실행 파일의 트리를 준비합니다.

참고 항목: Runfiles 문서

샌드박스 기능

실행 중인 작업을 제한된 임시 실행 루트 내에서 격리하는 방법으로, 선언되지 않은 입력을 읽거나 선언되지 않은 출력을 쓰지 않도록 합니다. 샌드박스는 밀폐성을 크게 향상하지만 일반적으로 성능 비용이 발생하며 운영체제의 지원이 필요합니다. 성능 비용은 플랫폼에 따라 다릅니다. Linux에서는 크게 중요하지 않지만 macOS에서는 샌드박스를 사용할 수 없게 됩니다.

스카이프레임

Skyframe은 Bazel의 핵심 병렬, 기능, 증분 평가 프레임워크입니다.

스탬핑

Bazel에서 빌드한 아티팩트에 추가 정보를 삽입하는 기능입니다. 예를 들어 소스 제어, 빌드 시간 및 출시 빌드의 기타 작업공간 또는 환경 관련 정보에 사용할 수 있습니다. --workspace_status_command 플래그 및 스탬프 속성을 지원하는 규칙을 통해 사용 설정합니다.

스타락

규칙매크로 작성을 위한 확장 언어입니다. 구성 및 성능 향상을 목표로 하는 제한된 Python 하위 집합 (구문 및 문법)입니다. .bzl 파일 확장자를 사용합니다. BUILD 파일은 이전의 Skylark로 알려진 훨씬 더 제한된 버전의 Starlark (예: def 함수 정의 없음)를 사용합니다.

참고 항목: Starlark 언어 도움말

시작 플래그

bazel명령어 간에 지정된 플래그 집합(예: bazel --host_jvm_debug 빌드) 이러한 플래그는 Bazel 서버의 구성을 수정하므로 시작 플래그를 수정하면 서버가 다시 시작됩니다. 시작 플래그는 특정 명령어에 국한되지 않습니다.

타겟

빌드 가능한 단위입니다. 규칙 대상, 파일 타겟 또는 패키지 그룹일 수 있습니다. 규칙 대상은 BUILD 파일의 규칙 선언에서 인스턴스화됩니다. 규칙 구현에 따라 규칙 대상을 테스트 또는 실행할 수도 있습니다. BUILD 파일에서 사용되는 모든 파일은 파일 타겟입니다. 타겟은 속성을 통해 다른 대상에 종속될 수 있습니다 (일반적으로는 아니지만 deps). 구성된 타겟은 타겟 및 빌드 구성의 쌍입니다.

타겟 그래프

타겟 및 그 종속 항목의 메모리 내 그래프 로드 단계 중에 생성되고 분석 단계의 입력으로 사용됩니다.

대상 패턴

명령줄에서 타겟 그룹을 지정하는 방법 일반적으로 사용되는 패턴은 :all(모든 규칙 대상), :*(모든 규칙 + 파일 타겟), ...(현재 패키지 및 모든 하위 패키지)를 재귀적으로 사용합니다. 조합하여 사용할 수 있습니다. 예를 들어 //...:*작업공간의 루트에서 반복적으로 모든 패키지의 모든 규칙 및 파일 타겟을 의미합니다.

테스트

규칙 테스트에서 인스턴스화된 규칙이므로 테스트 실행 파일이 포함됩니다. 실행 완료 지점에서의 0 반환 코드는 테스트 성공을 나타냅니다. Bazel 및 테스트 (예: 테스트 환경 변수, 테스트 결과 수집 메서드) 간의 정확한 계약은 테스트 백과사전에 명시되어 있습니다.

도구 모음

언어의 출력을 빌드하는 도구 모음입니다. 일반적으로 도구 모음에는 컴파일러, 링커, 인터프리터, 린터가 포함됩니다. 도구 모음은 플랫폼마다 다를 수 있습니다. 즉, 도구 모음이 같은 언어에 해당하더라도 Unix 컴파일러 도구 모음의 구성요소는 Windows 변형에 따라 다를 수 있습니다. 플랫폼에 적합한 도구 모음을 선택하는 것은 도구 모음 해상도라고 합니다.

최상위 대상

Bazel 명령줄에서 요청된 경우 빌드 대상은 최상위 수준입니다. 예를 들어 //:foo//:bar에 종속되고 bazel build //:foo가 호출되면 이 빌드의 경우 //:foo이 최상위 수준이고 //:bar은 최상위 대상이 아닙니다. 하지만 두 타겟을 모두 빌드해야 합니다. 최상위 수준과 최상위가 아닌 대상 간의 중요한 차이점은 Bazel 명령줄 또는 .bazelrc을 통해 설정된 명령어 플래그는 최상위 대상에 대한 구성을 설정하지만 최상위 대상이 아닌 경우 전환에 의해 수정될 수 있다는 점입니다.

Transition

한 값에서 다른 값으로의 구성 상태 매핑 빌드 그래프대상이 동일한 규칙에서 인스턴스화된 경우에도 다른 구성을 사용할 수 있습니다. 전환의 일반적인 용도는 분할 전환입니다. 여기서 대상 그래프의 특정 부분은 포크마다 별도의 구성으로 포크됩니다. 예를 들어 단일 빌드에서 분할 전환을 사용하여 ARM 및 x86용으로 컴파일된 네이티브 바이너리로 Android APK를 빌드할 수 있습니다.

참고 항목: 사용자 정의 전환

수목 아티팩트

아티팩트를 참고하세요.

공개 상태

타겟이 다른 타겟에 종속될 수 있는지 정의합니다. 기본적으로 타겟 공개 상태는 비공개입니다. 즉, 타겟은 동일한 패키지에 있는 다른 타겟에만 종속될 수 있습니다. 특정 패키지에 표시하거나 완전히 공개할 수 있습니다.

참고 항목: 공개 상태 문서

작업공간

WORKSPACE 소프트웨어 및 빌드할 소프트웨어의 소스 코드가 포함된 디렉터리 //로 시작하는 라벨은 작업공간 디렉터리를 기준으로 합니다.

WORKSPACE 파일

디렉터리를 작업공간으로 정의합니다. 파일은 비어 있을 수 있지만 일반적으로 네트워크 또는 로컬 파일 시스템에서 추가 종속 항목을 가져오기 위한 외부 저장소 선언을 포함합니다.