BazelCon 2022, 16 नवंबर से 17 नवंबर तक न्यूयॉर्क में और ऑनलाइन उपलब्ध है.
आज ही रजिस्टर करें!

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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

नियम

पाबंदी_सेटिंग

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

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

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

तर्क

एट्रिब्यूट
name

Name; required

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

default_constraint_value

Name; optional

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

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

पाबंदी/वैल्यू

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",
)
इसके बाद, प्लैटफ़ॉर्म यह एलान कर सकते हैं कि उनके पास mips आर्किटेक्चर, x86_64, arm वगैरह के विकल्प के तौर पर है.

तर्क

एट्रिब्यूट
name

Name; required

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

constraint_setting

Label; required

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

प्लैटफ़ॉर्म

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 डिक्शनरी में जानकारी जोड़ दी जाएगी. अगर एक ही कुंजी, पैरंट और #39; 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 के लिए होना चाहिए. उदाहरण के लिए, आप एक ऐसा प्लैटफ़ॉर्म नहीं बना सकते जिसके लिए cpu आर्किटेक्चर को @platforms//cpu:x86_64 और @platforms//cpu:arm दोनों की ज़रूरत हो.

exec_properties

Dictionary: String -> String; optional

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

List of labels; optional

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

String; optional

रुका हुआ विज्ञापन. इसके बजाय, कृपया exec_properties एट्रिब्यूट का इस्तेमाल करें. रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म को कॉन्फ़िगर करने के लिए इस्तेमाल की जाने वाली स्ट्रिंग. असल बिल्ड से यह समझने की कोशिश नहीं की जाती है कि उसे साफ़ तौर पर दिखाने वाला डेटा माना जाता है. इसका इस्तेमाल खास स्पॉनरनर कर सकते हैं. इसमें मैक्रो &कोटेशन;{PARENT_REMOTE_EXECUTION_PROPERTIES}&कोटेशन का इस्तेमाल करके, पैरंट प्लैटफ़ॉर्म's "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)

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

तर्क

एट्रिब्यूट
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(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

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