अतिरिक्त कार्रवाइयों के नियम

समस्या की शिकायत करें सोर्स देखें Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

नियम

action_listener
extra_action

action_listener

action_listener(name, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, extra_actions, features, licenses, mnemonics, package_metadata, 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" ]`. निमोनिक, सार्वजनिक इंटरफ़ेस नहीं हैं. इस बात की कोई गारंटी नहीं है कि निमोनिक और उनसे जुड़ी कार्रवाइयां नहीं बदलेंगी.

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

extra_actions

लेबल की सूची; ज़रूरी है

extra_action टारगेट की सूची इस action_listener को बिल्ड ग्राफ़ में जोड़ना चाहिए. उदाहरण के लिए, [ "//my/tools:analyzer" ].

mnemonics

स्ट्रिंग की सूची; ज़रूरी है

कार्रवाइयों के लिए इस्तेमाल होने वाले निमोनिक की सूची.action_listener को इन निमोनिक के लिए सुनना चाहिए. उदाहरण के लिए, [ "Javac" ].

निमोनिक, सार्वजनिक इंटरफ़ेस नहीं हैं. इस बात की कोई गारंटी नहीं है कि निमोनिक और उनसे जुड़ी कार्रवाइयां नहीं बदलेंगी.

extra_action

नियम का सोर्स देखें

extra_action(name, data, aspect_hints, cmd, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, licenses, out_templates, package_metadata, 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_actions_base.proto देखें. हर प्रोटो फ़ाइल में ExtraActionInfo मैसेज होता है.

अन्य सभी कार्रवाइयों की तरह, अतिरिक्त कार्रवाइयों को भी सैंडबॉक्स किया जाता है. इसलिए, इन्हें इस तरह से डिज़ाइन किया जाना चाहिए कि ये सैंडबॉक्स को मैनेज कर सकें.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम. `action_listener` नियमों के `extra_actions` आर्ग्युमेंट में, इस नियम को `label` के तौर पर इस्तेमाल किया जा सकता है.
`cmd`	स्ट्रिंग; ज़रूरी है कमांड चलाने के लिए. जैसे, genrule cmd एट्रिब्यूट में ये अंतर हैं: लेबल एक्सपैंशन के लिए, अनुमानित तरीके का इस्तेमाल नहीं किया गया. सिर्फ़ $(location ...) का इस्तेमाल करने वाले लेबल को बड़ा किया जाता है. स्ट्रिंग पर एक और पास लागू किया जाता है, ताकि `out_templates` एट्रिब्यूट से बनाए गए सभी आउटपुट को बदला जा सके. `$(output out_template)` के सभी इंस्टेंस को, `label` से दिखाई गई फ़ाइल के पाथ से बदल दिया जाता है. उदाहरण के लिए, out_template `$(ACTION_ID).analysis` को `$(output $(ACTION_ID).analysis)` से मैच किया जा सकता है. असल में, यह `$(location)` की तरह ही सब्स्टिट्यूशन है, लेकिन इसका स्कोप अलग है.
`out_templates`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है `extra_action` कमांड से जनरेट की गई फ़ाइलों के लिए, टेंप्लेट की सूची. टेंप्लेट में इन वैरिएबल का इस्तेमाल किया जा सकता है: $(ACTION_ID), यह `extra_action` की यूनीक आईडी है. इस कुकी का इस्तेमाल, यूनीक आउटपुट फ़ाइल जनरेट करने के लिए किया जाता है.
`requires_action_output`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है इससे पता चलता है कि इस `extra_action` के लिए, ओरिजनल कार्रवाई के आउटपुट को इनपुट के तौर पर इस्तेमाल करना ज़रूरी है.`extra_action` अगर इसे 'सही है' पर सेट किया जाता है (डिफ़ॉल्ट तौर पर 'बंद है' पर सेट होता है), तो extra_action यह मान सकता है कि ओरिजनल ऐक्शन के आउटपुट, इसके इनपुट के तौर पर उपलब्ध हैं.
`tools`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस नियम के लिए `tool` डिपेंडेंसी की सूची. ज़्यादा जानकारी के लिए, डिपेंडेंसी की परिभाषा देखें. बिल्ड सिस्टम यह पक्का करता है कि `extra_action` कमांड चलाने से पहले, इन ज़रूरी शर्तों को पूरा किया गया हो. इन्हें `exec`configuration का इस्तेमाल करके बनाया जाता है, क्योंकि इन्हें बिल्ड के दौरान टूल के तौर पर चलाना होता है. `$(location //x:y)` का इस्तेमाल करके, किसी व्यक्ति के `tools` टारगेट `//x:y` का पाथ पाया जा सकता है. सभी टूल और उनके डेटा डिपेंडेंसी को एक ही ट्री में शामिल किया जाता है. इससे कमांड, रिलेटिव पाथ का इस्तेमाल कर सकती है. वर्किंग डायरेक्ट्री, यूनिफ़ाइड ट्री का रूट होगी.