Bazel में, प्लैटफ़ॉर्म और टूलचेन को मॉडल करने के लिए, बेहतर सुविधाएं उपलब्ध हैं. इन्हें असल प्रोजेक्ट के साथ इंटिग्रेट करने के लिए, कोड के मालिकों, नियम बनाए रखने वाले लोगों, और Bazel के मुख्य डेवलपर के बीच सावधानी से सहयोग करना ज़रूरी है.
इस पेज पर, प्लैटफ़ॉर्म के मकसद के बारे में खास जानकारी दी गई है. साथ ही, यह भी बताया गया है कि प्लैटफ़ॉर्म की मदद से कैसे बनाया जा सकता है.
tl;dr: 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"]) कर सकते हैं. साथ ही, उन मशीनों के बारे में भी बताते हैं जिन पर उनके टूल
चल सकते हैं
(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() पर
constraint_value टारगेट का इस्तेमाल कर सकते हैं. हालांकि, पूरे
प्लैटफ़ॉर्म पर इसका इस्तेमाल नहीं किया जा सकता. ऐसा इसलिए किया जाता है, ताकि select() ज़्यादा से ज़्यादा मशीनों के साथ काम कर सके. ARM-खास सोर्स वाली लाइब्रेरी को, ARM पर चलने वाली सभी मशीनों के साथ काम करना चाहिए. हालांकि, अगर किसी खास वजह से ऐसा नहीं किया जा सकता, तो अलग बात है.
एक या उससे ज़्यादा constraint_value चुनने के लिए, इसका इस्तेमाल करें:
config_setting(
name = "is_arm",
constraint_values = [
"@platforms//cpu:arm",
],
)
यह पारंपरिक तौर पर --cpu पर चुनने के बराबर है:
config_setting(
name = "is_arm",
values = {
"cpu": "arm",
},
)
ज़्यादा जानकारी के लिए यहां देखें.
select में --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.