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

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

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

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

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

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