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

नियम

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> विकल्प तय करने पर, बिल्ड ग्राफ़ में extra_actions जोड़ने के लिए, बिल्ड में तय किया गया 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" ].

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

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)

चेतावनी: अतिरिक्त कार्रवाइयों को बंद कर दिया गया है. इसके बजाय, पहलुओं का इस्तेमाल करें.

अगर 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 attribute की तरह, लेकिन इनमें ये अंतर हैं:

  1. कोई अनुमानित लेबल एक्सपैंशन नहीं. सिर्फ़ $(location ...) का इस्तेमाल करने वाले लेबल को एक्सपैंड किया जाता है.

  2. `attribute` से बनाए गए आउटपुट के सभी इंस्टेंस को बदलने के लिए, स्ट्रिंग पर एक और पास लागू किया जाता है.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 यह मान सकता है कि the ओरिजनल ऐक्शन के आउटपुट, इसके इनपुट के तौर पर उपलब्ध हैं.

tools

लेबल की सूची; डिफ़ॉल्ट रूप से []

इस नियम के लिए, tool डिपेंडेंसी की सूची.

ज़्यादा जानकारी के लिए, डिपेंडेंसी की परिभाषा देखें.

बिल्ड सिस्टम यह पक्का करता है कि extra_action कमांड चलाने से पहले, ये ज़रूरी शर्तें पूरी हों. इन्हें execकॉन्फ़िगरेशन, का इस्तेमाल करके बनाया जाता है, क्योंकि इन्हें बिल्ड के दौरान टूल के तौर पर चलाना ज़रूरी है. एक व्यक्तिगत tools टारगेट //x:y के पाथ को $(location //x:y) का इस्तेमाल करके पाया जा सकता है.

सभी टूल और उनकी डेटा डिपेंडेंसी को एक ही ट्री में कंसोलिडेट किया जाता है . इसमें कमांड, रिलेटिव पाथ का इस्तेमाल कर सकती है. वर्किंग डायरेक्ट्री, उस यूनीफ़ाइड ट्री का रूट होगी.