플랫폼으로 마이그레이션

<ph type="x-smartling-placeholder"></ph> 문제 신고 <ph type="x-smartling-placeholder"></ph> 소스 보기 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5 를 참조하세요.

Bazel의 정교한 모델링 지원 플랫폼도구 모음을 크로스 컴파일 빌드입니다.

이 페이지에는 이 지원의 상태가 요약되어 있습니다.

관련 주제에 대한 추가 정보

상태

C++

C++ 규칙은 다음의 경우 플랫폼을 사용하여 도구 모음을 선택합니다. --incompatible_enable_cc_toolchain_resolution가 설정되었습니다.

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

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

레거시가 아닌

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

이 기능은 Bazel 7.0에서 기본적으로 사용 설정됩니다 (#7260).

플랫폼에서 C++ 프로젝트를 테스트하려면 다음을 참고하세요. 프로젝트 이전C++ 도구 모음 구성

자바

Java 규칙은 플랫폼을 사용하여 도구 모음을 선택합니다.

이는 기존 플래그 --java_toolchain, --host_java_toolchain, --javabase, --host_javabase

자세한 내용은 Java 및 Bazel을 참고하세요.

Android

Android 규칙은 다음과 같은 경우 플랫폼을 사용하여 도구 모음을 선택합니다. --incompatible_enable_android_toolchain_resolution가 설정되었습니다.

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

bazel build //:my_android_project --android_platforms=//:my_android_platform

--android_crosstool_top, --android_cpu, 및 --fat_apk_cpu

이 기능은 Bazel 7.0에서 기본적으로 사용 설정됩니다 (#16285).

플랫폼에서 Android 프로젝트를 테스트하려면 다음을 참고하세요. 프로젝트 이전

Apple

Apple 규칙은 플랫폼을 지원하지 않으며 아직 예약되지 않았습니다. 문의하세요.

Apple 빌드에서 플랫폼 API를 계속 사용할 수 있습니다 (예: Apple 규칙과 순수 C++를 혼합하여 사용) 매핑을 참조하세요.

다른 언어

  • Go 규칙은 플랫폼을 완벽하게 지원합니다.
  • Rust 규칙은 플랫폼을 완벽하게 지원합니다.

언어 규칙 모음을 보유하고 있는 경우 추가 방법은 규칙 집합 이전을 참조하세요. 도움이 될 수 있습니다

배경

소프트웨어 사용 방식을 표준화하기 위해 플랫폼도구 모음이 도입됨 프로젝트는 다양한 아키텍처를 타겟팅하고 크로스 컴파일합니다.

이전 가격 영감을 준 이미 광고 상에서 언어 유지관리자들이 이 작업을 수행하고 있다는 사실을 일회성, 비호환 방식으로 작동합니다 예를 들어 C++ 규칙은 --cpu--crosstool_top: 대상 CPU 및 도구 모음을 선언합니다. 해당 사항 없음 '플랫폼'을 올바르게 모델링합니다. 이로 인해 어색하고 잘못된 빌드가 생성되었습니다.

Java, Android 및 기타 언어도 유사한 목적을 위해 자체 플래그를 발전시켰습니다. 어떤 것도 서로 상호 운용되지 않습니다. 이로 인해 언어 간 빌드가 매우 복잡할 수 있습니다.

Bazel은 대규모 다국어 다중 플랫폼 프로젝트에 사용됩니다. 이 책임감 있는 AI 관행을 비롯하여 이러한 개념에 대해 보다 원칙적인 지원을 요구합니다. API를 사용할 수 있습니다.

마이그레이션의 필요성

새 API로 업그레이드하려면 API 출시와 업그레이드라는 두 가지 작업이 필요합니다. 사용하도록 설정해야 합니다.

첫 번째는 완료되지만 두 번째는 계속됩니다. 이 작업은 언어별 플랫폼 및 도구 모음이 정의됨, 언어 로직은 --crosstool_top와 같은 이전 플래그 대신 새 API를 통해 도구 모음을 제공합니다. config_setting는 이전 플래그 대신 새 API를 선택합니다.

이 작업은 간단하지만 언어마다 별도의 노력이 필요합니다. 프로젝트 소유자에게 예정된 변경사항을 테스트하도록 공정한 경고를 제공합니다.

이것이 바로 이전이 지속적인 이유입니다.

목표

모든 프로젝트가 다음 양식으로 빌드되면 이 이전이 완료됩니다.

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

이는 다음을 의미합니다.

  1. 프로젝트 규칙은 //:myplatform에 적합한 도구 모음을 선택합니다.
  2. 프로젝트의 종속 항목은 //:myplatform에 적합한 도구 모음을 선택합니다.
  3. 참조 //:myplatform일반 선언 (CPU, OS 및 기타 일반적이고 언어 독립적 속성)
  4. 모든 관련 select()//:myplatform과 올바르게 일치합니다.
  5. //:myplatform는 명확하고 액세스 가능한 위치인 프로젝트의 repo 또는 리소스 낭비가 줄어드는 것을

--cpu, --crosstool_top, --fat_apk_cpu 등의 이전 플래그가 적용됩니다. 안전한 즉시 삭제됩니다.

궁극적으로 이 방법이 아키텍처를 구성하는 유일한 방법이 될 것입니다.

프로젝트 마이그레이션

플랫폼을 지원하는 언어로 빌드하는 경우 빌드는 이미 다음과 같은 호출로 작업합니다.

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

정확한 세부정보는 상태 및 해당 언어의 문서를 참조하세요.

언어에 플랫폼 지원을 사용 설정하기 위해 플래그가 필요한 경우 있습니다. 자세한 내용은 상태를 참조하세요.

프로젝트를 빌드하려면 다음을 확인해야 합니다.

  1. //:myplatform이(가) 있어야 합니다. 일반적으로 프로젝트 소유자는 여러 프로젝트가 서로 다른 머신을 대상으로 하기 때문에 플랫폼을 정의할 수 있습니다. 기본 플랫폼을 참고하세요.

  2. 사용하려는 도구 모음이 있어야 합니다. 스톡 도구 모음을 사용하는 경우 언어 소유자는 등록 방법에 대한 안내를 포함해야 합니다. 만약 등록해야 하는 경우에는 MODULE.bazel 파일 또는 --extra_toolchains 사용

  3. select()구성 전환은 해결할 수 있습니다. select()전환을 참고하세요.

  4. 빌드에 플랫폼을 지원하는 언어와 지원하지 않는 언어가 혼합되어 있는 경우 기존 언어가 새 API와 작동할 수 있도록 플랫폼 매핑이 필요합니다. 자세한 내용은 플랫폼 매핑을 참고하세요.

문제가 계속되면 문의하여 지원을 받으세요.

기본 플랫폼

프로젝트 소유자는 포드에 대한 명시적인 platforms 선택할 수 있습니다 그러면 --platforms로 트리거됩니다.

--platforms이 설정되지 않은 경우 Bazel은 기본적으로 platform 로컬 빌드 머신을 만드는 방법을 알아보겠습니다 @platforms//host에서 자동 생성됨 (별칭: @bazel_tools//tools:host_platform) 명시적으로 정의할 필요가 없습니다 로컬 머신의 OS를 매핑합니다. 및 constraint_value이(가) 선언된 CPU @platforms

select()

프로젝트는 다음에서 select()할 수 있습니다. 타겟이 constraint_value이지만 완료되지 않음 지원합니다 이는 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" } 또는 플랫폼 사용 매핑을 통해 이전 중에 두 스타일을 모두 지원할 수 있습니다. 창

규칙 집합 이전

규칙 세트를 소유하고 있으며 플랫폼을 지원하려면 다음을 수행해야 합니다.

  1. 도구 모음 API로 도구 모음을 확인하는 규칙 로직이 필요합니다. 자세한 내용은 도구 모음 API (ctx.toolchains)

  2. 선택사항: --incompatible_enable_platforms_for_my_language 플래그를 정의하여 규칙 로직이 새 API나 이전 플래그를 통해 도구 모음을 확인하는 대안 예: --crosstool_top 등 이전 테스트 중

  3. 플랫폼 구성요소를 구성하는 관련 속성을 정의합니다. 자세한 내용은 일반 플랫폼 속성

  4. 표준 도구 모음을 정의하고 사용자가 이를 통해 액세스할 수 있게 합니다. 규칙의 등록 안내 (세부정보)

  5. select()구성 전환을 지원합니다. 이것은 가장 큰 과제였습니다. 특히 다국어 프로젝트에 있어서는 (모든 언어가 --platforms을 읽을 수 없는 경우 실패할 수 있음).

플랫폼을 지원하지 않는 규칙과 혼합해야 하는 경우 플랫폼 매핑을 통해 이러한 간격을 해소할 수 있습니다.

일반적인 플랫폼 속성

일반적인 교차 언어 플랫폼 속성(예: OS, CPU)은 다음과 같아야 합니다. @platforms에 선언됨 이는 공유, 표준화, 언어 간 호환성을 촉진합니다.

규칙 고유의 속성은 규칙의 저장소에 선언되어야 합니다. 이 규칙에서 사용할 특정 개념에 대한 소유권을 명확하게 유지 책임지지 않습니다

규칙에서 사용자 지정 목적의 OS 또는 CPU를 사용하는 경우 규칙의 저장소와 @platforms

플랫폼 매핑

플랫폼 매핑은 플랫폼 인식 로직이 레거시 로직만 지원합니다 이 둔 도구는 오직 한 손으로 서로 다른 마이그레이션 기간에 대한 원활한 비호환성 문제를 해결할 수 있습니다.

플랫폼 매핑은 platform()와 그 반대의 경우도 가능합니다. 예를 들면 다음과 같습니다.

platforms:
  # Maps "--platforms=//platforms:ios" to "--ios_multi_cpus=x86_64 --apple_platform_type=ios".
  //platforms:ios
    --ios_multi_cpus=x86_64
    --apple_platform_type=ios

flags:
  # Maps "--ios_multi_cpus=x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
  --ios_multi_cpus=x86_64
  --apple_platform_type=ios
    //platforms:ios

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

Bazel은 이를 사용하여 플랫폼 기반 및 레거시가 있으며, 다음을 포함하여 빌드 전체에 일관되게 적용됩니다. 전환을 설정하는 방법을 설명합니다.

기본적으로 Bazel은 platform_mappings 파일에서 매핑을 읽고 작업공간 루트를 선택합니다. 또한 --platform_mappings=//:my_custom_mapping

자세한 내용은 플랫폼 매핑 설계를 참고하세요.

API 검토

platform타겟 constraint_value:

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

constraint_value는 머신입니다. 속성 동일한 'kind'의 값 공통으로 그룹화되고 constraint_setting:

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

toolchainStarlark 법칙입니다. 자체 속성은 언어의 도구 (예: 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용 빌드 바이너리 이를 도구 모음 확인이라고 합니다.

사용 가능한 도구 모음 집합은 MODULE.bazel 파일에 등록 가능 register_toolchains 또는 명령줄에서 --extra_toolchains로 대체합니다.

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

질문

이전 일정에 관한 일반적인 지원 및 질문이 있는 경우 다음 연락처로 문의하세요. bazel-discuss 또는 해당 규칙의 소유자에게만 전달할 수 있습니다.

플랫폼/도구 모음 API의 설계와 진화에 관한 논의는 bazel-dev에 문의하세요.

참고 항목