일반적인 정의

<ph type="x-smartling-placeholder"></ph> 문제 신고 소스 보기 1박 · 7.2 · 7.1 · 7.0 · 6.5 · 6.4

이 섹션에서는 Google Cloud 프로젝트 및 빌드 규칙을 적용할 수 있습니다

목차

Bourne 셸 토큰화

일부 규칙의 특정 문자열 속성은 다음 단어 중 하나를 사용합니다. 따옴표가 없는 공백은 개별 단어를 구분하며 큰따옴표 문자와 백슬래시는 사용할 수 있습니다

이 토큰화의 적용을 받는 속성은 해당 용어의 정의에 명시적으로 명시되어 있습니다.

'Make'가 적용되는 속성 변수 확장 및 Bourne 셸 토큰화는 일반적으로 임의의 옵션을 컴파일러와 기타 도구를 사용합니다. 이러한 속성의 예는 다음과 같습니다. cc_library.coptsjava_library.javacopts. 이러한 대체 항목을 함께 사용하면 구성별 목록으로 확장할 단일 문자열 변수 단어를 선택하는 것입니다.

라벨 확장

극소수의 규칙 중 일부 문자열 속성에 라벨이 적용됩니다. 확장: 해당 문자열이 //mypkg:target과 같은 하위 문자열을 포함하며, 해당 라벨은 선언된 경우 이 규칙이 기존 규칙의 전제 조건으로 www.microsoft.com으로 표시되는 타겟 //mypkg:target

속성의 예로는 genrule.cmdcc_binary.linkopts입니다. 세부정보는 문제에 대해 상대적 라벨이 펼쳐짐 여러 파일로 확장되는 라벨의 처리할 수 있습니다. 자세한 내용은 해당 규칙 속성 문서를 살펴보겠습니다

대부분의 빌드 규칙에서 정의하는 일반적인 속성

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

속성 설명
data

라벨 목록 기본값은 []입니다.

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

data 속성에 있는 대상의 기본 출력 및 실행 파일 이 파일은*.runfiles 이 타겟에 대한 런타임 종속 항목이 있습니다. 여기에는 다음과 같은 데이터가 포함될 수 있습니다. 이 타겟의 버전이 변경될 때 사용되는 파일 또는 바이너리 srcs가 실행됩니다. 자세한 내용은 데이터 종속 항목 섹션을 참조하세요.

새 규칙은 처리 시 data 속성을 정의해야 합니다. 사용할 수 있습니다. Rules 구현 함수 또한 타겟의 runfiles data 속성의 출력과 runfile에서 종속 항목 속성의 runfile 포함)을 표시합니다. 소스 코드 또는 런타임 종속 항목을 사용할 수 있습니다

deps

라벨 목록 기본값은 []입니다.

이 대상의 종속 항목입니다. 일반적으로 규칙 대상만 나열해야 합니다. 일부 규칙은 파일을 deps에 직접 나열하도록 허용합니다. 가능하면 사용하지 않는 것이 좋습니다.)

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

타겟을 사용하여 타겟이 다른 타겟에 종속된다는 의미에 대한 정확한 의미 체계 deps는 규칙의 종류 및 규칙별로 다릅니다. 문서를 더 자세히 살펴보겠습니다 소스 코드를 처리하는 규칙의 경우 deps는 일반적으로 srcs

대부분의 경우 deps 종속 항목은 하나의 모듈에서 같은 프로그래밍 언어로 작성된 다른 모듈에 정의된 기호와 기호, 별도로 컴파일됩니다 여러 언어 간 종속 항목도 허용됩니다. 사례: 예를 들어 java_library 타겟은 C++ 코드에 종속될 수 있습니다. cc_library 타겟에 배치하려면 후자를 deps 속성 다음 정의 보기: 종속 항목 를 참조하세요.

licenses

문자열 목록 구성 불가 기본값은 ["none"]입니다.

이 특정 타겟에 사용할 라이선스 유형 문자열의 목록입니다. 이는 Bazel에서 더 이상 사용하지 않는 지원 중단된 License API의 일부입니다. 하지 말아야 할 일 사용할 수 있습니다.

srcs

라벨 목록 기본값은 []입니다.

이 규칙으로 처리되거나 포함된 파일입니다. 일반적으로 파일을 직접 나열하지만 다음 규칙을 적용할 수 있는 규칙 대상 (예: filegroup 또는 genrule) 기본 출력을 포함합니다.

언어별 규칙을 사용하면 나열된 파일에 개의 파일 확장자를 사용합니다.

모든 빌드 규칙의 공통 속성

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

속성 설명
compatible_with

라벨 목록 구성 불가 기본값은 []입니다.

이 타겟을 빌드할 수 있는 환경 목록과 환경 변수를 만들 수 있습니다

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

deprecation

String; 구성 불가 기본값은 None입니다.

이 타겟과 관련된 설명 경고 메시지입니다. 일반적으로 타겟이 더 이상 사용되지 않음을 사용자에게 알리는 데 사용됩니다. 또는 다른 규칙으로 대체되었거나, 패키지에 비공개인 경우, 유해할 수도 있습니다. 이 태그는 웹페이지, 버그 번호, 이전 CL 예시 등의 정보를 제공하여 메시지를 피하기 위해 필요한 변경사항을 쉽게 찾을 수 있습니다. 감소 대신에 사용할 수 있는 새로운 타겟이 있는 경우 이전 대상의 모든 사용자만 마이그레이션하는 것이 좋습니다.

이 속성은 빌드 방식에 영향을 미치지 않지만 빌드 도구의 진단 출력에 영향을 미칠 수 있습니다. 빌드 도구는 deprecation 속성이 있는 규칙이 다른 패키지의 타겟에 의해 종속됩니다.

패키지 내 종속 항목은 이 경고에서 제외되므로 예를 들어 지원 중단된 규칙의 테스트를 빌드해도 경고가 표시됩니다.

지원 중단된 타겟이 지원 중단된 다른 타겟에 종속되는 경우 경고 없음 메시지가 발행됩니다.

사용자가 사용을 중단하면 타겟을 삭제할 수 있습니다.

distribs

문자열 목록 구성 불가 기본값은 []입니다.

이 특정 타겟에 사용할 배포 메서드 문자열의 목록입니다. 이는 Bazel에서 더 이상 사용하지 않는 지원 중단된 License API의 일부입니다. 하지 말아야 할 일 사용할 수 있습니다.

exec_compatible_with

라벨 목록 구성 불가 기본값은 []입니다.

목록 constraint_values 이 타겟의 실행 플랫폼에 있어야 합니다. 이 내용은 규칙을 설정할 수 있습니다. 제약조건은 사용 가능한 실행 플랫폼 목록을 제한합니다. 자세한 내용은 설명: 도구 모음 해상도입니다.

exec_properties

문자열 사전 기본값은 {}입니다.

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

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

features

feature 문자열의 목록 기본값은 []입니다.

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

features 속성은 패키지 수준 features 속성을 지정해야 합니다. 예를 들어 기능 ["a", "b"]는 패키지 수준에서 사용 설정되고 타겟의 features 속성에는 규칙은 'b'가 됩니다. 'c'로 구성됩니다. 예를 참고하세요.

restricted_to

라벨 목록 구성 불가 기본값은 []입니다.

이 대상이 대신 빌드 가능한 환경 목록입니다. 환경 변수를 만들 수 있습니다

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

tags

문자열 목록 구성 불가 기본값은 []입니다.

태그는 모든 규칙에 사용할 수 있습니다. 태그 test_suite 규칙은 테스트를 분류하는 데 유용합니다. 비테스트 타겟의 태그genrule스타라크 인간 및/또는 외부 도구에 의한 파싱에 사용됩니다.

Bazel은 다음과 같은 경우 샌드박스 코드의 동작을 수정합니다. 테스트 또는 genruletags 속성에 있는 키워드 대상 또는 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 및 테스트의 경우 local = True로 규칙을 표시합니다. 속성의 효과는 동일합니다.
  • requires-network 키워드를 사용하면 외부 액세스할 수 있습니다. 이 태그는 샌드박스 설정 시에만 효과가 있습니다. 사용 설정되어 있는지 확인합니다.
  • block-network 키워드가 외부 계정에 대한 액세스를 차단합니다. 액세스할 수 있습니다. 이 경우에는 가능합니다 이 태그는 샌드박스가 사용 설정되어 있습니다.
  • requires-fakeroot는 테스트 또는 작업을 uid 및 gid 0으로 실행합니다 (즉, 루트 사용자). 이 기능은 Linux에서만 지원됩니다. 이 태그는 --sandbox_fake_username 명령줄 옵션.

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

Bazel은 테스트 실행 파일의 테스트 규칙의 tags 속성:

  • exclusive는 다음 위치에서 테스트를 강제로 실행합니다. '배타적' 다른 테스트가 실행되지 않도록 할 수 있습니다. 이러한 테스트는 모든 빌드 후에 직렬 방식으로 실행됩니다. 비독점 테스트가 완료되었습니다. 원격 실행은 이러한 테스트가 중지되었습니다. Bazel이 가상 머신을 실행하는 것입니다
  • exclusive-if-local는 다음 위치에서 테스트를 강제로 실행합니다. '배타적' 실행되고 있긴 하지만 실행 중인 경우에는 테스트를 병렬로 실행함 실행할 수 있습니다
  • 키워드 manual개가 타겟 패턴 와일드 카드가 확장되지 않도록 타겟을 제외합니다. (..., :*, :all 등) 및 test_suite 규칙 빌드/실행할 최상위 타겟 집합을 계산할 때 테스트를 명시적으로 나열하지 않음 (build, test, coverage 명령어) 하지만 다른 컨텍스트에서 타겟 와일드 카드 또는 테스트 모음 확장에 영향을 미칠 수도 있습니다. query 명령어. manual는 타겟을 충족해야 함을 의미하지 않습니다. 연속 빌드/테스트 시스템에 의해 자동으로 빌드/실행되지 않아야 합니다. 예를 들어 bazel test ...에서 특정 타겟을 제외하는 것이 좋습니다. Bazel 플래그이지만 올바르게 구성된 사전 제출 또는 지속적 테스트에 여전히 포함되어 있음 실행할 수도 있습니다
  • 키워드 external개를 통해 무조건 테스트가 실행됩니다. (--cache_test_results와 관계없이 실행됨) 값).
를 통해 개인정보처리방침을 정의할 수 있습니다. 자세한 내용은 태그 규칙 를 참조하세요.
target_compatible_with

라벨 목록 기본값은 []입니다.

목록 constraint_value초 이 타겟이 고려되려면 타겟 플랫폼에 있어야 함 호환됩니다. 이는 규칙 유형입니다. 타겟 플랫폼이 나열된 모든 제약조건을 충족하지 않으면 타겟이 호환되지 않는 것으로 간주됩니다. 호환되지 않는 타겟은 대상 패턴이 확장된 경우 빌드 및 테스트에서는 건너뜁니다. (예: //..., :all) 호환되지 않는 대상을 사용하면 Bazel에서 오류를 출력하고 빌드 또는 테스트 실패에 영향을 주지 않습니다

호환되지 않는 타겟에 전이적으로 의존하는 타겟은 그 자체입니다. 호환되지 않는 것으로 간주됩니다. 빌드 및 테스트에서도 건너뜁니다.

빈 목록 (기본값)은 타겟이 호환됨을 나타냅니다. 모든 플랫폼에서 사용할 수 있습니다.

Workspace 규칙을 제외한 모든 규칙에서 이 기능을 지원합니다. 속성 일부 규칙의 경우 이 속성이 아무런 영향을 미치지 않습니다. 예를 들어 가격: target_compatible_with cc_toolchain는 유용하지 않습니다.

자세한 내용은 플랫폼 페이지를 참조하세요.

testonly

Boolean; 구성 불가 기본값은 False입니다. 테스트 및 테스트 모음 대상 제외

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

마찬가지로 testonly이 아닌 규칙은 testonly인 모든 규칙에 종속됩니다.

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

이 속성은 타겟이 바이너리에 포함되어 있습니다

테스트는 런타임이 아닌 빌드 시간에만 적용되고 이를 통해 효과적으로 전파되도록 하려면 신중하게 적용해야 합니다. 대상 예를 들어 스텁과 페이크를 단위 테스트에 유용하며 통합 테스트에도 유용할 수 있습니다 프로덕션에 릴리스될 동일한 바이너리를 포함하며 따라서 testonly로 표시하면 안 됩니다. 반대로 무조건적으로 링크를 넣는다면 아마도 무조건적으로 재정의하려면 반드시 테스트 전용으로 표시해야 합니다.

toolchains

라벨 목록 구성 불가 기본값은 []입니다.

이 타겟의 변수를 지정하는 타겟 집합입니다. 볼 수 있습니다. 이러한 대상은 TemplateVariableInfo 또는 Bazel에 내장된 도구 모음 유형의 특수 대상 이러한 포함:

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

이것은 도구 모음 해상도 : 플랫폼 종속 구성의 규칙 구현에서 사용합니다. 사용할 수 없습니다. 속성을 사용하여 어떤 특정 cc_toolchain 또는 java_toolchain를 사용됩니다.

visibility

라벨 목록 구성 불가 기본값은 다음 시점의 default_visibility입니다. package(지정된 경우) 또는 "//visibility:private" 그렇지 않은 경우

타겟의 visibility 속성은 타겟이 다른 패키지에서 사용할 수 있습니다. 다음 문서를 참조하세요. 가시성이 있습니다.

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

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

속성 설명
args

문자열 목록 적용 대상 $(location)"Make 변수" 대체 Bourne 셸 토큰화 기본값은 []입니다.

타겟이 될 때 Bazel이 타겟에 전달하는 명령줄 인수 bazel test로 실행됩니다.

이 인수는 --test_arg 값 앞에 전달됩니다. bazel test 명령줄에서 지정할 수 있습니다.

env

문자열 사전 값은 $(location)"Make 변수" 대체; 기본값은 []입니다.

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

이 속성은 cc_test과 같은 네이티브 규칙에만 적용되며 py_test, sh_test 다음 항목에는 적용되지 않습니다. Starlark에서 정의한 테스트 규칙 자체 Starlark 규칙의 경우 'env'를 추가할 수 있습니다. 속성을 사용하여 TestEnvironment 제공업체.

env_inherit

문자열 목록 기본값은 []입니다.

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

이 속성은 cc_test, py_test, 및 sh_test Starlark에서 정의한 테스트 규칙에는 적용되지 않습니다.

size

문자열 "enormous", "large", "medium" 또는 "small"; 구성 불가 기본값은 "medium"입니다.

테스트 대상의 '무게', 즉 실행에 필요한 시간/리소스를 지정합니다.

단위 테스트는 '소형', 통합 테스트는 '중형', 엔드 투 엔드 테스트는 '대형'으로 간주됩니다. 또는 'enormous'. 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

문자열 "short", "moderate", "long" 또는 "eternal"; 구성 불가 기본값이 파생됨 테스트의 size 속성에서

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

테스트의 크기 속성은 리소스 추정을 제어하지만 테스트의 크기 속성은 제한 시간은 독립적으로 설정할 수 있습니다. 명시적으로 지정하지 않으면 제한 시간은 테스트 크기를 기준으로 합니다. 테스트 제한 시간은 --test_timeout 플래그를 사용하여 재정의할 수 있습니다. 예를 들면 대상: 특정 조건에서 실행되는 것을 볼 수 있습니다. 테스트 제한 시간 값 다음과 같은 기간이 적용됩니다.

제한 시간 값 기간
short 1분
보통 5분
long 15분
영원한 60분

위에 해당하지 않는 경우 테스트 제한 시간을 다음과 같이 재정의할 수 있습니다. --test_timeout bazel 플래그. 예: 수동으로 실행 중인 속도가 느린 것으로 알려져 있습니다 --test_timeout 값 초 단위입니다. 예를 들어 --test_timeout=120는 테스트를 설정합니다. 제한 시간을 2분으로 설정할 수 있습니다

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

flaky

Boolean; 구성 불가 기본값은 False입니다.

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

설정되면 테스트를 최대 세 번 실행하며, 테스트가 실패할 경우에만 실패로 표시합니다. 오류가 발생합니다 기본적으로 이 속성은 False로 설정되며 테스트는 한 번만 실행됩니다 일반적으로 이 속성은 사용하지 않는 것이 좋습니다. 테스트는 어설션이 유지될 때 안정적으로 통과해야 합니다.

shard_count

50 이하의 비음수 정수 기본값은 -1입니다.

병렬 샤드 수를 지정합니다. 테스트 실행에 사용할 수 있습니다.

설정된 경우 이 값은 테스트를 실행할 병렬 샤드입니다. 일부 테스트의 경우 이 매개변수는 샤딩을 사용 설정하는 데 필요할 수 있습니다. 있습니다. --test_sharding_strategy도 참조하세요.

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

샤딩을 하려면 테스트 실행기에서 테스트 샤딩 프로토콜을 지원해야 합니다. 그렇지 않으면 모든 샤드에서 모든 테스트를 실행할 가능성이 큽니다. 원하는 결과가 아니기 때문입니다.

자세한 내용은 테스트 샤딩 를 참조하세요.

local

Boolean; 구성 불가 기본값은 False입니다.

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

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

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

이 섹션에서는 모든 바이너리 규칙에 공통된 속성에 대해 설명합니다.

속성 설명
args

문자열 목록 적용 대상 $(location)"Make 변수" 대체 Bourne 셸 토큰화 구성 불가; 기본값은 []입니다.

실행 시 Bazel이 타겟에 전달할 명령줄 인수 run 명령어로 또는 테스트로 실행할 수 있습니다. 이러한 인수는 bazel run 또는 bazel test 명령줄을 사용하여 데이터를 삭제합니다.

참고: target을 실행할 때는 인수가 전달되지 않습니다. Bazel 외부에서 (예: bazel-bin/).

env

문자열 사전 값은 $(location)"Make 변수" 대체; 기본값은 {}입니다.

대상이 다음과 같을 때 설정할 추가 환경 변수를 지정합니다. bazel run에 의해 실행됩니다.

이 속성은 cc_binary, py_binary, 및 sh_binary Starlark에서 정의한 실행 가능 규칙에는 적용되지 않습니다.

참고: 환경 변수는 대상 Bazel 외부에서 (예: bazel-bin/).

output_licenses

문자열 목록 기본값은 []입니다.

이 바이너리가 생성하는 출력 파일의 라이선스입니다. 이는 Bazel에서 더 이상 사용하지 않는 지원 중단된 License 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는 대상의 구성 가능한 종속 항목에 대한 보수적인 추측만 할 수 있습니다. 자세한 내용은 이 FAQ 를 참조하세요.select()

문서에 nonconfigurable로 표시된 속성은 이 기능을 사용할 수 있습니다. 일반적으로 속성은 구성할 수 없음 문제를 해결하는 방법을 결정하려면 내부적으로 그 값을 알아야 합니다. select()

를 참조하세요. 구성 가능한 빌드 속성을 참조하세요.

암시적 출력 타겟

C++의 암시적 출력은 지원 중단되었습니다. 사용하지 마시기 바랍니다. 다른 언어로 번역하여 제공할 수 있습니다. 아직 지원 중단 경로가 없음 결국에는 지원 중단될 예정입니다.

BUILD 파일에서 빌드 규칙을 정의할 때는 명시적으로 패키지에서 이름이 지정된 새 규칙 대상을 선언하는 것입니다. 여러 빌드 규칙 함수는 또한 하나 이상의 출력 파일을 암시적으로 수반합니다. 대상의 콘텐츠와 의미가 규칙별로 다릅니다. 예를 들어, java_binary(name='foo', ...) 규칙으로 이동합니다. 암시적으로 출력 파일 선언 foo_deploy.jar를 동일한 패키지의 구성원으로 타겟팅합니다. (이 특정 대상은 컨테이너 이미지 생성에 적합한 배포용)

암시적 출력 타겟은 글로벌 그룹의 최고 구성원임 타겟 그래프입니다. 다른 표적과 마찬가지로 요청 시 구축됩니다. 최상위 빌드 명령에 지정되거나 다른 빌드 대상의 필수 기본 요건입니다. 그 것은 BUILD 파일에서 종속 항목으로 참조되며 bazel query와 같은 분석 도구의 출력

규칙 문서에는 각 빌드 규칙 유형에 대한 암시적으로 사용되는 모든 하위 클래스의 이름과 콘텐츠를 자세히 설명하는 출력을 생성합니다.

인코더-디코더 아키텍처를 중요시하지만 두 개의 네임스페이스가 있습니다. 라벨타겟을 식별합니다. 파일 대상은 규칙 또는 파일일 수 있으며 파일 대상은 소스 (또는 입력) 파일 대상 및 파생 (또는 출력) 파일 있습니다 BUILD 파일에서 언급할 수 있는 것들은 다음과 같습니다. 명령줄에서 빌드하거나 bazel query를 사용하여 검사합니다. 대상 네임스페이스입니다. 각 파일 대상은 디스크에 있는 실제 파일 하나('파일 시스템 네임스페이스')에 연결합니다. 각 규칙 대상은 디스크에 있는 0개 또는 1개 이상의 실제 파일에 해당할 수 있습니다. 디스크에 해당 타겟이 없는 파일이 있을 수 있습니다. 대상: 예: C++ 컴파일 중에 생성된 .o 객체 파일 BUILD 파일 내에서나 명령줄에서 참조할 수 없습니다. 이렇게 하면 빌드 도구가 역할을 합니다. 이 내용은 빌드 개념 참조를 참조하세요.