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

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 rules, प्लैटफ़ॉर्म के साथ पूरी तरह काम करते हैं
  • Rust के नियम, प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं.

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

बैकग्राउंड

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

यह सुविधा, इस बात को ध्यान में रखकर बनाई गई है कि भाषा को बनाए रखने वाले लोग, पहले से ही इस काम को अलग-अलग तरीकों से कर रहे हैं. हालांकि, ये तरीके काम नहीं करते. उदाहरण के लिए, C++ के नियमों में टारगेट सीपीयू और टूलचेन का एलान करने के लिए, --cpu और --crosstool_top का इस्तेमाल किया जाता है. इनमें से कोई भी "प्लैटफ़ॉर्म" को सही तरीके से मॉडल नहीं करता है. इस वजह से, अजीब और गलत जवाब मिलते थे.

Java, Android, और अन्य भाषाओं ने एक जैसे कामों के लिए अपने फ़्लैग बनाए. हालांकि, इनमें से कोई भी फ़्लैग एक-दूसरे के साथ काम नहीं करता था. इस वजह से, अलग-अलग भाषाओं में बनाए गए बिल्ड को समझना मुश्किल हो जाता था.

Bazel का इस्तेमाल, कई भाषाओं और प्लैटफ़ॉर्म पर काम करने वाले बड़े प्रोजेक्ट के लिए किया जाता है. इसके लिए, इन सिद्धांतों को ज़्यादा समर्थन देने की ज़रूरत है. साथ ही, एक स्टैंडर्ड एपीआई की भी ज़रूरत है.

माइग्रेशन की ज़रूरत

नए एपीआई पर अपग्रेड करने के लिए, दो काम करने होते हैं: एपीआई को रिलीज़ करना और इसका इस्तेमाल करने के लिए, नियम के लॉजिक को अपग्रेड करना.

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

यह काम आसान है, लेकिन हर भाषा के लिए अलग से मेहनत करनी पड़ती है. साथ ही, प्रोजेक्ट के मालिकों को आने वाले बदलावों के बारे में पहले से सूचना देनी होती है, ताकि वे उनकी जांच कर सकें.

इसलिए, यह माइग्रेशन जारी है.

लक्ष्य

यह माइग्रेशन तब पूरा होता है, जब फ़ॉर्म का इस्तेमाल करके बनाए गए सभी प्रोजेक्ट:

bazel build //:myproject --platforms=//:myplatform

इसका मतलब है कि:

  1. आपके प्रोजेक्ट के नियमों के हिसाब से, //:myplatform के लिए सही टूलचेन चुने जाते हैं.
  2. आपके प्रोजेक्ट की डिपेंडेंसी, //:myplatform के लिए सही टूलचेन चुनती हैं.
  3. //:myplatform, OS, और अन्य सामान्य, भाषा से जुड़ी प्रॉपर्टी के सामान्य एलान के रेफ़रंसCPU
  4. सभी काम के select(), //:myplatform से सही तरीके से मैच होने चाहिए.
  5. //:myplatform को साफ़ तौर पर और आसानी से ऐक्सेस की जा सकने वाली जगह पर तय किया गया हो: अगर प्लैटफ़ॉर्म आपके प्रोजेक्ट के लिए यूनीक है, तो आपके प्रोजेक्ट के repo में या ऐसी सामान्य जगह पर जहां सभी प्रोजेक्ट इसे ढूंढ सकें

--cpu, --crosstool_top, और --fat_apk_cpu जैसे पुराने फ़्लैग बंद कर दिए जाएंगे और उन्हें हटा दिया जाएगा. ऐसा तब किया जाएगा, जब ऐसा करना सुरक्षित हो.

आखिरकार, आर्किटेक्चर को कॉन्फ़िगर करने का एकमात्र तरीका यही होगा.

प्रोजेक्ट माइग्रेट करना

अगर आपने प्लैटफ़ॉर्म के साथ काम करने वाली भाषाओं का इस्तेमाल किया है, तो आपका बिल्ड इस तरह के इनवोकेशन के साथ पहले से ही काम करना चाहिए:

bazel build //:myproject --platforms=//:myplatform

ज़्यादा जानकारी के लिए, स्थिति और अपनी भाषा के दस्तावेज़ देखें.

अगर किसी भाषा के लिए, प्लैटफ़ॉर्म पर सहायता पाने की सुविधा चालू करने के लिए फ़्लैग की ज़रूरत होती है, तो आपको वह फ़्लैग भी सेट करना होगा. ज़्यादा जानकारी के लिए, स्थिति देखें.

अपने प्रोजेक्ट को बनाने के लिए, आपको यह देखना होगा कि:

  1. //:myplatform मौजूद होना चाहिए. आम तौर पर, प्रोजेक्ट के मालिक की यह ज़िम्मेदारी होती है कि वह प्लैटफ़ॉर्म तय करे. ऐसा इसलिए, क्योंकि अलग-अलग प्रोजेक्ट अलग-अलग मशीनों को टारगेट करते हैं. डिफ़ॉल्ट प्लैटफ़ॉर्म देखें.

  2. आपको जिन टूलचेन का इस्तेमाल करना है वे मौजूद होने चाहिए. अगर स्टॉक टूलचेन का इस्तेमाल किया जा रहा है, तो भाषा के मालिकों को उन्हें रजिस्टर करने के तरीके के बारे में निर्देश शामिल करने चाहिए. अगर आपको अपनी कस्टम टूलचेन लिखनी हैं, तो आपको उन्हें अपनी MODULE.bazel फ़ाइल में या --extra_toolchains के साथ रजिस्टर करना होगा.

  3. select()s और configuration transitions को सही तरीके से हल किया जाना चाहिए. select() और Transitions देखें.

  4. अगर आपके बिल्ड में ऐसी भाषाओं का इस्तेमाल किया गया है जो प्लैटफ़ॉर्म के साथ काम करती हैं और ऐसी भाषाओं का भी इस्तेमाल किया गया है जो प्लैटफ़ॉर्म के साथ काम नहीं करती हैं, तो आपको प्लैटफ़ॉर्म मैपिंग की ज़रूरत पड़ सकती है. इससे लेगसी भाषाओं को नए एपीआई के साथ काम करने में मदद मिलेगी. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म मैपिंग देखें.

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

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

प्रोजेक्ट के मालिकों को प्लैटफ़ॉर्म के बारे में साफ़ तौर पर बताना चाहिए, ताकि वे उन आर्किटेक्चर के बारे में बता सकें जिनके लिए उन्हें बनाना है. इसके बाद, इन्हें की मदद से ट्रिगर किया जाता है.--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" } में बदलना होगा. इसके अलावा, माइग्रेशन के दौरान दोनों स्टाइल का इस्तेमाल करने के लिए, प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करना होगा.

नियमों के सेट को माइग्रेट करना

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

  1. टूलचेन एपीआई की मदद से, टूलचेन की समस्याओं को हल करने के लिए नियम तय करें. toolchain API (ctx.toolchains) देखें.

  2. ज़रूरी नहीं: --incompatible_enable_platforms_for_my_language फ़्लैग तय करें, ताकि माइग्रेशन टेस्टिंग के दौरान नियम का लॉजिक, नए एपीआई या पुराने फ़्लैग (जैसे कि --crosstool_top) के ज़रिए टूलचेन को बारी-बारी से हल कर सके.

  3. प्लैटफ़ॉर्म कॉम्पोनेंट बनाने वाली काम की प्रॉपर्टी तय करें. सामान्य प्लैटफ़ॉर्म प्रॉपर्टी देखें

  4. स्टैंडर्ड टूलचेन तय करें और उन्हें उपयोगकर्ताओं के लिए उपलब्ध कराएं. इसके लिए, नियम के रजिस्ट्रेशन से जुड़े निर्देशों (जानकारी) का इस्तेमाल करें

  5. पक्का करें कि 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 अपने-आप एक ऐसी टूलचेन चुनता है जो बिल्ड मशीन पर चल सकती है और $ bazel build //:myproject --platforms=//:myplatform के लिए बाइनरी बना सकती है.//:myplatform इसे टूलचेन रिज़ॉल्यूशन कहा जाता है.

उपलब्ध टूलचेन के सेट को MODULE.bazel फ़ाइल में register_toolchains की मदद से या कमांड लाइन में --extra_toolchains की मदद से रजिस्टर किया जा सकता है.

ज़्यादा जानकारी के लिए, यहां देखें.

सवाल

सामान्य सहायता पाने और माइग्रेशन की समयसीमा के बारे में सवाल पूछने के लिए, bazel-discuss या सही नियमों के मालिकों से संपर्क करें.

प्लैटफ़ॉर्म/टूलचेन एपीआई के डिज़ाइन और डेवलपमेंट के बारे में चर्चा करने के लिए, bazel-dev से संपर्क करें.

इन्हें भी देखें