BazelCon 2024 등록이 시작되었습니다

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

일반 규칙

문제 신고 소스 보기 Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

규칙

별칭
config_setting
파일 그룹
genquery
genrule
starlark_doc_extract
test_suite

alias

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

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

별칭은 '일반' 타겟에만 적용됩니다. 특히 package_group 및 test_suite는 별칭을 지정할 수 없습니다.

타겟 이름을 변경하려면 많은 파일을 변경해야 하는 대규모 저장소에서는 별칭이 유용할 수 있습니다. 여러 타겟에 이 로직을 재사용하려는 경우 별칭 규칙을 사용하여 select 함수 호출을 저장할 수도 있습니다.

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

명령줄에 별칭이 언급된 경우 테스트가 실행되지 않습니다. 참조된 테스트를 실행하는 별칭을 정의하려면 tests 속성에 단일 타겟이 있는 test_suite 규칙을 사용하세요.
환경 그룹을 정의할 때 environment 규칙의 별칭은 지원되지 않습니다. --target_environment 명령줄 옵션에서도 지원되지 않습니다.

예

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

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

인수

속성

name

이름: 필수사항

이 타겟의 고유한 이름입니다.

actual

라벨, 필수

이 별칭이 참조하는 타겟입니다. 규칙이 아니어도 되며 입력 파일일 수도 있습니다.

config_setting

규칙 소스 보기

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

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

예

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

다음은 //example:glibc_2_25 라벨이 있는 constraint_value가 있다고 가정하여 x86_64 아키텍처 및 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가 현재 구성 상태와 일치하는 경우 어떻게 되는지 알아보려면 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,b와 ios_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`	이름: 필수사항 이 타겟의 고유한 이름입니다.
`constraint_values`	라벨 목록입니다. 구성할 수 없음. 기본값은 `[]`입니다. 이 `config_setting`와 일치하기 위해 타겟 플랫폼에서 지정해야 하는 최소 `constraint_values` 집합입니다. 실행 플랫폼은 여기에서 고려되지 않습니다. 플랫폼에 있는 추가 제약 조건 값은 무시됩니다. 자세한 내용은 구성 가능한 빌드 속성을 참고하세요. 두 개의 `config_setting`가 동일한 `select`에서 일치하고 하나에 다른 플래그와 `constraint_setting`가 모두 동일하고 추가 플래그가 있는 경우 설정이 더 많은 플래그가 선택됩니다. 이를 '전문성'이라고 합니다. 예를 들어 `x86` 및 `Linux`와 일치하는 `config_setting`는 `x86`와 일치하는 `config_setting`를 특수화합니다. 두 `config_setting`가 일치하고 둘 다 다른 하나에 `constraint_value`가 없는 경우 오류입니다.
`define_values`	사전: 문자열 -> 문자열; 구성 불가; 기본값은 `{}`입니다. `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`	사전: label -> 문자열; 구성 불가; 기본값은 `{}`입니다. `values`와 동일하지만 사용자 정의 빌드 플래그에 사용됩니다. 이는 사용자 정의 플래그는 라벨로 참조되는 반면 내장 플래그는 임의의 문자열로 참조되기 때문에 고유한 속성입니다.
`values`	사전: 문자열 -> 문자열; 구성 불가; 기본값은 `{}`입니다. 이 규칙과 일치하는 구성 값 집합(빌드 플래그로 표현됨) 이 규칙은 `select` 문에 이를 참조하는 구성된 타겟의 구성을 상속합니다. 사전의 모든 항목에 대해 구성이 항목의 예상 값과 일치하는 경우 Bazel 호출과 '일치'하는 것으로 간주됩니다. 예를 들어 `values = {"compilation_mode": "opt"}`는 대상 구성 규칙에서 호출 `bazel build --compilation_mode=opt ...` 및 `bazel build -c opt ...`와 일치합니다. 편의를 위해 구성 값은 빌드 플래그로 지정됩니다(앞에 `"--"`가 없음). 하지만 둘은 동일하지 않습니다. 이는 동일한 빌드 내에서 여러 구성으로 타겟을 빌드할 수 있기 때문입니다. 예를 들어 exec 구성의 '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는 명령줄이나 다른 규칙의 속성에 타겟을 나열하는 대안이 아닙니다. 타겟에는 출력 외에도 동일한 방식으로 수집되지 않는 여러 속성이 있기 때문입니다. 하지만 genrule의 srcs 속성이나 *_binary 규칙의 data 속성과 같이 몇 가지 경우에 유용합니다.

디렉터리를 직접 참조하는 대신 filegroup를 사용하는 것이 좋습니다. 디렉터리를 직접 참조하는 것은 권장하지 않습니다. 빌드 시스템은 디렉터리 아래의 모든 파일에 대한 전체 정보를 가지고 있지 않으므로 이러한 파일이 변경될 때 빌드되지 않을 수 있기 때문입니다. glob와 결합되면 filegroup는 모든 파일이 빌드 시스템에 명시적으로 인식되도록 할 수 있습니다.

예

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

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "//a/library:target",
        "//a/binary:target",
    ],
)

또는 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`	이름: 필수사항 이 타겟의 고유한 이름입니다.
`srcs`	라벨 목록입니다. 기본값은 `[]`입니다. 파일 그룹의 구성원인 타겟 목록입니다. `srcs` 속성의 값에 glob 표현식의 결과를 사용하는 것이 일반적입니다.
`data`	라벨 목록입니다. 기본값은 `[]`입니다. 런타임 시 이 규칙에 필요한 파일 목록입니다. `data` 속성에 이름이 지정된 타겟이 이 `filegroup` 규칙의 `runfiles`에 추가됩니다. `filegroup`가 다른 규칙의 `data` 속성에서 참조되면 `runfiles`가 종속 규칙의 `runfiles`에 추가됩니다. 데이터 파일을 종속 항목으로 사용하고 사용하는 방법에 관한 자세한 내용은 데이터 종속 항목 섹션과 `data`의 일반 문서를 참고하세요.
`output_group`	문자열, 기본값은 `""`입니다. 소스에서 아티팩트를 수집할 출력 그룹입니다. 이 속성을 지정하면 기본 출력 그룹 대신 종속 항목의 지정된 출력 그룹의 아티팩트가 내보내집니다. '출력 그룹'은 규칙의 구현에 지정된 타겟의 출력 아티팩트 카테고리입니다.

genquery

규칙 소스 보기

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

genquery()는 Bazel 쿼리 언어에 지정된 쿼리를 실행하고 결과를 파일에 덤프합니다.

빌드 일관성을 유지하기 위해 쿼리는 scope 속성에 지정된 타겟의 전이 폐쇄만 방문할 수 있습니다. 이 규칙을 위반하는 쿼리는 strict가 지정되지 않았거나 true인 경우 실행 중에 실패합니다. strict가 false인 경우 범위 외 타겟은 경고와 함께 건너뜁니다. 이러한 일이 발생하지 않도록 하는 가장 쉬운 방법은 쿼리 표현식에서와 동일한 라벨을 범위에 언급하는 것입니다.

여기에서 허용되는 쿼리와 명령줄에서 허용되는 쿼리의 유일한 차이점은 와일드 카드 타겟 사양(예: //pkg:* 또는 //pkg:all)이 포함된 쿼리는 여기에서 허용되지 않는다는 점입니다. 그 이유는 두 가지입니다.첫째, genquery는 쿼리의 전이 폐쇄 외부의 대상이 출력에 영향을 미치지 않도록 범위를 지정해야 하기 때문입니다. 둘째, BUILD 파일은 와일드 카드 종속 항목을 지원하지 않기 때문입니다 (예: deps=["//a/..."]는 허용되지 않음).

확정적인 출력을 적용하기 위해 genquery의 출력은 사전순으로 정렬됩니다. 단, --output=graph|minrank|maxrank 또는 somepath가 최상위 함수로 사용되는 경우는 예외입니다.

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

예

이 예에서는 지정된 타겟의 전이 폐쇄에 있는 라벨 목록을 파일에 씁니다.

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

인수

속성
`name`	이름. 필수 항목입니다. 이 대상의 고유한 이름입니다.
`compressed_output`	부울. 기본값은 `False`입니다. `True`인 경우 쿼리 출력은 GZIP 파일 형식으로 작성됩니다. 이 설정은 쿼리 출력이 클 것으로 예상될 때 Bazel의 메모리 사용량이 급증하는 것을 방지하는 데 사용할 수 있습니다. Bazel은 이미 이 설정의 값과 관계없이 2²⁰바이트보다 큰 쿼리 출력을 내부적으로 압축하므로 `True`로 설정해도 유지된 힙이 줄어들지 않을 수 있습니다. 그러나 이렇게 하면 Bazel이 메모리 집약적인 출력 파일을 쓸 때 압축 해제를 건너뛸 수 있습니다.
`expression`	문자열, 필수 실행할 쿼리입니다. BUILD 파일의 명령줄 및 다른 위치와 달리 여기서 라벨은 작업공간의 루트 디렉터리를 기준으로 확인됩니다. 예를 들어 `a/BUILD` 파일에 있는 이 속성의 `:b` 라벨은 타겟 `//:b`를 참조합니다.
`opts`	문자열 목록입니다. 기본값은 `[]`입니다. 쿼리 엔진에 전달되는 옵션입니다. 이는 `bazel query`에 전달할 수 있는 명령줄 옵션에 해당합니다. 여기서는 일부 쿼리 옵션(`--keep_going`, `--query_file`, `--universe_scope`, `--order_results`, `--order_output`)이 허용되지 않습니다. 여기에 지정되지 않은 옵션은 `bazel query`의 명령줄과 마찬가지로 기본값이 적용됩니다.
`scope`	라벨 목록(필수) 쿼리의 범위입니다. 쿼리는 이러한 타겟의 전이 폐쇄 외부의 타겟을 터치할 수 없습니다.
`strict`	부울. 기본값은 `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, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

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

Genrules는 작업에 관한 특정 규칙이 없는 경우 사용할 수 있는 일반 빌드 규칙입니다. 예를 들어 Bash 원라인을 실행할 수 있습니다. 그러나 C++ 파일을 컴파일해야 하는 경우에는 모든 어려운 작업이 이미 완료되었으므로 기존 cc_* 규칙을 따라야 합니다.

genrule을 사용하려면 셸이 명령어 인수를 해석해야 합니다. PATH에서 사용 가능한 임의의 프로그램을 쉽게 참조할 수도 있지만, 이렇게 하면 명령어가 폐쇄적이지 않게 되며 재현할 수 없을 수도 있습니다. 단일 도구만 실행해야 하는 경우 대신 run_binary를 사용하는 것이 좋습니다.

다른 모든 작업과 마찬가지로 genrule이 생성한 작업은 작업 디렉터리에 대해 어떠한 가정도 하지 않아야 합니다. 모든 Bazel은 선언된 입력이 $(location)가 라벨에 반환하는 경로에서 사용할 수 있도록 보장합니다. 예를 들어 작업이 샌드박스에서 실행되거나 원격으로 실행되는 경우 샌드박스 구현 또는 원격 실행에 따라 작업 디렉터리가 결정됩니다. standalone 전략을 사용하여 직접 실행하면 작업 디렉터리가 실행 루트 (bazel info execution_root의 결과)가 됩니다.

테스트 실행에는 genrule을 사용하지 마세요. 캐싱 정책 및 환경 변수를 포함하여 테스트 및 테스트 결과를 위한 특별 지급 방식이 있습니다. 테스트는 일반적으로 빌드가 완료된 후 타겟 아키텍처에서 실행해야 하지만 genrule은 빌드 도중과 exec 아키텍처에서 실행됩니다 (둘은 다를 수 있음). 범용 테스트 규칙이 필요한 경우 sh_test를 사용하세요.

크로스 컴파일 고려사항

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

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

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

genrules의 경우 빌드 시스템은 종속 항목이 적절하게 빌드되도록 합니다. srcs는 필요한 경우 타겟 구성을 위해 빌드되고, tools는 exec 구성을 위해 빌드되며, 출력은 타겟 구성을 위한 것으로 간주됩니다. 또한 genrule 명령어에서 상응하는 도구에 전달할 수 있는 'Make' 변수를 제공합니다.

genrule가 deps 속성을 정의하지 않는 것은 의도적인 것입니다. 다른 내장 규칙은 규칙 간에 전달되는 언어 종속 메타 정보를 사용하여 종속 규칙을 처리하는 방법을 자동으로 결정하지만 genrule에서는 이러한 수준의 자동화가 불가능합니다. Genrules는 순전히 파일 및 runfiles 수준에서 작동합니다.

특별 케이스

Exec-exec 컴파일: 경우에 따라 빌드 시스템은 빌드 중에 출력을 실행할 수도 있도록 genrules를 실행해야 합니다. 예를 들어 genrule이 나중에 다른 genrule에서 사용되는 일부 맞춤 컴파일러를 빌드하는 경우, 첫 번째 genrule은 exec 구성의 출력을 생성해야 합니다. 다른 genrule에서 컴파일러가 실행되는 위치이기 때문입니다. 이 경우 빌드 시스템이 자동으로 올바른 작업을 실행합니다. 즉, 타겟 구성 대신 exec 구성에 관한 첫 번째 genrule의 srcs 및 outs를 빌드합니다. 자세한 내용은 사용자 설명서를 참고하세요.

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)를 광범위하게 사용하세요. 다양한 구성에 맞게 출력 파일이 분리되므로 genrules는 하드코딩된 경로 또는 절대 경로를 사용할 수 없습니다.
동일하거나 매우 유사한 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에서 만든 디렉터리/심볼릭 링크 구조를 복사하지 않으며 디렉터리의 종속 항목 검사가 불안정합니다.
다른 규칙에서 genrule을 참조할 때는 genrule의 라벨 또는 개별 출력 파일의 라벨을 사용할 수 있습니다. 한 가지 접근 방식이 더 읽기 쉬울 때도 있고 다른 접근 방식이 더 읽기 쉬울 때도 있습니다. 사용하는 규칙의 srcs에서 이름으로 출력을 참조하면 의도치 않게 genrule의 다른 출력을 선택하지 않을 수 있지만 genrule이 많은 출력을 생성하는 경우 번거로울 수 있습니다.

예

이 예에서는 foo.h를 생성합니다. 명령어가 입력을 받지 않으므로 소스가 없습니다. 이 명령어로 실행되는 '바이너리'는 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`	이름: 필수사항 이 대상의 고유한 이름입니다. 다른 `BUILD` 규칙의 `srcs` 또는 `deps` 섹션에서 이 규칙을 이름으로 참조할 수 있습니다. 규칙이 소스 파일을 생성하는 경우 `srcs` 속성을 사용해야 합니다.
`srcs`	라벨 목록입니다. 기본값은 `[]`입니다. 처리할 소스 파일과 같은 이 규칙의 입력 목록입니다. 이 속성은 `cmd`에서 실행된 도구를 나열하는 데 적합하지 않습니다. 대신 `tools` 속성을 사용하세요. 빌드 시스템은 genrule 명령어를 실행하기 전에 이러한 기본 요건이 빌드되도록 합니다. 기본 요건은 원래 빌드 요청과 동일한 구성을 사용하여 빌드됩니다. 이러한 기본 요건의 파일 이름은 `$(SRCS)`에서 공백으로 구분된 목록으로 명령어에 제공됩니다. 또는 개별 `srcs` 타겟 `//x:y`의 경로는 `$(location //x:y)`를 사용하거나 `srcs`의 유일한 항목인 경우 `$<`를 사용하여 가져올 수 있습니다.
`outs`	파일 이름 목록입니다. 구성할 수 없음. 필수사항 이 규칙에 의해 생성된 파일 목록입니다. 출력 파일은 패키지 경계를 넘지 않아야 합니다. 출력 파일 이름은 패키지를 기준으로 해석됩니다. `executable` 플래그가 설정된 경우 `outs`에는 라벨이 정확히 하나 포함되어야 합니다. genrule 명령어는 사전 지정된 위치에 각 출력 파일을 만들어야 합니다. 이 위치는 genrule별 'Make' 변수(`$@`, `$(OUTS)`, `$(@D)` 또는 `$(RULEDIR)`)를 사용하거나 `$(location)` 대체를 사용하여 `cmd`에서 사용할 수 있습니다.
`cmd`	문자열, 기본값은 `""`입니다. 실행할 명령어입니다. `$(location)` 및 'Make' 변수 대체가 적용됩니다. 먼저 `$(location)` 대체가 적용되어 `$(location label)` 및 `$(locations label)`의 모든 인스턴스(및 관련 변수 `execpath`, `execpaths`, `rootpath`, `rootpaths`를 사용하는 유사한 구성)가 대체됩니다. 그런 다음 'Make' 변수가 펼쳐집니다. 사전 정의된 변수 `$(JAVA)`, `$(JAVAC)`, `$(JAVABASE)`는 exec 구성에서 확장되므로 빌드 단계의 일부로 실행되는 Java 호출은 공유 라이브러리 및 기타 종속 항목을 올바르게 로드할 수 있습니다. 마지막으로 결과 명령어는 Bash 셸을 사용하여 실행됩니다. 종료 코드가 0이 아니면 명령어가 실패한 것으로 간주됩니다. `cmd_bash`, `cmd_ps`, `cmd_bat` 중 어느 것도 적용되지 않는 경우의 대체입니다. 명령줄 길이가 플랫폼 한도 (Linux/macOS의 경우 64K, Windows의 경우 8K)를 초과하면 genrule가 명령어를 스크립트에 작성하고 해당 스크립트를 실행하여 문제를 해결합니다. 이는 모든 cmd 속성 (`cmd`, `cmd_bash`, `cmd_ps`, `cmd_bat`)에 적용됩니다.
`cmd_bash`	문자열, 기본값은 `""`입니다. 실행할 Bash 명령어 이 속성은 `cmd`보다 우선순위가 높습니다. 명령어가 확장되어 `cmd` 속성과 똑같은 방식으로 실행됩니다.
`cmd_bat`	문자열, 기본값은 `""`입니다. Windows에서 실행할 일괄 명령어입니다. 이 속성은 `cmd` 및 `cmd_bash`보다 우선순위가 높습니다. 이 명령어는 `cmd` 속성과 유사한 방식으로 실행되지만 다음과 같은 차이점이 있습니다. 이 속성은 Windows에서만 적용됩니다. 이 명령어는 다음과 같은 기본 인수와 함께 `cmd.exe /c`로 실행됩니다. `/S` - 첫 번째와 마지막 따옴표를 삭제하고 나머지는 있는 그대로 실행합니다. `/E:ON` - 확장 명령어 집합을 사용 설정합니다. `/V:ON` - 지연된 변수 확장 사용 설정 `/D` - 자동 실행 레지스트리 항목을 무시합니다. $(location) 및 "Make" 변수 대체 이후에는 경로가 Windows 스타일 경로 (백슬래시 사용)로 확장됩니다.
`cmd_ps`	문자열, 기본값은 `""`입니다. 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로 변경합니다.
`executable`	부울. 구성 불가능. 기본값은 `False`입니다. 출력을 실행 파일로 선언합니다. 이 플래그를 true로 설정하면 출력이 실행 파일이며 `run` 명령어를 사용하여 실행할 수 있음을 의미합니다. 이 경우 genrule은 정확히 하나의 출력을 생성해야 합니다. 이 속성을 설정하면 `run`는 내용에 상관없이 파일을 실행하려고 시도합니다. 생성된 실행 파일의 데이터 종속 항목을 선언하는 것은 지원되지 않습니다.
`local`	불리언. 기본값은 `False`입니다. 이 옵션을 True로 설정하면 이 `genrule`가 '로컬' 전략을 사용하여 강제로 실행됩니다. 즉, 원격 실행, 샌드박스, 영구 작업자가 없습니다. 이는 'local'을 태그 (`tags=["local"]`)로 제공하는 것과 같습니다.
`message`	문자열, 기본값은 `""`입니다. 진행률 메시지 이 빌드 단계가 실행될 때 출력되는 진행률 메시지입니다. 기본적으로 메시지는 '출력 생성 중' (또는 이와 비슷한 내용)이지만 더 구체적인 메시지를 제공할 수도 있습니다. `cmd` 명령어에서 `echo` 또는 다른 출력 문이 아닌 이 속성을 사용하면 빌드 도구에서 이러한 진행률 메시지가 출력되는지 여부를 제어할 수 있습니다.
`output_licenses`	라이선스 유형입니다. 기본값은 `["none"]`입니다. `common attributes` 참조
`output_to_bindir`	불리언. 구성 불가. 기본값은 `False`입니다. 이 옵션을 True로 설정하면 출력 파일이 `genfiles` 디렉터리가 아닌 `bin` 디렉터리에 작성됩니다.
`toolchains`	라벨 목록입니다. 구성할 수 없음. 기본값은 `[]`입니다. 이 genrule이 액세스할 수 있는 Make 변수의 타겟 세트 또는 이 genrule이 액세스할 `toolchain_type` 타겟입니다. `toolchain_type`를 통해 액세스하는 도구 모음은 타겟이 도구 모음 세부정보에 액세스하는 데 사용할 수 있는 `TemplateVariableInfo` 제공자도 제공해야 합니다.
`tools`	라벨 목록. 기본값은 `[]`입니다. 이 규칙의 도구 종속 항목 목록입니다. 자세한 내용은 종속 항목의 정의를 참고하세요. 빌드 시스템은 genrule 명령어를 실행하기 전에 이러한 기본 요건이 빌드되도록 합니다. 이러한 도구는 빌드의 일부로 실행되므로 exec 구성을 사용하여 빌드됩니다. 개별 `tools` 타겟 `//x:y`의 경로는 `$(location //x:y)`를 사용하여 가져올 수 있습니다. `cmd`에서 실행할 `*_binary` 또는 도구는 올바른 구성으로 빌드되도록 `srcs`이 아닌 이 목록에 표시되어야 합니다.

starlark_doc_extract

규칙 소스 보기

starlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)

starlark_doc_extract()는 지정된 .bzl 또는 .scl 파일에서 정의되거나 다시 내보낸 규칙, 함수 (매크로 포함), 관점, 제공자에 관한 문서를 추출합니다. 이 규칙의 출력은 Bazel 소스 트리의 stardoc_output.proto에 정의된 ModuleInfo 바이너리 proto입니다.

암시적 출력 타겟

name.binaryproto(기본 출력): ModuleInfo 바이너리 프로토입니다.
name.textproto(명시적으로 요청된 경우에만 빌드됨): name.binaryproto의 텍스트 프로토 버전입니다.

경고: 이 규칙의 출력 형식은 안정적이지 않을 수 있습니다. 주로 Stardoc에서 내부용으로 사용합니다.

인수

속성
`name`	이름: 필수사항 이 타겟의 고유한 이름입니다.
`deps`	라벨 목록입니다. 기본값은 `[]`입니다. `src`에 의해 `load()`된 Starlark 파일을 래핑하는 타겟 목록입니다. 이러한 타겟은 일반적인 사용 시 `bzl_library` 타겟이 어야 하지만 `starlark_doc_extract` 규칙은 이를 적용하지 않으며 `DefaultInfo`에 Starlark 파일을 제공하는 모든 타겟을 허용합니다. 래핑된 Starlark 파일은 소스 트리의 파일이어야 합니다. Bazel은 생성된 파일을 `load()`할 수 없습니다.
`src`	라벨: 필수사항 문서를 추출할 Starlark 파일입니다. 이 파일은 소스 트리의 파일이어야 합니다. Bazel은 생성된 파일을 `load()`할 수 없습니다.
`render_main_repo_name`	불리언. 기본값은 `False`입니다. 이 속성이 true이면 리포 저장소 구성요소를 사용하여 내보낸 문서에서 기본 저장소의 라벨을 렌더링합니다. 즉, `//foo:bar.bzl`가 `@main_repo_name//foo:bar.bzl`로 내보내집니다. 기본 저장소에 사용할 이름은 기본 저장소의 `MODULE.bazel` 파일 (Bzlmod가 사용 설정된 경우)의 `module(name = ...)` 또는 기본 저장소의 `WORKSPACE` 파일에 있는 `workspace(name = ...)`에서 가져옵니다. 이 속성은 동일한 저장소 내에서만 사용하려는 Starlark 파일의 문서를 생성할 때는 `False`로, 다른 저장소에서 사용하려는 Starlark 파일의 문서를 생성할 때는 `True`로 설정해야 합니다.
`symbol_names`	문자열 목록입니다. 기본값은 `[]`입니다. 문서를 추출할 내보낸 함수, 규칙, 제공자, 관점(또는 중첩된 구조체)의 정규화된 이름 목록입니다(선택사항). 여기서 정규화된 이름은 네임스페이스화의 목적으로 항목이 중첩된 모든 구조체를 포함하여 모듈의 사용자가 항목을 사용할 수 있는 이름을 의미합니다. `starlark_doc_extract`는 다음과 같은 경우에만 항목에 관한 문서를 내보냅니다. 항목의 정규화된 이름의 각 구성요소가 공개됩니다 (즉, 정규화된 이름의 각 구성요소의 첫 번째 문자가 `"_"`가 아닌 영문자임). 그리고 `symbol_names` 목록이 비어 있거나(기본값) 또는 항목의 정규화된 이름 또는 항목이 중첩되어 있는 구조체의 정규화된 이름은 `symbol_names` 목록에 있습니다.

test_suite

규칙 소스 보기

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

test_suite는 인간에게 '유용'하다고 간주되는 테스트 집합을 정의합니다. 이를 통해 프로젝트에서 '체크인 전에 실행해야 하는 테스트', '프로젝트의 스트레스 테스트', '모든 소규모 테스트'와 같은 테스트 세트를 정의할 수 있습니다. bazel test 명령어는 이러한 종류의 구성을 따릅니다. bazel test //some/test:suite와 같은 호출의 경우 Bazel은 먼저 //some/test:suite 대상에 의해 전이적으로 포함된 모든 테스트 대상을 열거합니다 (이를 'test_suite 확장'이라고 함). 그런 다음 Bazel은 이러한 대상을 빌드하고 테스트합니다.

예

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

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

이름: 필수사항

이 타겟의 고유한 이름입니다.

tags

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

'small', 'database' 또는 '-flaky'와 같은 텍스트 태그 목록입니다. 태그는 유효한 문자열이면 됩니다.

'-' 문자로 시작하는 태그는 음수 태그로 간주됩니다. 앞의 '-' 문자는 태그의 일부로 간주되지 않으므로 '-small' 도구 모음 태그는 테스트의 'small' 크기와 일치합니다. 다른 모든 태그는 양수 태그로 간주됩니다.

원하는 경우 긍정적인 태그를 더 명시적으로 만들기 위해 태그를 '+' 문자로 시작할 수도 있습니다. 이 경우 태그 텍스트의 일부로 평가되지 않습니다. 긍정과 부정을 더 쉽게 구분할 수 있을 뿐입니다.

양성 태그 모두와 일치하고 음성 태그 없음과 일치하는 테스트 규칙만 테스트 모음에 포함됩니다. 그렇다고 필터링된 테스트의 종속 항목에 대한 오류 검사가 건너뛰어지는 것은 아닙니다. 건너뛴 테스트의 종속 항목은 여전히 유효해야 합니다(예: 공개 범위 제약 조건으로 차단되지 않음).

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

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

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

tests

라벨 목록입니다. 구성할 수 없음. 기본값은 []입니다.

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

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

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