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

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(), //: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"]) कर सकती हैं. साथ ही, उन मशीनों के 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 प्रोजेक्ट अब भी C++ डिपेंडेंसी को --cpu और --crosstool_top (उदाहरण) के साथ कॉन्फ़िगर करते हैं. इसलिए, यह इस बात पर निर्भर करता है कि 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 नियमों में प्लैटफ़ॉर्म पूरी तरह से काम करते हैं.
  • 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. अपने प्रोजेक्ट की भाषाओं के लिए, "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 पर संपर्क करें.

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