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

नियम

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

constraint_setting

constraint_setting(name, default_constraint_value, deprecation, distribs, exec_compatible_with, exec_properties, 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 के लिए) से मैच नहीं करेगा जिसे उस सेटिंग के लिए किसी खास वैल्यू की ज़रूरत होती है.

constraint_value

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

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

उदाहरण

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

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

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

तर्क

एट्रिब्यूट
name	Name; required इस टारगेट के लिए एक खास नाम.
constraint_setting	Label; required; nonconfigurable वह constraint_setting जिसके लिए, constraint_value का इस्तेमाल किया जा सकता है.

platform

platform(name, constraint_values, deprecation, distribs, exec_compatible_with, 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" }.

तर्क

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

टूल चेन

toolchain(name, deprecation, distribs, exec_compatible_with, exec_properties, 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 टारगेट का लेबल, जो इस टूलचेन में मिलने वाली भूमिका के बारे में बताता है.

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	Name; required इस टारगेट के लिए एक खास नाम.