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

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

नियम

• 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

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 का अंतर इनहेरिटेंस चेन की अनुमति नहीं है. अब काम नहीं करने वाली सुविधा के बजाय, 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" }.

तर्क

टूल चेन

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

तर्क