Bazel में, प्लैटफ़ॉर्म और टूलचेन को मॉडल करने के लिए, बेहतर सुविधाएं उपलब्ध हैं. इन्हें असल प्रोजेक्ट के साथ इंटिग्रेट करने के लिए, कोड के मालिकों, नियमों को बनाए रखने वाले लोगों, और Bazel के मुख्य डेवलपर के बीच सावधानी से सहयोग करना ज़रूरी है.
इस पेज पर, प्लैटफ़ॉर्म के मकसद के बारे में खास जानकारी दी गई है. साथ ही, यह भी बताया गया है कि प्लैटफ़ॉर्म की मदद से कैसे बनाया जा सकता है.
खास जानकारी: Bazel के प्लैटफ़ॉर्म और टूलचेन एपीआई उपलब्ध हैं. हालांकि, जब तक सभी भाषा के नियम, select() और अन्य लेगसी रेफ़रंस अपडेट नहीं किए जाते, तब तक ये एपीआई हर जगह काम नहीं करेंगे. इस पर काम जारी है. आने वाले समय में, सभी बिल्ड प्लैटफ़ॉर्म पर आधारित होंगे.
यह जानने के लिए कि आपके बिल्ड कहां फ़िट होते हैं, नीचे दिया गया लेख पढ़ें.
ज़्यादा जानकारी के लिए, ये दस्तावेज़ देखें:
बैकग्राउंड
प्लैटफ़ॉर्म और टूलचेन को इसलिए पेश किया गया, ताकि सॉफ़्टवेयर प्रोजेक्ट अलग-अलग मशीनों को टारगेट करने और सही भाषा के टूल की मदद से बिल्ड करने के तरीके को स्टैंडर्ड बनाया जा सके.
Bazel में, यह सुविधा हाल ही में जोड़ी गई है. यह सुविधा, इस बात को ध्यान में रखकर जोड़ी गई है कि भाषा को बनाए रखने वाले लोग, पहले से ही इस काम को अलग-अलग और असंगत तरीकों से कर रहे थे. उदाहरण के लिए, C++ के नियम, बिल्ड के टारगेट सीपीयू और C++ टूलचेन को सेट करने के लिए, --cpu और --crosstool_top का इस्तेमाल करते हैं. इनमें से कोई भी "प्लैटफ़ॉर्म" को सही तरीके से मॉडल नहीं करता. ऐसा करने की पिछली कोशिशों की वजह से, अजीब और गलत बिल्ड तैयार हुए थे.
इन फ़्लैग से, Java कंपाइलेशन को भी कंट्रोल नहीं किया जा सकता. Java कंपाइलेशन ने --java_toolchain के साथ अपना अलग इंटरफ़ेस तैयार किया है.
Bazel का इस्तेमाल, बड़े, कई भाषाओं वाले, और कई प्लैटफ़ॉर्म वाले प्रोजेक्ट के लिए किया जाता है. इसके लिए, इन कॉन्सेप्ट के लिए ज़्यादा सिद्धांतों पर आधारित सहायता की ज़रूरत होती है. इसमें ऐसे एपीआई शामिल हैं जो भाषा और प्रोजेक्ट के इंटरऑपरेबिलिटी को बढ़ावा देते हैं. ये नए एपीआई, इसी मकसद से बनाए गए हैं.
माइग्रेशन
प्लैटफ़ॉर्म और टूलचेन एपीआई सिर्फ़ तब काम करते हैं, जब प्रोजेक्ट असल में इनका इस्तेमाल करते हैं. यह आसान नहीं है, क्योंकि प्रोजेक्ट के नियम लॉजिक, टूलचेन, डिपेंडेंसी, और select() को इनका इस्तेमाल करना होता है. इसके लिए, माइग्रेशन का क्रम सावधानी से तय करना ज़रूरी है, ताकि सभी प्रोजेक्ट और उनकी डिपेंडेंसी सही तरीके से काम करती रहें.
उदाहरण के लिए, Bazel के C++ के नियम, प्लैटफ़ॉर्म के साथ काम करते हैं. हालांकि, Apple के नियम ऐसा नहीं करते. हो सकता है कि आपके C++ प्रोजेक्ट को Apple की ज़रूरत न हो. हालांकि, दूसरों को इसकी ज़रूरत हो सकती है. इसलिए, फ़िलहाल सभी C++ बिल्ड के लिए, प्लैटफ़ॉर्म को वैश्विक तौर पर चालू करना सुरक्षित नहीं है.
इस पेज के बाकी हिस्सों में, माइग्रेशन के इस क्रम के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि आपके प्रोजेक्ट, इस क्रम में कब और कैसे फ़िट हो सकते हैं.
लक्ष्य
Bazel का प्लैटफ़ॉर्म माइग्रेशन तब पूरा होता है, जब सभी प्रोजेक्ट इस फ़ॉर्मैट में बिल्ड होते हैं:
bazel build //:myproject --platforms=//:myplatformइसका मतलब है कि:
- आपके प्रोजेक्ट में इस्तेमाल किए जाने वाले नियम,
//:myplatformसे सही टूलचेन का अनुमान लगा सकते हैं. - आपके प्रोजेक्ट की डिपेंडेंसी में इस्तेमाल किए जाने वाले नियम,
//:myplatformसे सही टूलचेन का अनुमान लगा सकते हैं. - आपके प्रोजेक्ट पर निर्भर रहने वाले प्रोजेक्ट,
//:myplatformके साथ काम करते हैं या आपका प्रोजेक्ट, लेगसी एपीआई (जैसे,--crosstool_top) के साथ काम करता है. //:myplatformमें,CPU,OS, और अन्य सामान्य कॉन्सेप्ट के [सामान्य एलान][Common Platform Declaration]{: .external} के रेफ़रंस शामिल होते हैं. इनसे, अलग-अलग प्रोजेक्ट के बीच अपने-आप कंपैटिबिलिटी बनी रहती है.- सभी काम के प्रोजेक्ट के
select()s को,//:myplatformसे मिलने वाली मशीन की प्रॉपर्टी के बारे में पता होता है. //:myplatformको एक ऐसी जगह पर तय किया जाता है जहां इसे फिर से इस्तेमाल किया जा सकता है. अगर प्लैटफ़ॉर्म सिर्फ़ आपके प्रोजेक्ट के लिए है, तो इसे आपके प्रोजेक्ट के रेपो में तय किया जाता है. वहीं, अगर यह प्लैटफ़ॉर्म एक से ज़्यादा प्रोजेक्ट के लिए है, तो इसे ऐसी जगह पर तय किया जाता है जहां इस प्लैटफ़ॉर्म का इस्तेमाल करने वाले सभी प्रोजेक्ट इसे ढूंढ सकें.
यह लक्ष्य हासिल होने के बाद, पुराने एपीआई हटा दिए जाएंगे. इसके बाद, प्रोजेक्ट के लिए प्लैटफ़ॉर्म और टूलचेन चुनने का यही स्टैंडर्ड तरीका होगा.
क्या मुझे प्लैटफ़ॉर्म का इस्तेमाल करना चाहिए?
अगर आपको सिर्फ़ किसी प्रोजेक्ट को बिल्ड करना है या क्रॉस-कंपाइल करना है, तो आपको प्रोजेक्ट के आधिकारिक दस्तावेज़ में दिया गया तरीका अपनाना चाहिए.
अगर आप किसी प्रोजेक्ट, भाषा या टूलचेन को बनाए रखने वाले व्यक्ति हैं, तो आपको आने वाले समय में नए एपीआई के साथ काम करना होगा. यह तय करना कि आपको वैश्विक माइग्रेशन पूरा होने तक इंतज़ार करना है या पहले से ही नए एपीआई का इस्तेमाल करना है, आपकी खास वैल्यू / लागत की ज़रूरतों पर निर्भर करता है:
वैल्यू
- आपके पास
select()या टूलचेन चुनने का विकल्प होता है. इसके लिए, आपको उन प्रॉपर्टी का इस्तेमाल करना होता है जिनकी आपको ज़रूरत है. इसके बजाय, आपको--cpuजैसे हार्ड-कोड किए गए फ़्लैग का इस्तेमाल नहीं करना होता. उदाहरण के लिए, एक से ज़्यादा सीपीयू निर्देशों के एक ही सेट के साथ काम कर सकते हैं. - ज़्यादा सही बिल्ड. ऊपर दिए गए उदाहरण में, अगर आपने
--cpuके साथselect()किया है और फिर एक नया सीपीयू जोड़ा है जो निर्देशों के उसी सेट के साथ काम करता है, तोselect()नए सीपीयू को नहीं पहचान पाएगा. हालांकि, प्लैटफ़ॉर्म परselect()हमेशा सटीक रहता है. - उपयोगकर्ताओं को मिलेगा बेहतर अनुभव. सभी प्रोजेक्ट,
--platforms=//:myplatformको समझ सकते हैं. कमांड लाइन पर, भाषा के हिसाब से अलग-अलग फ़्लैग की ज़रूरत नहीं होती. - भाषा का डिज़ाइन आसान होता है. सभी भाषाएं, टूलचेन तय करने, टूलचेन का इस्तेमाल करने, और किसी प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने के लिए, एक ही एपीआई शेयर करती हैं.
- अगर टारगेट, टारगेट प्लैटफ़ॉर्म के साथ काम नहीं करते हैं, तो उन्हें बिल्ड और टेस्ट फ़ेज़ में स्किप किया जा सकता है.
लागत
- हो सकता है कि डिपेंडेंट प्रोजेक्ट, आपके प्रोजेक्ट के साथ अपने-आप काम न करें, क्योंकि वे प्लैटफ़ॉर्म के साथ काम नहीं करते.
- उन्हें आपके प्रोजेक्ट के साथ काम करने के लिए, अस्थायी तौर पर रखरखाव की ज़रूरत पड़ सकती है.
- नए और लेगसी एपीआई के साथ काम करने के लिए, उपयोगकर्ताओं को ज़्यादा सावधानी से निर्देश देने की ज़रूरत होती है, ताकि कोई भ्रम न हो.
- सामान्य प्रॉपर्टी के लिए, कैननिकल डेफ़िनिशन अब भी तैयार की जा रही हैं. जैसे
OSऔरCPU. इसके लिए, शुरुआती तौर पर ज़्यादा योगदान की ज़रूरत पड़ सकती है. - भाषा के हिसाब से टूलचेन के लिए, कैननिकल डेफ़िनिशन अब भी तैयार की जा रही हैं. इसके लिए, शुरुआती तौर पर ज़्यादा योगदान की ज़रूरत पड़ सकती है.
एपीआई के ज़रिए समीक्षा करना
A platform कलेक्शन होता है
constraint_value टारगेट का:
platform(
name = "myplatform",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:arm",
],
)
A 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 के सभी मुख्य नियम, प्लैटफ़ॉर्म पर माइग्रेट किए जा रहे हैं. हालांकि, इस प्रोसेस में समय लगेगा. इसकी तीन मुख्य वजहें हैं:
नियम लॉजिक को अपडेट करना होगा, ताकि नए टूलचेन एपीआई (
ctx.toolchains) से टूल की जानकारी मिल सके. साथ ही,--cpuऔर--crosstool_topजैसी लेगसी सेटिंग को पढ़ना बंद किया जा सके. यह अपेक्षाकृत आसान है.टूलचेन को बनाए रखने वाले लोगों को टूलचेन तय करने होंगे और उन्हें उपयोगकर्ताओं के लिए उपलब्ध कराना होगा. इसके लिए, उन्हें GitHub रिपॉज़िटरी और
WORKSPACEएंट्री में टूलचेन की जानकारी देनी होगी. तकनीकी तौर पर यह आसान है, लेकिन उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, इसे समझदारी से व्यवस्थित करना होगा.प्लैटफ़ॉर्म की डेफ़िनिशन भी ज़रूरी हैं. हालांकि, अगर आप उसी मशीन के लिए बिल्ड करते हैं जिस पर Bazel चलता है, तो प्लैटफ़ॉर्म की डेफ़िनिशन की ज़रूरत नहीं होती. आम तौर पर, प्रोजेक्ट को अपने प्लैटफ़ॉर्म तय करने चाहिए.
मौजूदा प्रोजेक्ट को माइग्रेट करना होगा.
select()और ट्रांज़िशन को भी माइग्रेट करना होगा. यह सबसे बड़ी चुनौती है. यह कई भाषाओं वाले प्रोजेक्ट के लिए खास तौर पर मुश्किल है. ऐसा इसलिए, क्योंकि अगर सभी भाषाएं--platformsको नहीं पढ़ पाती हैं, तो प्रोजेक्ट में गड़बड़ी हो सकती है.
अगर आपको नियमों का नया सेट डिज़ाइन करना है, तो आपको शुरुआत से ही प्लैटफ़ॉर्म के साथ काम करना होगा. इससे आपके नियम, अन्य नियमों और प्रोजेक्ट के साथ अपने-आप कंपैटिबल हो जाते हैं. साथ ही, प्लैटफ़ॉर्म एपीआई के ज़्यादा इस्तेमाल होने पर, इसकी वैल्यू भी बढ़ जाती है.
सामान्य प्लैटफ़ॉर्म प्रॉपर्टी
OS और CPU जैसी प्लैटफ़ॉर्म प्रॉपर्टी, सभी प्रोजेक्ट के लिए सामान्य होती हैं. इन्हें एक स्टैंडर्ड और केंद्रीकृत जगह पर तय किया जाना चाहिए. इससे, अलग-अलग प्रोजेक्ट और भाषाओं के बीच कंपैटिबिलिटी बनी रहती है.
उदाहरण के लिए, अगर MyApp में constraint_value
@myapp//cpus:arm पर select() है और SomeCommonLib में @commonlib//constraints:arm पर select() है, तो ये असंगत शर्तों के साथ अपने "arm" मोड को ट्रिगर करते हैं.
वैश्विक तौर पर सामान्य प्रॉपर्टी,
@platforms रेपो में तय की जाती हैं
(इसलिए, ऊपर दिए गए उदाहरण के लिए कैननिकल लेबल @platforms//cpu:arm है).
भाषा के हिसाब से सामान्य प्रॉपर्टी, अपनी-अपनी भाषाओं के रेपो में तय की जानी चाहिए.
डिफ़ॉल्ट प्लैटफ़ॉर्म
आम तौर पर, प्रोजेक्ट के मालिकों को साफ़ तौर पर
प्लैटफ़ॉर्म तय करने चाहिए, ताकि वे यह बता सकें कि उन्हें किस तरह की मशीनों के लिए बिल्ड करना है. इसके बाद, इन्हें --platforms के साथ ट्रिगर किया जाता है.
जब --platforms सेट नहीं किया जाता है, तो Bazel डिफ़ॉल्ट रूप से एक ऐसे platform पर सेट हो जाता है जो
स्थानीय बिल्ड मशीन को दिखाता है. यह @local_config_platform//:host पर अपने-आप जनरेट होता है. इसलिए, इसे साफ़ तौर पर तय करने की ज़रूरत नहीं होती. यह स्थानीय मशीन के OS
और CPU को constraint_values के साथ मैप करता है जिसे
@platforms में तय किया गया है.
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 के नियम, प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं (ज़्यादा जानकारी).
अगर आपको किसी नई भाषा के लिए नियम डिज़ाइन करने हैं, तो अपनी भाषा के टूलचेन चुनने के लिए, प्लैटफ़ॉर्म का इस्तेमाल करें. अच्छी जानकारी के लिए, टूलचेन का दस्तावेज़ देखें.
select()
प्रोजेक्ट, select() on
constraint_value टारगेट पर कर सकते हैं. हालांकि, पूरे
प्लैटफ़ॉर्म पर नहीं किया जा सकता. ऐसा इसलिए किया जाता है, ताकि select() ज़्यादा से ज़्यादा तरह की मशीनों के साथ काम कर सके. ARM-खास सोर्स वाली लाइब्रेरी को, ARM-पावर वाली
सभी मशीनों के साथ काम करना चाहिए. हालांकि, अगर किसी खास वजह से ऐसा नहीं किया जा सकता, तो लाइब्रेरी को ARM-पावर वाली
सभी मशीनों के साथ काम करने की ज़रूरत नहीं है.
एक या उससे ज़्यादा constraint_value पर चुनने के लिए, इसका इस्तेमाल करें:
config_setting(
name = "is_arm",
constraint_values = [
"@platforms//cpu:arm",
],
)
यह पारंपरिक तौर पर --cpu पर चुनने के बराबर है:
config_setting(
name = "is_arm",
values = {
"cpu": "arm",
},
)
ज़्यादा जानकारी के लिए यहां देखें.
selects, --cpu, --crosstool_top वगैरह, --platforms को नहीं समझते. अपने प्रोजेक्ट को प्लैटफ़ॉर्म पर माइग्रेट करते समय, आपको या तो इन्हें
constraint_values में बदलना होगा या माइग्रेशन विंडो के दौरान, दोनों स्टाइल के साथ काम करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.
ट्रांज़िशन
Starlark ट्रांज़िशन आपके बिल्ड ग्राफ़ के अलग-अलग हिस्सों में
फ़्लैग बदलते हैं. अगर आपका प्रोजेक्ट, ऐसे ट्रांज़िशन का इस्तेमाल करता है जो --cpu, --crossstool_top या अन्य लेगसी फ़्लैग सेट करता है, तो --platforms को पढ़ने वाले नियमों को ये बदलाव नहीं दिखेंगे.
अपने प्रोजेक्ट को प्लैटफ़ॉर्म पर माइग्रेट करते समय, आपको या तो बदलावों को
return { "//command_line_option:cpu": "arm" } में बदलना होगा या माइग्रेशन
window के दौरान, दोनों स्टाइल के साथ काम करने के लिए, platform
mappings का इस्तेमाल करना होगा.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.