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

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

플랫폼을 이용한 빌드

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

Bazel은 플랫폼 및 툴체인 모델링을 위한 정교한 지원을 제공합니다. 이를 실제 프로젝트와 통합하려면 코드 소유자, 규칙 유지관리자, 핵심 Bazel 개발자 간의 신중한 협력이 필요합니다.

이 페이지에서는 플랫폼의 목적을 요약하고 플랫폼을 사용하여 빌드하는 방법을 보여줍니다.

요약: Bazel의 플랫폼 및 도구 모음 API는 사용할 수 있지만 모든 언어 규칙, select() 및 기타 기존 참조가 업데이트될 때까지는 모든 곳에서 작동하지 않습니다. 이 같은 노력은 현재도 진행 중입니다. 결국 모든 빌드는 플랫폼 기반이 될 것입니다. 아래에서 빌드가 어디에 적합한지 알아보세요.

보다 공식적인 문서는 다음을 참고하세요.

배경

플랫폼 및 툴체인은 소프트웨어 프로젝트가 여러 머신을 타겟팅하고 적절한 언어 도구로 빌드하는 방식을 표준화하기 위해 도입되었습니다.

이는 Bazel에 비교적 최근에 추가된 기능입니다. 이는 언어 유지관리자가 이미 비호환적인 임시 방식으로 이를 실행하고 있다는 관찰에 영감을 얻은 것입니다. 예를 들어 C++ 규칙은 --cpu 및 --crosstool_top를 사용하여 빌드의 대상 CPU 및 C++ 도구 모음을 설정합니다. 둘 다 '플랫폼'을 올바르게 모델링하지 않습니다. 이전에 이를 시도한 결과 불편하고 부정확한 빌드가 발생했습니다. 또한 이러한 플래그는 --java_toolchain를 통해 자체 독립형 인터페이스를 발전시킨 Java 컴파일을 제어하지 않습니다.

Bazel은 대규모 다중 언어 다중 플랫폼 프로젝트를 위해 설계되었습니다. 이를 위해서는 언어 및 프로젝트 상호 운용성을 장려하는 명확한 API를 비롯하여 이러한 개념에 대한 원칙에 입각한 지원이 더 필요합니다. 이러한 새로운 API는 이를 위해 마련되었습니다.

마이그레이션

플랫폼 및 도구 모음 API는 프로젝트에서 실제로 사용할 때만 작동합니다. 이는 프로젝트의 규칙 로직, 도구 모음, 종속 항목, select()가 이를 지원해야 하므로 간단하지 않습니다. 이를 위해서는 모든 프로젝트와 종속 항목이 올바르게 작동하도록 신중하게 마이그레이션 시퀀스를 진행해야 합니다.

예를 들어 Bazel의 C++ 규칙은 플랫폼을 지원합니다. 하지만 Apple 규칙은 그렇지 않습니다. 내 C++ 프로젝트는 Apple을 고려하지 않을 수 있습니다. 하지만 그렇지 않은 경우도 있습니다. 따라서 아직 모든 C++ 빌드에 대해 전 세계적으로 플랫폼을 사용 설정하는 것은 안전하지 않습니다.

이 페이지의 나머지 부분에서는 이 이전 시퀀스와 프로젝트를 적용할 수 있는 방법과 시기를 설명합니다.

목표

모든 프로젝트가 다음 형식으로 빌드되면 Bazel의 플랫폼 이전이 완료됩니다.

bazel build //:myproject --platforms=//:myplatform

이는 다음을 의미합니다.

프로젝트에서 사용하는 규칙은 //:myplatform에서 올바른 도구 모음을 추론할 수 있습니다.
프로젝트의 종속 항목에서 사용하는 규칙은 //:myplatform에서 올바른 도구 모음을 추론할 수 있습니다.
내 프로젝트에 종속된 프로젝트가 //:myplatform를 지원하거나 또는 내 프로젝트가 기존 API (예: --crosstool_top)를 지원합니다.
//:myplatform는 자동 교차 프로젝트 호환성을 지원하는 CPU, OS 및 기타 일반 개념의 [공통 선언][공통 플랫폼 선언]{: .external}을 참조합니다.
모든 관련 프로젝트의 select()는 //:myplatform에 의해 암시된 머신 속성을 이해합니다.
//:myplatform는 재사용 가능한 명확한 위치에 정의됩니다. 플랫폼이 프로젝트에 고유한 경우 프로젝트 저장소에 정의되고, 그렇지 않은 경우에는 이 플랫폼을 사용할 수 있는 모든 프로젝트에서 찾을 수 있는 위치에 정의됩니다.

이 목표가 달성되는 즉시 이전 API가 삭제됩니다. 그러면 프로젝트에서 플랫폼과 도구 모음을 선택하는 표준 방법이 됩니다.

플랫폼을 사용해야 하나요?

프로젝트를 빌드하거나 크로스 컴파일하기만 하면 되는 경우 프로젝트의 공식 문서를 따라야 합니다.

프로젝트, 언어 또는 도구 모음 유지관리자는 결국 새 API를 지원해야 합니다. 전 세계 이전이 완료될 때까지 기다릴지 아니면 조기에 선택할지는 구체적인 가치 / 비용 요구사항에 따라 다릅니다.

값

--cpu과 같은 하드코딩된 플래그 대신 중요한 정확한 속성에서 select()하거나 도구 모음을 선택할 수 있습니다. 예를 들어 여러 CPU가 동일한 명령 집합을 지원할 수 있습니다.
더 정확한 빌드 위 예에서 --cpu로 select()한 다음 동일한 명령 집합을 지원하는 새 CPU를 추가하면 select()가 새 CPU를 인식하지 못합니다. 하지만 플랫폼의 select()는 정확하게 유지됩니다.
간편한 사용자 환경 모든 프로젝트는 --platforms=//:myplatform를 이해합니다. 명령줄에 여러 언어별 플래그가 필요하지 않습니다.
더 간단한 언어 디자인 모든 언어는 도구 모음을 정의하고, 도구 모음을 사용하고, 플랫폼에 적합한 도구 모음을 선택하기 위한 공통 API를 공유합니다.
대상이 타겟 플랫폼과 호환되지 않는 경우 빌드 및 테스트 단계에서 건너뛸 수 있습니다.

비용

아직 플랫폼을 지원하지 않는 종속 프로젝트는 내 프로젝트와 자동으로 작동하지 않을 수 있습니다.
이를 작동시키려면 추가 임시 유지보수가 필요할 수 있습니다.
신규 API와 기존 API가 공존하는 경우 혼란을 피하기 위해 더 신중한 사용자 안내가 필요합니다.
OS 및 CPU와 같은 일반 속성의 표준 정의는 아직 발전 중이며 추가 초기 참여가 필요할 수 있습니다.
언어별 도구 모음의 표준 정의는 아직 발전 중이며 추가 초기 참여가 필요할 수 있습니다.

API 검토

platform는 constraint_value 타겟의 모음입니다.

platform(
    name = "myplatform",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)

constraint_value은 머신 속성입니다. 동일한 '종류'의 값은 공통 constraint_setting 아래에 그룹화됩니다.

constraint_setting(name = "os")
constraint_value(
    name = "linux",
    constraint_setting = ":os",
)
constraint_value(
    name = "mac",
    constraint_setting = ":os",
)

toolchain는 Starlark 규칙입니다. 속성은 언어의 도구 (예: compiler = "//mytoolchain:custom_gcc")를 선언합니다. 제공업체는 이 정보를 이러한 도구로 빌드해야 하는 규칙에 전달합니다.

도구 모음은 타겟팅할 수 있는 머신의 constraint_value(target_compatible_with = ["@platforms//os:linux"]) 및 도구가 실행될 수 있는 머신(exec_compatible_with = ["@platforms//os:mac"])을 선언합니다.

$ bazel build //:myproject --platforms=//:myplatform를 빌드할 때 Bazel은 빌드 머신에서 실행할 수 있는 도구 모음을 자동으로 선택하고 //:myplatform의 바이너리를 빌드합니다. 이를 툴체인 확인이라고 합니다.

사용 가능한 도구 모음은 WORKSPACE에서 register_toolchains를 사용하거나 명령줄에서 --extra_toolchains를 사용하여 등록할 수 있습니다.

자세한 내용은 여기를 참고하세요.

상태

현재 플랫폼 지원은 언어마다 다릅니다. Bazel의 모든 주요 규칙이 플랫폼으로 이동하고 있습니다. 하지만 이 절차에는 시간이 걸립니다. 이는 다음과 같은 세 가지 주요 이유 때문입니다.

새 툴체인 API (ctx.toolchains)에서 도구 정보를 가져오고 --cpu 및 --crosstool_top와 같은 기존 설정을 읽지 않도록 규칙 로직을 업데이트해야 합니다. 비교적 간단합니다.
도구 모음 유지보육자는 도구 모음을 정의하고 사용자가 GitHub 저장소 및 WORKSPACE 항목에서 액세스할 수 있도록 해야 합니다. 이는 기술적으로 간단하지만 편리한 사용자 환경을 유지하려면 지능적으로 구성해야 합니다.

Bazel이 실행되는 것과 동일한 머신용으로 빌드하지 않는 한 플랫폼 정의도 필요합니다. 일반적으로 프로젝트는 자체 플랫폼을 정의해야 합니다.
기존 프로젝트를 마이그레이션해야 합니다. select() 및 전환도 마이그레이션해야 합니다. 이것이 가장 큰 과제입니다. 특히 다국어 프로젝트의 경우 어려움이 있습니다. 모든 언어로 --platforms를 읽을 수 없는 경우 실패할 수 있습니다.

새 규칙 세트를 설계하는 경우 처음부터 플랫폼을 지원해야 합니다. 이렇게 하면 규칙이 다른 규칙 및 프로젝트와 자동으로 호환되며 플랫폼 API가 점점 보편화됨에 따라 가치가 증가합니다.

공통 플랫폼 속성

프로젝트 전반에서 공통적인 플랫폼 속성(예: OS 및 CPU)은 표준화된 중앙 집중식 위치에 선언해야 합니다. 이렇게 하면 프로젝트 간 및 언어 간 호환성이 촉진됩니다.

예를 들어 MyApp에 constraint_value @myapp//cpus:arm에 select()가 있고 SomeCommonLib에 @commonlib//constraints:arm에 select()가 있으면 이러한 모드는 호환되지 않는 기준으로 'arm' 모드를 트리거합니다.

전 세계적으로 공통적인 속성은 @platforms 저장소에 선언됩니다(따라서 위 예시의 표준 라벨은 @platforms//cpu:arm임). 언어별 공통 속성은 각 언어의 저장소에 선언해야 합니다.

기본 플랫폼

일반적으로 프로젝트 소유자는 빌드하려는 머신 유형을 설명하기 위해 명시적인 플랫폼을 정의해야 합니다. 그런 다음 --platforms로 트리거됩니다.

--platforms이 설정되지 않으면 Bazel은 기본적으로 로컬 빌드 머신을 나타내는 platform으로 설정됩니다. 이는 @local_config_platform//:host에서 자동 생성되므로 명시적으로 정의할 필요가 없습니다. 로컬 머신의 OS 및 CPU를 @platforms에 선언된 constraint_value에 매핑합니다.

C++

Bazel의 C++ 규칙은 --incompatible_enable_cc_toolchain_resolution를 설정할 때 플랫폼을 사용하여 도구 모음을 선택합니다(#7260).

즉, 다음을 사용하여 C++ 프로젝트를 구성할 수 있습니다.

bazel build //:my_cpp_project --platforms=//:myplatform

대신 다음을 사용합니다.

bazel build //:my_cpp_project` --cpu=... --crosstool_top=...  --compiler=...

프로젝트가 순수 C++이고 C++ 이외의 프로젝트에 종속되지 않는 경우 select 및 전환이 호환되는 한 플랫폼을 안전하게 사용할 수 있습니다. 자세한 내용은 #7260 및 C++ 도구 모음 구성을 참고하세요.

이 모드는 기본적으로 사용 설정되지 않습니다. 이는 Apple 프로젝트가 여전히 --cpu 및 --crosstool_top로 C++ 종속 항목을 구성하기 때문입니다(예). 따라서 이는 플랫폼으로 이전되는 Apple 규칙에 따라 다릅니다.

자바

Bazel의 Java 규칙은 플랫폼을 사용합니다.

이는 기존 플래그 --java_toolchain, --host_java_toolchain, --javabase, --host_javabase를 대체합니다.

구성 플래그를 사용하는 방법은 Bazel 및 Java 매뉴얼을 참고하세요. 자세한 내용은 설계 문서를 참고하세요.

여전히 기존 플래그를 사용하는 경우 문제 #7849의 이전 프로세스를 따르세요.

Android

Bazel의 Android 규칙은 --incompatible_enable_android_toolchain_resolution를 설정할 때 플랫폼을 사용하여 도구 모음을 선택합니다.

이 기능은 기본적으로 사용 설정되지 않습니다. 하지만 이전은 순조롭게 진행되고 있습니다.

Apple

Bazel의 Apple 규칙은 아직 플랫폼에서 Apple 도구 모음을 선택하는 것을 지원하지 않습니다.

또한 기존 --crosstool_top를 사용하여 C++ 도구 모음을 설정하므로 플랫폼 지원 C++ 종속 항목도 지원하지 않습니다. 이전이 완료될 때까지 플랫폼 매핑을 사용하여 Apple 프로젝트와 플랫폼 지원 C++를 혼합할 수 있습니다(예).

다른 언어

Bazel의 Rust 규칙은 플랫폼을 완벽하게 지원합니다.
Bazel의 Go 규칙은 플랫폼을 완전히 지원합니다(세부정보).

새 언어의 규칙을 설계하는 경우 플랫폼을 사용하여 언어의 도구 모음을 선택합니다. 자세한 내용은 툴체인 문서를 참고하세요.

`select()`

프로젝트는 constraint_value 타겟에서 select()할 수 있지만 전체 플랫폼에서는 할 수 없습니다. 이는 select()가 최대한 다양한 머신을 지원할 수 있도록 의도적으로 설계된 것입니다. ARM별 소스가 있는 라이브러리는 더 구체적인 이유가 없는 한 ARM 지원 머신 전체를 지원해야 합니다.

constraint_value를 하나 이상 선택하려면 다음을 사용하세요.

config_setting(
    name = "is_arm",
    constraint_values = [
        "@platforms//cpu:arm",
    ],
)

이는 기존에 --cpu에서 선택하는 것과 같습니다.

config_setting(
    name = "is_arm",
    values = {
        "cpu": "arm",
    },
)

자세한 내용은 여기를 참고하세요.

--cpu, --crosstool_top 등의 select는 --platforms를 이해하지 못합니다. 프로젝트를 플랫폼으로 이전할 때는 constraint_values로 변환하거나 플랫폼 매핑을 사용하여 이전 기간 동안 두 스타일을 모두 지원해야 합니다.

화면전환

Starlark 전환은 빌드 그래프의 일부 아래에 있는 플래그를 변경합니다. 프로젝트에서 --cpu, --crossstool_top 또는 기타 기존 플래그를 설정하는 전환을 사용하는 경우 --platforms를 읽는 규칙에는 이러한 변경사항이 표시되지 않습니다.

프로젝트를 플랫폼으로 이전할 때는 return { "//command_line_option:cpu": "arm" }와 같은 변경사항을 return { "//command_line_option:platforms": "//:my_arm_platform" }로 변환하거나 플랫폼 매핑을 사용하여 이전 기간 동안 두 스타일을 모두 지원해야 합니다.

현재 플랫폼을 사용하는 방법

프로젝트를 빌드하거나 크로스 컴파일하기만 하면 되는 경우 프로젝트의 공식 문서를 따라야 합니다. 플랫폼과 통합하는 방법과 시점, 제공하는 가치는 언어 및 프로젝트 유지관리자가 결정합니다.

프로젝트, 언어 또는 도구 모음 유지관리자이고 빌드에서 기본적으로 플랫폼을 사용하지 않는 경우 전 세계 이전을 기다리는 것 외에 다음 세 가지 옵션이 있습니다.

프로젝트의 언어에 '플랫폼 사용' 플래그를 사용 설정하고 (플래그가 있는 경우) 관심 있는 프로젝트가 작동하는지 확인하는 데 필요한 테스트를 실행합니다.
관심 있는 프로젝트가 여전히 --cpu 및 --crosstool_top와 같은 기존 플래그를 사용하는 경우 --platforms와 함께 사용합니다.
```
bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...
```
이 방법에는 유지보수 비용이 있습니다 (설정이 일치하는지 수동으로 확인해야 함). 하지만 배신자 전환이 없는 경우에는 작동합니다.
--cpu 스타일 설정을 해당 플랫폼에 매핑하고 그 반대로 하여 두 스타일을 모두 지원하는 플랫폼 매핑을 작성합니다.

플랫폼 매핑

플랫폼 매핑은 레거시 기반 로직을 지원하는 플랫폼 기반 로직이 후자의 지원 중단 기간을 통해 동일한 빌드에서 공존할 수 있도록 하는 임시 API입니다.

플랫폼 매핑은 platform()와 상응하는 기존 플래그 집합의 매핑 또는 그 반대의 매핑입니다. 예를 들면 다음과 같습니다.

platforms:
  # Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
  //platforms:ios
    --cpu=ios_x86_64
    --apple_platform_type=ios

flags:
  # Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
  --cpu=ios_x86_64
  --apple_platform_type=ios
    //platforms:ios

  # Maps "--cpu=darwin --apple_platform_type=macos" to "//platform:macos".
  --cpu=darwin
  --apple_platform_type=macos
    //platforms:macos

Bazel은 이를 사용하여 플랫폼 기반 설정과 기존 설정 모두 전환을 포함하여 빌드 전체에 일관되게 적용되도록 보장합니다.

기본적으로 Bazel은 작업공간 루트의 platform_mappings 파일에서 매핑을 읽습니다. --platform_mappings=//:my_custom_mapping를 설정할 수도 있습니다.

자세한 내용은 여기를 참고하세요.

질문

이전 일정에 관한 일반적인 지원 및 질문은 bazel-discuss@googlegroups.com 또는 적절한 규칙의 소유자에게 문의하세요.

플랫폼/툴체인 API의 설계 및 발전에 관한 논의는 bazel-dev@googlegroups.com으로 문의하세요.

플랫폼을 이용한 빌드

배경

마이그레이션

목표

플랫폼을 사용해야 하나요?

값

비용

API 검토

상태

공통 플랫폼 속성

기본 플랫폼

C++

자바

Android

Apple

다른 언어

select()

화면전환

현재 플랫폼을 사용하는 방법

플랫폼 매핑

질문

참고 항목

`select()`