이 규칙 집합은 빌드하는 특정 하드웨어 플랫폼을 모델링하고 해당 플랫폼의 코드를 컴파일하는 데 필요한 특정 도구를 지정할 수 있도록 지원하기 위해 존재합니다. 사용자는 여기에 설명된 개념을 숙지하고 있어야 합니다.
규칙
constraint_setting
규칙 소스 보기constraint_setting(name, default_constraint_value, deprecation, distribs, features, licenses, tags, testonly, visibility)
이 규칙은 플랫폼에서 값을 지정할 수 있는 새로운 제약 조건 유형을 도입하는 데 사용됩니다.
예를 들어 'glibc_version'이라는 constraint_setting을 정의하여 플랫폼에 glibc 라이브러리의 여러 버전이 설치될 수 있는 기능을 나타낼 수 있습니다.
자세한 내용은 플랫폼 페이지를 참고하세요.
각 constraint_setting에는 확장 가능한 연결된 constraint_value 집합이 있습니다. 일반적으로 이러한 설정은 동일한 패키지에 정의되지만 다른 패키지에서 기존 설정에 새 값을 도입하는 경우도 있습니다. 예를 들어 사전 정의된 설정 @platforms//cpu:cpu를 맞춤 값으로 확장하여 모호한 CPU 아키텍처를 타겟팅하는 플랫폼을 정의할 수 있습니다.
인수
| 속성 | |
|---|---|
name |
이름: 필수사항 이 타겟의 고유한 이름입니다. |
default_constraint_value
|
값이 제공되지 않은 경우 사용되는 이 설정의 기본값 라벨입니다. 이 속성이 있는 경우 이 속성이 가리키는 constraint_value는 이 constraint_setting와 동일한 패키지에 정의되어야 합니다.
제약 조건 설정에 기본값이 있는 경우 플랫폼이 해당 설정의 제약 조건 값을 포함하지 않을 때마다 플랫폼에서 기본값을 지정한 것과 동일합니다. 기본값이 없는 경우 제약 조건 설정은 해당 플랫폼에서 지정되지 않은 것으로 간주됩니다. 이 경우 플랫폼은 해당 설정에 특정 값이 필요한 제약 조건 목록 (예: |
constraint_value
규칙 소스 보기constraint_value(name, constraint_setting, deprecation, distribs, features, licenses, tags, testonly, visibility)
예
다음은 CPU 아키텍처를 나타내는 사전 정의된 constraint_value의 새로운 가능한 값을 만듭니다.
constraint_value(
name = "mips",
constraint_setting = "@platforms//cpu:cpu",
)
x86_64, arm 등의 대안으로 mips 아키텍처를 보유하고 있다고 선언할 수 있습니다.
인수
| 속성 | |
|---|---|
name |
이름: 필수사항 이 타겟의 고유한 이름입니다. |
constraint_setting
|
이 constraint_value가 가능한 선택사항인 constraint_setting입니다.
|
platform
규칙 소스 보기platform(name, constraint_values, deprecation, distribs, exec_properties, features, flags, licenses, parents, remote_execution_properties, required_settings, tags, testonly, visibility)
이 규칙은 빌드의 일부가 실행될 수 있는 환경을 설명하는 제약 조건 선택사항(예: CPU 아키텍처 또는 컴파일러 버전)의 이름이 지정된 모음인 새 플랫폼을 정의합니다. 자세한 내용은 플랫폼 페이지를 참고하세요.
예
이는 ARM에서 Linux를 실행하는 모든 환경을 설명하는 플랫폼을 정의합니다.
platform(
name = "linux_arm",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:arm",
],
)
플랫폼 플래그
플랫폼은 flags 속성을 사용하여 플랫폼이 타겟 플랫폼 (즉, --platforms 플래그의 값)으로 사용될 때마다 구성에 추가할 플래그 목록을 지정할 수 있습니다.
플랫폼에서 설정된 플래그는 사실상 가장 높은 우선순위를 가지며 명령줄, rc 파일 또는 전환에서 해당 플래그의 이전 값을 덮어씁니다.
예
platform(
name = "foo",
flags = [
"--dynamic_mode=fully",
"--//bool_flag",
"--no//package:other_bool_flag",
],
)
그러면 foo라는 플랫폼이 정의됩니다. 이 플랫폼이 타겟 플랫폼인 경우 (사용자가 --platforms//:foo를 지정했거나, 전환이 //command_line_option:platforms 플래그를 ["//:foo"]로 설정했거나, //:foo가 실행 플랫폼으로 사용되었기 때문에) 지정된 플래그가 구성에 설정됩니다.
플랫폼 및 반복 가능한 플래그
일부 플래그(예: --features, --copt, config.string(repeatable = True)로 생성된 모든 Starlark 플래그)는 반복될 때 값을 누적합니다.
이러한 플래그는 플랫폼에서 플래그를 설정하는 것과 호환되지 않습니다. 대신 이전의 모든 값이 삭제되고 플랫폼의 값으로 덮어쓰기됩니다.
예를 들어 다음 플랫폼을 사용하면 호출 build --platforms=//:repeat_demo
--features feature_a --features feature_b의 결과로 --feature 플래그 값이 ["feature_c", "feature_d"]가 되어 명령줄에 설정된 기능이 삭제됩니다.
platform(
name = "repeat_demo",
flags = [
"--features=feature_c",
"--features=feature_d",
],
)
따라서 flags 속성에는 반복 가능한 플래그를 사용하지 않는 것이 좋습니다.
플랫폼 상속
플랫폼은 parents 속성을 사용하여 제약 조건 값을 상속할 다른 플랫폼을 지정할 수 있습니다. parents 속성은 목록을 사용하지만 현재 하나 이상의 값은 지원되지 않으며 여러 상위 요소를 지정하면 오류가 발생합니다.
플랫폼에서 제약 조건 설정의 값을 확인할 때는 먼저 constraint_values 속성을 통해 직접 설정된 값이 확인된 후 상위 요소의 제약 조건 값이 확인됩니다. 이는 상위 플랫폼 체인을 따라 재귀적으로 계속 진행됩니다. 이렇게 하면 플랫폼에 직접 설정된 값이 상위 요소에 설정된 값보다 우선 적용됩니다.
플랫폼은 상위 플랫폼에서 exec_properties 속성을 상속합니다.
상위 플랫폼과 하위 플랫폼의 exec_properties에 있는 사전 항목이 결합됩니다.
상위 요소와 하위 요소의 exec_properties에 동일한 키가 표시되면 하위 요소의 값이 사용됩니다. 하위 플랫폼에서 빈 문자열을 값으로 지정하면 해당 속성이 설정 해제됩니다.
플랫폼은 상위 플랫폼에서 지원 중단된 remote_execution_properties 속성을 상속할 수도 있습니다. 참고: 새 코드는 대신 exec_properties를 사용해야 합니다. 아래에 설명된 로직은 기존 동작과 호환되도록 유지되지만 향후 삭제될 예정입니다.
상위 플랫폼이 있는 경우 remote_execution_platform를 설정하는 로직은 다음과 같습니다.
-
하위 플랫폼에서
remote_execution_property가 설정되지 않으면 상위의remote_execution_properties가 사용됩니다. -
remote_execution_property가 하위 플랫폼에 설정되어 있고 리터럴 문자열 {PARENT_REMOTE_EXECUTION_PROPERTIES}를 포함하는 경우 이 매크로는 상위 요소의remote_execution_property속성 콘텐츠로 대체됩니다. -
remote_execution_property가 하위 플랫폼에 설정되어 있고 매크로를 포함하지 않는 경우 하위의remote_execution_property가 변경되지 않고 사용됩니다.
remote_execution_properties는 지원 중단되었으며 단계적으로 지원 중단될 예정이므로 동일한 상속 체인에서 remote_execution_properties와 exec_properties를 혼합할 수 없습니다.
지원 중단된 remote_execution_properties 대신 exec_properties를 사용하는 것이 좋습니다.
예: 제약 조건 값
platform(
name = "parent",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:arm",
],
)
platform(
name = "child_a",
parents = [":parent"],
constraint_values = [
"@platforms//cpu:x86_64",
],
)
platform(
name = "child_b",
parents = [":parent"],
)
이 예에서 하위 플랫폼에는 다음과 같은 속성이 있습니다.
-
child_a에는 제약 조건 값@platforms//os:linux(상위 요소에서 상속됨) 및@platforms//cpu:x86_64(플랫폼에서 직접 설정됨)가 있습니다. -
child_b는 상위 요소에서 모든 제약 조건 값을 상속하며 자체 값은 설정하지 않습니다.
예: 실행 속성
platform(
name = "parent",
exec_properties = {
"k1": "v1",
"k2": "v2",
},
)
platform(
name = "child_a",
parents = [":parent"],
)
platform(
name = "child_b",
parents = [":parent"],
exec_properties = {
"k1": "child"
}
)
platform(
name = "child_c",
parents = [":parent"],
exec_properties = {
"k1": ""
}
)
platform(
name = "child_d",
parents = [":parent"],
exec_properties = {
"k3": "v3"
}
)
이 예에서 하위 플랫폼에는 다음과 같은 속성이 있습니다.
-
child_a는 상위의 'exec_properties'를 상속하고 자체 속성을 설정하지 않습니다. -
child_b는 상위 요소의exec_properties를 상속하고k1의 값을 재정의합니다.exec_properties은{ "k1": "child", "k2": "v2" }입니다. -
child_c는 상위 요소의exec_properties를 상속하고k1를 설정 해제합니다.exec_properties은{ "k2": "v2" }입니다. -
child_d는 상위의exec_properties를 상속하고 새 속성을 추가합니다.exec_properties은{ "k1": "v1", "k2": "v2", "k3": "v3" }입니다.
인수
| 속성 | |
|---|---|
name |
이름: 필수사항 이 타겟의 고유한 이름입니다. |
constraint_values
|
라벨 목록입니다. 구성할 수 없음. 기본값은 이 목록의 각 |
exec_properties
|
사전: 문자열 -> 문자열; 구성 불가; 기본값은 exec_properties 속성의 모든 데이터가 포함됩니다.
하위 플랫폼과 상위 플랫폼에서 동일한 키를 정의하는 경우 하위 요소의 값이 유지됩니다. 빈 문자열 값과 연결된 모든 키가 사전에서 삭제됩니다.
이 속성은 지원 중단된 remote_execution_properties를 완전히 대체합니다.
|
flags
|
문자열 목록입니다. 구성 불가. 기본값은 |
parents
|
라벨 목록입니다. 구성할 수 없음. 기본값은 platform 타겟의 라벨입니다. 이 속성은 목록을 사용하지만 플랫폼은 하나만 있어야 합니다. 이 플랫폼에서 직접 설정되지 않은 constraint_settings는 상위 플랫폼에서 찾을 수 있습니다.
자세한 내용은 플랫폼 상속 섹션을 참고하세요.
|
remote_execution_properties
|
문자열, 구성 불가, 기본값은 |
required_settings
|
라벨 목록입니다. 기본값은 config_setting 목록입니다.
필수 설정은 상위 플랫폼에서 상속되지 않습니다.
|
도구 모음
규칙 소스 보기toolchain(name, deprecation, distribs, exec_compatible_with, features, licenses, tags, target_compatible_with, target_settings, testonly, toolchain, toolchain_type, visibility)
이 규칙은 도구 모음 확인 중에 선택할 수 있도록 특정 도구 모음의 유형과 제약조건을 선언합니다. 자세한 내용은 툴체인 페이지를 참고하세요.
인수
| 속성 | |
|---|---|
name |
이름: 필수사항 이 타겟의 고유한 이름입니다. |
exec_compatible_with
|
라벨 목록입니다. 구성할 수 없음. 기본값은 constraint_value 목록입니다.
|
target_compatible_with
|
라벨 목록입니다. 구성할 수 없음. 기본값은 constraint_value 목록입니다.
|
target_settings
|
라벨 목록입니다. 기본값은 config_setting 목록입니다.
|
toolchain
|
이름: 필수사항 이 도구 모음이 선택되었을 때 사용할 수 있는 실제 도구 또는 도구 모음을 나타내는 타겟입니다. |
toolchain_type
|
이 도구 모음이 제공하는 역할을 나타내는 toolchain_type 타겟의 라벨입니다.
|
toolchain_type
규칙 소스 보기toolchain_type(name, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
이 규칙은 새로운 유형의 도구 모음을 정의합니다. 즉, 다양한 플랫폼에서 동일한 역할을 하는 도구 클래스를 나타내는 간단한 타겟입니다.
자세한 내용은 툴체인 페이지를 참고하세요.
예
이렇게 하면 맞춤 규칙의 도구 모음 유형이 정의됩니다.
toolchain_type(
name = "bar_toolchain_type",
)
bzl 파일에서 사용할 수 있습니다.
bar_binary = rule(
implementation = _bar_binary_impl,
attrs = {
"srcs": attr.label_list(allow_files = True),
...
# No `_compiler` attribute anymore.
},
toolchains = ["//bar_tools:toolchain_type"]
)
인수
| 속성 | |
|---|---|
name |
이름: 필수사항 이 타겟의 고유한 이름입니다. |