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

प्लैटफ़ॉर्म की मदद से इमारत बनाना

Bazel के पास, मॉडलिंग के प्लैटफ़ॉर्म और टूलचेन के लिए बेहतर सहायता है. इसे असली प्रोजेक्ट के साथ जोड़ने के लिए, कोड के मालिकों, नियम का रखरखाव करने वालों, और Bazel डेवलपर के बीच सावधानी से सहयोग की ज़रूरत है.

इस पेज पर, प्लैटफ़ॉर्म के मकसद के बारे में खास जानकारी दी गई है. साथ ही, उन्हें बनाने का तरीका भी बताया गया है.

tl;dr: Bazel का प्लैटफ़ॉर्म और टूलचेन एपीआई उपलब्ध हैं, लेकिन जब तक भाषा के सभी नियम, select(), और दूसरी लेगसी पहचान फ़ाइलें अपडेट नहीं हो जातीं, तब तक ये हर जगह काम नहीं करेंगे. यह काम चल रहा है. आखिर में, सभी बिल्ड प्लैटफ़ॉर्म पर आधारित होंगे. आपके बिल्ड कहां फ़िट होते हैं, यह जानने के लिए नीचे पढ़ें.

ज़्यादा औपचारिक दस्तावेज़ देखने के लिए, देखें:

बैकग्राउंड

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

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

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

माइग्रेशन

प्लैटफ़ॉर्म और टूलचेन एपीआई सिर्फ़ तब काम करते हैं, जब प्रोजेक्ट असल में उनका इस्तेमाल करते हैं. यह आसान नहीं है, क्योंकि प्रोजेक्ट के नियम वाले लॉजिक, टूलचेन, डिपेंडेंसी, और select() के साथ काम करना भी ज़रूरी होता है. इसके लिए, माइग्रेशन क्रम में सावधानी बरतनी ज़रूरी है, ताकि सभी प्रोजेक्ट और उनकी डिपेंडेंसी सही तरीके से काम करती रहें.

उदाहरण के लिए, Bazel के C++ नियम सहायता प्लैटफ़ॉर्म. हालांकि, Apple के नियमों में ऐसा नहीं है. ऐसा हो सकता है कि आपका C++ प्रोजेक्ट Apple की परवाह न करता हो. हालांकि, दूसरे लोग भी कर सकते हैं. इसलिए, फ़िलहाल सभी C++ बिल्ड के लिए वैश्विक रूप से प्लैटफ़ॉर्म चालू करना सुरक्षित नहीं है.

इस पेज के बाकी हिस्से में, माइग्रेशन के इस क्रम के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि आपके प्रोजेक्ट कब और कैसे फ़िट हो सकते हैं.

लक्ष्य

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

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

इसका मतलब है कि:

आपका प्रोजेक्ट जिन नियमों का इस्तेमाल करता है उनसे //:myplatform से सही टूलचेन का अनुमान लगाया जा सकता है.
आपके प्रोजेक्ट की डिपेंडेंसी के लिए जिन नियमों का इस्तेमाल होता है उनसे //:myplatform से सही टूलचेन मिल सकते हैं.
या तो इस आधार पर प्रोजेक्ट में आपकी मदद की जा सकती है //:myplatform या आपका प्रोजेक्ट लेगसी एपीआई के साथ काम करता है (जैसे कि --crosstool_top).
//:myplatform रेफ़रंस [सामान्य एलान][सामान्य प्लैटफ़ॉर्म एलान]{: .external} CPU, OS, और अन्य सामान्य कॉन्सेप्ट के बारे में बताते हैं जो अपने-आप क्रॉस-प्रोजेक्ट के साथ काम करने की सुविधा देते हैं.
सभी काम के प्रोजेक्ट के select() //:myplatform में शामिल मशीन प्रॉपर्टी को समझते हैं.
//:myplatform के बारे में साफ़ और फिर से इस्तेमाल की जा सकने वाली जगह पर बताया गया है: अगर वह प्लैटफ़ॉर्म आपके प्रोजेक्ट के लिए खास है, तो यह आपके प्रोजेक्ट के डेटा स्टोर में होती है. अगर वह प्लैटफ़ॉर्म आपके प्रोजेक्ट के लिए खास है, तो यह ऐसी जगह पर होगा जहां इस प्लैटफ़ॉर्म का इस्तेमाल करने वाले सभी प्रोजेक्ट ढूंढ सकते हैं.

यह लक्ष्य पूरा होते ही, पुराने एपीआई हटा दिए जाएंगे. फिर यह प्रोजेक्ट, प्लैटफ़ॉर्म और टूलचेन चुनने का स्टैंडर्ड तरीका होगा.

क्या मुझे प्लैटफ़ॉर्म का इस्तेमाल करना चाहिए?

अगर आपको सिर्फ़ कोई प्रोजेक्ट बनाना या उसे क्रॉस-कंप करना है, तो प्रोजेक्ट के आधिकारिक दस्तावेज़ में दिए गए निर्देशों का पालन करें.

अगर आप किसी प्रोजेक्ट, भाषा या टूलचेन मेंटेनर हैं, तो आपको नए एपीआई का इस्तेमाल करना होगा. आप ग्लोबल माइग्रेशन पूरा होने तक इंतज़ार करें या पहले ऑप्ट-इन करें, यह आपकी खास वैल्यू / कीमत की ज़रूरतों पर निर्भर करता है:

वैल्यू

आपके पास select() या --cpu जैसे हार्ड कोड किए गए फ़्लैग के बजाय, उन प्रॉपर्टी पर टूलचेन को चुनने का विकल्प है जो आपके लिए अहम हैं. उदाहरण के लिए, एक से ज़्यादा सीपीयू पर एक ही निर्देश सेट काम कर सकता है.
ज़्यादा सही बिल्ड. अगर ऊपर दिए गए उदाहरण में --cpu के साथ select() किया जाता है, तो एक ऐसा नया सीपीयू जोड़ें जो उसी निर्देश के सेट के साथ काम करता हो, तो select() नए सीपीयू की पहचान नहीं कर पाएगा. हालांकि, प्लैटफ़ॉर्म पर select() सटीक बना रहता है.
ज़्यादा आसान उपयोगकर्ता अनुभव. सभी प्रोजेक्ट यह समझते हैं: --platforms=//:myplatform. कमांड लाइन पर, अलग-अलग भाषाओं के लिए कई फ़्लैग की ज़रूरत नहीं होती.
आसान भाषा डिज़ाइन. टूलचेन को तय करने, टूलचेन का इस्तेमाल करने, और प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने के लिए, सभी भाषाएं एक ही एपीआई शेयर करती हैं.
अगर टारगेट, टारगेट प्लैटफ़ॉर्म के साथ काम नहीं करते, तो बिल्ड और टेस्ट फ़ेज़ में उन्हें छोड़ा जा सकता है.

लागत

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

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

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") के बारे में बताती हैं. इसके provider, इस जानकारी को इन टूल के साथ बनाए जाने वाले नियमों को देते हैं.

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

नए टूलचेन एपीआई (ctx.toolchains) से टूल की जानकारी पाने के लिए, नियम लॉजिक को अपडेट करना ज़रूरी है. इससे यह भी ज़रूरी है कि --cpu और --crosstool_top जैसी लेगसी सेटिंग को ऐक्सेस न किया जा सके. यह कुछ हद तक आसान है.
टूलचेन मेंटेनर को टूलचेन के बारे में बताना चाहिए और उन्हें उपयोगकर्ता (GitHub रिपॉज़िटरी और WORKSPACE एंट्री में) इस्तेमाल करने लायक बनाना चाहिए. यह तकनीकी रूप से आसान है. हालांकि, उपयोगकर्ता अनुभव को आसान बनाए रखने के लिए, इसे बेहतर तरीके से व्यवस्थित किया जाना चाहिए.

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

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

कॉमन प्लैटफ़ॉर्म प्रॉपर्टी

सभी प्रोजेक्ट में आम तौर पर इस्तेमाल की जाने वाली OS और CPU जैसी प्लैटफ़ॉर्म प्रॉपर्टी का एलान, स्टैंडर्ड और एक ही जगह पर किया जाना चाहिए. इससे क्रॉस-प्रोजेक्ट और दूसरी भाषाओं में काम करने की सुविधा को बढ़ावा मिलता है.

उदाहरण के लिए, अगर MyApp का constraint_value पर select() है @myapp//cpus:arm और SomeCommonLib का select(), @commonlib//constraints:arm, तो ये काम न करने वाली शर्तों के साथ अपने "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 के नियमों पर निर्भर करता है.

Java

Bazel के Java नियम, प्लैटफ़ॉर्म का इस्तेमाल करते हैं.

यह --java_toolchain, --host_java_toolchain, --javabase, और --host_javabase लेगसी फ़्लैग की जगह ले लेगा.

कॉन्फ़िगरेशन फ़्लैग को इस्तेमाल करने का तरीका जानने के लिए, Bazel और Java का मैन्युअल देखें. ज़्यादा जानकारी के लिए, डिज़ाइन का दस्तावेज़ देखें.

अगर अब भी लेगसी फ़्लैग का इस्तेमाल किया जा रहा है, तो समस्या #7849 में, माइग्रेशन की प्रोसेस को फ़ॉलो करें.

Android

जब आप --incompatible_enable_android_toolchain_resolution को सेट करते हैं, तब Bazel के Android नियम, टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.

यह सुविधा डिफ़ॉल्ट रूप से चालू नहीं होती है. हालांकि, माइग्रेशन का काम अभी पूरा होने वाला है.

सेब

फ़िलहाल, Bazel के Apple नियम, Apple टूलचेन चुनने वाले प्लैटफ़ॉर्म के साथ काम नहीं करते हैं.

वे प्लैटफ़ॉर्म पर काम करने वाली C++ डिपेंडेंसी के साथ भी काम नहीं करते, क्योंकि वे C++ टूलचेन को सेट करने के लिए, लेगसी --crosstool_top का इस्तेमाल करते हैं. जब तक यह माइग्रेट नहीं हो जाता, तब तक Apple प्रोजेक्ट को platorm की सुविधा वाले C++ के साथ प्लैटफ़ॉर्म मैपिंग के साथ मिक्स किया जा सकता है (उदाहरण).

अन्य भाषाएं

Bazel के Rust नियम, प्लैटफ़ॉर्म पर पूरी तरह काम करते हैं.
Bazel के Go नियम, सभी प्लैटफ़ॉर्म पर काम करते हैं (जानकारी).

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

`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 वगैरह पर मौजूद selects, --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-स्टाइल की सेटिंग को उनसे जुड़े प्लैटफ़ॉर्म के साथ मैप करें.

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

प्लैटफ़ॉर्म मैपिंग एक अस्थायी एपीआई है. इसकी मदद से, प्लैटफ़ॉर्म और लेगसी से चलने वाले लॉजिक को, एक बंद सुविधा के दौरान एक ही बिल्ड में एक साथ इस्तेमाल किया जा सकता है.

प्लैटफ़ॉर्म मैपिंग, 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 या उचित नियमों के मालिकों से संपर्क करें.

प्लैटफ़ॉर्म/toolchain एपीआई को डिज़ाइन करने और उसे आगे बढ़ाने के बारे में ज़्यादा जानने के लिए, bazel-dev@googlegroups.com से संपर्क करें.