इस पेज का अनुवाद Cloud Translation API से किया गया है.

प्लैटफ़ॉर्म पर माइग्रेट करना

Bazel में प्लैटफ़ॉर्म के मॉडल बनाने के लिए बेहतरीन सहायता है. साथ ही, कई आर्किटेक्चर और क्रॉस कंपाइल किए गए बिल्ड के लिए टूलचेन भी हैं.

यह पेज इस सहायता की स्थिति के बारे में बताता है.

यह भी देखें:

स्थिति

C++

--incompatible_enable_cc_toolchain_resolution सेट होने पर, C++ के नियम प्लैटफ़ॉर्म का इस्तेमाल करते हैं.

इसका मतलब है कि यहां दिए गए विकल्पों से, 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 के नियम, टूल चेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.

यह लेगसी फ़्लैग --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 के बिल्ड के साथ प्लैटफ़ॉर्म एपीआई का इस्तेमाल किया जा सकता है. उदाहरण के लिए, Apple के नियमों और C++ के मिक्स का इस्तेमाल करके, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल किया जा सकता है.

अन्य भाषाएं

Go Go पूरी तरह से काम करने वाला प्लैटफ़ॉर्म है
रस्ट रूल, प्लैटफ़ॉर्म पर पूरी तरह से लागू होते हैं.

अगर आप किसी भाषा के नियमों के समूह के मालिक हैं, तो सहायता जोड़ने के लिए अपने नियम सेट को माइग्रेट करना देखें.

बैकग्राउंड

प्लैटफ़ॉर्म और टूलचेन की मदद से, यह तय किया गया था कि सॉफ़्टवेयर प्रोजेक्ट अलग-अलग आर्किटेक्चर और क्रॉस-कंपाइल को टारगेट कैसे करते हैं.

यह इस बात से प्रेरणा देता था कि भाषा का रखरखाव करने वाले लोग ऐड-हॉक, कई तरह से गलत तरीके से ऐसा कर रहे थे. उदाहरण के लिए, C++ के नियमों में, --cpu और --crosstool_top का इस्तेमाल करके, सीपीयू और टूल चेन का एलान किया गया. इनमें से कोई भी सही से "प्लैटफ़ॉर्म" मॉडल नहीं करता है. इससे अजीब चीज़ें और गलत बिल्ड बने.

इसी तरह के मकसद के लिए, Java, Android, और दूसरी भाषाओं ने अपने फ़्लैग बनाए हैं. इनमें से कोई भी एक-दूसरे के साथ काम नहीं करता है. इससे दूसरी भाषा के बिल्ड को समझना मुश्किल और मुश्किल हो गया.

Bazel का मकसद कई भाषाओं, भाषाओं, और भाषाओं के बड़े प्रोजेक्ट बनाना है. इन कॉन्सेप्ट के लिए, आपको ज़्यादा बेहतर सिद्धांत की ज़रूरत होती है. इसके लिए, साफ़ तौर पर एक स्टैंडर्ड एपीआई की ज़रूरत होती है.

माइग्रेशन की ज़रूरत है

नए एपीआई पर अपग्रेड करने के लिए, दो बार कोशिश करनी होती है: एपीआई को रिलीज़ करना और नियम के नियम का इस्तेमाल करने के लिए उसे अपग्रेड करना.

पहली सूची तैयार हो गई है, लेकिन दूसरी जारी है. इसमें यह पक्का करना शामिल है कि भाषा के हिसाब से प्लैटफ़ॉर्म और टूल चेन के बारे में बताया गया हो. भाषा का लॉजिक, --crosstool_top जैसे पुराने फ़्लैग के बजाय, नए एपीआई के ज़रिए टूलचेन को पढ़ता है. साथ ही, पुराने फ़्लैग के बजाय config_setting नए एपीआई को चुनता है.

यह काम आसान है. हालांकि, आपको हर भाषा के लिए अलग से कोशिश करनी होगी. साथ ही, प्रोजेक्ट के मालिकों को आने वाले समय में होने वाले बदलावों की जांच करने के लिए, सही चेतावनी देनी होगी.

इसलिए, डेटा दूसरी जगह भेजने की यह प्रोसेस जारी है.

लक्ष्य

जब सभी प्रोजेक्ट इस फ़ॉर्म के साथ बनते हैं, तब माइग्रेशन पूरा हो जाता है:

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

इसका मतलब है:

आपके प्रोजेक्ट के नियम //:myplatform के लिए सही टूलचेन चुनते हैं.
आपके प्रोजेक्ट की डिपेंडेंसी, //:myplatform के लिए सही टूलचेन बनाती हैं.
//:myplatform CPU, OS, और भाषा से स्वतंत्र दूसरी प्रॉपर्टी की सामान्य जानकारी देता है
काम के select(), //:myplatform से पूरी तरह मेल खाते हैं.
//:myplatform को साफ़ तौर पर ऐक्सेस की जा सकने वाली जगह पर परिभाषित किया गया है. आपके प्रोजेक्ट के रीपो में, अगर प्लैटफ़ॉर्म आपके प्रोजेक्ट के लिए खास है या कोई ऐसी सामान्य जगह है जहां सभी प्रोजेक्ट को इसे मिल सकता है

जैसे ही सुरक्षित किया जाएगा, --cpu, --crosstool_top, और --fat_apk_cpu जैसे पुराने फ़्लैग हटा दिए जाएंगे और हटा दिए जाएंगे.

कुल मिलाकर, यह आर्किटेक्चर को कॉन्फ़िगर करने का एक तरीका होगा.

प्रोजेक्ट को माइग्रेट करना

अगर आपने प्लैटफ़ॉर्म के साथ काम करने वाली भाषाएं बनाई हैं, तो आपका बिल्ड पहले से ही किसी नाम के साथ काम करेगा, जैसे कि:

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

सटीक जानकारी के लिए, स्थिति और अपनी भाषा के दस्तावेज़ देखें.

अगर किसी भाषा को प्लैटफ़ॉर्म पर सहायता उपलब्ध कराने के लिए फ़्लैग की ज़रूरत होती है, तो आपको उस फ़्लैग को भी सेट करना होगा. ज़्यादा जानकारी के लिए, स्थिति पर जाएं.

अपना प्रोजेक्ट बनाने के लिए, आपको इन चीज़ों की जांच करनी होगी:

//:myplatform मौजूद होना चाहिए. आम तौर पर, प्लैटफ़ॉर्म को तय करना प्रोजेक्ट के मालिक की ज़िम्मेदारी होता है, क्योंकि अलग-अलग प्रोजेक्ट अलग-अलग मशीनों को टारगेट करते हैं. डिफ़ॉल्ट प्लैटफ़ॉर्म पर जाएं.
आप जिन टूलचेन का इस्तेमाल करना चाहते हैं वे मौजूद होने चाहिए. अगर स्टॉक टूलचेन का इस्तेमाल किया जा रहा है, तो भाषा के मालिकों को उन्हें रजिस्टर करने के निर्देश दिए जाने चाहिए. अगर आप अपने कस्टम टूलचेन लिख रहे हैं, तो आपकोउन्हेंWORKSPACEया--extra_toolchainsपर रजिस्टर करना होगा.
select() और कॉन्फ़िगरेशन का ट्रांज़िशन ठीक से होना चाहिए. select() और ट्रांज़िशन देखें.
अगर आपके बिल्ड में ऐसी भाषाएं हैं जो प्लैटफ़ॉर्म के साथ काम नहीं करतीं, तो आपको प्लैटफ़ॉर्म मैपिंग की ज़रूरत पड़ सकती है, ताकि लेगसी भाषाएं नए एपीआई के साथ काम कर सकें. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म मैपिंग देखें.

अगर आपको अब भी समस्याएं आ रही हैं, तो सहायता के लिए संपर्क करें.

डिफ़ॉल्ट प्लैटफ़ॉर्म

प्रोजेक्ट के मालिकों को ऐसे प्लैटफ़ॉर्म तय करने चाहिए जहां वे वास्तुकला के बारे में बता सकें. इसके बाद, इन्हें --platforms की मदद से ट्रिगर किया जाता है.

--platforms सेट न होने पर, Bazel, लोकल बिल्ड मशीन को दिखाने वाले platform को डिफ़ॉल्ट तौर पर सेट करता है. यह @local_config_platform//:host पर अपने-आप जनरेट होता है, इसलिए इसके बारे में साफ़ तौर पर बताने की ज़रूरत नहीं है. इसमें, लोकल मशीन की OS और CPU को मैप किया गया है, जिसमें constraint_value, @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 में बदलाव करना होगा या दोनों प्लैटफ़ॉर्म के लिए प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.

ट्रांज़िशन

स्टारलार्क ट्रांज़िशन बदलाव आपके बिल्ड ग्राफ़ के हिस्सों को फ़्लैग कर देता है. अगर आपके प्रोजेक्ट में किसी ऐसे ट्रांज़िशन का इस्तेमाल किया जाता है जो --cpu, --crossstool_top या दूसरे लेगसी फ़्लैग को सेट करता है, तो --platforms वाले नियमों में ये बदलाव नहीं दिखेंगे.

अपने प्रोजेक्ट को प्लैटफ़ॉर्म पर माइग्रेट करते समय, आपको return { "//command_line_option:cpu": "arm" } जैसे बदलावों को return { "//command_line_option:platforms": "//:my_arm_platform" } में बदलना होगा या माइग्रेशन के दौरान, दोनों स्टाइल में काम करने के लिए प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.

अपने नियम सेट को माइग्रेट करें

अगर आपके पास किसी नियम सेट का मालिकाना हक है और आपको प्लैटफ़ॉर्म को सपोर्ट करना है, तो आपको ये काम करने होंगे:

नियमों के तर्क का समाधान और टूलटिप वाले एपीआई के साथ टूलचेन पाएं. टूलचेन एपीआई देखें (ctx.toolchains).
ज़रूरी नहीं: --incompatible_enable_platforms_for_my_language फ़्लैग तय करें, ताकि माइग्रेशन की प्रोसेस के दौरान, नियम लॉजिक वैकल्पिक रूप से नए एपीआई या --crosstool_top जैसे पुराने फ़्लैग की मदद से टूलचेन का समाधान कर सके.
प्लैटफ़ॉर्म के कॉम्पोनेंट तैयार करने वाली प्रॉपर्टी तय करें. सामान्य प्लैटफ़ॉर्म प्रॉपर्टी देखें
स्टैंडर्ड टूलचेन तय करें और अपने नियम के रजिस्ट्रेशन निर्देशों के ज़रिए उपयोगकर्ताओं को ऐक्सेस करने लायक बनाएं (जानकारी)
पक्का करें कि प्लैटफ़ॉर्म पर select() और कॉन्फ़िगरेशन ट्रांज़िशन की सुविधा उपलब्ध हो. यह सबसे बड़ी चुनौती है. कई भाषाओं वाले प्रोजेक्ट के लिए यह चुनौती भरा हो सकता है (अगर सभी भाषाएं --platforms नहीं पढ़ सकतीं, तो हो सकता है कि वे काम न करें).

अगर आपको ऐसे नियमों के साथ मिलान करना हो जो प्लैटफ़ॉर्म पर काम नहीं करते, तो इस अंतर को कम करने के लिए, आपको प्लैटफ़ॉर्म मैपिंग की ज़रूरत पड़ सकती है.

आम प्लैटफ़ॉर्म प्रॉपर्टी

आम तौर पर, दूसरी भाषाओं की प्रॉपर्टी, जैसे कि OS और CPU का एलान @platforms में किया जाना चाहिए. इससे कॉन्टेंट को शेयर करने, मानक तय करने, और दूसरी भाषाओं के साथ काम करने की सुविधा मिलती है.

आपके नियमों के लिए खास प्रॉपर्टी का एलान, आपके नियम के डेटा में होना चाहिए. इसकी मदद से, आप उन खास सिद्धांतों पर अपने मालिकाना हक को बनाए रख सकते हैं जो आपके नियमों के लिए ज़िम्मेदार हैं.

अगर आपके नियमों का इस्तेमाल, खास मकसद से बनाए गए ओएस या सीपीयू का इस्तेमाल करते हैं, तो इनकी जानकारी आपके नियम के डेटा संग्रह में दी जानी चाहिए. @platforms

प्लैटफ़ॉर्म मैपिंग

प्लैटफ़ॉर्म मैपिंग एक अस्थायी एपीआई है. इसकी मदद से, प्लैटफ़ॉर्म-लॉजिक लॉजिक को उसी बिल्ड में लेगसी लॉजिक के साथ जोड़ा जा सकता है. यह एक ब्लंट टूल है, जिसका मकसद माइग्रेशन की अलग-अलग समयसीमाओं के साथ-साथ गड़बड़ियों को भी आसान बनाना है.

प्लैटफ़ॉर्म मैपिंग, 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_x86_64 --apple_platform_type=macos" to "//platform:macos".
  --cpu=darwin_x86_64
  --apple_platform_type=macos
    //platforms:macos

बेज़ल इसका इस्तेमाल यह पक्का करने के लिए करता है कि प्लैटफ़ॉर्म पर काम करने वाली सेटिंग और लेगसी सेटिंग, दोनों पूरे बिल्ड पर लगातार लागू हों. इनमें ट्रांज़िशन का इस्तेमाल करना भी शामिल है.

डिफ़ॉल्ट रूप से, बेज़ल आपके फ़ाइल फ़ोल्डर के रूट में, platform_mappings फ़ाइल से मैपिंग को पढ़ता है. --platform_mappings=//:my_custom_mapping को भी सेट किया जा सकता है.

ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म मैपिंग डिज़ाइन देखें.

एपीआई समीक्षा

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 स्टारलार्क का नियम होता है. इसके एट्रिब्यूट, भाषा के टूल (जैसे कि 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 के लिए बाइनरी बना सकता है. इसे टूलचेन रिज़ॉल्यूशन के नाम से जाना जाता है.

उपलब्ध टूल चेन का सेट register_toolchains के साथ या कमांड लाइन पर --extra_toolchains के साथ रजिस्टर किया जा सकता है.