Babel के पास प्लैटफ़ॉर्म और टूलचेन की मॉडलिंग का बेहतरीन तरीके से इस्तेमाल किया जा सकता है. इसे रीयल प्रोजेक्ट के साथ इंटिग्रेट करने के लिए, कोड के मालिकों, नियम में मदद करने वालों, और Baज़र के मुख्य डेवलपर के बीच सहयोग की ज़रूरत होती है.
इस पेज पर, प्लैटफ़ॉर्म बनाने के मकसद के बारे में खास जानकारी दी गई है. साथ ही, उन्हें बनाने का तरीका भी बताया गया है.
tl;dr: Basel का प्लैटफ़ॉर्म और Toolchain API उपलब्ध हैं, लेकिन ये हर जगह तब तक काम नहीं करेंगे, जब तक कि भाषा के सभी नियम, select(), और अन्य लेगसी रेफ़रंस अपडेट नहीं हो जाते. यह काम जारी है. आखिरकार, सभी बिल्ड प्लैटफ़ॉर्म-आधारित होंगे.
आपके बिल्ड कहां फ़िट होते हैं, यह जानने के लिए नीचे पढ़ें.
ज़्यादा औपचारिक दस्तावेज़ के लिए, इन्हें देखें:
बैकग्राउंड
प्लैटफ़ॉर्म और टूलचेन की शुरुआत यह मानक बनाने के लिए की गई थी कि सॉफ़्टवेयर प्रोजेक्ट अलग-अलग मशीनों को कैसे टारगेट करते हैं और उन्हें सही भाषा टूल की मदद से कैसे बनाया जाता है.
यह Baज़ल की तुलना में हाल ही का है. यह देखने से प्रेरणा मिली
कि भाषा का रखरखाव करने वाले लोग पहले से ही ऐड-हॉक और गलत तरीकों से ऐसा कर रहे थे. उदाहरण के लिए, बिल्ड का टारगेट सीपीयू और C++ टूलचेन सेट करने के लिए, C++ के नियम --cpu और --crosstool_top का इस्तेमाल करते हैं. इनमें से कोई भी एक सही "प्लैटफ़ॉर्म"
को मॉडल नहीं करता. ऐसा करने की ऐतिहासिक कोशिशों की वजह से, बनाना अजीब और गलत तरीके से बना था.
ये फ़्लैग, Java को कंपाइल करने की सुविधा को भी कंट्रोल नहीं करते हैं, जिसने --java_toolchain के साथ अपना इंडिपेंडेंट इंटरफ़ेस डेवलप किया है.
Basel को बड़े, कई भाषाओं वाले, और कई प्लैटफ़ॉर्म पर काम करने वाले प्रोजेक्ट के लिए बनाया गया है. इसलिए, इन सिद्धांतों को लागू करने के लिए, ज़्यादा सैद्धांतिक तौर पर मदद करने की ज़रूरत पड़ती है. इसमें ऐसे एपीआई भी शामिल हैं जो भाषा और प्रोजेक्ट इंटरऑपरेबिलिटी को बढ़ावा देते हैं. ये नए एपीआई इसी काम के लिए हैं.
माइग्रेशन
प्लैटफ़ॉर्म और टूलचेन एपीआई सिर्फ़ तब काम करते हैं, जब प्रोजेक्ट उनका इस्तेमाल करते हैं. यह मामूली बात नहीं है, क्योंकि प्रोजेक्ट के नियम का लॉजिक, टूलचेन, डिपेंडेंसी, और
select() को इनके साथ काम करना होता है. इसके लिए सावधानी से माइग्रेशन क्रम की ज़रूरत होती है,
ताकि सभी प्रोजेक्ट और उनकी डिपेंडेंसी सही तरीके से काम कर सकें.
उदाहरण के लिए, Basel का C++ रूल सहायता प्लैटफ़ॉर्म है. हालांकि, Apple के नियम लागू नहीं होते. ऐसा हो सकता है कि आपका C++ प्रोजेक्ट Apple की परवाह न करता हो. हालांकि, कुछ ऐसा कर सकते हैं. इसलिए, सभी C++ बिल्ड के लिए प्लैटफ़ॉर्म को दुनिया भर में चालू करना फ़िलहाल सुरक्षित नहीं है.
इस पेज के बाकी हिस्से में, माइग्रेशन के इस क्रम के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि आपके प्रोजेक्ट कब और कैसे फ़िट हो सकते हैं.
लक्ष्य
जब सभी प्रोजेक्ट इस फ़ॉर्म के साथ तैयार होते हैं, तब Baज़र का प्लैटफ़ॉर्म माइग्रेशन पूरा हो जाता है:
bazel build //:myproject --platforms=//:myplatform
इसका मतलब है कि:
- आपके प्रोजेक्ट में जिन नियमों का इस्तेमाल किया जाता है वे
//:myplatformसे सही टूलचेन का अनुमान लगा सकते हैं. - आपके प्रोजेक्ट की डिपेंडेंसी का इस्तेमाल करने वाले नियमों से,
//:myplatformसे सही टूलचेन का पता लग सकता है. - या तो इस आधार पर कि प्रोजेक्ट आपके साथ काम कर रहे हैं
//:myplatformया आपका प्रोजेक्ट, लेगसी एपीआई (जैसे कि--crosstool_top) के साथ काम करता है. //:myplatformरेफ़रंस [सामान्य एलान]CPU,OSमें से [सामान्य प्लैटफ़ॉर्म का एलान]{: .external} और दूसरे सामान्य कॉन्सेप्ट हैं जो क्रॉस-प्रोजेक्ट के साथ अपने-आप काम करने की सुविधा के साथ काम करते हैं.- सभी ज़रूरी प्रोजेक्ट के
select(),//:myplatformमें लागू की गई मशीन प्रॉपर्टी को समझते हैं. //:myplatformको किसी साफ़ और फिर से इस्तेमाल करने लायक जगह पर बनाया गया है: अगर यह प्लैटफ़ॉर्म आपके प्रोजेक्ट के लिए खास है, तो आपके प्रोजेक्ट के रेपो में. ऐसा नहीं होने पर, इस प्लैटफ़ॉर्म का इस्तेमाल करने वाले सभी प्रोजेक्ट को ये प्रोजेक्ट मिल सकते हैं.
इस लक्ष्य के पूरा होते ही, पुराने एपीआई हटा दिए जाएंगे. इसके बाद, यह प्लैटफ़ॉर्म और टूलचेन को चुनने का स्टैंडर्ड तरीका होगा.
क्या मुझे प्लैटफ़ॉर्म का इस्तेमाल करना चाहिए?
अगर आपको किसी प्रोजेक्ट को सिर्फ़ बनाना या क्रॉस-कंपाइल करना है, तो आपको प्रोजेक्ट के आधिकारिक दस्तावेज़ फ़ॉलो करने चाहिए.
अगर आप कोई प्रोजेक्ट, भाषा या टूलचेन मेंटेनर हैं, तो आपको नए एपीआई के साथ काम करना होगा. ग्लोबल माइग्रेशन के पूरा होने तक इंतज़ार करना या जल्दी ऑप्ट इन करना, आपकी वैल्यू / लागत की ज़रूरतों पर निर्भर करता है:
वैल्यू
select()या--cpuजैसे हार्ड कोड किए गए फ़्लैग के बजाय, अपनी पसंदीदा प्रॉपर्टी के लिए टूलचेन को चुना जा सकता है. उदाहरण के लिए, कई सीपीयू पर एक ही निर्देश सेट काम कर सकता है.- ज़्यादा सही बिल्ड. अगर ऊपर दिए गए उदाहरण में
--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एंट्री में). यह तकनीकी रूप से सरल है, लेकिन एक आसान उपयोगकर्ता अनुभव बनाए रखने के लिए बेहतर तरीके से व्यवस्थित किया जाना चाहिए.प्लैटफ़ॉर्म की परिभाषाएं भी ज़रूरी हैं (जब तक कि उसी मशीन के लिए बैज न बनाया गया हो जिस पर बैज चलता है). आम तौर पर, प्रोजेक्ट को अपने प्लैटफ़ॉर्म तय करने चाहिए.
मौजूदा प्रोजेक्ट माइग्रेट करने होंगे.
select()और ट्रांज़िशन को भी माइग्रेट करना होगा. यह सबसे बड़ी चुनौती है. यह खास तौर पर, कई भाषाओं वाले प्रोजेक्ट के लिए चुनौती भरा होता है. हालांकि, अगर सभी भाषाओं को--platformsनहीं पढ़ा जा सकता, तो हो सकता है कि यह काम न करे.
अगर आप नया नियमों का सेट डिज़ाइन कर रहे हैं, तो आपको शुरुआत से ही प्लैटफ़ॉर्म के साथ काम करना होगा. इससे आपके नियम, दूसरे नियमों और प्रोजेक्ट के साथ अपने-आप काम करते हैं. साथ ही, प्लैटफ़ॉर्म एपीआई के ज़्यादा से ज़्यादा हर जगह उपलब्ध होने पर, इसकी वैल्यू भी बढ़ती जाती है.
सामान्य प्लैटफ़ॉर्म प्रॉपर्टी
OS और CPU जैसी प्लैटफ़ॉर्म प्रॉपर्टी, जो सभी प्रोजेक्ट में एक जैसी हैं
इन्हें स्टैंडर्ड और एक ही जगह पर रखा जाना चाहिए. इससे क्रॉस-प्रोजेक्ट और
दूसरी भाषाओं में काम करने की सुविधा को बढ़ावा मिलता है.
उदाहरण के लिए, अगर MyApp के constraint_value
@myapp//cpus:arm पर select() है और SomeCommonLib के लिए select() चालू है@commonlib//constraints: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
बेज़ेल के Java के नियम, प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
यह लेगसी फ़्लैग --java_toolchain, --host_java_toolchain, --javabase, और --host_javabase की जगह ले लेगा.
कॉन्फ़िगरेशन फ़्लैग का इस्तेमाल करने का तरीका जानने के लिए, Bazu और Java मैन्युअल देखें. ज़्यादा जानकारी के लिए, डिज़ाइन दस्तावेज़ देखें.
अगर अब भी लेगसी फ़्लैग का इस्तेमाल किया जा रहा है, तो समस्या #7849 में दी गई माइग्रेशन प्रोसेस अपनाएं.
Android
जब --incompatible_enable_android_toolchain_resolution को सेट किया जाता है, तो बेज़ेल के Android के नियम, टूलचेन को चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
यह सुविधा डिफ़ॉल्ट रूप से चालू नहीं होती. लेकिन माइग्रेशन जारी है.
Apple
Basel के Apple के नियम, फ़िलहाल Apple के टूलचेन को चुनने के लिए किसी प्लैटफ़ॉर्म का इस्तेमाल नहीं करते.
इसके अलावा, ये प्लैटफ़ॉर्म के साथ काम करने वाली C++ डिपेंडेंसी के साथ भी काम नहीं करते, क्योंकि वे C++ टूलचेन को सेट करने के लिए
लेगसी --crosstool_top का इस्तेमाल करते हैं. जब तक इसे माइग्रेट नहीं किया जाता, तब तक Apple प्रोजेक्ट को प्लैटफ़ॉर्म मैपिंग के साथ platorm-चालू C++ के साथ मिक्स
किया जा सकता है (उदाहरण).
अन्य भाषाएं
- बेज़ल के रस्ट रूल, प्लैटफ़ॉर्म पर पूरी तरह से काम करते हैं.
- Basel के Go के नियम, सभी प्लैटफ़ॉर्म पर पूरी तरह काम करते हैं (ज़्यादा जानकारी).
अगर आपको किसी नई भाषा के लिए नियम तय करने हैं, तो अपनी भाषा के टूलचेन को चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करें. अच्छे तरीके से निर्देश पाने के लिए, toolchains से जुड़े दस्तावेज़ देखें.
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" } में बदलना होगा या माइग्रेशन विंडो से दोनों स्टाइल के साथ काम करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.
आज प्लैटफ़ॉर्म इस्तेमाल करने का तरीका
अगर आपको किसी प्रोजेक्ट को सिर्फ़ बनाना या क्रॉस-कंपाइल करना है, तो आपको प्रोजेक्ट के आधिकारिक दस्तावेज़ फ़ॉलो करने चाहिए. यह भाषा और प्रोजेक्ट मेंटेन करने वालों पर निर्भर करता है कि उन्हें प्लैटफ़ॉर्म के साथ कैसे और कब इंटिग्रेट करना है और उनसे क्या फ़ायदा मिल सकता है.
अगर आप कोई प्रोजेक्ट, भाषा या टूलचेन मेंटेनर हैं और आपका बिल्ड डिफ़ॉल्ट रूप से प्लैटफ़ॉर्म का इस्तेमाल नहीं करता है, तो आपके पास तीन विकल्प हैं (ग्लोबल माइग्रेशन के लिए इंतज़ार करने के अलावा):
अपने प्रोजेक्ट की भाषाओं के लिए "प्लैटफ़ॉर्म का इस्तेमाल करें" फ़्लैग को फ़्लिप करें (अगर उनमें एक है) और जो भी प्रोजेक्ट ज़रूरी हैं वे काम कर रहे हैं या नहीं, यह देखने के लिए उनकी जांच कर लें.
अगर आपके पसंदीदा प्रोजेक्ट अब भी
--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 से संपर्क करें.