नियमों का यह सेट, आपको उन खास हार्डवेयर प्लैटफ़ॉर्म को मॉडल करने की अनुमति देता है जिनके लिए आप प्लैटफ़ॉर्म बना रहे हैं. साथ ही, यह आपको उन खास टूल के बारे में बताने की अनुमति देता है जिनकी ज़रूरत आपको उन प्लैटफ़ॉर्म के लिए कोड कंपाइल करने के दौरान पड़ सकती है. उपयोगकर्ता को यहां बताई गई अवधारणाओं के बारे में पता होना चाहिए यहां.
नियम
constraint_setting
नियम का सोर्स देखेंconstraint_setting(name, default_constraint_value, deprecation, distribs, features, licenses, tags, testonly, visibility)
इस नियम का इस्तेमाल, कंस्ट्रेंट के नए टाइप को पेश करने के लिए किया जाता है. इसके लिए, प्लैटफ़ॉर्म कोई वैल्यू तय कर सकता है.
उदाहरण के लिए, प्लैटफ़ॉर्म पर glibc लाइब्रेरी के अलग-अलग वर्शन इंस्टॉल करने की सुविधा दिखाने के लिए, "glibc_version" नाम का constraint_setting तय किया जा सकता है.
ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पेज देखें.
हर constraint_setting में, उससे जुड़ी constraint_value का सेट होता है. इसे बढ़ाया जा सकता है. आम तौर पर, इन्हें एक ही पैकेज में तय किया जाता है. हालांकि, कभी-कभी कोई दूसरा पैकेज, मौजूदा सेटिंग के लिए नई वैल्यू पेश करेगा. उदाहरण के लिए, किसी ऐसे प्लैटफ़ॉर्म को तय करने के लिए, जिसे सीपीयू के किसी खास आर्किटेक्चर के लिए बनाया गया है, पहले से तय सेटिंग @platforms//cpu:cpu को कस्टम वैल्यू के साथ बढ़ाया जा सकता है.
तर्क
| एट्रिब्यूट | |
|---|---|
name |
नाम; ज़रूरी है इस टारगेट के लिए कोई यूनीक नाम. |
default_constraint_value
|
नाम; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू constraint_value को उसी पैकेज में तय किया जाना चाहिए जिसमें यह constraint_setting तय किया गया है.
अगर कंस्ट्रेंट सेटिंग की कोई डिफ़ॉल्ट वैल्यू है, तो जब भी कोई प्लैटफ़ॉर्म उस सेटिंग के लिए कोई कंस्ट्रेंट वैल्यू शामिल नहीं करता है
तो यह ऐसा ही होता है जैसे प्लैटफ़ॉर्म ने डिफ़ॉल्ट वैल्यू तय की हो. इसके अलावा, अगर कोई डिफ़ॉल्ट वैल्यू नहीं है, तो कंस्ट्रेंट सेटिंग को उस प्लैटफ़ॉर्म के लिए तय नहीं किया गया माना जाता है. ऐसे में, प्लैटफ़ॉर्म किसी भी
कंस्ट्रेंट सूची (जैसे, |
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",
)
x86_64, arm वगैरह के विकल्प के तौर पर mips आर्किटेक्चर है.
तर्क
| एट्रिब्यूट | |
|---|---|
name |
नाम; ज़रूरी है इस टारगेट के लिए कोई यूनीक नाम. |
constraint_setting
|
लेबल; कॉन्फ़िगर नहीं किया जा सकता; ज़रूरी है वहconstraint_setting जिसके लिए यह constraint_value एक
संभावित विकल्प है.
|
platform
नियम का सोर्स देखेंplatform(name, constraint_values, deprecation, distribs, 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 सेट करने की लॉजिक इस तरह काम करती है जब कोई पैरंट प्लैटफ़ॉर्म मौजूद होता है:
-
अगर
remote_execution_propertyचाइल्ड प्लैटफ़ॉर्म पर सेट नहीं है, तो पैरंट केremote_execution_propertiesका इस्तेमाल किया जाएगा. -
अगर
remote_execution_propertyचाइल्ड प्लैटफ़ॉर्म पर सेट है और इसमें लिटरल स्ट्रिंग {PARENT_REMOTE_EXECUTION_PROPERTIES} शामिल है, तो उस मैक्रो को पैरंट केremote_execution_propertyएट्रिब्यूट के कॉन्टेंट से बदल दिया जाएगा. -
अगर
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
|
लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू इस सूची में मौजूद हर |
exec_properties
|
डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू exec_properties एट्रिब्यूट का कोई भी डेटा शामिल होता है.
अगर चाइल्ड और पैरंट प्लैटफ़ॉर्म, दोनों में एक ही कुंजियां तय की जाती हैं, तो चाइल्ड की वैल्यू सेव की जाती हैं. डिक्शनरी से, खाली स्ट्रिंग वाली वैल्यू से जुड़ी सभी
कुंजियां हटा दी जाती हैं.
यह एट्रिब्यूट, अब इस्तेमाल में नहीं रहे
remote_execution_properties की जगह पूरी तरह से ले चुका है.
|
parents
|
लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू platform टारगेट का लेबल, जिससे इस प्लैटफ़ॉर्म को इनहेरिट करना चाहिए. हालांकि,
इस एट्रिब्यूट में एक सूची शामिल होती है, लेकिन इसमें एक से ज़्यादा प्लैटफ़ॉर्म नहीं होना चाहिए. इस प्लैटफ़ॉर्म पर सीधे तौर पर सेट न की गई कोई भी
constraint_setting, पैरंट प्लैटफ़ॉर्म में मौजूद होगी.
ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म इनहेरिटेंस सेक्शन देखें.
|
remote_execution_properties
|
स्ट्रिंग; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू |
toolchain
नियम का सोर्स देखेंtoolchain(name, deprecation, distribs, exec_compatible_with, features, licenses, tags, target_compatible_with, target_settings, testonly, toolchain, toolchain_type, visibility)
इस नियम से, किसी खास टूल चेन के टाइप और कंस्ट्रेंट का एलान किया जाता है, ताकि टूल चेन रिज़ॉल्यूशन के दौरान इसे चुना जा सके. ज़्यादा जानकारी के लिए, टूल चेन पेज देखें.
तर्क
| एट्रिब्यूट | |
|---|---|
name |
नाम; ज़रूरी है इस टारगेट के लिए कोई यूनीक नाम. |
exec_compatible_with
|
लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू constraint_value की सूची. इस सूची में मौजूद सभी वैल्यू, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के लिए ज़रूरी हैं. ऐसा होने पर ही, उस प्लैटफ़ॉर्म पर बिल्ड किए जा रहे टारगेट के लिए इस टूल चेन को चुना जा सकता है.
|
target_compatible_with
|
लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू constraint_value की सूची. इस सूची में मौजूद सभी वैल्यू, टारगेट प्लैटफ़ॉर्म के लिए ज़रूरी हैं.
ऐसा होने पर ही, उस प्लैटफ़ॉर्म के लिए बिल्ड किए जा रहे टारगेट के लिए इस टूल चेन को चुना जा सकता है.
|
target_settings
|
लेबल की सूची; डिफ़ॉल्ट वैल्यू है config_setting की सूची. इस सूची में मौजूद सभी वैल्यू, टारगेट कॉन्फ़िगरेशन के लिए ज़रूरी हैं. ऐसा होने पर ही, टूल चेन रिज़ॉल्यूशन के दौरान इस टूल चेन को चुना जा सकता है.
|
toolchain
|
नाम; ज़रूरी है वह टारगेट जो असल टूल या टूल सुइट को दिखाता है. इस टूल चेन को चुनने पर, यह उपलब्ध हो जाता है. |
toolchain_type
|
लेबल; कॉन्फ़िगर नहीं किया जा सकता; ज़रूरी है 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 |
नाम; ज़रूरी है इस टारगेट के लिए कोई यूनीक नाम. |