नियम
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)
चेतावनी: अतिरिक्त कार्रवाइयां हटा दी गई हैं. इसके बजाय aspects का इस्तेमाल करें.
action_listener
नियम खुद कोई आउटपुट नहीं देता है.
इसके बजाय, यह टूल डेवलपर को बिल्ड सिस्टम में extra_action
डालने की अनुमति देता है. इसके लिए, वे ऐक्शन से extra_action
को मैप करते हैं.
इस नियम के आर्ग्युमेंट,
extra_action
नियमों से ऐक्शन मॉनमोनिक्स मैप करते हैं.
--experimental_action_listener=<label>
विकल्प चुनने पर, बिल्ड
extra_action
को बिल्ड ग्राफ़ में डालने के लिए, तय किए गए action_listener
का इस्तेमाल करेगा.
उदाहरण
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
|
extra_action टारगेट की सूची
इस action_listener को बिल्ड ग्राफ़ में जोड़नी चाहिए.
उदाहरण के लिए, [ "//my/tools:analyzer" ] .
|
mnemonics
|
action_listener को सुनना चाहिए, जैसे कि [ "Javac" ] .
Mnemonics कोई सार्वजनिक इंटरफ़ेस नहीं है. इसकी कोई गारंटी नहीं है कि स्मरक (मेनिमोनिक) और उनकी कार्रवाइयों में कोई बदलाव नहीं होगा. |
extra_action
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)
चेतावनी: अतिरिक्त कार्रवाइयां हटा दी गई हैं. इसके बजाय aspects का इस्तेमाल करें.
सामान्य बिल्ड टारगेट के तौर पर बताए जाने पर, extra_action
नियम कोई काम का आउटपुट
नहीं देता. इसके बजाय, इसकी मदद से टूल डेवलपर
बिल्ड ग्राफ़ में ऐसी अन्य कार्रवाइयां शामिल कर सकते हैं जो मौजूदा कार्रवाइयों को शैडो करती हैं.
extra_action
चालू करने के तरीके के बारे में ज़्यादा जानने के लिए, action_listener
पर जाएं.
extra_action
, कमांड लाइन के तौर पर चलते हैं. कमांड-लाइन टूल को,
$(EXTRA_ACTION_FILE) के रूप में प्रोटोकॉल बफ़र वाली फ़ाइल का ऐक्सेस मिलता है.
इसमें उस मूल कार्रवाई की पूरी जानकारी होती है जिसे वह शैडो कर रहा था.
इसके पास उन सभी इनपुट फ़ाइलों का ऐक्सेस भी होता है जिनका ऐक्सेस ओरिजनल ऐक्शन के पास होता है.
प्रोटोकॉल बफ़र में सेव किए गए डेटा के बारे में जानने के लिए, extra_actions_base.proto देखें. हर प्रोटो फ़ाइल में
एक ExtraActionInfo मैसेज होता है.
दूसरी सभी कार्रवाइयों की तरह, अतिरिक्त कार्रवाइयां भी सैंडबॉक्स होती हैं और उन्हें ऐसी स्थिति में होने के लिए डिज़ाइन किया जाना चाहिए.
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. आप action_listener नियमों के extra_actions तर्क में, यह नियम label से देख सकते हैं.
|
cmd
|
नीचे बताए गए अंतर के साथ genrole cmd एट्रिब्यूट की तरह करें:
|
out_templates
|
extra_action कमांड से जनरेट की गई फ़ाइलों के लिए टेंप्लेट की सूची.
टेंप्लेट में इन वैरिएबल का इस्तेमाल किया जा सकता है:
|
requires_action_output
|
extra_action को, इस extra_action में इनपुट के तौर पर
ओरिजनल ऐक्शन के आउटपुट की ज़रूरत है.
'सही' (डिफ़ॉल्ट तौर पर गलत) होने पर, extra_action यह मान सकता है कि मूल कार्रवाई के आउटपुट उसके इनपुट के हिस्से के तौर पर उपलब्ध हैं. |
tools
|
tool डिपेंडेंसी की सूची.
ज़्यादा जानकारी के लिए, डिपेंडेंसी की परिभाषा देखें.
बिल्ड सिस्टम यह पक्का करता है कि सभी टूल और उनकी डेटा डिपेंडेंसी, एक ही ट्री में इकट्ठा कर दी जाती हैं. इनमें कमांड, रिलेटिव पाथ का इस्तेमाल कर सकता है. वर्किंग डायरेक्ट्री उस यूनिफ़ाइड ट्री का रूट होगी. |