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

समस्या की शिकायत करें सोर्स देखें Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

नियम

• constraint_setting
• constraint_value
• platform
• टूलचेन
• toolchain_type

constraint_setting

नियम का सोर्स देखें

constraint_setting(name, aspect_hints, default_constraint_value, deprecation, features, licenses, tags, testonly, visibility)

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
default_constraint_value	नाम; बदला नहीं जा सकता; डिफ़ॉल्ट वैल्यू None है इस सेटिंग की डिफ़ॉल्ट वैल्यू का लेबल. इसका इस्तेमाल तब किया जाता है, जब कोई वैल्यू नहीं दी जाती है. अगर यह एट्रिब्यूट मौजूद है, तो यह जिस constraint_value की ओर इशारा करता है उसे उसी पैकेज में तय किया जाना चाहिए जिसमें यह constraint_setting मौजूद है. अगर किसी सेटिंग के लिए डिफ़ॉल्ट वैल्यू सेट है, तो जब भी कोई प्लैटफ़ॉर्म उस सेटिंग के लिए कोई वैल्यू शामिल नहीं करता है, तो उसे डिफ़ॉल्ट वैल्यू के तौर पर माना जाता है. इसके अलावा, अगर कोई डिफ़ॉल्ट वैल्यू नहीं है, तो प्लैटफ़ॉर्म पर पाबंदी की सेटिंग को 'तय नहीं की गई' माना जाता है. ऐसे में, प्लैटफ़ॉर्म किसी भी ऐसी शर्त वाली सूची (जैसे कि config_setting के लिए) से मेल नहीं खाएगा जिसके लिए उस सेटिंग की कोई खास वैल्यू ज़रूरी है.

constraint_value

नियम का सोर्स देखें

constraint_value(name, aspect_hints, constraint_setting, deprecation, features, licenses, tags, testonly, visibility)

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

उदाहरण

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

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
constraint_setting	लेबल; कॉन्फ़िगर नहीं किया जा सकता; ज़रूरी है वह constraint_setting जिसके लिए यह constraint_value एक संभावित विकल्प है.

प्लैटफ़ॉर्म

नियम का सोर्स देखें

platform(name, aspect_hints, constraint_values, deprecation, exec_properties, features, flags, licenses, missing_toolchain_error, 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" }.

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
constraint_values	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है इस प्लैटफ़ॉर्म में शामिल, पाबंदी से जुड़े विकल्पों का कॉम्बिनेशन. किसी प्लैटफ़ॉर्म को किसी एनवायरमेंट पर लागू करने के लिए, एनवायरमेंट में इस सूची में दी गई वैल्यू कम से कम होनी चाहिए. इस सूची में मौजूद हर constraint_value, अलग-अलग constraint_setting के लिए होना चाहिए. उदाहरण के लिए, ऐसा प्लैटफ़ॉर्म तय नहीं किया जा सकता जिसके लिए सीपीयू आर्किटेक्चर @platforms//cpu:x86_64 और @platforms//cpu:arm, दोनों होने चाहिए.
exec_properties	डिक्शनरी: String -> String; nonconfigurable; डिफ़ॉल्ट वैल्यू {} है यह स्ट्रिंग का एक मैप होता है. इससे यह तय होता है कि रिमोट से कार्रवाइयां कैसे की जाएंगी. Bazel इसे समझने की कोशिश नहीं करता. इसे ऐसे डेटा के तौर पर माना जाता है जिसे रिमोट एक्ज़ीक्यूशन प्रोटोकॉल के Platform फ़ील्ड के ज़रिए फ़ॉरवर्ड किया जाता है. इसमें पैरंट प्लैटफ़ॉर्म के exec_properties एट्रिब्यूट का डेटा भी शामिल होता है. अगर चाइल्ड और पैरंट प्लैटफ़ॉर्म, दोनों में एक ही कुंजियां तय की गई हैं, तो चाइल्ड प्लैटफ़ॉर्म की वैल्यू को बनाए रखा जाता है. डिक्शनरी से उन सभी कुंजियों को हटा दिया जाता है जिनकी वैल्यू एक खाली स्ट्रिंग होती है. यह एट्रिब्यूट, बंद हो चुके remote_execution_properties की जगह इस्तेमाल किया जा सकता है.
flags	स्ट्रिंग की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है उन फ़्लैग की सूची जिन्हें इस प्लैटफ़ॉर्म को कॉन्फ़िगरेशन में टारगेट प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने पर चालू किया जाएगा. सिर्फ़ उन फ़्लैग को सेट किया जा सकता है जो कॉन्फ़िगरेशन का हिस्सा हैं. जैसे, ट्रांज़िशन में इस्तेमाल किए जा सकने वाले फ़्लैग या --define फ़्लैग.
missing_toolchain_error	स्ट्रिंग; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू "For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro." है यह एक कस्टम गड़बड़ी का मैसेज है. यह तब दिखता है, जब टारगेट प्लैटफ़ॉर्म के लिए टूलचेन की ज़रूरी शर्त पूरी नहीं की जा सकती. इसका मकसद, उपयोगकर्ताओं को ज़रूरी दस्तावेज़ों के बारे में बताना है. इन दस्तावेज़ों को पढ़कर, उपयोगकर्ता यह जान सकते हैं कि उनकी टूलचेन को गलत तरीके से कॉन्फ़िगर क्यों किया गया है. इन्हें पैरंट प्लैटफ़ॉर्म से इनहेरिट नहीं किया जाता.
parents	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है platform टारगेट का वह लेबल जिसे इस प्लैटफ़ॉर्म को इनहेरिट करना चाहिए. हालांकि, इस एट्रिब्यूट में एक सूची दी जा सकती है, लेकिन इसमें एक से ज़्यादा प्लैटफ़ॉर्म मौजूद नहीं होने चाहिए. इस प्लैटफ़ॉर्म पर सीधे तौर पर सेट न की गई कोई भी constraint_settings, पैरंट प्लैटफ़ॉर्म में दिखेगी. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म इनहेरिटेंस सेक्शन देखें.
remote_execution_properties	स्ट्रिंग; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू "" है DEPRECATED. इसके बजाय, कृपया exec_properties एट्रिब्यूट का इस्तेमाल करें. इस स्ट्रिंग का इस्तेमाल, रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म को कॉन्फ़िगर करने के लिए किया जाता है. असल बिल्ड में, इसे समझने की कोई कोशिश नहीं की जाती. इसे ऐसे डेटा के तौर पर माना जाता है जिसका इस्तेमाल सिर्फ़ SpawnRunner कर सकता है. इसमें पैरंट प्लैटफ़ॉर्म के "remote_execution_properties" एट्रिब्यूट का डेटा शामिल हो सकता है. इसके लिए, "{PARENT_REMOTE_EXECUTION_PROPERTIES}" मैक्रो का इस्तेमाल करें. ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म इनहेरिटेंस सेक्शन देखें.
required_settings	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है config_setting की एक सूची, जिन्हें टारगेट कॉन्फ़िगरेशन को पूरा करना होगा, ताकि इस प्लैटफ़ॉर्म का इस्तेमाल टूलचेन रिज़ॉल्यूशन के दौरान एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर किया जा सके. ज़रूरी सेटिंग, पैरंट प्लैटफ़ॉर्म से इनहेरिट नहीं की जाती हैं.

टूल चेन

नियम का सोर्स देखें

toolchain(name, aspect_hints, deprecation, exec_compatible_with, features, licenses, package_metadata, tags, target_compatible_with, target_settings, testonly, toolchain, toolchain_type, use_target_platform_constraints, visibility)

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
exec_compatible_with	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है constraint_value की सूची. किसी एक्ज़ीक्यूशन प्लैटफ़ॉर्म को इन शर्तों को पूरा करना होगा, ताकि उस प्लैटफ़ॉर्म पर टारगेट बनाने के लिए इस टूलचेन को चुना जा सके.
target_compatible_with	लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू [] है constraint_value की सूची. टारगेट प्लैटफ़ॉर्म को इन शर्तों को पूरा करना होगा, ताकि इस टूलचेन को उस प्लैटफ़ॉर्म के लिए टारगेट बिल्डिंग के तौर पर चुना जा सके.
target_settings	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है config_setting की एक सूची. टूलचेन रिज़ॉल्यूशन के दौरान इस टूलचेन को चुनने के लिए, टारगेट कॉन्फ़िगरेशन को इन config_setting को पूरा करना होगा .
toolchain	नाम; ज़रूरी है यह टारगेट, टूल या टूल सुइट को दिखाता है. यह टूल या टूल सुइट, इस टूलचेन को चुनने पर उपलब्ध होता है.
toolchain_type	लेबल; कॉन्फ़िगर नहीं किया जा सकता; ज़रूरी है toolchain_type टारगेट का लेबल, जो यह दिखाता है कि यह टूलचेन कौनसी भूमिका निभाती है.
use_target_platform_constraints	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू False है अगर True है, तो यह टूलचेन इस तरह काम करती है जैसे कि इसकी exec_compatible_with और target_compatible_with की पाबंदियां, मौजूदा टारगेट प्लैटफ़ॉर्म की पाबंदियों पर सेट हों. ऐसे मामले में, exec_compatible_with और target_compatible_with को सेट नहीं किया जाना चाहिए.

toolchain_type

नियम का सोर्स देखें

toolchain_type(name, aspect_hints, compatible_with, deprecation, features, no_match_error, package_metadata, 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	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
no_match_error	स्ट्रिंग; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू "" है इस टाइप के लिए, मैच करने वाली कोई टूलचेन न मिलने पर दिखाने के लिए कस्टम गड़बड़ी का मैसेज.