Bazel में, प्लैटफ़ॉर्म और टूलचेन को मॉडलिंग करने के लिए बेहतर सुविधाएं मौजूद हैं. इसे असली प्रोजेक्ट के साथ इंटिग्रेट करने के लिए, कोड के मालिकों, नियमों को बनाए रखने वाले लोगों, और Bazel के मुख्य डेवलपर के बीच सावधानी से काम करना ज़रूरी है.
इस पेज पर, प्लैटफ़ॉर्म के मकसद के बारे में खास जानकारी दी गई है. साथ ही, इन प्लैटफ़ॉर्म का इस्तेमाल करके ऐप्लिकेशन बनाने का तरीका भी बताया गया है.
खास जानकारी: Bazel का प्लैटफ़ॉर्म और टूलचेन एपीआई उपलब्ध हैं. हालांकि, ये सभी जगह काम नहीं करेंगे, जब तक सभी भाषा के नियम, select(), और अन्य लेगसी रेफ़रंस अपडेट नहीं किए जाते. यह काम जारी है. आखिर में, सभी बिल्ड प्लैटफ़ॉर्म पर आधारित होंगे.
यहां पढ़ें कि आपके बिल्ड किस कैटगरी में आते हैं.
ज़्यादा जानकारी के लिए, ये दस्तावेज़ देखें:
बैकग्राउंड
प्लैटफ़ॉर्म और टूलचेन को इसलिए पेश किया गया था, ताकि यह स्टैंडर्ड किया जा सके कि सॉफ़्टवेयर प्रोजेक्ट, अलग-अलग मशीनों को कैसे टारगेट करते हैं और सही भाषा टूल की मदद से कैसे बनाए जाते हैं.
यह Bazel में हाल ही में जोड़ा गया है. भाषा के रखरखाव करने वाले लोग, पहले से ही इस काम को अलग-अलग तरीकों से कर रहे थे. इस बात से हमें प्रेरण मिली कि इस काम को एक ही तरीके से किया जा सकता है. उदाहरण के लिए, C++ नियम, किसी बिल्ड के टारगेट सीपीयू और C++ टूलचेन को सेट करने के लिए, --cpu और --crosstool_top का इस्तेमाल करते हैं. इनमें से कोई भी "प्लैटफ़ॉर्म" को सही तरीके से मॉडल नहीं करता. ऐसा करने की पिछली कोशिशों की वजह से, अजीब और गलत बिल्ड बनते थे.
ये फ़्लैग, Java कंपाइलेशन को भी कंट्रोल नहीं करते. --java_toolchain के साथ, Java ने अपना अलग इंटरफ़ेस विकसित किया है.
Bazel का मकसद, बड़े, कई भाषाओं वाले, और कई प्लैटफ़ॉर्म के प्रोजेक्ट के लिए है. इसके लिए, इन कॉन्सेप्ट के लिए ज़्यादा मदद की ज़रूरत है. इसमें ऐसे एपीआई भी शामिल हैं जो भाषा और प्रोजेक्ट के साथ काम करने की सुविधा को बढ़ावा देते हैं. इन नए एपीआई का यही मकसद है.
माइग्रेशन
प्लैटफ़ॉर्म और टूलचेन एपीआई सिर्फ़ तब काम करते हैं, जब प्रोजेक्ट उनका इस्तेमाल करते हैं. यह आसान काम नहीं है, क्योंकि प्रोजेक्ट के नियम के लॉजिक, टूलचेन, डिपेंडेंसी, और select() को इनका इस्तेमाल करना होगा. सभी प्रोजेक्ट और उनकी डिपेंडेंसी को सही तरीके से काम करते रखने के लिए, माइग्रेशन का क्रम ध्यान से तय करना ज़रूरी है.
उदाहरण के लिए, Bazel के C++ नियम, प्लैटफ़ॉर्म के साथ काम करते हैं. हालांकि, Apple के नियम ऐसा नहीं करते. ऐसा हो सकता है कि आपके C++ प्रोजेक्ट में Apple के बारे में कोई जानकारी न हो. हालांकि, कुछ अन्य प्लैटफ़ॉर्म पर ऐसा हो सकता है. इसलिए, फ़िलहाल सभी C++ बिल्ड के लिए, दुनिया भर में प्लैटफ़ॉर्म को चालू करना सुरक्षित नहीं है.
इस पेज के बाकी हिस्से में, माइग्रेशन के क्रम के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि आपके प्रोजेक्ट इसमें कब और कैसे शामिल किए जा सकते हैं.
लक्ष्य
Bazel के प्लैटफ़ॉर्म का माइग्रेशन तब पूरा हो जाता है, जब सभी प्रोजेक्ट इस फ़ॉर्म के साथ बने हों:
bazel build //:myproject --platforms=//:myplatformइसका मतलब है कि:
- आपके प्रोजेक्ट में इस्तेमाल किए गए नियमों से,
//:myplatformसे सही टूलचेन का पता लगाया जा सकता है. - आपके प्रोजेक्ट की डिपेंडेंसी के नियमों से,
//:myplatformसे सही टूलचेन का अनुमान लगाया जा सकता है. - या आपके प्रोजेक्ट पर निर्भर प्रोजेक्ट,
//:myplatformके साथ काम करते हैं या आपका प्रोजेक्ट,--crosstool_topजैसे लेगसी एपीआई के साथ काम करता है. //:myplatformCPU,OS, और अन्य सामान्य कॉन्सेप्ट के [common declarations][Common Platform Declaration]{: .external} का रेफ़रंस देता है. ये कॉन्सेप्ट, एक से ज़्यादा प्रोजेक्ट के साथ अपने-आप काम करने की सुविधा के साथ काम करते हैं.- काम के सभी प्रोजेक्ट के
select(),//:myplatformसे जुड़ी मशीन प्रॉपर्टी को समझते हैं. //: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 के सभी मुख्य नियम, प्लैटफ़ॉर्म पर शिफ़्ट हो रहे हैं. हालांकि, इस प्रोसेस में समय लगेगा. ऐसा तीन मुख्य वजहों से होता है:
नए टूलचेन एपीआई (
ctx.toolchains) से टूल की जानकारी पाने और--cpuऔर--crosstool_topजैसी लेगसी सेटिंग को पढ़ने से रोकने के लिए, नियम का लॉजिक अपडेट करना ज़रूरी है. यह अपेक्षाकृत आसान है.टूलचेन मैनेजर को टूलचेन तय करने चाहिए और उन्हें उपयोगकर्ताओं के लिए ऐक्सेस करना चाहिए. ऐसा, GitHub रिपॉज़िटरी और
WORKSPACEएंट्री में किया जा सकता है. तकनीकी तौर पर, यह आसान है. हालांकि, उपयोगकर्ता अनुभव को बेहतर बनाए रखने के लिए, इसे बेहतर तरीके से व्यवस्थित करना ज़रूरी है.प्लैटफ़ॉर्म की परिभाषाएं भी ज़रूरी हैं (जब तक कि आपने उसी मशीन के लिए बिल्ड न किया हो जिस पर Bazel काम करता है). आम तौर पर, प्रोजेक्ट को अपने प्लैटफ़ॉर्म तय करने चाहिए.
मौजूदा प्रोजेक्ट को माइग्रेट करना ज़रूरी है.
select()और ट्रांज़िशन को भी माइग्रेट करना होगा. यह सबसे बड़ी चुनौती है. यह कई भाषाओं वाले प्रोजेक्ट के लिए खास तौर पर चुनौती भरा होता है. अगर सभी भाषाओं में--platformsको पढ़ा नहीं जा सकता, तो प्रोजेक्ट पूरा नहीं हो सकता.
अगर कोई नया नियम सेट डिज़ाइन किया जा रहा है, तो आपको शुरू से ही प्लैटफ़ॉर्म के साथ काम करना होगा. इससे आपके नियम, अन्य नियमों और प्रोजेक्ट के साथ अपने-आप काम करने लगते हैं. साथ ही, प्लैटफ़ॉर्म एपीआई के ज़्यादा इस्तेमाल होने पर, इन नियमों की वैल्यू भी बढ़ती है.
प्लैटफ़ॉर्म की सामान्य प्रॉपर्टी
OS और CPU जैसी प्लैटफ़ॉर्म प्रॉपर्टी, सभी प्रोजेक्ट में एक जैसी होती हैं. इसलिए, इन्हें एक स्टैंडर्ड और एक ही जगह पर एलान किया जाना चाहिए. इससे, अलग-अलग प्रोजेक्ट और भाषाओं के साथ काम करने की सुविधा मिलती है.
उदाहरण के लिए, अगर MyApp में constraint_value पर select() और SomeCommonLib में @commonlib//constraints:arm पर select() है, तो ये अपने "arm" मोड को, काम न करने वाली शर्तों के साथ ट्रिगर करते हैं.@myapp//cpus:arm
दुनिया भर में काम करने वाली सामान्य प्रॉपर्टी, @platforms रिपॉज़िटरी में बताई जाती हैं. इसलिए, ऊपर दिए गए उदाहरण के लिए कैननिकल लेबल @platforms//cpu:arm है. भाषा के हिसाब से काम करने वाली सामान्य प्रॉपर्टी, अपनी भाषा के रिपॉज़िटरी में बताई जानी चाहिए.
डिफ़ॉल्ट प्लैटफ़ॉर्म
आम तौर पर, प्रोजेक्ट के मालिकों को साफ़ तौर पर प्लैटफ़ॉर्म तय करने चाहिए, ताकि वे उन मशीनों के बारे में बता सकें जिनके लिए उन्हें ऐप्लिकेशन बनाना है. इसके बाद, इन्हें --platforms से ट्रिगर किया जाता है.
--platforms सेट न होने पर, Bazel डिफ़ॉल्ट रूप से platform पर सेट हो जाता है. यह 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 नियम, टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
यह सुविधा डिफ़ॉल्ट रूप से चालू नहीं होती. हालांकि, माइग्रेशन की प्रोसेस जारी है.
Apple
Bazel के Apple के नियमों के मुताबिक, फ़िलहाल Apple के टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल नहीं किया जा सकता.
ये प्लैटफ़ॉर्म पर काम करने वाली C++ डिपेंडेंसी के साथ भी काम नहीं करते, क्योंकि ये C++ टूलचेन सेट करने के लिए, लेगसी --crosstool_top का इस्तेमाल करते हैं. जब तक इसे माइग्रेट नहीं किया जाता, तब तक प्लैटफ़ॉर्म मैपिंग (उदाहरण) की मदद से, Apple प्रोजेक्ट को प्लैटफ़ॉर्म के साथ काम करने वाले C++ के साथ मिक्स किया जा सकता है.
अन्य भाषाएं
- Bazel के Rust नियम, प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं.
- Bazel के Go नियम, सभी प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं (जानकारी).
अगर किसी नई भाषा के लिए नियम डिज़ाइन किए जा रहे हैं, तो अपनी भाषा के टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करें. ज़्यादा जानकारी के लिए, टूलचेन का दस्तावेज़ देखें.
select()
प्रोजेक्ट, constraint_value टारगेट पर select() किए जा सकते हैं, लेकिन सभी प्लैटफ़ॉर्म पर नहीं. ऐसा इसलिए किया गया है, ताकि select()s ज़्यादा से ज़्यादा तरह की मशीनों पर काम कर सके. 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" } में बदलना होगा या माइग्रेशन विंडो के दौरान दोनों स्टाइल के साथ काम करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.
आज के दौर में प्लैटफ़ॉर्म इस्तेमाल करने का तरीका
अगर आपको सिर्फ़ किसी प्रोजेक्ट को बनाना है या क्रॉस-कंपाइल करना है, तो आपको प्रोजेक्ट के आधिकारिक दस्तावेज़ों का पालन करना चाहिए. यह तय करना भाषा और प्रोजेक्ट के रखरखाव करने वालों का काम है कि प्लैटफ़ॉर्म के साथ कैसे और कब इंटिग्रेट किया जाए. साथ ही, यह भी तय करना कि इससे क्या फ़ायदा मिलेगा.
अगर आप किसी प्रोजेक्ट, भाषा या टूलचेन के मैनेजर हैं और आपका बिल्ड डिफ़ॉल्ट रूप से प्लैटफ़ॉर्म का इस्तेमाल नहीं करता है, तो आपके पास ग्लोबल माइग्रेशन के इंतज़ार के अलावा, ये तीन विकल्प हैं:
अपने प्रोजेक्ट की भाषाओं के लिए, "प्लैटफ़ॉर्म का इस्तेमाल करें" फ़्लैग को चालू करें (अगर उनके पास एक है). साथ ही, यह देखने के लिए ज़रूरी टेस्ट करें कि आपके काम के प्रोजेक्ट काम कर रहे हैं या नहीं.
अगर आपके पसंदीदा प्रोजेक्ट अब भी
--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 या संबंधित नियमों के मालिकों से संपर्क करें.
प्लैटफ़ॉर्म/टूलचेन एपीआई के डिज़ाइन और विकास के बारे में चर्चा करने के लिए, bazel-dev@googlegroups.com पर संपर्क करें.