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

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

नियम

• constraint_setting
• constraint_value
• platform
• toolchain
• toolchain_type

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 को कस्टम वैल्यू के साथ बढ़ाया जा सकता है.

तर्क

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",
)

तर्क

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 को मिक्स करने की अनुमति नहीं है. अब इस्तेमाल नहीं किए जा रहे 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" }.

तर्क

toolchain

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

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

तर्क

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"]
)

तर्क