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

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

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

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

लक्ष्य

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

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

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

1. आपके प्रोजेक्ट के नियमों के हिसाब से, //:myplatform के लिए सही टूलचेन चुने जाते हैं.
2. आपके प्रोजेक्ट की डिपेंडेंसी, //:myplatform के लिए सही टूलचेन चुनती हैं.
3. //:myplatform के सामान्य एलान के CPU, OS, और अन्य सामान्य, भाषा से जुड़ी प्रॉपर्टी के रेफ़रंस
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() और कॉन्फ़िगरेशन ट्रांज़िशन से जुड़ी समस्याएं ठीक से हल होनी चाहिए. select() और Transitions देखें.

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

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

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

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

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

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

ट्रांज़िशन

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 "--cpu=ios_x86_64 --apple_platform_type=ios".
  //platforms:ios
    --cpu=ios_x86_64
    --apple_platform_type=ios

flags:
  # Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
  --cpu=ios_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 से संपर्क करें.

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

• कॉन्फ़िगर किए जा सकने वाले बिल्ड - पार्ट 1
• प्लैटफ़ॉर्म
• टूलचेन
• Bazel Platforms Cookbook
• प्लैटफ़ॉर्म के उदाहरण
• C++ टूलचेन का उदाहरण