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

किसी समस्या की शिकायत करें सोर्स देखें 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=...

यह सुविधा Basel 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 के नियम, प्लैटफ़ॉर्म के साथ पूरी तरह काम करते हैं
  • Rust के नियम, प्लैटफ़ॉर्म के साथ पूरी तरह से काम करते हैं.

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

बैकग्राउंड

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

भाषा के रखरखाव करने वाले लोग, पहले से ही इस काम को अलग-अलग तरीकों से कर रहे थे. हालांकि, ये तरीके एक-दूसरे के साथ काम नहीं करते थे. इस बात से हमें प्रेरण मिली कि इस काम को एक ही तरीके से किया जा सकता है. उदाहरण के लिए, 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 में रजिस्टर करना होगा.

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

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

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

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

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

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

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:platforms": "//:my_arm_platform" } के लिए return { "//command_line_option:cpu": "arm" } या प्लैटफ़ॉर्म का इस्तेमाल करें मैपिंग का इस्तेमाल करें. विंडो.

आपके नियम सेट को माइग्रेट करना

अगर आपके पास नियमों का सेट है और आपको प्लैटफ़ॉर्म का इस्तेमाल करना है, तो आपको ये काम करने होंगे:

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

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

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

सवाल

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

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

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