날짜 비워 두기: BazelCon 2023이 10월 24~25일에 Google 뮌헨에서 열립니다. 자세히 알아보기

일반적인 정의

문제 신고 소스 보기

이 섹션에서는 여러 함수 또는 빌드 규칙에 공통으로 적용되는 다양한 용어와 개념을 정의합니다.

목차

본 셸 토큰화

일부 규칙의 특정 문자열 속성은 본 셸의 토큰화 규칙에 따라 여러 단어로 분할됩니다. 따옴표 없는 공백은 별도의 단어를 구분하며, 작은따옴표와 큰따옴표, 백슬래시는 토큰화를 방지합니다.

이 토큰화가 적용되는 속성은 이 문서의 정의에 명시된 대로 명시적으로 표시됩니다.

'Make' 변수 확장 및 본 셸 토큰화가 적용되는 속성은 일반적으로 컴파일러 및 기타 도구에 임의의 옵션을 전달하는 데 사용됩니다. 이러한 속성의 예로는 cc_library.coptsjava_library.javacopts가 있습니다. 이러한 대체 항목을 함께 사용하면 단일 문자열 변수를 옵션별 구성별 목록으로 확장할 수 있습니다.

라벨 확장

매우 적은 규칙의 일부 문자열 속성에는 라벨 확장이 적용됩니다. 문자열에 유효한 문자열이 하위 문자열(예: //mypkg:target)로 포함되어 있고 해당 라벨이 현재 규칙의 선언된 전제 조건이라면 타겟 //mypkg:target으로 표시되는 파일의 경로 이름으로 확장됩니다.

속성의 예로는 genrule.cmdcc_binary.linkopts가 있습니다. 세부정보는 각 사례에서 상당한 차이가 있을 수 있습니다. 예를 들어 상대 라벨을 펼쳤는지, 여러 파일로 확장하는 라벨을 어떻게 처리하는지 등에 대해 자세히 알아볼 수 있습니다. 자세한 내용은 규칙 속성 문서를 참조하세요.

대부분의 빌드 규칙으로 정의된 일반적인 속성

이 섹션에서는 모든 빌드 규칙이 아닌 여러 빌드 규칙에 의해 정의되는 속성을 설명합니다.

속성 설명
data

List of labels ; optional

런타임에 이 규칙에 필요한 파일 파일 또는 규칙 타겟을 나열할 수 있습니다. 일반적으로 모든 대상을 허용합니다.

data 속성에서 타겟의 기본 출력 및 실행 파일은 이 타겟에 의해 실행되거나 이 타겟에 대한 런타임 종속 항목이 있는 모든 실행 파일의 *.runfiles 영역에 표시되어야 합니다. 여기에는 이 타겟의 srcs가 실행될 때 사용되는 데이터 파일 또는 바이너리가 포함될 수 있습니다. 데이터 파일에 종속되고 사용하는 방법에 관한 자세한 내용은 데이터 종속 항목 섹션을 참고하세요.

새 규칙은 런타임에 다른 입력을 사용할 수 있는 입력을 처리하는 경우 data 속성을 정의해야 합니다. 또한 규칙의 구현 함수는 data 속성의 출력과 실행 파일에서 대상의 런파일을 입력하고 소스 코드 또는 런타임 종속 항목을 제공하는 모든 종속 항목 속성에서 런파일도 채워야 합니다.

deps

List of labels ; optional

이 타겟의 종속 항목입니다. 일반적으로 규칙 타겟만 나열해야 합니다. (일부 규칙에서는 파일을 deps에 직접 나열할 수 있지만 가능한 경우 이 방법을 피해야 합니다.)

언어별 규칙은 일반적으로 나열된 대상을 특정 제공업체가 있는 대상으로 제한합니다.

대상이 deps를 사용하여 다른 항목에 종속된다는 것이 갖는 의미의 정확한 시맨틱스는 규칙의 종류에 따라 다르며, 규칙별 문서에서 자세한 내용을 확인할 수 있습니다. 소스 코드를 처리하는 규칙의 경우 deps는 일반적으로 srcs의 코드에서 사용하는 코드 종속 항목을 지정합니다.

대부분의 경우 deps 종속 항목을 사용하면 한 모듈이 같은 프로그래밍 언어로 작성되어 별도로 컴파일된 다른 모듈에 정의된 기호를 사용할 수 있습니다. 언어 간 종속 항목도 여러 경우에 허용됩니다. 예를 들어 java_library 대상은 deps 속성에 후자를 나열하여 cc_library 타겟의 C++ 코드에 종속될 수 있습니다. 자세한 내용은 종속 항목의 정의를 참조하세요.

licenses

List of strings; optional; nonconfigurable

이 특정 타겟에 사용할 라이선스 유형 문자열 목록입니다. 이는 Bazel이 더 이상 사용하지 않는 지원 중단된 라이선스 API의 일부입니다. 사용하지 마세요.

srcs

List of labels ; optional

이 규칙에 의해 처리되거나 포함된 파일입니다. 일반적으로 파일을 직접 나열하지만 filegroup 또는 genrule와 같은 규칙 대상을 나열하여 기본 출력을 포함할 수 있습니다.

언어별 규칙을 사용하려면 나열된 파일에 특정 파일 확장자가 있어야 하는 경우가 많습니다.

모든 빌드 규칙에 공통적인 속성

이 섹션에서는 모든 빌드 규칙에 암시적으로 추가되는 속성을 설명합니다.

속성 설명
compatible_with

List of labels ; optional; nonconfigurable

기본 지원 환경 외에 이 대상을 빌드할 수 있는 환경 목록

이는 사용자가 서로 종속될 수 있는 대상과 선언할 수 없는 대상을 선언할 수 있게 해주는 Bazel의 제약조건 시스템의 일부입니다. 예를 들어 외부에서 배포 가능한 바이너리는 회사 보안 비밀 코드가 있는 라이브러리에 종속되면 안 됩니다. 자세한 내용은 ConstraintSemantics를 참고하세요.

deprecation

String; optional; nonconfigurable

이 타겟과 관련된 설명 경고 메시지입니다. 일반적으로 대상이 더 이상 사용되지 않거나, 다른 규칙에 의해 대체되었거나, 패키지에만 공개되거나, 어떤 이유로든 유해한 것으로 간주될 수 있음을 사용자에게 알리는 데 사용됩니다. 웹페이지, 버그 번호, 이전 CL과 같은 참조를 포함하여 메시지를 피하는 데 필요한 변경사항을 쉽게 찾을 수 있도록 하는 것이 좋습니다. 대체의 감소로 사용할 수 있는 새 대상이 있는 경우 이전 대상의 모든 사용자를 이전하는 것이 좋습니다.

이 속성은 항목이 빌드되는 방식에는 영향을 미치지 않지만 빌드 도구의 진단 출력에는 영향을 미칠 수 있습니다. 빌드 속성이 deprecation 속성이 있는 규칙이 다른 패키지의 타겟에 종속되면 빌드 도구가 경고를 표시합니다.

패키지 내 종속 항목은 이 경고에서 제외되므로, 예를 들어 지원 중단된 규칙의 테스트를 빌드하면 경고가 발생하지 않습니다.

지원 중단된 대상이 지원 중단된 다른 대상에 종속되면 경고 메시지가 표시되지 않습니다.

사용자가 사용을 중지하면 대상을 삭제할 수 있습니다.

distribs

List of strings; optional; nonconfigurable

이 특정 대상에 사용할 배포 방법 문자열의 목록입니다. 이는 Bazel이 더 이상 사용하지 않는 지원 중단된 라이선스 API의 일부입니다. 사용하지 마세요.

exec_compatible_with

List of labels ; optional; nonconfigurable

이 타겟의 실행 플랫폼에 있어야 하는 constraint_values 목록입니다. 이는 규칙 유형에서 이미 설정한 제약조건 외에 추가로 적용됩니다. 제약조건은 사용 가능한 실행 플랫폼 목록을 제한하는 데 사용됩니다. 자세한 내용은 도구 모음 해상도 설명을 참고하세요.

exec_properties

Dictionary of strings; optional

이 타겟에 대해 선택된 플랫폼의 exec_properties에 추가될 문자열 사전입니다. 플랫폼 규칙의 exec_properties를 참고하세요.

키가 플랫폼 수준과 타겟 수준 속성에 모두 있는 경우 값은 타겟에서 가져옵니다.

features

List of feature strings; optional

기능은 타겟에서 사용 설정 또는 사용 중지할 수 있는 문자열 태그입니다. 특성의 의미는 규칙 자체에 따라 다릅니다.

features 속성은 패키지 수준 features 속성과 결합됩니다. 예를 들어 패키지 수준에서 [a, 'b'] 기능이 사용 설정되고 대상의 features 속성에 ["-a", 'c']가 포함된 경우 규칙에 사용 설정된 특성은 'b' 및 'c'입니다. 예 보기

restricted_to

List of labels ; optional; nonconfigurable

기본 지원 환경 대신 이 대상을 빌드할 수 있는 환경 목록

이는 Bazel의 제약조건 시스템의 일부입니다. 자세한 내용은 compatible_with를 참고하세요.

tags

List of strings; optional; nonconfigurable

태그는 모든 규칙에서 사용할 수 있습니다. 테스트 및 test_suite 규칙의 태그는 테스트를 분류하는 데 유용합니다. 테스트 대상이 아닌 타겟에 관한 태그genruleStarlark 작업의 샌드박스 실행을 제어하고 사람 또는 외부 도구에 의해 파싱되는 데 사용됩니다.

Bazel이 테스트 또는 genrule 대상의 tags 속성에서 또는 Starlark 작업에 대해 execution_requirements 키에서 다음 키워드를 찾으면 샌드박스 코드의 동작을 수정합니다.

  • no-sandbox 키워드를 사용하면 샌드박스 처리되지 않은 작업 또는 테스트가 발생합니다. 여전히 캐시되거나 원격으로 실행될 수 있습니다. 둘 중 하나 또는 둘 다를 방지하려면 no-cache 또는 no-remote를 사용합니다.
  • no-cache 키워드로 인해 작업 또는 테스트가 캐시되지 않음 (원격 또는 로컬)
  • no-remote-cache 키워드를 사용하면 작업 또는 테스트가 원격으로 캐시되지 않습니다. 하지만 로컬에서 캐시될 수도 있고 원격으로 실행될 수도 있습니다. 참고: 이 태그의 목적상 디스크 캐시는 로컬 캐시로 간주되지만 http 및 gRPC 캐시는 원격 캐시로 간주됩니다. 로컬 디스크 캐시와 원격 캐시의 조합 (합계 캐시)을 사용하면 원격 캐시로 처리되며 --incompatible_remote_results_ignore_disk가 설정되지 않은 한 완전히 사용 중지됩니다. 로컬 구성요소가 사용됩니다.
  • no-remote-exec 키워드를 사용하면 작업이나 테스트가 원격으로 실행되지 않지만 원격으로 캐시될 수 있습니다.
  • no-remote 키워드는 작업 또는 테스트가 원격으로 실행되거나 원격으로 캐시되지 않도록 합니다. no-remote-cacheno-remote-exec를 모두 사용하는 것과 같습니다.
  • no-remote-cache-upload 키워드는 생성 원격 원격 업로드 부분을 사용 중지합니다. 원격 실행이 중지되지 않습니다.
  • local 키워드를 사용하면 작업 또는 테스트가 원격으로 캐시되거나 원격으로 실행되거나 샌드박스 내부에서 실행되지 않습니다. genrule 및 test의 경우 규칙을 local = True 속성으로 표시하면 동일한 효과가 적용됩니다.
  • requires-network 키워드를 사용하면 샌드박스 내부에서 외부 네트워크에 액세스할 수 있습니다. 이 태그는 샌드박스가 사용 설정된 경우에만 적용됩니다.
  • block-network 키워드는 샌드박스 내부에서 외부 네트워크에 액세스하는 것을 차단합니다. 이 경우 localhost와의 통신만 허용됩니다. 이 태그는 샌드박스가 사용 설정된 경우에만 적용됩니다.
  • requires-fakeroot는 테스트 또는 작업을 uid 및 gid 0 (즉, 루트 사용자)으로 실행합니다. Linux에서만 지원됩니다. 이 태그는 --sandbox_fake_username 명령줄 옵션보다 우선합니다.

테스트의 태그는 일반적으로 디버그 및 출시 프로세스에서 테스트의 역할에 주석을 지정하는 데 사용됩니다. 일반적으로 태그는 런타임 주석 기능이 없는 C++ 및 Python 테스트에 가장 유용합니다. 태그 및 크기 요소를 사용하면 코드베이스 체크인 정책에 따라 테스트 모음을 유연하게 구성할 수 있습니다.

Bazel이 테스트 규칙의 tags 속성에서 다음 키워드를 찾으면 테스트 실행 동작을 수정합니다.

  • exclusive는 테스트가 '독점' 모드로 강제 실행되도록 하여 다른 테스트가 동시에 실행되지 않도록 합니다. 이러한 테스트는 모든 빌드 활동 및 비배타적 테스트가 완료된 후 순차적으로 실행됩니다. Bazel은 원격 머신에서 실행 중인 항목을 제어할 수 없으므로 이러한 테스트에는 원격 실행이 사용 중지됩니다.
  • exclusive-if-local는 테스트가 로컬에서 실행되면 '배타적' 모드로 실행되도록 하지만, 테스트가 원격으로 실행되는 경우 테스트를 병렬로 실행합니다.
  • manual 키워드는 build, testcoverage 명령어에서 빌드/실행할 최상위 타겟 세트를 계산할 때 테스트를 명시적으로 나열하지 않는 타겟 와일드 카드(..., :*, :all 등) 및 test_suite 규칙의 확장에서 타겟을 제외합니다. query 명령어를 비롯한 다른 컨텍스트에서 타겟 와일드 카드나 테스트 모음 확장에는 영향을 미치지 않습니다. manual는 지속적인 빌드/테스트 시스템에서 타겟을 자동으로 빌드/실행해서는 안 된다는 것을 의미하지 않습니다. 예를 들어, 특정 Bazel 플래그가 필요하지만 여전히 올바르게 구성된 사전 제출 또는 지속적 테스트 실행에는 포함되어 있기 때문에 bazel test ...에서 대상을 제외하는 것이 바람직할 수 있습니다.
  • external 키워드는 테스트를 --cache_test_results 값과 상관없이 무조건 실행합니다.
테스트 대상에 연결된 태그에 관한 추가 규칙은 테스트 백과사전의 태그 규칙을 참고하세요.
target_compatible_with

List of labels ; optional

이 타겟이 호환되는 것으로 간주되려면 타겟 플랫폼에 있어야 하는 constraint_value 목록입니다. 이는 규칙 유형에서 이미 설정한 제약조건에 더하여 적용됩니다. 타겟 플랫폼이 나열된 모든 제약 조건을 충족하지 않으면 타겟은 호환되지 않는 것으로 간주됩니다. 대상 패턴이 확장되면 빌드 및 테스트를 위해 호환되지 않는 대상을 건너뜁니다(예: //..., :all). 명령줄에서 명시적으로 지정하면 호환되지 않는 대상으로 인해 Bazel이 오류를 출력하고 빌드 또는 테스트 실패를 일으킵니다.

호환되지 않는 대상에 전이적으로 종속되는 타겟은 자체적으로 호환되지 않는 것으로 간주됩니다. 또한 빌드 및 테스트에서도 건너뜁니다.

빈 목록 (기본값)은 대상이 모든 플랫폼과 호환됨을 나타냅니다.

작업공간 규칙을 제외한 모든 규칙에서 이 속성을 지원합니다. 일부 규칙에서는 이 속성이 적용되지 않습니다. 예를 들어 cc_toolchaintarget_compatible_with를 지정하는 것은 유용하지 않습니다.

호환되지 않는 타겟 건너뛰기에 관한 자세한 내용은 플랫폼 페이지를 참고하세요.

testonly

Boolean; optional; default False except for test and test suite targets; nonconfigurable

True인 경우 테스트 전용 타겟 (예: 테스트)만 이 타겟에 종속될 수 있습니다.

따라서 testonly이 아닌 규칙은 testonly인 규칙에 종속될 수 없습니다.

테스트 (*_test 규칙) 및 테스트 모음 (test_suite 규칙)은 기본적으로 testonly입니다.

이 속성은 프로덕션에 출시된 바이너리에 타겟을 포함해서는 안 된다는 것을 의미합니다.

테스트 전용은 런타임이 아닌 빌드 시간에 시행되며 종속 항목 트리를 통해 바이럴로 전파되므로 신중하게 적용되어야 합니다. 예를 들어 단위 테스트에 유용한 스텁 및 가짜는 프로덕션에 출시될 동일한 바이너리를 포함하는 통합 테스트에도 유용할 수 있으므로 테스트 전용으로 표시하면 안 됩니다. 반대로 링크하는 데 위험한 규칙(예: 일반 동작을 무조건 재정의하는 경우)은 테스트 전용으로 표시해야 합니다.

toolchains

List of labels ; optional; nonconfigurable

이 타겟이 액세스할 수 있는 Make 변수의 타겟 집합입니다. 이러한 대상은 TemplateVariableInfo를 제공하는 규칙의 인스턴스이거나 Bazel에 내장된 도구 모음 유형에 대한 특수 대상입니다. 예를 들면 다음과 같습니다.

  • @bazel_tools//tools/cpp:current_cc_toolchain
  • @bazel_tools//tools/jdk:current_java_runtime

이는 플랫폼 종속적 구성을 위한 규칙 구현에서 사용하는 도구 모음 확인 개념과 다릅니다. 이 속성을 사용하여 타겟에서 사용할 특정 cc_toolchain 또는 java_toolchain를 결정할 수 없습니다.

visibility

List of labels ; optional; default default_visibility from package if specified, or //visibility:private otherwise; nonconfigurable

타겟의 visibility 속성은 타겟을 다른 패키지에서 사용할 수 있는지 여부를 제어합니다. 공개 상태 문서를 참고하세요.

모든 테스트 규칙에 공통되는 속성 (*_test)

이 섹션에서는 모든 테스트 규칙에 공통으로 적용되는 속성을 설명합니다.

속성 설명
args

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization

Bazel이 bazel test로 실행될 때 대상에 전달하는 명령줄 인수입니다.

이러한 인수는 bazel test 명령줄에 지정된 --test_arg 값 앞에 전달됩니다.

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

bazel test에서 테스트를 실행할 때 설정할 추가 환경 변수를 지정합니다.

이 속성은 cc_test, py_test, sh_test 등의 네이티브 규칙에만 적용됩니다. Starlark 정의 테스트 규칙에는 적용되지 않습니다. 자체 Starlark 규칙의 경우 'env' 속성을 추가하고 이 속성을 사용하여 TestEnvironment 제공업체를 채울 수 있습니다.

env_inherit

List of strings; optional

bazel test에서 테스트를 실행할 때 외부 환경에서 상속할 추가 환경 변수를 지정합니다.

이 속성은 cc_test, py_test, sh_test 등의 네이티브 규칙에만 적용됩니다. Starlark 정의 테스트 규칙에는 적용되지 않습니다.

size

String "enormous", "large" "medium" or "small", default is "medium"; optional; nonconfigurable

테스트 대상의 '무거움'(실행에 필요한 시간/리소스)을 지정합니다.

단위 테스트는 '소형', 통합 테스트는 '중간', 엔드 투 엔드 테스트는 '대형' 또는 '대규모'로 간주됩니다. Bazel은 크기를 사용하여 기본 제한 시간을 결정하며 이는 timeout 속성을 사용하여 재정의할 수 있습니다. 시간 제한은 각 개별 테스트가 아니라 BUILD 타겟의 모든 테스트에 적용됩니다. 테스트가 로컬에서 실행될 때 size는 일정 예약 목적으로 추가로 사용됩니다. Bazel은 --local_{ram,cpu}_resources를 존중하면서 로컬 머신에 무거운 많은 테스트를 동시에 실행하여 로컬 머신에 부담을 주지 않습니다.

테스트 크기는 다음과 같은 기본 제한 시간 및 최대 로컬 리소스 사용량으로 간주됩니다.

크기 RAM (MB) CPU (CPU 코어) 기본 제한 시간
small 20태국 바트 1 단편 (1분)
중간 100 1 보통 (5분)
대형 300 1 장편 (15분)
거대한 800 1 이터널 (60분)

TEST_SIZE 환경 변수는 테스트를 만들 때 이 속성 값으로 설정됩니다.

timeout

String "short", "moderate", "long", "eternal" (with the default derived from the test's size attribute); nonconfigurable

반환하기 전에 테스트가 실행될 것으로 예상되는 시간입니다.

테스트의 크기 속성은 리소스 추정을 제어하지만 테스트 제한 시간은 독립적으로 설정할 수 있습니다. 명시적으로 지정하지 않으면 제한 시간은 테스트 크기를 기반으로 합니다. 테스트 제한 시간은 --test_timeout 플래그로 재정의할 수 있습니다(예: 느리다고 알려진 특정 조건에서 실행). 테스트 제한 시간 값은 다음 기간에 해당합니다.

제한 시간 값 기간
short 1분
보통 5분
long 15분
이터널 60분

위 시간이 아닌 경우 테스트 제한 시간은 --test_timeout bazel 플래그로 재정의할 수 있습니다. 예를 들어 속도가 느린 것으로 알려진 조건에서 수동으로 실행할 수 있습니다. --test_timeout 값은 초 단위입니다. 예를 들어 --test_timeout=120는 테스트 제한 시간을 2분으로 설정합니다.

환경 변수 TEST_TIMEOUT 는 테스트를 생성할 때 테스트 제한 시간 (초)으로 설정됩니다.

flaky

Boolean; optional; default False; nonconfigurable

테스트를 불안정하다고 표시합니다.

설정된 경우 테스트가 최대 3회 실행되어 매번 실패하는 경우에만 실패로 표시됩니다. 기본적으로 이 속성은 False로 설정되고 테스트는 한 번만 실행됩니다. 이 속성은 일반적으로 사용하지 않는 것이 좋습니다. 어설션이 유지되는 경우 테스트를 안정적으로 통과해야 합니다.

shard_count

Non-negative integer less than or equal to 50; optional

테스트를 실행하는 데 사용할 병렬 샤드 수를 지정합니다.

이 값은 테스트를 실행하는 병렬 샤드 수를 결정하는 데 사용되는 휴리스틱을 재정의합니다. 애초에 샤딩을 사용 설정하기 위해 일부 테스트 규칙의 경우 이 매개변수가 필요할 수 있습니다. --test_sharding_strategy도 참조하세요.

테스트 샤딩을 사용 설정하면 테스트를 생성할 때 TEST_TOTAL_SHARDS 환경 변수가 이 값으로 설정됩니다.

샤딩하려면 테스트 실행기에서 테스트 샤딩 프로토콜을 지원해야 합니다. 그렇지 않은 경우 모든 샤드에서 모든 테스트를 실행할 가능성이 가장 높습니다.

샤딩에 관한 자세한 내용은 테스트 백과사전의 테스트 샤딩을 참고하세요.

local

Boolean; default False; nonconfigurable

샌드박스 없이 테스트를 로컬에서 실행합니다.

True로 설정하는 것은 'local'을 태그(tags=["local"])로 제공하는 것과 같습니다.

모든 바이너리 규칙에 공통적인 속성 (*_binary)

이 섹션에서는 모든 바이너리 규칙에 공통적인 속성을 설명합니다.

속성 설명
args

List of strings; optional; subject to $(location) and "Make variable" substitution, and Bourne shell tokenization; nonconfigurable

Bazel이 run 명령어로 실행되거나 테스트로 실행될 때 대상에 전달하는 명령줄 인수입니다. 이러한 인수는 bazel run 또는 bazel test 명령줄에 지정된 인수 앞에 전달됩니다.

참고: Bazel 외부에서 대상을 실행할 때는 인수가 전달되지 않습니다 (예: bazel-bin/에서 바이너리를 수동으로 실행).

env

Dictionary of strings; optional; values are subject to $(location) and "Make variable" substitution

bazel run에서 타겟을 실행할 때 설정할 추가 환경 변수를 지정합니다.

이 속성은 cc_binary, py_binary, sh_binary 등의 네이티브 규칙에만 적용됩니다. Starlark 정의 실행 규칙에는 적용되지 않습니다.

참고: Bazel 외부에서 대상을 실행할 때는 환경 변수가 설정되지 않습니다 (예: bazel-bin/에서 바이너리를 수동으로 실행).

output_licenses

List of strings; optional

이 바이너리가 생성하는 출력 파일의 라이선스입니다. 이는 Bazel이 더 이상 사용하지 않는 지원 중단된 라이선스 API의 일부입니다. 사용하지 마세요.

구성 가능한 속성

대부분의 속성은 '구성 가능'합니다. 즉, 타겟이 다른 방식으로 빌드될 때 값은 변경될 수 있습니다. 특히 구성 가능한 속성은 Bazel 명령줄로 전달되는 플래그나 타겟을 요청하는 다운스트림 종속 항목에 따라 달라질 수 있습니다. 예를 들어 이 기능은 여러 플랫폼 또는 컴파일 모드의 타겟을 맞춤설정하는 데 사용할 수 있습니다.

다음 예에서는 서로 다른 타겟 아키텍처에 대해 서로 다른 소스를 선언합니다. bazel build :multiplatform_lib --cpu x86를 실행하면 x86_impl.cc를 사용하여 타겟이 빌드되고 --cpu arm를 대체하면 arm_impl.cc가 대신 사용됩니다.

cc_library(
    name = "multiplatform_lib",
    srcs = select({
        ":x86_mode": ["x86_impl.cc"],
        ":arm_mode": ["arm_impl.cc"]
    })
)
config_setting(
    name = "x86_mode",
    values = { "cpu": "x86" }
)
config_setting(
    name = "arm_mode",
    values = { "cpu": "arm" }
)

select() 함수는 타겟의 구성이 충족하는 config_setting 또는 constraint_value 기준에 따라 구성 가능한 속성의 다양한 대체 값 중에서 선택합니다.

Bazel은 매크로를 처리한 후와 규칙을 처리하기 전에 구성 가능한 속성을 평가합니다 (기술적으로 로드 단계와 분석 단계 사이에). select() 평가 이전의 모든 처리는 select()가 선택하는 브랜치를 알지 못합니다. 예를 들어 매크로는 선택된 브랜치에 따라 동작을 변경할 수 없으며 bazel query는 타겟의 구성 가능한 종속 항목에 관해 보수적인 추측만 할 수 있습니다. 규칙 및 매크로와 함께 select()을 사용하는 방법에 관한 자세한 내용은 이 FAQ를 참고하세요.

문서에 nonconfigurable로 표시된 속성은 이 기능을 사용할 수 없습니다. 일반적으로 Bazel이 select()의 확인 방법을 결정하기 전에 내부적으로 값을 알아야 하므로 속성을 구성할 수 없습니다.

자세한 내용은 구성 가능한 빌드 속성을 참조하세요.

암시적 출력 타겟

C++의 암시적 출력은 지원 중단되었습니다. 가능한 경우 다른 언어로 사용하지 마세요. 아직 지원 중단 경로가 없지만 결국에는 지원 중단될 예정입니다.

BUILD 파일에서 빌드 규칙을 정의하면 패키지에서 이름이 지정된 새 규칙 대상을 명시적으로 선언합니다. 또한 여러 빌드 규칙 함수에는 콘텐츠와 그 규칙이 규칙별로 적용되는 하나 이상의 출력 파일 타겟이 암시적으로 포함됩니다. 예를 들어 java_binary(name='foo', ...) 규칙을 명시적으로 선언하면 출력 파일의 대상 foo_deploy.jar를 동일한 패키지의 구성원으로 암시적으로 선언하게 됩니다. 이 특정 대상은 배포에 적합한 독립 실행형 자바 보관 파일입니다.

암시적 출력 타겟은 전역 타겟 그래프의 최고 멤버입니다. 다른 타겟과 마찬가지로, 이러한 객체는 최상위 빌드 명령어에 지정되었거나 다른 빌드 타겟의 필수 기본 요건이 되는 경우 필요에 따라 빌드됩니다. 이는 BUILD 파일에서 종속 항목으로 참조될 수 있으며 bazel query와 같은 분석 도구의 출력에서 관찰될 수 있습니다.

각 빌드 규칙의 종류에 관한 규칙 문서에는 해당 종류의 규칙 선언에 수반되는 암시적 출력의 이름과 내용을 자세히 설명하는 특수 섹션이 포함되어 있습니다.

빌드 시스템에서 사용하는 두 네임스페이스의 중요하지만 미묘한 차이입니다. 라벨은 규칙 또는 파일일 수 있는 타겟을 식별하고 파일 타겟은 소스 (또는 입력) 파일 타겟과 파생 (또는 출력) 파일 타겟으로 나눌 수 있습니다. BUILD 파일에서 언급하거나, 명령줄에서 빌드하거나, bazel query를 사용하여 검사할 수 있습니다. 이러한 대상을 대상 네임스페이스입니다. 각 파일 대상은 디스크의 실제 파일('파일 시스템 네임스페이스' 1개)에 해당합니다. 각 규칙 대상은 디스크에 있는 0개, 1개 이상의 실제 파일에 해당할 수 있습니다. 디스크에 해당되는 타겟이 없는 파일이 있을 수 있습니다. 예를 들어 C++ 컴파일 중에 생성된 .o 객체 파일은 BUILD 파일 또는 명령줄에서 참조할 수 없습니다. 이러한 방식으로 빌드 도구는 작업 수행 방식에 관한 특정 구현 세부정보를 숨길 수도 있습니다. 자세한 내용은 BUILD 개념 참조에서 자세히 설명합니다.