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

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_settings पुराने फ़्लैग के बजाय नए एपीआई पर चुने जाते हों.

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

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

लक्ष्य

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  3. select() और कॉन्फ़िगरेशन ट्रांज़िशन से जुड़ी समस्याएं ठीक से हल होनी चाहिए. 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"]) कर सकती हैं. साथ ही, उन मशीनों के constraint_value तय करती हैं जिन पर उनके टूल चल सकते हैं (exec_compatible_with = ["@platforms//os:mac"]).

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

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

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

सवाल

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

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

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