इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

constraint_setting

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

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

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

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

तर्क

विशेषताएं

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

default_constraint_value

नाम; कॉन्फ़िगरेशन नहीं किया जा सकता; डिफ़ॉल्ट रूप से None है

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

अगर किसी कंस्ट्रेंट सेटिंग की कोई डिफ़ॉल्ट वैल्यू है, तो जब भी किसी प्लैटफ़ॉर्म में उस सेटिंग के लिए कोई कंस्ट्रेंट वैल्यू शामिल नहीं होती, तब यह ठीक वैसा ही होता है जैसा प्लैटफ़ॉर्म ने डिफ़ॉल्ट वैल्यू तय की थी. ऐसा न होने पर, अगर कोई डिफ़ॉल्ट वैल्यू नहीं है, तो उस प्लैटफ़ॉर्म पर कंस्ट्रेंट सेटिंग की जानकारी नहीं दी जाएगी. ऐसे मामले में, प्लैटफ़ॉर्म ऐसी किसी भी कंस्ट्रेंट सूची (जैसे कि config_setting के लिए) से मैच नहीं होगा जिसमें उस सेटिंग के लिए किसी खास वैल्यू की ज़रूरत होती है.

constraint_value

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

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

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

उदाहरण

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

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

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

तर्क

विशेषताएं

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

constraint_setting

लेबल; कॉन्फ़िगर नहीं किया जा सकता; ज़रूरी है

वह constraint_setting जिसके लिए यह constraint_value एक संभावित विकल्प है.

platform

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

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

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

उदाहरण

यह एक प्लैटफ़ॉर्म के बारे में बताता है, जो ARM पर 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 को सेट करने का आधार यहां बताया गया है:

अगर remote_execution_property चाइल्ड प्लैटफ़ॉर्म पर सेट नहीं है, तो माता-पिता के remote_execution_properties का इस्तेमाल किया जाएगा.
अगर remote_execution_property को चाइल्ड प्लैटफ़ॉर्म पर सेट किया गया है और उसमें लिटरल स्ट्रिंग {PARENT_REMOTE_EXECUTION_PROPERTIES} है, तो उस मैक्रो को अभिभावक के remote_execution_property एट्रिब्यूट के कॉन्टेंट से बदल दिया जाएगा.
अगर 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_property" इनहेरिट करता है और खुद की "exec_property" सेट नहीं करता.
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`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`constraint_values`	लेबल की सूची कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट रूप से यह `[]` पर सेट होती है इस प्लैटफ़ॉर्म में कंस्ट्रेंट के विकल्पों का कॉम्बिनेशन शामिल है. किसी दिए गए एनवायरमेंट पर किसी प्लैटफ़ॉर्म को लागू करने के लिए, एनवायरमेंट में इस सूची में कम से कम वैल्यू होनी चाहिए. इस सूची में मौजूद हर `constraint_value`, अलग-अलग `constraint_setting` के लिए होना चाहिए. उदाहरण के लिए, ऐसा प्लैटफ़ॉर्म नहीं बनाया जा सकता जिसके लिए सीपीयू आर्किटेक्चर की `@platforms//cpu:x86_64` और `@platforms//cpu:arm`, दोनों ज़रूरी हों.
`exec_properties`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; कॉन्फ़िगरेशन नहीं किया जा सकता; डिफ़ॉल्ट `{}` है स्ट्रिंग का मैप, जो रिमोट तरीके से कार्रवाइयां करने के तरीके पर असर डालता है. Basel ने इसे समझने की कोशिश नहीं की. इसे ओपेक डेटा के तौर पर देखा जाता है जिसे रिमोट एक्ज़ीक्यूशन प्रोटोकॉल के प्लैटफ़ॉर्म फ़ील्ड के ज़रिए फ़ॉरवर्ड किया जाता है. इसमें पैरंट प्लैटफ़ॉर्म के `exec_properties` एट्रिब्यूट का कोई भी डेटा शामिल है. अगर चाइल्ड और पैरंट प्लैटफ़ॉर्म एक ही कुंजी तय करते हैं, तो बच्चे की वैल्यू रखी जाती हैं. किसी वैल्यू से जुड़ी ऐसी किसी भी कुंजी को शब्दकोश से हटा दिया जाता है जो खाली स्ट्रिंग होती है. यह एट्रिब्यूट, अब काम न करने वाले `remote_execution_properties` की जगह इस्तेमाल किया जा सकता है.
`parents`	लेबल की सूची कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट रूप से यह `[]` पर सेट होती है `platform` टारगेट का लेबल, जिससे इस प्लैटफ़ॉर्म को इनहेरिट किया जाना चाहिए. हालांकि, एट्रिब्यूट की एक सूची होती है, लेकिन एक से ज़्यादा प्लैटफ़ॉर्म नहीं होने चाहिए. ऐसी कोई भी कंस्ट्रेंट_सेटिंग, जिसे इस प्लैटफ़ॉर्म पर सीधे सेट नहीं किया गया है, पैरंट प्लैटफ़ॉर्म में मिलेगी. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म का इनहेरिटेंस सेक्शन देखें.
`remote_execution_properties`	स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट रूप से `""` पर सेट है रुका हुआ विज्ञापन. इसके बजाय, कृपया exec_property एट्रिब्यूट का इस्तेमाल करें. रिमोट तौर पर प्रोग्राम चलाने वाले प्लैटफ़ॉर्म को कॉन्फ़िगर करने के लिए इस्तेमाल की जाने वाली स्ट्रिंग. असल बिल्ड इसे समझने की कोशिश नहीं करते. इसे ओपेक डेटा के तौर पर देखा जाता है जिसका इस्तेमाल कोई खास स्पानरनर कर सकता है. इसमें मैक्रो "{PARENT_REMOTE_EXECUTION_PROPERTIES}" का इस्तेमाल करके, पैरंट प्लैटफ़ॉर्म के "remote_execution_property" एट्रिब्यूट से मिला डेटा शामिल किया जा सकता है. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म का इनहेरिटेंस सेक्शन देखें.

टूल चेन

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

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

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

तर्क

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

toolchain_type

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

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

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.