일반 규칙

규칙

• <ph type="x-smartling-placeholder"></ph> 별칭
• <ph type="x-smartling-placeholder"></ph> config_setting
• <ph type="x-smartling-placeholder"></ph> 파일 그룹
• <ph type="x-smartling-placeholder"></ph> 생성형 쿼리
• <ph type="x-smartling-placeholder"></ph> genrule
• <ph type="x-smartling-placeholder"></ph> test_suite

alias

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

alias 규칙은 규칙이 참조할 수 있는 다른 이름을 만듭니다.

별칭은 'regular'에서만 작동합니다. 있습니다 특히 package_group는 및 test_suite에는 별칭을 지정할 수 없습니다.

별칭 규칙에는 자체 공개 상태 선언이 있습니다. 다른 모든 측면에서는 참조하는 규칙과 마찬가지로 (예: 별칭의 testonly는 무시되고, testonly-ness는 대신 사용) 일부 사소한 예외가 있습니다.

• 별칭이 명령줄에 언급되면 테스트가 실행되지 않습니다. 별칭을 정의하려면 다음 단계를 따르세요. test_suite를 사용합니다. tests에 단일 대상이 있는 규칙 속성의 값을 제공합니다.
• 환경 그룹을 정의할 때 environment 규칙에 대한 별칭은 지원됩니다. --target_environment 명령줄에서 지원되지 않음 둘 중 하나를 선택해도 됩니다.

예

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

인수

속성
name	Name; required 이 대상의 고유한 이름입니다.
actual	Label; required 이 별칭이 참조하는 타겟입니다. 규칙이 아니어도 되며 입력으로도 입력 가능합니다. 파일에서 참조됩니다.

config_setting

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

다음의 예상 구성 상태 (빌드 플래그 또는 플랫폼 제약 조건으로 표현됨)와 일치합니다. 구성 가능한 속성을 트리거하는 목적으로 사용됩니다. 다음 경우에 select를 참조하세요. 이 규칙과 일반 기능의 개요는 Configurable 속성을 참조하세요.

예

다음은 --compilation_mode=opt 또는 -c opt (명령줄에서 명시적으로 또는 .bazelrc 파일에서 암시적으로):

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

다음은 ARM을 대상으로 하고 사용자설정 정의를 적용하는 모든 빌드와 일치합니다. FOO=bar (예: bazel build --cpu=arm --define FOO=bar ...):

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

다음은 사용자 정의 플래그 --//custom_flags:foo=1 (명령줄에서 명시적으로 또는 암시적으로 .bazelrc 파일).

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

다음은 x86_64 아키텍처 및 glibc가 있는 플랫폼을 대상으로 하는 모든 빌드와 일치합니다. 버전 2.25, 라벨이 있는 constraint_value가 있다고 가정합니다. //example:glibc_2_25입니다. 플랫폼은 추가 제약 값이 존재합니다.

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  

드림 이러한 모든 경우에 구성은 빌드 내에서 변경될 수 있습니다. 예를 들면 다음과 같습니다. 타겟이 dep와 다른 플랫폼용으로 빌드되어야 합니다. 다시 말해 config_setting는 최상위 명령줄 플래그와 일치하지 않지만 일치할 수도 있습니다. 살펴보겠습니다

참고

• 여러 번 선택했을 때 발생하는 결과는 선택을 참고하세요. config_setting은 현재 구성 상태와 일치합니다.
• 약식 형식을 지원하는 플래그 (예: --compilation_mode vs. -c), values 정의는 전체 형식을 사용해야 합니다. 이러한 항목은 자동으로 두 형식 중 하나를 사용하여 호출을 매칭할 수 있습니다.
• 플래그가 여러 값 (예: --copt=-Da --copt=-Db 또는 목록 유형)을 사용하는 경우 <ph type="x-smartling-placeholder"></ph> Starlark 플래그), "a"가 다음과 같은 경우 values = { "flag": "a" }는 일치합니다. 실제 목록의 어딘가에 있어야 합니다.

  values = { "myflag": "a,b" }도 같은 방식으로 작동하며 --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c --myflag=a,b, --myflag=c,b,a 정확한 의미 체계는 있습니다. 예를 들어 --copt는 같은 위치에 있는 여러 값을 지원하지 않습니다. 인스턴스: --copt=a,b는 ["a,b"]를 생성하지만 --copt=a --copt=b은 ["a", "b"]를 생성합니다 (따라서 values = { "copt": "a,b" } 전자와 일치하지만 후자는 일치하지 않음). 하지만 --ios_multi_cpus (Apple 규칙의 경우) 실행: -ios_multi_cpus=a,b 및 ios_multi_cpus=a --ios_multi_cpus=b 모두 ["a", "b"]를 생성합니다. 플래그 정의를 확인하고 조건을 주의 깊게 검토하여 정확한 기대치를 확인합니다.

• 기본 제공 빌드 플래그로 모델링되지 않는 조건을 정의해야 하는 경우 <ph type="x-smartling-placeholder"></ph> Starlark 정의 플래그. --define를 사용할 수도 있지만 성능이 더 낮습니다. 권장되지 않습니다 자세한 내용은 자세한 내용은 여기를 참고하세요.
• 여러 패키지에서 동일한 config_setting 정의를 반복하지 않습니다. 대신 표준 패키지에 정의된 공통 config_setting를 참조합니다.
• values님, define_values 및 constraint_values 같은 config_setting에서 어떤 조합으로든 사용할 수 있지만 적어도 하나는 반드시 특정 config_setting에 대해 설정되어야 합니다.

인수

속성
name	Name; required 이 대상의 고유한 이름입니다.
constraint_values	List of labels; optional; nonconfigurable 타겟 플랫폼에서 지정해야 하는 최소 constraint_values 세트 이 config_setting에 일치시킵니다. (실행 플랫폼은 여기에서 고려됨) 플랫폼의 모든 추가 제약조건 값은 무시됩니다. 자세한 내용은 <ph type="x-smartling-placeholder"></ph> 구성 가능한 빌드 속성을 참조하세요. 두 config_setting가 모두 동일한 select인 경우 이 속성은 config_setting 중 하나가 다른 하나의 전문 분야인지 여부 기타 즉, 하나의 config_setting가 다른 플랫폼보다 더 강력하게 일치할 수는 없습니다.
define_values	Dictionary: String -> String; optional; nonconfigurable values와 동일하지만 특히 --define 플래그에 관한 것입니다. --define는 문법 (--define KEY=VAL) 때문에 특수합니다. 이는 KEY=VAL가 Bazel 플래그 관점에서 값임을 의미합니다. 이는 다음을 의미합니다. config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) 같은 키 (define)가 있습니다. 이 속성은 이 문제를 해결합니다. config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) bazel build //foo --define a=1 --define b=2와 정확하게 일치합니다. --define님은 다음 위치에 계속 표시될 수 있습니다. 일반 플래그 구문이 있는 values 사전 키가 구별되는 한 이 속성과 자유롭게 혼합할 수 있습니다.
flag_values	Dictionary: label -> String; optional; nonconfigurable values와 동일하지만 (용) 사용자 정의 빌드 플래그를 참고하세요. 이것은 고유한 속성입니다. 사용자 정의 플래그는 라벨로 참조되는 반면 내장 플래그는 임의의 문자열로 참조됩니다.
values	Dictionary: String -> String; optional; nonconfigurable 이 규칙과 일치하는 구성 값의 집합입니다 (빌드 플래그로 표현됨). 이 규칙은 설정된 대상의 구성을 상속합니다. select 문에서 이를 참조합니다. 이는 "일치" Bazel 호출을 추가합니다. 항목의 예상 값과 일치합니다. 예: values = {"compilation_mode": "opt"}는 호출과 일치합니다. bazel build --compilation_mode=opt ... 및 대상에서 구성한 규칙에 대한 bazel build -c opt ...입니다. 편의를 위해 구성 값은 빌드 플래그로 지정됩니다( 이전 "--") 그러나 이 둘은 서로 다르다는 점을 명심하세요. 이 대상이 동일한 환경 내에서 여러 구성으로 빌드될 수 있기 때문에 있습니다. 예를 들어 호스트 구성의 'cpu'는 는 --cpu가 아닌 --host_cpu입니다. 따라서 포드의 동일한 config_setting이 동일한 호출에 다르게 일치할 수도 있습니다. 해당 규칙을 사용하는 규칙의 구성에 따라 달라집니다. 명령줄에서 플래그를 명시적으로 설정하지 않으면 기본값이 사용됩니다. 키가 사전에 여러 번 표시되면 마지막 인스턴스만 사용됩니다. 키가 명령줄에서 여러 번 설정할 수 있는 플래그 (예: bazel build --copt=foo --copt=bar --copt=baz ...), 다음과 같은 경우 일치가 발생합니다. 해당 설정 중 하나라도 일치

파일 그룹

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

filegroup을 사용하여 타겟 컬렉션에 편리한 이름을 지정합니다. 그런 다음 다른 규칙에서 이를 참조할 수 있습니다.

디렉터리를 직접 참조하는 대신 filegroup를 사용하는 것이 좋습니다. 빌드 시스템이 모든 파일을 완전히 알지 못하기 때문에 후자는 바람직하지 않습니다. 이러한 파일이 변경될 때 다시 빌드되지 않을 수 있습니다. 결합 시 glob, filegroup는 모든 파일이 빌드 시스템에 명시적으로 알려져 있습니다

예

두 개의 소스 파일로 구성된 filegroup를 만들려면 다음을 실행합니다.

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

또는 glob를 사용하여 testdata 디렉터리를 탐색합니다.

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

이러한 정의를 활용하려면 규칙의 라벨로 filegroup를 참조합니다.

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

인수

속성
name	Name; required 이 대상의 고유한 이름입니다.
srcs	List of labels; optional 파일 그룹의 구성원인 대상 목록입니다. glob 표현식의 결과를 사용하는 것이 일반적입니다. srcs 속성의 값입니다.
data	List of labels; optional 런타임 시 이 규칙에 필요한 파일의 목록입니다. data 속성에 이름이 지정된 대상은 이 filegroup 규칙의 runfiles입니다. 이 filegroup는 다음의 data 속성에서 참조됩니다. 또 다른 규칙은 runfiles가 runfiles에 추가됩니다. 적용됩니다. 데이터 종속 항목 참조 섹션 및 data를 참고하세요.
output_group	String; optional 소스에서 아티팩트를 수집할 출력 그룹입니다. 이 속성이 지정하면 종속 항목의 지정된 출력 그룹의 아티팩트를 내보냅니다. 기본 출력 그룹 대신 '출력 그룹' 대상의 출력 아티팩트 카테고리이며, 확인할 수 있습니다.

Genquery

genquery(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery()는 Blaze 쿼리 언어 및 결과를 덤프 할 수 있습니다.

빌드를 일관성 있게 유지하기 위해 쿼리는 다음 방문에만 허용됩니다. scope에 지정된 타겟의 전이적 종료 속성의 값을 제공합니다. 이 규칙을 위반하는 쿼리는 다음과 같은 경우 실행 중에 실패합니다. strict가 지정되지 않았거나 true입니다 (strict가 false인 경우 지원 범위 외 대상은 경고와 함께 건너뜁니다.) 이 이를 방지하는 가장 쉬운 방법은 동일한 라벨을 언급하는 것입니다. 할 수 있습니다.

여기에서 허용되는 쿼리와 명령어에서 허용되는 쿼리의 유일한 차이점은 와일드 카드 타겟 사양 (예: //pkg:* 또는 //pkg:all)은 여기에서 허용되지 않습니다. 그 이유는 두 가지입니다. 첫 번째는 genquery가 는 출력에 영향을 줄 수 있습니다. 두 번째는 BUILD 파일이 와일드 카드 종속 항목 (예: deps=["//a/..."])을 지원하지 않음 허용되지 않음).

genquery의 출력은 다음에서 --order_output=full를 사용하여 정렬됩니다. 확정적인 출력을 적용합니다

출력 파일의 이름은 규칙의 이름입니다.

예

이 예에서는 대상에 추가합니다.

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

인수

속성
name	Name; required 이 대상의 고유한 이름입니다.
expression	String; required 실행할 쿼리입니다. BUILD 파일의 명령줄 및 다른 위치와 달리 라벨은 작업공간의 루트 디렉터리를 기준으로 확인됩니다. 예를 들어 a/BUILD 파일에서 이 속성의 :b 라벨은 타겟 //:b.
opts	List of strings; optional 쿼리 엔진에 전달되는 옵션입니다. 이는 Kubernetes 클러스터의 bazel query에 전달할 수 있는 옵션입니다. 일부 쿼리 옵션이 허용되지 않음 위치: --keep_going, --query_file, --universe_scope, --order_results 및 --order_output 여기에 지정되지 않은 옵션 bazel query의 명령줄과 마찬가지로 기본값을 갖습니다.
scope	null; required 쿼리의 범위입니다. 쿼리에서 전환 이외의 대상을 터치할 수 없습니다. 도움이 될 수 있습니다
strict	Boolean; optional; default is True true이면 쿼리가 범위의 전이적 닫기를 이스케이프하는 대상이 다음을 수행할 수 없습니다. 있습니다. false인 경우 Bazel은 경고를 출력하고 범위를 좁히고 나머지 쿼리를 완료합니다.

Genrule

genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

genrule는 사용자 정의 Bash 명령어를 사용하여 하나 이상의 파일을 생성합니다.

Genrule은 작업에 대한 특정 규칙이 없는 경우 사용할 수 있는 일반적인 빌드 규칙입니다. 예를 들어 Bash 한 줄 줄을 실행할 수 있습니다. 그러나 C++ 파일을 컴파일해야 하는 경우에는 기존 cc_* 규칙에 대한 권한만 부여합니다. 이는 모든 어려운 작업이 이미 완료되었기 때문입니다. 있습니다.

테스트 실행에 genrule을 사용하지 마세요. 테스트 및 테스트를 위한 특별 조제가 있습니다. 캐싱 정책 및 환경 변수를 포함하여 이러한 결과를 수행할 수 있습니다 일반적으로 테스트는 대상 아키텍처에서 빌드가 완료된 후 대상 아키텍처에서 실행되는 반면, 빌드와 호스트 아키텍처 (이 둘은 다를 수 있음)에 따라 다릅니다. 범용 테스트 규칙인 경우 sh_test를 사용합니다.

크로스 컴파일 고려사항

다음에 대한 자세한 내용은 사용자 설명서를 참조하세요. 크로스 컴파일이 가능합니다.

genrule이 빌드 중에 실행되지만 해당 출력은 빌드 이후에 배포 또는 있습니다. 마이크로컨트롤러의 C 코드를 컴파일하는 예를 생각해 보세요. 컴파일러는 C를 허용합니다. 소스 파일을 빌드하고 마이크로컨트롤러에서 실행되는 코드를 생성합니다. 생성된 코드는 빌드하는 데 사용된 CPU에서는 실행할 수 없지만 C 컴파일러 (소스에서 컴파일된 경우)는 알아내야 합니다

빌드 시스템은 호스트 구성을 사용하여 빌드가 실행되는 머신을 설명합니다. 빌드의 출력이 생성되는 머신을 설명하는 대상 구성 있습니다 각 구성요소를 구성할 수 있는 옵션을 제공하며 해당 파일을 별도의 디렉터리로 옮겨 충돌을 방지합니다.

genrule의 경우 빌드 시스템에서 종속 항목이 적절하게 빌드되도록 합니다. srcs는 대상 구성을 위해 빌드됩니다 (필요한 경우). tools는 호스트 구성용으로 빌드되며 출력은 대상 구성용입니다. 또한 '만들기' 변수를 생성합니다.

genrule이 deps 속성을 정의하지 않도록 의도된 것입니다. 다른 기본 제공 규칙은 규칙 간에 전달되는 언어별 메타 정보로 하지만 genrule에 대해 이러한 수준의 자동화가 불가능합니다. Genrule 작동 순전히 파일 및 실행 파일 수준에서만 작동합니다.

특수 사례

호스트 호스트 컴파일: 경우에 따라 빌드 시스템은 출력은 빌드 중에도 실행될 수 있습니다. 예를 들어 genrule이 커스텀 컴파일러를 빌드한다면 다른 genrule이 사용하는 경우, 첫 번째 Genrule은 다른 genrule에서 컴파일러가 실행되기 때문입니다. 이 경우 빌드 시스템이 자동으로 올바른 작업을 실행합니다. srcs를 빌드하고 대상 대신 호스트 구성에 대한 첫 번째 genrule의 outs 구성할 수 있습니다 자세한 내용은 사용자 설명서를 참고하세요. 확인할 수 있습니다

JDK 및 C++ 도구: JDK 또는 C++ 컴파일러 제품군의 도구를 사용하려면 빌드 시스템 사용할 변수 집합을 제공합니다. '만들기'를 참고하세요. 변수의 경우 확인하세요.

Genrule 환경

genrule 명령어는 명령어 실행 시 실패하도록 구성된 Bash 셸에 의해 실행됩니다. set -e -o pipefail를 사용하여 파이프라인이 실패하는 경우

빌드 툴은 PATH, PWD, TMPDIR 외 몇 명입니다. 빌드를 재현할 수 있도록 하기 위해, 대부분의 변수는 사용자의 셸에 정의되어 있습니다. 환경은 genrule의 명령어에 전달되지 않습니다. 그러나 Bazel (단, Bazel은 Blaze)에서 사용자의 PATH 환경 변수 값을 전달합니다. PATH 값을 변경하면 Bazel에서 명령어를 다시 실행합니다. 확인할 수 있습니다.

genrule 명령어는 작동 중인 프로세스를 연결하는 경우를 제외하고 네트워크에 액세스해서는 안 됩니다. 명령어 자체의 하위 요소이며, 이는 현재 시행되지 않습니다.

빌드 시스템은 기존 출력 파일을 자동으로 삭제하지만 필요한 상위 파일을 생성합니다. 디렉터리를 생성합니다. 또한 장애가 발생할 경우 모든 출력 파일을 삭제합니다.

일반 도움말

• genrule에서 실행하는 도구가 확정적이고 밀폐되어야 합니다. 타임스탬프를 출력에 추가하고, 집합과 맵에 안정적인 순서를 사용해야 하며, 절대 경로 없이 상대 파일 경로만 출력에 씁니다. 이 규칙을 따르지 않으면 예기치 않은 빌드 동작 (Bazel이 생각했던 genrule을 다시 빌드하지 않음)이 발생하는 경우 및 캐시 성능이 저하될 수 있습니다
• 출력, 도구, 소스에 $(location)를 광범위하게 사용합니다. 이로 인해 여러 구성에 대해 출력 파일을 분리할 수 있으므로 genrule이 하드 코딩된 절대 경로일 수 있습니다.
• 다음과 같거나 매우 유사한 genrule이 사용되는 경우 공통 Starlark 매크로를 작성합니다. 액세스할 수 있습니다 genrule이 복잡하면 스크립트나 스타라크 법칙. 따라서 가독성과 테스트 가능성이 향상됩니다.
• 종료 코드가 genrule의 성공 또는 실패를 올바르게 나타내는지 확인하세요.
• stdout 또는 stderr에 정보 메시지를 작성하지 마세요. 이는 디버깅에는 유용하지만 노이즈가 되기 쉽습니다. 성공적인 genrule은 조용해야 합니다. 반면에 실패한 genrule은 좋은 오류 메시지를 표시합니다.
• $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
• 심볼릭 링크와 디렉터리를 만들지 않는 것이 좋습니다. Bazel이 디렉터리/심볼릭 링크를 복사하지 않음 genrules로 만든 구조와 디렉터리의 종속 항목 검사가 올바르지 않습니다.
• 다른 규칙에서 genrule을 참조할 때 genrule의 라벨 또는 지정할 수도 있습니다 한 가지 접근 방식이 더 읽기 쉽고 기타: 소비 규칙의 srcs에서 이름으로 출력을 참조하면 안 됩니다. genrule의 다른 출력을 의도치 않게 가져오는 것이지만 이 생성 규칙이 많은 출력을 생성합니다.

예

이 예시에서는 foo.h를 생성합니다. 이 명령어는 모든 입력. '바이너리' genrule과 동일한 패키지의 PERL 스크립트입니다.

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

다음 예는 filegroup를 사용하는 방법을 보여줍니다. 및 다른 genrule의 출력을 생성합니다. 대신 $(SRCS) 사용 명시적 $(location) 지시어도 작동합니다. 이 예에서는 후자를 보여드렸습니다.

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

인수

속성
name	Name; required 이 대상의 고유한 이름입니다. 다른 BUILD의 srcs 또는 deps 섹션 있습니다. 규칙이 소스 파일을 생성하는 경우 srcs 속성
srcs	List of labels; optional 이 규칙의 입력 목록입니다(예: 처리할 소스 파일). 이 속성은 cmd에서 실행된 도구를 나열하는 데 적합하지 않습니다. 사용 tools 속성을 대신 사용하세요. 빌드 시스템은 genrule을 실행하기 전에 이러한 기본 요건이 빌드되었는지 확인합니다. 명령어; 원래 빌드 요청과 동일한 구성을 사용하여 빌드됩니다. 이 이러한 사전 요구 사항의 파일 이름은 명령에 $(SRCS) 형식의 공백으로 구분된 목록 또는 개별 사용자의 경로가 srcs 대상 //x:y은 $(location //x:y)을 사용하거나 $<를 사용하여 구할 수 있습니다(단, 이 항목이 srcs입니다.
outs	List of filenames; required; nonconfigurable 이 규칙으로 생성된 파일의 목록입니다. 출력 파일은 패키지 경계를 넘지 않아야 합니다. 출력 파일 이름은 패키지를 기준으로 해석됩니다. executable 플래그가 설정된 경우 outs에 정확히 하나만 포함되어야 합니다. 라벨을 지정합니다. genrule 명령어는 사전에 결정된 위치에 각 출력 파일을 생성합니다. 위치는 cmd에서 genrule 특정 'Make'를 사용하여 사용할 수 있습니다. 변수 ($@, $(OUTS), $(@D) 또는 $(RULEDIR)) 또는 사용 $(location) 대체
cmd	String; optional 실행할 명령어입니다. $(location) 및 'Make' 적용 변수 대체를 지원합니다. 첫 번째 $(location) 대체가 적용되어 $(location label) 및 $(locations label)의 모든 일치하는 항목 (및 유사한 항목)을 대체합니다. 관련 변수 execpath, execpaths, rootpath 및 rootpaths)을 입력합니다. 다음으로 '만들기' 변수는 확장됩니다. 참고: 사전 정의된 변수 $(JAVA), $(JAVAC), $(JAVABASE)는 호스트 구성 아래에서 확장되므로 Java 호출이 빌드 단계의 일부로 실행되는 모든 애플리케이션은 공유 라이브러리 및 기타 종속 항목이 포함됩니다 마지막으로 결과 명령어는 Bash 셸을 사용하여 실행됩니다. 종료 코드가 실패한 것으로 간주됩니다. 를 통해 개인정보처리방침을 정의할 수 있습니다. 이는 cmd_bash, cmd_ps, cmd_bat의 대체입니다. 해당 사항이 없는 경우 명령줄 길이가 플랫폼 제한 (Linux/macOS에서 64K, Windows에서 8K)을 초과하는 경우 genrule이 명령어를 스크립트에 작성하고 해당 스크립트를 실행하여 문제를 해결합니다. 이 모든 cmd 속성 (cmd, cmd_bash, cmd_ps, cmd_bat).
cmd_bash	String; optional 실행할 Bash 명령어 이 속성의 우선순위가 cmd보다 높습니다. 명령어가 확장되어 cmd 속성과 정확히 동일한 방식으로 실행됩니다.
cmd_bat	String; optional Windows에서 실행할 일괄 명령어입니다. 이 속성의 우선순위가 cmd 및 cmd_bash보다 높습니다. 명령어는 cmd 속성과 비슷한 방식으로 실행되며 다음과 같은 차이점이 있습니다. 이 속성은 Windows에만 적용됩니다. 명령어는 다음 기본 인수와 함께 cmd.exe /c를 사용하여 실행됩니다. <ph type="x-smartling-placeholder"> </ph> /S - 첫 번째와 마지막 따옴표를 제거하고 다른 모든 것을 있는 그대로 실행합니다. /E:ON - 확장된 명령어 집합을 사용 설정합니다. /V:ON - 지연된 변수 확장 사용 설정 /D - AutoRun 레지스트리 항목을 무시합니다. $(location) 및 이후 '만들기' 변수 대체를 사용하려는 경우 경로는 Windows 스타일 경로 (백슬래시 포함)로 확장되었습니다.
cmd_ps	String; optional Windows에서 실행되는 Powershell 명령어 이 속성의 우선순위가 cmd, cmd_bash 및 cmd_bat입니다. 명령어는 cmd와 유사한 방식으로 실행됩니다. 속성을 사용하여 다음과 같은 차이점이 있습니다. 이 속성은 Windows에만 적용됩니다. 명령어는 powershell.exe /c로 실행됩니다. Powershell을 더 쉽게 사용하고 오류 발생 가능성을 줄이기 위해 다음을 실행합니다. 명령어를 사용하여 환경을 설정한 다음 genrule에서 Powershell 명령어를 실행합니다. Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - 실행 허용 사용할 수 없습니다. $errorActionPreference='Stop' - 명령어가 여러 개인 경우 ;로 구분되며 Powershell CmdLet이 실패하면 작업이 즉시 종료됩니다. 외부 명령에는 작동하지 않습니다. $PSDefaultParameterValues['*:Encoding'] = 'utf8' - 기본값 변경 utf-16에서 utf-8로 변환할 수 있습니다.
exec_tools	List of labels; optional 이 규칙에 대한 tool 종속 항목의 목록입니다. 이것은 tools 속성(단, 이러한 종속 항목은 제외) 호스트 구성이 아닌 규칙의 실행 플랫폼에 맞게 구성됩니다. 즉, exec_tools의 종속 항목은 동일한 영향을 받지 않습니다. tools의 종속 항목으로 인한 제한사항을 확인합니다. 특히 자체 전이 종속 항목에 호스트 구성을 사용합니다 자세한 내용은 tools에서 자세한 내용을 확인하세요. Blaze팀에서 exec_tools 사용을 위해 모든 tools 사용을 이전하고 있습니다. 의미합니다 사용자는 tools보다 exec_tools를 선호하는 것이 좋습니다. 아무런 문제가 발생하지 않습니다. 기능 이전이 완료되면 exec_tools를 tools로 바꿉니다. 지원이 중단됩니다 경고 및 이전 안내를 따르세요.
executable	Boolean; optional; nonconfigurable; default is False 출력을 실행 파일로 선언합니다. 이 플래그를 True로 설정하면 출력이 실행 파일이며 다음을 사용하여 실행할 수 있습니다. run 명령어. 이 경우 genrule이 정확히 하나의 출력을 생성해야 합니다. 이 속성을 설정하면 run은 있습니다. 생성된 실행 파일의 데이터 종속 항목을 선언하는 것은 지원되지 않습니다.
local	Boolean; optional; default is False True로 설정하면 이 옵션은 'local'을 사용하여 이 genrule를 강제로 실행합니다. 즉, 원격 실행, 샌드박스, 영구 작업자가 없습니다. 이것은 'local'을 제공하는 것과 같습니다. 태그 (tags=["local"])로 사용합니다.
message	String; optional 진행 메시지 이 빌드 단계가 실행될 때 출력될 진행률 메시지입니다. 기본적으로 '출력 생성 중'이라는 메시지가 표시됩니다. (또는 똑같이 단조로운 느낌) 그러나 더 구체적입니다. echo 또는 다른 인쇄 대신 이 속성을 사용하세요. 문을 cmd 명령어에 넣으면 빌드 도구가 이러한 진행률 메시지가 인쇄되는지 여부입니다.
output_licenses	Licence type; optional common attributes 참조
output_to_bindir	Boolean; optional; nonconfigurable; default is False True로 설정하면 이 옵션을 사용하면 출력 파일이 bin에 쓰여집니다. 디렉터리를 생성합니다.genfiles
tools	List of labels; optional 이 규칙에 대한 tool 종속 항목의 목록입니다. 다음 정의 보기: 종속 항목을 참조하세요. 빌드 시스템은 genrule 명령어를 실행하기 전에 이러한 기본 요건이 빌드되었는지 확인합니다. 호스트 구성 - 이러한 도구는 빌드의 일부로 실행되기 때문입니다. 개별 tools 타겟 //x:y는 다음을 사용하여 가져올 수 있습니다. $(location //x:y)입니다. cmd에서 실행할 모든 *_binary 또는 도구는 이 올바른 구성으로 빌드되었는지 확인하기 위해 srcs 목록에 없습니다.

test_suite

test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite는 '유용'한 것으로 간주되는 테스트 세트를 정의합니다. 제공합니다. 이 프로젝트에서 '체크인 전에 실행해야 하는 테스트', ' 프로젝트의 스트레스 테스트" 지정할 수 있습니다 blaze test 명령어는 이 정렬을 따릅니다. 조직: blaze test //some/test:suite 등의 호출의 경우 Blaze 우선 //some/test:suite 타겟에 의해 전이적으로 포함된 모든 테스트 타겟을 열거합니다 (이 'test_suite 확장'이라고 하면 Blaze가 해당 타겟을 빌드하고 테스트합니다.

예

현재 패키지의 모든 소규모 테스트를 실행하는 테스트 모음입니다.

test_suite(
    name = "small_tests",
    tags = ["small"],
)

지정된 테스트 세트를 실행하는 테스트 모음:

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

현재 패키지에서 불안정하지 않은 모든 테스트를 실행하는 테스트 모음입니다.

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

인수

속성
name	Name; required 이 대상의 고유한 이름입니다.
tags	List of strings; optional; nonconfigurable 텍스트 태그 목록(예: 'small') 또는 '데이터베이스' 또는 '-불안정'합니다. 태그는 모든 유효한 문자열일 수 있습니다. '-'로 시작하는 태그 제외 태그로 간주됩니다 이 앞에 '-' 문자는 태그의 일부로 간주되지 않으므로 도구 모음 태그는 '-small' 테스트의 'small'과 일치 있습니다. 다른 모든 태그가 고려됨 포함할 수 있습니다. 포함 태그를 더 명시적으로 만들기 위해 태그가 '+' 이 문자는 태그 텍스트의 일부로 평가되지 않습니다. 그것은 긍정적이든 부정적이든 구분하기 쉽도록 할 뿐입니다. 모든 양성 태그 및 제외 태그 없음과 일치하는 규칙만 테스트하세요. 태그가 테스트 모음에 포함됩니다. 이것이 오류를 검사한다고 해서 필터링된 테스트의 종속 항목은 건너뜁니다. 건너뛴 테스트는 여전히 합법적이어야 합니다 (예: 공개 상태 제약으로 차단되지 않음). manual 태그 키워드는 'test_suite 확장' 호출 시 blaze test 명령어로 실행 와일드 카드 포함 타겟 패턴을 기준으로 합니다. 있음, '수동' 태그가 지정된 타겟 test_suite개 필터링되어 펼쳐짐). 이 동작은 blaze build 및 blaze test는 일반적으로 와일드 카드 타겟 패턴을 처리합니다. 이것은 blaze query 'tests(E)'의 동작 방식과 명시적으로 다릅니다. 항상 tests 쿼리 함수에 의해 확장되며 manual 태그 테스트의 size은 필터링 목적으로 태그로 간주됩니다. 상호 배타적인 태그가 있는 테스트가 포함된 test_suite가 필요한 경우 (예: 모든 중소형 테스트)에 대해 세 개의 test_suite를 만들어야 합니다. 하나는 모든 소형 테스트, 다른 하나는 모든 중형 테스트, 다른 하나는 이전 두 개를 살펴봅니다.
tests	List of labels; optional; nonconfigurable 모든 언어의 테스트 모음 및 테스트 타겟 목록 언어와 상관없이 모든 *_test가 여기에서 허용됩니다. 아니요 그러나 *_binary 타겟은 테스트를 실행하더라도 허용됩니다. 지정된 tags로 필터링은 이 속성에 적용됩니다. 이 속성에 test_suite가 포함된 경우 내부 테스트는 이 test_suite로 필터링되지 않습니다( 이미 필터링됨). tests 속성이 지정되지 않거나 비어 있으면 규칙은 기본적으로 다음과 같이 설정됩니다. 태그가 지정되지 않은 현재 BUILD 파일의 모든 테스트 규칙 포함 manual입니다. 이러한 규칙에는 계속 tag 필터링이 적용됩니다.