प्लैटफ़ॉर्म और टूलचेन नियम

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

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

नियम

• पाबंदी_सेटिंग
• आंकड़ों की सीमा
• प्लैटफ़ॉर्म
• टूलचेन
• Toolchain_type

कंस्ट्रेंट_सेटिंग

नियम का सोर्स देखेंopen_in_new

constraint_setting(name, default_constraint_value, deprecation, distribs, features, licenses, tags, testonly, visibility)

इस नियम का इस्तेमाल उस नए कंस्ट्रेंट टाइप को शुरू करने के लिए किया जाता है जिसके लिए प्लैटफ़ॉर्म, वैल्यू तय कर सकता है. उदाहरण के लिए, आप "glibc_version" नाम का कोई constraint_setting तय कर सकते हैं, ताकि प्लैटफ़ॉर्म पर glibc लाइब्रेरी के अलग-अलग वर्शन इंस्टॉल किए जा सकें. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पेज देखें.

हर constraint_setting में, उससे जुड़े constraint_value का बहुत बड़ा सेट होता है. आम तौर पर, ये पैकेज एक ही होते हैं, लेकिन कभी-कभी किसी दूसरे पैकेज में मौजूदा सेटिंग के लिए नई वैल्यू डाल दी जाती हैं. उदाहरण के लिए, पहले से तय की गई सेटिंग @platforms//cpu:cpu को एक कस्टम वैल्यू के साथ बढ़ाया जा सकता है. इससे, एक ऐसा प्लैटफ़ॉर्म तय किया जा सकता है जो किसी सीपीयू सीपीयू को टारगेट करता हो.

तर्क

विशेषताएं
name	Name; required इस टारगेट के लिए यूनीक नाम.
default_constraint_value	Name; optional; nonconfigurable अगर कोई मान नहीं दिया गया है, तो इस सेटिंग के लिए डिफ़ॉल्ट वैल्यू का लेबल इस्तेमाल किया जाएगा. अगर यह एट्रिब्यूट मौजूद है, तो constraint_value के ज़रिए बताए गए एट्रिब्यूट के बारे में उसी constraint_setting में बताए गए पैकेज में बताया जाना चाहिए. अगर कंस्ट्रेंट की सेटिंग की कोई डिफ़ॉल्ट वैल्यू है, तो जब भी प्लैटफ़ॉर्म पर उस सेटिंग के लिए कोई कंस्ट्रेंट वैल्यू शामिल न हो, तो प्लैटफ़ॉर्म के कंस्ट्रेंट की वैल्यू वही होती है जो प्लैटफ़ॉर्म ने दी है. ऐसा न होने पर, अगर कोई डिफ़ॉल्ट वैल्यू नहीं है, तो कंस्ट्रेंट की सेटिंग को उस प्लैटफ़ॉर्म से नहीं हटाया जाएगा. ऐसे में, प्लैटफ़ॉर्म ऐसी किसी भी कंस्ट्रेंट सूची (जैसे कि config_setting के लिए) से मेल नहीं खाएगा जिसे उस सेटिंग के लिए, किसी खास वैल्यू की ज़रूरत होती है.

कंस्ट्रेंट_वैल्यू

नियम का स्रोत देखेंopen_in_new

constraint_value(name, constraint_setting, deprecation, distribs, features, licenses, tags, testonly, visibility)

यह नियम, दिए गए कंस्ट्रेंट के लिए एक नई वैल्यू उपलब्ध कराता है. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पेज देखें.

उदाहरण

यह पहले से तय सीपीयू के आर्किटेक्चर को दिखाने वाले constraint_value के लिए एक नई वैल्यू बनाता है.

constraint_value(
    name = "mips",
    constraint_setting = "@platforms//cpu:cpu",
)

इसके बाद, प्लैटफ़ॉर्म यह एलान कर सकता है कि उसके पास mips आर्किटेक्चर, x86_64, arm वगैरह है.

तर्क

विशेषताएं
name	Name; required इस टारगेट के लिए यूनीक नाम.
constraint_setting	Label; required; nonconfigurable constraint_setting को चुना जा सकता है, जिसके लिए constraint_value का इस्तेमाल किया जा सकता है.

प्लैटफ़ॉर्म

नियम का सोर्स देखेंopen_in_new

platform(name, constraint_values, deprecation, distribs, exec_properties, features, licenses, parents, remote_execution_properties, tags, testonly, visibility)

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

उदाहरण

यह एक ऐसा प्लैटफ़ॉर्म तय करता है जो एआरएम पर Linux चलाने वाले किसी भी एनवायरमेंट की जानकारी देता है.

platform(
    name = "linux_arm",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)

प्लैटफ़ॉर्म इनहेरिटेंस

प्लैटफ़ॉर्म, parents एट्रिब्यूट का इस्तेमाल करके कोई ऐसा प्लैटफ़ॉर्म तय कर सकते हैं जहां से वे कंस्ट्रेंट वैल्यू इनहेरिट कर सकें. हालांकि, parents एट्रिब्यूट की सूची इस्तेमाल की जाती है, लेकिन एक बार में एक से ज़्यादा वैल्यू का इस्तेमाल नहीं किया जा सकता. साथ ही, एक से ज़्यादा पैरंट के बारे में जानकारी देने में गड़बड़ी होती है.

किसी प्लैटफ़ॉर्म पर कंस्ट्रेंट की वैल्यू की जांच करते समय, पहले constraint_values वैल्यू के ज़रिए सीधे तौर पर सेट की गई वैल्यू को चुना जाता है. इसके बाद, माता-पिता को कंस्ट्रेंट की वैल्यू दी जाती है. यह प्लैटफ़ॉर्म, बार-बार पैरंट प्लैटफ़ॉर्म की सीरीज़ में शामिल है. इस तरह, प्लैटफ़ॉर्म पर सेट की गई वैल्यू, पैरंट पर सेट की गई वैल्यू को बदल देंगी.

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

प्लैटफ़ॉर्म, पैरंट प्लैटफ़ॉर्म से भी remote_execution_properties एट्रिब्यूट (अब इस्तेमाल में नहीं है) भी हासिल कर सकते हैं. ध्यान दें: नए कोड के बजाय exec_properties का इस्तेमाल करना चाहिए. नीचे दिए गए तर्क को लेगसी बिहेवियर के साथ इस्तेमाल करने के लिए बनाए रखा गया है. हालांकि, इसे आने वाले समय में हटा दिया जाएगा. कोई पैरंट प्लैटफ़ॉर्म उपलब्ध होने पर, remote_execution_platform को सेट करने का तर्क यहां दिया गया है:

1. अगर remote_execution_property को चाइल्ड प्लैटफ़ॉर्म पर सेट नहीं किया गया है, तो पैरंट के remote_execution_properties का इस्तेमाल किया जाएगा.
2. अगर remote_execution_property को चाइल्ड प्लैटफ़ॉर्म पर सेट किया गया है और उसमें लिटरल स्ट्रिंग {CENTER_REMOTE_EXECUTION_PROPERTies} है, तो उस मैक्रो को पैरंट एट्रिब्यूट remote_execution_property के कॉन्टेंट से बदल दिया जाएगा.
3. अगर remote_execution_property को चाइल्ड प्लैटफ़ॉर्म पर सेट किया गया है और इसमें मैक्रो नहीं है, तो बच्चे के remote_execution_property का इस्तेमाल नहीं किया जाएगा.

remote_execution_properties के इस्तेमाल पर रोक लगा दी गई है और इसे हटा दिया जाएगा. इसलिए, एक ही इनहेरिटेंस वाली चेन में, remote_execution_properties और exec_properties को मिलाने की अनुमति नहीं है. अमान्य remote_execution_properties के बजाय exec_properties का इस्तेमाल करें.

उदाहरण: कंस्ट्रेंट वैल्यू

platform(
    name = "parent",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)
platform(
    name = "child_a",
    parents = [":parent"],
    constraint_values = [
        "@platforms//cpu:x86_64",
    ],
)
platform(
    name = "child_b",
    parents = [":parent"],
)

इस उदाहरण में, चाइल्ड प्लैटफ़ॉर्म पर ये प्रॉपर्टी मौजूद हैं:

• child_a की कंस्ट्रेंट वैल्यू @platforms//os:linux (जो पैरंट से इनहेरिट की गई हैं) और @platforms//cpu:x86_64 (सीधे प्लैटफ़ॉर्म पर सेट हैं) हैं.
• child_b, पैरंट की सभी कंस्ट्रेंट वैल्यू को इनहेरिट करता है और अपनी कोई वैल्यू सेट नहीं करता.

उदाहरण: एक्ज़ीक्यूशन प्रॉपर्टी

platform(
    name = "parent",
    exec_properties = {
      "k1": "v1",
      "k2": "v2",
    },
)
platform(
    name = "child_a",
    parents = [":parent"],
)
platform(
    name = "child_b",
    parents = [":parent"],
    exec_properties = {
      "k1": "child"
    }
)
platform(
    name = "child_c",
    parents = [":parent"],
    exec_properties = {
      "k1": ""
    }
)
platform(
    name = "child_d",
    parents = [":parent"],
    exec_properties = {
      "k3": "v3"
    }
)

इस उदाहरण में, चाइल्ड प्लैटफ़ॉर्म पर ये प्रॉपर्टी मौजूद हैं:

• child_a को पैरंट की "exec_Properties" मिलती है और वह अपनी खुद की प्रॉपर्टी सेट नहीं करती.
• child_b, पैरंट की exec_properties को इनहेरिट करता है और k1 की वैल्यू को बदल देता है. इसका exec_properties, { "k1": "child", "k2": "v2" } होगा.
• child_c, पैरंट की exec_properties को इनहेरिट करता है और k1 को अनसेट करता है. इसका exec_properties, { "k2": "v2" } होगा.
• child_d, पैरंट के exec_properties को इनहेरिट करता है और एक नई प्रॉपर्टी जोड़ता है. इसका exec_properties, { "k1": "v1", "k2": "v2", "k3": "v3" } होगा.

तर्क

विशेषताएं
name	Name; required इस टारगेट के लिए यूनीक नाम.
constraint_values	List of labels; optional; nonconfigurable इस प्लैटफ़ॉर्म में मौजूद कंस्ट्रेंट के विकल्पों का कॉम्बिनेशन. किसी प्लैटफ़ॉर्म पर प्लैटफ़ॉर्म लागू करने के लिए, एनवायरमेंट में इस सूची में कम से कम वैल्यू होनी चाहिए. इस सूची में मौजूद हर constraint_value अलग constraint_setting के लिए होना चाहिए. उदाहरण के लिए, आप ऐसा प्लैटफ़ॉर्म तय नहीं कर सकते जिसके लिए सीपीयू आर्किटेक्चर को @platforms//cpu:x86_64 और @platforms//cpu:arm, दोनों की ज़रूरत हो.
exec_properties	Dictionary: String -> String; optional मैप पर अलग-अलग कार्रवाइयों को पूरा करने वाली स्ट्रिंग का डेटा. बेज़ल इसे समझने की कोई कोशिश नहीं करता. इसे अपारदर्शी डेटा माना जाता है जो रिमोट एक्ज़ीक्यूशन प्रोटोकॉल के प्लैटफ़ॉर्म फ़ील्ड से फ़ॉरवर्ड किया जाता है. इसमें पैरंट प्लैटफ़ॉर्म के exec_properties एट्रिब्यूट से जुड़ा कोई भी डेटा शामिल होता है. अगर चाइल्ड और पैरंट प्लैटफ़ॉर्म एक ही कुंजी तय करते हैं, तो बच्चे की वैल्यू को सुरक्षित रखा जाता है. खाली स्ट्रिंग वाली वैल्यू से जुड़ी किसी भी कुंजी को डिक्शनरी से हटा दिया जाता है. यह एट्रिब्यूट, अब काम नहीं करता है remote_execution_properties.
parents	List of labels; optional; nonconfigurable platform टारगेट का लेबल जिसे इस प्लैटफ़ॉर्म से इनहेरिट किया जाना चाहिए. हालांकि, एट्रिब्यूट की सूची मिलती है. हालांकि, एक से ज़्यादा प्लैटफ़ॉर्म नहीं होने चाहिए. कोई भी पाबंदी_सेटिंग सीधे इस प्लैटफ़ॉर्म पर सेट नहीं है, तो वह पैरंट प्लैटफ़ॉर्म में दिखेगी. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पर इनहेरिटेंस वाला सेक्शन देखें.
remote_execution_properties	String; optional रुका हुआ विज्ञापन. कृपया इसके बजाय exec_Properties विशेषता का इस्तेमाल करें. स्ट्रिंग, जिसे एक्ज़ीक्यूशन प्लैटफ़ॉर्म कॉन्फ़िगर करने के लिए इस्तेमाल किया जाता है. असल बिल्ड इसे समझने की कोशिश नहीं करते हैं. यह ऐसा अपारदर्शी डेटा माना जाता है जिसे कोई खास SpwnRunner इस्तेमाल कर सकता है. इसमें मैक्रो "{Parent_REMOTE_EXECUTION_PROPERTIE}" का इस्तेमाल करके, पैरंट प्लैटफ़ॉर्म के "remote_execution_property" एट्रिब्यूट का डेटा शामिल किया जा सकता है. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म इनहेरिटेंस पर मौजूद सेक्शन देखें.

टूल चेन

नियम का सोर्स देखेंopen_in_new

toolchain(name, deprecation, distribs, exec_compatible_with, features, licenses, tags, target_compatible_with, target_settings, testonly, toolchain, toolchain_type, visibility)

यह नियम एक खास टूलचेन टाइप और कंस्ट्रेंट के बारे में बताता है, ताकि टूलचेन रिज़ॉल्यूशन के दौरान इसे चुना जा सके. ज़्यादा जानकारी के लिए, टूलचेन पेज देखें.

तर्क

विशेषताएं
name	Name; required इस टारगेट के लिए यूनीक नाम.
exec_compatible_with	List of labels; optional; nonconfigurable इस टूलचेन को उस प्लैटफ़ॉर्म पर मौजूद टारगेट बिल्डिंग के लिए चुनने के लिए, एक तय की गई प्रोसेस के हिसाब से constraint_value प्लैटफ़ॉर्म की सूची होनी चाहिए.
target_compatible_with	List of labels; optional; nonconfigurable इस टूलचेन को उस प्लैटफ़ॉर्म के लिए टारगेट बिल्डिंग के तौर पर चुनने के लिए, constraint_value की ऐसी सूची होती है जो टारगेट प्लैटफ़ॉर्म के हिसाब से सही हो.
target_settings	List of labels; optional टारगेट कॉन्फ़िगरेशन के हिसाब से सभी config_setting की सूची पूरी करनी होगी, ताकि टूलचेन रिज़ॉल्यूशन के दौरान, इस टूलचेन को चुना जा सके.
toolchain	Name; required टारगेट, उस असल टूल या टूल सुइट को दिखाता है जो इस टूलचेन को चुनने पर उपलब्ध कराया जाता है.
toolchain_type	Label; required; nonconfigurable toolchain_type टारगेट का लेबल, इस टूलचेन में इस्तेमाल की जाने वाली भूमिका को दिखाता है.

टूल चेन_टाइप

नियम का सोर्स देखेंopen_in_new

toolchain_type(name, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

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

ज़्यादा जानकारी के लिए, टूलचेन पेज देखें.

उदाहरण

यह किसी कस्टम नियम के लिए एक टूलचेन प्रकार को परिभाषित करता है.

toolchain_type(
    name = "bar_toolchain_type",
)

इसका इस्तेमाल bzl फ़ाइल में किया जा सकता है.

bar_binary = rule(
    implementation = _bar_binary_impl,
    attrs = {
        "srcs": attr.label_list(allow_files = True),
        ...
        # No `_compiler` attribute anymore.
    },
    toolchains = ["//bar_tools:toolchain_type"]
)

तर्क

विशेषताएं
name	Name; required इस टारगेट के लिए यूनीक नाम.