रिलीज़ होने वाले किसी भी वर्शन की जानकारी देने वाले दस्तावेज़ के लिए, कृपया "वर्शन दस्तावेज़" ड्रॉप-डाउन का इस्तेमाल करें. डिफ़ॉल्ट व्यू, head पर सबसे नए वर्शन को दिखाता है.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

प्लैटफ़ॉर्म पर माइग्रेट करना

समस्या की शिकायत करें स्रोत देखें

Bazel के पास, कई तरह के आर्किटेक्चर और क्रॉस-कंपाइल्ड बिल्ड के लिए, प्लैटफ़ॉर्म और टूलचेन की मॉडलिंग के लिए, बेहतर सहायता है.

इस पेज पर, सहायता की स्थिति के बारे में खास जानकारी दी गई है.

यह भी देखें:

स्थिति

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

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 के नियमों और शुद्ध C++ के संयोजन के साथ प्लैटफ़ॉर्म मैपिंग के साथ प्लैटफ़ॉर्म एपीआई इस्तेमाल करते समय.

अन्य भाषाएं

Go के नियम प्लैटफ़ॉर्म के साथ पूरी तरह काम करते हैं
रस्ट के नियम, प्लैटफ़ॉर्म के मुताबिक काम करते हैं.

अगर आप भाषा के नियम सेट के मालिक हैं, तो सहायता जोड़ने के लिए अपने नियम सेट को माइग्रेट करना देखें.

बैकग्राउंड

सॉफ़्टवेयर प्रोजेक्ट, अलग-अलग आर्किटेक्चर और क्रॉस-कंपाइल को कैसे टारगेट करते हैं, यह तय करने के लिए प्लैटफ़ॉर्म और टूलचेन की शुरुआत की गई.

यह इस बात से प्रेरित था कि भाषा का रखरखाव करने वाले लोग पहले से ही, खास तरह से और काम न करने वाले तरीकों से ऐसा कर रहे थे. उदाहरण के लिए, 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 में register होगा.
select() और कॉन्फ़िगरेशन ट्रांज़िशन को ठीक से हल करना ज़रूरी है. select() और ट्रांज़िशन देखें.
अगर आपके बिल्ड में ऐसी भाषाएं मिक्स की गई हैं जो प्लैटफ़ॉर्म के साथ काम करती हैं और नहीं भी, तो हो सकता है कि आपको प्लैटफ़ॉर्म मैपिंग की ज़रूरत हो, ताकि लेगसी भाषाएं, नए एपीआई के साथ काम कर सकें. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म मैपिंग देखें.

अगर आपको अब भी समस्याएं आ रही हैं, तो सहायता के लिए संपर्क करें.

डिफ़ॉल्ट प्लैटफ़ॉर्म

प्रोजेक्ट के मालिकों को ऐसे प्लैटफ़ॉर्म के बारे में साफ़ तौर पर बताना चाहिए जिनके लिए वे इसे बनाना चाहते हैं. इसके बाद, ये --platforms से ट्रिगर होंगे.

अगर --platforms को सेट नहीं किया जाता है, तो Bazel डिफ़ॉल्ट रूप से platform दिखाता है. यह लोकल बिल्ड मशीन दिखाता है. यह @platforms//host पर अपने-आप जनरेट होता है (इसे @bazel_tools//tools:host_platform के तौर पर कहा जाता है) इसलिए, इसे साफ़ तौर पर बताने की ज़रूरत नहीं होती. यह स्थानीय मशीन के OS और CPU को मैप करता है, जिनमें constraint_value का एलान @platforms में किया गया है.

`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 में बदलना होगा या माइग्रेशन के दौरान दोनों स्टाइल के साथ काम करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.

ट्रांज़िशन

स्टारलार्क ट्रांज़िशन, आपके बिल्ड ग्राफ़ के हिस्सों को फ़्लैग करता है. अगर आपका प्रोजेक्ट ऐसे ट्रांज़िशन का इस्तेमाल करता है जो --cpu, --crossstool_top या अन्य लेगसी फ़्लैग सेट करता है, तो --platforms पढ़ने वाले नियमों को ये बदलाव नहीं दिखेंगे.

अपने प्रोजेक्ट को प्लैटफ़ॉर्म पर माइग्रेट करते समय, आपको return { "//command_line_option:cpu": "arm" } जैसे बदलावों को return { "//command_line_option:platforms": "//:my_arm_platform" } में बदलना होगा. इसके अलावा, माइग्रेशन के दौरान दोनों स्टाइल के साथ काम करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा. window.

आपके नियम सेट को माइग्रेट किया जा रहा है

अगर आपके पास किसी नियम का सेट है और आपको प्लैटफ़ॉर्म का इस्तेमाल करना है, तो आपको:

टूलचेन एपीआई की मदद से, नियम लॉजिक को टूलचेन में ठीक करें. 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

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 स्टारलार्क नियम होता है. इसकी विशेषताएं किसी भाषा के टूल (जैसे 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 से संपर्क करें.