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

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

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

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

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

बैकग्राउंड

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

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

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

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

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

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

मान

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

प्रोजेक्ट, 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. अपने प्रोजेक्ट की भाषाओं के लिए, "use platforms" फ़्लैग चालू करें (अगर उनमें से किसी के पास यह फ़्लैग है). साथ ही, यह देखने के लिए ज़रूरी टेस्टिंग करें कि आपके प्रोजेक्ट काम कर रहे हैं या नहीं.

  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 पर संपर्क करें.

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