.bzl 파일

_로 시작하는 암시적 속성에는 기본값이 있어야 하며 label 또는 label_list 유형이어야 합니다.

명시적 속성은 string 유형이어야 하며 values 제한을 사용해야 합니다. 명시적 속성은 제한사항에 따라 동일한 이름, 유형, 유효한 값의 속성이 있는 규칙에만 사용되도록 관점을 제한합니다.

중첩되지 않은 제공업체 목록은 제공업체 목록 1개가 포함된 목록으로 자동 변환됩니다. 즉, [FooInfo, BarInfo]가 [[FooInfo, BarInfo]]로 자동 변환됩니다.

일부 규칙 (예: some_rule) 대상이 특정 관점에 표시되도록 하려면 some_rule에서 하나 이상의 필수 제공업체 목록에 있는 모든 제공업체를 광고해야 합니다. 예를 들어 관점의 required_providers가 [[FooInfo], [BarInfo], [BazInfo, QuxInfo]]인 경우 some_rule가 FooInfo 또는 BarInfo 또는 BazInfo 및 QuxInfo를 모두 제공하는 경우에만 some_rule 타겟을 볼 수 있습니다.

중첩되지 않은 제공업체 목록은 제공업체 목록 1개가 포함된 목록으로 자동 변환됩니다. 즉, [FooInfo, BarInfo]가 [[FooInfo, BarInfo]]로 자동 변환됩니다.

이 관점에 다른 관점 (예: other_aspect)이 표시되도록 하려면 other_aspect에서 목록 중 하나 이상의 모든 제공자를 제공해야 합니다. [[FooInfo], [BarInfo], [BazInfo, QuxInfo]]의 예에서 other_aspect가 FooInfo 또는 BarInfo 또는 BazInfo 및 QuxInfo를 모두 제공하는 경우에만 other_aspect를 볼 수 있습니다.

구현 함수가 여기에 나열된 제공자 유형을 반환 값에서 생략하면 오류입니다. 그러나 구현 함수는 여기에 나열되지 않은 추가 제공자를 반환할 수도 있습니다.

목록의 각 요소는 provider()에서 반환하는 *Info 객체입니다. 단, 기존 제공자는 문자열 이름으로 표시됩니다. 규칙의 대상이 필요한 제공자를 선언하는 타겟의 종속 항목으로 사용되는 경우 여기에서 해당 제공자를 지정할 필요가 없습니다. 구현 함수가 이를 반환하는 것으로 충분합니다. 필수 사항은 아니지만 지정하는 것이 좋습니다. 하지만 측면의 required_providers 필드를 사용하려면 제공자를 여기에 지정해야 합니다.

예를 들어 관점이 `deps` 속성을 통해 전이적으로 전파되고 `alpha`를 타겟팅하는 데 적용된다고 가정해 보겠습니다. `alpha` 에 `deps = [':beta_output']`이 있다고 가정해 보겠습니다. 여기서 `beta_output` 은 타겟 `beta`의 선언된 출력입니다. `beta` 에 타겟 `charlie` 가 `deps` 중 하나로 있다고 가정해 보겠습니다. 관점에 `apply_to_generating_rules=True` 인 경우 관점은 `alpha`, `beta`, `charlie`를 통해 전파됩니다. False인 경우 관점은 `alpha`로만 전파됩니다.

기본값은 false입니다.

• 필드 목록:
  

  provider(fields = ['a', 'b'])

• 사전 필드 이름 -> 문서:
  

  provider(
         fields = { 'a' : 'Documentation for a', 'b' : 'Documentation for b' })

정확한 설명은 다음과 같습니다. 직관적인 논의 및 사용 사례는 규칙 (제공업체 맞춤 초기화)을 참고하세요.

P를 provider()를 호출하여 만든 제공자 기호로 둡니다. 개념적으로 P 인스턴스는 다음을 실행하는 기본 생성자 함수 c(*args, **kwargs)를 호출하여 생성됩니다.

• args가 비어 있지 않으면 오류가 발생합니다.
• provider()가 호출될 때 fields 매개변수가 지정되었고 kwargs에 fields에 나열되지 않은 키가 포함되어 있으면 오류가 발생합니다.
• 그렇지 않으면 c는 kwargs의 각 k: v 항목에 대해 값이 v인 k라는 필드가 포함된 새 인스턴스를 반환합니다.

MyInfo = provider()
m = MyInfo(foo = 1)

그러나 init가 지정된 경우 P(*args, **kwargs) 호출은 대신 다음 단계를 실행합니다.

1. 콜백은 init(*args, **kwargs)로 호출됩니다. 즉, P에 전달된 것과 정확히 동일한 위치 및 키워드 인수를 사용합니다.
2. init의 반환 값은 키가 필드 이름 문자열인 d 사전이어야 합니다. 그렇지 않은 경우 오류가 발생합니다.
3. c(**d)에서와 같이 d의 항목을 키워드 인수로 사용하여 기본 생성자를 호출하는 것처럼 P의 새 인스턴스가 생성됩니다.

참고: 위 단계는 *args 또는 **kwargs가 init의 서명과 일치하지 않거나 init의 본문 평가가 실패하거나 (의도적으로 fail() 호출을 통해) init의 반환 값이 예상 스키마가 포함된 사전이 아닌 경우 오류가 발생함을 암시합니다.

이러한 방식으로 init 콜백은 전처리와 검증을 위한 위치 인수와 임의의 로직을 허용하여 일반 제공자 생성을 일반화합니다. 허용된 fields 목록의 우회를 사용 설정하지 않습니다.

init가 지정되면 provider()의 반환 값은 튜플 (P, r)이 되며, 여기서 r는 원시 생성자입니다. 실제로 r의 동작은 위에서 설명한 기본 생성자 함수 c의 동작과 정확히 일치합니다. 일반적으로 r는 이름에 밑줄이 붙은 변수에 결합되어 있으므로 현재 .bzl 파일만 이 변수에 직접 액세스할 수 있습니다.

MyInfo, _new_myinfo = provider(init = ...)

사전 선언된 출력을 정의하기 위한 스키마입니다. output 및 output_list 속성과 달리 사용자는 이러한 파일의 라벨을 지정하지 않습니다. 사전 선언된 출력에 관한 자세한 내용은 규칙 페이지를 참고하세요.

이 인수의 값은 사전 또는 사전을 생성하는 콜백 함수입니다. 콜백은 계산된 종속 항목 속성과 유사하게 작동합니다. 함수의 매개변수 이름은 규칙의 속성과 일치하므로 예를 들어 def _my_func(srcs, deps): ... 정의로 outputs = _my_func를 전달하면 함수가 srcs 및 deps 속성에 액세스할 수 있습니다. 사전이 직접 지정되거나 함수를 통해 지정되면 다음과 같이 해석됩니다.

사전의 각 항목은 키가 식별자이고 값은 출력 라벨을 결정하는 문자열 템플릿인 사전 선언된 출력을 생성합니다. 규칙의 구현 함수에서 식별자는 ctx.outputs에서 출력의 File에 액세스하는 데 사용되는 필드 이름이 됩니다. 출력 라벨에는 규칙과 동일한 패키지가 있으며 패키지 뒷부분은 "%{ATTR}" 형식의 각 자리표시자를 ATTR 속성 값으로 구성된 문자열로 대체하여 생성됩니다.

• 문자열 유형 속성은 그대로 대체됩니다.
• 라벨 유형 속성은 패키지 뒤에서 파일 확장자를 뺀 라벨의 일부가 됩니다. 예를 들어 "//pkg:a/b.c" 라벨은 "a/b"가 됩니다.
• 출력 유형 속성은 패키지 뒤에서 라벨의 일부가 되며 파일 확장자 (위의 예의 경우 "a/b.c")도 포함됩니다.
• 자리표시자에 사용되는 모든 목록 유형 속성 (예: attr.label_list)은 정확히 하나의 요소를 포함해야 합니다. 전환이 비목록 버전 (attr.label)과 동일합니다.
• 다른 속성 유형은 자리표시자에 표시되지 않을 수 있습니다.
• 속성이 아닌 특수 자리표시자 %{dirname} 및 %{basename}는 패키지를 제외하고 규칙 라벨의 해당 부분으로 확장됩니다. 예를 들어 "//pkg:a/b.c"에서 dirname은 a이고 기본 이름은 b.c입니다.

실제로 가장 일반적인 대체 자리표시자는 "%{name}"입니다. 예를 들어 이름이 'foo'인 대상의 경우 출력 dict {"bin": "%{name}.exe"}는 구현 함수에서 ctx.outputs.bin로 액세스할 수 있는 foo.exe라는 출력을 사전 선언합니다.

구현 함수가 여기에 나열된 제공자 유형을 반환 값에서 생략하면 오류입니다. 그러나 구현 함수는 여기에 나열되지 않은 추가 제공자를 반환할 수도 있습니다.

목록의 각 요소는 provider()에서 반환하는 *Info 객체입니다. 단, 기존 제공자는 문자열 이름으로 표시됩니다. 규칙의 대상이 필요한 제공자를 선언하는 타겟의 종속 항목으로 사용되는 경우 여기에서 해당 제공자를 지정할 필요가 없습니다. 구현 함수가 이를 반환하는 것으로 충분합니다. 필수 사항은 아니지만 지정하는 것이 좋습니다. 하지만 측면의 required_providers 필드를 사용하려면 제공자를 여기에 지정해야 합니다.

참고: 분석 테스트 규칙은 주로 핵심 Starlark 라이브러리에서 제공되는 인프라를 사용하여 정의됩니다. 자세한 내용은 테스트를 참고하세요.

규칙이 분석 테스트 규칙으로 정의되면 속성에 analysis_test_transition을 사용하여 정의된 구성 전환을 사용할 수 있지만, 몇 가지 제한사항이 적용됩니다.

• 이 규칙의 대상은 보유할 수 있는 전이 종속 항목의 수가 제한됩니다.
• test=True가 설정된 것처럼 이 규칙이 테스트 규칙으로 간주됩니다. 이 값은 test의 값을 대체합니다.
• 규칙 구현 함수에서 작업을 등록할 수 없습니다. 대신 AnalysisTestResultInfo를 제공하여 성공/실패 결과를 등록해야 합니다.

이 함수는 각 규칙 인스턴스가 로드될 때 호출됩니다. name 및 규칙에 의해 정의된 공개 속성 값 (예: tags와 같은 일반 속성이 아님)으로 호출됩니다.

속성 이름에서 원하는 값으로 사전을 반환해야 합니다. 반환되지 않은 속성은 영향을 받지 않습니다. None를 값으로 반환하면 속성 정의에 지정된 기본값이 사용됩니다.

이니셜라이저는 속성 정의에 지정된 기본값 전에 평가됩니다. 따라서 이니셜라이저 서명의 매개변수에 기본값이 포함된 경우 속성 정의의 기본값을 덮어씁니다 (None를 반환하는 경우는 제외).

마찬가지로 이니셜라이저 서명의 매개변수에 기본값이 없으면 매개변수가 필수가 됩니다. 이러한 경우 속성 정의에서 기본/필수 설정을 생략하는 것이 좋습니다.

처리되지 않는 속성에는 **kwargs를 사용하는 것이 좋습니다.

확장 규칙의 경우 하위에서 상위로 이동하는 모든 이니셜라이저가 호출됩니다. 각 이니셜라이저는 알고 있는 공개 속성에만 전달됩니다.

하위 규칙에는 라벨 유형 (즉, 라벨 또는 라벨 목록)이 있는 비공개 속성만 포함될 수 있습니다. 이러한 라벨에 해당하는 결정된 값은 Bazel에 의해 이름이 지정된 인수로 하위 규칙의 구현 함수에 자동으로 전달됩니다. 따라서 구현 함수가 속성 이름과 일치하는 이름이 지정된 매개변수를 허용해야 합니다. 이러한 값의 유형은 다음과 같습니다.

• executable=True가 있는 라벨 속성의 경우 FilesToRunProvider
• allow_single_file=True가 있는 라벨 속성의 경우 File
• 기타 모든 라벨 속성의 경우 Target
• 모든 라벨 목록 속성의 경우 [Target]

패키지 사양은 음수 패키지 사양이 허용되지 않는다는 점을 제외하고 package_group와 동일한 형식을 따릅니다. 즉, 사양의 형식은 다음과 같을 수 있습니다.

• "//foo": //foo 패키지입니다.
• "//foo/...": //foo 패키지 및 모든 하위 패키지입니다.
• "public" 또는 "private": 각각 모든 패키지 또는 패키지 없음

'@' 구문은 허용되지 않습니다. 모든 사양은 현재 모듈의 저장소를 기준으로 해석됩니다.

value가 문자열 목록인 경우 이 모듈에 공개 상태가 부여되는 패키지 세트는 각 사양이 나타내는 패키지의 합집합입니다. 빈 목록은 private와 효과가 같습니다. value가 단일 문자열이면 싱글톤 목록 [value]인 것처럼 처리됩니다.

--incompatible_package_group_has_public_syntax 및 --incompatible_fix_package_group_reporoot_syntax 플래그는 이 인수에 영향을 미치지 않습니다. "public" 및 "private" 값은 항상 사용할 수 있으며 "//..."는 항상 '현재 저장소의 모든 패키지'로 해석됩니다.