नियम
action_listener
नियम का सोर्स देखेंaction_listener(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, extra_actions, features, licenses, mnemonics, restricted_to, tags, target_compatible_with, testonly, visibility)
चेतावनी: कुछ और कार्रवाइयों के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय जानकारी का इस्तेमाल करें.
action_listener
नियम से कोई आउटपुट नहीं मिलता.
इसके बजाय, यह टूल डेवलपर को
extra_action
को बिल्ड सिस्टम में डालने की अनुमति देता है.
इसके लिए, यह कार्रवाई से extra_action
तक मैपिंग की जानकारी देता है.
इस नियम के तर्क, extra_action
नियमों पर कार्रवाई के नियमों को मैप करते हैं.
--experimental_action_listener=<label>
विकल्प की मदद से, बिल्ड बताए गए action_listener
का इस्तेमाल करके, बिल्ड ग्राफ़ में extra_action
डालेगा.
उदाहरण
action_listener( name = "index_all_languages", mnemonics = [ "Javac", "CppCompile", "Python", ], extra_actions = [":indexer"], ) action_listener( name = "index_java", mnemonics = ["Javac"], extra_actions = [":indexer"], ) extra_action( name = "indexer", tools = ["//my/tools:indexer"], cmd = "$(location //my/tools:indexer)" + "--extra_action_file=$(EXTRA_ACTION_FILE)", )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए यूनीक नाम. |
extra_actions
|
action_listener के extra_action टारगेट की सूची, बिल्ड ग्राफ़ में जोड़ी जानी चाहिए.
उदाहरण, [ "//my/tools:analyzer" ]
|
mnemonics
|
action_listener को सुनना चाहिए, जैसे कि [ "Javac" ] .
याद रखने का तरीका, सार्वजनिक इंटरफ़ेस नहीं है. इस बात की कोई गारंटी नहीं है कि शब्दों और वाक्यांशों में कोई बदलाव न किया जाए. |
अतिरिक्त_कार्रवाई
नियम का सोर्स देखेंextra_action(name, data, cmd, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, out_templates, requires_action_output, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
चेतावनी: कुछ और कार्रवाइयों के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय जानकारी का इस्तेमाल करें.
रेगुलर बिल्ड टारगेट के तौर पर तय किए जाने पर, extra_action
नियम से कोई काम का आउटपुट नहीं मिलता. इसके बजाय, टूल डेवलपर को
दूसरी कार्रवाइयों को उन बिल्ड ग्राफ़ में डालने की अनुमति देता है जो मौजूदा कार्रवाइयों को शैडो करते हैं.
extra_action
को चालू करने का तरीका जानने के लिए,
action_listener
देखें.
extra_action
, कमांड लाइन के तौर पर चलते हैं. कमांड-लाइन टूल को उस फ़ाइल का ऐक्सेस मिलता है जिसमें प्रोटोकॉल बफ़र $(EXTRA_ACTION_FILE)
का होता है. इसमें वह ओरिजनल ऐक्शन की जानकारी होती है जिसे शैडो कार्रवाई के तहत शैडो किया जाता है.
इसके पास उन सभी इनपुट फ़ाइलों का ऐक्सेस भी होता है जिनका ऐक्सेस मूल कार्रवाई के पास है.
प्रोटोकॉल बफ़र में स्टोर किए गए डेटा के बारे में ज़्यादा जानने के लिए, extra_action_base.proto देखें. हर प्रोटो फ़ाइल में
एक ExtraActionInfo मैसेज होता है.
अन्य सभी कार्रवाइयों की तरह ही, अतिरिक्त कार्रवाइयों को सैंडबॉक्स किया जाता है और उन्हें उसे हैंडल करने के लिए डिज़ाइन किया जाना चाहिए.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए यूनीक नाम. आप action_listener नियमों के extra_actions तर्क में label के इस नियम को देख सकते हैं.
|
cmd
|
नीचे दिए गए अंतर के साथ genrule cmd एट्रिब्यूट की तरह:
|
out_templates
|
extra_action कमांड से जनरेट की गई फ़ाइलों के टेंप्लेट की सूची.
टेंप्लेट में इन वैरिएबल का इस्तेमाल किया जा सकता है:
|
requires_action_output
|
extra_action में मूल कार्रवाई का आउटपुट इस extra_action के लिए इनपुट के तौर पर मौजूद होना चाहिए.
सही होने पर (डिफ़ॉल्ट रूप से 'गलत है' पर), Extra_action यह मान सकता है कि मूल कार्रवाई के आउटपुट अपने इनपुट के हिस्से के रूप में मौजूद हैं. |
tools
|
tool डिपेंडेंसी की सूची.
ज़्यादा जानकारी के लिए डिपेंडेंसी की परिभाषा देखें.
बिल्ड सिस्टम यह पक्का करता है कि ये ज़रूरी शर्तें, सभी टूल और उनके डेटा की डिपेंडेंसी एक ही ट्री में इकट्ठा हो जाती हैं. इसके अंदर कमांड, रिलेटिव पाथ का इस्तेमाल कर सकता है. काम करने वाली डायरेक्ट्री, उस यूनिफ़ाइड ट्री का रूट होगी. |