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

समस्या की शिकायत करें सोर्स देखें

बेज़ल, एक से ज़्यादा आर्किटेक्चर और क्रॉस-कंपाइल्ड बिल्ड के लिए, मॉडलिंग प्लैटफ़ॉर्म और टूलचेन के लिए बेहतरीन काम करता है.

इस पेज पर, सहायता की स्थिति के बारे में खास जानकारी दी गई है.

यह भी देखें:

स्थिति

C++

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

इसका मतलब है कि C++ प्रोजेक्ट को इनके साथ कॉन्फ़िगर किया जा सकता है:

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

के बजाय:

bazel build //:my_cpp_project` --cpu=... --crosstool_top=...  --compiler=...

यह सुविधा Basel 7.0 (#7260) में डिफ़ॉल्ट रूप से चालू होगी.

प्लैटफ़ॉर्म के साथ अपने C++ प्रोजेक्ट की जांच करने के लिए, अपने प्रोजेक्ट को माइग्रेट करना और C++ टूलचेन को कॉन्फ़िगर करना लेख पढ़ें.

Java

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

यह लेगसी फ़्लैग --java_toolchain, --host_java_toolchain, --javabase, और --host_javabase की जगह ले लेगा.

ज़्यादा जानकारी के लिए, Java और Basel की वेबसाइट देखें.

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. आपको जिन टूलचेन का इस्तेमाल करना है वे मौजूद होने चाहिए. अगर स्टॉक टूलचेन का इस्तेमाल किया जा रहा है, तो भाषा के मालिकों को उन्हें रजिस्टर करने के निर्देश शामिल करने चाहिए. अगर आप अपने कस्टम टूलचेन लिख रहे हैं, तो आपको उन्हें अपने WORKSPACE या --extra_toolchains की मदद से register होगा.

  3. select() और कॉन्फ़िगरेशन ट्रांज़िशन से जुड़ी समस्या, ठीक से काम करनी चाहिए. select() और ट्रांज़िशन देखें.

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

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

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

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

जब --platforms को सेट नहीं किया जाता है, तो Baze डिफ़ॉल्ट रूप से लोकल बिल्ड मशीन के बारे में बताने वाली platform वैल्यू चुन लेता है. यह @local_config_platform//:host पर अपने-आप जनरेट होता है, इसलिए, इसे साफ़ तौर पर तय करने की ज़रूरत नहीं है. यह स्थानीय मशीन के 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

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

डिफ़ॉल्ट रूप से, Basel आपके फ़ाइल फ़ोल्डर के रूट में 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, स्टारलार्क का नियम है. इसके एट्रिब्यूट किसी भाषा के टूल के बारे में बताते हैं (जैसे कि compiler = "//mytoolchain:custom_gcc"). इसके सेवा देने वाले, यह जानकारी उन नियमों को भेजते हैं जो इन टूल की मदद से बनाए जाने चाहिए.

टूलचेन से पता चलता है कि constraint_value मशीनों को वे टारगेट (target_compatible_with = ["@platforms//os:linux"]) कर सकते हैं और उन मशीनों के बारे में जानकारी दे सकते हैं जिन्हें उनके टूल इस्तेमाल कर सकते हैं (exec_compatible_with = ["@platforms//os:mac"]).

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

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

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

सवाल

माइग्रेशन की समयावधि के बारे में सामान्य मदद और सवालों के जवाब पाने के लिए, baaz-discuss या ज़रूरी नियमों के मालिकों से संपर्क करें.

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

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