नियमों का यह सेट, आपको खास हार्डवेयर प्लैटफ़ॉर्म को मॉडल करने की अनुमति देता है उन प्लैटफ़ॉर्म के लिए कोड कंपाइल करने के लिए, खास टूल बनाना और उनके बारे में बताना. उपयोगकर्ता को यहां बताए गए कॉन्सेप्ट की जानकारी होनी चाहिए.
नियम
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
को कस्टम वैल्यू के साथ बढ़ाया जा सकता है. ऐसा करने पर,
एक प्लैटफ़ॉर्म को परिभाषित किया जा सकता है.
तर्क
विशेषताएं | |
---|---|
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", )अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इसके बाद, प्लैटफ़ॉर्म यह एलान कर सकते हैं कि उनके पास
mips
आर्किटेक्चर के बजाय
x86_64
, arm
वगैरह.
तर्क
विशेषताएं | |
---|---|
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
का अंतर
इनहेरिटेंस चेन की अनुमति नहीं है.
अब काम नहीं करने वाली सुविधा के बजाय, 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" }
.
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
constraint_values
|
लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से इस सूची में मौजूद हर |
exec_properties
|
शब्दकोश: स्ट्रिंग -> String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से exec_properties एट्रिब्यूट का कोई भी डेटा शामिल है.
अगर चाइल्ड और पैरंट प्लैटफ़ॉर्म एक ही कुंजी तय करते हैं, तो बच्चे की वैल्यू रखी जाती हैं. कोई भी
खाली स्ट्रिंग की वैल्यू से जुड़ी कुंजियों को शब्दकोश से हटा दिया जाता है.
यह एट्रिब्यूट अब काम नहीं करने वाले एट्रिब्यूट की जगह ले सकता है
remote_execution_properties .
|
parents
|
लेबल की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से platform टारगेट का लेबल, जिससे इस प्लैटफ़ॉर्म को इनहेरिट किया जाना चाहिए. हालांकि
एट्रिब्यूट की एक सूची होती है. इसलिए, एक से ज़्यादा प्लैटफ़ॉर्म नहीं होने चाहिए. कोई भी
कंस्ट्रेंट_सेटिंग, जो इस प्लैटफ़ॉर्म पर सीधे सेट नहीं हैं, पैरंट प्लैटफ़ॉर्म में मिलेंगी.
ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म का इनहेरिटेंस सेक्शन देखें.
|
remote_execution_properties
|
String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से |
टूल चेन
नियम का सोर्स देखें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 |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |