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