Bazel में, मल्टी-आर्किटेक्चर और क्रॉस-कंपाइल किए गए बिल्ड के लिए, प्लैटफ़ॉर्म और टूलचेन को मॉडल बनाने की बेहतर सुविधा उपलब्ध है.
इस पेज पर, इस सुविधा की स्थिति के बारे में खास जानकारी दी गई है.
यह भी देखें:
स्थिति
C++
C++ के नियम, --incompatible_enable_cc_toolchain_resolution सेट होने पर टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
इसका मतलब है कि 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
Android के नियम, --incompatible_enable_android_toolchain_resolution सेट होने पर टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
इसका मतलब है कि 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, और अन्य भाषाओं ने एक जैसे मकसद के लिए अपने फ़्लैग बनाए. हालांकि, इनमें से कोई भी फ़्लैग एक-दूसरे के साथ काम नहीं करता था. इस वजह से, अलग-अलग भाषाओं में बनाए गए बिल्ड को समझना मुश्किल हो जाता था.
Bazel का इस्तेमाल, कई भाषाओं और प्लैटफ़ॉर्म पर काम करने वाले बड़े प्रोजेक्ट के लिए किया जाता है. इसके लिए, इन सिद्धांतों को ज़्यादा समर्थन देने की ज़रूरत है. साथ ही, एक स्टैंडर्ड एपीआई की भी ज़रूरत है.
माइग्रेशन की ज़रूरत
नए एपीआई पर अपग्रेड करने के लिए, दो काम करने होते हैं: एपीआई रिलीज़ करना और उसका इस्तेमाल करने के लिए, नियम के लॉजिक को अपग्रेड करना.
पहली प्रोसेस पूरी हो गई है, लेकिन दूसरी प्रोसेस जारी है. इसमें यह पक्का करना शामिल है कि भाषा के हिसाब से प्लैटफ़ॉर्म और टूलचेन तय किए गए हों, भाषा की लॉजिक टूलचेन, --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मौजूद होना चाहिए. आम तौर पर, प्लैटफ़ॉर्म तय करने की ज़िम्मेदारी प्रोजेक्ट के मालिक की होती है, क्योंकि अलग-अलग प्रोजेक्ट अलग-अलग मशीनों को टारगेट करते हैं. डिफ़ॉल्ट प्लैटफ़ॉर्म देखें.आपको जिन टूलचेन का इस्तेमाल करना है वे मौजूद होनी चाहिए. अगर स्टॉक टूलचेन का इस्तेमाल किया जा रहा है, तो भाषा के मालिकों को उन्हें रजिस्टर करने के तरीके के बारे में निर्देश शामिल करने चाहिए. अगर आपको अपनी कस्टम टूलचेन लिखनी हैं, तो आपको उन्हें अपनी
MODULE.bazelफ़ाइल में या--extra_toolchainsके साथ रजिस्टर करना होगा.select()और कॉन्फ़िगरेशन ट्रांज़िशन से जुड़ी समस्याएं ठीक से हल होनी चाहिए. select() और Transitions देखें.अगर आपकी बिल्ड में ऐसी भाषाओं का इस्तेमाल किया गया है जो प्लैटफ़ॉर्म के साथ काम करती हैं और ऐसी भाषाओं का भी इस्तेमाल किया गया है जो प्लैटफ़ॉर्म के साथ काम नहीं करती हैं, तो आपको प्लैटफ़ॉर्म मैपिंग की ज़रूरत पड़ सकती है. इससे लेगसी भाषाओं को नए एपीआई के साथ काम करने में मदद मिलेगी. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म मैपिंग देखें.
अगर आपको अब भी समस्याएं आ रही हैं, तो सहायता पाने के लिए संपर्क करें.
डिफ़ॉल्ट प्लैटफ़ॉर्म
प्रोजेक्ट के मालिकों को प्लैटफ़ॉर्म के बारे में साफ़ तौर पर बताना चाहिए, ताकि वे उन आर्किटेक्चर के बारे में बता सकें जिनके लिए उन्हें ऐप्लिकेशन बनाना है. इसके बाद, इन्हें --platforms की मदद से ट्रिगर किया जाता है.
--platforms सेट न होने पर, Bazel डिफ़ॉल्ट रूप से platform को चुनता है. यह लोकल बिल्ड मशीन को दिखाता है. यह @platforms//host (इसे @bazel_tools//tools:host_platform के तौर पर भी जाना जाता है) पर अपने-आप जनरेट होता है. इसलिए, इसे साफ़ तौर पर तय करने की ज़रूरत नहीं होती. यह लोकल मशीन के 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" } में बदलना होगा. इसके अलावा, माइग्रेशन के दौरान दोनों स्टाइल को सपोर्ट करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.
नियमों के सेट को माइग्रेट करना
अगर आपके पास नियमों का सेट है और आपको प्लैटफ़ॉर्म के लिए सहायता चाहिए, तो आपको ये काम करने होंगे:
toolchain API की मदद से, टूलचेन से जुड़ी समस्याओं को हल करने के लिए नियम तय करें. toolchain API (
ctx.toolchains) देखें.ज़रूरी नहीं:
--incompatible_enable_platforms_for_my_languageफ़्लैग तय करें, ताकि माइग्रेशन टेस्टिंग के दौरान नियम का लॉजिक, नए एपीआई या--crosstool_topजैसे पुराने फ़्लैग के ज़रिए टूलचेन को बारी-बारी से हल कर सके.प्लैटफ़ॉर्म कॉम्पोनेंट बनाने वाली काम की प्रॉपर्टी तय करें. सामान्य प्लैटफ़ॉर्म प्रॉपर्टी देखें
स्टैंडर्ड टूलचेन तय करें और उन्हें उपयोगकर्ताओं के लिए उपलब्ध कराएं. इसके लिए, अपने नियम के रजिस्ट्रेशन निर्देशों (जानकारी) का इस्तेमाल करें
पक्का करें कि
select()s और कॉन्फ़िगरेशन ट्रांज़िशन के साथ काम करने वाले प्लैटफ़ॉर्म इस्तेमाल किए जा रहे हों. यह सबसे बड़ी चुनौती है. यह सुविधा, एक से ज़्यादा भाषाओं वाले प्रोजेक्ट के लिए खास तौर पर मुश्किल है. ऐसा इसलिए, क्योंकि अगर सभी भाषाओं में--platformsको नहीं पढ़ा जा सकता, तो हो सकता है कि प्रोजेक्ट पूरा न हो पाए.
अगर आपको ऐसे नियमों के साथ मिक्स करना है जो प्लैटफ़ॉर्म के साथ काम नहीं करते हैं, तो आपको अंतर को कम करने के लिए प्लैटफ़ॉर्म मैपिंग की ज़रूरत पड़ सकती है.
सामान्य प्लैटफ़ॉर्म प्रॉपर्टी
OS और CPU जैसी, अलग-अलग भाषाओं में इस्तेमाल होने वाली प्लैटफ़ॉर्म प्रॉपर्टी को @platforms में एलान किया जाना चाहिए.
इससे शेयर करने, स्टैंडर्ड तय करने, और अलग-अलग भाषाओं के साथ काम करने की सुविधा को बढ़ावा मिलता है.
आपके नियमों के लिए यूनीक प्रॉपर्टी, आपके नियम के रेपो में घोषित की जानी चाहिए. इससे आपको उन खास कॉन्सेप्ट पर साफ़ तौर पर मालिकाना हक बनाए रखने में मदद मिलती है जिनके लिए आपके नियम ज़िम्मेदार हैं.
अगर आपके नियमों में कस्टम-पर्पज़ ओएस या सीपीयू का इस्तेमाल किया जाता है, तो इन्हें आपके नियम के रेपो में @platforms के बजाय घोषित किया जाना चाहिए.
प्लैटफ़ॉर्म मैपिंग
प्लैटफ़ॉर्म मैपिंग एक अस्थायी एपीआई है. इसकी मदद से, प्लैटफ़ॉर्म के बारे में जानकारी देने वाले लॉजिक को एक ही बिल्ड में लेगसी लॉजिक के साथ मिक्स किया जा सकता है. यह एक ऐसा टूल है जो सिर्फ़ माइग्रेशन की अलग-अलग समयावधियों के साथ होने वाली समस्याओं को ठीक करने के लिए बनाया गया है.
प्लैटफ़ॉर्म मैपिंग, platform() को लेगसी फ़्लैग के मिलते-जुलते सेट या इसके उलट मैप करने की सुविधा है. उदाहरण के लिए:
platforms:
# Maps "--platforms=//platforms:ios" to "--ios_multi_cpus=x86_64 --apple_platform_type=ios".
//platforms:ios
--ios_multi_cpus=x86_64
--apple_platform_type=ios
flags:
# Maps "--ios_multi_cpus=x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
--ios_multi_cpus=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 के लिए बाइनरी बिल्ड कर सकती है. इसे टूलचेन रिज़ॉल्यूशन कहा जाता है.
उपलब्ध टूलचेन के सेट को MODULE.bazel फ़ाइल में register_toolchains के साथ या कमांड लाइन में --extra_toolchains के साथ रजिस्टर किया जा सकता है.
ज़्यादा जानकारी के लिए, यहां देखें.
सवाल
सामान्य सहायता पाने और माइग्रेशन की समयसीमा के बारे में सवाल पूछने के लिए, bazel-discuss या सही नियमों के मालिकों से संपर्क करें.
प्लैटफ़ॉर्म/टूलचेन एपीआई के डिज़ाइन और डेवलपमेंट के बारे में चर्चा करने के लिए, bazel-dev से संपर्क करें.