Babel के पास मॉडलिंग के लिए बेहतरीन सहायता है मल्टी-आर्किटेक्चर और कई आर्किटेक्चर के लिए, प्लैटफ़ॉर्म और टूलचेन क्रॉस-कंपाइल्ड बिल्ड.
इस पेज पर, सहायता की स्थिति के बारे में खास जानकारी दी गई है.
यह भी देखें:
स्थिति
C++
जब C++ के नियम, टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं, तब
--incompatible_enable_cc_toolchain_resolution
सेट हो गया है.
इसका मतलब है कि C++ प्रोजेक्ट को इनके साथ कॉन्फ़िगर किया जा सकता है:
bazel build //:my_cpp_project --platforms=//:myplatform
के बजाय:
bazel build //:my_cpp_project` --cpu=... --crosstool_top=... --compiler=...
यह सुविधा Basel 7.0 (#7260) में डिफ़ॉल्ट रूप से चालू होगी.
प्लैटफ़ॉर्म के साथ अपने C++ प्रोजेक्ट की जांच करने के लिए, देखें अपने प्रोजेक्ट को माइग्रेट करना और C++ टूलचेन कॉन्फ़िगर करना.
Java
Java के नियम, टूलचेन को चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.
यह लेगसी फ़्लैग --java_toolchain
, --host_java_toolchain
की जगह लेगा,
--javabase
और --host_javabase
.
ज़्यादा जानकारी के लिए, Java और Basel की वेबसाइट देखें.
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
.
यह सुविधा, Basel 7.0 (#16285) में डिफ़ॉल्ट रूप से चालू होती है.
प्लैटफ़ॉर्म के साथ अपने Android प्रोजेक्ट की जांच करने के लिए, देखें अपने प्रोजेक्ट को माइग्रेट करना.
Apple
Apple के नियम, प्लैटफ़ॉर्म के साथ काम नहीं करते और इन्हें फ़िलहाल शेड्यूल नहीं किया गया है सहायता के लिए.
अब भी Apple बिल्ड के साथ प्लैटफ़ॉर्म एपीआई इस्तेमाल किए जा सकते हैं. उदाहरण के लिए, ऐप्लिकेशन बनाते समय जिसमें Apple के नियमों और C++ का मिला-जुला रूप इस्तेमाल किया जाएगा) और platform के साथ मैपिंग.
अन्य भाषाएं
- Go के नियम, प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं
- रस्ट के नियम, प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं.
अगर आप भाषा के नियम सेट के मालिक हैं, तो जोड़ने के लिए अपने नियम सेट का डेटा दूसरी जगह भेजना देखें सहायता.
बैकग्राउंड
सॉफ़्टवेयर का मानक तय करने के लिए, प्लैटफ़ॉर्म और टूलचेन की शुरुआत की गई अलग-अलग आर्किटेक्चर और क्रॉस-कंपाइल को टारगेट करते हैं.
यह था
प्रेरणा देने वाला
यह देखा कि भाषा की देखरेख करने वाले लोग पहले से ही
अमान्य, असंगत तरीके. उदाहरण के लिए, 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
का मौजूद होना ज़रूरी है. आम तौर पर, इसकी ज़िम्मेदारी प्रोजेक्ट के मालिक की होती है का इस्तेमाल करें, क्योंकि अलग-अलग प्रोजेक्ट अलग-अलग मशीनों को टारगेट करते हैं. डिफ़ॉल्ट प्लैटफ़ॉर्म देखें.आपको जिन टूलचेन का इस्तेमाल करना है वे मौजूद होने चाहिए. अगर स्टॉक टूलचेन का इस्तेमाल किया जा रहा है, तो भाषा के मालिकों को उन्हें रजिस्टर करने के निर्देश शामिल करने चाहिए. अगर आपने तो आपको अपने कस्टम टूलचेन में उन्हें रजिस्टर करना होगा
MODULE.bazel
फ़ाइल या--extra_toolchains
के साथ.select()
और कॉन्फ़िगरेशन ट्रांज़िशन होने चाहिए उसका ठीक से समाधान करें. select() और ट्रांज़िशन देखें.अगर आपके बिल्ड में वे भाषाएं इस्तेमाल की गई हैं जो प्लैटफ़ॉर्म पर काम करती हैं और काम नहीं करतीं, तो एपीआई की पुरानी भाषाओं को नए एपीआई के साथ काम करने में मदद करने के लिए प्लैटफ़ॉर्म मैपिंग की ज़रूरत होगी. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म की मैपिंग देखें.
अगर आपको अब भी समस्याएं आ रही हैं, तो सहायता के लिए संपर्क करें.
डिफ़ॉल्ट प्लैटफ़ॉर्म
प्रोजेक्ट के मालिकों को अश्लील कॉन्टेंट के बारे में बताना चाहिए
प्लैटफ़ॉर्म का इस्तेमाल करके आर्किटेक्चर की जानकारी देंगे
ताकि वे अपने कारोबार को आगे बढ़ा सकें. इसके बाद, ये --platforms
ट्रिगर होते हैं.
--platforms
के सेट न होने पर, Baze डिफ़ॉल्ट रूप से platform
को दिखाता है. यह
लोकल बिल्ड मशीन. यह @platforms//host
पर अपने-आप जनरेट हुआ है (इसे दूसरा नाम दिया गया है
@bazel_tools//tools:host_platform
)
इसलिए, इसे साफ़ तौर पर बताने की ज़रूरत नहीं है. यह लोकल मशीन के OS
को मैप करता है
और CPU
के साथ constraint_value
का एलान किया गया
@platforms
.
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",
},
)
ज़्यादा जानकारी के लिए यहां जाएं.
--cpu
, --crosstool_top
वगैरह पर मौजूद select
, --platforms
को समझ नहीं पाते हैं.
अपने प्रोजेक्ट को प्लैटफ़ॉर्म पर माइग्रेट करते समय, आपको उन्हें
constraint_values
या सहायता के लिए प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करें
माइग्रेशन के दौरान दोनों स्टाइल.
ट्रांज़िशन
स्टारलार्क ट्रांज़िशन में बदलाव
आपके बिल्ड ग्राफ़ के हिस्सों को फ़्लैग करता है. अगर आपके प्रोजेक्ट में किसी ऐसे ट्रांज़िशन का इस्तेमाल किया जाता है जो
--cpu
, --crossstool_top
या अन्य लेगसी फ़्लैग सेट करता है.
--platforms
को ये बदलाव नहीं दिखेंगे.
अपने प्रोजेक्ट को प्लैटफ़ॉर्म पर माइग्रेट करते समय, आपको या तो इन बदलावों को बदलना होगा
return {
"//command_line_option:platforms": "//:my_arm_platform" }
के लिए return { "//command_line_option:cpu": "arm" }
या प्लैटफ़ॉर्म का इस्तेमाल करें
मैपिंग का इस्तेमाल करें.
विंडो.
आपके नियम सेट को माइग्रेट करना
अगर आपके पास नियमों का सेट है और आपको प्लैटफ़ॉर्म का इस्तेमाल करना है, तो आपको ये काम करने होंगे:
टूलचेन एपीआई की मदद से, नियम वाले लॉजिक से टूलचेन को रिज़ॉल्व करने की सुविधा मिलती है. यहां जाएं: toolchain API (
ctx.toolchains
).ज़रूरी नहीं:
--incompatible_enable_platforms_for_my_language
फ़्लैग तय करें, ताकि नियम वाला लॉजिक, नए एपीआई या पुराने फ़्लैग के ज़रिए टूलचेन के साथ काम करता है जैसे कि--crosstool_top
.प्लैटफ़ॉर्म कॉम्पोनेंट बनाने वाली काम की प्रॉपर्टी तय करें. यहां जाएं: सामान्य प्लैटफ़ॉर्म प्रॉपर्टी
मानक टूलचेन परिभाषित करें और अपने नियम के रजिस्ट्रेशन से जुड़े निर्देश (जानकारी)
पक्का करें कि
select()
और कॉन्फ़िगरेशन ट्रांज़िशन की सुविधा वाले प्लैटफ़ॉर्म. यह है सबसे बड़ी चुनौती यह है. कई भाषाओं वाले प्रोजेक्ट के लिए यह खास तौर पर चुनौती भरा होता है (हालांकि, अगर सभी भाषाएं--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
Basel का इस्तेमाल, प्लैटफ़ॉर्म-आधारित और वे पूरे बिल्ड में लगातार इस्तेमाल किए जाते हैं. इनमें शामिल हैं ट्रांज़िशन.
डिफ़ॉल्ट रूप से Basel, आपके ब्राउज़र में मौजूद 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
, स्टारलार्क का नियम है. यह
एट्रिब्यूट किसी भाषा के टूल के बारे में बताते हैं (जैसे कि 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
के लिए बाइनरी बनाएं. इसे टूलचेन रिज़ॉल्यूशन के नाम से जाना जाता है.
उपलब्ध टूलचेन के सेट को MODULE.bazel
फ़ाइल में रजिस्टर किया जा सकता है
register_toolchains
या
कमांड लाइन, --extra_toolchains
शामिल है.
ज़्यादा जानकारी के लिए यहां देखें.
सवाल
माइग्रेशन की समयावधि के बारे में सामान्य सहायता और सवालों के लिए, यहां संपर्क करें bazz-discuss या सही नियमों के मालिकों के पास.
प्लैटफ़ॉर्म/टूलचेन एपीआई के डिज़ाइन और आगे बढ़ने पर चर्चा करने के लिए, bazel-dev से संपर्क करें.