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

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

नियम

• 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 को कस्टम वैल्यू के साथ बढ़ाया जा सकता है, ताकि किसी ऐसे प्लैटफ़ॉर्म को तय किया जा सके जो किसी खास सीपीयू आर्किटेक्चर को टारगेट करता हो.

तर्क

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(name, constraint_values, deprecation, distribs, exec_properties, features, flags, licenses, parents, remote_execution_properties, required_settings, tags, testonly, visibility)

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

उदाहरण

यह एक ऐसा प्लैटफ़ॉर्म तय करता है जो ARM पर Linux चलाने वाले किसी भी एनवायरमेंट के बारे में बताता है.

platform(
    name = "linux_arm",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)

प्लैटफ़ॉर्म फ़्लैग

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

प्लैटफ़ॉर्म से सेट किए गए फ़्लैग को सबसे ज़्यादा प्राथमिकता दी जाती है. साथ ही, कमांड लाइन, rc फ़ाइल या ट्रांज़िशन से, उस फ़्लैग की पिछली वैल्यू को बदल दिया जाता है.

उदाहरण

platform(
    name = "foo",
    flags = [
        "--dynamic_mode=fully",
        "--//bool_flag",
        "--no//package:other_bool_flag",
    ],
)

इससे foo नाम के प्लैटफ़ॉर्म के बारे में पता चलता है. अगर यह टारगेट प्लैटफ़ॉर्म है (इसकी वजह यह हो सकती है कि उपयोगकर्ता ने --platforms//:foo तय किया हो, किसी ट्रांज़िशन ने //command_line_option:platforms फ़्लैग को ["//:foo"] पर सेट किया हो या //:foo का इस्तेमाल, एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर किया गया हो), तो दिए गए फ़्लैग कॉन्फ़िगरेशन में सेट हो जाएंगे.

प्लैटफ़ॉर्म और बार-बार इस्तेमाल किए जा सकने वाले फ़्लैग

कुछ फ़्लैग दोहराए जाने पर, उनकी वैल्यू इकट्ठा हो जाएंगी. जैसे, --features, --copt, config.string(repeatable = True) के तौर पर बनाया गया कोई भी Starlark फ़्लैग. ये फ़्लैग, प्लैटफ़ॉर्म से फ़्लैग सेट करने के साथ काम नहीं करते: इसके बजाय, सभी पिछली वैल्यू हटा दी जाएंगी और प्लैटफ़ॉर्म की वैल्यू से बदल दी जाएंगी.

उदाहरण के लिए, नीचे दिए गए प्लैटफ़ॉर्म के लिए, build --platforms=//:repeat_demo --features feature_a --features feature_b को कॉल करने पर, --feature फ़्लैग की वैल्यू ["feature_c", "feature_d"] हो जाएगी. साथ ही, कमांड लाइन पर सेट की गई सुविधाएं हट जाएंगी.

platform(
    name = "repeat_demo",
    flags = [
        "--features=feature_c",
        "--features=feature_d",
    ],
)

इस वजह से, हमारा सुझाव है कि flags एट्रिब्यूट में, बार-बार इस्तेमाल किए जा सकने वाले फ़्लैग का इस्तेमाल न करें.

प्लैटफ़ॉर्म इनहेरिटेंस

प्लैटफ़ॉर्म, 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(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"]
)

तर्क