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