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

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

--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, और अन्य भाषाओं ने इसी काम के लिए अपने-अपने फ़्लैग बनाए, इनमें से कोई भी एक-दूसरे के साथ काम नहीं करता. इससे, अलग-अलग भाषाओं में बने बिल्ड को समझना और उनका इस्तेमाल करना मुश्किल हो गया था.

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

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

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

पहला हो गया है, लेकिन दूसरा जारी है. इसमें यह पक्का करना शामिल है कि भाषा के हिसाब से प्लैटफ़ॉर्म और टूलचेन तय किए गए हों, भाषा लॉजिक --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 से संपर्क करें.

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

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