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

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

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

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

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

बैकग्राउंड

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

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

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

माइग्रेशन

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

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

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

लक्ष्य

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

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

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

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

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

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

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

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

मान

  • select() या --cpu जैसे हार्ड-कोड किए गए फ़्लैग के बजाय, उन प्रॉपर्टी पर टूलचेन चुनें जिनके बारे में आपको जानकारी चाहिए. उदाहरण के लिए, कई सीपीयू एक ही निर्देश सेट के साथ काम कर सकते हैं.
  • ज़्यादा सही बिल्ड. अगर ऊपर दिए गए उदाहरण में, select() के साथ --cpu का इस्तेमाल किया जाता है, तो उसी इंस्ट्रक्शन सेट के साथ काम करने वाला नया सीपीयू जोड़ने पर, 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 एक 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 अपने-आप एक ऐसी टूलचेन चुनता है जो बिल्ड मशीन पर चल सकती है और $ bazel build //:myproject --platforms=//:myplatform के लिए बाइनरी बना सकती है.//:myplatform इसे टूलचेन रिज़ॉल्यूशन कहा जाता है.

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

ज़्यादा जानकारी के लिए, यहां देखें.

स्थिति

फ़िलहाल, अलग-अलग भाषाओं के लिए प्लैटफ़ॉर्म की उपलब्धता अलग-अलग है. Bazel के सभी मुख्य नियम, प्लैटफ़ॉर्म पर माइग्रेट किए जा रहे हैं. हालांकि, इस प्रोसेस में समय लगेगा. ऐसा तीन मुख्य वजहों से होता है:

  1. नए toolchain API (ctx.toolchains) से टूल की जानकारी पाने के लिए, नियम के लॉजिक को अपडेट करना होगा. साथ ही, --cpu और --crosstool_top जैसी लेगसी सेटिंग को पढ़ना बंद करना होगा. यह काफ़ी आसान है.

  2. टूलचेन को मैनेज करने वाले लोगों को टूलचेन तय करनी होंगी. साथ ही, उन्हें उपयोगकर्ताओं के लिए उपलब्ध कराना होगा. ऐसा GitHub रिपॉज़िटरी और WORKSPACE एंट्री में किया जा सकता है. तकनीकी तौर पर यह आसान है, लेकिन उपयोगकर्ता अनुभव को बेहतर बनाने के लिए इसे सही तरीके से व्यवस्थित करना ज़रूरी है.

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

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

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

सामान्य प्लैटफ़ॉर्म प्रॉपर्टी

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

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

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

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

Apple

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

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

अन्य भाषाएं

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

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

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" } में बदलना होगा. इसके अलावा, माइग्रेशन विंडो के दौरान दोनों स्टाइल को सपोर्ट करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.

आज के समय में प्लैटफ़ॉर्म का इस्तेमाल कैसे करें

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

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

  1. अपने प्रोजेक्ट की भाषाओं के लिए, "प्लैटफ़ॉर्म का इस्तेमाल करें" फ़्लैग चालू करें (अगर उनके पास कोई फ़्लैग है). साथ ही, यह देखने के लिए ज़रूरी टेस्टिंग करें कि आपके प्रोजेक्ट काम कर रहे हैं या नहीं.

  2. अगर आपके प्रोजेक्ट अब भी --cpu और --crosstool_top जैसे लेगसी फ़्लैग पर निर्भर हैं, तो इनका इस्तेमाल --platforms के साथ करें:

    bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...

    इसमें कुछ रखरखाव लागत लगती है. आपको मैन्युअल तरीके से यह पक्का करना होगा कि सेटिंग मेल खाती हों. हालांकि, ट्रांज़िशन के दौरान, इस सुविधा के काम न करने पर ऐसा हो सकता है.

  3. दोनों स्टाइल के साथ काम करने के लिए, प्लैटफ़ॉर्म मैपिंग लिखें. इसके लिए, --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 पर संपर्क करें. इसके अलावा, संबंधित नियमों के मालिकों से भी संपर्क किया जा सकता है.

प्लेटफ़ॉर्म/टूलचेन एपीआई के डिज़ाइन और डेवलपमेंट के बारे में चर्चा करने के लिए, bazel-dev@googlegroups.com पर संपर्क करें.

इन्हें भी देखें