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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की रिपोर्ट करें सोर्स देखें नाइटली · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

नियम

• constraint_setting
• constraint_value
• प्लैटफ़ॉर्म
• टूलचेन
• toolchain_type

constraint_setting

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

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	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.
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",
)

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

तर्क

विशेषताएं
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 को सेट करने का आधार यह होता है कि पैरंट प्लैटफ़ॉर्म है:

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

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

टूल चेन

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

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	नाम; आवश्यक इस टारगेट के लिए यूनीक नाम.