Basel के पास, मल्टी-आर्किटेक्चर और क्रॉस-कंपाइल्ड बिल्ड के लिए, मॉडलिंग प्लैटफ़ॉर्म और टूलचैन के लिए बेहतरीन सहायता है.
इस पेज पर, सहायता की स्थिति के बारे में खास जानकारी दी गई है.
यह भी देखें:
स्थिति
C++
--incompatible_enable_cc_toolchain_resolution सेट होने पर C++ के नियम, टूलचेन को चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
इसका मतलब है कि C++ प्रोजेक्ट को इनके साथ कॉन्फ़िगर किया जा सकता है:
bazel build //:my_cpp_project --platforms=//:myplatformके बजाय:
bazel build //:my_cpp_project` --cpu=... --crosstool_top=... --compiler=...यह सुविधा, Bazel 7.0 (#7260) में डिफ़ॉल्ट रूप से चालू होगी.
प्लैटफ़ॉर्म पर अपने C++ प्रोजेक्ट की जांच करने के लिए, अपने प्रोजेक्ट को माइग्रेट करना और C++ टूलचेन को कॉन्फ़िगर करना लेख पढ़ें.
Java
Java के नियम, टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
यह लेगसी फ़्लैग --java_toolchain, --host_java_toolchain,
--javabase, और --host_javabase की जगह लेता है.
ज़्यादा जानकारी के लिए, Java और Bazel देखें.
Android
--incompatible_enable_android_toolchain_resolution सेट होने पर, Android के नियम टूलचेन को चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
इसका मतलब है कि Android प्रोजेक्ट को इनके साथ कॉन्फ़िगर किया जा सकता है:
bazel build //:my_android_project --android_platforms=//:my_android_platformका इस्तेमाल करें.--android_crosstool_top--android_cpu--fat_apk_cpu
यह सुविधा, Bazel 7.0 (#16285) में डिफ़ॉल्ट रूप से चालू होगी.
प्लैटफ़ॉर्म पर अपने Android प्रोजेक्ट की जांच करने के लिए, अपने प्रोजेक्ट को माइग्रेट करना लेख पढ़ें.
Apple
Apple के नियम किसी प्लैटफ़ॉर्म पर काम नहीं करते और न ही इन्हें सहायता के लिए शेड्यूल किया गया है.
प्लैटफ़ॉर्म मैपिंग की मदद से, अब भी Apple के बिल्ड के साथ प्लैटफ़ॉर्म एपीआई का इस्तेमाल किया जा सकता है. उदाहरण के लिए, Apple के नियमों और प्योर C++ के मिश्रण के साथ बिल्ड करते समय.
अन्य भाषाएं
- Go के नियम, प्लैटफ़ॉर्म के साथ पूरी तरह काम करते हैं
- Rust के नियम, प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं.
अगर आपके पास भाषा के नियम के सेट का मालिकाना हक है, तो सहायता जोड़ने के लिए अपने नियम के सेट को माइग्रेट करना लेख देखें.
बैकग्राउंड
प्लैटफ़ॉर्म और टूलचेन की शुरुआत यह तय करने के लिए की गई थी कि सॉफ़्टवेयर प्रोजेक्ट अलग-अलग आर्किटेक्चर और क्रॉस-कंपाइल को कैसे टारगेट करते हैं.
भाषा के रखरखाव करने वाले लोग, पहले से ही इस काम को अलग-अलग तरीकों से कर रहे थे. हालांकि, ये तरीके एक-दूसरे के साथ काम नहीं करते थे. इस बात से हमें प्रेरण मिली कि इस काम को एक ही तरीके से किया जा सकता है. उदाहरण के लिए, C++ नियमों में टारगेट सीपीयू और टूलचेन का एलान करने के लिए, --cpu और
--crosstool_top का इस्तेमाल किया गया. इनमें से कोई भी, "प्लैटफ़ॉर्म" को सही तरीके से मॉडल नहीं करता. इससे अजीब और गलत बिल्ड बनते हैं.
Java, Android, और अन्य भाषाओं ने इसी काम के लिए अपने-अपने फ़्लैग बनाए, इनमें से कोई भी एक-दूसरे के साथ काम नहीं करता. इससे दूसरी भाषा का इस्तेमाल करना मुश्किल और मुश्किल हो गया.
Basel को बड़े, कई भाषाओं वाले, और कई प्लैटफ़ॉर्म पर काम करने वाले प्रोजेक्ट के लिए बनाया गया है. इसकी वजह से, इन सिद्धांतों के लिए ज़्यादा सैद्धांतिक मदद चाहिए होती है. इसमें एक साफ़ स्टैंडर्ड एपीआई भी शामिल है.
माइग्रेशन की ज़रूरत
नए एपीआई पर अपग्रेड करने के लिए, दो काम करने होंगे: एपीआई को रिलीज़ करना और उसका इस्तेमाल करने के लिए, नियम के लॉजिक को अपग्रेड करना.
पहला चरण पूरा हो गया है, लेकिन दूसरा चरण जारी है. इसमें यह पक्का करना शामिल है कि भाषा के हिसाब से प्लैटफ़ॉर्म और टूलचेन तय किए गए हों, भाषा लॉजिक --crosstool_top जैसे पुराने फ़्लैग के बजाय नए एपीआई के ज़रिए टूलचेन पढ़ता हो, और config_setting पुराने फ़्लैग के बजाय नए एपीआई पर चुने जाते हों.
यह काम आसान है, लेकिन इसके लिए हर भाषा में अलग से कोशिश करने की ज़रूरत होती है. साथ ही, प्रोजेक्ट के मालिकों को फ़ेयर चेतावनी मिलेगी, ताकि यह पता लगाया जा सके कि वे आगे क्या होने वाले हैं.
इसलिए, यह माइग्रेशन जारी है.
लक्ष्य
यह माइग्रेशन तब पूरा हो जाता है, जब फ़ॉर्म की मदद से सभी प्रोजेक्ट बनाए जाते हैं:
bazel build //:myproject --platforms=//:myplatformइसका मतलब है कि:
- आपके प्रोजेक्ट के नियम,
//:myplatformके लिए सही टूलचेन चुनते हैं. - आपके प्रोजेक्ट की डिपेंडेंसी,
//:myplatformके लिए सही टूलचेन चुनती हैं. //:myplatform,CPU,OS, और भाषा पर निर्भर न करने वाली अन्य सामान्य प्रॉपर्टी के सामान्य एलान का रेफ़रंस देता है- काम के सभी
select(),//:myplatformसे सही तरीके से मैच करते हैं. //:myplatformको एक ऐसी जगह पर बनाया गया है जहां आसानी से पहुंचा जा सके: आपके प्रोजेक्ट के रेपो में, अगर प्रोजेक्ट आपके प्रोजेक्ट के लिए खास है या कोई ऐसी जगह है जहां सभी प्रोजेक्ट पर काम करते हैं
--cpu, --crosstool_top, और --fat_apk_cpu जैसे पुराने फ़्लैग हटा दिए जाएंगे और सुरक्षित होते ही उन्हें हटा दिया जाएगा.
कुल मिलाकर, आर्किटेक्चर को कॉन्फ़िगर करने का यह एकमात्र तरीका होगा.
आपके प्रोजेक्ट को माइग्रेट किया जा रहा है
अगर आपने प्लैटफ़ॉर्म के साथ काम करने वाली भाषाओं में बिल्ड किया है, तो आपका बिल्ड पहले से ही इनवोकेशन के साथ काम करना चाहिए:
bazel build //:myproject --platforms=//:myplatformसटीक जानकारी के लिए, स्टेटस और अपनी भाषा का दस्तावेज़ देखें.
अगर किसी भाषा के लिए, प्लैटफ़ॉर्म से जुड़ी सहायता चालू करने के लिए फ़्लैग की ज़रूरत है, तो आपको वह फ़्लैग भी सेट करना होगा. ज़्यादा जानकारी के लिए, स्थिति देखें.
प्रोजेक्ट बनाने के लिए, आपको इन बातों की जांच करनी होगी:
//:myplatformका मौजूद होना ज़रूरी है. आम तौर पर, प्लैटफ़ॉर्म तय करना प्रोजेक्ट के मालिक की ज़िम्मेदारी होती है, क्योंकि अलग-अलग प्रोजेक्ट अलग-अलग मशीनों को टारगेट करते हैं. डिफ़ॉल्ट प्लैटफ़ॉर्म देखें.जिन टूलचेन का इस्तेमाल करना है वे मौजूद होने चाहिए. स्टॉक टूलचेन का इस्तेमाल करने पर, भाषा के मालिकों को उन्हें रजिस्टर करने का तरीका बताना चाहिए. अगर आपको अपनी पसंद के मुताबिक टूलचेन लिखने हैं, तो आपको उन्हें अपने
WORKSPACEया--extra_toolchainsमें register करना होगा.select()और कॉन्फ़िगरेशन ट्रांज़िशन को सही तरीके से हल करना चाहिए. select() और ट्रांज़िशन देखें.अगर आपके बिल्ड में ऐसी भाषाएं शामिल हैं जो प्लैटफ़ॉर्म के साथ काम करती हैं और नहीं करती हैं, तो आपको प्लैटफ़ॉर्म मैपिंग की ज़रूरत पड़ सकती है. इससे, पुरानी भाषाओं को नए एपीआई के साथ काम करने में मदद मिलेगी. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म मैपिंग देखें.
अगर आपको अब भी समस्याएं आ रही हैं, तो मदद पाने के लिए हमसे संपर्क करें.
डिफ़ॉल्ट प्लैटफ़ॉर्म
प्रोजेक्ट के मालिकों को उन प्लैटफ़ॉर्म के बारे में साफ़ तौर पर बताना चाहिए जिनके लिए उन्हें आर्किटेक्चर बनाना है. इसके बाद, ये --platforms ट्रिगर होते हैं.
--platforms सेट न होने पर, Bazel डिफ़ॉल्ट रूप से platform पर सेट हो जाता है. यह platform, लोकल बिल्ड मशीन को दिखाता है. यह @local_config_platform//:host पर अपने-आप जनरेट होता है. इसलिए, इसे साफ़ तौर पर बताने की ज़रूरत नहीं है. यह स्थानीय मशीन के OS और CPU को @platforms में बताए गए constraint_value से मैप करता है.
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" } में बदलना होगा. इसके अलावा, माइग्रेशन के दौरान दोनों स्टाइल के साथ काम करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल किया जा सकता है.
आपके नियम सेट को माइग्रेट करना
अगर आपके पास नियमों का सेट है और आपको प्लैटफ़ॉर्म का इस्तेमाल करना है, तो आपको ये काम करने होंगे:
नियम के लॉजिक में, टूलचेन एपीआई की मदद से टूलचेन को हल करें. टूलचेन एपीआई (
ctx.toolchains) देखें.ज़रूरी नहीं:
--incompatible_enable_platforms_for_my_languageफ़्लैग तय करें, ताकि माइग्रेशन टेस्टिंग के दौरान, नियम लॉजिक, नए एपीआई या--crosstool_topजैसे पुराने फ़्लैग के ज़रिए टूलचेन को बारी-बारी से हल कर सके.प्लैटफ़ॉर्म कॉम्पोनेंट बनाने वाली काम की प्रॉपर्टी तय करें. सामान्य प्लैटफ़ॉर्म प्रॉपर्टी देखें
स्टैंडर्ड टूलचेन परिभाषित करें और अपने नियम के रजिस्ट्रेशन निर्देशों के ज़रिए, उपयोगकर्ताओं के लिए उन्हें ऐक्सेस करें (जानकारी)
पक्का करें कि
select()और कॉन्फ़िगरेशन ट्रांज़िशन, प्लैटफ़ॉर्म के साथ काम करते हों. यह सबसे बड़ी चुनौती है. यह कई भाषाओं वाले प्रोजेक्ट के लिए खास तौर पर चुनौती भरा होता है. ऐसा तब हो सकता है, जब सभी भाषाएं--platformsको न पढ़ पाएं.
अगर आपको ऐसे नियमों का एक साथ इस्तेमाल करना है जो प्लैटफ़ॉर्म के साथ काम नहीं करते, तो इस अंतर को कम करने के लिए आपको प्लैटफ़ॉर्म मैपिंग की ज़रूरत पड़ सकती है.
प्लैटफ़ॉर्म की सामान्य प्रॉपर्टी
OS और CPU जैसी सामान्य, अलग-अलग भाषाओं के प्लैटफ़ॉर्म प्रॉपर्टी, @platforms में बताई जानी चाहिए.
इससे, डेटा शेयर करने, उसे स्टैंडर्ड बनाने, और अलग-अलग भाषाओं के साथ काम करने में मदद मिलती है.
आपके नियमों की यूनीक प्रॉपर्टी, आपके नियम के रेपो में शामिल होनी चाहिए. इससे, उन खास कॉन्सेप्ट पर मालिकाना हक बनाए रखने में मदद मिलती है जिनके लिए आपके नियम लागू होते हैं.
अगर आपके नियमों में, खास काम के लिए बनाए गए ओएस या सीपीयू का इस्तेमाल किया जाता है, तो इनका एलान आपके नियम के रिपॉज़िटरी बनाम @platforms में किया जाना चाहिए.
प्लैटफ़ॉर्म मैपिंग
प्लैटफ़ॉर्म मैपिंग एक ऐसा एपीआई है जो प्लैटफ़ॉर्म के हिसाब से काम करने वाले लॉजिक को एक ही बिल्ड में लेगसी लॉजिक के साथ मिक्स करने की सुविधा देता है. यह एक ऐसा टूल है जिसका मकसद, माइग्रेशन के अलग-अलग समयसीमाओं के साथ काम करने में आने वाली समस्याओं को हल करना है.
प्लैटफ़ॉर्म मैपिंग, 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_x86_64 --apple_platform_type=macos" to "//platform:macos".
--cpu=darwin_x86_64
--apple_platform_type=macos
//platforms:macos
Bazel इसका इस्तेमाल यह पक्का करने के लिए करता है कि प्लैटफ़ॉर्म पर आधारित और लेगसी, दोनों सेटिंग पूरे बिल्ड में लगातार लागू हों. इनमें ट्रांज़िशन भी शामिल हैं.
डिफ़ॉल्ट रूप से, Bazel आपके वर्कस्पेस रूट में मौजूद platform_mappings फ़ाइल से मैपिंग पढ़ता है. --platform_mappings=//:my_custom_mapping को भी सेट किया जा सकता है.
ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म मैपिंग का डिज़ाइन देखें.
एपीआई की समीक्षा
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-discuss या सही नियमों के मालिकों से संपर्क करें.
प्लैटफ़ॉर्म/टूलचेन एपीआई के डिज़ाइन और विकास के बारे में चर्चा करने के लिए, bazel-dev से संपर्क करें.