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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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 और Baज़र पर जाएं.

Android

--incompatible_enable_android_toolchain_resolution सेट होने पर, Android के नियम टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं.

इसका मतलब है कि 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++ के मिश्रण के साथ बिल्ड करते समय.

अन्य भाषाएं

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

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

बैकग्राउंड

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

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

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

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

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

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

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

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

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

लक्ष्य

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

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 के साथ register करना होगा.

  3. select() और कॉन्फ़िगरेशन ट्रांज़िशन को सही तरीके से हल करना चाहिए. select() और ट्रांज़िशन देखें.

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

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

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

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

--platforms सेट न होने पर, Bazel डिफ़ॉल्ट रूप से platform पर सेट हो जाता है. यह 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() और कॉन्फ़िगरेशन ट्रांज़िशन, सुविधा वाले प्लैटफ़ॉर्म पर काम करते हों. यह सबसे बड़ी चुनौती है. यह कई भाषाओं में उपलब्ध प्रोजेक्ट के लिए खास तौर पर चुनौती भरा होता है. अगर सभी भाषाओं में --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 अपने-आप एक टूलचेन चुनता है. यह टूलचेन, बिल्ड मशीन पर चल सकता है और //:myplatform के लिए बाइनरी बना सकता है. इसे टूलचेन रिज़ॉल्यूशन कहा जाता है.

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

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

सवाल

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

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

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