일반 규칙

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

규칙

별칭

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

alias 규칙은 규칙이 참조될 수 있는 다른 이름을 생성합니다.

앨리어싱은 '일반' 타겟에만 작동합니다. 특히 package_grouptest_suite는 별칭을 지정할 수 없습니다.

별칭 규칙에는 자체 공개 상태 선언이 있습니다. 다른 모든 경우에서는 규칙이 참조되는 규칙처럼 작동합니다 (예: 별칭의 테스트 전용은 무시됨, 참조된 규칙의 테스트 전용성이 대신 사용됨). 몇 가지 사소한 예외가 있습니다.

  • 명령줄에서 별칭이 언급되면 테스트가 실행되지 않습니다. 참조된 테스트를 실행하는 별칭을 정의하려면 tests 속성에 단일 대상이 있는 test_suite 규칙을 사용합니다.
  • 환경 그룹을 정의할 때 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)

구성 가능한 속성을 트리거할 목적으로 예상되는 구성 상태 (빌드 플래그 또는 플랫폼 제약조건으로 표현됨)와 일치합니다. 이 규칙을 사용하는 방법은 선택을 참조하고 일반적인 기능의 개요는 구성 가능한 속성을 참조하세요.

다음은 --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"
      }
  )
  

다음은 명령줄에 명시적으로 또는 .bazelrc 파일에서 암시적으로 사용자 정의 플래그 --//custom_flags:foo=1를 설정하는 모든 빌드와 일치합니다.

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

다음은 x86_64 아키텍처 및 glibc 버전 2.25의 플랫폼을 타겟팅하는 모든 빌드와 일치합니다(라벨이 //example:glibc_2_25constraint_value이 존재한다고 가정). 플랫폼이 이 두 가지 이외의 추가 제약조건 값을 정의하는 경우에도 플랫폼이 일치합니다.

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  
이러한 모든 경우에는 빌드 내에서 구성을 변경할 수 있습니다. 예를 들어 타겟이 종속 항목과 다른 플랫폼에 대해 빌드되어야 하는 경우, 이는 config_setting가 최상위 명령줄 플래그와 일치하지 않더라도 일부 빌드 대상과 일치할 수 있다는 의미입니다.

참고

  • 여러 config_setting이 현재 구성 상태와 일치하면 select를 참조하세요.
  • 약식 양식을 지원하는 플래그 (예: --compilation_mode-c)의 경우 values 정의는 전체 양식을 사용해야 합니다. 두 양식 중 하나를 사용하여 자동으로 호출을 일치시킵니다.
  • 플래그에 여러 값이 있는 경우 (예: --copt=-Da --copt=-Db 또는 목록 유형 Starlark 플래그) values = { "flag": "a" }"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,bios_multi_cpus=a --ios_multi_cpus=b 이 모두 ["a", "b"]생성합니다. 플래그 정의를 확인하고 조건을 신중하게 테스트하여 정확한 기대치를 확인하세요.

  • 기본 제공 빌드 플래그로 모델링되지 않는 조건을 정의해야 하는 경우 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

config_setting와 일치하도록 타겟 플랫폼에서 지정해야 하는 constraint_values의 최소 집합입니다. (실행 플랫폼은 여기에서 고려되지 않습니다.) 플랫폼에서 무시한 추가 제약 조건 값은 무시됩니다. 자세한 내용은 구성 가능한 빌드 속성을 참조하세요.

두 개의 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가 아니라 --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

파일 그룹의 구성원인 타겟 목록.

일반적으로 srcs 속성 값에 glob 표현식의 결과를 사용합니다.

data

List of labels; optional

런타임 시 이 규칙에 필요한 파일 목록

data 속성에 지정된 대상은 이 filegroup 규칙의 runfiles에 추가됩니다. 다른 규칙의 data 속성에서 filegroup이 참조되면 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

쿼리 엔진으로 전달되는 옵션입니다. 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을 사용하지 마세요. 테스트 및 테스트 결과에 관한 특별한 배치(예: 캐싱 정책 및 환경 변수)가 있습니다. 일반적으로 테스트는 빌드가 완료된 후 타겟 아키텍처에서 실행되어야 하지만, genrule은 빌드 도중과 호스트 아키텍처에서 실행됩니다 (두 가지는 다를 수 있음). 범용 테스트 규칙이 필요한 경우 sh_test를 사용하세요.

크로스 컴파일 고려사항

크로스 컴파일에 관한 자세한 내용은 사용자 설명서를 참고하세요.

genrule은 빌드 중에 실행되지만 해당 출력은 빌드 후 배포 또는 테스트용으로 사용되는 경우가 많습니다. 마이크로 컨트롤러용 C 코드를 컴파일하는 예를 살펴보겠습니다. 컴파일러가 C 소스 파일을 허용하고 마이크로 컨트롤러에서 실행되는 코드를 생성합니다. 생성된 코드는 코드를 빌드하는 데 사용된 CPU에서 실행할 수 없지만 C 컴파일러 (소스에서 컴파일된 경우) 자체는 실행해야 합니다.

빌드 시스템은 호스트 구성을 사용하여 빌드가 실행되는 머신을 설명하고 대상 구성을 사용하여 빌드 출력이 실행되어야 하는 머신을 설명합니다. 각각을 구성하는 옵션을 제공하며 충돌을 방지하기 위해 해당 파일을 별도의 디렉터리로 분리합니다.

genrule의 경우 빌드 시스템은 종속 항목이 적절하게 빌드되도록 합니다. srcs대상 구성에 맞게 빌드되고 (필요한 경우) tools호스트 구성에 맞게 빌드되며, 출력은 대상 구성에 사용되는 것으로 간주됩니다. 또한 genrule 명령어가 해당 도구에 전달할 수 있는 "Make" 변수도 제공합니다.

genrule은 deps 속성을 정의하지 않아야 합니다. 다른 기본 제공 규칙은 규칙 간에 전달된 언어 종속 메타 정보를 사용하여 종속 규칙을 처리하는 방법을 자동으로 결정하지만 genrule에는 이러한 수준의 자동화가 불가능합니다. Genrule은 파일 및 runfile 수준에서만 작동합니다.

특수한 경우

호스트 호스트 컴파일: 빌드 시스템이 빌드 중에도 출력을 실행할 수 있도록 genrule을 실행해야 하는 경우가 있습니다. 예를 들어 genrule이 나중에 다른 genrule에서 사용하는 맞춤 컴파일러를 빌드하는 경우 첫 번째 컴파일러는 호스트 구성을 위한 출력을 생성해야 합니다. 이는 컴파일러가 다른 genrule에서 실행되기 때문입니다. 이 경우 빌드 시스템은 올바른 작업을 자동으로 합니다. 즉, 대상 구성이 아닌 호스트 구성에 대한 첫 번째 genrule의 srcsouts를 빌드합니다. 자세한 내용은 사용자 설명서를 참조하세요.

JDK 및 C++ 도구: JDK 또는 C++ 컴파일러 묶음의 도구를 사용하기 위해 빌드 시스템은 사용할 변수 집합을 제공합니다. 자세한 내용은 "Make" 변수를 참조하세요.

Genrule 환경

genrule 명령어는 set -e -o pipefail을 사용하여 명령어 또는 파이프라인이 실패할 때 실패하도록 구성된 Bash 셸에서 실행됩니다.

빌드 도구는 PATH, PWD, TMPDIR 및 기타 몇 가지 핵심 변수만 정의하는 정리된 프로세스 환경에서 Bash 명령어를 실행합니다. 빌드를 재현할 수 있도록 사용자의 셸 환경에 정의된 대부분의 변수는 genrule의 명령어에 전달되지 않습니다. 그러나 Bazel (하지만 Blaze는 아님)은 사용자의 PATH 환경 변수의 값을 전달합니다. PATH 값을 변경하면 Bazel이 다음 빌드에서 명령어를 다시 실행합니다.

genrule 명령어는 명령어 자체의 하위 요소인 연결 프로세스를 제외하고 네트워크에 액세스하면 안 되지만 현재 시행되지는 않습니다.

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

일반 조언

  • genrule이 실행하는 도구는 확정적이고 밀폐되어야 합니다. 출력에 타임스탬프를 쓰면 안 되며, 세트와 맵에 안정적인 순서를 사용해야 하며 절대 경로가 아닌 상대 파일 경로만 출력에 작성해야 합니다. 이 규칙을 따르지 않으면 Bazel이 생각했던 genrule을 다시 빌드하지 않고 예기치 않은 빌드 동작이 발생하고 캐시 성능이 저하됩니다.
  • 출력, 도구, 소스에 $(location)를 광범위하게 사용합니다. 다양한 구성에 대한 출력 파일 분리로 인해 genrule은 하드 코딩된 경로 또는 절대 경로에 의존할 수 없습니다.
  • 동일하거나 매우 유사한 genrule이 여러 위치에서 사용되는 경우 공통 Starlark 매크로를 작성하세요. genrule이 복잡한 경우 스크립트 또는 Starlark 규칙으로 구현하는 것이 좋습니다. 이를 통해 가독성과 테스트 가능성이 개선됩니다.
  • 종료 코드가 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은 genrule에 의해 생성된 디렉터리/symlink 구조를 복사하지 않으며 디렉터리의 종속 항목 검사는 부적절합니다.
  • 다른 규칙에서 genrule을 참조할 때 genrule의 라벨 또는 개별 출력 파일의 라벨을 사용할 수 있습니다. 한 가지 접근 방식은 경우에 따라 가독성이 높고, 다른 하나는 소비 규칙에서 이름으로 출력을 참조하면 srcs가 의도치 않게 다른 genrule의 출력을 선택하는 것을 피할 수 있지만 genrule이 여러 출력을 생성하는 경우 지루한 작업이 될 수 있습니다.

이 예시에서는 foo.h를 생성합니다. 소스가 입력을 취하지 않기 때문에 소스가 없습니다. 명령어로 실행되는 'binary'는 genrule과 같은 패키지의 PERL 스크립트입니다.

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

다음 예는 filegroup과 다른 genrule의 출력을 사용하는 방법을 보여줍니다. 명시적인 $(location) 지시어 대신 $(SRCS)을 사용하는 방법도 괜찮습니다. 이 예시에서는 설명하기 위해 후자를 사용합니다.

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-specific "Make" 변수 ($@, $(OUTS), $(@D) 또는 $(RULEDIR))를 사용하거나 $(location) 대체 항목을 사용하여 사용할 수 있습니다.

cmd

String; optional

실행할 명령어입니다. $(location) '변수' 대체를 따릅니다.
  1. 첫 번째 $(location) 대체가 적용되어 $(location label)$(locations label)의 모든 항목을 대체합니다(관련 변수 execpath, execpaths, rootpath, rootpaths를 사용하여 유사한 구성).
  2. 다음으로 "Make" 변수가 펼쳐집니다. 사전 정의된 변수 $(JAVA), $(JAVAC), $(JAVABASE)host 구성 아래에 확장되므로 빌드 단계의 일부로 실행되는 자바 호출은 공유 라이브러리 및 기타 종속 항목을 올바르게 로드할 수 있습니다.
  3. 마지막으로 결과 명령어는 Bash 셸을 사용하여 실행됩니다. 종료 코드가 0이 아니면 명령어가 실패한 것으로 간주됩니다.
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에서 실행할 Batch 명령어입니다.

이 속성은 cmdcmd_bash보다 우선순위가 높습니다. 이 명령어는 cmd 속성과 유사한 방식으로 실행되지만 다음과 같은 차이점이 있습니다.

  • 이 속성은 Windows에만 적용됩니다.
  • 이 명령어는 다음 기본 인수를 사용하여 cmd.exe /c로 실행됩니다.
    • /S - 첫 번째와 마지막 따옴표를 제거하고 다른 모든 것을 그대로 실행합니다.
    • /E:ON - 확장 명령어 집합을 사용 설정합니다.
    • /V:ON - 지연된 변수 확장 사용 설정
    • /D - AutoRun 레지스트리 항목을 무시합니다.
  • $(location)"variable 대체 후에 경로가 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

이 규칙에 대한 도구 종속 항목 목록입니다. 이 종속 항목은 호스트 구성이 아닌 규칙의 실행 플랫폼에 구성된다는 점을 제외하고 tools 속성과 완전히 동일하게 작동합니다. 즉, exec_tools의 종속 항목에 tools의 종속 항목과 동일한 제한사항이 적용되지 않습니다. 특히 자체 전이 종속 항목에 호스트 구성을 사용할 필요가 없습니다. 자세한 내용은 tools를 참고하세요.

Blaze 팀은 모든 tools 사용을 전환하여 exec_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로 설정하면 이 옵션은 genrule를 '로컬' 전략을 사용하여 강제로 실행합니다. 즉, 원격 실행, 샌드박스, 영구 작업자가 없습니다.

이는 로컬(#)을 태그(tags=["local"])로 제공하는 것과 같습니다.

message

String; optional

진행률 메시지입니다.

이 빌드 단계가 실행될 때 출력될 진행률 메시지입니다. 기본적으로 메시지는 '출력'(또는 동등하게 표시됨)이지만 보다 구체적인 메시지를 제공할 수도 있습니다. 빌드 도구가 이러한 진행률 메시지를 출력할지 여부를 제어할 수 있으므로 echo 또는 cmd 명령어에서 다른 print 문 대신 이 속성을 사용합니다.

output_licenses

Licence type; optional

common attributes 을 참고하세요.
output_to_bindir

Boolean; optional; nonconfigurable; default is False

True로 설정하면 이 옵션이 출력 파일을 genfiles 디렉터리가 아닌 bin 디렉터리에 작성합니다.

tools

List of labels; optional

이 규칙에 대한 도구 종속 항목 목록입니다. 자세한 내용은 종속 항목의 정의를 참조하세요.

빌드 시스템은 이러한 기본 요건이 genrule 명령어를 실행하기 전에 빌드되는지 확인합니다. 이러한 도구는 빌드의 일부로 실행되기 때문에 host 구성을 사용하여 빌드됩니다. 개별 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 확장'이라고 함) 이러한 대상을 빌드하고 테스트합니다.

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

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" 또는 &flat;-flaky") 태그는 유효한 문자열일 수 있습니다.

'-' 문자로 시작하는 태그는 제외 태그로 간주됩니다. 앞의 '-' 문자는 태그의 일부로 간주되지 않으므로 '-small' 묶음 태그는 테스트의 작은 크기와 일치합니다. 다른 모든 태그는 포함 태그로 간주됩니다.

선택적으로, 포지티브 태그를 더 명시적으로 하기 위해 태그는 "+로 시작할 수도 있습니다. 이 문자는 태그 텍스트의 일부로 평가되지 않습니다. 이렇게 하면 긍정적 및 부정적 차이를 더 쉽게 읽을 수 있습니다.

모든 포지티브 태그와 일치하는 제외 태그 없음과 일치하는 테스트 규칙만 테스트 모음에 포함됩니다. 그렇더라도 필터링되는 테스트의 종속 항목 확인 오류를 건너뛰는 것은 아닙니다. 건너뛴 테스트의 종속 항목은 여전히 합법적이어야 합니다 (예: 공개 상태 제약조건에 의해 차단되지 않음).

manual 태그 키워드는 와일드 카드 타겟 패턴과 관련된 호출에 blaze test 명령어가 수행하는 'test_suite 확장'에 의해 위와 다르게 처리됩니다. 여기서 '수동'으로 태그가 지정된 타겟 test_suite개가 필터링되어 확장되지 않습니다. 이 동작은 일반적으로 blaze buildblaze test가 와일드 카드 타겟 패턴을 처리하는 방식과 일치합니다. 이는 manual 태그와 관계없이 도구 모음이 항상 tests 쿼리 함수에 의해 확장되므로 blaze query 'tests(E)'의 동작과는 명시적으로 다릅니다.

테스트의 size는 필터링 목적으로 태그로 간주됩니다.

상호 배타적인 태그가 포함된 테스트(예: 모든 소규모 및 중간 테스트)가 포함된 test_suite이 필요한 경우 세 가지 test_suite 규칙을 만들어야 합니다. 하나는 모든 소규모 테스트용이고, 다른 하나는 이전 두 개의 테스트용입니다.

tests

List of labels; optional; nonconfigurable

모든 언어의 테스트 모음 및 테스트 대상의 목록입니다.

언어와 관계없이 모든 *_test가 허용됩니다. 하지만 테스트가 실행되는 경우에도 *_binary 타겟은 허용되지 않습니다. 지정된 tags별로 필터링은 이 속성에 직접 나열된 테스트에서만 실행됩니다. 이 속성에 test_suites가 포함되어 있으면 이 속성 내의 테스트는 이 test_suite에서 필터링되지 않습니다(이미 필터링된 것으로 간주됨).

tests 속성이 지정되지 않거나 비어 있으면 규칙은 기본적으로 manual로 태그되지 않은 현재 BUILD 파일에 모든 테스트 규칙을 포함합니다. 이러한 규칙에는 tag 필터링이 계속 적용됩니다.