Bazel में, प्लैटफ़ॉर्म और टूलचेन को मॉडलिंग करने के लिए बेहतर सुविधाएं मौजूद हैं. इसे रीयल प्रोजेक्ट के साथ इंटिग्रेट करने के लिए, कोड के मालिकों, नियम मैनेज करने वाले लोगों, और Baज़र के मुख्य डेवलपर के बीच सहयोग की ज़रूरत होती है.
इस पेज पर, प्लैटफ़ॉर्म बनाने के मकसद के बारे में खास जानकारी दी गई है. साथ ही, यह भी बताया गया है कि इन प्लैटफ़ॉर्म का इस्तेमाल कैसे किया जा सकता है.
खास जानकारी: Bazel का प्लैटफ़ॉर्म और टूलचेन एपीआई उपलब्ध हैं. हालांकि, ये सभी जगह काम नहीं करेंगे, जब तक सभी भाषा के नियम, select(), और अन्य लेगसी रेफ़रंस अपडेट नहीं किए जाते. यह काम जारी है. आखिरकार, सभी बिल्ड प्लैटफ़ॉर्म-आधारित होंगे.
यहां पढ़ें कि आपके बिल्ड किस कैटगरी में आते हैं.
ज़्यादा जानकारी के लिए, ये दस्तावेज़ देखें:
बैकग्राउंड
प्लैटफ़ॉर्म और टूलचेन की शुरुआत यह मानक तय करने के लिए की गई थी कि सॉफ़्टवेयर प्रोजेक्ट अलग-अलग मशीनों को कैसे टारगेट करते हैं और उन्हें सही भाषा टूल की मदद से कैसे बनाया जाता है.
यह Baज़ल की तुलना में हाल ही का है. भाषा के रखरखाव करने वाले लोग, पहले से ही इस काम को अलग-अलग तरीकों से कर रहे थे. इस बात से हमें प्रेरण मिली कि इस काम को एक ही तरीके से किया जा सकता है. उदाहरण के लिए, C++ नियम, किसी बिल्ड के टारगेट सीपीयू और C++ टूलचेन को सेट करने के लिए, --cpu और --crosstool_top का इस्तेमाल करते हैं. इनमें से कोई भी "प्लैटफ़ॉर्म" को सही तरीके से मॉडल नहीं करता. ऐसा करने की पिछली कोशिशों की वजह से, अजीब और गलत बिल्ड बनते थे.
ये फ़्लैग, Java कंपाइलेशन को भी कंट्रोल नहीं करते. --java_toolchain के साथ, Java ने अपना अलग इंटरफ़ेस विकसित किया है.
Bazel का मकसद, बड़े, कई भाषाओं वाले, और कई प्लैटफ़ॉर्म के प्रोजेक्ट के लिए है. इसके लिए, इन कॉन्सेप्ट के लिए ज़्यादा मदद की ज़रूरत है. इसमें ऐसे एपीआई भी शामिल हैं जो भाषा और प्रोजेक्ट के साथ काम करने की सुविधा को बढ़ावा देते हैं. इन नए एपीआई का यही मकसद है.
माइग्रेशन
प्लैटफ़ॉर्म और टूलचेन एपीआई सिर्फ़ तब काम करते हैं, जब प्रोजेक्ट उनका इस्तेमाल करते हैं. यह आसान काम नहीं है, क्योंकि प्रोजेक्ट के नियम के लॉजिक, टूलचेन, डिपेंडेंसी, और select() को इनका इस्तेमाल करना होगा. इसके लिए सावधानी से माइग्रेशन क्रम की ज़रूरत होती है,
ताकि सभी प्रोजेक्ट और उनकी डिपेंडेंसी सही तरीके से काम कर सकें.
उदाहरण के लिए, Basel का 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()या टूलचेन चुने जा सकते हैं. उदाहरण के लिए, कई सीपीयू पर एक ही निर्देश सेट काम कर सकता है.- ज़्यादा सही बिल्ड. अगर ऊपर दिए गए उदाहरण में
--cpuके साथselect(), तो एक ऐसा नया सीपीयू जोड़ें जो उसी निर्देश सेट के साथ काम करता हो, तो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, स्टारलार्क का नियम है. इसके एट्रिब्यूट से, किसी भाषा के टूल (जैसे, compiler =
"//mytoolchain:custom_gcc") के बारे में पता चलता है. इसके प्रोवाइडर, इस जानकारी को उन नियमों को पास करते हैं जिन्हें इन टूल के साथ बनाना ज़रूरी है.
टूलचेन उन मशीनों के constraint_value की जानकारी देते हैं जिन्हें वे
टारगेट
(target_compatible_with = ["@platforms//os:linux"]) कर सकती हैं. साथ ही, वे उन मशीनों के बारे में भी बताती हैं जिन पर उनके टूल
चले
(exec_compatible_with = ["@platforms//os:mac"]) सकते हैं.
$ bazel build //:myproject --platforms=//:myplatform बनाते समय, Basel एक टूलचेन को
अपने-आप चुनता है. यह टूल, बिल्ड मशीन पर चल सकता है और //:myplatform के लिए बाइनरी बना सकता है. इसे टूलचेन रिज़ॉल्यूशन के नाम से जाना जाता है.
उपलब्ध टूलचेन का सेट, WORKSPACE में register_toolchains या कमांड लाइन में --extra_toolchains के साथ रजिस्टर किया जा सकता है.
ज़्यादा जानकारी के लिए यहां देखें.
स्थिति
मौजूदा प्लैटफ़ॉर्म पर यह सुविधा, अलग-अलग भाषाओं में उपलब्ध है. बेज़ल के सभी मुख्य नियम प्लैटफ़ॉर्म पर शिफ़्ट हो रहे हैं. हालांकि, इस प्रोसेस में समय लगेगा. ऐसा तीन मुख्य वजहों से होता है:
नए toolchain API (
ctx.toolchains) से टूल की जानकारी पाने और--cpuऔर--crosstool_topजैसी लेगसी सेटिंग को पढ़ने से रोकने के लिए, नियम के लॉजिक को अपडेट करना ज़रूरी है. यह अपेक्षाकृत आसान है.टूलचेन मैनेजर को टूलचेन तय करने चाहिए और उन्हें उपयोगकर्ताओं के लिए ऐक्सेस करना चाहिए (GitHub रिपॉज़िटरी और
WORKSPACEएंट्री में). यह तकनीकी रूप से सरल है, लेकिन एक आसान उपयोगकर्ता अनुभव बनाए रखने के लिए बेहतर तरीके से व्यवस्थित किया जाना चाहिए.प्लैटफ़ॉर्म की परिभाषाएं भी ज़रूरी हैं (जब तक कि आपने उसी मशीन के लिए बिल्ड न किया हो जिस पर Bazel काम करता है). आम तौर पर, प्रोजेक्ट को अपने प्लैटफ़ॉर्म तय करने चाहिए.
मौजूदा प्रोजेक्ट को माइग्रेट करना ज़रूरी है.
select()और ट्रांज़िशन को भी माइग्रेट करना होगा. यह सबसे बड़ी चुनौती है. यह खास तौर पर, कई भाषाओं वाले प्रोजेक्ट के लिए चुनौती भरा होता है. हालांकि, अगर सभी भाषाओं को--platformsनहीं पढ़ा जा सकता, तो हो सकता है कि यह काम न करे.
अगर कोई नया नियम सेट डिज़ाइन किया जा रहा है, तो आपको शुरू से ही प्लैटफ़ॉर्म के साथ काम करना होगा. इससे आपके नियम, अन्य नियमों और प्रोजेक्ट के साथ अपने-आप काम करने लगते हैं. साथ ही, प्लैटफ़ॉर्म एपीआई के ज़्यादा इस्तेमाल होने पर, इन नियमों की वैल्यू भी बढ़ती है.
प्लैटफ़ॉर्म की सामान्य प्रॉपर्टी
OS और CPU जैसी प्लैटफ़ॉर्म प्रॉपर्टी, जो सभी प्रोजेक्ट में एक जैसी हैं
इन्हें स्टैंडर्ड और एक ही जगह पर रखा जाना चाहिए. इससे क्रॉस-प्रोजेक्ट और
दूसरी भाषाओं में काम करने की सुविधा को बढ़ावा मिलता है.
उदाहरण के लिए, अगर MyApp में constraint_value पर select() और SomeCommonLib में @commonlib//constraints:arm पर select() है, तो ये अपने "arm" मोड को, काम न करने वाली शर्तों के साथ ट्रिगर करते हैं.
दुनिया भर में काम करने वाली सामान्य प्रॉपर्टी, @platforms रिपॉज़िटरी में बताई जाती हैं. इसलिए, ऊपर दिए गए उदाहरण के लिए कैननिकल लेबल @platforms//cpu:arm है. भाषा के हिसाब से काम करने वाली सामान्य प्रॉपर्टी, अपनी भाषा के रिपॉज़िटरी में बताई जानी चाहिए.
डिफ़ॉल्ट प्लैटफ़ॉर्म
आम तौर पर, प्रोजेक्ट के मालिकों को साफ़ तौर पर प्लैटफ़ॉर्म तय करने चाहिए, ताकि वे उन मशीनों के बारे में बता सकें जिनके लिए उन्हें ऐप्लिकेशन बनाना है. इसके बाद, ये
--platforms से ट्रिगर होते हैं.
जब --platforms को सेट नहीं किया जाता है, तो Baze डिफ़ॉल्ट रूप से लोकल बिल्ड मशीन के बारे में बताने वाली platform वैल्यू चुन लेता है. यह @local_config_platform//:host पर अपने-आप जनरेट होता है. इसलिए, इसे साफ़ तौर पर बताने की ज़रूरत नहीं है. यह स्थानीय मशीन के OS और CPU को @platforms में बताए गए constraint_value से मैप करता है.
C++
जब आप सेट करते हैं, तब बेज़ल के 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
Basel के Apple के नियम, फ़िलहाल Apple के टूलचेन को चुनने के लिए किसी प्लैटफ़ॉर्म का इस्तेमाल नहीं करते.
ये प्लैटफ़ॉर्म पर काम करने वाली C++ डिपेंडेंसी के साथ भी काम नहीं करते, क्योंकि ये C++ टूलचेन सेट करने के लिए, लेगसी --crosstool_top का इस्तेमाल करते हैं. जब तक इसे माइग्रेट नहीं किया जाता, तब तक प्लैटफ़ॉर्म मैपिंग (उदाहरण) की मदद से, Apple प्रोजेक्ट को प्लैटफ़ॉर्म के साथ काम करने वाले C++ के साथ मिक्स किया जा सकता है.
अन्य भाषाएं
- बेज़ल के रस्ट रूल, प्लैटफ़ॉर्म पर पूरी तरह से काम करते हैं.
- Bazel के Go नियम, सभी प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं (जानकारी).
अगर किसी नई भाषा के लिए नियम डिज़ाइन किए जा रहे हैं, तो अपनी भाषा के टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करें. अच्छे तरीके से निर्देश पाने के लिए, toolchains से जुड़े दस्तावेज़ देखें.
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
Basel का इस्तेमाल, प्लैटफ़ॉर्म-आधारित और लेगसी, दोनों तरह की सभी सेटिंग की गारंटी देने के लिए किया जाता है. ये सेटिंग पूरे बिल्ड के दौरान लागू रहती हैं. इनमें ट्रांज़िशन की सेटिंग भी शामिल हैं.
डिफ़ॉल्ट रूप से, Basel आपके फ़ाइल फ़ोल्डर के रूट में platform_mappings फ़ाइल की मैपिंग को पढ़ता है. --platform_mappings=//:my_custom_mapping को भी सेट किया जा सकता है.
पूरी जानकारी के लिए, यहां देखें.
सवाल
माइग्रेशन की समयावधि के बारे में सामान्य मदद पाने और सवालों के जवाब पाने के लिए, bazel-discuss@googlegroups.com या ज़रूरी नियमों के मालिकों से संपर्क करें.
प्लैटफ़ॉर्म/toolchain API के डिज़ाइन और आगे बढ़ने के बारे में बातचीत करने के लिए, bazel-dev@googlegroups.com से संपर्क करें.