कमांड-लाइन रेफ़रंस

नाइटली रिलीज़ · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

bazel [<startup options>] <command> [<args>]

या

bazel [<startup options>] <command> [<args>] -- [<target patterns>]

टारगेट पैटर्न के सिंटैक्स के लिए, उपयोगकर्ता गाइड देखें.

विकल्प का सिंटैक्स

Bazel को अलग-अलग तरीकों से विकल्प दिए जा सकते हैं. जिन विकल्पों के लिए वैल्यू की ज़रूरत होती है उन्हें बराबर के चिह्न या स्पेस के साथ पास किया जा सकता है:

--<option>=<value>
--<option> <value>

कुछ विकल्पों के लिए, एक वर्ण वाला छोटा फ़ॉर्म इस्तेमाल किया जाता है. ऐसे में, छोटे फ़ॉर्म को एक डैश और स्पेस के साथ पास करना होता है.

-<short_form> <value>

बूलियन विकल्पों को इस तरह चालू किया जा सकता है:

--<option>
--<option>=[true|yes|1]

और इसे इस तरह बंद कर दिया गया है:

--no<option>
--<option>=[false|no|0]

आम तौर पर, ट्रिस्टेट विकल्प डिफ़ॉल्ट रूप से 'अपने-आप' पर सेट होते हैं. इन्हें इस तरह से चालू किया जा सकता है:

--<option>=[true|yes|1]

को बंद कर दिया गया है या इसे इस तरह से बंद किया गया है:

--no<option>
--<option>=[false|no|0]

निर्देश

`analyze-profile`	यह कुकी, बिल्ड प्रोफ़ाइल के डेटा का विश्लेषण करती है.
`aquery`	यह दिए गए टारगेट का विश्लेषण करता है और ऐक्शन ग्राफ़ से क्वेरी करता है.
`build`	यह तय किए गए टारगेट बनाता है.
`canonicalize-flags`	यह फ़ंक्शन, Bazel के विकल्पों की सूची को कैननिकल बनाता है.
`clean`	इससे आउटपुट फ़ाइलें हट जाती हैं. साथ ही, सर्वर को बंद करने का विकल्प भी मिलता है.
`coverage`	यह तय किए गए टेस्ट टारगेट के लिए, कोड कवरेज रिपोर्ट जनरेट करता है.
`cquery`	यह कॉन्फ़िगरेशन के साथ, तय किए गए टारगेट को लोड करता है, उनका विश्लेषण करता है, और उनसे क्वेरी करता है.
`dump`	यह Bazel सर्वर प्रोसेस की इंटरनल स्थिति को डंप करता है.
`fetch`	यह उन बाहरी रिपॉज़िटरी को फ़ेच करता है जो टारगेट के लिए ज़रूरी हैं.
`help`	निर्देशों या इंडेक्स के लिए मदद प्रिंट करता है.
`info`	यह Bazel सर्वर के बारे में रनटाइम की जानकारी दिखाता है.
`license`	इस सॉफ़्टवेयर का लाइसेंस प्रिंट करता है.
`mobile-install`	यह कुकी, मोबाइल डिवाइसों पर इंस्टॉल को टारगेट करती है.
`mod`	यह Bzlmod के बाहरी डिपेंडेंसी ग्राफ़ के बारे में क्वेरी करता है
`print_action`	यह विकल्प, किसी फ़ाइल को कंपाइल करने के लिए कमांड-लाइन आर्ग्युमेंट प्रिंट करता है.
`query`	डिपेंडेंसी ग्राफ़ क्वेरी को एक्ज़ीक्यूट करता है.
`run`	इससे तय किया गया टारगेट चलता है.
`shutdown`	यह Bazel सर्वर को बंद कर देता है.
`sync`	यह फ़ाइल फ़ोल्डर में मौजूद सभी रिपॉज़िटरी को सिंक करता है
`test`	यह तय किए गए टेस्ट टारगेट बनाता है और उन्हें चलाता है.
`vendor`	यह फ़्लैग --vendor_dir के ज़रिए तय किए गए फ़ोल्डर में, बाहरी रिपॉज़िटरी फ़ेच करता है.
`version`	Bazel के वर्शन की जानकारी दिखाता है.

स्टार्टअप के विकल्प

--[no]autodetect_server_javabase default: "true": जब --noautodetect_server_javabase पास किया जाता है, तो Bazel, bazel सर्वर को चलाने के लिए लोकल JDK पर वापस नहीं आता. इसके बजाय, यह बंद हो जाता है.
टैग: affects_outputs, loses_incremental_state
--[no]batch default: "false": अगर इसे सेट किया जाता है, तो Bazel को स्टैंडर्ड क्लाइंट/सर्वर मोड में चलाने के बजाय, सिर्फ़ एक क्लाइंट प्रोसेस के तौर पर चलाया जाएगा. यह सुविधा अब काम नहीं करती और इसे हटा दिया जाएगा. अगर आपको सर्वर को बंद करने में समस्या आ रही है, तो कृपया सर्वर को बंद करने के लिए इस तरीके का इस्तेमाल करें.
टैग: loses_incremental_state, bazel_internal_configuration, deprecated
--[no]batch_cpu_scheduling default: "false": सिर्फ़ Linux पर; Blaze के लिए 'batch' सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति उन वर्कलोड के लिए काम की है जिनमें इंटरैक्ट करने की ज़रूरत नहीं होती, लेकिन वे अपनी नाइस वैल्यू को कम नहीं करना चाहते. 'man 2 sched_setscheduler' देखें. अगर यह नीति 'गलत है' पर सेट है, तो Bazel सिस्टम कॉल नहीं करेगा.
टैग: host_machine_resource_optimizations
--bazelrc=<path> कई बार इस्तेमाल किया गया हो: उपयोगकर्ता की .bazelrc फ़ाइल की जगह. इसमें Bazel के विकल्पों की डिफ़ॉल्ट वैल्यू होती हैं. /dev/null से पता चलता है कि आगे के सभी `--bazelrc`को अनदेखा कर दिया जाएगा.यह उपयोगकर्ता की rc फ़ाइल को खोजने की सुविधा को बंद करने के लिए उपयोगी है. उदाहरण के लिए, रिलीज़ बिल्ड में. इस विकल्प को एक से ज़्यादा बार भी तय किया जा सकता है. उदाहरण के लिए, `--bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc` के साथ, 1) x.rc और y.rc पढ़े जाते हैं. 2) /dev/null के पहले से मौजूद होने की वजह से, z.rc को अनदेखा कर दिया जाता है. अगर कोई फ़ाइल नहीं बताई जाती है, तो Bazel उस पहली .bazelrc फ़ाइल का इस्तेमाल करता है जो उसे इन दो जगहों पर मिलती है: वर्कस्पेस डायरेक्ट्री और फिर उपयोगकर्ता की होम डायरेक्ट्री. ध्यान दें: कमांड लाइन के विकल्प, हमेशा bazelrc में मौजूद किसी भी विकल्प से ज़्यादा प्राथमिकता वाले होते हैं.
टैग: changes_inputs
--[no]block_for_lock default: "true": जब --noblock_for_lock पास किया जाता है, तो Bazel चालू कमांड के पूरा होने का इंतज़ार नहीं करता. इसके बजाय, यह तुरंत बंद हो जाता है.
टैग: eagerness_to_exit
--[no]client_debug default: "false": अगर सही है, तो क्लाइंट से डीबग जानकारी को stderr में लॉग करें. इस विकल्प को बदलने से, सर्वर रीस्टार्ट नहीं होगा.
टैग: affects_outputs, bazel_monitoring
--connect_timeout_secs=<an integer> डिफ़ॉल्ट: "30": क्लाइंट, सर्वर से कनेक्ट करने के हर अनुरोध के लिए कितने समय तक इंतज़ार करता है
टैग: bazel_internal_configuration
--digest_function=<hash function> डिफ़ॉल्ट: ब्यौरा देखें: फ़ाइल डाइजेस्ट का हिसाब लगाते समय इस्तेमाल किया जाने वाला हैश फ़ंक्शन.
टैग: loses_incremental_state, bazel_internal_configuration
--experimental_cgroup_parent=<path> डिफ़ॉल्ट: ब्यौरा देखें: वह cgroup जहां Bazel सर्वर को ऐब्सलूट पाथ के तौर पर शुरू करना है. सर्वर प्रोसेस, हर कंट्रोलर के लिए बताए गए cgroup में शुरू की जाएगी. उदाहरण के लिए, अगर इस फ़्लैग की वैल्यू /build/bazel है और सीपीयू और मेमोरी कंट्रोलर को क्रमशः /sys/fs/cgroup/cpu और /sys/fs/cgroup/memory पर माउंट किया गया है, तो सर्वर को cgroups /sys/fs/cgroup/cpu/build/bazel और /sys/fs/cgroup/memory/build/bazel में शुरू किया जाएगा.अगर बताया गया cgroup, एक या उससे ज़्यादा कंट्रोलर के लिए लिखने लायक नहीं है, तो यह गड़बड़ी नहीं है. इस विकल्प का उन प्लैटफ़ॉर्म पर कोई असर नहीं पड़ता जिन पर cgroup काम नहीं करते.
टैग: bazel_monitoring, execution
--[no]experimental_run_in_user_cgroup default: "false": अगर यह विकल्प सही है, तो Bazel सर्वर को systemd-run के साथ चलाया जाएगा. साथ ही, उपयोगकर्ता के पास cgroup का मालिकाना हक होगा. इस फ़्लैग का असर सिर्फ़ Linux पर पड़ता है.
टैग: bazel_monitoring, execution
--failure_detail_out=<path> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेट है, तो यह ऐसी जगह के बारे में बताता है जहां सर्वर के काम न करने पर, failure_detail protobuf मैसेज लिखा जा सकता है. ऐसा तब होता है, जब सर्वर सामान्य तरीके से gRPC के ज़रिए इसकी सूचना नहीं दे पाता. अगर ऐसा नहीं होता है, तो फ़ाइल ${OUTPUT_BASE}/failure_detail.rawproto में सेव होगी.
टैग: affects_outputs, loses_incremental_state
--[no]home_rc default: "true": $HOME/.bazelrc में मौजूद होम bazelrc फ़ाइल को ढूंढना है या नहीं
टैग: changes_inputs
--[no]idle_server_tasks default: "true": सर्वर के इस्तेमाल में न होने पर, System.gc() चलाएं
टैग: loses_incremental_state, host_machine_resource_optimizations
--[no]ignore_all_rc_files default: "false": यह सभी rc फ़ाइलों को बंद कर देता है. भले ही, rc में बदलाव करने वाले अन्य फ़्लैग की वैल्यू कुछ भी हों. भले ही, ये फ़्लैग स्टार्टअप के विकल्पों की सूची में बाद में आते हों.
टैग: changes_inputs
--io_nice_level={-1,0,1,2,3,4,5,6,7} डिफ़ॉल्ट: "-1": सिर्फ़ Linux पर; sys_ioprio_set सिस्टम कॉल का इस्तेमाल करके, सबसे अच्छे तरीके से आई/ओ शेड्यूल करने के लिए, 0 से 7 तक का लेवल सेट करें. 0 सबसे ज़्यादा प्राथमिकता वाला और 7 सबसे कम प्राथमिकता वाला है. अनुमानित शेड्यूल करने की सुविधा, सिर्फ़ प्राथमिकता 4 तक के अनुरोधों को पूरा कर सकती है. अगर इसे नेगेटिव वैल्यू पर सेट किया जाता है, तो Bazel सिस्टम कॉल नहीं करता.
टैग: host_machine_resource_optimizations
--local_startup_timeout_secs=<an integer> डिफ़ॉल्ट: "120": क्लाइंट, सर्वर से कनेक्ट होने के लिए ज़्यादा से ज़्यादा कितना समय इंतज़ार करता है
टैग: bazel_internal_configuration
--macos_qos_class=<a string> default: "default": macOS पर Bazel सर्वर चलाने पर, QoS सेवा क्लास सेट करता है. इस फ़्लैग का असर अन्य सभी प्लैटफ़ॉर्म पर नहीं पड़ता. हालांकि, इसे इसलिए इस्तेमाल किया जाता है, ताकि यह पक्का किया जा सके कि rc फ़ाइलों को बिना किसी बदलाव के इन प्लैटफ़ॉर्म के बीच शेयर किया जा सके. संभावित वैल्यू ये हैं: user-interactive, user-initiated, default, utility, और background.
टैग: host_machine_resource_optimizations
--max_idle_secs=<integer> default: "10800": यह बताता है कि बिल्ड सर्वर बंद होने से पहले कितने सेकंड तक इंतज़ार करेगा. शून्य का मतलब है कि सर्वर कभी बंद नहीं होगा. इसे सिर्फ़ सर्वर शुरू होने पर पढ़ा जाता है. इस विकल्प को बदलने से सर्वर रीस्टार्ट नहीं होगा.
टैग: eagerness_to_exit, loses_incremental_state
--output_base=<path> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेट है, तो यह आउटपुट की उस जगह की जानकारी देता है जहां सभी बिल्ड आउटपुट लिखे जाएंगे. ऐसा न होने पर, लोकेशन ${OUTPUT_ROOT}/_blaze_${USER}/${MD5_OF_WORKSPACE_ROOT} होगी. ध्यान दें: अगर आपने इस वैल्यू के लिए, Bazel को एक से दूसरी बार शुरू करने पर कोई दूसरा विकल्प चुना है, तो हो सकता है कि आपको एक नया Bazel सर्वर शुरू करना पड़े. Bazel, तय किए गए हर आउटपुट बेस के लिए सिर्फ़ एक सर्वर शुरू करता है. आम तौर पर, हर Workspace के लिए एक आउटपुट बेस होता है. हालांकि, इस विकल्प की मदद से, हर Workspace के लिए एक से ज़्यादा आउटपुट बेस बनाए जा सकते हैं. इससे, एक ही मशीन पर एक ही क्लाइंट के लिए एक साथ कई बिल्ड चलाए जा सकते हैं. Bazel सर्वर को बंद करने का तरीका जानने के लिए, 'bazel help shutdown' देखें.
टैग: affects_outputs, loses_incremental_state
--output_user_root=<path> डिफ़ॉल्ट: ब्यौरा देखें: यह उपयोगकर्ता के हिसाब से तय की गई डायरेक्ट्री होती है. इसमें सभी बिल्ड आउटपुट लिखे जाते हैं. डिफ़ॉल्ट रूप से, यह $USER का फ़ंक्शन होता है. हालांकि, किसी कॉन्स्टेंट को तय करके, बिल्ड आउटपुट को साथ मिलकर काम करने वाले उपयोगकर्ताओं के बीच शेयर किया जा सकता है.
टैग: affects_outputs, loses_incremental_state
--[no]preemptible default: "false": अगर यह वैल्यू सही है, तो कोई दूसरी कमांड शुरू होने पर, इस कमांड को रोका जा सकता है.
टैग: eagerness_to_exit
--[no]quiet default: "false": अगर यह वैल्यू सही है, तो कंसोल पर सूचना देने वाले मैसेज नहीं दिखेंगे. सिर्फ़ गड़बड़ियों के मैसेज दिखेंगे. इस विकल्प को बदलने से, सर्वर रीस्टार्ट नहीं होगा.
टैग: affects_outputs, bazel_monitoring
--server_jvm_out=<path> डिफ़ॉल्ट: ब्यौरा देखें: सर्वर के JVM के आउटपुट को लिखने की जगह. अगर इसे सेट नहीं किया जाता है, तो यह output_base में मौजूद किसी जगह पर डिफ़ॉल्ट रूप से सेट हो जाता है.
टैग: affects_outputs, loses_incremental_state
--[no]shutdown_on_low_sys_mem default: "false": अगर max_idle_secs सेट है और बिल्ड सर्वर कुछ समय से इस्तेमाल नहीं किया जा रहा है, तो सिस्टम में खाली रैम कम होने पर सर्वर को बंद कर दें. सिर्फ़ Linux के लिए.
टैग: eagerness_to_exit, loses_incremental_state
--[no]system_rc default: "true": सिस्टम-वाइड bazelrc को खोजना है या नहीं.
टैग: changes_inputs
--[no]unlimit_coredumps default: "false": यह विकल्प, सॉफ़्ट कोरडंप की सीमा को हार्ड लिमिट तक बढ़ाता है, ताकि सामान्य स्थितियों में सर्वर (इसमें JVM भी शामिल है) और क्लाइंट के कोरडंप बनाए जा सकें. इस फ़्लैग को अपने bazelrc में एक बार चिपकाएं और इसके बारे में भूल जाएं, ताकि जब आपको ऐसी स्थिति का सामना करना पड़े जो कोरडंप को ट्रिगर करती है, तो आपको कोरडंप मिलें.
टैग: bazel_internal_configuration
--[no]watchfs default: "false": अगर यह विकल्प सही पर सेट है, तो Bazel हर फ़ाइल को स्कैन करने के बजाय, ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करके स्थानीय बदलावों का पता लगाने की कोशिश करता है.
टैग: deprecated
--[no]windows_enable_symlinks default: "false": अगर यह विकल्प चुना जाता है, तो फ़ाइल कॉपी करने के बजाय Windows पर असली सिंबॉलिक लिंक बनाए जाएंगे. इसके लिए, Windows डेवलपर मोड चालू होना चाहिए. साथ ही, Windows 10 का 1703 या उसके बाद का वर्शन होना चाहिए.
टैग: bazel_internal_configuration
--[no]workspace_rc default: "true": $workspace/.bazelrc पर मौजूद वर्कस्पेस की bazelrc फ़ाइल को देखना है या नहीं
टैग: changes_inputs

--host_jvm_args=<jvm_arg> कई बार इस्तेमाल किया गया हो: Blaze को चलाने वाले JVM को पास किए जाने वाले फ़्लैग.
--host_jvm_debug: कुछ और JVM स्टार्टअप फ़्लैग जोड़ने का आसान विकल्प. इनकी वजह से, स्टार्टअप के दौरान JVM तब तक इंतज़ार करता है, जब तक कि आप पोर्ट 5005 से JDWP के साथ काम करने वाले डीबगर (जैसे कि Eclipse) से कनेक्ट नहीं हो जाते.
बढ़कर यह हो जाता है:
--host_jvm_args=-Xdebug
--host_jvm_args=-Xrunjdwp:transport=dt_socket,server=y,address=5005
--server_javabase=<jvm path> default: "": Bazel को चलाने के लिए इस्तेमाल किए गए JVM का पाथ.

सभी निर्देशों के लिए उपलब्ध विकल्प

--distdir=<a path> कई बार इस्तेमाल किया गया हो: नेटवर्क से डाउनलोड करने से पहले, संग्रहों को खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks default: "false": अगर यह विकल्प सेट है, तो कैश मेमोरी में मौजूद फ़ाइल को कॉपी करने के बजाय, रिपॉज़िटरी कैश मेमोरी उसे हार्डलिंक करेगी. इसका मकसद डिस्क में जगह बचाना है.
टैग: bazel_internal_configuration
--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "5": डाउनलोड करने में हुई गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental
--experimental_scale_timeouts=<a double> default: "1.0": इस फ़ैक्टर के हिसाब से, Starlark के डेटाबेस नियमों में सभी टाइमआउट को स्केल करें. इस तरह, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले व्यक्ति की उम्मीद से ज़्यादा समय लेती हैं. इसके लिए, सोर्स कोड में बदलाव करने की ज़रूरत नहीं होती
टैग: bazel_internal_configuration, experimental
--http_connector_attempts=<an integer> default: "8": http से डाउनलोड करने के लिए, ज़्यादा से ज़्यादा कोशिशें.
टैग: bazel_internal_configuration
--http_connector_retry_max_timeout=<An immutable length of time.> default: "0s": एचटीटीपी डाउनलोड करने की कोशिशों के लिए, ज़्यादा से ज़्यादा समय खत्म होने की अवधि. वैल्यू 0 होने पर, ज़्यादा से ज़्यादा समयसीमा तय नहीं की जाती.
टैग: bazel_internal_configuration
--http_max_parallel_downloads=<an integer> default: "8": साथ-साथ डाउनलोड होने वाली एचटीटीपी फ़ाइलों की ज़्यादा से ज़्यादा संख्या.
टैग: bazel_internal_configuration
--http_timeout_scaling=<a double> default: "1.0": एचटीटीपी डाउनलोड से जुड़े सभी टाइमआउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग: bazel_internal_configuration
--[no]incompatible_disable_native_repo_rules default: "false": अगर यह वैल्यू 'गलत है' पर सेट है, तो WORKSPACE में नेटिव रीपो नियमों का इस्तेमाल किया जा सकता है. अगर यह वैल्यू 'सही है' पर सेट है, तो WORKSPACE में Starlark रीपो नियमों का इस्तेमाल करना होगा. नेटिव रेपो नियमों में local_repository, new_local_repository, और local_config_platform शामिल हैं. इस फ़्लैग को सेट करने पर, Bzlmod में local_config_platform बिल्ट-इन मॉड्यूल भी उपलब्ध नहीं होता है. इसके बजाय, `@platforms//host` का इस्तेमाल करें.
टैग: bazel_internal_configuration
--repo_contents_cache=<a path> default: "": यह repo के कॉन्टेंट की कैश मेमोरी की जगह के बारे में बताता है. इसमें फ़ेच की गई repo डायरेक्ट्री होती हैं, जिन्हें सभी वर्कस्पेस के साथ शेयर किया जा सकता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग का इस्तेमाल करने से, रिपॉज़िटरी के कॉन्टेंट की कैश मेमोरी को बंद करने का अनुरोध किया जाता है.
टैग: bazel_internal_configuration
--repo_contents_cache_gc_idle_delay=<An immutable length of time.> default: "5m": इससे यह तय होता है कि रिपॉज़िटरी के कॉन्टेंट की कैश मेमोरी में मौजूद डेटा को हटाने से पहले, सर्वर को कितने समय तक इस्तेमाल नहीं किया जाना चाहिए.
टैग: bazel_internal_configuration
--repo_contents_cache_gc_max_age=<An immutable length of time.> डिफ़ॉल्ट: "14d": इससे पता चलता है कि रीपो के कॉन्टेंट की कैश मेमोरी में मौजूद कोई एंट्री, कितने समय तक इस्तेमाल नहीं की जा सकती. इसके बाद, उसे हटा दिया जाता है. अगर इसे शून्य पर सेट किया जाता है, तो गार्बेज कलेक्शन की सुविधा बंद हो जाती है.
टैग: bazel_internal_configuration
--repository_cache=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह के बारे में बताता है. ये वैल्यू, बाहरी रिपॉज़िटरी से फ़ेच की जाती हैं. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग का इस्तेमाल करने पर, कैश मेमोरी को बंद करने का अनुरोध किया जाता है. ऐसा न करने पर, डिफ़ॉल्ट रूप से '<--output_user_root>/cache/repos/v1' का इस्तेमाल किया जाता है
टैग: bazel_internal_configuration
--[no]repository_disable_download default: "false": अगर यह सेट है, तो रिपॉज़िटरी फ़ेच करने के दौरान ctx.download{,_and_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है. ctx.execute अब भी इंटरनेट ऐक्सेस करने वाले किसी भी एक्ज़ीक्यूटेबल को चला सकता है.
टैग: bazel_internal_configuration

--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range> default: "1048576": stdout / stderr फ़ाइलों का ज़्यादा से ज़्यादा साइज़, जिसे कंसोल पर प्रिंट किया जाएगा. -1 का मतलब है कि कोई सीमा नहीं है.
टैग: execution
--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह, इस्तेमाल किए गए स्पेस का वह प्रतिशत (0-100) है जिसके ऊपर GcThrashingDetector, मेमोरी प्रेशर इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--[no]incompatible_enable_proto_toolchain_resolution default: "false": अगर यह सही है, तो प्रोटो लैंग के नियम, प्रोटोबफ़ रिपॉज़िटरी से टूलचेन तय करते हैं.
टैग: loading_and_analysis, incompatible_change

--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1": बीईपी आर्टफ़ैक्ट अपलोड करते समय, ज़्यादा से ज़्यादा इतनी फ़ाइलें खुली होनी चाहिए.
टैग: affects_outputs
--remote_download_all: इस विकल्प से, सभी रिमोट आउटपुट को लोकल मशीन पर डाउनलोड किया जाता है. यह फ़्लैग, --remote_download_outputs=all का एलियास है.
इनके लिए उपलब्ध है:
--remote_download_outputs=all

टैग: affects_outputs
--remote_download_minimal: यह लोकल मशीन पर, रिमोट बिल्ड के किसी भी आउटपुट को डाउनलोड नहीं करता है. यह फ़्लैग, --remote_download_outputs=minimal का अन्य नाम है.
इनके लिए उपलब्ध है:
--remote_download_outputs=minimal

टैग: affects_outputs
--remote_download_outputs=<all, minimal or toplevel> default: "toplevel": 'कम से कम' पर सेट होने पर, रिमोट बिल्ड के किसी भी आउटपुट को लोकल मशीन पर डाउनलोड नहीं करता है. हालांकि, स्थानीय कार्रवाइयों के लिए ज़रूरी आउटपुट डाउनलोड किए जाते हैं. 'toplevel' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह टॉप लेवल के टारगेट के आउटपुट को भी लोकल मशीन पर डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की वजह से बिल्ड होने में ज़्यादा समय लगता है, तो इन दोनों विकल्पों से बिल्ड होने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs
--remote_download_symlink_template=<a string> default: "": रिमोट बिल्ड के आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबॉलिक लिंक बनाएं. सिंबॉलिक लिंक के टारगेट को टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये ऑब्जेक्ट के हैश और साइज़ को बाइट में दिखाते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक ऐसे FUSE फ़ाइल सिस्टम की ओर ले जा सकते हैं जो CAS से ऑब्जेक्ट को ज़रूरत के हिसाब से लोड करता है.
टैग: affects_outputs
--remote_download_toplevel: यह सिर्फ़ टॉप लेवल के टारगेट के रिमोट आउटपुट को स्थानीय मशीन पर डाउनलोड करता है. यह फ़्लैग, --remote_download_outputs=toplevel के लिए उपनाम है.
इनके लिए उपलब्ध है:
--remote_download_outputs=toplevel

टैग: affects_outputs
--repo_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह ऐसे अतिरिक्त एनवायरमेंट वैरिएबल तय करता है जो सिर्फ़ रिपॉज़िटरी के नियमों के लिए उपलब्ध होते हैं. ध्यान दें कि रिपॉज़िटरी के नियम, पूरे एनवायरमेंट को देखते हैं. हालांकि, इस तरह से कॉन्फ़िगरेशन की जानकारी को विकल्पों के ज़रिए रिपॉज़िटरी में पास किया जा सकता है. इससे ऐक्शन ग्राफ़ अमान्य नहीं होता.
टैग: action_command_lines

--[no]check_bzl_visibility default: "true": अगर यह विकल्प बंद है, तो .bzl फ़ाइल लोड करने की गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]incompatible_enforce_starlark_utf8 डिफ़ॉल्ट: "warning": अगर यह सेटिंग चालू है या इसे 'error' पर सेट किया गया है, तो Starlark फ़ाइलों को UTF-8 में कोड में बदलने पर गड़बड़ी होगी. अगर इसे 'warning' पर सेट किया जाता है, तो इसके बजाय चेतावनी जारी करें. अगर इसे 'off' पर सेट किया जाता है, तो Bazel यह मान लेता है कि Starlark फ़ाइलें UTF-8 में एन्कोड की गई हैं. हालांकि, वह इस बात की पुष्टि नहीं करता है. ध्यान दें कि UTF-8 में एन्कोड नहीं की गई Starlark फ़ाइलों की वजह से, Bazel अलग-अलग तरीके से काम कर सकता है.
टैग: loading_and_analysis, incompatible_change

--[no]enable_bzlmod default: "true": अगर सही है, तो Bzlmod डिपेंडेंसी मैनेजमेंट सिस्टम चालू हो जाता है. इसे WORKSPACE से ज़्यादा प्राथमिकता मिलती है. ज़्यादा जानकारी के लिए, https://bazel.build/docs/bzlmod पर जाएं.
टैग: loading_and_analysis
--[no]enable_workspace default: "false": अगर सही है, तो बाहरी डिपेंडेंसी के लिए लेगसी WORKSPACE सिस्टम चालू करता है. ज़्यादा जानकारी के लिए, https://bazel.build/external/overview पर जाएं.
टैग: loading_and_analysis
--[no]experimental_bzl_visibility default: "true": इस विकल्प को चालू करने पर, `visibility()` फ़ंक्शन जुड़ जाता है. .bzl फ़ाइलें, टॉप-लेवल के आकलन के दौरान इस फ़ंक्शन को कॉल कर सकती हैं. इससे, load() स्टेटमेंट के लिए अपनी विज़िबिलिटी सेट की जा सकती है.
टैग: loading_and_analysis, experimental
--[no]experimental_cc_shared_library default: "false": अगर इसे सही पर सेट किया जाता है, तो cc_shared_library नियम के लिए ज़रूरी नियम एट्रिब्यूट और Starlark API के तरीके उपलब्ध होंगे
टैग: build_file_semantics, loading_and_analysis, experimental
--[no]experimental_disable_external_package default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो अपने-आप जनरेट होने वाला //external पैकेज अब उपलब्ध नहीं होगा. Bazel अब भी 'external/BUILD' फ़ाइल को पार्स नहीं कर पाएगा. हालांकि, बिना नाम वाले पैकेज से external/ तक पहुंचने वाले ग्लोब काम करेंगे.
टैग: loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_dormant_deps default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो attr.label(materializer=), attr(for_dependency_resolution=), attr.dormant_label(), attr.dormant_label_list() और rule(for_dependency_resolution=) का इस्तेमाल किया जा सकता है.
टैग: build_file_semantics, experimental
--[no]experimental_enable_android_migration_apis default: "false": इस नीति को 'सही है' पर सेट करने से, Android Starlark माइग्रेशन के लिए ज़रूरी एपीआई चालू हो जाते हैं.
टैग: build_file_semantics
--[no]experimental_enable_first_class_macros default: "true": अगर इसे सही पर सेट किया जाता है, तो सिंबॉलिक मैक्रो तय करने के लिए `macro()` कंस्ट्रक्ट चालू हो जाता है.
टैग: build_file_semantics
--[no]experimental_enable_scl_dialect default: "true": अगर इसे सही पर सेट किया जाता है, तो load() स्टेटमेंट में .scl फ़ाइलों का इस्तेमाल किया जा सकता है.
टैग: build_file_semantics
--[no]experimental_enable_starlark_set default: "true": अगर यह सही है, तो Starlark में सेट किए गए डेटा टाइप और set() कंस्ट्रक्टर को चालू करें.
टैग: build_file_semantics, experimental
--[no]experimental_google_legacy_api default: "false": अगर इसे सही पर सेट किया जाता है, तो Google के लेगसी कोड से जुड़े Starlark build API के कई एक्सपेरिमेंटल कॉम्पोनेंट दिखते हैं.
टैग: loading_and_analysis, experimental
--[no]experimental_isolated_extension_usages default: "false": अगर यह सही है, तो <a href="https://bazel.build/rules/lib/globals/module#use_extension"><code>use_extension</code></a> फ़ंक्शन में<code>isolate</code> पैरामीटर चालू हो जाता है.
टैग: loading_and_analysis
--[no]experimental_java_library_export default: "false": अगर यह सुविधा चालू है, तो experimental_java_library_export_do_not_use मॉड्यूल उपलब्ध होता है.
टैग: loading_and_analysis, incompatible_change
--[no]experimental_platforms_api default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो प्लैटफ़ॉर्म से जुड़े कई Starlark API चालू हो जाते हैं. ये डीबग करने के लिए काम के होते हैं.
टैग: loading_and_analysis, experimental
--[no]experimental_repo_remote_exec default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो repository_rule को रिमोट एक्ज़ीक्यूशन की कुछ सुविधाएं मिलती हैं.
टैग: build_file_semantics, loading_and_analysis, experimental
--[no]experimental_repository_ctx_execute_wasm default: "false": अगर यह सही है, तो repository_ctx के `load_wasm` और `execute_wasm` तरीके चालू हो जाते हैं.
टैग: loading_and_analysis, experimental
--[no]experimental_sibling_repository_layout default: "false": अगर इसे सही पर सेट किया जाता है, तो मुख्य नहीं हैं उन रिपॉज़िटरी को एक्ज़ीक्यूशन रूट में मुख्य रिपॉज़िटरी के सिंबल लिंक के तौर पर प्लांट किया जाता है. इसका मतलब है कि सभी रिपॉज़िटरी, $output_base/execution_root डायरेक्ट्री की चाइल्ड डायरेक्ट्री होती हैं. इससे, $output_base/execution_root/__main__/external डायरेक्ट्री खाली हो जाती है, ताकि टॉप-लेवल की 'external' डायरेक्ट्री को बनाया जा सके.
टैग: action_command_lines, bazel_internal_configuration, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_single_package_toolchain_binding default: "false": इस सुविधा के चालू होने पर, register_toolchain फ़ंक्शन में ऐसे टारगेट पैटर्न शामिल नहीं हो सकते जो एक से ज़्यादा पैकेज को रेफ़र करते हों.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_allow_tags_propagation default: "true": अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो टैग को टारगेट से लेकर, कार्रवाइयों को पूरा करने की ज़रूरी शर्तों तक भेजा जाएगा. अगर ऐसा नहीं किया जाता है, तो टैग नहीं भेजे जाएंगे. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/8830 पर जाएं.
टैग: build_file_semantics, experimental
--[no]incompatible_always_check_depset_elements default: "true": सभी कंस्ट्रक्टर में, डिपसेट में जोड़े गए एलिमेंट की वैधता की जांच करें. तत्वों में बदलाव नहीं किया जा सकता. हालांकि, पहले depset(direct=...) कंस्ट्रक्टर इसकी जांच नहीं करता था. डिपसेट एलिमेंट में सूचियों के बजाय टपल का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10313 पर जाएं.
टैग: build_file_semantics, incompatible_change
--incompatible_autoload_externally=<comma-separated set of options> default: "+@rules_python,+java_common,+JavaInfo,+JavaPluginInfo,ProguardSpecProvider,java_binary,java_import,java_library,java_plugin,java_test,java_runtime,java_toolchain,java_package_configuration,@com_google_protobuf,@rules_shell,+@rules_android": यह नियमों (या अन्य सिंबल) की कॉमा-सेपरेटेड लिस्ट होती है. ये नियम पहले Bazel का हिस्सा थे और अब इन्हें अपनी-अपनी बाहरी रिपॉज़िटरी से वापस पाना है. इस फ़्लैग का इस्तेमाल, नियमों को Bazel से बाहर माइग्रेट करने के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/23043 पर भी जाएं. किसी फ़ाइल में अपने-आप लोड होने वाला सिंबल, इस तरह काम करता है जैसे Bazel में पहले से मौजूद उसकी परिभाषा को किसी बाहरी रिपॉज़िटरी में मौजूद उसकी नई कैननिकल परिभाषा से बदल दिया गया हो. BUILD फ़ाइल के लिए, इसका मतलब है कि load() स्टेटमेंट को परोक्ष रूप से जोड़ा गया है. .bzl फ़ाइल के लिए, यह load() स्टेटमेंट होता है या `native` ऑब्जेक्ट के फ़ील्ड में बदलाव होता है. यह इस बात पर निर्भर करता है कि अपने-आप लोड होने वाला सिंबल कोई नियम है या नहीं. Bazel, उन सभी सिंबल की एक हार्डकोड की गई सूची बनाए रखता है जिन्हें अपने-आप लोड किया जा सकता है. इस फ़्लैग में सिर्फ़ वे सिंबल दिख सकते हैं. Bazel को हर सिंबल के लिए, बाहरी रिपॉज़िटरी में नई परिभाषा की जगह के बारे में पता होता है. साथ ही, उसे उन रिपॉज़िटरी के बारे में भी पता होता है जिन्हें अपने-आप लोड नहीं करना चाहिए, ताकि साइकल न बन पाएं. इस फ़्लैग में "+foo" की सूची में मौजूद आइटम की वजह से, foo सिंबल अपने-आप लोड हो जाता है. हालांकि, foo की उन रिपॉज़िटरी में ऐसा नहीं होता जिनमें यह फ़्लैग लागू नहीं होता. इन रिपॉज़िटरी में, Bazel के तय किए गए foo का वर्शन अब भी उपलब्ध होता है. ऊपर दिए गए उदाहरण के मुताबिक, "foo" की सूची का आइटम अपने-आप लोड होने की सुविधा को ट्रिगर करता है. हालांकि, Bazel के तय किए गए foo के वर्शन को उन रिपॉज़िटरी के लिए उपलब्ध नहीं कराया जाता जिन्हें शामिल नहीं किया गया है. इससे यह पक्का होता है कि foo की बाहरी रिपॉज़िटरी, foo के Bazel के पुराने वर्शन पर निर्भर नहीं है "-foo" की सूची का कोई आइटम, अपने-आप लोड होने की सुविधा को ट्रिगर नहीं करता है. हालांकि, इससे Bazel के तय किए गए foo के वर्शन को पूरे वर्कस्पेस में ऐक्सेस नहीं किया जा सकता. इस कुकी का इस्तेमाल यह पुष्टि करने के लिए किया जाता है कि वर्कस्पेस, Bazel से foo की परिभाषा को मिटाने के लिए तैयार है. अगर इस फ़्लैग में किसी सिंबल का नाम नहीं दिया गया है, तो वह सामान्य तरीके से काम करता रहेगा. न तो अपने-आप लोड होने की सुविधा काम करेगी और न ही Bazel के तय किए गए वर्शन को छिपाया जाएगा. कॉन्फ़िगरेशन के लिए, https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/packages/AutoloadSymbols.java देखें. शॉर्टकट के तौर पर, पूरी रिपॉज़िटरी का भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, +@rules_python से सभी Python नियम अपने-आप लोड हो जाएंगे.
टैग: loses_incremental_state, build_file_semantics, incompatible_change
--[no]incompatible_depset_for_libraries_to_link_getter default: "true": इस विकल्प को सही पर सेट करने पर, Bazel, linking_context.libraries_to_link से सूची नहीं दिखाता है. इसके बजाय, यह एक depset दिखाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disable_autoloads_in_main_repo default: "false": यह विकल्प कंट्रोल करता है कि मुख्य रिपॉज़िटरी में, अपने-आप लोड होने वाली फ़ाइलें (इन्हें --incompatible_autoload_externally से सेट किया जाता है) चालू हैं या नहीं. इस सुविधा को चालू करने पर, Bazel में पहले से मौजूद नियमों (या अन्य सिंबल) में लोड स्टेटमेंट होने चाहिए. उन्हें जोड़ने के लिए, buildifier का इस्तेमाल करें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disable_objc_library_transition default: "true": objc_library के कस्टम ट्रांज़िशन को बंद करें और इसके बजाय, टॉप लेवल के टारगेट से इनहेरिट करें (Bazel में कोई कार्रवाई नहीं)
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_starlark_host_transitions default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो नियम एट्रिब्यूट 'cfg = "host"' सेट नहीं कर सकते. इसके बजाय, नियमों में 'cfg = "exec"' सेट किया जाना चाहिए.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disable_target_default_provider_fields default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स के ज़रिए 'टारगेट' ऑब्जेक्ट पर मौजूद प्रोवाइडर को ऐक्सेस करने की सुविधा बंद हो जाती है. इसके बजाय, provider-key सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, नियम लागू करने वाले फ़ंक्शन के अंदर से `my_info` को ऐक्सेस करने के लिए, `ctx.attr.dep.my_info` का इस्तेमाल करने के बजाय, `ctx.attr.dep[MyInfo]` का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/9014 देखें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_target_provider_fields default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स के ज़रिए डिफ़ॉल्ट प्रोवाइडर का इस्तेमाल करने की सुविधा बंद हो जाती है. इसके बजाय, provider-key सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, `files` को ऐक्सेस करने के लिए `ctx.attr.dep.files` का इस्तेमाल करने के बजाय, `ctx.attr.dep[DefaultInfo].files का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/9014 पर जाएं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disallow_ctx_resolve_tools default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो डेप्रिकेट किए गए ctx.resolve_tools API को कॉल करने पर हमेशा गड़बड़ी होती है. इस एपीआई के इस्तेमाल को, ctx.actions.run या ctx.actions.run_shell के लिए, एक्ज़ीक्यूटेबल या टूल आर्ग्युमेंट से बदला जाना चाहिए.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_empty_glob default: "true": If set to true, the default value of the `allow_empty` argument of glob() is False.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disallow_struct_provider_syntax default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो नियम लागू करने वाले फ़ंक्शन, स्ट्रक्चर नहीं दिखा सकते. इसके बजाय, उन्हें सेवा देने वाली कंपनियों के इंस्टेंस की सूची दिखानी चाहिए.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_enable_deprecated_label_apis default: "true": अगर यह सेटिंग चालू है, तो हटाए जा चुके कुछ एपीआई (native.repository_name, Label.workspace_name, Label.relative) का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis
--[no]incompatible_fail_on_unknown_attributes default: "true": अगर यह सुविधा चालू है, तो उन टारगेट को मंज़ूरी नहीं मिलती जिनके लिए 'कोई नहीं' पर सेट किए गए एट्रिब्यूट की वैल्यू 'पता नहीं' है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_fix_package_group_reporoot_syntax default: "true": package_group एट्रिब्यूट के `packages` एट्रिब्यूट में, "//..." वैल्यू का मतलब बदल जाता है. अब यह वैल्यू, किसी भी रिपॉज़िटरी के सभी पैकेज के बजाय, मौजूदा रिपॉज़िटरी के सभी पैकेज को रेफ़र करती है. पुराने तरीके से काम करने के लिए, "//..." की जगह "public" वैल्यू का इस्तेमाल किया जा सकता है. इस फ़्लैग के लिए, --incompatible_package_group_has_public_syntax फ़्लैग भी चालू होना चाहिए.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_java_common_parameters default: "true": अगर इस फ़्लैग को सही पर सेट किया जाता है, तो pack_sources और host_javabase में मौजूद output_jar और compile में मौजूद host_javabase पैरामीटर हटा दिए जाएंगे.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_locations_prefers_executable default: "true": अगर फ़ाइलों की संख्या एक से ज़्यादा है, तो क्या एक्ज़ीक्यूटेबल उपलब्ध कराने वाला टारगेट, $(locations ...) एक्सपैंशन के तहत <code>DefaultInfo.files</code> में मौजूद फ़ाइलों के बजाय एक्ज़ीक्यूटेबल में बदल जाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_merge_fixed_and_default_shell_env default: "true": अगर यह विकल्प चालू है, तो ctx.actions.run और ctx.actions.run_shell के साथ रजिस्टर किए गए ऐसे ऐक्शन जिनमें 'env' और 'use_default_shell_env = True' दोनों को सेट किया गया है वे डिफ़ॉल्ट शेल एनवायरमेंट से मिले एनवायरमेंट का इस्तेमाल करेंगे. इसके लिए, 'env' में पास की गई वैल्यू को बदला जाएगा. अगर यह सुविधा बंद है, तो इस मामले में 'env' की वैल्यू को पूरी तरह से अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_no_attr_license default: "true": इस वैल्यू को सही पर सेट करने से, `attr.license` फ़ंक्शन बंद हो जाता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_no_implicit_file_export default: "false": अगर इसे सेट किया जाता है, तो इस्तेमाल की गई सोर्स फ़ाइलें पैकेज के लिए निजी होती हैं. हालांकि, इन्हें साफ़ तौर पर एक्सपोर्ट किया जा सकता है. https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-24-file-visibility.md पर जाएं
टैग: build_file_semantics, incompatible_change
--[no]incompatible_no_implicit_watch_label default: "true": अगर यह वैल्यू सही है, तो <code>repository_ctx</code> पर मौजूद ऐसे तरीके जो लेबल पास करते हैं वे उस लेबल के तहत मौजूद फ़ाइल में होने वाले बदलावों को अपने-आप ट्रैक नहीं करेंगे. भले ही, <code>watch = "no"</code> हो. साथ ही, <code>repository_ctx.path</code> की वजह से, लौटाए गए पाथ को ट्रैक नहीं किया जाएगा. इसके बजाय, <code>repository_ctx.watch</code> का इस्तेमाल करें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_no_rule_outputs_param default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो यह `rule()` Starlark फ़ंक्शन के `outputs` पैरामीटर को बंद कर देता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_package_group_has_public_syntax default: "true": package_group एट्रिब्यूट के `packages` एट्रिब्यूट में, "public" या "private" वैल्यू लिखने की अनुमति देता है. इससे सभी पैकेज या कोई भी पैकेज नहीं चुना जाता.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_require_linker_input_cc_api default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो create_linking_context नियम के लिए, libraries_to_link के बजाय linker_inputs की ज़रूरत होगी. linking_context के पुराने गेटर भी बंद हो जाएंगे. सिर्फ़ linker_inputs उपलब्ध होंगे.
टैग: build_file_semantics, loading_and_analysis, incompatible_change
--[no]incompatible_run_shell_command_string default: "true": अगर इसे सही पर सेट किया जाता है, तो actions.run_shell का कमांड पैरामीटर सिर्फ़ स्ट्रिंग स्वीकार करेगा
टैग: build_file_semantics, incompatible_change
--[no]incompatible_simplify_unconditional_selects_in_rule_attrs default: "true": अगर यह वैल्यू सही है, तो कॉन्फ़िगर किए जा सकने वाले नियम एट्रिब्यूट को आसान बनाएं. इनमें सिर्फ़ बिना शर्त वाले विकल्प शामिल होते हैं. उदाहरण के लिए, अगर किसी नियम एट्रिब्यूट को ["a"] + select("//conditions:default", ["b"]) असाइन किया जाता है, तो इसे ["a", "b"] के तौर पर सेव किया जाता है. इस विकल्प से, सिंबॉलिक मैक्रो या एट्रिब्यूट की डिफ़ॉल्ट वैल्यू के एट्रिब्यूट पर कोई असर नहीं पड़ता.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_stop_exporting_build_file_path default: "false": अगर इस नीति को 'सही है' पर सेट किया जाता है, तो ctx.build_file_path का इस्तेमाल नहीं किया जा सकेगा. इसके बजाय, ctx.label.package + '/BUILD' का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_stop_exporting_language_modules default: "false": अगर यह सुविधा चालू है, तो भाषा के हिसाब से कुछ मॉड्यूल (जैसे कि `cc_common`) उपयोगकर्ता की .bzl फ़ाइलों में उपलब्ध नहीं होते. इन्हें सिर्फ़ इनसे जुड़े नियमों की रिपॉज़िटरी से कॉल किया जा सकता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_top_level_aspects_require_providers default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो टॉप लेवल का आसपेक्ट, सेवा देने वाली ज़रूरी कंपनियों की शर्तों का पालन करेगा. साथ ही, यह सिर्फ़ उन टॉप लेवल के टारगेट पर चलेगा जिनके नियमों में, सेवा देने वाली ज़रूरी कंपनियों के तौर पर विज्ञापन दिखाने वाली कंपनियां, आसपेक्ट की ज़रूरी कंपनियों की शर्तों को पूरा करती हैं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_unambiguous_label_stringification default: "true": इस विकल्प को सही पर सेट करने पर, Bazel, @//foo:bar लेबल को @//foo:bar के तौर पर स्ट्रिंग में बदल देगा. ऐसा //foo:bar के बजाय किया जाएगा. इससे सिर्फ़ str(), % ऑपरेटर वगैरह के व्यवहार पर असर पड़ता है. repr() के व्यवहार में कोई बदलाव नहीं होता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15916 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_cc_configure_from_rules_cc default: "false": इस विकल्प को सही पर सेट करने पर, Bazel @bazel_tools से cc_configure का इस्तेमाल करने की अनुमति नहीं देगा. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, कृपया https://github.com/bazelbuild/bazel/issues/10134 देखें.
टैग: loading_and_analysis, incompatible_change
--max_computation_steps=<a long integer> default: "0": BUILD फ़ाइल से, Starlark के ज़्यादा से ज़्यादा कितने कंप्यूटेशन चरण पूरे किए जा सकते हैं. शून्य का मतलब है कि कोई सीमा नहीं है.
टैग: build_file_semantics
--nested_set_depth_limit=<an integer> डिफ़ॉल्ट: "3500": यह depset (इसे NestedSet भी कहा जाता है) के अंदर मौजूद ग्राफ़ की ज़्यादा से ज़्यादा डेप्थ होती है. इससे ज़्यादा डेप्थ होने पर, depset() कंस्ट्रक्टर काम नहीं करेगा.
टैग: loading_and_analysis
--repositories_without_autoloads=<comma-separated set of options> default: "": अतिरिक्त रिपॉज़िटरी की सूची (Bazel को पहले से पता है कि किन रिपॉज़िटरी में ऑटोलोड नहीं जोड़े जाने हैं). इसमें आम तौर पर ऐसी रिपॉज़िटरी शामिल होनी चाहिए जिन पर किसी ऐसी रिपॉज़िटरी की निर्भरता हो जो अपने-आप लोड हो सकती है. इससे एक साइकल बन सकता है.
टैग: loses_incremental_state, build_file_semantics, incompatible_change

--allow_yanked_versions=<a string> कई बार इस्तेमाल किया गया हो: मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के फ़ॉर्मैट में तय किया गया है. इन्हें हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल करने की अनुमति होगी. भले ही, इन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से ये आते हैं (अगर ये NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल का इस्तेमाल करके, हटाए गए वर्शन को भी अनुमति दी जा सकती है. 'all' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, ऐसा करने का सुझाव नहीं दिया जाता.
टैग: loading_and_analysis
--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error": Bazel मॉड्यूल के Bazel वर्शन के साथ काम करने की क्षमता की जांच करें. मान्य वैल्यू ये हैं: `error` का इस्तेमाल करके, समस्या को हल न होने की स्थिति में बढ़ाएं, `off` का इस्तेमाल करके जांच बंद करें या `warning` का इस्तेमाल करके, मेल न खाने पर चेतावनी प्रिंट करें.
टैग: loading_and_analysis
--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "warning": जांच करें कि रूट मॉड्यूल में सीधे तौर पर डिक्लेयर की गई `bazel_dep` डिपेंडेंसी, हल किए गए डिपेंडेंसी ग्राफ़ में मौजूद डिपेंडेंसी के वर्शन से मेल खाती हैं या नहीं. इसकी मान्य वैल्यू ये हैं: `off` का इस्तेमाल जांच बंद करने के लिए किया जाता है, `warning` का इस्तेमाल वैल्यू के मेल न खाने पर चेतावनी दिखाने के लिए किया जाता है या `error` का इस्तेमाल समस्या को हल न कर पाने की स्थिति में बढ़ाने के लिए किया जाता है.
टैग: loading_and_analysis
--[no]ignore_dev_dependency default: "false": अगर इसे सही पर सेट किया जाता है, तो Bazel, रूट मॉड्यूल के MODULE.bazel फ़ाइल में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर यह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपमेंट डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग: loading_and_analysis
--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल को इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है. `refresh` का इस्तेमाल, समय-समय पर रिमोट रजिस्ट्री से बदलाव की जा सकने वाली जानकारी (हटाए गए वर्शन और पहले से मौजूद नहीं मॉड्यूल) को रीफ़्रेश करने के लिए किया जाता है. `error` का इस्तेमाल, लॉकफ़ाइल का इस्तेमाल करने के लिए किया जाता है. हालांकि, अगर यह अप-टू-डेट नहीं है, तो एक गड़बड़ी दिखेगी. `off` का इस्तेमाल, लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए किया जाता है.
टैग: loading_and_analysis
--override_module=<an equals-separated mapping of module name to path> कई बार इस्तेमाल किया गया हो: <मॉड्यूल का नाम>=<पाथ> के फ़ॉर्मैट में, लोकल पाथ का इस्तेमाल करके किसी मॉड्यूल को बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल उसी तरह किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पिछले सभी ओवरराइड हटा दें.
--registry=<a string> कई बार इस्तेमाल किया गया हो: Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए इस्तेमाल की जाने वाली रजिस्ट्री के बारे में बताता है. मॉड्यूल के क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल को सबसे पहले पुरानी रजिस्ट्री में खोजा जाएगा. अगर वे पुरानी रजिस्ट्री में नहीं मिलते हैं, तो उन्हें नई रजिस्ट्री में खोजा जाएगा.
टैग: changes_inputs
--vendor_dir=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह उस डायरेक्ट्री के बारे में बताता है जिसमें वेंडर मोड में बाहरी रिपॉज़िटरी होनी चाहिए. ऐसा इसलिए, ताकि उन्हें फ़ेच किया जा सके या उन्हें बनाने के दौरान इस्तेमाल किया जा सके. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर तय किया जा सकता है.
टैग: loading_and_analysis

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> default: "1s:2,20s:3,1m:5": ये सीमाएं तय करती हैं कि अगर इन तक पहुंचा जाता है, तो GcThrashingDetector, Bazel को OOM के साथ क्रैश कर देगा. हर सीमा को <period>:<count> के तौर पर तय किया जाता है. इसमें अवधि, समयावधि होती है और गिनती, पॉज़िटिव पूर्णांक होता है. अगर <period> में लगातार <count> बार फ़ुल जीसी होने के बाद भी, पुराने जनरेशन के हीप का --gc_thrashing_threshold प्रतिशत से ज़्यादा हिस्सा इस्तेमाल किया जाता है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--[no]heuristically_drop_nodes default: "false": अगर यह वैल्यू सही है, तो Blaze, FileState और DirectoryListingState नोड को हटा देगा. ऐसा तब होगा, जब File और DirectoryListing नोड से जुड़ी प्रोसेस पूरी हो जाएगी. इससे मेमोरी को सेव किया जा सकेगा. हमें उम्मीद है कि इन नोड की ज़रूरत दोबारा नहीं पड़ेगी. अगर ऐसा होता है, तो प्रोग्राम उनकी फिर से समीक्षा करेगा.
टैग: loses_incremental_state
--[no]incompatible_do_not_split_linking_cmdline default: "true": इस विकल्प को सही पर सेट करने पर, Bazel लिंकिंग के लिए इस्तेमाल किए गए कमांड लाइन फ़्लैग में बदलाव नहीं करता. साथ ही, यह भी तय नहीं करता कि कौनसे फ़्लैग पैरामीटर फ़ाइल में जाएंगे और कौनसे नहीं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7670 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]keep_state_after_build default: "true": अगर यह वैल्यू गलत है, तो बिल्ड पूरा होने पर Blaze, इस बिल्ड की इनमेमोरी स्थिति को खारिज कर देगा. इसके बाद के बिल्ड में, इस बिल्ड के मुकाबले कोई बढ़ोतरी नहीं होगी.
टैग: loses_incremental_state
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> default: "10": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल GC इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट वैल्यू 10 होती है. शून्य का मतलब है कि फ़ुल जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति को अब नहीं हटाया जाएगा. साथ ही, बनाए रखी गई ढेर मेमोरी के थ्रेशोल्ड का प्रतिशत भी इससे ज़्यादा नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> default: "10": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट वैल्यू 10 होती है. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> default: "85": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि इस्तेमाल किया गया हीप का प्रतिशत, कम से कम इस थ्रेशोल्ड पर है, तो वह Skyframe की गैर-ज़रूरी अस्थायी स्थिति को हटा देगा. इसमें बदलाव करने से, GC थ्रैशिंग की वजह से लगने वाले समय पर असर पड़ सकता है. ऐसा तब होता है, जब GC थ्रैशिंग (i) इस अस्थायी स्थिति में मेमोरी के इस्तेमाल की वजह से होती है और (ii) जब इसकी ज़रूरत होती है, तब स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations
--[no]track_incremental_state default: "true": अगर यह वैल्यू 'गलत' पर सेट है, तो Blaze ऐसे डेटा को सेव नहीं करेगा जिससे इंक्रीमेंटल बिल्ड पर अमान्य होने और फिर से आकलन करने की अनुमति मिलती है. ऐसा इसलिए किया जाता है, ताकि इस बिल्ड पर मेमोरी सेव की जा सके. इसके बाद के बिल्ड में, इस बिल्ड के मुकाबले कोई बढ़ोतरी नहीं होगी. आम तौर पर, इस विकल्प को false पर सेट करते समय --batch को सेट करना होता है.
टैग: loses_incremental_state

--[no]announce_rc default: "false": rc विकल्पों के बारे में सूचना देनी है या नहीं.
टैग: affects_outputs
--[no]attempt_to_print_relative_paths default: "false": मैसेज के लोकेशन वाले हिस्से को प्रिंट करते समय, वर्कस्पेस डायरेक्ट्री या --package_path से तय की गई डायरेक्ट्री में से किसी एक के हिसाब से पाथ का इस्तेमाल करने की कोशिश करें.
टैग: terminal_output
--bes_backend=<a string> default: "": यह [SCHEME://]HOST[:PORT] के फ़ॉर्मैट में, बिल्ड इवेंट सर्विस (बीईएस) के बैकएंड एंडपॉइंट के बारे में बताता है. डिफ़ॉल्ट रूप से, BES पर अपलोड करने की सुविधा बंद होती है. grpc और grpcs (टीएलएस की सुविधा के साथ grpc) स्कीम का इस्तेमाल किया जा सकता है. अगर कोई स्कीम नहीं दी जाती है, तो Bazel, grpcs को डिफ़ॉल्ट स्कीम मानता है.
टैग: affects_outputs
--[no]bes_check_preceding_lifecycle_events default: "false": यह PublishBuildToolEventStreamRequest पर check_preceding_lifecycle_events_present फ़ील्ड सेट करता है. इससे BES को यह पता चलता है कि उसे मौजूदा टूल इवेंट से मैच करने वाले InvocationAttemptStarted और BuildEnqueued इवेंट पहले मिले थे या नहीं.
टैग: affects_outputs
--bes_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: NAME=VALUE फ़ॉर्म में एक हेडर तय करें, जिसे BES अनुरोधों में शामिल किया जाएगा. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
टैग: affects_outputs
--bes_instance_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह उस इंस्टेंस का नाम बताता है जिसके तहत BES, अपलोड किए गए BEP को सेव करेगा. डिफ़ॉल्ट रूप से, यह शून्य पर सेट होती है.
टैग: affects_outputs
--bes_keywords=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: यह सूचना वाले कीवर्ड की एक सूची तय करता है. इन कीवर्ड को BES में पब्लिश किए गए कीवर्ड के डिफ़ॉल्ट सेट में जोड़ा जाता है ("command_name=<command_name> ", "protocol_name=BEP"). डिफ़ॉल्ट रूप से, इसकी वैल्यू 'कोई नहीं' होती है.
टैग: affects_outputs
--[no]bes_lifecycle_events default: "true": इससे पता चलता है कि BES के लाइफ़साइकल इवेंट पब्लिश करने हैं या नहीं. (डिफ़ॉल्ट रूप से 'true' पर सेट होता है).
टैग: affects_outputs
--bes_oom_finish_upload_timeout=<An immutable length of time.> default: "10m": इससे यह तय होता है कि मेमोरी खत्म होने पर, BES/BEP के अपलोड होने का इंतज़ार Bazel को कितनी देर तक करना चाहिए. यह फ़्लैग यह पक्का करता है कि जब JVM में GC थ्रैशिंग की समस्या हो और वह किसी भी उपयोगकर्ता थ्रेड पर काम न कर पाए, तो उसे बंद कर दिया जाए.
टैग: bazel_monitoring
--bes_outerr_buffer_size=<an integer> default: "10240": यह बीईपी में stdout या stderr के ज़्यादा से ज़्यादा साइज़ के बारे में बताता है. इससे पहले कि इसे प्रोग्रेस इवेंट के तौर पर रिपोर्ट किया जाए, इसे बफ़र किया जाता है. अलग-अलग राइट अब भी एक ही इवेंट में रिपोर्ट किए जाते हैं. भले ही, वे --bes_outerr_chunk_size तक तय की गई वैल्यू से ज़्यादा हों.
टैग: affects_outputs
--bes_outerr_chunk_size=<an integer> default: "1048576": इस विकल्प से, stdout या stderr का ज़्यादा से ज़्यादा साइज़ तय किया जाता है. यह साइज़, बीईपी को भेजे जाने वाले एक मैसेज के लिए होता है.
टैग: affects_outputs
--bes_proxy=<a string> डिफ़ॉल्ट: ब्यौरा देखें: प्रॉक्सी के ज़रिए Build Event Service से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--bes_results_url=<a string> default: "": यह उस बेस यूआरएल के बारे में बताता है जहां उपयोगकर्ता, BES बैकएंड पर स्ट्रीम की गई जानकारी देख सकता है. Bazel, टर्मिनल पर यूआरएल को इनवॉकेशन आईडी के साथ जोड़कर आउटपुट करेगा.
टैग: terminal_output
--bes_system_keywords=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: यह सूचना से जुड़े कीवर्ड की एक सूची तय करता है. इन्हें सीधे तौर पर शामिल किया जाता है. इनमें "user_keyword=" प्रीफ़िक्स शामिल नहीं होता. यह प्रीफ़िक्स, --bes_keywords के ज़रिए दिए गए कीवर्ड के लिए शामिल किया जाता है. यह बिल्ड सेवा के उन ऑपरेटर के लिए है जो --bes_lifecycle_events=false सेट करते हैं और PublishLifecycleEvent को कॉल करते समय कीवर्ड शामिल करते हैं. इस फ़्लैग का इस्तेमाल करके, सेवा ऑपरेटरों को यह पक्का करना चाहिए कि उपयोगकर्ता, फ़्लैग की वैल्यू को न बदल पाएं.
टैग: affects_outputs
--bes_timeout=<An immutable length of time.> default: "0s": इससे यह तय होता है कि बिल्ड और टेस्ट पूरे होने के बाद, Bazel को BES/BEP अपलोड होने का कितना इंतज़ार करना चाहिए. मान्य टाइम आउट, एक ऐसी पूर्णांक संख्या होती है जिसके बाद यूनिट होती है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). डिफ़ॉल्ट वैल्यू '0' होती है. इसका मतलब है कि कोई टाइम आउट नहीं है.
टैग: affects_outputs
--bes_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete": इससे यह तय होता है कि Build Event Service के अपलोड होने तक बिल्ड पूरा होने की प्रोसेस को रोका जाए या बिल्ड को तुरंत बंद कर दिया जाए और अपलोड की प्रोसेस बैकग्राउंड में पूरी हो. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit
--build_event_binary_file=<a string> default: "": अगर यह फ़ाइल खाली नहीं है, तो इसमें बिल्ड इवेंट प्रोटोकॉल का varint डेलिमिटेड बाइनरी फ़ॉर्मैट लिखें. इस विकल्प का मतलब है --bes_upload_mode=wait_for_upload_complete.
टैग: affects_outputs
--[no]build_event_binary_file_path_conversion default: "true": बिल्ड इवेंट प्रोटोकॉल के बाइनरी फ़ाइल फ़ॉर्मैट में मौजूद पाथ को, जब भी हो सके, ज़्यादा मान्य यूआरआई में बदलें. अगर यह सुविधा बंद है, तो हमेशा file:// यूआरआई स्कीम का इस्तेमाल किया जाएगा
टैग: affects_outputs
--build_event_binary_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete": इससे यह तय होता है कि --build_event_binary_file के लिए Build Event Service का अपलोड, बिल्ड पूरा होने को ब्लॉक करेगा या इनवोकेशन को तुरंत खत्म कर देगा और बैकग्राउंड में अपलोड पूरा करेगा. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit
--build_event_json_file=<a string> default: "": अगर यह फ़ाइल खाली नहीं है, तो इसमें बिल्ड इवेंट प्रोटोकॉल का JSON सीरियललाइज़ेशन लिखें. इस विकल्प का मतलब है --bes_upload_mode=wait_for_upload_complete.
टैग: affects_outputs
--[no]build_event_json_file_path_conversion default: "true": जब भी हो सके, बिल्ड इवेंट प्रोटोकॉल के json फ़ाइल फ़ॉर्मैट में मौजूद पाथ को ज़्यादा मान्य यूआरआई में बदलें. अगर यह सुविधा बंद है, तो हमेशा file:// uri स्कीम का इस्तेमाल किया जाएगा
टैग: affects_outputs
--build_event_json_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete": इससे यह तय होता है कि --build_event_json_file के लिए, Build Event Service का अपलोड, बिल्ड पूरा होने पर ब्लॉक होना चाहिए या इनवोकेशन को तुरंत खत्म कर देना चाहिए और बैकग्राउंड में अपलोड पूरा करना चाहिए. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit
--build_event_max_named_set_of_file_entries=<an integer> default: "5000": named_set_of_files इवेंट के लिए, ज़्यादा से ज़्यादा एंट्री की संख्या. दो से कम वैल्यू को अनदेखा कर दिया जाता है और इवेंट को स्प्लिट नहीं किया जाता. इसका इस्तेमाल, बिल्ड इवेंट प्रोटोकॉल में इवेंट के साइज़ को सीमित करने के लिए किया जाता है. हालांकि, यह सीधे तौर पर इवेंट के साइज़ को कंट्रोल नहीं करता है. इवेंट का कुल साइज़, सेट के स्ट्रक्चर के साथ-साथ फ़ाइल और यूआरआई की लंबाई पर निर्भर करता है. यह हैश फ़ंक्शन पर भी निर्भर कर सकता है.
टैग: affects_outputs
--[no]build_event_publish_all_actions default: "false": क्या सभी कार्रवाइयों को पब्लिश किया जाना चाहिए.
टैग: affects_outputs
--build_event_text_file=<a string> default: "": If non-empty, write a textual representation of the build event protocol to that file
टैग: affects_outputs
--[no]build_event_text_file_path_conversion default: "true": बिल्ड इवेंट प्रोटोकॉल की टेक्स्ट फ़ाइल में मौजूद पाथ को, ज़्यादा से ज़्यादा मान्य यूआरआई में बदलें. अगर यह सुविधा बंद है, तो हमेशा file:// यूआरआई स्कीम का इस्तेमाल किया जाएगा
टैग: affects_outputs
--build_event_text_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete": इससे यह तय होता है कि --build_event_text_file के लिए Build Event Service का अपलोड, बिल्ड पूरा होने को ब्लॉक करेगा या इनवोकेशन को तुरंत खत्म कर देगा और बैकग्राउंड में अपलोड पूरा करेगा. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit
--build_event_upload_max_retries=<an integer> default: "4": Bazel को बिल्ड इवेंट अपलोड करने की कोशिश ज़्यादा से ज़्यादा कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration
--[no]experimental_bep_target_summary default: "false": TargetSummary इवेंट पब्लिश करने हैं या नहीं.
--[no]experimental_build_event_expand_filesets default: "false": अगर यह वैल्यू सही है, तो आउटपुट फ़ाइलें दिखाते समय बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks default: "false": अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में Fileset के सभी रिलेटिव सिंबल लिंक पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets विकल्प ज़रूरी है.
टैग: affects_outputs
--experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both> कई बार इस्तेमाल किया गया हो: यह तय करें कि TargetComplete/AspectComplete BEP इवेंट में, आउटपुट ग्रुप की फ़ाइलें कैसे दिखाई जाएंगी. वैल्यू, आउटपुट ग्रुप के नाम को 'NAMED_SET_OF_FILES_ONLY', 'INLINE_ONLY' या 'BOTH' में से किसी एक को असाइन की जाती है. डिफ़ॉल्ट वैल्यू 'NAMED_SET_OF_FILES_ONLY' होती है. अगर किसी आउटपुट ग्रुप को दोहराया जाता है, तो दिखने वाली फ़ाइनल वैल्यू का इस्तेमाल किया जाता है. डिफ़ॉल्ट वैल्यू, कवरेज आर्टफ़ैक्ट के लिए मोड को BOTH पर सेट करती है: --experimental_build_event_output_group_mode=baseline.lcov=both
टैग: affects_outputs
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> default: "1s": बीईपी अपलोड न होने पर, एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने के लिए, शुरुआती और कम से कम देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इससे यह चुना जाता है कि बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को कैसे अपलोड करना है.
टैग: affects_outputs
--[no]experimental_collect_load_average_in_profiler default: "true": इस विकल्प के चालू होने पर, प्रोफ़ाइलर सिस्टम के कुल लोड का औसत इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_pressure_stall_indicators default: "false": अगर यह विकल्प चालू है, तो प्रोफ़ाइलर, Linux PSI डेटा इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_resource_estimation default: "false": अगर यह सेटिंग चालू है, तो प्रोफ़ाइलर, स्थानीय कार्रवाइयों के लिए सीपीयू और मेमोरी के इस्तेमाल का अनुमान इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_skyframe_counts_in_profiler default: "false": अगर यह सुविधा चालू है, तो प्रोफ़ाइलर, Skyframe ग्राफ़ में समय के साथ SkyFunction की संख्या इकट्ठा करता है. यह संख्या, मुख्य फ़ंक्शन टाइप के लिए होती है. जैसे, कॉन्फ़िगर किए गए टारगेट और कार्रवाइयों को पूरा करना. इससे परफ़ॉर्मेंस पर असर पड़ सकता है, क्योंकि यह हर प्रोफ़ाइलिंग टाइम यूनिट पर पूरे Skyframe ग्राफ़ पर जाता है. परफ़ॉर्मेंस के लिए ज़रूरी मेज़रमेंट के साथ इस फ़्लैग का इस्तेमाल न करें.
टैग: bazel_monitoring
--[no]experimental_collect_system_network_usage default: "true": अगर यह सुविधा चालू है, तो प्रोफ़ाइलर, सिस्टम के नेटवर्क इस्तेमाल की जानकारी इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_worker_data_in_profiler default: "false": अगर यह सुविधा चालू है, तो प्रोफ़ाइलर, वर्कर के संसाधन का इकट्ठा किया गया डेटा इकट्ठा करता है.
टैग: bazel_monitoring
--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: ब्यौरा देखें: यह कुकी, कमांड की अवधि के लिए Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करती है. प्रोफ़ाइलिंग के लिए इस्तेमाल किए जा सकने वाले इवेंट टाइप (cpu, wall, alloc या lock) में से किसी एक को आर्ग्युमेंट के तौर पर दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम वाली फ़ाइल में लिखा जाता है. ज़्यादा प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, आने वाले समय में इस फ़्लैग के सिंटैक्स और सिमैंटिक में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--experimental_profile_additional_tasks=<phase, action, discover_inputs, action_check, action_lock, action_update, action_complete, action_rewinding, bzlmod, info, create_package, remote_execution, local_execution, scanner, local_parse, upload_time, remote_process_time, remote_queue, remote_setup, fetch, local_process_time, vfs_stat, vfs_dir, vfs_readlink, vfs_md5, vfs_xattr, vfs_delete, vfs_open, vfs_read, vfs_write, vfs_glob, vfs_vmfs_stat, vfs_vmfs_dir, vfs_vmfs_read, wait, thread_name, thread_sort_index, skyframe_eval, skyfunction, critical_path, critical_path_component, handle_gc_notification, local_action_counts, starlark_parser, starlark_user_fn, starlark_builtin_fn, starlark_user_compiled_fn, starlark_repository_fn, action_fs_staging, remote_cache_check, remote_download, remote_network, filesystem_traversal, worker_execution, worker_setup, worker_borrow, worker_working, worker_copying_outputs, credential_helper, conflict_check, dynamic_lock, repository_fetch, repository_vendor, repo_cache_gc_wait, spawn_log, wasm_load, wasm_exec or unknown> कई बार इस्तेमाल किया गया हो: इस विकल्प का इस्तेमाल करके, प्रोफ़ाइल में शामिल करने के लिए अन्य प्रोफ़ाइल टास्क तय किए जाते हैं.
टैग: bazel_monitoring
--[no]experimental_profile_include_primary_output default: "false": इसमें कार्रवाई वाले इवेंट में "out" एट्रिब्यूट शामिल होता है. इसमें कार्रवाई के मुख्य आउटपुट का एक्ज़ेक पाथ होता है.
टैग: bazel_monitoring
--[no]experimental_profile_include_target_configuration default: "false": इसमें कार्रवाई वाले इवेंट के JSON प्रोफ़ाइल डेटा में, टारगेट कॉन्फ़िगरेशन हैश शामिल होता है.
टैग: bazel_monitoring
--[no]experimental_profile_include_target_label default: "false": इसमें कार्रवाई वाले इवेंट के JSON प्रोफ़ाइल डेटा में टारगेट लेबल शामिल होता है.
टैग: bazel_monitoring
--[no]experimental_record_metrics_for_all_mnemonics default: "false": यह BEP ActionSummary और BuildGraphMetrics के आउटपुट को कंट्रोल करता है. साथ ही, ActionData में मौजूद निमोनिक की संख्या और BuildGraphMetrics.AspectCount/RuleClassCount में रिपोर्ट की गई एंट्री की संख्या को सीमित करता है. डिफ़ॉल्ट रूप से, टाइप की संख्या को टॉप 20 तक सीमित किया जाता है. यह संख्या, ActionData के लिए की गई कार्रवाइयों की संख्या और RuleClass और Asepcts के लिए इंस्टेंस की संख्या के हिसाब से तय की जाती है. इस विकल्प को सेट करने पर, सभी नेमोनिक, नियम क्लास, और पहलुओं के लिए आंकड़े लिखे जाएंगे.
--[no]experimental_record_skyframe_metrics default: "false": यह फ़्लैग, BEP BuildGraphMetrics के आउटपुट को कंट्रोल करता है. इसमें Skykeys, RuleClasses, और Aspects के बारे में Skyframe मेट्रिक को कंप्यूट करने में लगने वाला समय शामिल है. इस फ़्लैग को फ़ॉल्स पर सेट करने पर, BEP में BuildGraphMetrics.rule_count और aspectfields नहीं भरे जाएंगे.
--[no]experimental_run_bep_event_include_residue default: "false": क्या रन बिल्ड इवेंट में कमांड-लाइन के बचे हुए हिस्से को शामिल करना है. इसमें बचा हुआ हिस्सा शामिल हो सकता है. डिफ़ॉल्ट रूप से, रन कमांड के बिल्ड इवेंट में रेज़िड्यू शामिल नहीं होता. हालांकि, इसमें रेज़िड्यू शामिल हो सकता है.
टैग: affects_outputs
--[no]experimental_stream_log_file_uploads default: "false": स्ट्रीम लॉग फ़ाइलें, डिस्क पर लिखने के बजाय सीधे रिमोट स्टोरेज पर अपलोड करता है.
टैग: affects_outputs
--experimental_workspace_rules_log_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Workspace के कुछ नियमों से जुड़े इवेंट को इस फ़ाइल में, WorkspaceEvent protos के तौर पर लॉग करें.
--[no]generate_json_trace_profile default: "auto": इस विकल्प को चालू करने पर, Bazel बिल्ड की प्रोफ़ाइल बनाता है और आउटपुट बेस में मौजूद किसी फ़ाइल में JSON फ़ॉर्मैट वाली प्रोफ़ाइल लिखता है. chrome://tracing में लोड करके प्रोफ़ाइल देखें. डिफ़ॉल्ट रूप से, Bazel, बिल्ड जैसी सभी कमांड और क्वेरी के लिए प्रोफ़ाइल लिखता है.
टैग: bazel_monitoring
--[no]heap_dump_on_oom default: "false": अगर ओओएम की समस्या आती है, तो क्या हीप डंप को मैन्युअल तरीके से आउटपुट करना है. इसमें --gc_thrashing_limits तक पहुंचने की वजह से होने वाले मैन्युअल ओओएम भी शामिल हैं. डंप को <output_base>/<invocation_id>.heapdump.hprof में लिखा जाएगा. यह विकल्प, -XX:+HeapDumpOnOutOfMemoryError को बदल देता है. हालांकि, मैन्युअल OOM के लिए इसका कोई असर नहीं होता.
टैग: bazel_monitoring
--jvm_heap_histogram_internal_object_pattern=<a valid Java regular expression> डिफ़ॉल्ट: "jdk\.internal\.vm\.Filler.+": JDK21+ JVM हीप मेमोरी कलेक्शन के लिए, मैचिंग लॉजिक को बदलने के लिए रेगुलर एक्सप्रेशन. हम मेमोरी के इस्तेमाल से जुड़ी सटीक मेट्रिक पाने के लिए, G1 GC को लागू करने से जुड़ी अस्थिर जानकारी पर भरोसा कर रहे हैं. इस विकल्प की मदद से, हम G1 GC को लागू करने से जुड़ी जानकारी में हुए बदलावों के हिसाब से खुद को ढाल सकते हैं. इसके लिए, हमें बाइनरी रिलीज़ का इंतज़ार नहीं करना पड़ता. Passed to JDK Matcher.find()
--[no]legacy_important_outputs default: "false": इस विकल्प का इस्तेमाल करके, TargetComplete इवेंट में लेगसी important_outputs फ़ील्ड जनरेट होने से रोका जा सकता है. Bazel को ResultStore/BTX इंटिग्रेशन के लिए important_outputs की ज़रूरत होती है.
टैग: affects_outputs
--logging=<0 <= an integer <= 6> default: "3": लॉगिंग का लेवल.
टैग: affects_outputs
--memory_profile=<a path> डिफ़ॉल्ट: ब्यौरा देखें: अगर सेट किया गया है, तो फ़ेज़ के खत्म होने पर, मेमोरी के इस्तेमाल का डेटा तय की गई फ़ाइल में लिखें. साथ ही, बिल्ड के खत्म होने पर स्टेबल हीप को मास्टर लॉग में लिखें.
टैग: bazel_monitoring
--memory_profile_stable_heap_parameters=<integers, separated by a comma expected in pairs> default: "1,0": बिल्ड के आखिर में, मेमोरी प्रोफ़ाइल के स्टेबल हीप के हिसाब को बेहतर बनाया गया है. यह कॉमा से अलग किए गए पूर्णांकों की सम संख्या होनी चाहिए. हर पेयर में, पहली पूर्णांक संख्या, जीसी की संख्या होती है. हर जोड़े में दूसरा पूर्णांक, जीसी के बीच इंतज़ार करने के लिए सेकंड की संख्या है. उदाहरण के लिए, 2,4,4,0 का मतलब है कि दो बार जीसी होगा और हर बार चार सेकंड का पॉज़ होगा. इसके बाद, चार बार जीसी होगा और हर बार शून्य सेकंड का पॉज़ होगा
टैग: bazel_monitoring
--profile=<a path> डिफ़ॉल्ट: ब्यौरा देखें: अगर सेट किया गया है, तो Bazel की प्रोफ़ाइल बनाएं और डेटा को बताई गई फ़ाइल में लिखें. प्रोफ़ाइल का विश्लेषण करने के लिए, bazel analyze-profile का इस्तेमाल करें.
टैग: bazel_monitoring
--profiles_to_retain=<an integer> डिफ़ॉल्ट: "5": आउटपुट बेस में बनाए रखने के लिए प्रोफ़ाइलों की संख्या. अगर आउटपुट बेस में इस संख्या से ज़्यादा प्रोफ़ाइलें हैं, तो सबसे पुरानी प्रोफ़ाइलों को तब तक मिटाया जाता है, जब तक कि कुल संख्या तय सीमा से कम न हो जाए.
टैग: bazel_monitoring
--[no]record_full_profiler_data default: "false": डिफ़ॉल्ट रूप से, Bazel प्रोफ़ाइलर सिर्फ़ एग्रीगेट किया गया डेटा रिकॉर्ड करेगा. ऐसा इसलिए, ताकि तेज़ी से होने वाले कई इवेंट (जैसे, फ़ाइल की स्थिति) को रिकॉर्ड किया जा सके. इस विकल्प के चालू होने पर, प्रोफ़ाइलर हर इवेंट को रिकॉर्ड करेगा. इससे प्रोफ़ाइलिंग का ज़्यादा सटीक डेटा मिलेगा, लेकिन परफ़ॉर्मेंस पर काफ़ी असर पड़ेगा. इस विकल्प का असर सिर्फ़ तब होता है, जब --profile का भी इस्तेमाल किया गया हो.
टैग: bazel_monitoring
--[no]redirect_local_instrumentation_output_writes default: "false": अगर यह विकल्प सही पर सेट है और इसे इस्तेमाल किया जा सकता है, तो इंस्ट्रुमेंटेशन आउटपुट को रीडायरेक्ट किया जाता है. इससे, इसे उस मशीन पर स्थानीय तौर पर लिखा जा सकता है जिस पर Bazel नहीं चल रहा है.
टैग: bazel_monitoring
--remote_print_execution_messages=<failure, success or all> default: "failure": रिमोट एक्ज़ीक्यूशन के मैसेज प्रिंट करने की फ़्रीक्वेंसी चुनें. मान्य वैल्यू ये हैं: `failure` का इस्तेमाल सिर्फ़ उन मामलों में प्रिंट करने के लिए किया जाता है जिनमें जांच पूरी नहीं हो सकी, `success` का इस्तेमाल सिर्फ़ उन मामलों में प्रिंट करने के लिए किया जाता है जिनमें जांच पूरी हो गई, और `all` का इस्तेमाल हमेशा प्रिंट करने के लिए किया जाता है.
टैग: terminal_output
--[no]slim_profile default: "true": अगर प्रोफ़ाइल बहुत बड़ी हो जाती है, तो यह कुकी इवेंट को मर्ज करके JSON प्रोफ़ाइल का साइज़ कम कर देती है.
टैग: bazel_monitoring
--starlark_cpu_profile=<a string> default: "": यह फ़ंक्शन, सभी Starlark थ्रेड के ज़रिए सीपीयू के इस्तेमाल की pprof प्रोफ़ाइल को तय की गई फ़ाइल में लिखता है.
टैग: bazel_monitoring
--tool_tag=<a string> default: "": इस Bazel इनवोकेशन का श्रेय देने के लिए टूल का नाम.
टैग: affects_outputs, bazel_monitoring
--ui_event_filters=<Convert list of comma separated event kind to list of filters> कई बार इस्तेमाल किया गया हो: इससे यह तय होता है कि यूज़र इंटरफ़ेस (यूआई) में कौनसे इवेंट दिखाए जाएं. लीडिंग +/- का इस्तेमाल करके, डिफ़ॉल्ट इवेंट में इवेंट जोड़े या हटाए जा सकते हैं. इसके अलावा, सीधे असाइनमेंट का इस्तेमाल करके, डिफ़ॉल्ट सेट को पूरी तरह से बदला जा सकता है. इस्तेमाल किए जा सकने वाले इवेंट के टाइप में INFO, DEBUG, ERROR वगैरह शामिल हैं.
टैग: terminal_output

--experimental_resolved_file_instead_of_workspace=<a string> default: "": अगर यह खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय, तय की गई हल की गई फ़ाइल को पढ़ें
टैग: changes_inputs

--downloader_config=<a path> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (सिर्फ़ `allow` और `block` के लिए) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल, यूआरएल से मैच करने के लिए किया जाता है. वहीं, दूसरे पैटर्न का इस्तेमाल, यूआरएल को बदलने के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. किसी यूआरएल के लिए, एक से ज़्यादा `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, एक से ज़्यादा यूआरएल दिखाए जाएंगे.
--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: ब्यौरा देखें: यह बताता है कि सर्किट ब्रेकर को किस रणनीति का इस्तेमाल करना है. उपलब्ध रणनीतियां "failure" हैं. विकल्प के लिए अमान्य वैल्यू होने पर, विकल्प सेट न होने पर जैसा व्यवहार होता है वैसा ही व्यवहार होता है.
टैग: execution
--experimental_remote_cache_compression_threshold=<an integer> डिफ़ॉल्ट: "100": zstd का इस्तेमाल करके कंप्रेस/डीकंप्रेस करने के लिए, कम से कम ब्लोब साइज़ ज़रूरी है. जब तक --remote_cache_compression सेट नहीं किया जाता, तब तक यह विकल्प काम नहीं करता.
--[no]experimental_remote_cache_lease_extension default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, बिल्ड के दौरान रिमोट ऐक्शन के आउटपुट के लिए लीज़ को बढ़ा देगा. इसके लिए, वह समय-समय पर रिमोट कैश को `FindMissingBlobs` कॉल भेजेगा. फ़्रीक्वेंसी, `--experimental_remote_cache_ttl` की वैल्यू पर आधारित होती है.
--experimental_remote_cache_ttl=<An immutable length of time.> default: "3h": डाइजेस्ट का हाल ही में रेफ़रंस दिए जाने के बाद, रिमोट कैश में मौजूद ब्लॉब का कम से कम टीटीएल. उदाहरण के लिए, ActionResult या FindMissingBlobs. Bazel, ब्लॉब के टीटीएल के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, इंक्रीमेंटल बिल्ड में GetActionResult को बार-बार कॉल नहीं करता है. वैल्यू को असली टीटीएल से थोड़ा कम पर सेट किया जाना चाहिए, क्योंकि सर्वर के डाइजेस्ट वापस भेजने और Bazel के उन्हें पाने के बीच कुछ समय लगता है.
टैग: execution
--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह उस डायरेक्ट्री का पाथ है जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.
--[no]experimental_remote_discard_merkle_trees default: "true": अगर इसे सही पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़े इनपुट मैपिंग की इन-मेमोरी कॉपी को खारिज कर दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में मौजूद न होने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कंप्यूट करना होगा.
--experimental_remote_downloader=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाना है. grpc, grpcs (TLS की सुविधा के साथ grpc), और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. इस लिंक पर जानकारी पाएं: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback default: "false": अगर रिमोट डाउनलोडर काम नहीं करता है, तो लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.
--[no]experimental_remote_downloader_propagate_credentials default: "false": netrc और क्रेडेंशियल हेल्पर से रिमोट डाउनलोडर सर्वर पर क्रेडेंशियल भेजने हैं या नहीं. सर्वर के लिए, `http_header_url:<url-index>:<header-key>` क्वालिफ़ायर का इस्तेमाल किया जाना चाहिए. इसमें `<url-index>`, FetchBlobRequest के `uris` फ़ील्ड में मौजूद यूआरएल की 0 पर आधारित पोज़िशन होती है. यूआरएल के हिसाब से तय किए गए हेडर को ग्लोबल हेडर से ज़्यादा प्राथमिकता दी जानी चाहिए.
--[no]experimental_remote_execution_keepalive default: "false": रिमोट तरीके से एक्ज़ीक्यूट करने के लिए कॉल के दौरान, कीपअलाइव का इस्तेमाल करना है या नहीं.
--experimental_remote_failure_rate_threshold=<an integer in 0-100 range> default: "10": यह विकल्प, किसी समयावधि के लिए फ़ेल होने की दर को प्रतिशत में सेट करता है. इसके बाद, यह रिमोट कैश/एक्ज़ीक्यूटर को कॉल करना बंद कर देता है. डिफ़ॉल्ट रूप से इसकी वैल्यू 10 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
टैग: execution
--experimental_remote_failure_window_interval=<An immutable length of time.> default: "60s": वह समयावधि जिसमें रिमोट अनुरोधों के फ़ेल होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, फ़ेल होने की अवधि को पूरे एक्ज़ीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution
--[no]experimental_remote_mark_tool_inputs default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर्सिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache default: "false": अगर इस नीति को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने के लिए, मर्कल ट्री की कैलकुलेशन को मेमोराइज़ किया जाएगा. कैश मेमोरी के फ़ुटप्रिंट को --experimental_remote_merkle_tree_cache_size कंट्रोल करता है.
--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000": रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने के लिए, मेमोइज़ किए जाने वाले मर्कल ट्री की संख्या. सॉफ़्ट रेफ़रंस को मैनेज करने के Java के तरीके के मुताबिक, कैश अपने-आप कम हो जाता है. हालांकि, अगर इसे बहुत ज़्यादा पर सेट किया जाता है, तो मेमोरी से जुड़ी गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड होता है. सबसे सही वैल्यू, प्रोजेक्ट के साइज़ के हिसाब से अलग-अलग होती है. डिफ़ॉल्ट रूप से 1,000 पर सेट होता है.
--experimental_remote_output_service=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट आउटपुट सेवा के एंडपॉइंट का HOST या HOST:PORT. grpc, grpcs (TLS की सुविधा के साथ grpc), और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS बंद करने के लिए, grpc:// या unix: स्कीमा तय करें.
--experimental_remote_output_service_output_path_prefix=<a string> default: "": यह वह पाथ है जिसके तहत, --experimental_remote_output_service से मैनेज की गई आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. बिल्ड के लिए इस्तेमाल की जाने वाली असली आउटपुट डायरेक्ट्री, इस पाथ की डिसेंडेंट होगी. साथ ही, इसका फ़ैसला आउटपुट सेवा करेगी.
--[no]experimental_remote_require_cached default: "false": अगर इस विकल्प को 'चालू है' पर सेट किया जाता है, तो यह ज़रूरी हो जाता है कि रिमोट तरीके से की जा सकने वाली सभी कार्रवाइयों को कैश मेमोरी में सेव किया जाए. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह गैर-निर्धारित समस्याओं को हल करने के लिए उपयोगी है. इससे यह जांच की जा सकती है कि जिन कार्रवाइयों को कैश मेमोरी में सेव किया जाना चाहिए उन्हें कैश मेमोरी में सेव किया गया है या नहीं. साथ ही, यह भी जांच की जा सकती है कि कैश मेमोरी में नए नतीजे गलत तरीके से तो नहीं डाले गए हैं.
--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: ब्यौरा देखें: यह विकल्प, दी गई कॉन्फ़िगरेशन फ़ाइल की मदद से रिमोट कैश मेमोरी की कुंजी को मिटाने की सुविधा चालू करता है. यह फ़ाइल, टेक्स्ट फ़ॉर्मैट में प्रोटोकॉल बफ़र होनी चाहिए (src/main/protobuf/remote_scrubbing.proto देखें). इस सुविधा का मकसद, अलग-अलग प्लैटफ़ॉर्म पर एक्ज़ीक्यूट की जा रही कार्रवाइयों के बीच रिमोट/डिस्क कैश मेमोरी को शेयर करना है. हालांकि, ये कार्रवाइयां एक ही प्लैटफ़ॉर्म को टारगेट करती हैं. इसका इस्तेमाल बहुत सावधानी से करना चाहिए, क्योंकि गलत सेटिंग की वजह से कैश मेमोरी की एंट्री अनजाने में शेयर हो सकती हैं. इससे गलत बिल्ड बन सकते हैं. स्क्रबिंग से, कार्रवाई के तरीके पर कोई असर नहीं पड़ता. इससे सिर्फ़ यह तय होता है कि कार्रवाई के नतीजे को वापस पाने या सेव करने के लिए, रिमोट/डिस्क कैश मेमोरी की कुंजी की गिनती कैसे की जाती है. स्क्रब की गई कार्रवाइयां, रिमोट तरीके से लागू नहीं की जा सकतीं. इसलिए, इन्हें हमेशा स्थानीय तौर पर लागू किया जाएगा. स्क्रबिंग कॉन्फ़िगरेशन में बदलाव करने से, लोकल फ़ाइल सिस्टम या इंटरनल कैश मेमोरी में मौजूद आउटपुट अमान्य नहीं होते. जिन कार्रवाइयों पर असर पड़ा है उन्हें फिर से लागू करने के लिए, क्लीन बिल्ड की ज़रूरत होती है. इस सुविधा का इस्तेमाल करने के लिए, आपको --host_platform को --experimental_platform_in_output_dir (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --incompatible_strict_action_env (एनवायरमेंट वैरिएबल को सामान्य बनाने के लिए) के साथ सेट करना होगा.
--experimental_worker_for_repo_fetching=<off, platform, virtual or auto> default: "auto": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. ऐसा न होने पर, वर्चुअल वर्कर थ्रेड का इस्तेमाल करता है.
--[no]guard_against_concurrent_changes default: "lite": इसे 'full' पर सेट करें, ताकि रिमोट कैश में अपलोड करने से पहले, किसी कार्रवाई की सभी इनपुट फ़ाइलों के ctime की जांच की जा सके. ऐसा हो सकता है कि कुछ मामलों में Linux कर्नल, फ़ाइलों को लिखने में देरी करे. इससे फ़ॉल्स पॉज़िटिव मिल सकते हैं. डिफ़ॉल्ट रूप से, यह 'lite' पर सेट होता है. यह सिर्फ़ मुख्य रिपॉज़िटरी में मौजूद सोर्स फ़ाइलों की जांच करता है. इसे 'बंद है' पर सेट करने से, सभी जांच बंद हो जाती हैं. हमारा सुझाव है कि ऐसा न करें. ऐसा इसलिए, क्योंकि जब किसी सोर्स फ़ाइल में बदलाव किया जाता है, तब उसे इनपुट के तौर पर इस्तेमाल करने वाली कार्रवाई चल रही होती है. इससे कैश मेमोरी में मौजूद डेटा खराब हो सकता है.
टैग: execution
--[no]remote_accept_cached default: "true": रिमोटली कैश मेमोरी में सेव किए गए ऐक्शन के नतीजों को स्वीकार करना है या नहीं.
--remote_build_event_upload=<all or minimal> default: "minimal": अगर इसे 'all' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश में अपलोड किए जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो बीईपी से रेफ़र की गई लोकल आउटपुट फ़ाइलों को रिमोट कैश में अपलोड नहीं किया जाता. हालांकि, बीईपी के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों को अपलोड किया जाता है. जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का इस्तेमाल हमेशा किया जाता है. भले ही, वे रिमोट कैश में मौजूद न हों. डिफ़ॉल्ट रूप से 'minimal' पर सेट होता है.
--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: होस्टनेम और इंस्टेंस का नाम, जिसका इस्तेमाल build event streams में लिखे गए bytestream:// यूआरआई में किया जाना है. इस विकल्प को तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इससे --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इसे सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.
--remote_cache=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कैशिंग एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://bazel.build/remote/caching देखें
--[no]remote_cache_async default: "true": अगर यह वैल्यू सही है, तो कार्रवाई के नतीजों को डिस्क या रिमोट कैश में अपलोड करने की प्रोसेस बैकग्राउंड में होगी. इससे कार्रवाई पूरी होने में कोई रुकावट नहीं आएगी. कुछ कार्रवाइयां, बैकग्राउंड में अपलोड करने की सुविधा के साथ काम नहीं करती हैं. इसलिए, इस फ़्लैग के सेट होने पर भी ये कार्रवाइयां ब्लॉक हो सकती हैं.
--[no]remote_cache_compression default: "false": अगर यह विकल्प चालू है, तो कैश मेमोरी में सेव किए गए बड़े डेटा ऑब्जेक्ट को zstd की मदद से कंप्रेस/डिकंप्रेस करें. ऐसा तब करें, जब उनका साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.
--remote_cache_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: कैश मेमोरी के अनुरोधों में शामिल किए जाने वाले हेडर के बारे में बताएं: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_default_exec_properties=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: डिफ़ॉल्ट exec प्रॉपर्टी सेट करें, ताकि उन्हें रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल किया जा सके. ऐसा तब किया जाता है, जब एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट न करता हो.
टैग: affects_outputs
--remote_default_platform_properties=<a string> default: "": अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म ने पहले से ही remote_execution_properties सेट नहीं की हैं, तो रिमोट एक्ज़ीक्यूशन एपीआई के लिए सेट की जाने वाली डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. अगर रिमोट एक्ज़ीक्यूशन के लिए होस्ट प्लैटफ़ॉर्म को एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल किया जाएगा.
--remote_download_regex=<a valid Java regular expression> कई बार इस्तेमाल किया गया हो: इस पैटर्न से मेल खाने वाले पाथ के रिमोट बिल्ड के आउटपुट को डाउनलोड करने के लिए मजबूर करें. भले ही, --remote_download_outputs का इस्तेमाल किया गया हो या नहीं. इस फ़्लैग को दोहराकर, कई पैटर्न तय किए जा सकते हैं.
टैग: affects_outputs
--remote_downloader_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: ऐसा हेडर तय करें जिसे रिमोट डाउनलोडर के अनुरोधों में शामिल किया जाएगा: --remote_downloader_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_exec_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: ऐसा हेडर तय करें जिसे एक्ज़ीक्यूशन के अनुरोधों में शामिल किया जाएगा: --remote_exec_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_execution_priority=<an integer> default: "0": रिमोट तरीके से की जाने वाली कार्रवाइयों की प्राथमिकता. किसी प्राथमिकता की वैल्यू का मतलब, सर्वर पर निर्भर करता है.
--remote_executor=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट एक्ज़ीक्यूशन एंडपॉइंट का HOST या HOST:PORT. grpc, grpcs (TLS की सुविधा के साथ grpc), और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS बंद करने के लिए, grpc:// या unix: स्कीमा तय करें.
--remote_grpc_log=<a path> डिफ़ॉल्ट: ब्यौरा देखें: अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में, क्रम से लगाए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry प्रोटोबफ़ होते हैं. हर मैसेज के पहले एक वैरिएंट होता है, जो क्रम से लगाए गए अगले प्रोटोबफ़ मैसेज के साइज़ को दिखाता है. ऐसा LogEntry.writeDelimitedTo(OutputStream) तरीके से किया जाता है.
--remote_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: अनुरोधों में शामिल किए जाने वाले हेडर के बारे में बताएं: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_instance_name=<a string> default: "": रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.
--[no]remote_local_fallback default: "false": अगर रिमोट एक्ज़ीक्यूशन काम नहीं करता है, तो क्या स्टैंडअलोन लोकल एक्ज़ीक्यूशन की रणनीति पर वापस जाना है.
--remote_local_fallback_strategy=<a string> default: "local": अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.
--remote_max_connections=<an integer> डिफ़ॉल्ट: "100": रिमोट कैश/एक्ज़ीक्यूटर से एक साथ कनेक्ट किए जा सकने वाले कनेक्शन की ज़्यादा से ज़्यादा संख्या को सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एक्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर 100 से ज़्यादा एक साथ किए गए अनुरोधों को हैंडल कर सकता है. इसलिए, Bazel एक साथ किए गए करीब `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations
--remote_proxy=<a string> डिफ़ॉल्ट: ब्यौरा देखें: प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer> default: "0": रिमोट ऐक्शन की प्राथमिकता, जिसे रिमोट कैश मेमोरी में सेव किया जाना है. किसी प्राथमिकता की वैल्यू का मतलब, सर्वर पर निर्भर करता है.
--remote_retries=<an integer> डिफ़ॉल्ट: "5": यह विकल्प, कुछ समय के लिए होने वाली गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कोशिश करने की सुविधा देता है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
--remote_retry_max_delay=<An immutable length of time.> default: "5s": रीमोट तरीके से फिर से कोशिश करने के लिए, बैकऑफ़ में लगने वाला ज़्यादा से ज़्यादा समय. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
--remote_timeout=<An immutable length of time.> default: "60s": रिमोट एक्ज़ीक्यूशन और कैश मेमोरी के कॉल के लिए, इंतज़ार करने की ज़्यादा से ज़्यादा समयावधि. REST कैश के लिए, यह कनेक्ट और रीड, दोनों के लिए टाइमआउट होता है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
--[no]remote_upload_local_results default: "true": अगर रिमोट कैश मेमोरी इस सुविधा के साथ काम करती है और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या स्थानीय तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.
--[no]remote_verify_downloads default: "true": इस विकल्प को सही पर सेट करने पर, Bazel सभी रिमोट डाउनलोड के हैश का योग कैलकुलेट करेगा. साथ ही, अगर रिमोट तौर पर कैश की गई वैल्यू, अनुमानित वैल्यू से मैच नहीं करती हैं, तो उन्हें खारिज कर देगा.

--build_metadata=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: बिल्ड इवेंट में सप्लाई करने के लिए कस्टम की-वैल्यू स्ट्रिंग पेयर.
टैग: terminal_output
--color=<yes, no or auto> default: "auto": आउटपुट को रंगीन बनाने के लिए, टर्मिनल कंट्रोल का इस्तेमाल करें.
--config=<a string> कई बार इस्तेमाल किया गया हो: rc फ़ाइलों से अतिरिक्त कॉन्फ़िगरेशन सेक्शन चुनता है; हर <command> के लिए, यह <command>:<config> से विकल्प भी खींचता है, अगर ऐसा कोई सेक्शन मौजूद है; अगर यह सेक्शन किसी भी .rc फ़ाइल में मौजूद नहीं है, तो Blaze गड़बड़ी के साथ बंद हो जाता है. कॉन्फ़िगरेशन सेक्शन और उनसे मिलते-जुलते फ़्लैग कॉम्बिनेशन, tools/*.blazerc कॉन्फ़िगरेशन फ़ाइलों में मौजूद होते हैं.
--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.> कई बार इस्तेमाल किया गया हो: यह <a href="https://github.com/EngFlow/credential-helper-spec">क्रेडेंशियल हेल्पर स्पेसिफ़िकेशन</a> के मुताबिक क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है. इसका इस्तेमाल, रिपॉज़िटरी फ़ेच करने, रिमोट कैशिंग और एक्ज़ीक्यूशन, और बिल्ड इवेंट सेवा के लिए अनुमति देने वाले क्रेडेंशियल को वापस पाने के लिए किया जाता है. सहायता करने वाले व्यक्ति की ओर से दिए गए क्रेडेंशियल को, `--google_default_credentials`, `--google_credentials`, `.netrc` फ़ाइल या `repository_ctx.download()` और `repository_ctx.download_and_extract()` के लिए auth पैरामीटर की ओर से दिए गए क्रेडेंशियल से ज़्यादा प्राथमिकता दी जाती है. एक से ज़्यादा हेल्पर सेट अप करने के लिए, इसे कई बार तय किया जा सकता है. निर्देशों के लिए, https://blog.engflow.com/2023/10/09/configuring-bazels-credential-helper/ पर जाएं.
--credential_helper_cache_duration=<An immutable length of time.> default: "30m": अगर क्रेडेंशियल हेल्पर, क्रेडेंशियल के खत्म होने की तारीख नहीं बताता है, तो क्रेडेंशियल हेल्पर से मिले क्रेडेंशियल को डिफ़ॉल्ट रूप से इस अवधि के लिए कैश मेमोरी में सेव किया जाता है.
--credential_helper_timeout=<An immutable length of time.> default: "10s": इस नीति की मदद से, क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर किया जाता है. अगर क्रेडेंशियल हेल्पर इस टाइमआउट के अंदर जवाब नहीं देते हैं, तो उन्हें लागू नहीं किया जा सकेगा.
--curses=<yes, no or auto> default: "auto": स्क्रोलिंग आउटपुट को कम करने के लिए, टर्मिनल कर्सर कंट्रोल का इस्तेमाल करें.
--disk_cache=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह उस डायरेक्ट्री का पाथ होता है जहां Bazel, कार्रवाइयां और कार्रवाई के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.
--[no]enable_platform_specific_config default: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, bazelrc फ़ाइलों से होस्ट ओएस के हिसाब से कॉन्फ़िगरेशन लाइनें चुनता है. उदाहरण के लिए, अगर होस्ट ओएस Linux है और आपने bazel build कमांड चलाई है, तो Bazel, build:linux से शुरू होने वाली लाइनों को चुनता है. इस्तेमाल किए जा सकने वाले ओएस आइडेंटिफ़ायर ये हैं: linux, macos, windows, freebsd, और openbsd. इस फ़्लैग को चालू करने का मतलब है कि Linux पर --config=linux, Windows पर --config=windows वगैरह का इस्तेमाल किया जा रहा है.
--experimental_disk_cache_gc_idle_delay=<An immutable length of time.> default: "5m": डिस्क कैश मेमोरी की गार्बेज कलेक्शन की प्रोसेस शुरू होने से पहले, सर्वर को कितने समय तक बंद रहना चाहिए. कचरा इकट्ठा करने की नीति तय करने के लिए, --experimental_disk_cache_gc_max_size और/या --experimental_disk_cache_gc_max_age सेट करें.
--experimental_disk_cache_gc_max_age=<An immutable length of time.> default: "0": अगर इसे पॉज़िटिव वैल्यू पर सेट किया जाता है, तो डिस्क कैश मेमोरी से समय-समय पर ऐसी एंट्री हटा दी जाएंगी जो इस वैल्यू से ज़्यादा पुरानी हैं. अगर इसे --experimental_disk_cache_gc_max_size के साथ सेट किया जाता है, तो दोनों शर्तें लागू होती हैं. सर्वर के निष्क्रिय होने के बाद, बैकग्राउंड में गार्बेज कलेक्शन होता है. सर्वर के निष्क्रिय होने का समय, --experimental_disk_cache_gc_idle_delay फ़्लैग से तय होता है.
--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier> default: "0": अगर इसे पॉज़िटिव वैल्यू पर सेट किया जाता है, तो डिस्क कैश को समय-समय पर रीसाइकल किया जाएगा, ताकि यह इस साइज़ से ज़्यादा न हो. अगर इसे --experimental_disk_cache_gc_max_age के साथ सेट किया जाता है, तो दोनों शर्तें लागू होती हैं. सर्वर के निष्क्रिय होने के बाद, बैकग्राउंड में गार्बेज कलेक्शन होता है. सर्वर के निष्क्रिय होने का समय, --experimental_disk_cache_gc_idle_delay फ़्लैग से तय होता है.
--experimental_install_base_gc_max_age=<An immutable length of time.> डिफ़ॉल्ट: "30d": किसी ऐप्लिकेशन को कितने समय तक इस्तेमाल न करने पर, उसे ट्रैश में भेजा जा सकता है. अगर यह वैल्यू शून्य नहीं है, तो सर्वर, इस्तेमाल में न होने पर अन्य इंस्टॉल बेस को गार्बेज इकट्ठा करने की कोशिश करेगा.
टैग: host_machine_resource_optimizations
--[no]experimental_rule_extension_api default: "true": Enable experimental rule extension API and subrule APIs
Tags: loading_and_analysis, experimental
--[no]experimental_windows_watchfs default: "false": अगर यह वैल्यू सही है, तो --watchfs के लिए एक्सपेरिमेंट के तौर पर उपलब्ध Windows की सुविधा चालू हो जाती है. इसके अलावा, Windows पर --watchfs काम नहीं करता है. --watchfs को भी चालू करना न भूलें.
--google_auth_scopes=<comma-separated list of options> default: "https://www.googleapis.com/auth/cloud-platform": Google Cloud की पुष्टि करने के स्कोप की कॉमा लगाकर अलग की गई सूची.
--google_credentials=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प का इस्तेमाल करके, उस फ़ाइल के बारे में बताया जाता है जिससे पुष्टि करने वाले क्रेडेंशियल पाने हैं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं.
--[no]google_default_credentials default: "false": पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं. यह सुविधा डिफ़ॉल्ट रूप से बंद होती है.
--grpc_keepalive_time=<An immutable length of time.> डिफ़ॉल्ट: ब्यौरा देखें: इस कुकी का इस्तेमाल, आउटगोइंग gRPC कनेक्शन के लिए कीप-अलाइव पिंग को कॉन्फ़िगर करने के लिए किया जाता है. अगर यह विकल्प सेट किया जाता है, तो कनेक्शन पर कोई भी रीड ऑपरेशन न होने पर, Bazel इस समयावधि के बाद पिंग भेजता है. हालांकि, ऐसा सिर्फ़ तब होता है, जब कम से कम एक gRPC कॉल लंबित हो. समय को सेकंड के हिसाब से माना जाता है. एक सेकंड से कम की वैल्यू सेट करना एक गड़बड़ी है. डिफ़ॉल्ट रूप से, कीप-अलाइव पिंग की सुविधा बंद होती है. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक से संपर्क करना चाहिए. उदाहरण के लिए, इस फ़्लैग के लिए 30 सेकंड की वैल्यू सेट करने के लिए, इसे इस तरह से किया जाना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.> default: "20s": यह कुकी, आउटगोइंग gRPC कनेक्शन के लिए कीप-अलाइव टाइमआउट को कॉन्फ़िगर करती है. अगर --grpc_keepalive_time के साथ कीप-अलाइव पिंग चालू किए जाते हैं, तो Bazel इस समय के बाद पिंग का जवाब न मिलने पर कनेक्शन को टाइम आउट कर देता है. समय को सेकंड के हिसाब से माना जाता है. एक सेकंड से कम की वैल्यू सेट करना एक गड़बड़ी है. अगर कीप-अलाइव पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.
--[no]incompatible_disable_non_executable_java_binary default: "false": अगर सही है, तो java_binary हमेशा एक्ज़ीक्यूटेबल होता है. create_executable एट्रिब्यूट हटा दिया जाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_repo_env_ignores_action_env default: "false": अगर यह वैल्यू सही है, तो <code>--action_env=NAME=VALUE</code> का असर, रिपॉज़िटरी के नियम और मॉड्यूल एक्सटेंशन एनवायरमेंट पर नहीं पड़ेगा.
टैग: loading_and_analysis, incompatible_change
--inject_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: यह <repository name>=<path> के फ़ॉर्मैट में, लोकल पाथ के साथ एक नई रिपॉज़िटरी जोड़ता है. यह सिर्फ़ --enable_bzlmod के साथ काम करता है. साथ ही, यह `use_repo_rule` के ज़रिए रूट मॉड्यूल की MODULE.bazel फ़ाइल में, इससे मिलती-जुलती `local_repository` जोड़ने के बराबर है. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल उसी तरह किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पिछले सभी इंजेक्शन हटा दें.
--invocation_id=<a UUID> default: "": यह यूयूआईडी फ़ॉर्मैट में, चालू की जा रही कमांड के लिए यूनीक आइडेंटिफ़ायर होता है. अगर यूनीकनेस के बारे में साफ़ तौर पर बताया गया है, तो कॉलर को यह पक्का करना होगा कि वह यूनीक हो. यूयूआईडी को stderr, बीईपी, और रिमोट एक्ज़ीक्यूशन प्रोटोकॉल में प्रिंट किया जाता है.
टैग: bazel_monitoring, bazel_internal_configuration
--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सल्यूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पिछले सभी ओवरराइड हटा दें.
--[no]progress_in_terminal_title default: "false": टर्मिनल के टाइटल में कमांड की प्रोग्रेस दिखाएं. कई टर्मिनल टैब होने पर, Bazel क्या कर रहा है, यह देखने के लिए यह विकल्प काम आता है.
--[no]show_progress default: "true": बिल्ड के दौरान प्रोग्रेस मैसेज दिखाएं.
--show_progress_rate_limit=<a double> default: "0.2": आउटपुट में प्रोग्रेस मैसेज के बीच कम से कम सेकंड की संख्या.
--[no]show_timestamps default: "false": मैसेज में टाइमस्टैंप शामिल करना
--tls_certificate=<a string> डिफ़ॉल्ट: ब्यौरा देखें: उस टीएलएस सर्टिफ़िकेट का पाथ डालें जिस पर सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.
--tls_client_certificate=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इस्तेमाल किए जाने वाले टीएलएस क्लाइंट सर्टिफ़िकेट के बारे में बताएं. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इस्तेमाल की जाने वाली टीएलएस क्लाइंट कुंजी तय करें. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
--ui_actions_shown=<an integer> default: "8": प्रोग्रेस बार में एक साथ की जा रही कार्रवाइयों की संख्या दिखाई जाती है. हर कार्रवाई को अलग लाइन में दिखाया जाता है. प्रोग्रेस बार में हमेशा कम से कम एक दिखता है. एक से कम सभी संख्याओं को 1 पर मैप किया जाता है.
टैग: terminal_output
--[no]watchfs default: "false": Linux/macOS पर: अगर यह विकल्प सही है, तो Bazel हर फ़ाइल को स्कैन करने के बजाय, स्थानीय बदलावों के लिए ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करता है. Windows पर: फ़िलहाल, यह फ़्लैग काम नहीं करता है. हालांकि, इसे --experimental_windows_watchfs के साथ चालू किया जा सकता है. किसी भी ओएस पर: अगर आपका वर्कस्पेस किसी नेटवर्क फ़ाइल सिस्टम पर है और फ़ाइलों में बदलाव किसी रिमोट मशीन पर किया जाता है, तो इसका व्यवहार तय नहीं किया जा सकता.

प्रोफ़ाइल का विश्लेषण करने के विकल्प

--[no]incompatible_use_plus_in_repo_names default: "true": No-op.
टैग: loading_and_analysis

--dump=<text or raw> [-d] डिफ़ॉल्ट: ब्यौरा देखें: पूरी प्रोफ़ाइल का डेटा डंप करें. इसे ऐसे 'टेक्स्ट' फ़ॉर्मैट में डंप करें जिसे कोई भी व्यक्ति आसानी से पढ़ सके या ऐसे 'रॉ' फ़ॉर्मैट में डंप करें जिसे स्क्रिप्ट आसानी से पढ़ सके.
टैग: bazel_monitoring

Aquery के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

--aspect_deps=<off, conservative or precise> default: "conservative": जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तब पहलू की डिपेंडेंसी को कैसे हल करें. 'off' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'conservative' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी का नियम क्लास दिया गया हो या नहीं. 'precise' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हों. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह फ़ैसला विश्लेषण के चरण में लिया जाता है. यह चरण 'bazel query' के दौरान नहीं चलता.
टैग: build_file_semantics
--[no]consistent_labels default: "false": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे कि Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के बजाय रिपॉज़िटरी के नाम (मुख्य रिपॉज़िटरी के हिसाब से) दिखा सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects default: "false": aquery, cquery: whether to include aspect-generated actions in the output. query: no-op (aspects are always followed).
टैग: terminal_output
--[no]graph:factored default: "true": अगर यह विकल्प चुना जाता है, तो ग्राफ़ को 'फ़ैक्टर्ड' किया जाएगा. इसका मतलब है कि टोपोलॉजिकल तौर पर एक जैसे नोड को एक साथ मर्ज कर दिया जाएगा और उनके लेबल को एक साथ जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> default: "512": आउटपुट में, ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. बड़े लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि लेबल को छोटा नहीं किया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps default: "true": अगर यह विकल्प चालू है, तो क्वेरी जिस डिपेंडेंसी ग्राफ़ पर काम करती है उसमें इंप्लिसिट डिपेंडेंसी शामिल की जाएंगी. इंप्लिसिट डिपेंडेंसी ऐसी डिपेंडेंसी होती है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया जाता, लेकिन Bazel इसे जोड़ देता है. cquery के लिए, यह विकल्प हल की गई टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_artifacts default: "true": इसमें आउटपुट में कार्रवाई के इनपुट और आउटपुट के नाम शामिल होते हैं (यह काफ़ी बड़ा हो सकता है).
टैग: terminal_output
--[no]include_aspects default: "true": aquery, cquery: whether to include aspect-generated actions in the output. query: no-op (aspects are always followed).
टैग: terminal_output
--[no]include_commandline default: "true": इसमें आउटपुट में कार्रवाई के निर्देश वाली लाइनों का कॉन्टेंट शामिल होता है. यह काफ़ी बड़ा हो सकता है.
टैग: terminal_output
--[no]include_file_write_contents default: "false": FileWrite, SourceSymlinkManifest, और RepoMappingManifest कार्रवाइयों के लिए, फ़ाइल का कॉन्टेंट शामिल करें. इसमें ज़्यादा समय लग सकता है.
टैग: terminal_output
--[no]include_param_files default: "false": कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें. यह कॉन्टेंट बड़ा हो सकता है. ध्यान दें: इस फ़्लैग को चालू करने पर, --include_commandline फ़्लैग अपने-आप चालू हो जाएगा.
टैग: terminal_output
--[no]include_pruned_inputs default: "true": इसमें कार्रवाई के ऐसे इनपुट शामिल होते हैं जिन्हें कार्रवाई पूरी होने के दौरान हटाया गया था. इससे सिर्फ़ उन कार्रवाइयों पर असर पड़ता है जो इनपुट का पता लगाती हैं और पिछले इनवोकेशन में पूरी हो चुकी हैं. यह विकल्प सिर्फ़ तब काम करता है, जब --include_artifacts भी सेट किया गया हो.
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash default: "true": अगर यह विकल्प चालू है, तो package_group एट्रिब्यूट के `packages` एट्रिब्यूट की वैल्यू देते समय, शुरुआती `//` को शामिल किया जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope default: "false": अगर इसे सेट किया गया है और --universe_scope को सेट नहीं किया गया है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि क्वेरी एक्सप्रेशन के लिए अनुमानित --universe_scope वैल्यू, आपकी ज़रूरत के हिसाब से नहीं हो सकती.ऐसा तब होता है, जब क्वेरी एक्सप्रेशन में यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे, `allrdeps`) का इस्तेमाल किया जाता है.इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करें, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query पर जाएं. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है. इसका मतलब है कि यह `cquery` पर लागू नहीं होता.
टैग: loading_and_analysis
--[no]line_terminator_null default: "false": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया गया है.
टैग: terminal_output
--[no]nodep_deps default: "true": अगर यह विकल्प चालू है, तो "nodep" एट्रिब्यूट से मिले डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल किए जाएंगे. क्वेरी इसी ग्राफ़ पर काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` कमांड चलाएं और उसके आउटपुट को पार्स करें.
टैग: build_file_semantics
--output=<a string> default: "text": वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. aquery के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: text, textproto, proto, streamed_proto, jsonproto.
टैग: terminal_output
--output_file=<a string> default: "": इस विकल्प को चुनने पर, क्वेरी के नतीजे सीधे इस फ़ाइल में लिखे जाएंगे. साथ ही, Bazel के स्टैंडर्ड आउटपुट स्ट्रीम (stdout) में कुछ भी प्रिंट नहीं किया जाएगा. आम तौर पर, बेंचमार्क में यह <code>bazel query > file</code> से ज़्यादा तेज़ होता है.
टैग: terminal_output
--[no]proto:default_values default: "true": अगर यह वैल्यू सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह वैल्यू गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack default: "false": definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, नियम के हर इंस्टेंस के लिए, Starlark कॉल स्टैक को रिकॉर्ड करता है. यह रिकॉर्डिंग, नियम की क्लास तय किए जाने के समय की जाती है.
टैग: terminal_output
--[no]proto:flatten_selects default: "true": अगर यह विकल्प चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किए गए डेटा का मतलब ऐसी सूची से है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects default: "false": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, उस सोर्स पहलू का नाम डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स पहलू से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output
--[no]proto:include_synthetic_attribute_hash default: "false": $internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack default: "false": हर नियम के इंस्टैंटिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए, स्टैक में
टैग मौजूद होने चाहिए: terminal_output
--[no]proto:locations default: "true": क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> default: "all": आउटपुट में शामिल करने के लिए, कॉमा लगाकर अलग किए गए एट्रिब्यूट की सूची. डिफ़ॉल्ट रूप से, सभी एट्रिब्यूट के लिए लागू होता है. किसी भी एट्रिब्यूट को आउटपुट न करने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प, --output=proto पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_classes default: "false": हर नियम के rule_class_key फ़ील्ड में वैल्यू डालें. साथ ही, किसी दिए गए rule_class_key वाले पहले नियम के लिए, उसके rule_class_info प्रोटो फ़ील्ड में भी वैल्यू डालें. rule_class_key फ़ील्ड, नियम क्लास की खास तौर पर पहचान करता है. साथ ही, rule_class_info फ़ील्ड, Stardoc फ़ॉर्मैट में नियम क्लास की एपीआई डेफ़िनिशन है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs default: "true": rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output
--query_file=<a string> default: "": अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.
टैग: changes_inputs
--[no]relative_locations default: "false": अगर यह विकल्प चुना जाता है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह की जानकारी रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह अलग-अलग मशीनों पर एक जैसा नहीं होता. इस विकल्प को true पर सेट करके, सभी मशीनों पर एक जैसा नतीजा पाया जा सकता है.
टैग: terminal_output
--[no]skyframe_state default: "false": ज़्यादा विश्लेषण किए बिना, Skyframe से मौजूदा ऐक्शन ग्राफ़ को डंप करो. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय करने की सुविधा उपलब्ध नहीं है. यह फ़्लैग सिर्फ़ --output=proto या --output=textproto के साथ उपलब्ध है.
टैग: terminal_output
--[no]tool_deps default: "true": क्वेरी: अगर यह सुविधा बंद है, तो 'एक्ज़ीक्यूशन कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'exec configuration' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से लेकर प्रोटोकॉल कंपाइलर तक, आम तौर पर उसी 'target' प्रोग्राम के किसी हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल की ओर इशारा करता है. Cquery: अगर यह सुविधा बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर दिया जाता है जो टॉप-लेवल के उस टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं जिसने इस कॉन्फ़िगर किए गए टारगेट का पता लगाया था. इसका मतलब है कि अगर टॉप-लेवल का टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो टारगेट कॉन्फ़िगरेशन में मौजूद सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प से, हल की गई टूलचेन को नहीं हटाया जाएगा.
टैग: build_file_semantics
--universe_scope=<comma-separated list of options> default: "": कॉमा लगाकर अलग किए गए टारगेट पैटर्न का सेट (जोड़ने और घटाने वाले). क्वेरी को, ट्रांज़िटिव क्लोज़र के ज़रिए तय किए गए यूनिवर्स में किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट होते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर इस विकल्प के बारे में नहीं बताया जाता है, तो यह माना जाता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के टारगेट हैं. ध्यान दें: cquery के लिए, इस विकल्प को तय न करने पर, बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ नहीं बनाए जा सकते.
टैग: loading_and_analysis

--[no]experimental_inprocess_symlink_creation default: "true": सिंबल लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या हेल्पर प्रोसेस को डेलिगेट करना है.
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor default: "false": वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution, experimental
--[no]experimental_remotable_source_manifests default: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing default: "false": अगर यह विकल्प सही है, तो Bazel, टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.
टैग: execution, experimental
--[no]experimental_strict_fileset_output default: "false": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental
--[no]incompatible_modify_execution_info_additive default: "false": इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो: कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि कई रेगुलर एक्सप्रेशन एक ही नेमोनिक पर लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z' से, सभी कार्रवाइयों के लिए एक्ज़ीक्यूशन की जानकारी में 'x' और 'z' जुड़ जाते हैं और 'y' हट जाता है. 'Genrule=+requires-x' से, Genrule की सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी में जोड़ा जाता है. '(?!Genrule).*=-requires-x' से, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी से हटा दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis
--persistent_android_dex_desugar: वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू रखें.
इनके तौर पर दिखता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution
--persistent_android_resource_processor: वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को हमेशा चालू रखें.
बढ़कर यह हो जाता है:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_dex_desugar: वर्कर्स का इस्तेमाल करके, लगातार मल्टीप्लेक्स किए गए Android dex और desugar कार्रवाइयों को चालू करें.
इनके तौर पर दिखता है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_resource_processor: वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.
इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_tools: Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (dexing, desugaring, resource processing) चालू करें.
इनके तौर पर दिखता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--[no]use_target_platform_for_tests default: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. इसके बजाय, टेस्ट एक्ज़ेक ग्रुप का इस्तेमाल नहीं करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android": android_binary नियमों के लिए, मेनिफ़ेस्ट मर्जर को चुनता है. यह फ़्लैग, लेगसी मर्जर से Android मेनिफ़ेस्ट मर्जर पर स्विच करने में मदद करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_platforms=<a build target label> default: "": यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain": Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> default: "": यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger": यह उस बाइनरी का पाथ है जिसका इस्तेमाल रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:lcov_merger' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator": कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी का पाथ. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट वैल्यू '//tools/test:coverage_report_generator' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support": सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:coverage_support' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह कस्टम malloc को लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के पहले, - (नेगेटिव एक्सप्रेशन) का इस्तेमाल किया जा सकता है. इसे कॉमा लगाकर अलग किए गए, कंस्ट्रेंट वैल्यू टारगेट की सूची को असाइन (=) किया जाता है. अगर कोई टारगेट, किसी भी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसके टूलचेन रिज़ॉल्यूशन को इस तरह से पूरा किया जाएगा जैसे कि उसने कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर एलान किया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64 'test' नाम वाले लक्ष्यों को छोड़कर, //demo के अंतर्गत किसी भी लक्ष्य में 'x86_64' जोड़ देगा.
टैग: loading_and_analysis
--[no]experimental_include_xcode_execution_requirements default: "false": अगर सेट है, तो हर Xcode कार्रवाई में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution, experimental
--[no]experimental_prefer_mutual_xcode default: "true": अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state, experimental
--extra_execution_platforms=<comma-separated list of options> default: "": कार्रवाइयां करने के लिए उपलब्ध प्लैटफ़ॉर्म. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले माना जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, पहले की फ़्लैग सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में एलान किए गए टूलचेन से पहले माना जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह फ़्लैग कोई कार्रवाई नहीं करता. इसे आने वाले समय में हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform": यह प्लैटफ़ॉर्म के नियम का लेबल है. इससे होस्ट सिस्टम के बारे में पता चलता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_bazel_test_exec_run_under default: "false": अगर यह विकल्प चालू है, तो "bazel test --run_under=//:runner" कमांड, एक्ज़ेक कॉन्फ़िगरेशन में "//:runner" बनाता है. यह सुविधा बंद होने पर, टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true": अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution default: "false": ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_remove_legacy_whole_archive default: "true": अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_strip_executable_safely default: "false": अगर यह सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects default: "true": अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी ईएलएफ़ टूलचेन इस सेटिंग के साथ काम करते हैं.
टैग: loading_and_analysis, affects_outputs, affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे macOS ऐप्लिकेशन बनाने के लिए, macOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से macOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--minimum_os_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह ओएस का वह कम से कम वर्शन है जिसे कंपाइल करने के लिए टारगेट किया जाता है.
टैग: loading_and_analysis, affects_outputs
--platform_mappings=<a main workspace-relative path> default: "": यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य वर्कस्पेस रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, वर्कस्पेस के रूट फ़ोल्डर में मौजूद होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> default: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह py_runtime का लेबल है. यह टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर को दिखाता है. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से tvOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह विकल्प चुना जाता है, तो यह बिल्ड से जुड़ी कार्रवाइयों के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी जाती है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes": यह xcode_config नियम का लेबल है. इसका इस्तेमाल, बिल्ड कॉन्फ़िगरेशन में Xcode का वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym default: "false": डीबग सिंबल (.dSYM) वाली फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह जानकारी गलत है, तो इसे शामिल न करें. इसकी वैल्यू फ़ॉल्स होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs
--[no]build_test_dwp default: "false": अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h": cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc": cc_proto_library, सोर्स फ़ाइलों के ऐसे सफ़िक्स सेट करता है जिन्हें वह बनाता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info default: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state default: "false": कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> default: "no": इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल कौनसे कंपाइलेशन मोड करते हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data default: "true": अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]incompatible_compact_repo_mapping_manifest default: "false": अगर यह सुविधा चालू है, तो <binary>.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन की रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन, रनफ़ाइल जनरेट करने वाले हर रेपो के लिए एक बार रेपो मैपिंग दिखाने के बजाय, सिर्फ़ एक बार दिखाती है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_filegroup_runfiles_for_data default: "false": अगर सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.
टैग: incompatible_change
--[no]legacy_external_runfiles default: "false": अगर यह सही है, तो .runfiles/repo के साथ-साथ .runfiles/wsname/external/repo में मौजूद बाहरी रिपॉज़िटरी के लिए, बिल्ड रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap default: "false": इससे यह तय किया जाता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps default: "false": अगर यह सेट है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को <code>name</code> के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर के हिसाब से भी वैरिएबल को तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है. <br> ध्यान दें कि जब तक <code>--incompatible_repo_env_ignores_action_env</code> की वैल्यू सही नहीं होती, तब तक सभी <code>name=value</code> पेयर, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.
टैग: action_command_lines
--allowed_cpu_values=<comma-separated set of options> default: "": --cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs
--[no]android_databinding_use_androidx default: "true": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args default: "true": 3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> default: "off": इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तब Android के नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. ALPHABETICAL का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से पाथ के हिसाब से क्रम से लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस तरह से क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip default: "auto": Build python executable zip; on on Windows, off on other platforms
Tags: affects_outputs
--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ऐसी सूची जिसमें Apple Catalyst बाइनरी बनाने के लिए, आर्किटेक्चर को कॉमा लगाकर अलग किया गया हो.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage default: "false": अगर बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild": इससे यह तय किया जाता है कि बाइनरी किस मोड में बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> कई बार इस्तेमाल किया गया हो: gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> default: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs
--cxxopt=<a string> कई बार इस्तेमाल किया गया हो: C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, सबसे बाद वाली वैल्यू का इस्तेमाल किया जाता है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> default: "default": इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_propeller_optimize_absolute_paths default: "true": अगर यह सेट है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_remaining_fdo_absolute_paths default: "true": अगर यह नीति सेट की जाती है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs
--[no]enable_runfiles default: "auto": runfiles symlink ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows पर बंद होता है और अन्य प्लैटफ़ॉर्म पर चालू होता है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो: अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. action_listener का इस्तेमाल करके, मौजूदा बिल्ड ऐक्शन में extra_action अटैच करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources default: "false": एपीके में Java संसाधनों को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 default: "true": android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_rewrite_dexes_with_rex default: "false": use rex tool to rewrite dex files
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files default: "false": अगर बताया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental
--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1": इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines
--[no]experimental_omitfp default: "false": अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> default: "off": आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution
--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो: हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir default: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_py_binaries_include_label default: "false": py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap default: "false": अगर collect_code_coverage चालू है, तो Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true": कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental
--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है. जैसे, `//foo/bar:file.afdo`. इसके लिए, आपको संबंधित पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है. साथ ही, यह `fdo_profile` टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, `fdo_profile` नियम की जगह लागू होगा.
टैग: affects_outputs
--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कैश मेमोरी प्रीफ़ेच करने के लिए, हिंट का इस्तेमाल करें.
टैग: affects_outputs
--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.
टैग: affects_outputs
--features=<a string> कई बार इस्तेमाल किया गया हो: टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं. --host_features भी देखें
टैग: changes_inputs, affects_outputs
--[no]force_pic default: "false": अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय पीआईसी प्री-बिल्ट लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.
टैग: loading_and_analysis, affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह उन एनवायरमेंट वैरिएबल का सेट तय करता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt> default: "opt": बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल के मोड के बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C कंपाइलर को पास करने का अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है. हालांकि, C++ सोर्स फ़ाइलों को कंपाइल करते समय इसका इस्तेमाल नहीं किया जाता.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> default: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास किए जाने वाले अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_features=<a string> कई बार इस्तेमाल किया गया हो: दी गई सुविधाएं, exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs
--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: यह exec कॉन्फ़िगरेशन के लिए Python के वर्शन को बदलता है. इसे "PY2" या "PY3" पर सेट किया जा सकता है.
टैग: loading_and_analysis, affects_outputs
--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: होस्ट टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है. हालांकि, bar.cc में यह विकल्प नहीं जोड़ा जाता.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups default: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory default: "true": अगर सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में शामिल किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets default: "false": कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]": कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ ऐसे नियमों को लागू किया जाता है जो टेस्ट नहीं किए गए हैं. हालांकि, अगर --instrument_test_targets विकल्प चालू है, तो टेस्ट किए गए नियमों को भी लागू किया जा सकता है.
टैग: affects_outputs
--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'ios_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें बताए गए सभी आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive default: "true": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated
--linkopt=<a string> कई बार इस्तेमाल किया गया हो: लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो: LTO के बैकएंड चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो: एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple macOS के बाइनरी फ़ाइलें बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.
टैग: loses_incremental_state, loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs
--[no]objc_debug_with_GLIBCXX default: "false": अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping default: "false": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines
--objccopt=<a string> कई बार इस्तेमाल किया गया हो: Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ बैकएंड ऑब्जेक्ट कंपाइल करते समय, LTO बैकएंड (under --features=thin_lto) को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों की एलटीओ बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis
--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें. Propeller प्रोफ़ाइल में कम से कम दो फ़ाइलों में से एक फ़ाइल होनी चाहिए. ये फ़ाइलें cc प्रोफ़ाइल और ld प्रोफ़ाइल हैं. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस देता है. उदाहरण के लिए, a/b/BUILD में मौजूद BUILD फ़ाइल, लेबल को इस तरह से तय करती है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नेम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]share_native_deps default: "true": अगर यह वैल्यू सही है, तो एक जैसी फ़ंक्शनैलिटी वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs
--[no]stamp default: "false": तारीख, उपयोगकर्ता नाम, होस्टनेम, वर्कस्पेस की जानकारी वगैरह के साथ बाइनरी पर स्टैंप लगाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.
टैग: affects_outputs
--stripopt=<a string> कई बार इस्तेमाल किया गया हो: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple tvOS के बाइनरी फ़ाइलें बनाने के लिए, आर्किटेक्चर की कॉमा लगाकर अलग की गई सूची.
टैग: loses_incremental_state, loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple visionOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.
टैग: affects_outputs

--[no]check_licenses default: "false": देखें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]desugar_for_android default: "true": Java 8 के बाइटकोड को डेक्सिंग से पहले डीशुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs default: "false": लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की सुविधा वाली लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints default: "true": यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps default: "true": Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental
--experimental_import_deps_checking=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कोई कार्रवाई नहीं की गई, इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है
टैग: loading_and_analysis
--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है": इस विकल्प को चालू करने पर, यह पक्का किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल न हों. नीति उल्लंघन ठीक करने के लिए की गई कार्रवाई से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.
टैग: loading_and_analysis
--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default": अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files default: "false": अगर यह चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मिलती-जुलती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains default: "false": इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules default: "false": यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule default: "false": कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]one_version_enforcement_on_java_tests default: "true": इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.
टैग: loading_and_analysis
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: --incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल करने के लिए, अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis
--[no]strict_filesets default: "false": अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> default: "off": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes default: "false": अगर यह वैल्यू सही है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित किए जाने चाहिए.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2": APK पर साइन करने के लिए इस्तेमाल किया जाने वाला तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis
--[no]device_debug_entitlements default: "true": अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो हस्ताक्षर करते समय, objc ऐप्लिकेशन में डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs
--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें: iOS पर साइन करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.
टैग: action_command_lines

--[no]incompatible_disallow_legacy_py_provider default: "true": यह कोई कार्रवाई नहीं करता है. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes default: "false": अगर यह सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_alwayslink_by_default default: "false": अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules default: "false": जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures default: "false": अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के इंस्टेंस को AnalysisFailureInfo का इंस्टेंस मिलेगा. इसमें गड़बड़ी की जानकारी होगी. इससे बिल्ड पूरा नहीं होगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन वाले नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure default: "false": अगर dex2oat की कार्रवाई पूरी नहीं होती है, तो टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय, बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो: टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की रकम को बदल देंगे. वैल्यू, HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]<float> (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4) भी हो सकता है. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में तय किए गए संसाधनों से बदल दिया जाता है.
--[no]experimental_android_use_parallel_dex2oat default: "false": android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks default: "false": ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines
--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. उदाहरण के लिए, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची देखी जा सकती है.
टैग: test_runner
--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर पर चलाने या जांच करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner
--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो: इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी वजह से इनमें से कोई भी कोशिश पूरी नहीं होती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू से है. वहीं, regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को तीन बार नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. मिलते-जुलते सबसे हाल के तर्क को प्राथमिकता दी जाती है. अगर कोई भी शर्त पूरी नहीं होती है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.
--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
टैग: test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट के टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करने के लिए कहा जाता है.
--[no]zip_undeclared_test_outputs default: "false": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो बिना बताए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

--[no]experimental_filter_library_jar_with_program_jar default: "false": ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास हटाई जा सकें.
टैग: action_command_lines, experimental
--[no]experimental_inmemory_dotd_files default: "true": अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly default: "false": इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट से जुड़े नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_starlark_cc_import default: "false": यह विकल्प चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning default: "false": क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता है और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental
--[no]incremental_dexing default: "true": यह हर जार फ़ाइल के लिए, अलग से डेक्सिंग का ज़्यादातर काम करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning default: "true": अगर इस विकल्प को सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल किया जाएगा. इससे, objc कंपाइलर को पास किए गए इनपुट के सेट को कम किया जा सकेगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies default: "false": When building a target //a:a, process headers in all targets that //a:a depends on (if header processing is enabled for the toolchain).
टैग: execution
--[no]trim_test_configuration default: "true": यह सुविधा चालू होने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*": टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.
टैग: terminal_output

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py default: "false": इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन पाएं. खास तौर पर, जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इस फ़्लैग को सेट करने पर ही इसे गलत माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed default: "true": अगर यह 'सही है', तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, ऐसे आउटपुट रूट में दिखेंगे जिसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिमलिंक, Python 2 के बजाय Python 3 के टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default default: "true": अगर यह सही है, तो `py_binary` और `py_test` टारगेट, `python_version` या `default_python_version` एट्रिब्यूट सेट नहीं करते हैं. ऐसे में, ये टारगेट डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. इस फ़्लैग को सेट करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py2_outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains default: "true": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के एक्ज़ीक्यूटेबल नेटिव नियम, Python टूलचेन के ज़रिए तय किए गए Python रनटाइम का इस्तेमाल करेंगे. इसके बजाय, वे --python_top जैसे लेगसी फ़्लैग के ज़रिए दिए गए रनटाइम का इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change
--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: Python का मुख्य वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट से बदला जाता है. भले ही, वे साफ़ तौर पर किसी वर्शन के बारे में न बताते हों. इसलिए, आम तौर पर इस फ़्लैग को सप्लाई करने की कोई वजह नहीं होती.
टैग: loading_and_analysis, affects_outputs

--[no]cache_test_results [-t] default: "auto": अगर इसे 'auto' पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें बाहरी के तौर पर मार्क नहीं किया गया है. 'नहीं' पर सेट होने पर, Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.
--[no]experimental_cancel_concurrent_tests default: "never": अगर 'on_failed' या 'on_passed' है, तो Blaze उस नतीजे के साथ पहली बार चलने वाले टेस्ट को रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_fetch_all_coverage_outputs default: "false": अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_generate_llvm_lcov default: "false": अगर यह विकल्प सही पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_j2objc_header_map default: "true": J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental
--[no]experimental_j2objc_shorter_header_path default: "false": क्या हेडर पाथ को छोटा करके जनरेट करना है. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "javabuilder": इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.
--[no]experimental_limit_android_lint_to_android_constrained_java default: "false": No-op, kept only for backwards compatibility
Tags: affects_outputs, experimental
--[no]experimental_run_android_lint_on_java_rules default: "false": java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs, experimental
--[no]explicit_java_test_deps default: "false": java_test में, TestRunner की deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.
--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, javac को पास करने के लिए अतिरिक्त विकल्प.
--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्डिंग टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये टूल, बिल्ड के दौरान एक्ज़ीक्यूट किए जाते हैं. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support default: "true": अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को तब फ़ेल कर देगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में मौजूद पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, हर शार्ड में सभी टेस्ट चलाएगा.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed default: "true": अगर यह वैल्यू सही है, तो सैंडबॉक्स की गई रणनीति के साथ खास टेस्ट चलाए जाएंगे. 'local' टैग जोड़कर, स्थानीय तौर पर सिर्फ़ एक टेस्ट रन करें
टैग: incompatible_change
--[no]incompatible_strict_action_env default: "false": अगर यह विकल्प सही है, तो Bazel ऐसे एनवायरमेंट का इस्तेमाल करता है जिसमें PATH के लिए स्टैटिक वैल्यू होती है. साथ ही, यह LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने से, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा. ऐसा तब होगा, जब शेयर की गई कैश मेमोरी का इस्तेमाल किया जा रहा हो.
टैग: loading_and_analysis, incompatible_change
--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.
--java_debug: इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इनमें बदल जाता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps default: "true": हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करें. फ़िलहाल, यह जानकारी कंपाइल-टाइम क्लासपाथ के लिए जनरेट की जाती है.
--[no]java_header_compilation default: "true": सोर्स से सीधे तौर पर ijars कंपाइल करें.
--java_language_version=<a string> default: "": Java भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट, इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": Java रनटाइम का वर्शन
--javacopt=<a string> कई बार इस्तेमाल किया गया हो: javac को पास करने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> कई बार इस्तेमाल किया गया हो: Java VM को पास करने के लिए अतिरिक्त विकल्प. इन विकल्पों को हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिया जाएगा.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किए जाने वाले बाइनरी के बारे में बताता है.
--plugin=<a build target label> कई बार इस्तेमाल किया गया हो: बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.
--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प से यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.
--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--[no]proto_profile default: "true": प्रोफ़ाइल_पाथ को प्रोटो कंपाइलर को पास करना है या नहीं.
टैग: affects_outputs, loading_and_analysis
--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल, जो C++ प्रोटो को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि j2objc protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि Java protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि JavaLite protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--protocopt=<a string> कई बार इस्तेमाल किया गया हो: प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs
--[no]runs_per_test_detects_flakes default: "false": अगर यह वैल्यू सही है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.
--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का ऐब्सलूट पाथ. अगर इसे सेट नहीं किया जाता है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन (जो Bazel सर्वर शुरू करता है) पर सेट किया जाता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. जैसे, Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी फ़ाइलों को बनाने या उन्हें चलाने में समस्याएं आ सकती हैं.
टैग: loading_and_analysis
--test_arg=<a string> कई बार इस्तेमाल किया गया हो: यह अतिरिक्त विकल्प और आर्ग्युमेंट तय करता है. इन्हें टेस्ट एक्ज़ीक्यूटेबल को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast default: "false": यह विकल्प, टेस्ट रनर को फ़ेल फ़ास्ट की जानकारी देता है. पहली गड़बड़ी होने पर, टेस्ट रनर को टेस्ट बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'shard_count' BUILD एट्रिब्यूट मौजूद होने पर ही शार्डिंग का इस्तेमाल करने के लिए, 'explicit' का इस्तेमाल करें. 'disabled' को कभी भी टेस्ट शार्डिंग का इस्तेमाल न करने के लिए सेट करें. 'forced=k' का इस्तेमाल, 'shard_count' BUILD एट्रिब्यूट के बावजूद, टेस्टिंग के लिए 'k' शार्ड लागू करने के लिए किया जाता है.
--tool_java_language_version=<a string> default: "": The Java language version used to execute the tools that are needed during a build
--tool_java_runtime_version=<a string> default: "remotejdk_11": बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

बनाने के विकल्प

--[no]check_up_to_date default: "false": बिल्ड न करें. बस यह देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड पूरा हो जाता है. अगर किसी चरण को पूरा करने में कोई गड़बड़ी होती है, तो इसकी सूचना दी जाती है और बिल्ड पूरा नहीं हो पाता.
टैग: execution
--dynamic_local_execution_delay=<an integer> डिफ़ॉल्ट: "1000": अगर बिल्ड के दौरान रिमोट एक्ज़ीक्यूशन कम से कम एक बार तेज़ी से हुआ था, तो लोकल एक्ज़ीक्यूशन को कितने मिलीसेकंड तक डिले किया जाना चाहिए?
टैग: execution, host_machine_resource_optimizations
--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो: दिए गए नेमोनिक के लिए, क्रम से स्थानीय रणनीतियां इस्तेमाल की जाती हैं. सबसे पहले लागू होने वाली रणनीति का इस्तेमाल किया जाता है. उदाहरण के लिए, `worker,sandboxed` उन कार्रवाइयों को चलाता है जो वर्कर रणनीति का इस्तेमाल करके पर्सिस्टेंट वर्कर के साथ काम करती हैं. साथ ही, अन्य सभी कार्रवाइयों को सैंडबॉक्स वाली रणनीति का इस्तेमाल करके चलाता है. अगर कोई नेमोनिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी नेमोनिक के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `worker,sandboxed` होती है. अगर`experimental_local_lockfree_output` सेट है, तो यह सूची `worker,sandboxed,standalone` होती है. Takes [mnemonic=]local_strategy[,local_strategy,...]
टैग: execution, host_machine_resource_optimizations
--dynamic_remote_strategy=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो: दिए गए नेमोनिक के लिए, क्रम से रिमोट रणनीतियां इस्तेमाल की जाती हैं. सबसे पहले लागू होने वाली रणनीति का इस्तेमाल किया जाता है. अगर कोई नेमोनिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी नेमोनिक के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `remote` होती है. इसलिए, आम तौर पर इस फ़्लैग को साफ़ तौर पर सेट करने की ज़रूरत नहीं होती. Takes [mnemonic=]remote_strategy[,remote_strategy,...]
टैग: execution, host_machine_resource_optimizations
--experimental_docker_image=<a string> default: "": डॉकटर इमेज का वह नाम (जैसे, "ubuntu:latest") डालें जिसका इस्तेमाल, सैंडबॉक्स किए गए ऐक्शन को एक्ज़ीक्यूट करने के लिए किया जाना चाहिए. ऐसा तब करें, जब docker रणनीति का इस्तेमाल किया जा रहा हो और ऐक्शन में, प्लैटफ़ॉर्म के ब्यौरे में मौजूद remote_execution_properties में पहले से कोई container-image एट्रिब्यूट न हो. इस फ़्लैग की वैल्यू को 'docker run' में पास किया जाता है. इसलिए, यह Docker के सिंटैक्स और मेकैनिज़्म के साथ काम करता है.
टैग: execution
--[no]experimental_docker_use_customized_images default: "true": यह विकल्प चालू होने पर, Docker इमेज का इस्तेमाल करने से पहले, मौजूदा उपयोगकर्ता के यूआईडी और जीआईडी को उसमें शामिल किया जाता है. अगर आपके बिल्ड / टेस्ट इस बात पर निर्भर करते हैं कि कंटेनर में उपयोगकर्ता का नाम और होम डायरेक्ट्री मौजूद है, तो यह ज़रूरी है. यह सुविधा डिफ़ॉल्ट रूप से चालू रहती है. हालांकि, अगर आपके मामले में इमेज को अपने-आप पसंद के मुताबिक बनाने की सुविधा काम नहीं करती है या आपको पता है कि आपको इसकी ज़रूरत नहीं है, तो इसे बंद किया जा सकता है.
टैग: execution
--[no]experimental_dynamic_exclude_tools default: "true": इस विकल्प को सेट करने पर, "टूल के लिए" बनाए गए टारगेट, डाइनैमिक तरीके से लागू नहीं होते. ऐसे टारगेट को धीरे-धीरे बढ़ाना बहुत मुश्किल होता है. इसलिए, इन पर लोकल साइकल खर्च करना फ़ायदेमंद नहीं होता.
टैग: execution, host_machine_resource_optimizations
--experimental_dynamic_local_load_factor=<a double> default: "0": इससे यह कंट्रोल किया जाता है कि डाइनैमिक एक्ज़ीक्यूशन से, लोकल मशीन पर कितना लोड डाला जाए. यह फ़्लैग, डाइनैमिक एक्ज़ीक्यूशन में एक साथ शेड्यूल की जाने वाली कार्रवाइयों की संख्या को अडजस्ट करता है. यह इस बात पर निर्भर करता है कि Blaze को कितने सीपीयू उपलब्ध लगते हैं. इसे --local_cpu_resources फ़्लैग की मदद से कंट्रोल किया जा सकता है. अगर इस फ़्लैग की वैल्यू 0 है, तो सभी कार्रवाइयों को तुरंत स्थानीय तौर पर शेड्यूल किया जाता है. अगर वैल्यू > 0 है, तो स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या, उपलब्ध सीपीयू की संख्या के हिसाब से तय होती है. अगर इसकी वैल्यू < 1 है, तो लोड फ़ैक्टर का इस्तेमाल, स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या को कम करने के लिए किया जाता है. ऐसा तब किया जाता है, जब शेड्यूल की जाने वाली कार्रवाइयों की संख्या ज़्यादा हो. इससे क्लीन बिल्ड के मामले में, लोकल मशीन पर लोड कम हो जाता है. इसमें लोकल मशीन का ज़्यादा योगदान नहीं होता.
टैग: execution, host_machine_resource_optimizations
--experimental_dynamic_slow_remote_time=<An immutable length of time.> default: "0": अगर वैल्यू >0 है, तो इसका मतलब है कि डाइनैमिक तरीके से चलने वाली कार्रवाई को सिर्फ़ रिमोट तरीके से तब तक चलना चाहिए, जब तक हम उसे स्थानीय तौर पर चलाने को प्राथमिकता नहीं देते. इससे रिमोट टाइमआउट से बचा जा सकता है. इससे रिमोट एक्ज़ीक्यूशन सिस्टम में कुछ समस्याएं छिप सकती हैं. रिमोट एक्ज़ीक्यूशन से जुड़ी समस्याओं की निगरानी किए बिना, इसे चालू न करें.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_enable_docker_sandbox default: "false": Docker पर आधारित सैंडबॉक्सिंग चालू करें. अगर Docker इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: execution
--[no]experimental_inmemory_sandbox_stashes default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो reuse_sandbox_directories के लिए, स्टैश किए गए सैंडबॉक्स के कॉन्टेंट को मेमोरी में ट्रैक किया जाएगा. इससे, दोबारा इस्तेमाल के दौरान ज़रूरी I/O की मात्रा कम हो जाती है. बिल्ड के हिसाब से, यह फ़्लैग वॉल टाइम को बेहतर बना सकता है. बिल्ड के आधार पर, यह फ़्लैग काफ़ी ज़्यादा मेमोरी इस्तेमाल कर सकता है.
टैग: host_machine_resource_optimizations, execution
--experimental_sandbox_async_tree_delete_idle_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "4": अगर वैल्यू 0 है, तो कार्रवाई पूरी होते ही सैंडबॉक्स ट्री मिटा दें. इससे कार्रवाई पूरी होने में देरी हो सकती है. अगर यह वैल्यू शून्य से ज़्यादा है, तो एसिंक्रोनस थ्रेड पूल पर ऐसे तीन को मिटाएं. जब बिल्ड चल रहा हो, तब इस पूल का साइज़ 1 होता है. जब सर्वर का इस्तेमाल नहीं हो रहा होता है, तब इसका साइज़ इस फ़्लैग से तय होता है.
टैग: host_machine_resource_optimizations, execution
--experimental_sandbox_enforce_resources_regexp=<a valid Java regular expression> default: "": अगर यह वैल्यू true पर सेट है, तो जिन कार्रवाइयों के नेमोनिक, इनपुट किए गए रेगुलर एक्सप्रेशन से मेल खाते हैं उनके लिए संसाधन के अनुरोधों पर सीमाएं लागू की जाएंगी. अगर संसाधन का टाइप इसकी अनुमति देता है, तो --experimental_sandbox_limits की वैल्यू को बदल दिया जाएगा. उदाहरण के लिए, अगर किसी टेस्ट में cpu:3 और resources:memory:10 तय किया गया है, तो वह ज़्यादा से ज़्यादा तीन सीपीयू और 10 मेगाबाइट मेमोरी के साथ चलेगा.
टैग: execution
--experimental_sandbox_limits=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> कई बार इस्तेमाल किया गया हो: अगर वैल्यू > 0 है, तो हर Linux सैंडबॉक्स को तय किए गए संसाधन के लिए, दी गई रकम तक सीमित कर दिया जाएगा. इसके लिए, --incompatible_use_new_cgroup_implementation फ़्लैग की ज़रूरत होती है. साथ ही, यह --experimental_sandbox_memory_limit_mb फ़्लैग को बदल देता है. इसके लिए, cgroups v1 या v2 और उपयोगकर्ताओं को cgroups डायरेक्ट्री का ऐक्सेस देने की अनुमतियां ज़रूरी हैं.
टैग: execution
--experimental_sandbox_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0": अगर वैल्यू > 0 है, तो हर Linux सैंडबॉक्स को दी गई मेमोरी (MB में) के हिसाब से सीमित किया जाएगा. इसके लिए, cgroups v1 या v2 और उपयोगकर्ताओं को cgroups डायरेक्ट्री का ऐक्सेस देने की अनुमतियां ज़रूरी हैं.
टैग: execution
--[no]experimental_shrink_worker_pool default: "false": अगर यह सुविधा चालू है, तो वर्कर पूल को छोटा किया जा सकता है. ऐसा तब होता है, जब वर्कर की मेमोरी पर ज़्यादा दबाव पड़ता है. यह फ़्लैग सिर्फ़ तब काम करता है, जब experimental_total_worker_memory_limit_mb फ़्लैग चालू हो.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_split_xml_generation default: "true": अगर यह फ़्लैग सेट है और टेस्ट ऐक्शन से test.xml फ़ाइल जनरेट नहीं होती है, तो Bazel एक अलग ऐक्शन का इस्तेमाल करके, डमी test.xml फ़ाइल जनरेट करता है. इस फ़ाइल में टेस्ट लॉग होता है. ऐसा न होने पर, Bazel, टेस्ट ऐक्शन के हिस्से के तौर पर test.xml जनरेट करता है.
टैग: execution
--experimental_total_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0": अगर यह सीमा शून्य से ज़्यादा है, तो सभी वर्कर के कुल मेमोरी इस्तेमाल की सीमा से ज़्यादा होने पर, कुछ वर्कर बंद किए जा सकते हैं.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_use_hermetic_linux_sandbox default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो रूट को माउंट न करें. सिर्फ़ sandbox_add_mount_pair के साथ दी गई चीज़ों को माउंट करें. इनपुट फ़ाइलों को सैंडबॉक्स से सिंक करने के बजाय, सैंडबॉक्स से हार्डलिंक किया जाएगा. अगर ऐक्शन इनपुट फ़ाइलें, सैंडबॉक्स से अलग फ़ाइल सिस्टम पर मौजूद हैं, तो इनपुट फ़ाइलों को कॉपी किया जाएगा.
टैग: execution
--[no]experimental_use_semaphore_for_jobs default: "true": अगर इसे सही पर सेट किया जाता है, तो एक साथ चलने वाले जॉब की संख्या को सीमित करने के लिए, सेमाफ़ोर का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution
--[no]experimental_use_windows_sandbox default: "false": कार्रवाइयां करने के लिए, Windows सैंडबॉक्स का इस्तेमाल करें. अगर "हां" है, तो --experimental_windows_sandbox_path से दिया गया बाइनरी मान्य होना चाहिए. साथ ही, यह sandboxfs के साथ काम करने वाले वर्शन से मेल खाना चाहिए. अगर "auto" है, तो हो सकता है कि बाइनरी मौजूद न हो या काम न करे.
टैग: execution
--experimental_windows_sandbox_path=<a string> default: "BazelSandbox.exe": Windows सैंडबॉक्स के बाइनरी का पाथ. इसका इस्तेमाल तब किया जाता है, जब --experimental_use_windows_sandbox की वैल्यू सही होती है. अगर कोई बेयर नेम है, तो PATH में मिले उस नाम के पहले बाइनरी का इस्तेमाल करें.
टैग: execution
--experimental_worker_allowlist=<comma-separated set of options> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह फ़ील्ड खाली नहीं है, तो दी गई वर्कर कुंजी नेमोनिक के साथ सिर्फ़ परसिस्टेंट वर्कर का इस्तेमाल करने की अनुमति दें.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_worker_cancellation default: "false": अगर यह सुविधा चालू है, तो Bazel उन वर्कर को रद्द करने के अनुरोध भेज सकता है जो इस सुविधा के साथ काम करते हैं.
टैग: execution
--experimental_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0": अगर यह सीमा शून्य से ज़्यादा है, तो वर्कर की मेमोरी का इस्तेमाल सीमा से ज़्यादा होने पर, वर्कर बंद किए जा सकते हैं. अगर इस विकल्प का इस्तेमाल, डाइनैमिक एक्ज़ीक्यूशन और `--experimental_dynamic_ignore_local_signals=9` के साथ नहीं किया जाता है, तो आपका बिल्ड क्रैश हो सकता है.
टैग: execution, host_machine_resource_optimizations
--experimental_worker_metrics_poll_interval=<An immutable length of time.> default: "5s": वर्कर मेट्रिक इकट्ठा करने और वर्कर को हटाने की कोशिश करने के बीच का समय. परफ़ॉर्मेंस की वजह से, इसे एक सेकंड से कम नहीं किया जा सकता.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_worker_multiplex_sandboxing default: "false": इस फ़्लैग को चालू करने पर, 'supports-multiplex-sandboxing' की ज़रूरी शर्त पूरी करने वाले मल्टीप्लेक्स वर्कर, सैंडबॉक्स किए गए एनवायरमेंट में काम करेंगे. इसके लिए, हर वर्क अनुरोध के लिए अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल किया जाएगा. जिन मल्टीप्लेक्स वर्कर को एक्ज़ीक्यूट करने की ज़रूरत होती है उन्हें डाइनैमिक एक्ज़ीक्यूशन की रणनीति के तहत हमेशा सैंडबॉक्स किया जाता है. भले ही, यह फ़्लैग सेट किया गया हो या नहीं.
टैग: execution
--[no]experimental_worker_sandbox_hardening default: "false": अगर यह विकल्प चालू है, तो वर्कर को एक सुरक्षित सैंडबॉक्स में चलाया जाता है. हालांकि, ऐसा सिर्फ़ तब किया जाता है, जब लागू करने की सुविधा इसकी अनुमति देती हो. अगर हार्डनिंग की सुविधा चालू है, तो अलग-अलग वर्कर के लिए tmp डायरेक्ट्री अलग-अलग होती हैं.
टैग: execution
--experimental_worker_sandbox_inmemory_tracking=<a string> कई बार इस्तेमाल किया गया हो: यह वर्कर की का नेमोनिक है. इसके लिए, सैंडबॉक्स डायरेक्ट्री के कॉन्टेंट को मेमोरी में ट्रैक किया जाता है. इससे, मेमोरी के ज़्यादा इस्तेमाल की वजह से बिल्ड की परफ़ॉर्मेंस बेहतर हो सकती है. इसका असर सिर्फ़ सैंडबॉक्स किए गए वर्कर पर पड़ता है. अलग-अलग नेमोनिक के लिए, इसे एक से ज़्यादा बार तय किया जा सकता है.
टैग: execution
--[no]experimental_worker_strict_flagfiles default: "false": अगर यह सुविधा चालू है, तो वर्कर के लिए कार्रवाई के ऐसे आर्ग्युमेंट इस्तेमाल करने पर गड़बड़ी होगी जो वर्कर के स्पेसिफ़िकेशन के मुताबिक नहीं हैं. वर्कर आर्ग्युमेंट में, आर्ग्युमेंट की सूची के आखिर में सिर्फ़ एक @flagfile आर्ग्युमेंट होना चाहिए.
टैग: execution
--genrule_strategy=<comma-separated list of options> default: "": बताएं कि जनरूल को कैसे लागू करना है. इस फ़्लैग को धीरे-धीरे हटाया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरूल को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution
--[no]incompatible_sandbox_hermetic_tmp default: "true": इस विकल्प को सही पर सेट करने पर, हर Linux सैंडबॉक्स में अपनी एक खाली डायरेक्ट्री होगी. इसे होस्ट फ़ाइल सिस्टम के साथ /tmp शेयर करने के बजाय, /tmp के तौर पर माउंट किया जाएगा. सभी सैंडबॉक्स में होस्ट के/tmp को देखने के लिए, --sandbox_add_mount_pair=/tmp का इस्तेमाल करें.
टैग: execution
--[no]incompatible_use_new_cgroup_implementation default: "false": अगर यह वैल्यू सही है, तो cgroup के लिए नए तरीके का इस्तेमाल करें. पुराना तरीका सिर्फ़ मेमोरी कंट्रोलर के साथ काम करता है और --experimental_sandbox_limits की वैल्यू को अनदेखा करता है.
टैग: execution
--[no]internal_spawn_scheduler default: "true": यह प्लेसहोल्डर विकल्प है, ताकि हम Blaze में यह बता सकें कि स्पॉन शेड्यूलर चालू था या नहीं.
टैग: execution, host_machine_resource_optimizations
--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> [-j] default: "auto": एक साथ चलने वाले जॉब की संख्या. यह पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, विकल्प के तौर पर कोई कार्रवाई ([-|*]<float>) की जा सकती है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". वैल्यू, 1 से 5000 के बीच होनी चाहिए. 2500 से ज़्यादा वैल्यू होने पर, मेमोरी से जुड़ी समस्याएं हो सकती हैं. "auto" विकल्प, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू का हिसाब लगाता है.
टैग: host_machine_resource_optimizations, execution
--[no]keep_going [-k] डिफ़ॉल्ट: "false": गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उन पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto": लोडिंग/विश्लेषण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto" वैल्यू, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करती है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration
--[no]reuse_sandbox_directories default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स किए गए नॉन-वर्कर एक्ज़ीक्यूशन के लिए इस्तेमाल की गई डायरेक्ट्री को फिर से इस्तेमाल किया जा सकता है. इससे सेटअप करने में लगने वाले गैर-ज़रूरी खर्च से बचा जा सकता है.
टैग: host_machine_resource_optimizations, execution
--sandbox_base=<a string> default: "": इस पाथ के नीचे सैंडबॉक्स को अपनी सैंडबॉक्स डायरेक्ट्री बनाने की अनुमति देता है. अगर आपके बिल्ड /टेस्ट में कई इनपुट फ़ाइलें हैं, तो परफ़ॉर्मेंस को बेहतर बनाने के लिए, tmpfs पर कोई पाथ (जैसे कि/run / shm) तय करें. ध्यान दें: कार्रवाइयां चलाने से जनरेट होने वाली आउटपुट और इंटरमीडिएट फ़ाइलों को सेव करने के लिए, आपके पास tmpfs पर ज़रूरत के मुताबिक रैम और खाली जगह होनी चाहिए.
टैग: host_machine_resource_optimizations, execution
--[no]sandbox_explicit_pseudoterminal default: "false": सैंडबॉक्स की गई कार्रवाइयों के लिए, स्यूडो टर्मिनल बनाने की सुविधा को साफ़ तौर पर चालू करें. कुछ Linux डिस्ट्रिब्यूशन में, सैंडबॉक्स के अंदर प्रोसेस का ग्रुप आईडी 'tty' पर सेट करना ज़रूरी होता है, ताकि स्यूडोटर्मिनल काम कर सकें. अगर इसकी वजह से समस्याएं आ रही हैं, तो इस फ़्लैग को बंद किया जा सकता है, ताकि अन्य ग्रुप का इस्तेमाल किया जा सके.
टैग: execution
--sandbox_tmpfs_path=<an absolute path> कई बार इस्तेमाल किया गया हो: सैंडबॉक्स की गई कार्रवाइयों के लिए, इस ऐब्सलूट पाथ पर एक खाली डायरेक्ट्री माउंट करें. ऐसा तब करें, जब सैंडबॉक्सिंग लागू करने की सुविधा उपलब्ध हो. अगर यह सुविधा उपलब्ध नहीं है, तो इसे अनदेखा कर दिया जाएगा.
टैग: host_machine_resource_optimizations, execution
--[no]skip_incompatible_explicit_targets default: "false": कमांड लाइन पर साफ़ तौर पर दिए गए ऐसे टारगेट छोड़ें जो काम नहीं करते. डिफ़ॉल्ट रूप से, ऐसे टारगेट बनाने पर गड़बड़ी होती है. हालांकि, इस विकल्प के चालू होने पर, इन्हें चुपचाप तरीके से छोड़ दिया जाता है. देखें: https://bazel.build/extending/platforms#skipping-incompatible-targets
टैग: loading_and_analysis
--spawn_strategy=<comma-separated list of options> default: "": इससे यह तय किया जाता है कि स्पॉन की कार्रवाइयों को डिफ़ॉल्ट रूप से कैसे लागू किया जाता है. यह सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार करता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली ऐसी रणनीति चुनता है जो कार्रवाई को पूरा कर सकती है. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" होती है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution
--strategy=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो: बताएं कि अन्य स्पॉन कार्रवाइयों के कंपाइलेशन को कैसे डिस्ट्रिब्यूट करना है. यह सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार करता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली ऐसी रणनीति चुनता है जो कार्रवाई को पूरा कर सकती है. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" होती है. यह फ़्लैग, --spawn_strategy से सेट की गई वैल्यू को बदल देता है. साथ ही, अगर इसका इस्तेमाल नेमोनिक Genrule के साथ किया जाता है, तो यह --genrule_strategy से सेट की गई वैल्यू को भी बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution
--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> कई बार इस्तेमाल किया गया हो: यह तय करें कि regex_filter से मेल खाने वाले ब्यौरे वाले स्पॉन ऐक्शन को लागू करने के लिए, किस स्पॉन रणनीति का इस्तेमाल किया जाना चाहिए. regex_filter मैचिंग के बारे में ज़्यादा जानने के लिए, --per_file_copt देखें. ब्यौरे से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. यह विकल्प, रणनीति तय करने के लिए अन्य फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि अगर कार्रवाइयों के ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो लोकल रणनीति का इस्तेमाल करके कार्रवाइयां चलाएं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed, 'Compiling //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा. हालांकि, क्रम बदलने पर इसे 'sandboxed' रणनीति के साथ चलाया जाएगा.
टैग: execution
--worker_extra_flag=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: ये अतिरिक्त कमांड-फ़्लैग हैं. इन्हें वर्कर प्रोसेस में पास किया जाएगा. ये --persistent_worker के साथ-साथ नेमोनिक के हिसाब से तय किए जाते हैं. जैसे, --worker_extra_flag=Javac=--debug.
टैग: execution, host_machine_resource_optimizations
--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> कई बार इस्तेमाल किया गया हो: अगर 'worker' रणनीति का इस्तेमाल किया जाता है, तो हर तरह के परसिस्टेंट वर्कर के कितने इंस्टेंस लॉन्च किए जा सकते हैं. इसे [name=value] के तौर पर तय किया जा सकता है, ताकि हर निमोनिक के लिए अलग वैल्यू दी जा सके. यह सीमा वर्कर कुंजियों पर आधारित होती है. इन्हें नेमोनिक के आधार पर अलग-अलग किया जाता है. हालांकि, इन्हें स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में हर नेमोनिक के लिए, इस फ़्लैग में बताई गई संख्या से ज़्यादा वर्कर हो सकते हैं. यह पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, विकल्प के तौर पर कोई कार्रवाई ([-|*]<float>) की जा सकती है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 'auto' वैल्यू, मशीन की क्षमता के आधार पर डिफ़ॉल्ट वैल्यू का हिसाब लगाती है. "=value" से, ऐसे निमोनिक के लिए डिफ़ॉल्ट वैल्यू सेट की जाती है जिनके बारे में जानकारी नहीं दी गई है.
टैग: execution, host_machine_resource_optimizations
--worker_max_multiplex_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> कई बार इस्तेमाल किया गया हो: अगर --worker_multiplex के साथ 'worker' रणनीति का इस्तेमाल किया जाता है, तो मल्टीप्लेक्स वर्कर प्रोसेस को एक साथ कितने WorkRequest मिल सकते हैं. इसे [name=value] के तौर पर तय किया जा सकता है, ताकि हर निमोनिक के लिए अलग वैल्यू दी जा सके. यह सीमा वर्कर कुंजियों पर आधारित होती है. इन्हें नेमोनिक के आधार पर अलग-अलग किया जाता है. हालांकि, इन्हें स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में हर नेमोनिक के लिए, इस फ़्लैग में बताई गई संख्या से ज़्यादा वर्कर हो सकते हैं. यह पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, विकल्प के तौर पर कोई कार्रवाई ([-|*]<float>) की जा सकती है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 'auto' वैल्यू, मशीन की क्षमता के आधार पर डिफ़ॉल्ट वैल्यू का हिसाब लगाती है. "=value" से, ऐसे निमोनिक के लिए डिफ़ॉल्ट वैल्यू सेट की जाती है जिनके बारे में जानकारी नहीं दी गई है.
टैग: execution, host_machine_resource_optimizations
--[no]worker_multiplex default: "true": यह सुविधा चालू होने पर, वर्कर मल्टीप्लेक्सिंग का इस्तेमाल करेंगे. हालांकि, ऐसा सिर्फ़ तब होगा, जब वे मल्टीप्लेक्सिंग के साथ काम करते हों.
टैग: execution, host_machine_resource_optimizations
--[no]worker_quit_after_build default: "false": इस फ़्लैग के चालू होने पर, बिल्ड पूरा होने के बाद सभी वर्कर बंद हो जाते हैं.
टैग: execution, host_machine_resource_optimizations
--[no]worker_sandboxing default: "false": अगर यह विकल्प चालू है, तो सिंगलप्लेक्स वर्कर, सैंडबॉक्स वाले एनवायरमेंट में काम करेंगे. डाइनैमिक एक्ज़ीक्यूशन की रणनीति के तहत काम करने वाले सिंगलप्लेक्स वर्कर को हमेशा सैंडबॉक्स किया जाता है. भले ही, यह फ़्लैग मौजूद हो या न हो.
टैग: execution
--[no]worker_verbose default: "false": चालू होने पर, वर्कर शुरू होने, बंद होने वगैरह पर ज़्यादा जानकारी वाले मैसेज प्रिंट करता है...

--[no]build default: "true": बिल्ड को एक्ज़ीक्यूट करें. यह सामान्य प्रोसेस है. --nobuild विकल्प का इस्तेमाल करने पर, बिल्ड की प्रोसेस, बिल्ड ऐक्शन को लागू करने से पहले ही रुक जाती है. अगर पैकेज लोड करने और विश्लेषण करने के चरण पूरे हो जाते हैं, तो यह शून्य दिखाता है. यह मोड, इन चरणों की जांच करने के लिए काम का है.
टैग: execution, affects_outputs
--[no]experimental_use_validation_aspect default: "false": क्या पुष्टि करने वाली कार्रवाइयों को पहलू का इस्तेमाल करके चलाना है, ताकि टेस्ट के साथ पैरलल तरीके से काम किया जा सके.
टैग: execution, affects_outputs
--output_groups=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इनमें से हर नाम के पहले, + या - का निशान लगाया जा सकता है. + के निशान वाले ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ा जाता है, जबकि - के निशान वाले ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप में प्रीफ़िक्स नहीं लगाया गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट शामिल नहीं किया जाएगा. उदाहरण के लिए, --output_groups=+foo,+bar से डिफ़ॉल्ट सेट, foo, और bar का यूनीयन बनता है. वहीं, --output_groups=foo,bar से डिफ़ॉल्ट सेट ओवरराइड हो जाता है, ताकि सिर्फ़ foo और bar बन सकें.
टैग: execution, affects_outputs
--[no]run_validations default: "true": बिल्ड के दौरान, पुष्टि करने वाली कार्रवाइयां करनी हैं या नहीं. https://bazel.build/extending/rules#validation_actions पर जाएं
टैग: execution, affects_outputs
--serialized_frontier_profile=<a string> default: "": सीरियलाइज़ किए गए फ़्रंटियर बाइट की प्रोफ़ाइल डंप करता है. इससे आउटपुट पाथ के बारे में पता चलता है.
टैग: bazel_monitoring

--aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए उन पहलुओं की सूची जिन्हें टॉप-लेवल के टारगेट पर लागू किया जाना है. अगर सूची में शामिल कुछ_आस्पेक्ट, ज़रूरी आसपेक्ट प्रोवाइडर के लिए required_aspect_providers का इस्तेमाल करता है, तो कुछ_आस्पेक्ट, आसपेक्ट की सूची में उससे पहले बताए गए हर उस आसपेक्ट के बाद चलेगा जिसके विज्ञापित प्रोवाइडर, कुछ_आस्पेक्ट के ज़रूरी आसपेक्ट प्रोवाइडर की शर्तों को पूरा करते हैं. इसके अलावा, requires एट्रिब्यूट से तय किए गए सभी ज़रूरी पहलुओं के बाद, some_aspect चलेगा. इसके बाद, some_aspect के पास उन पहलुओं के प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, उदाहरण के लिए '//tools:my_def.bzl%my_aspect'. इसमें 'my_aspect' एक टॉप-लेवल वैल्यू है, जो tools/my_def.bzl फ़ाइल से ली गई है
--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1": बीईपी आर्टफ़ैक्ट अपलोड करते समय, ज़्यादा से ज़्यादा इतनी फ़ाइलें खुली होनी चाहिए.
टैग: affects_outputs
--[no]experimental_convenience_symlinks default: "normal": इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिए बनाए गए सिंबल लिंक (ऐसे सिंबल लिंक जो बिल्ड के बाद वर्कस्पेस में दिखते हैं) को कैसे मैनेज किया जाएगा. संभावित वैल्यू: normal (डिफ़ॉल्ट): बिल्ड के हिसाब से, हर तरह का सुविधा वाला सिंबल लिंक बनाया या मिटाया जाएगा. clean: सभी सिमलंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: इस विकल्प को चुनने पर, सिंबॉलिक लिंक न तो बनाए जाएंगे और न ही हटाए जाएंगे. log_only: 'normal' को पास किए जाने पर, लॉग मैसेज जनरेट करें. हालांकि, फ़ाइल सिस्टम से जुड़ी कोई भी कार्रवाई न करें. यह टूल के लिए फ़ायदेमंद है. ध्यान दें कि सिर्फ़ उन सिमलंक पर असर पड़ सकता है जिनके नाम, --symlink_prefix की मौजूदा वैल्यू से जनरेट किए गए हैं. अगर प्रीफ़िक्स बदलता है, तो पहले से मौजूद किसी भी सिमलंक पर कोई असर नहीं पड़ेगा.
टैग: affects_outputs
--[no]experimental_convenience_symlinks_bep_event default: "true": यह फ़्लैग कंट्रोल करता है कि हम BuildEventProtocol में build eventConvenienceSymlinksIdentified पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में convenienceSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके वर्कस्पेस में बनाए गए सभी सुविधा वाले सिंबल लिंक की सूची होगी. अगर यह वैल्यू 'गलत है', तो BuildEventProtocol में convenienceSymlinksIdentified एंट्री खाली होगी.
टैग: affects_outputs
--remote_download_all: इस विकल्प से, सभी रिमोट आउटपुट को लोकल मशीन पर डाउनलोड किया जाता है. यह फ़्लैग, --remote_download_outputs=all का एलियास है.
इनके लिए उपलब्ध है:
--remote_download_outputs=all

टैग: affects_outputs
--remote_download_minimal: यह लोकल मशीन पर, रिमोट बिल्ड के किसी भी आउटपुट को डाउनलोड नहीं करता है. यह फ़्लैग, --remote_download_outputs=minimal का अन्य नाम है.
इनके लिए उपलब्ध है:
--remote_download_outputs=minimal

टैग: affects_outputs
--remote_download_outputs=<all, minimal or toplevel> default: "toplevel": 'कम से कम' पर सेट होने पर, रिमोट बिल्ड के किसी भी आउटपुट को लोकल मशीन पर डाउनलोड नहीं करता है. हालांकि, स्थानीय कार्रवाइयों के लिए ज़रूरी आउटपुट डाउनलोड किए जाते हैं. 'toplevel' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह टॉप लेवल के टारगेट के आउटपुट को भी लोकल मशीन पर डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की वजह से बिल्ड होने में ज़्यादा समय लगता है, तो इन दोनों विकल्पों से बिल्ड होने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs
--remote_download_symlink_template=<a string> default: "": रिमोट बिल्ड के आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबॉलिक लिंक बनाएं. सिंबॉलिक लिंक के टारगेट को टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये ऑब्जेक्ट के हैश और साइज़ को बाइट में दिखाते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक ऐसे FUSE फ़ाइल सिस्टम की ओर ले जा सकते हैं जो CAS से ऑब्जेक्ट को ज़रूरत के हिसाब से लोड करता है.
टैग: affects_outputs
--remote_download_toplevel: यह सिर्फ़ टॉप लेवल के टारगेट के रिमोट आउटपुट को स्थानीय मशीन पर डाउनलोड करता है. यह फ़्लैग, --remote_download_outputs=toplevel के लिए उपनाम है.
इनके लिए उपलब्ध है:
--remote_download_outputs=toplevel

टैग: affects_outputs
--symlink_prefix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह प्रीफ़िक्स, बिल्ड के बाद बनाए गए किसी भी सुविधा वाले सिमलंक के पहले जोड़ा जाता है. अगर इसे शामिल नहीं किया जाता है, तो डिफ़ॉल्ट वैल्यू, बिल्ड टूल का नाम और उसके बाद हाइफ़न होती है. अगर '/' पास किया जाता है, तो कोई सिमलंक नहीं बनाया जाता और कोई चेतावनी नहीं दी जाती. चेतावनी: '/' के लिए खास सुविधा जल्द ही बंद हो जाएगी. इसके बजाय, --experimental_convenience_symlinks=ignore का इस्तेमाल करें.
टैग: affects_outputs

--[no]experimental_docker_privileged default: "false": इस विकल्प के चालू होने पर, Bazel, कार्रवाइयां करते समय 'docker run' को --privileged फ़्लैग पास करेगा. यह आपके बिल्ड के लिए ज़रूरी हो सकता है. हालांकि, इससे हर्मेटिकनेस कम हो सकता है.
टैग: execution
--[no]experimental_sandboxfs_map_symlink_targets default: "false": No-op
टैग: host_machine_resource_optimizations, execution
--[no]incompatible_legacy_local_fallback default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स की गई रणनीति से स्थानीय रणनीति पर लेगसी इंप्लिसिट फ़ॉलबैक की सुविधा चालू हो जाती है. यह फ़्लैग आखिर में डिफ़ॉल्ट रूप से 'बंद है' पर सेट हो जाएगा. इसके बाद, यह काम नहीं करेगा. फ़ॉलबैक को कॉन्फ़िगर करने के लिए, --strategy, --spawn_strategy या --dynamic_local_strategy का इस्तेमाल करें.
टैग: execution, incompatible_change
--sandbox_add_mount_pair=<a single path or a 'source:target' pair> कई बार इस्तेमाल किया गया हो: सैंडबॉक्स में माउंट करने के लिए, अतिरिक्त पाथ पेयर जोड़ें.
टैग: execution
--sandbox_block_path=<a string> कई बार इस्तेमाल किया गया हो: सैंडबॉक्स की गई कार्रवाइयों के लिए, इस पाथ का ऐक्सेस न दें.
टैग: execution
--[no]sandbox_default_allow_network default: "true": कार्रवाइयों के लिए, नेटवर्क ऐक्सेस को डिफ़ॉल्ट रूप से अनुमति दें. ऐसा हो सकता है कि यह सुविधा, सैंडबॉक्सिंग की सभी सुविधाओं के साथ काम न करे.
टैग: execution
--[no]sandbox_fake_hostname default: "false": सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग: execution
--[no]sandbox_fake_username default: "false": सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'nobody' में बदलें.
टैग: execution
--sandbox_writable_path=<a string> कई बार इस्तेमाल किया गया हो: सैंडबॉक्स की गई कार्रवाइयों के लिए, सैंडबॉक्स में मौजूद किसी डायरेक्ट्री को लिखने लायक बनाएं. अगर सैंडबॉक्सिंग लागू करने की सुविधा काम करती है, तो इसे अनदेखा कर दिया जाता है.
टैग: execution

--[no]incompatible_config_setting_private_default_visibility default: "false": अगर incompatible_enforce_config_setting_visibility=false है, तो यह एक noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होगी. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enforce_config_setting_visibility default: "true": अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है', तो हर config_setting, हर टारगेट को दिखेगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

--[no]check_tests_up_to_date default: "false": टेस्ट न चलाएं, बस यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी टेस्ट के नतीजे अप-टू-डेट हैं, तो टेस्टिंग पूरी हो जाती है. अगर किसी टेस्ट को बनाने या उसे लागू करने की ज़रूरत होती है, तो गड़बड़ी की सूचना दी जाती है और टेस्टिंग पूरी नहीं हो पाती. इस विकल्प का मतलब है कि --check_up_to_date का इस्तेमाल किया गया है.
टैग: execution
--flaky_test_attempts=<a positive integer, the string "default", or test_regex@attempts. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो: अगर कोई टेस्ट फ़ेल हो जाता है, तो उसे तय की गई संख्या तक फिर से आज़माया जाएगा. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश करनी पड़ी उन्हें टेस्ट की खास जानकारी में 'FLAKY' के तौर पर मार्क किया जाता है. आम तौर पर, दी गई वैल्यू सिर्फ़ एक पूर्णांक या 'default' स्ट्रिंग होती है. अगर यह पूर्णांक है, तो सभी टेस्ट N बार चलाए जाएंगे. अगर 'default' चुना जाता है, तो सामान्य टेस्ट के लिए सिर्फ़ एक बार टेस्ट किया जाएगा. साथ ही, जिन टेस्ट को उनके नियम के हिसाब से साफ़ तौर पर फ़्लेकी के तौर पर मार्क किया गया है (flaky=1 एट्रिब्यूट), उनके लिए तीन बार टेस्ट किया जाएगा. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. यहां flaky_test_attempts ऊपर दिए गए तरीके से तय किए जाते हैं. साथ ही, regex_filter में शामिल और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची होती है. --runs_per_test भी देखें. उदाहरण: --flaky_test_attempts=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार छोड़कर, foo/bar में मौजूद सभी टेस्ट को तीन बार डीफ़्लेक करता है. इस विकल्प को कई बार पास किया जा सकता है. मिलते-जुलते सबसे हाल के तर्क को प्राथमिकता दी जाती है. अगर कोई भी शर्त पूरी नहीं होती है, तो 'default' के तौर पर ऊपर दिया गया तरीका लागू होता है.
टैग: execution
--local_test_jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto": एक साथ चलाए जा सकने वाले लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. यह पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, विकल्प के तौर पर कोई कार्रवाई ([-|*]<float>) की जा सकती है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 0 का मतलब है कि लोकल संसाधनों का इस्तेमाल करके, एक साथ चलाए जा सकने वाले लोकल टेस्ट जॉब की संख्या को सीमित किया जाएगा. इसे --jobs की वैल्यू से ज़्यादा पर सेट करने से कोई फ़र्क़ नहीं पड़ता.
टैग: execution
--[no]test_keep_going default: "true": इसे बंद करने पर, टेस्ट पास न करने वाला कोई भी बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट चलाए जाते हैं. भले ही, कुछ टेस्ट पास न हुए हों.
टैग: execution
--test_strategy=<a string> default: "": यह कुकी बताती है कि टेस्ट चलाते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution
--test_tmpdir=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह 'bazel test' के लिए, बुनियादी अस्थायी डायरेक्ट्री के बारे में बताता है.

--cache_computed_file_digests=<a long integer> default: "50000": अगर यह वैल्यू 0 से ज़्यादा है, तो Bazel को कॉन्फ़िगर किया जाता है. इससे Bazel, फ़ाइल डाइजेस्ट को मेमोरी में कैश कर लेता है. ऐसा वह फ़ाइल के मेटाडेटा के आधार पर करता है. इससे, जब भी फ़ाइल डाइजेस्ट की ज़रूरत होती है, तो Bazel को डिस्क से डाइजेस्ट को फिर से कंप्यूट नहीं करना पड़ता. इसे 0 पर सेट करने से, यह पक्का किया जा सकता है कि फ़ाइल में किए गए सभी बदलावों को ट्रैक किया जा रहा है. ऐसा इसलिए, क्योंकि फ़ाइल के मेटाडेटा से सभी बदलावों का पता नहीं लगाया जा सकता. जब इसकी वैल्यू 0 नहीं होती है, तो यह कैश मेमोरी के साइज़ को दिखाता है. यह कैश मेमोरी में सेव किए जाने वाले फ़ाइल डाइजेस्ट की संख्या के तौर पर दिखता है.
--[no]experimental_cpu_load_scheduling default: "false": इससे सीपीयू लोड के आधार पर, एक्सपेरिमेंट के तौर पर स्थानीय एक्ज़ीक्यूशन को शेड्यूल किया जा सकता है. इसमें एक-एक करके कार्रवाइयों का अनुमान नहीं लगाया जाता. एक्सपेरिमेंट के तौर पर उपलब्ध शेड्यूलिंग की सुविधा से, ज़्यादा कोर वाले पावरफ़ुल कंप्यूटर पर स्थानीय तौर पर बनाए गए बड़े बिल्ड को काफ़ी फ़ायदा मिला है. इसे --local_resources=cpu=HOST_CPUS के साथ इस्तेमाल करने का सुझाव दिया जाता है
टैग: execution
--experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers> डिफ़ॉल्ट: ब्यौरा देखें: यह ओएस सिग्नल नंबर की सूची लेता है. अगर डाइनैमिक एक्ज़ीक्यूशन की कोई लोकल ब्रांच, इनमें से किसी भी सिग्नल की वजह से बंद हो जाती है, तो रिमोट ब्रांच को पूरा होने दिया जाएगा. पर्सिंस्टेंट वर्कर के लिए, इससे सिर्फ़ उन सिग्नल पर असर पड़ता है जो वर्कर प्रोसेस को बंद कर देते हैं.
टैग: execution
--[no]experimental_enable_skyfocus default: "false": अगर यह विकल्प सही है, तो --experimental_working_set का इस्तेमाल चालू करें. इससे इंक्रीमेंटल बिल्ड के लिए, Bazel के मेमोरी फ़ुटप्रिंट को कम किया जा सकता है. इस सुविधा को Skyfocus के नाम से जाना जाता है.
टैग: host_machine_resource_optimizations
--experimental_working_set=<comma-separated list of options> default: "": Skyfocus के लिए वर्किंग सेट. इन्हें कॉमा लगाकर अलग किए गए, वर्कस्पेस के रूट से जुड़े पाथ के तौर पर तय करें. यह एक स्टेटफ़ुल फ़्लैग है. वर्किंग सेट को तय करने से, यह बाद के इनवोकेशन के लिए बना रहता है. हालांकि, इसे नए सेट के साथ फिर से तय किया जा सकता है.
टैग: host_machine_resource_optimizations
--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_CPUS": Bazel के लिए, लोकल सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें. इससे Bazel, स्थानीय तौर पर की गई बिल्ड कार्रवाइयों पर खर्च कर पाएगा. यह पूर्णांक या "HOST_CPUS" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_CPUS*.5 का इस्तेमाल करके, उपलब्ध सीपीयू कोर का आधा हिस्सा इस्तेमाल किया जा सकता है). डिफ़ॉल्ट रूप से, ("HOST_CPUS") Bazel, सिस्टम कॉन्फ़िगरेशन के बारे में क्वेरी करेगा, ताकि उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाया जा सके.
टैग: host_machine_resource_optimizations
--local_extra_resources=<a named float, 'name=value'> कई बार इस्तेमाल किया गया हो: Bazel के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. यह स्ट्रिंग-फ़्लोट पेयर लेता है. इसका इस्तेमाल कई बार किया जा सकता है, ताकि अलग-अलग तरह के अतिरिक्त संसाधनों के बारे में बताया जा सके. Bazel, उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों को सीमित करेगा. जांचें, "resources:<resoucename>:<amount>" फ़ॉर्मैट वाले टैग का इस्तेमाल करके, यह तय कर सकती हैं कि उन्हें कितने अतिरिक्त संसाधनों की ज़रूरत है. इस फ़्लैग की मदद से, उपलब्ध सीपीयू, रैम, और संसाधनों को सेट नहीं किया जा सकता.
टैग: host_machine_resource_optimizations
--local_ram_resources=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_RAM*.67": Bazel के लिए, लोकल होस्ट रैम की कुल मेमोरी (एमबी में) साफ़ तौर पर सेट करें. इसका इस्तेमाल, स्थानीय तौर पर एक्ज़ीक्यूट की गई बिल्ड कार्रवाइयों पर किया जाएगा. यह पूर्णांक या "HOST_RAM" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_RAM*.5 का इस्तेमाल करके, उपलब्ध रैम का आधा हिस्सा इस्तेमाल किया जा सकता है). डिफ़ॉल्ट रूप से, ("HOST_RAM*.67"), Bazel सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा, ताकि उपलब्ध रैम का अनुमान लगाया जा सके. इसके बाद, वह इसका 67% इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations
--local_resources=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> कई बार इस्तेमाल किया गया हो: Bazel के लिए उपलब्ध संसाधनों की संख्या सेट करें. यह फ़्लोट या HOST_RAM/HOST_CPUS को असाइनमेंट में लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए memory=HOST_RAM*.5) का इस्तेमाल किया जा सकता है. इसका इस्तेमाल कई बार किया जा सकता है, ताकि अलग-अलग तरह के संसाधनों के बारे में बताया जा सके. Bazel, उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों को सीमित करेगा. टेस्ट, "resources:<resource name>:<amount>" फ़ॉर्मैट वाले टैग का इस्तेमाल करके, ज़रूरी संसाधनों की संख्या के बारे में बता सकते हैं. यह --local_{cpu|ram|extra}_resources में बताए गए संसाधनों को बदलता है.
टैग: host_machine_resource_optimizations

--build_event_upload_max_retries=<an integer> default: "4": Bazel को बिल्ड इवेंट अपलोड करने की कोशिश ज़्यादा से ज़्यादा कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration
--[no]debug_spawn_scheduler default: "false"
--[no]experimental_bep_target_summary default: "false": TargetSummary इवेंट पब्लिश करने हैं या नहीं.
--[no]experimental_build_event_expand_filesets default: "false": अगर यह वैल्यू सही है, तो आउटपुट फ़ाइलें दिखाते समय बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks default: "false": अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में Fileset के सभी रिलेटिव सिंबल लिंक पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets विकल्प ज़रूरी है.
टैग: affects_outputs
--experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both> कई बार इस्तेमाल किया गया हो: यह तय करें कि TargetComplete/AspectComplete BEP इवेंट में, आउटपुट ग्रुप की फ़ाइलें कैसे दिखाई जाएंगी. वैल्यू, आउटपुट ग्रुप के नाम को 'NAMED_SET_OF_FILES_ONLY', 'INLINE_ONLY' या 'BOTH' में से किसी एक को असाइन की जाती है. डिफ़ॉल्ट वैल्यू 'NAMED_SET_OF_FILES_ONLY' होती है. अगर किसी आउटपुट ग्रुप को दोहराया जाता है, तो दिखने वाली फ़ाइनल वैल्यू का इस्तेमाल किया जाता है. डिफ़ॉल्ट वैल्यू, कवरेज आर्टफ़ैक्ट के लिए मोड को BOTH पर सेट करती है: --experimental_build_event_output_group_mode=baseline.lcov=both
टैग: affects_outputs
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> default: "1s": बीईपी अपलोड न होने पर, एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने के लिए, शुरुआती और कम से कम देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इससे यह चुना जाता है कि बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को कैसे अपलोड करना है.
टैग: affects_outputs
--[no]experimental_docker_verbose default: "false": अगर यह विकल्प चालू है, तो Bazel, Docker सैंडबॉक्स की रणनीति के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करेगा.
टैग: execution
--[no]experimental_materialize_param_files_directly default: "false": अगर पैरामीटर फ़ाइलों को मटीरियलाइज़ किया जा रहा है, तो उन्हें सीधे डिस्क में लिखें.
टैग: execution
--experimental_repository_resolved_file=<a string> default: "": अगर यह खाली नहीं है, तो Starlark वैल्यू लिखें. इसमें Starlark रिपॉज़िटरी के उन सभी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs
--[no]experimental_run_bep_event_include_residue default: "false": क्या रन बिल्ड इवेंट में कमांड-लाइन के बचे हुए हिस्से को शामिल करना है. इसमें बचा हुआ हिस्सा शामिल हो सकता है. डिफ़ॉल्ट रूप से, रन कमांड के बिल्ड इवेंट में रेज़िड्यू शामिल नहीं होता. हालांकि, इसमें रेज़िड्यू शामिल हो सकता है.
टैग: affects_outputs
--experimental_skyfocus_dump_keys=<none, count or verbose> default: "none": Skyfocus को डीबग करने के लिए. फ़ोकस किए गए SkyKeys (रूट, पत्तियां, फ़ोकस किए गए deps, फ़ोकस किए गए rdeps) को डंप करें.
टैग: terminal_output
--[no]experimental_skyfocus_dump_post_gc_stats default: "false": Skyfocus को डीबग करने के लिए. अगर यह विकल्प चालू है, तो फ़ोकस करने से पहले/बाद में मैन्युअल GC को ट्रिगर करें, ताकि हीप साइज़ में हुई कमी की जानकारी दी जा सके. इससे Skyfocus की लेटेन्सी बढ़ जाएगी.
टैग: terminal_output
--experimental_skyfocus_handling_strategy=<strict or warn> default: "strict": वर्किंग सेट के बाहर के बदलावों को मैनेज करने के लिए, Skyfocus की रणनीतियां.
टैग: eagerness_to_exit
--[no]experimental_stream_log_file_uploads default: "false": स्ट्रीम लॉग फ़ाइलें, डिस्क पर लिखने के बजाय सीधे रिमोट स्टोरेज पर अपलोड करता है.
टैग: affects_outputs
--explain=<a path> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प का इस्तेमाल करने पर, बिल्ड सिस्टम, बिल्ड के हर चरण के बारे में जानकारी देता है. वजह को बताई गई लॉग फ़ाइल में लिखा जाता है.
टैग: affects_outputs
--[no]ignore_unsupported_sandboxing default: "false": अगर इस सिस्टम पर सैंडबॉक्स किए गए कोड को चलाने की सुविधा काम नहीं करती है, तो चेतावनी न दिखाएं.
टैग: terminal_output
--[no]legacy_important_outputs default: "false": इस विकल्प का इस्तेमाल करके, TargetComplete इवेंट में लेगसी important_outputs फ़ील्ड जनरेट होने से रोका जा सकता है. Bazel को ResultStore/BTX इंटिग्रेशन के लिए important_outputs की ज़रूरत होती है.
टैग: affects_outputs
--[no]materialize_param_files default: "false": यह रिमोट ऐक्शन एक्ज़ीक्यूशन या कैश मेमोरी का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें लिखता है. कार्रवाइयों को डीबग करते समय यह काम का होता है. यह --subcommands और --verbose_failures से पता चलता है.
टैग: execution
--max_config_changes_to_show=<an integer> default: "3": बिल्ड के विकल्पों में बदलाव होने की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नाम की दी गई संख्या तक दिखाता है. अगर दी गई संख्या -1 है, तो बदले गए सभी विकल्प दिखेंगे.
टैग: terminal_output
--max_test_output_bytes=<an integer> डिफ़ॉल्ट: "-1": यह हर टेस्ट लॉग के लिए ज़्यादा से ज़्यादा साइज़ तय करता है. यह साइज़ तब लागू होता है, जब --test_output की वैल्यू 'errors' या 'all' पर सेट हो. यह विकल्प, टेस्ट के ज़्यादा शोर वाले आउटपुट से आउटपुट को ज़्यादा न भरने में मदद करता है. टेस्ट हेडर को लॉग के साइज़ में शामिल किया जाता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट या तो पूरा होता है या कुछ भी नहीं होता.
टैग: test_runner, terminal_output, execution
--output_filter=<a valid Java regular expression> डिफ़ॉल्ट: ब्यौरा देखें: सिर्फ़ उन नियमों के लिए चेतावनियां और कार्रवाई के आउटपुट दिखाता है जिनके नाम, दिए गए रेगुलर एक्सप्रेशन से मेल खाते हैं.
टैग: affects_outputs
--progress_report_interval=<an integer in 0-3600 range> default: "0": यह विकल्प, अब भी चल रहे कामों की रिपोर्ट के बीच इंतज़ार करने के लिए सेकंड की संख्या तय करता है. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड के बाद और फिर हर मिनट में एक बार प्रोग्रेस की रिपोर्ट दी जाएगी. --curses विकल्प चालू होने पर, हर सेकंड में प्रोग्रेस की जानकारी मिलती है.
टैग: affects_outputs
--remote_print_execution_messages=<failure, success or all> default: "failure": रिमोट एक्ज़ीक्यूशन के मैसेज प्रिंट करने की फ़्रीक्वेंसी चुनें. मान्य वैल्यू ये हैं: `failure` का इस्तेमाल सिर्फ़ उन मामलों में प्रिंट करने के लिए किया जाता है जिनमें जांच पूरी नहीं हो सकी, `success` का इस्तेमाल सिर्फ़ उन मामलों में प्रिंट करने के लिए किया जाता है जिनमें जांच पूरी हो गई, और `all` का इस्तेमाल हमेशा प्रिंट करने के लिए किया जाता है.
टैग: terminal_output
--[no]sandbox_debug default: "false": इससे सैंडबॉक्सिंग की सुविधा के लिए, डीबग करने की सुविधाएं चालू होती हैं. इसमें दो चीज़ें शामिल हैं: पहली, बिल्ड के बाद सैंडबॉक्स के रूट कॉन्टेंट में कोई बदलाव नहीं किया जाता; और दूसरी, यह एक्ज़ीक्यूशन पर डीबग करने से जुड़ी अतिरिक्त जानकारी प्रिंट करता है. इससे Bazel या Starlark के नियमों के डेवलपर को, इनपुट फ़ाइलें मौजूद न होने की वजह से डीबग करने में मदद मिल सकती है.
टैग: terminal_output
--show_result=<an integer> default: "1": बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए, यह बताएं कि उसे अप-टू-डेट किया गया है या नहीं. अगर हां, तो बनाई गई आउटपुट फ़ाइलों की सूची दें. प्रिंट की गई फ़ाइलें, शेल में कॉपी करके चिपकाने के लिए सुविधाजनक स्ट्रिंग होती हैं, ताकि उन्हें एक्ज़ीक्यूट किया जा सके. इस विकल्प के लिए, पूर्णांक आर्ग्युमेंट की ज़रूरत होती है. यह टारगेट की वह थ्रेशोल्ड संख्या होती है जिसके ऊपर, नतीजे की जानकारी प्रिंट नहीं की जाती. इसलिए, शून्य की वजह से मैसेज नहीं दिखता है और MAX_INT की वजह से, नतीजे हमेशा दिखते हैं. डिफ़ॉल्ट रूप से, इसकी वैल्यू एक होती है. अगर किसी टारगेट के लिए कुछ भी नहीं बनाया गया है, तो उसके नतीजों को हटाया जा सकता है, ताकि आउटपुट तय सीमा के अंदर रहे.
टैग: affects_outputs
--[no]subcommands [-s] डिफ़ॉल्ट: "false": बिल्ड के दौरान लागू की गई सब-कमांड दिखाएं. इससे जुड़े फ़्लैग: --execution_log_json_file, --execution_log_binary_file (उप-निर्देशों को टूल के हिसाब से फ़ॉर्मैट की गई फ़ाइल में लॉग करने के लिए).
टैग: terminal_output
--test_output=<summary, errors, all or streamed> default: "summary": इससे आउटपुट का पसंदीदा मोड तय किया जाता है. मान्य वैल्यू ये हैं: 'summary' का इस्तेमाल सिर्फ़ टेस्ट की स्थिति की खास जानकारी दिखाने के लिए किया जाता है, 'errors' का इस्तेमाल फ़ेल हुए टेस्ट के लिए टेस्ट लॉग भी प्रिंट करने के लिए किया जाता है, 'all' का इस्तेमाल सभी टेस्ट के लिए लॉग प्रिंट करने के लिए किया जाता है, और 'streamed' का इस्तेमाल सभी टेस्ट के लिए रीयल टाइम में लॉग दिखाने के लिए किया जाता है. इससे टेस्ट को एक-एक करके स्थानीय तौर पर चलाने के लिए मजबूर किया जाएगा, भले ही --test_strategy की वैल्यू कुछ भी हो.
टैग: test_runner, terminal_output, execution
--test_summary=<short, terse, detailed, none or testcase> डिफ़ॉल्ट: "short": इस विकल्प का इस्तेमाल करके, टेस्ट की खास जानकारी का फ़ॉर्मैट तय किया जाता है. मान्य वैल्यू ये हैं: 'short' का इस्तेमाल सिर्फ़ उन टेस्ट के बारे में जानकारी प्रिंट करने के लिए किया जाता है जिन्हें पूरा किया गया है, 'terse' का इस्तेमाल सिर्फ़ उन टेस्ट के बारे में जानकारी प्रिंट करने के लिए किया जाता है जिन्हें पूरा नहीं किया जा सका, 'detailed' का इस्तेमाल उन टेस्ट केस के बारे में ज़्यादा जानकारी प्रिंट करने के लिए किया जाता है जो पूरे नहीं किए जा सके, 'testcase' का इस्तेमाल टेस्ट केस के रिज़ॉल्यूशन में खास जानकारी प्रिंट करने के लिए किया जाता है. इससे उन टेस्ट केस के बारे में ज़्यादा जानकारी प्रिंट नहीं की जाती जिन्हें पूरा नहीं किया जा सका. 'none' का इस्तेमाल खास जानकारी को हटाने के लिए किया जाता है.
टैग: terminal_output
--[no]verbose_explanations default: "false": अगर --explain विकल्प चालू है, तो इससे जवाब में ज़्यादा जानकारी मिलती है. अगर --explain विकल्प चालू नहीं है, तो इसका कोई असर नहीं होगा.
टैग: affects_outputs
--[no]verbose_failures default: "false": अगर कोई निर्देश पूरा नहीं होता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

--aspects_parameters=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: यह कमांड-लाइन के पहलुओं के पैरामीटर की वैल्यू तय करता है. हर पैरामीटर वैल्यू को <param_name>=<param_value> के ज़रिए तय किया जाता है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param' --aspects सूची में किसी पहलू का पैरामीटर है या सूची में किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. हालांकि, एक ही पैरामीटर को एक से ज़्यादा बार वैल्यू असाइन करने की अनुमति नहीं है.
टैग: loading_and_analysis
--target_pattern_file=<a string> default: "": अगर इसे सेट किया जाता है, तो बिल्ड, कमांड लाइन के बजाय यहां दी गई फ़ाइल से पैटर्न पढ़ेगा. यहां फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न तय करना एक गड़बड़ी है.
टैग: changes_inputs

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: ब्यौरा देखें: यह बताता है कि सर्किट ब्रेकर को किस रणनीति का इस्तेमाल करना है. उपलब्ध रणनीतियां "failure" हैं. विकल्प के लिए अमान्य वैल्यू होने पर, विकल्प सेट न होने पर जैसा व्यवहार होता है वैसा ही व्यवहार होता है.
टैग: execution
--experimental_remote_cache_compression_threshold=<an integer> डिफ़ॉल्ट: "100": zstd का इस्तेमाल करके कंप्रेस/डीकंप्रेस करने के लिए, कम से कम ब्लोब साइज़ ज़रूरी है. जब तक --remote_cache_compression सेट नहीं किया जाता, तब तक यह विकल्प काम नहीं करता.
--experimental_remote_cache_eviction_retries=<an integer> डिफ़ॉल्ट: "5": अगर बिल्ड को रिमोट कैश से जुड़ी ऐसी अस्थायी गड़बड़ी का सामना करना पड़ता है जिसकी वजह से बिल्ड पूरा नहीं हो पाता है, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. यह उदाहरण के लिए तब लागू होता है, जब रिमोट कैश से आर्टफ़ैक्ट हटा दिए जाते हैं या कैश मेमोरी काम नहीं करती है. शून्य से अलग वैल्यू सेट करने पर, --incompatible_remote_use_new_exit_code_for_lost_inputs को डिफ़ॉल्ट रूप से सही पर सेट कर दिया जाएगा. हर कोशिश के लिए, एक नया इनवोकेशन आईडी जनरेट किया जाएगा. अगर आपने इनवोकेशन आईडी जनरेट किया है और इसे --invocation_id के साथ Bazel को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, --incompatible_remote_use_new_exit_code_for_lost_inputs फ़्लैग सेट करें और 39 के एक्ज़िट कोड की जांच करें.
टैग: execution
--[no]experimental_remote_cache_lease_extension default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, बिल्ड के दौरान रिमोट ऐक्शन के आउटपुट के लिए लीज़ को बढ़ा देगा. इसके लिए, वह समय-समय पर रिमोट कैश को `FindMissingBlobs` कॉल भेजेगा. फ़्रीक्वेंसी, `--experimental_remote_cache_ttl` की वैल्यू पर आधारित होती है.
--experimental_remote_cache_ttl=<An immutable length of time.> default: "3h": डाइजेस्ट का हाल ही में रेफ़रंस दिए जाने के बाद, रिमोट कैश में मौजूद ब्लॉब का कम से कम टीटीएल. उदाहरण के लिए, ActionResult या FindMissingBlobs. Bazel, ब्लॉब के टीटीएल के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, इंक्रीमेंटल बिल्ड में GetActionResult को बार-बार कॉल नहीं करता है. वैल्यू को असली टीटीएल से थोड़ा कम पर सेट किया जाना चाहिए, क्योंकि सर्वर के डाइजेस्ट वापस भेजने और Bazel के उन्हें पाने के बीच कुछ समय लगता है.
टैग: execution
--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह उस डायरेक्ट्री का पाथ है जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.
--[no]experimental_remote_discard_merkle_trees default: "true": अगर इसे सही पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़े इनपुट मैपिंग की इन-मेमोरी कॉपी को खारिज कर दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में मौजूद न होने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कंप्यूट करना होगा.
--experimental_remote_downloader=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाना है. grpc, grpcs (TLS की सुविधा के साथ grpc), और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. इस लिंक पर जानकारी पाएं: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback default: "false": अगर रिमोट डाउनलोडर काम नहीं करता है, तो लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.
--[no]experimental_remote_downloader_propagate_credentials default: "false": netrc और क्रेडेंशियल हेल्पर से रिमोट डाउनलोडर सर्वर पर क्रेडेंशियल भेजने हैं या नहीं. सर्वर के लिए, `http_header_url:<url-index>:<header-key>` क्वालिफ़ायर का इस्तेमाल किया जाना चाहिए. इसमें `<url-index>`, FetchBlobRequest के `uris` फ़ील्ड में मौजूद यूआरएल की 0 पर आधारित पोज़िशन होती है. यूआरएल के हिसाब से तय किए गए हेडर को ग्लोबल हेडर से ज़्यादा प्राथमिकता दी जानी चाहिए.
--[no]experimental_remote_execution_keepalive default: "false": रिमोट तरीके से एक्ज़ीक्यूट करने के लिए कॉल के दौरान, कीपअलाइव का इस्तेमाल करना है या नहीं.
--experimental_remote_failure_rate_threshold=<an integer in 0-100 range> default: "10": यह विकल्प, किसी समयावधि के लिए फ़ेल होने की दर को प्रतिशत में सेट करता है. इसके बाद, यह रिमोट कैश/एक्ज़ीक्यूटर को कॉल करना बंद कर देता है. डिफ़ॉल्ट रूप से इसकी वैल्यू 10 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
टैग: execution
--experimental_remote_failure_window_interval=<An immutable length of time.> default: "60s": वह समयावधि जिसमें रिमोट अनुरोधों के फ़ेल होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, फ़ेल होने की अवधि को पूरे एक्ज़ीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution
--[no]experimental_remote_mark_tool_inputs default: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर्सिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache default: "false": अगर इस नीति को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने के लिए, मर्कल ट्री की कैलकुलेशन को मेमोराइज़ किया जाएगा. कैश मेमोरी के फ़ुटप्रिंट को --experimental_remote_merkle_tree_cache_size कंट्रोल करता है.
--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000": रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने के लिए, मेमोइज़ किए जाने वाले मर्कल ट्री की संख्या. सॉफ़्ट रेफ़रंस को मैनेज करने के Java के तरीके के मुताबिक, कैश अपने-आप कम हो जाता है. हालांकि, अगर इसे बहुत ज़्यादा पर सेट किया जाता है, तो मेमोरी से जुड़ी गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड होता है. सबसे सही वैल्यू, प्रोजेक्ट के साइज़ के हिसाब से अलग-अलग होती है. डिफ़ॉल्ट रूप से 1,000 पर सेट होता है.
--experimental_remote_output_service=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट आउटपुट सेवा के एंडपॉइंट का HOST या HOST:PORT. grpc, grpcs (TLS की सुविधा के साथ grpc), और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS बंद करने के लिए, grpc:// या unix: स्कीमा तय करें.
--experimental_remote_output_service_output_path_prefix=<a string> default: "": यह वह पाथ है जिसके तहत, --experimental_remote_output_service से मैनेज की गई आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. बिल्ड के लिए इस्तेमाल की जाने वाली असली आउटपुट डायरेक्ट्री, इस पाथ की डिसेंडेंट होगी. साथ ही, इसका फ़ैसला आउटपुट सेवा करेगी.
--[no]experimental_remote_require_cached default: "false": अगर इस विकल्प को 'चालू है' पर सेट किया जाता है, तो यह ज़रूरी हो जाता है कि रिमोट तरीके से की जा सकने वाली सभी कार्रवाइयों को कैश मेमोरी में सेव किया जाए. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह गैर-निर्धारित समस्याओं को हल करने के लिए उपयोगी है. इससे यह जांच की जा सकती है कि जिन कार्रवाइयों को कैश मेमोरी में सेव किया जाना चाहिए उन्हें कैश मेमोरी में सेव किया गया है या नहीं. साथ ही, यह भी जांच की जा सकती है कि कैश मेमोरी में नए नतीजे गलत तरीके से तो नहीं डाले गए हैं.
--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: ब्यौरा देखें: यह विकल्प, दी गई कॉन्फ़िगरेशन फ़ाइल की मदद से रिमोट कैश मेमोरी की कुंजी को मिटाने की सुविधा चालू करता है. यह फ़ाइल, टेक्स्ट फ़ॉर्मैट में प्रोटोकॉल बफ़र होनी चाहिए (src/main/protobuf/remote_scrubbing.proto देखें). इस सुविधा का मकसद, अलग-अलग प्लैटफ़ॉर्म पर एक्ज़ीक्यूट की जा रही कार्रवाइयों के बीच रिमोट/डिस्क कैश मेमोरी को शेयर करना है. हालांकि, ये कार्रवाइयां एक ही प्लैटफ़ॉर्म को टारगेट करती हैं. इसका इस्तेमाल बहुत सावधानी से करना चाहिए, क्योंकि गलत सेटिंग की वजह से कैश मेमोरी की एंट्री अनजाने में शेयर हो सकती हैं. इससे गलत बिल्ड बन सकते हैं. स्क्रबिंग से, कार्रवाई के तरीके पर कोई असर नहीं पड़ता. इससे सिर्फ़ यह तय होता है कि कार्रवाई के नतीजे को वापस पाने या सेव करने के लिए, रिमोट/डिस्क कैश मेमोरी की कुंजी की गिनती कैसे की जाती है. स्क्रब की गई कार्रवाइयां, रिमोट तरीके से लागू नहीं की जा सकतीं. इसलिए, इन्हें हमेशा स्थानीय तौर पर लागू किया जाएगा. स्क्रबिंग कॉन्फ़िगरेशन में बदलाव करने से, लोकल फ़ाइल सिस्टम या इंटरनल कैश मेमोरी में मौजूद आउटपुट अमान्य नहीं होते. जिन कार्रवाइयों पर असर पड़ा है उन्हें फिर से लागू करने के लिए, क्लीन बिल्ड की ज़रूरत होती है. इस सुविधा का इस्तेमाल करने के लिए, आपको --host_platform को --experimental_platform_in_output_dir (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --incompatible_strict_action_env (एनवायरमेंट वैरिएबल को सामान्य बनाने के लिए) के साथ सेट करना होगा.
--[no]guard_against_concurrent_changes default: "lite": इसे 'full' पर सेट करें, ताकि रिमोट कैश में अपलोड करने से पहले, किसी कार्रवाई की सभी इनपुट फ़ाइलों के ctime की जांच की जा सके. ऐसा हो सकता है कि कुछ मामलों में Linux कर्नल, फ़ाइलों को लिखने में देरी करे. इससे फ़ॉल्स पॉज़िटिव मिल सकते हैं. डिफ़ॉल्ट रूप से, यह 'lite' पर सेट होता है. यह सिर्फ़ मुख्य रिपॉज़िटरी में मौजूद सोर्स फ़ाइलों की जांच करता है. इसे 'बंद है' पर सेट करने से, सभी जांच बंद हो जाती हैं. हमारा सुझाव है कि ऐसा न करें. ऐसा इसलिए, क्योंकि जब किसी सोर्स फ़ाइल में बदलाव किया जाता है, तब उसे इनपुट के तौर पर इस्तेमाल करने वाली कार्रवाई चल रही होती है. इससे कैश मेमोरी में मौजूद डेटा खराब हो सकता है.
टैग: execution
--[no]incompatible_remote_use_new_exit_code_for_lost_inputs default: "true": अगर इसे सही पर सेट किया जाता है, तो रिमोट कैश मेमोरी से जुड़ी गड़बड़ियों की वजह से बिल्ड फ़ेल होने पर, Bazel नए एक्ज़िट कोड 39 का इस्तेमाल करेगा. इनमें कैश मेमोरी से डेटा हटाना भी शामिल है.
टैग: incompatible_change
--[no]remote_accept_cached default: "true": रिमोटली कैश मेमोरी में सेव किए गए ऐक्शन के नतीजों को स्वीकार करना है या नहीं.
--remote_build_event_upload=<all or minimal> default: "minimal": अगर इसे 'all' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश में अपलोड किए जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो बीईपी से रेफ़र की गई लोकल आउटपुट फ़ाइलों को रिमोट कैश में अपलोड नहीं किया जाता. हालांकि, बीईपी के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों को अपलोड किया जाता है. जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का इस्तेमाल हमेशा किया जाता है. भले ही, वे रिमोट कैश में मौजूद न हों. डिफ़ॉल्ट रूप से 'minimal' पर सेट होता है.
--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: होस्टनेम और इंस्टेंस का नाम, जिसका इस्तेमाल build event streams में लिखे गए bytestream:// यूआरआई में किया जाना है. इस विकल्प को तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इससे --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इसे सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.
--remote_cache=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कैशिंग एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://bazel.build/remote/caching देखें
--[no]remote_cache_async default: "true": अगर यह वैल्यू सही है, तो कार्रवाई के नतीजों को डिस्क या रिमोट कैश में अपलोड करने की प्रोसेस बैकग्राउंड में होगी. इससे कार्रवाई पूरी होने में कोई रुकावट नहीं आएगी. कुछ कार्रवाइयां, बैकग्राउंड में अपलोड करने की सुविधा के साथ काम नहीं करती हैं. इसलिए, इस फ़्लैग के सेट होने पर भी ये कार्रवाइयां ब्लॉक हो सकती हैं.
--[no]remote_cache_compression default: "false": अगर यह विकल्प चालू है, तो कैश मेमोरी में सेव किए गए बड़े डेटा ऑब्जेक्ट को zstd की मदद से कंप्रेस/डिकंप्रेस करें. ऐसा तब करें, जब उनका साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.
--remote_cache_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: कैश मेमोरी के अनुरोधों में शामिल किए जाने वाले हेडर के बारे में बताएं: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_default_exec_properties=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: डिफ़ॉल्ट exec प्रॉपर्टी सेट करें, ताकि उन्हें रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल किया जा सके. ऐसा तब किया जाता है, जब एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट न करता हो.
टैग: affects_outputs
--remote_default_platform_properties=<a string> default: "": अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म ने पहले से ही remote_execution_properties सेट नहीं की हैं, तो रिमोट एक्ज़ीक्यूशन एपीआई के लिए सेट की जाने वाली डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. अगर रिमोट एक्ज़ीक्यूशन के लिए होस्ट प्लैटफ़ॉर्म को एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल किया जाएगा.
--remote_download_regex=<a valid Java regular expression> कई बार इस्तेमाल किया गया हो: इस पैटर्न से मेल खाने वाले पाथ के रिमोट बिल्ड के आउटपुट को डाउनलोड करने के लिए मजबूर करें. भले ही, --remote_download_outputs का इस्तेमाल किया गया हो या नहीं. इस फ़्लैग को दोहराकर, कई पैटर्न तय किए जा सकते हैं.
टैग: affects_outputs
--remote_downloader_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: ऐसा हेडर तय करें जिसे रिमोट डाउनलोडर के अनुरोधों में शामिल किया जाएगा: --remote_downloader_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_exec_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: ऐसा हेडर तय करें जिसे एक्ज़ीक्यूशन के अनुरोधों में शामिल किया जाएगा: --remote_exec_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_execution_priority=<an integer> default: "0": रिमोट तरीके से की जाने वाली कार्रवाइयों की प्राथमिकता. किसी प्राथमिकता की वैल्यू का मतलब, सर्वर पर निर्भर करता है.
--remote_executor=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट एक्ज़ीक्यूशन एंडपॉइंट का HOST या HOST:PORT. grpc, grpcs (TLS की सुविधा के साथ grpc), और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS बंद करने के लिए, grpc:// या unix: स्कीमा तय करें.
--remote_grpc_log=<a path> डिफ़ॉल्ट: ब्यौरा देखें: अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में, क्रम से लगाए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry प्रोटोबफ़ होते हैं. हर मैसेज के पहले एक वैरिएंट होता है, जो क्रम से लगाए गए अगले प्रोटोबफ़ मैसेज के साइज़ को दिखाता है. ऐसा LogEntry.writeDelimitedTo(OutputStream) तरीके से किया जाता है.
--remote_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: अनुरोधों में शामिल किए जाने वाले हेडर के बारे में बताएं: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_instance_name=<a string> default: "": रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.
--[no]remote_local_fallback default: "false": अगर रिमोट एक्ज़ीक्यूशन काम नहीं करता है, तो क्या स्टैंडअलोन लोकल एक्ज़ीक्यूशन की रणनीति पर वापस जाना है.
--remote_local_fallback_strategy=<a string> default: "local": अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.
--remote_max_connections=<an integer> डिफ़ॉल्ट: "100": रिमोट कैश/एक्ज़ीक्यूटर से एक साथ कनेक्ट किए जा सकने वाले कनेक्शन की ज़्यादा से ज़्यादा संख्या को सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एक्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर 100 से ज़्यादा एक साथ किए गए अनुरोधों को हैंडल कर सकता है. इसलिए, Bazel एक साथ किए गए करीब `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations
--remote_proxy=<a string> डिफ़ॉल्ट: ब्यौरा देखें: प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer> default: "0": रिमोट ऐक्शन की प्राथमिकता, जिसे रिमोट कैश मेमोरी में सेव किया जाना है. किसी प्राथमिकता की वैल्यू का मतलब, सर्वर पर निर्भर करता है.
--remote_retries=<an integer> डिफ़ॉल्ट: "5": यह विकल्प, कुछ समय के लिए होने वाली गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कोशिश करने की सुविधा देता है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
--remote_retry_max_delay=<An immutable length of time.> default: "5s": रीमोट तरीके से फिर से कोशिश करने के लिए, बैकऑफ़ में लगने वाला ज़्यादा से ज़्यादा समय. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
--remote_timeout=<An immutable length of time.> default: "60s": रिमोट एक्ज़ीक्यूशन और कैश मेमोरी के कॉल के लिए, इंतज़ार करने की ज़्यादा से ज़्यादा समयावधि. REST कैश के लिए, यह कनेक्ट और रीड, दोनों के लिए टाइमआउट होता है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
--[no]remote_upload_local_results default: "true": अगर रिमोट कैश मेमोरी इस सुविधा के साथ काम करती है और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या स्थानीय तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.
--[no]remote_verify_downloads default: "true": इस विकल्प को सही पर सेट करने पर, Bazel सभी रिमोट डाउनलोड के हैश का योग कैलकुलेट करेगा. साथ ही, अगर रिमोट तौर पर कैश की गई वैल्यू, अनुमानित वैल्यू से मैच नहीं करती हैं, तो उन्हें खारिज कर देगा.

--[no]allow_analysis_cache_discard default: "true": अगर बिल्ड सिस्टम में बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज किया जा रहा है, तो इस विकल्प को 'गलत है' पर सेट करने से, Bazel बिल्ड जारी रखने के बजाय बंद हो जाएगा. अगर 'discard_analysis_cache' विकल्प भी सेट है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit
--auto_output_filter=<none, all, packages or subpackages> default: "none": अगर --output_filter के बारे में नहीं बताया गया है, तो इस विकल्प की वैल्यू का इस्तेमाल करके फ़िल्टर अपने-आप बन जाता है. अनुमति वाली वैल्यू ये हैं: 'none' (किसी भी चीज़ को फ़िल्टर न करें / सब कुछ दिखाएं), 'all' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'packages' (Blaze कमांड लाइन पर बताए गए पैकेज में मौजूद नियमों से मिले आउटपुट को शामिल करें), और 'subpackages' ('packages' की तरह, लेकिन इसमें सब-पैकेज भी शामिल हैं). 'packages' और 'subpackages' वैल्यू के लिए, //java/foo और //javatests/foo को एक पैकेज माना जाता है)'.
--[no]build_manual_tests default: "false": 'मैन्युअल' के तौर पर टैग किए गए टेस्ट टारगेट को बनाने के लिए मजबूर करता है. 'मैन्युअल' टेस्ट को प्रोसेस से बाहर रखा जाता है. इस विकल्प से, उन्हें बनाया जा सकता है, लेकिन लागू नहीं किया जा सकता.
--build_tag_filters=<comma-separated list of options> default: "": कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. जिन टैग को शामिल नहीं करना है उन्हें तय करने के लिए, हर टैग से पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें कम से कम एक शामिल किया गया टैग हो और कोई भी बाहर रखा गया टैग न हो. इस विकल्प से, 'test' कमांड के साथ लागू किए गए टेस्ट के सेट पर कोई असर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों के हिसाब से तय किए जाते हैं. उदाहरण के लिए, '--test_tag_filters'
--[no]build_tests_only default: "false": अगर यह विकल्प दिया गया है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.
--combined_report=<none or lcov> default: "none": इससे, कवरेज की कुल रिपोर्ट का टाइप तय किया जाता है. फ़िलहाल, सिर्फ़ LCOV फ़ॉर्मैट इस्तेमाल किया जा सकता है.
--[no]compile_one_dependency default: "false": तर्क फ़ाइलों की एक ही डिपेंडेंसी कंपाइल करें. यह आईडीई में सोर्स फ़ाइलों के सिंटैक्स की जांच करने के लिए उपयोगी है. उदाहरण के लिए, सोर्स फ़ाइल पर निर्भर किसी एक टारगेट को फिर से बनाकर, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का पता लगाया जा सकता है. इस तर्क से, फ़्लैग नहीं किए गए सभी तर्कों को समझने के तरीके पर असर पड़ता है. ये तर्क, बनाने के लिए टारगेट होने के बजाय सोर्स फ़ाइल के नाम होते हैं. हर सोर्स फ़ाइल के नाम के लिए, एक मनमाना टारगेट बनाया जाएगा. यह टारगेट, सोर्स फ़ाइल के नाम पर निर्भर करेगा.
--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD मिटा दिया है, तो बिल्ड सिस्टम को शिकायत मिल सकती है. ऐसा तब होगा, जब उसे '//x:y/z' लेबल मिलेगा. हालांकि, यह लेबल अब भी package_path की किसी दूसरी एंट्री से मिल रहा होगा. --deleted_packages x/y विकल्प का इस्तेमाल करके, इस समस्या से बचा जा सकता है.
--[no]discard_analysis_cache default: "false": विश्लेषण पूरा होने के तुरंत बाद, विश्लेषण की कैश मेमोरी को खारिज कर दें. इससे मेमोरी का इस्तेमाल ~10% तक कम हो जाता है. हालांकि, इसके बाद इंक्रीमेंटल बिल्ड की प्रोसेस धीमी हो जाती है.
--disk_cache=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह उस डायरेक्ट्री का पाथ होता है जहां Bazel, कार्रवाइयां और कार्रवाई के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.
--embed_label=<a one-line string> default: "": सोर्स कंट्रोल के वर्शन या रिलीज़ लेबल को बाइनरी में एम्बेड करें
--execution_log_binary_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें: src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में एक्ज़ीक्यूट किए गए स्पॉन को, लंबाई के हिसाब से तय किए गए SpawnExec protos के तौर पर लॉग करें. --execution_log_compact_file को प्राथमिकता दें. यह काफ़ी छोटा होता है और इसे जनरेट करने में कम खर्च आता है. इससे जुड़े फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).
--execution_log_compact_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें: इस फ़ाइल में, एक्ज़ीक्यूट किए गए स्पॉन को लंबाई के हिसाब से सीमा तय किए गए ExecLogEntry प्रोटो के तौर पर लॉग करें. इसके लिए, src/main/protobuf/spawn.proto के निर्देशों का पालन करें. पूरी फ़ाइल को zstd फ़ॉर्मैट में कंप्रेस किया गया है. इससे जुड़े फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; एक-दूसरे से अलग), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).
--execution_log_json_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें: src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में एक्ज़ीक्यूट किए गए स्पॉन को SpawnExec protos के न्यूलाइन-डीलिमिटेड JSON फ़ॉर्मैट में लॉग करें. --execution_log_compact_file को प्राथमिकता दें. यह काफ़ी छोटा होता है और इसे जनरेट करने में कम खर्च आता है. इससे जुड़े फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_binary_file (बाइनरी protobuf फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).
--[no]execution_log_sort default: "true": क्या एक्ज़ीक्यूशन लॉग को क्रम से लगाना है, ताकि अलग-अलग इनवोकेशन के लॉग की तुलना करना आसान हो. इस विकल्प को false पर सेट करने से, इनवोकेशन के आखिर में सीपीयू और मेमोरी का इस्तेमाल काफ़ी हद तक कम हो जाता है. हालांकि, इससे लॉग को नॉनडिटरमिनिस्टिक एक्ज़ीक्यूशन ऑर्डर में जनरेट किया जाता है. यह सिर्फ़ बाइनरी और JSON फ़ॉर्मैट पर लागू होता है. कॉम्पैक्ट फ़ॉर्मैट को कभी भी क्रम से नहीं लगाया जाता.
--[no]expand_test_suites default: "true": विश्लेषण करने से पहले, test_suite के टारगेट को उनके कॉम्पोनेंट टेस्ट में बदलें. इस फ़्लैग को चालू करने पर (डिफ़ॉल्ट रूप से), नेगेटिव टारगेट पैटर्न, टेस्ट सुइट से जुड़े टेस्ट पर लागू होंगे. ऐसा न करने पर, वे लागू नहीं होंगे. इस फ़्लैग को बंद करने से तब फ़ायदा होता है, जब कमांड लाइन पर टॉप-लेवल के पहलुओं को लागू किया जाता है. इससे वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis
--experimental_disk_cache_gc_idle_delay=<An immutable length of time.> default: "5m": डिस्क कैश मेमोरी की गार्बेज कलेक्शन की प्रोसेस शुरू होने से पहले, सर्वर को कितने समय तक बंद रहना चाहिए. कचरा इकट्ठा करने की नीति तय करने के लिए, --experimental_disk_cache_gc_max_size और/या --experimental_disk_cache_gc_max_age सेट करें.
--experimental_disk_cache_gc_max_age=<An immutable length of time.> default: "0": अगर इसे पॉज़िटिव वैल्यू पर सेट किया जाता है, तो डिस्क कैश मेमोरी से समय-समय पर ऐसी एंट्री हटा दी जाएंगी जो इस वैल्यू से ज़्यादा पुरानी हैं. अगर इसे --experimental_disk_cache_gc_max_size के साथ सेट किया जाता है, तो दोनों शर्तें लागू होती हैं. सर्वर के निष्क्रिय होने के बाद, बैकग्राउंड में गार्बेज कलेक्शन होता है. सर्वर के निष्क्रिय होने का समय, --experimental_disk_cache_gc_idle_delay फ़्लैग से तय होता है.
--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier> default: "0": अगर इसे पॉज़िटिव वैल्यू पर सेट किया जाता है, तो डिस्क कैश को समय-समय पर रीसाइकल किया जाएगा, ताकि यह इस साइज़ से ज़्यादा न हो. अगर इसे --experimental_disk_cache_gc_max_age के साथ सेट किया जाता है, तो दोनों शर्तें लागू होती हैं. सर्वर के निष्क्रिय होने के बाद, बैकग्राउंड में गार्बेज कलेक्शन होता है. सर्वर के निष्क्रिय होने का समय, --experimental_disk_cache_gc_idle_delay फ़्लैग से तय होता है.
--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "": अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. यह फ़िल्टर, टारगेट का ऐसा सेट बनाता है जिसके लिए extra_actions को शेड्यूल किया जा सकता है.
--[no]experimental_extra_action_top_level_only default: "false": अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. यह सिर्फ़ टॉप लेवल के टारगेट के लिए extra_actions शेड्यूल करता है.
--experimental_spawn_scheduler: कार्रवाइयों को स्थानीय और रिमोट तौर पर एक साथ चलाकर, डाइनैमिक तरीके से लागू करने की सुविधा चालू करें. Bazel, हर कार्रवाई को स्थानीय और रिमोट, दोनों जगहों पर शुरू करता है. इसके बाद, वह उस कार्रवाई को चुनता है जो सबसे पहले पूरी होती है. अगर किसी कार्रवाई के लिए वर्कर की ज़रूरत होती है, तो स्थानीय कार्रवाई को पर्सिस्टेंट वर्कर मोड में चलाया जाएगा. किसी कार्रवाई के लिए डाइनैमिक तरीके से एक्ज़ीक्यूशन की सुविधा चालू करने के लिए, `--internal_spawn_scheduler` और `--strategy=<mnemonic>=dynamic` फ़्लैग का इस्तेमाल करें.
बढ़कर यह हो जाता है:
--internal_spawn_scheduler
--spawn_strategy=dynamic
--[no]fetch default: "true": इस कमांड की मदद से, बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर कोई भी वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.
--local_termination_grace_seconds=<an integer> default: "15": टाइम आउट की वजह से किसी लोकल प्रोसेस को बंद करने और उसे तुरंत बंद करने के बीच इंतज़ार करने का समय.
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस से जुड़े होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट वैल्यू 'bazel info default-package-path' का आउटपुट होती है.
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.
--test_lang_filters=<comma-separated list of options> default: "": इसमें, टेस्ट की जाने वाली भाषाओं की कॉमा लगाकर अलग की गई सूची दी जाती है. हर भाषा से पहले '-' का इस्तेमाल करके, उन भाषाओं को तय किया जा सकता है जिन्हें शामिल नहीं करना है. हालांकि, ऐसा करना ज़रूरी नहीं है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जो बताई गई भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test नियम में भाषा के प्रीफ़िक्स के जैसा होना चाहिए. उदाहरण के लिए, 'cc', 'java', 'py' वगैरह. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.
--test_size_filters=<comma-separated list of values: small, medium, large, or enormous> default: "": इस एट्रिब्यूट की वैल्यू के तौर पर, कॉमा लगाकर अलग किए गए टेस्ट के साइज़ की सूची दी जाती है. हर साइज़ से पहले '-' का इस्तेमाल करके, उन साइज़ के बारे में बताया जा सकता है जिन्हें शामिल नहीं करना है. हालांकि, ऐसा करना ज़रूरी नहीं है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक शामिल किया गया साइज़ हो और कोई भी साइज़ शामिल न किया गया हो. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.
--test_tag_filters=<comma-separated list of options> default: "": यह कॉमा लगाकर अलग किए गए टेस्ट टैग की सूची तय करता है. जिन टैग को शामिल नहीं करना है उन्हें तय करने के लिए, हर टैग से पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक शामिल किया गया टैग हो और कोई भी बाहर रखा गया टैग न हो. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.
--test_timeout_filters=<comma-separated list of values: short, moderate, long, or eternal> default: "": यह कॉमा लगाकर अलग किए गए टेस्ट टाइमआउट की सूची तय करता है. हर टाइमआउट से पहले '-' का इस्तेमाल करके, उन टाइमआउट के बारे में बताया जा सकता है जिन्हें शामिल नहीं किया गया है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक टाइमआउट शामिल हो और कोई भी टाइमआउट शामिल न हो. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.
--workspace_status_command=<path> default: "": यह कमांड, बिल्ड की शुरुआत में लागू की जाती है. इससे की/वैल्यू पेयर के तौर पर, वर्कस्पेस की स्थिति के बारे में जानकारी मिलती है. पूरी जानकारी के लिए, उपयोगकर्ता का मैन्युअल देखें. उदाहरण के लिए, tools/buildstamp/get_workspace_status भी देखें.

--[no]experimental_inprocess_symlink_creation default: "true": सिंबल लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या हेल्पर प्रोसेस को डेलिगेट करना है.
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor default: "false": वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution, experimental
--[no]experimental_remotable_source_manifests default: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing default: "false": अगर यह विकल्प सही है, तो Bazel, टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.
टैग: execution, experimental
--[no]experimental_strict_fileset_output default: "false": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental
--[no]incompatible_modify_execution_info_additive default: "false": इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो: कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि कई रेगुलर एक्सप्रेशन एक ही नेमोनिक पर लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z' से, सभी कार्रवाइयों के लिए एक्ज़ीक्यूशन की जानकारी में 'x' और 'z' जुड़ जाते हैं और 'y' हट जाता है. 'Genrule=+requires-x' से, Genrule की सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी में जोड़ा जाता है. '(?!Genrule).*=-requires-x' से, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी से हटा दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis
--persistent_android_dex_desugar: वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू रखें.
इनके तौर पर दिखता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution
--persistent_android_resource_processor: वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को हमेशा चालू रखें.
बढ़कर यह हो जाता है:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_dex_desugar: वर्कर्स का इस्तेमाल करके, लगातार मल्टीप्लेक्स किए गए Android dex और desugar कार्रवाइयों को चालू करें.
इनके तौर पर दिखता है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_resource_processor: वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.
इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_tools: Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (dexing, desugaring, resource processing) चालू करें.
इनके तौर पर दिखता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--[no]use_target_platform_for_tests default: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. इसके बजाय, टेस्ट एक्ज़ेक ग्रुप का इस्तेमाल नहीं करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android": android_binary नियमों के लिए, मेनिफ़ेस्ट मर्जर को चुनता है. यह फ़्लैग, लेगसी मर्जर से Android मेनिफ़ेस्ट मर्जर पर स्विच करने में मदद करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_platforms=<a build target label> default: "": यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain": Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> default: "": यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger": यह उस बाइनरी का पाथ है जिसका इस्तेमाल रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:lcov_merger' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator": कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी का पाथ. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट वैल्यू '//tools/test:coverage_report_generator' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support": सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:coverage_support' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह कस्टम malloc को लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के पहले, - (नेगेटिव एक्सप्रेशन) का इस्तेमाल किया जा सकता है. इसे कॉमा लगाकर अलग किए गए, कंस्ट्रेंट वैल्यू टारगेट की सूची को असाइन (=) किया जाता है. अगर कोई टारगेट, किसी भी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसके टूलचेन रिज़ॉल्यूशन को इस तरह से पूरा किया जाएगा जैसे कि उसने कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर एलान किया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64 'test' नाम वाले लक्ष्यों को छोड़कर, //demo के अंतर्गत किसी भी लक्ष्य में 'x86_64' जोड़ देगा.
टैग: loading_and_analysis
--[no]experimental_include_xcode_execution_requirements default: "false": अगर सेट है, तो हर Xcode कार्रवाई में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution, experimental
--[no]experimental_prefer_mutual_xcode default: "true": अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state, experimental
--extra_execution_platforms=<comma-separated list of options> default: "": कार्रवाइयां करने के लिए उपलब्ध प्लैटफ़ॉर्म. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले माना जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, पहले की फ़्लैग सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में एलान किए गए टूलचेन से पहले माना जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह फ़्लैग कोई कार्रवाई नहीं करता. इसे आने वाले समय में हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform": यह प्लैटफ़ॉर्म के नियम का लेबल है. इससे होस्ट सिस्टम के बारे में पता चलता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_bazel_test_exec_run_under default: "false": अगर यह विकल्प चालू है, तो "bazel test --run_under=//:runner" कमांड, एक्ज़ेक कॉन्फ़िगरेशन में "//:runner" बनाता है. यह सुविधा बंद होने पर, टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true": अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution default: "false": ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_remove_legacy_whole_archive default: "true": अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_strip_executable_safely default: "false": अगर यह सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects default: "true": अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी ईएलएफ़ टूलचेन इस सेटिंग के साथ काम करते हैं.
टैग: loading_and_analysis, affects_outputs, affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे macOS ऐप्लिकेशन बनाने के लिए, macOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से macOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--minimum_os_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह ओएस का वह कम से कम वर्शन है जिसे कंपाइल करने के लिए टारगेट किया जाता है.
टैग: loading_and_analysis, affects_outputs
--platform_mappings=<a main workspace-relative path> default: "": यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य वर्कस्पेस रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, वर्कस्पेस के रूट फ़ोल्डर में मौजूद होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> default: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह py_runtime का लेबल है. यह टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर को दिखाता है. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से tvOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह विकल्प चुना जाता है, तो यह बिल्ड से जुड़ी कार्रवाइयों के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी जाती है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes": यह xcode_config नियम का लेबल है. इसका इस्तेमाल, बिल्ड कॉन्फ़िगरेशन में Xcode का वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym default: "false": डीबग सिंबल (.dSYM) वाली फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह जानकारी गलत है, तो इसे शामिल न करें. इसकी वैल्यू फ़ॉल्स होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs
--[no]build_test_dwp default: "false": अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h": cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc": cc_proto_library, सोर्स फ़ाइलों के ऐसे सफ़िक्स सेट करता है जिन्हें वह बनाता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info default: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state default: "false": कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> default: "no": इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल कौनसे कंपाइलेशन मोड करते हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data default: "true": अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]incompatible_compact_repo_mapping_manifest default: "false": अगर यह सुविधा चालू है, तो <binary>.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन की रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन, रनफ़ाइल जनरेट करने वाले हर रेपो के लिए एक बार रेपो मैपिंग दिखाने के बजाय, सिर्फ़ एक बार दिखाती है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_filegroup_runfiles_for_data default: "false": अगर सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.
टैग: incompatible_change
--[no]legacy_external_runfiles default: "false": अगर यह सही है, तो .runfiles/repo के साथ-साथ .runfiles/wsname/external/repo में मौजूद बाहरी रिपॉज़िटरी के लिए, बिल्ड रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap default: "false": इससे यह तय किया जाता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps default: "false": अगर यह सेट है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को <code>name</code> के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर के हिसाब से भी वैरिएबल को तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है. <br> ध्यान दें कि जब तक <code>--incompatible_repo_env_ignores_action_env</code> की वैल्यू सही नहीं होती, तब तक सभी <code>name=value</code> पेयर, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.
टैग: action_command_lines
--allowed_cpu_values=<comma-separated set of options> default: "": --cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs
--[no]android_databinding_use_androidx default: "true": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args default: "true": 3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> default: "off": इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तब Android के नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. ALPHABETICAL का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से पाथ के हिसाब से क्रम से लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस तरह से क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip default: "auto": Build python executable zip; on on Windows, off on other platforms
Tags: affects_outputs
--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ऐसी सूची जिसमें Apple Catalyst बाइनरी बनाने के लिए, आर्किटेक्चर को कॉमा लगाकर अलग किया गया हो.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage default: "false": अगर बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild": इससे यह तय किया जाता है कि बाइनरी किस मोड में बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> कई बार इस्तेमाल किया गया हो: gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> default: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs
--cxxopt=<a string> कई बार इस्तेमाल किया गया हो: C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, सबसे बाद वाली वैल्यू का इस्तेमाल किया जाता है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> default: "default": इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_propeller_optimize_absolute_paths default: "true": अगर यह सेट है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_remaining_fdo_absolute_paths default: "true": अगर यह नीति सेट की जाती है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs
--[no]enable_runfiles default: "auto": runfiles symlink ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows पर बंद होता है और अन्य प्लैटफ़ॉर्म पर चालू होता है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो: अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. action_listener का इस्तेमाल करके, मौजूदा बिल्ड ऐक्शन में extra_action अटैच करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources default: "false": एपीके में Java संसाधनों को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 default: "true": android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_rewrite_dexes_with_rex default: "false": use rex tool to rewrite dex files
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files default: "false": अगर बताया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental
--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1": इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines
--[no]experimental_omitfp default: "false": अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> default: "off": आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution
--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो: हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir default: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_py_binaries_include_label default: "false": py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap default: "false": अगर collect_code_coverage चालू है, तो Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true": कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental
--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है. जैसे, `//foo/bar:file.afdo`. इसके लिए, आपको संबंधित पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है. साथ ही, यह `fdo_profile` टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, `fdo_profile` नियम की जगह लागू होगा.
टैग: affects_outputs
--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कैश मेमोरी प्रीफ़ेच करने के लिए, हिंट का इस्तेमाल करें.
टैग: affects_outputs
--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.
टैग: affects_outputs
--features=<a string> कई बार इस्तेमाल किया गया हो: टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं. --host_features भी देखें
टैग: changes_inputs, affects_outputs
--[no]force_pic default: "false": अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय पीआईसी प्री-बिल्ट लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.
टैग: loading_and_analysis, affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह उन एनवायरमेंट वैरिएबल का सेट तय करता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt> default: "opt": बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल के मोड के बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C कंपाइलर को पास करने का अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है. हालांकि, C++ सोर्स फ़ाइलों को कंपाइल करते समय इसका इस्तेमाल नहीं किया जाता.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> default: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास किए जाने वाले अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_features=<a string> कई बार इस्तेमाल किया गया हो: दी गई सुविधाएं, exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs
--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: यह exec कॉन्फ़िगरेशन के लिए Python के वर्शन को बदलता है. इसे "PY2" या "PY3" पर सेट किया जा सकता है.
टैग: loading_and_analysis, affects_outputs
--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: होस्ट टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है. हालांकि, bar.cc में यह विकल्प नहीं जोड़ा जाता.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups default: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory default: "true": अगर सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में शामिल किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets default: "false": कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]": कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ ऐसे नियमों को लागू किया जाता है जो टेस्ट नहीं किए गए हैं. हालांकि, अगर --instrument_test_targets विकल्प चालू है, तो टेस्ट किए गए नियमों को भी लागू किया जा सकता है.
टैग: affects_outputs
--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'ios_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें बताए गए सभी आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive default: "true": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated
--linkopt=<a string> कई बार इस्तेमाल किया गया हो: लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो: LTO के बैकएंड चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो: एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple macOS के बाइनरी फ़ाइलें बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.
टैग: loses_incremental_state, loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs
--[no]objc_debug_with_GLIBCXX default: "false": अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping default: "false": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines
--objccopt=<a string> कई बार इस्तेमाल किया गया हो: Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ बैकएंड ऑब्जेक्ट कंपाइल करते समय, LTO बैकएंड (under --features=thin_lto) को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों की एलटीओ बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis
--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें. Propeller प्रोफ़ाइल में कम से कम दो फ़ाइलों में से एक फ़ाइल होनी चाहिए. ये फ़ाइलें cc प्रोफ़ाइल और ld प्रोफ़ाइल हैं. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस देता है. उदाहरण के लिए, a/b/BUILD में मौजूद BUILD फ़ाइल, लेबल को इस तरह से तय करती है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नेम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]share_native_deps default: "true": अगर यह वैल्यू सही है, तो एक जैसी फ़ंक्शनैलिटी वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs
--[no]stamp default: "false": तारीख, उपयोगकर्ता नाम, होस्टनेम, वर्कस्पेस की जानकारी वगैरह के साथ बाइनरी पर स्टैंप लगाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.
टैग: affects_outputs
--stripopt=<a string> कई बार इस्तेमाल किया गया हो: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple tvOS के बाइनरी फ़ाइलें बनाने के लिए, आर्किटेक्चर की कॉमा लगाकर अलग की गई सूची.
टैग: loses_incremental_state, loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple visionOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.
टैग: affects_outputs

--[no]check_licenses default: "false": देखें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]desugar_for_android default: "true": Java 8 के बाइटकोड को डेक्सिंग से पहले डीशुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs default: "false": लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की सुविधा वाली लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints default: "true": यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps default: "true": Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental
--experimental_import_deps_checking=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कोई कार्रवाई नहीं की गई, इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है
टैग: loading_and_analysis
--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है": इस विकल्प को चालू करने पर, यह पक्का किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल न हों. नीति उल्लंघन ठीक करने के लिए की गई कार्रवाई से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.
टैग: loading_and_analysis
--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default": अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files default: "false": अगर यह चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मिलती-जुलती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains default: "false": इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules default: "false": यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule default: "false": कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]one_version_enforcement_on_java_tests default: "true": इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.
टैग: loading_and_analysis
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: --incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल करने के लिए, अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis
--[no]strict_filesets default: "false": अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> default: "off": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes default: "false": अगर यह वैल्यू सही है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित किए जाने चाहिए.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2": APK पर साइन करने के लिए इस्तेमाल किया जाने वाला तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis
--[no]device_debug_entitlements default: "true": अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो हस्ताक्षर करते समय, objc ऐप्लिकेशन में डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs
--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें: iOS पर साइन करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.
टैग: action_command_lines

--[no]incompatible_disallow_legacy_py_provider default: "true": यह कोई कार्रवाई नहीं करता है. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes default: "false": अगर यह सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_alwayslink_by_default default: "false": अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules default: "false": जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures default: "false": अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के इंस्टेंस को AnalysisFailureInfo का इंस्टेंस मिलेगा. इसमें गड़बड़ी की जानकारी होगी. इससे बिल्ड पूरा नहीं होगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन वाले नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure default: "false": अगर dex2oat की कार्रवाई पूरी नहीं होती है, तो टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय, बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो: टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की रकम को बदल देंगे. वैल्यू, HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]<float> (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4) भी हो सकता है. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में तय किए गए संसाधनों से बदल दिया जाता है.
--[no]experimental_android_use_parallel_dex2oat default: "false": android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks default: "false": ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines
--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. उदाहरण के लिए, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची देखी जा सकती है.
टैग: test_runner
--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर पर चलाने या जांच करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner
--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो: इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी वजह से इनमें से कोई भी कोशिश पूरी नहीं होती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू से है. वहीं, regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को तीन बार नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. मिलते-जुलते सबसे हाल के तर्क को प्राथमिकता दी जाती है. अगर कोई भी शर्त पूरी नहीं होती है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.
--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
टैग: test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट के टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करने के लिए कहा जाता है.
--[no]zip_undeclared_test_outputs default: "false": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो बिना बताए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

--[no]experimental_filter_library_jar_with_program_jar default: "false": ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास हटाई जा सकें.
टैग: action_command_lines, experimental
--[no]experimental_inmemory_dotd_files default: "true": अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly default: "false": इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट से जुड़े नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_starlark_cc_import default: "false": यह विकल्प चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning default: "false": क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता है और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental
--[no]incremental_dexing default: "true": यह हर जार फ़ाइल के लिए, अलग से डेक्सिंग का ज़्यादातर काम करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning default: "true": अगर इस विकल्प को सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल किया जाएगा. इससे, objc कंपाइलर को पास किए गए इनपुट के सेट को कम किया जा सकेगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies default: "false": When building a target //a:a, process headers in all targets that //a:a depends on (if header processing is enabled for the toolchain).
टैग: execution
--[no]trim_test_configuration default: "true": यह सुविधा चालू होने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*": टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.
टैग: terminal_output

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py default: "false": इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन पाएं. खास तौर पर, जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इस फ़्लैग को सेट करने पर ही इसे गलत माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed default: "true": अगर यह 'सही है', तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, ऐसे आउटपुट रूट में दिखेंगे जिसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिमलिंक, Python 2 के बजाय Python 3 के टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default default: "true": अगर यह सही है, तो `py_binary` और `py_test` टारगेट, `python_version` या `default_python_version` एट्रिब्यूट सेट नहीं करते हैं. ऐसे में, ये टारगेट डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. इस फ़्लैग को सेट करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py2_outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains default: "true": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के एक्ज़ीक्यूटेबल नेटिव नियम, Python टूलचेन के ज़रिए तय किए गए Python रनटाइम का इस्तेमाल करेंगे. इसके बजाय, वे --python_top जैसे लेगसी फ़्लैग के ज़रिए दिए गए रनटाइम का इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change
--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: Python का मुख्य वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट से बदला जाता है. भले ही, वे साफ़ तौर पर किसी वर्शन के बारे में न बताते हों. इसलिए, आम तौर पर इस फ़्लैग को सप्लाई करने की कोई वजह नहीं होती.
टैग: loading_and_analysis, affects_outputs

--[no]cache_test_results [-t] default: "auto": अगर इसे 'auto' पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें बाहरी के तौर पर मार्क नहीं किया गया है. 'नहीं' पर सेट होने पर, Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.
--[no]experimental_cancel_concurrent_tests default: "never": अगर 'on_failed' या 'on_passed' है, तो Blaze उस नतीजे के साथ पहली बार चलने वाले टेस्ट को रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_fetch_all_coverage_outputs default: "false": अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_generate_llvm_lcov default: "false": अगर यह विकल्प सही पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_j2objc_header_map default: "true": J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental
--[no]experimental_j2objc_shorter_header_path default: "false": क्या हेडर पाथ को छोटा करके जनरेट करना है. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "javabuilder": इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.
--[no]experimental_limit_android_lint_to_android_constrained_java default: "false": No-op, kept only for backwards compatibility
Tags: affects_outputs, experimental
--[no]experimental_run_android_lint_on_java_rules default: "false": java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs, experimental
--[no]explicit_java_test_deps default: "false": java_test में, TestRunner की deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.
--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, javac को पास करने के लिए अतिरिक्त विकल्प.
--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्डिंग टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये टूल, बिल्ड के दौरान एक्ज़ीक्यूट किए जाते हैं. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support default: "true": अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को तब फ़ेल कर देगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में मौजूद पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, हर शार्ड में सभी टेस्ट चलाएगा.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed default: "true": अगर यह वैल्यू सही है, तो सैंडबॉक्स की गई रणनीति के साथ खास टेस्ट चलाए जाएंगे. 'local' टैग जोड़कर, स्थानीय तौर पर सिर्फ़ एक टेस्ट रन करें
टैग: incompatible_change
--[no]incompatible_strict_action_env default: "false": अगर यह विकल्प सही है, तो Bazel ऐसे एनवायरमेंट का इस्तेमाल करता है जिसमें PATH के लिए स्टैटिक वैल्यू होती है. साथ ही, यह LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने से, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा. ऐसा तब होगा, जब शेयर की गई कैश मेमोरी का इस्तेमाल किया जा रहा हो.
टैग: loading_and_analysis, incompatible_change
--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.
--java_debug: इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इनमें बदल जाता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps default: "true": हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करें. फ़िलहाल, यह जानकारी कंपाइल-टाइम क्लासपाथ के लिए जनरेट की जाती है.
--[no]java_header_compilation default: "true": सोर्स से सीधे तौर पर ijars कंपाइल करें.
--java_language_version=<a string> default: "": Java भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट, इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": Java रनटाइम का वर्शन
--javacopt=<a string> कई बार इस्तेमाल किया गया हो: javac को पास करने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> कई बार इस्तेमाल किया गया हो: Java VM को पास करने के लिए अतिरिक्त विकल्प. इन विकल्पों को हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिया जाएगा.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किए जाने वाले बाइनरी के बारे में बताता है.
--plugin=<a build target label> कई बार इस्तेमाल किया गया हो: बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.
--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प से यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.
--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--[no]proto_profile default: "true": प्रोफ़ाइल_पाथ को प्रोटो कंपाइलर को पास करना है या नहीं.
टैग: affects_outputs, loading_and_analysis
--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल, जो C++ प्रोटो को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि j2objc protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि Java protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि JavaLite protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--protocopt=<a string> कई बार इस्तेमाल किया गया हो: प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs
--[no]runs_per_test_detects_flakes default: "false": अगर यह वैल्यू सही है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.
--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का ऐब्सलूट पाथ. अगर इसे सेट नहीं किया जाता है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन (जो Bazel सर्वर शुरू करता है) पर सेट किया जाता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. जैसे, Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी फ़ाइलों को बनाने या उन्हें चलाने में समस्याएं आ सकती हैं.
टैग: loading_and_analysis
--test_arg=<a string> कई बार इस्तेमाल किया गया हो: यह अतिरिक्त विकल्प और आर्ग्युमेंट तय करता है. इन्हें टेस्ट एक्ज़ीक्यूटेबल को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast default: "false": यह विकल्प, टेस्ट रनर को फ़ेल फ़ास्ट की जानकारी देता है. पहली गड़बड़ी होने पर, टेस्ट रनर को टेस्ट बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'shard_count' BUILD एट्रिब्यूट मौजूद होने पर ही शार्डिंग का इस्तेमाल करने के लिए, 'explicit' का इस्तेमाल करें. 'disabled' को कभी भी टेस्ट शार्डिंग का इस्तेमाल न करने के लिए सेट करें. 'forced=k' का इस्तेमाल, 'shard_count' BUILD एट्रिब्यूट के बावजूद, टेस्टिंग के लिए 'k' शार्ड लागू करने के लिए किया जाता है.
--tool_java_language_version=<a string> default: "": The Java language version used to execute the tools that are needed during a build
--tool_java_runtime_version=<a string> default: "remotejdk_11": बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

Canonicalize-flags के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

--[no]canonicalize_policy default: "false": एक्सपैंड और फ़िल्टर करने के बाद, कैननिकल नीति को आउटपुट करें. आउटपुट को साफ़-सुथरा रखने के लिए, इस विकल्प को 'सही है' पर सेट करने पर, कैननिकल किए गए कमांड आर्ग्युमेंट नहीं दिखाए जाएंगे. ध्यान दें कि --for_command से तय की गई कमांड का असर फ़िल्टर की गई नीति पर पड़ता है. अगर कोई कमांड तय नहीं की जाती है, तो डिफ़ॉल्ट कमांड 'build' होती है.
टैग: affects_outputs, terminal_output
--[no]experimental_include_default_values default: "true": क्या Starlark के ऐसे विकल्प आउटपुट में शामिल किए गए हैं जिनकी वैल्यू डिफ़ॉल्ट पर सेट है.
टैग: affects_outputs, terminal_output

--[no]incompatible_config_setting_private_default_visibility default: "false": अगर incompatible_enforce_config_setting_visibility=false है, तो यह एक noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होगी. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enforce_config_setting_visibility default: "true": अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है', तो हर config_setting, हर टारगेट को दिखेगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

--for_command=<a string> default: "build": वह कमांड जिसके विकल्पों को कैननिकल किया जाना चाहिए.
टैग: affects_outputs, terminal_output
--invocation_policy=<a string> default: "": कैननिकल किए जाने वाले विकल्पों पर, इनवॉकेशन की नीति लागू करता है.
टैग: affects_outputs, terminal_output

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD मिटा दिया है, तो बिल्ड सिस्टम को शिकायत मिल सकती है. ऐसा तब होगा, जब उसे '//x:y/z' लेबल मिलेगा. हालांकि, यह लेबल अब भी package_path की किसी दूसरी एंट्री से मिल रहा होगा. --deleted_packages x/y विकल्प का इस्तेमाल करके, इस समस्या से बचा जा सकता है.
--[no]fetch default: "true": इस कमांड की मदद से, बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर कोई भी वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस से जुड़े होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट वैल्यू 'bazel info default-package-path' का आउटपुट होती है.
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

साफ़ करने के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

--[no]async default: "false": अगर सही है, तो आउटपुट को एसिंक्रोनस तरीके से साफ़ किया जाता है. इस कमांड के पूरा होने के बाद, उसी क्लाइंट में नई कमांड को सुरक्षित तरीके से लागू किया जा सकेगा. भले ही, बैकग्राउंड में डेटा मिटाने की प्रोसेस जारी रहे.
टैग: host_machine_resource_optimizations
--[no]expunge default: "false": अगर यह सही है, तो क्लीन कमांड इस Bazel इंस्टेंस के लिए पूरे वर्किंग ट्री को हटा देती है. इसमें Bazel की बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर Bazel सर्वर चल रहा है, तो उसे बंद कर देती है.
टैग: host_machine_resource_optimizations
--expunge_async: अगर साफ़ तौर पर बताया गया है, तो clean कमांड इस Bazel इंस्टेंस के लिए पूरे वर्किंग ट्री को एसिंक्रोनस तरीके से हटा देती है. इसमें Bazel की बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर Bazel सर्वर चल रहा है, तो उसे बंद कर देती है. इस कमांड के पूरा होने के बाद, उसी क्लाइंट में नई कमांड को सुरक्षित तरीके से लागू किया जा सकेगा. भले ही, बैकग्राउंड में डेटा मिटाने की प्रोसेस जारी रहे.
इसकी जगह यह दिखता है:
--expunge
--async

टैग: host_machine_resource_optimizations

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

कॉन्फ़िगरेशन के विकल्प

कवरेज के विकल्प

test से सभी विकल्प इनहेरिट करता है.

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

Cquery के विकल्प

test से सभी विकल्प इनहेरिट करता है.

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

--aspect_deps=<off, conservative or precise> default: "conservative": जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तब पहलू की डिपेंडेंसी को कैसे हल करें. 'off' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'conservative' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी का नियम क्लास दिया गया हो या नहीं. 'precise' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हों. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह फ़ैसला विश्लेषण के चरण में लिया जाता है. यह चरण 'bazel query' के दौरान नहीं चलता.
टैग: build_file_semantics
--[no]consistent_labels default: "false": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे कि Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के बजाय रिपॉज़िटरी के नाम (मुख्य रिपॉज़िटरी के हिसाब से) दिखा सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects default: "false": aquery, cquery: whether to include aspect-generated actions in the output. query: no-op (aspects are always followed).
टैग: terminal_output
--[no]graph:factored default: "true": अगर यह विकल्प चुना जाता है, तो ग्राफ़ को 'फ़ैक्टर्ड' किया जाएगा. इसका मतलब है कि टोपोलॉजिकल तौर पर एक जैसे नोड को एक साथ मर्ज कर दिया जाएगा और उनके लेबल को एक साथ जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> default: "512": आउटपुट में, ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. बड़े लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि लेबल को छोटा नहीं किया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps default: "true": अगर यह विकल्प चालू है, तो क्वेरी जिस डिपेंडेंसी ग्राफ़ पर काम करती है उसमें इंप्लिसिट डिपेंडेंसी शामिल की जाएंगी. इंप्लिसिट डिपेंडेंसी ऐसी डिपेंडेंसी होती है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया जाता, लेकिन Bazel इसे जोड़ देता है. cquery के लिए, यह विकल्प हल की गई टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_aspects default: "true": aquery, cquery: whether to include aspect-generated actions in the output. query: no-op (aspects are always followed).
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash default: "true": अगर यह विकल्प चालू है, तो package_group एट्रिब्यूट के `packages` एट्रिब्यूट की वैल्यू देते समय, शुरुआती `//` को शामिल किया जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope default: "false": अगर इसे सेट किया गया है और --universe_scope को सेट नहीं किया गया है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि क्वेरी एक्सप्रेशन के लिए अनुमानित --universe_scope वैल्यू, आपकी ज़रूरत के हिसाब से नहीं हो सकती.ऐसा तब होता है, जब क्वेरी एक्सप्रेशन में यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे, `allrdeps`) का इस्तेमाल किया जाता है.इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करें, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query पर जाएं. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है. इसका मतलब है कि यह `cquery` पर लागू नहीं होता.
टैग: loading_and_analysis
--[no]line_terminator_null default: "false": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया गया है.
टैग: terminal_output
--[no]nodep_deps default: "true": अगर यह विकल्प चालू है, तो "nodep" एट्रिब्यूट से मिले डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल किए जाएंगे. क्वेरी इसी ग्राफ़ पर काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` कमांड चलाएं और उसके आउटपुट को पार्स करें.
टैग: build_file_semantics
--output=<a string> default: "label": वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: label, label_kind, textproto, transitions, proto, streamed_proto, jsonproto. 'transitions' चुनने पर, आपको --transitions=(lite|full) विकल्प भी तय करना होगा.
टैग: terminal_output
--output_file=<a string> default: "": इस विकल्प को चुनने पर, क्वेरी के नतीजे सीधे इस फ़ाइल में लिखे जाएंगे. साथ ही, Bazel के स्टैंडर्ड आउटपुट स्ट्रीम (stdout) में कुछ भी प्रिंट नहीं किया जाएगा. आम तौर पर, बेंचमार्क में यह <code>bazel query > file</code> से ज़्यादा तेज़ होता है.
टैग: terminal_output
--[no]proto:default_values default: "true": अगर यह वैल्यू सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह वैल्यू गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack default: "false": definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, नियम के हर इंस्टेंस के लिए, Starlark कॉल स्टैक को रिकॉर्ड करता है. यह रिकॉर्डिंग, नियम की क्लास तय किए जाने के समय की जाती है.
टैग: terminal_output
--[no]proto:flatten_selects default: "true": अगर यह विकल्प चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किए गए डेटा का मतलब ऐसी सूची से है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects default: "false": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, उस सोर्स पहलू का नाम डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स पहलू से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output
--[no]proto:include_configurations default: "true": अगर यह चालू है, तो प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. इस सुविधा के बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs
--[no]proto:include_synthetic_attribute_hash default: "false": $internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack default: "false": हर नियम के इंस्टैंटिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए, स्टैक में
टैग मौजूद होने चाहिए: terminal_output
--[no]proto:locations default: "true": क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> default: "all": आउटपुट में शामिल करने के लिए, कॉमा लगाकर अलग किए गए एट्रिब्यूट की सूची. डिफ़ॉल्ट रूप से, सभी एट्रिब्यूट के लिए लागू होता है. किसी भी एट्रिब्यूट को आउटपुट न करने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प, --output=proto पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_classes default: "false": हर नियम के rule_class_key फ़ील्ड में वैल्यू डालें. साथ ही, किसी दिए गए rule_class_key वाले पहले नियम के लिए, उसके rule_class_info प्रोटो फ़ील्ड में भी वैल्यू डालें. rule_class_key फ़ील्ड, नियम क्लास की खास तौर पर पहचान करता है. साथ ही, rule_class_info फ़ील्ड, Stardoc फ़ॉर्मैट में नियम क्लास की एपीआई डेफ़िनिशन है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs default: "true": rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output
--query_file=<a string> default: "": अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.
टैग: changes_inputs
--[no]relative_locations default: "false": अगर यह विकल्प चुना जाता है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह की जानकारी रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह अलग-अलग मशीनों पर एक जैसा नहीं होता. इस विकल्प को true पर सेट करके, सभी मशीनों पर एक जैसा नतीजा पाया जा सकता है.
टैग: terminal_output
--show_config_fragments=<off, direct or transitive> default: "off": इससे किसी नियम और उसकी ट्रांज़िटिव डिपेंडेंसी के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट दिखते हैं. इससे यह पता लगाया जा सकता है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ को कितना कम किया जा सकता है.
टैग: affects_outputs
--starlark:expr=<a string> default: "": यह एक Starlark एक्सप्रेशन है. इसका इस्तेमाल cquery के --output=starlark मोड में, कॉन्फ़िगर किए गए हर टारगेट को फ़ॉर्मैट करने के लिए किया जाता है. कॉन्फ़िगर किया गया टारगेट, 'target' से जुड़ा होता है. अगर --starlark:expr या --starlark:file में से किसी को भी तय नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट होगा. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल नहीं किया जा सकता.
टैग: terminal_output
--starlark:file=<a string> default: "": यह उस फ़ाइल का नाम है जो 'format' नाम के Starlark फ़ंक्शन को तय करती है. इस फ़ंक्शन में एक आर्ग्युमेंट होता है. इसे हर कॉन्फ़िगर किए गए टारगेट पर लागू किया जाता है, ताकि उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जा सके. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, --output=starlark के लिए सहायता देखें.
टैग: terminal_output
--[no]tool_deps default: "true": क्वेरी: अगर यह सुविधा बंद है, तो 'एक्ज़ीक्यूशन कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'exec configuration' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से लेकर प्रोटोकॉल कंपाइलर तक, आम तौर पर उसी 'target' प्रोग्राम के किसी हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल की ओर इशारा करता है. Cquery: अगर यह सुविधा बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर दिया जाता है जो टॉप-लेवल के उस टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं जिसने इस कॉन्फ़िगर किए गए टारगेट का पता लगाया था. इसका मतलब है कि अगर टॉप-लेवल का टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो टारगेट कॉन्फ़िगरेशन में मौजूद सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प से, हल की गई टूलचेन को नहीं हटाया जाएगा.
टैग: build_file_semantics
--transitions=<full, lite or none> default: "none": यह वह फ़ॉर्मैट है जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगा.
टैग: affects_outputs
--universe_scope=<comma-separated list of options> default: "": कॉमा लगाकर अलग किए गए टारगेट पैटर्न का सेट (जोड़ने और घटाने वाले). क्वेरी को, ट्रांज़िटिव क्लोज़र के ज़रिए तय किए गए यूनिवर्स में किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट होते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर इस विकल्प के बारे में नहीं बताया जाता है, तो यह माना जाता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के टारगेट हैं. ध्यान दें: cquery के लिए, इस विकल्प को तय न करने पर, बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ नहीं बनाए जा सकते.
टैग: loading_and_analysis

--[no]experimental_inprocess_symlink_creation default: "true": सिंबल लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या हेल्पर प्रोसेस को डेलिगेट करना है.
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor default: "false": वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution, experimental
--[no]experimental_remotable_source_manifests default: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing default: "false": अगर यह विकल्प सही है, तो Bazel, टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.
टैग: execution, experimental
--[no]experimental_strict_fileset_output default: "false": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental
--[no]incompatible_modify_execution_info_additive default: "false": इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो: कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि कई रेगुलर एक्सप्रेशन एक ही नेमोनिक पर लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z' से, सभी कार्रवाइयों के लिए एक्ज़ीक्यूशन की जानकारी में 'x' और 'z' जुड़ जाते हैं और 'y' हट जाता है. 'Genrule=+requires-x' से, Genrule की सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी में जोड़ा जाता है. '(?!Genrule).*=-requires-x' से, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी से हटा दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis
--persistent_android_dex_desugar: वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू रखें.
इनके तौर पर दिखता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution
--persistent_android_resource_processor: वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को हमेशा चालू रखें.
बढ़कर यह हो जाता है:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_dex_desugar: वर्कर्स का इस्तेमाल करके, लगातार मल्टीप्लेक्स किए गए Android dex और desugar कार्रवाइयों को चालू करें.
इनके तौर पर दिखता है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_resource_processor: वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.
इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_tools: Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (dexing, desugaring, resource processing) चालू करें.
इनके तौर पर दिखता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--[no]use_target_platform_for_tests default: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. इसके बजाय, टेस्ट एक्ज़ेक ग्रुप का इस्तेमाल नहीं करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android": android_binary नियमों के लिए, मेनिफ़ेस्ट मर्जर को चुनता है. यह फ़्लैग, लेगसी मर्जर से Android मेनिफ़ेस्ट मर्जर पर स्विच करने में मदद करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_platforms=<a build target label> default: "": यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain": Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> default: "": यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger": यह उस बाइनरी का पाथ है जिसका इस्तेमाल रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:lcov_merger' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator": कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी का पाथ. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट वैल्यू '//tools/test:coverage_report_generator' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support": सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:coverage_support' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह कस्टम malloc को लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के पहले, - (नेगेटिव एक्सप्रेशन) का इस्तेमाल किया जा सकता है. इसे कॉमा लगाकर अलग किए गए, कंस्ट्रेंट वैल्यू टारगेट की सूची को असाइन (=) किया जाता है. अगर कोई टारगेट, किसी भी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसके टूलचेन रिज़ॉल्यूशन को इस तरह से पूरा किया जाएगा जैसे कि उसने कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर एलान किया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64 'test' नाम वाले लक्ष्यों को छोड़कर, //demo के अंतर्गत किसी भी लक्ष्य में 'x86_64' जोड़ देगा.
टैग: loading_and_analysis
--[no]experimental_include_xcode_execution_requirements default: "false": अगर सेट है, तो हर Xcode कार्रवाई में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution, experimental
--[no]experimental_prefer_mutual_xcode default: "true": अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state, experimental
--extra_execution_platforms=<comma-separated list of options> default: "": कार्रवाइयां करने के लिए उपलब्ध प्लैटफ़ॉर्म. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले माना जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, पहले की फ़्लैग सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में एलान किए गए टूलचेन से पहले माना जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह फ़्लैग कोई कार्रवाई नहीं करता. इसे आने वाले समय में हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform": यह प्लैटफ़ॉर्म के नियम का लेबल है. इससे होस्ट सिस्टम के बारे में पता चलता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_bazel_test_exec_run_under default: "false": अगर यह विकल्प चालू है, तो "bazel test --run_under=//:runner" कमांड, एक्ज़ेक कॉन्फ़िगरेशन में "//:runner" बनाता है. यह सुविधा बंद होने पर, टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true": अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution default: "false": ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_remove_legacy_whole_archive default: "true": अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_strip_executable_safely default: "false": अगर यह सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects default: "true": अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी ईएलएफ़ टूलचेन इस सेटिंग के साथ काम करते हैं.
टैग: loading_and_analysis, affects_outputs, affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे macOS ऐप्लिकेशन बनाने के लिए, macOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से macOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--minimum_os_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह ओएस का वह कम से कम वर्शन है जिसे कंपाइल करने के लिए टारगेट किया जाता है.
टैग: loading_and_analysis, affects_outputs
--platform_mappings=<a main workspace-relative path> default: "": यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य वर्कस्पेस रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, वर्कस्पेस के रूट फ़ोल्डर में मौजूद होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> default: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह py_runtime का लेबल है. यह टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर को दिखाता है. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से tvOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह विकल्प चुना जाता है, तो यह बिल्ड से जुड़ी कार्रवाइयों के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी जाती है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes": यह xcode_config नियम का लेबल है. इसका इस्तेमाल, बिल्ड कॉन्फ़िगरेशन में Xcode का वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym default: "false": डीबग सिंबल (.dSYM) वाली फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह जानकारी गलत है, तो इसे शामिल न करें. इसकी वैल्यू फ़ॉल्स होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs
--[no]build_test_dwp default: "false": अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h": cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc": cc_proto_library, सोर्स फ़ाइलों के ऐसे सफ़िक्स सेट करता है जिन्हें वह बनाता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info default: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state default: "false": कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> default: "no": इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल कौनसे कंपाइलेशन मोड करते हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data default: "true": अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]incompatible_compact_repo_mapping_manifest default: "false": अगर यह सुविधा चालू है, तो <binary>.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन की रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन, रनफ़ाइल जनरेट करने वाले हर रेपो के लिए एक बार रेपो मैपिंग दिखाने के बजाय, सिर्फ़ एक बार दिखाती है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_filegroup_runfiles_for_data default: "false": अगर सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.
टैग: incompatible_change
--[no]legacy_external_runfiles default: "false": अगर यह सही है, तो .runfiles/repo के साथ-साथ .runfiles/wsname/external/repo में मौजूद बाहरी रिपॉज़िटरी के लिए, बिल्ड रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap default: "false": इससे यह तय किया जाता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps default: "false": अगर यह सेट है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को <code>name</code> के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर के हिसाब से भी वैरिएबल को तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है. <br> ध्यान दें कि जब तक <code>--incompatible_repo_env_ignores_action_env</code> की वैल्यू सही नहीं होती, तब तक सभी <code>name=value</code> पेयर, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.
टैग: action_command_lines
--allowed_cpu_values=<comma-separated set of options> default: "": --cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs
--[no]android_databinding_use_androidx default: "true": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args default: "true": 3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> default: "off": इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तब Android के नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. ALPHABETICAL का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से पाथ के हिसाब से क्रम से लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस तरह से क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip default: "auto": Build python executable zip; on on Windows, off on other platforms
Tags: affects_outputs
--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ऐसी सूची जिसमें Apple Catalyst बाइनरी बनाने के लिए, आर्किटेक्चर को कॉमा लगाकर अलग किया गया हो.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage default: "false": अगर बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild": इससे यह तय किया जाता है कि बाइनरी किस मोड में बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> कई बार इस्तेमाल किया गया हो: gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> default: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs
--cxxopt=<a string> कई बार इस्तेमाल किया गया हो: C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, सबसे बाद वाली वैल्यू का इस्तेमाल किया जाता है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> default: "default": इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_propeller_optimize_absolute_paths default: "true": अगर यह सेट है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_remaining_fdo_absolute_paths default: "true": अगर यह नीति सेट की जाती है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs
--[no]enable_runfiles default: "auto": runfiles symlink ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows पर बंद होता है और अन्य प्लैटफ़ॉर्म पर चालू होता है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो: अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. action_listener का इस्तेमाल करके, मौजूदा बिल्ड ऐक्शन में extra_action अटैच करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources default: "false": एपीके में Java संसाधनों को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 default: "true": android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_rewrite_dexes_with_rex default: "false": use rex tool to rewrite dex files
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files default: "false": अगर बताया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental
--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1": इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines
--[no]experimental_omitfp default: "false": अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> default: "off": आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution
--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो: हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir default: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_py_binaries_include_label default: "false": py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap default: "false": अगर collect_code_coverage चालू है, तो Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true": कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental
--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है. जैसे, `//foo/bar:file.afdo`. इसके लिए, आपको संबंधित पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है. साथ ही, यह `fdo_profile` टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, `fdo_profile` नियम की जगह लागू होगा.
टैग: affects_outputs
--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कैश मेमोरी प्रीफ़ेच करने के लिए, हिंट का इस्तेमाल करें.
टैग: affects_outputs
--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.
टैग: affects_outputs
--features=<a string> कई बार इस्तेमाल किया गया हो: टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं. --host_features भी देखें
टैग: changes_inputs, affects_outputs
--[no]force_pic default: "false": अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय पीआईसी प्री-बिल्ट लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.
टैग: loading_and_analysis, affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह उन एनवायरमेंट वैरिएबल का सेट तय करता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt> default: "opt": बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल के मोड के बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C कंपाइलर को पास करने का अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है. हालांकि, C++ सोर्स फ़ाइलों को कंपाइल करते समय इसका इस्तेमाल नहीं किया जाता.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> default: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास किए जाने वाले अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_features=<a string> कई बार इस्तेमाल किया गया हो: दी गई सुविधाएं, exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs
--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: यह exec कॉन्फ़िगरेशन के लिए Python के वर्शन को बदलता है. इसे "PY2" या "PY3" पर सेट किया जा सकता है.
टैग: loading_and_analysis, affects_outputs
--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: होस्ट टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है. हालांकि, bar.cc में यह विकल्प नहीं जोड़ा जाता.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups default: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory default: "true": अगर सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में शामिल किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets default: "false": कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]": कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ ऐसे नियमों को लागू किया जाता है जो टेस्ट नहीं किए गए हैं. हालांकि, अगर --instrument_test_targets विकल्प चालू है, तो टेस्ट किए गए नियमों को भी लागू किया जा सकता है.
टैग: affects_outputs
--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'ios_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें बताए गए सभी आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive default: "true": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated
--linkopt=<a string> कई बार इस्तेमाल किया गया हो: लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो: LTO के बैकएंड चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो: एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple macOS के बाइनरी फ़ाइलें बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.
टैग: loses_incremental_state, loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs
--[no]objc_debug_with_GLIBCXX default: "false": अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping default: "false": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines
--objccopt=<a string> कई बार इस्तेमाल किया गया हो: Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ बैकएंड ऑब्जेक्ट कंपाइल करते समय, LTO बैकएंड (under --features=thin_lto) को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों की एलटीओ बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis
--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें. Propeller प्रोफ़ाइल में कम से कम दो फ़ाइलों में से एक फ़ाइल होनी चाहिए. ये फ़ाइलें cc प्रोफ़ाइल और ld प्रोफ़ाइल हैं. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस देता है. उदाहरण के लिए, a/b/BUILD में मौजूद BUILD फ़ाइल, लेबल को इस तरह से तय करती है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नेम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]share_native_deps default: "true": अगर यह वैल्यू सही है, तो एक जैसी फ़ंक्शनैलिटी वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs
--[no]stamp default: "false": तारीख, उपयोगकर्ता नाम, होस्टनेम, वर्कस्पेस की जानकारी वगैरह के साथ बाइनरी पर स्टैंप लगाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.
टैग: affects_outputs
--stripopt=<a string> कई बार इस्तेमाल किया गया हो: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple tvOS के बाइनरी फ़ाइलें बनाने के लिए, आर्किटेक्चर की कॉमा लगाकर अलग की गई सूची.
टैग: loses_incremental_state, loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple visionOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.
टैग: affects_outputs

--[no]check_licenses default: "false": देखें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]desugar_for_android default: "true": Java 8 के बाइटकोड को डेक्सिंग से पहले डीशुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs default: "false": लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की सुविधा वाली लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints default: "true": यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps default: "true": Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental
--experimental_import_deps_checking=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कोई कार्रवाई नहीं की गई, इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है
टैग: loading_and_analysis
--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है": इस विकल्प को चालू करने पर, यह पक्का किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल न हों. नीति उल्लंघन ठीक करने के लिए की गई कार्रवाई से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.
टैग: loading_and_analysis
--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default": अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files default: "false": अगर यह चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मिलती-जुलती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains default: "false": इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules default: "false": यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule default: "false": कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]one_version_enforcement_on_java_tests default: "true": इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.
टैग: loading_and_analysis
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: --incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल करने के लिए, अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis
--[no]strict_filesets default: "false": अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> default: "off": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes default: "false": अगर यह वैल्यू सही है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित किए जाने चाहिए.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2": APK पर साइन करने के लिए इस्तेमाल किया जाने वाला तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis
--[no]device_debug_entitlements default: "true": अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो हस्ताक्षर करते समय, objc ऐप्लिकेशन में डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs
--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें: iOS पर साइन करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.
टैग: action_command_lines

--[no]incompatible_disallow_legacy_py_provider default: "true": यह कोई कार्रवाई नहीं करता है. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes default: "false": अगर यह सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_alwayslink_by_default default: "false": अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules default: "false": जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures default: "false": अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के इंस्टेंस को AnalysisFailureInfo का इंस्टेंस मिलेगा. इसमें गड़बड़ी की जानकारी होगी. इससे बिल्ड पूरा नहीं होगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन वाले नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure default: "false": अगर dex2oat की कार्रवाई पूरी नहीं होती है, तो टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय, बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो: टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की रकम को बदल देंगे. वैल्यू, HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]<float> (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4) भी हो सकता है. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में तय किए गए संसाधनों से बदल दिया जाता है.
--[no]experimental_android_use_parallel_dex2oat default: "false": android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks default: "false": ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines
--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. उदाहरण के लिए, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची देखी जा सकती है.
टैग: test_runner
--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर पर चलाने या जांच करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner
--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो: इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी वजह से इनमें से कोई भी कोशिश पूरी नहीं होती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू से है. वहीं, regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को तीन बार नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. मिलते-जुलते सबसे हाल के तर्क को प्राथमिकता दी जाती है. अगर कोई भी शर्त पूरी नहीं होती है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.
--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
टैग: test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट के टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करने के लिए कहा जाता है.
--[no]zip_undeclared_test_outputs default: "false": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो बिना बताए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

--[no]experimental_filter_library_jar_with_program_jar default: "false": ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास हटाई जा सकें.
टैग: action_command_lines, experimental
--[no]experimental_inmemory_dotd_files default: "true": अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly default: "false": इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट से जुड़े नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_starlark_cc_import default: "false": यह विकल्प चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning default: "false": क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता है और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental
--[no]incremental_dexing default: "true": यह हर जार फ़ाइल के लिए, अलग से डेक्सिंग का ज़्यादातर काम करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning default: "true": अगर इस विकल्प को सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल किया जाएगा. इससे, objc कंपाइलर को पास किए गए इनपुट के सेट को कम किया जा सकेगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies default: "false": When building a target //a:a, process headers in all targets that //a:a depends on (if header processing is enabled for the toolchain).
टैग: execution
--[no]trim_test_configuration default: "true": यह सुविधा चालू होने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*": टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.
टैग: terminal_output

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py default: "false": इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन पाएं. खास तौर पर, जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इस फ़्लैग को सेट करने पर ही इसे गलत माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed default: "true": अगर यह 'सही है', तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, ऐसे आउटपुट रूट में दिखेंगे जिसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिमलिंक, Python 2 के बजाय Python 3 के टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default default: "true": अगर यह सही है, तो `py_binary` और `py_test` टारगेट, `python_version` या `default_python_version` एट्रिब्यूट सेट नहीं करते हैं. ऐसे में, ये टारगेट डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. इस फ़्लैग को सेट करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py2_outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains default: "true": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के एक्ज़ीक्यूटेबल नेटिव नियम, Python टूलचेन के ज़रिए तय किए गए Python रनटाइम का इस्तेमाल करेंगे. इसके बजाय, वे --python_top जैसे लेगसी फ़्लैग के ज़रिए दिए गए रनटाइम का इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change
--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: Python का मुख्य वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट से बदला जाता है. भले ही, वे साफ़ तौर पर किसी वर्शन के बारे में न बताते हों. इसलिए, आम तौर पर इस फ़्लैग को सप्लाई करने की कोई वजह नहीं होती.
टैग: loading_and_analysis, affects_outputs

--[no]cache_test_results [-t] default: "auto": अगर इसे 'auto' पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें बाहरी के तौर पर मार्क नहीं किया गया है. 'नहीं' पर सेट होने पर, Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.
--[no]experimental_cancel_concurrent_tests default: "never": अगर 'on_failed' या 'on_passed' है, तो Blaze उस नतीजे के साथ पहली बार चलने वाले टेस्ट को रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_fetch_all_coverage_outputs default: "false": अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_generate_llvm_lcov default: "false": अगर यह विकल्प सही पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_j2objc_header_map default: "true": J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental
--[no]experimental_j2objc_shorter_header_path default: "false": क्या हेडर पाथ को छोटा करके जनरेट करना है. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "javabuilder": इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.
--[no]experimental_limit_android_lint_to_android_constrained_java default: "false": No-op, kept only for backwards compatibility
Tags: affects_outputs, experimental
--[no]experimental_run_android_lint_on_java_rules default: "false": java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs, experimental
--[no]explicit_java_test_deps default: "false": java_test में, TestRunner की deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.
--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, javac को पास करने के लिए अतिरिक्त विकल्प.
--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्डिंग टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये टूल, बिल्ड के दौरान एक्ज़ीक्यूट किए जाते हैं. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support default: "true": अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को तब फ़ेल कर देगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में मौजूद पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, हर शार्ड में सभी टेस्ट चलाएगा.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed default: "true": अगर यह वैल्यू सही है, तो सैंडबॉक्स की गई रणनीति के साथ खास टेस्ट चलाए जाएंगे. 'local' टैग जोड़कर, स्थानीय तौर पर सिर्फ़ एक टेस्ट रन करें
टैग: incompatible_change
--[no]incompatible_strict_action_env default: "false": अगर यह विकल्प सही है, तो Bazel ऐसे एनवायरमेंट का इस्तेमाल करता है जिसमें PATH के लिए स्टैटिक वैल्यू होती है. साथ ही, यह LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने से, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा. ऐसा तब होगा, जब शेयर की गई कैश मेमोरी का इस्तेमाल किया जा रहा हो.
टैग: loading_and_analysis, incompatible_change
--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.
--java_debug: इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इनमें बदल जाता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps default: "true": हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करें. फ़िलहाल, यह जानकारी कंपाइल-टाइम क्लासपाथ के लिए जनरेट की जाती है.
--[no]java_header_compilation default: "true": सोर्स से सीधे तौर पर ijars कंपाइल करें.
--java_language_version=<a string> default: "": Java भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट, इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": Java रनटाइम का वर्शन
--javacopt=<a string> कई बार इस्तेमाल किया गया हो: javac को पास करने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> कई बार इस्तेमाल किया गया हो: Java VM को पास करने के लिए अतिरिक्त विकल्प. इन विकल्पों को हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिया जाएगा.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किए जाने वाले बाइनरी के बारे में बताता है.
--plugin=<a build target label> कई बार इस्तेमाल किया गया हो: बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.
--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प से यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.
--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--[no]proto_profile default: "true": प्रोफ़ाइल_पाथ को प्रोटो कंपाइलर को पास करना है या नहीं.
टैग: affects_outputs, loading_and_analysis
--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल, जो C++ प्रोटो को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि j2objc protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि Java protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि JavaLite protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--protocopt=<a string> कई बार इस्तेमाल किया गया हो: प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs
--[no]runs_per_test_detects_flakes default: "false": अगर यह वैल्यू सही है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.
--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का ऐब्सलूट पाथ. अगर इसे सेट नहीं किया जाता है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन (जो Bazel सर्वर शुरू करता है) पर सेट किया जाता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. जैसे, Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी फ़ाइलों को बनाने या उन्हें चलाने में समस्याएं आ सकती हैं.
टैग: loading_and_analysis
--test_arg=<a string> कई बार इस्तेमाल किया गया हो: यह अतिरिक्त विकल्प और आर्ग्युमेंट तय करता है. इन्हें टेस्ट एक्ज़ीक्यूटेबल को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast default: "false": यह विकल्प, टेस्ट रनर को फ़ेल फ़ास्ट की जानकारी देता है. पहली गड़बड़ी होने पर, टेस्ट रनर को टेस्ट बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'shard_count' BUILD एट्रिब्यूट मौजूद होने पर ही शार्डिंग का इस्तेमाल करने के लिए, 'explicit' का इस्तेमाल करें. 'disabled' को कभी भी टेस्ट शार्डिंग का इस्तेमाल न करने के लिए सेट करें. 'forced=k' का इस्तेमाल, 'shard_count' BUILD एट्रिब्यूट के बावजूद, टेस्टिंग के लिए 'k' शार्ड लागू करने के लिए किया जाता है.
--tool_java_language_version=<a string> default: "": The Java language version used to execute the tools that are needed during a build
--tool_java_runtime_version=<a string> default: "remotejdk_11": बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

डंप के विकल्प

--[no]action_cache default: "false": ऐक्शन की कैश मेमोरी में सेव किया गया कॉन्टेंट डंप करें.
टैग: bazel_monitoring
--memory=<memory mode> डिफ़ॉल्ट: ब्यौरा देखें: दिए गए Skyframe नोड के लिए, मेमोरी के इस्तेमाल की जानकारी डंप करें.
टैग: bazel_monitoring
--[no]packages default: "false": पैकेज की कैश मेमोरी में सेव किए गए कॉन्टेंट को डंप करें.
टैग: bazel_monitoring
--[no]rule_classes default: "false": नियमों की क्लास डंप करें.
टैग: bazel_monitoring
--[no]rules default: "false": डंप के नियम. इनमें डंप की संख्या और मेमोरी के इस्तेमाल की जानकारी शामिल होती है. हालांकि, यह जानकारी सिर्फ़ तब शामिल होती है, जब मेमोरी को ट्रैक किया जाता है.
टैग: bazel_monitoring
--skyframe=<off, summary, count, value, deps, rdeps, function_graph, working_set or working_set_frontier_deps> default: "off": Skyframe ग्राफ़ को डंप करें.
टैग: bazel_monitoring
--skykey_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: ".*": आउटपुट के लिए SkyKey के नामों का रेगुलर एक्सप्रेशन वाला फ़िल्टर. इसका इस्तेमाल सिर्फ़ --skyframe=deps, rdeps, function_graph के साथ किया जाता है.
टैग: bazel_monitoring
--skylark_memory=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कमांड, pprof के साथ काम करने वाली मेमोरी प्रोफ़ाइल को तय किए गए पाथ पर डंप करती है. ज़्यादा जानने के लिए, कृपया https://github.com/google/pprof पर जाएं.
टैग: bazel_monitoring

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

डेटा फ़ेच करने के विकल्प

test से सभी विकल्प इनहेरिट करता है.

--[no]all default: "false": यह किसी टारगेट या रिपॉज़िटरी को बनाने के लिए ज़रूरी सभी बाहरी रिपॉज़िटरी को फ़ेच करता है. अगर कोई अन्य फ़्लैग और तर्क नहीं दिया गया है, तो यह डिफ़ॉल्ट रूप से लागू होता है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--[no]keep_going [-k] डिफ़ॉल्ट: "false": गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उन पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto": लोडिंग/विश्लेषण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto" वैल्यू, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करती है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--[no]incompatible_config_setting_private_default_visibility default: "false": अगर incompatible_enforce_config_setting_visibility=false है, तो यह एक noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होगी. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enforce_config_setting_visibility default: "true": अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है', तो हर config_setting, हर टारगेट को दिखेगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names default: "true": No-op.
टैग: loading_and_analysis

--[no]configure default: "false": सिर्फ़ उन रिपॉज़िटरी को फ़ेच करता है जिन्हें सिस्टम कॉन्फ़िगरेशन के मकसद से 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--[no]force default: "false": अगर कोई मौजूदा रिपॉज़िटरी है, तो उसे अनदेखा करें और रिपॉज़िटरी को फिर से फ़ेच करें. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--repo=<a string> कई बार इस्तेमाल किया गया हो: सिर्फ़ बताई गई रिपॉज़िटरी को फ़ेच करता है. यह {@apparent_repo_name} या {@@canonical_repo_name} हो सकती है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs

--experimental_repository_resolved_file=<a string> default: "": अगर यह खाली नहीं है, तो Starlark वैल्यू लिखें. इसमें Starlark रिपॉज़िटरी के उन सभी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD मिटा दिया है, तो बिल्ड सिस्टम को शिकायत मिल सकती है. ऐसा तब होगा, जब उसे '//x:y/z' लेबल मिलेगा. हालांकि, यह लेबल अब भी package_path की किसी दूसरी एंट्री से मिल रहा होगा. --deleted_packages x/y विकल्प का इस्तेमाल करके, इस समस्या से बचा जा सकता है.
--[no]fetch default: "true": इस कमांड की मदद से, बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर कोई भी वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस से जुड़े होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट वैल्यू 'bazel info default-package-path' का आउटपुट होती है.
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

--[no]experimental_inprocess_symlink_creation default: "true": सिंबल लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या हेल्पर प्रोसेस को डेलिगेट करना है.
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor default: "false": वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution, experimental
--[no]experimental_remotable_source_manifests default: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing default: "false": अगर यह विकल्प सही है, तो Bazel, टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.
टैग: execution, experimental
--[no]experimental_strict_fileset_output default: "false": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental
--[no]incompatible_modify_execution_info_additive default: "false": इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो: कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि कई रेगुलर एक्सप्रेशन एक ही नेमोनिक पर लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z' से, सभी कार्रवाइयों के लिए एक्ज़ीक्यूशन की जानकारी में 'x' और 'z' जुड़ जाते हैं और 'y' हट जाता है. 'Genrule=+requires-x' से, Genrule की सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी में जोड़ा जाता है. '(?!Genrule).*=-requires-x' से, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी से हटा दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis
--persistent_android_dex_desugar: वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू रखें.
इनके तौर पर दिखता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution
--persistent_android_resource_processor: वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को हमेशा चालू रखें.
बढ़कर यह हो जाता है:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_dex_desugar: वर्कर्स का इस्तेमाल करके, लगातार मल्टीप्लेक्स किए गए Android dex और desugar कार्रवाइयों को चालू करें.
इनके तौर पर दिखता है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_resource_processor: वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.
इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_tools: Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (dexing, desugaring, resource processing) चालू करें.
इनके तौर पर दिखता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--[no]use_target_platform_for_tests default: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. इसके बजाय, टेस्ट एक्ज़ेक ग्रुप का इस्तेमाल नहीं करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android": android_binary नियमों के लिए, मेनिफ़ेस्ट मर्जर को चुनता है. यह फ़्लैग, लेगसी मर्जर से Android मेनिफ़ेस्ट मर्जर पर स्विच करने में मदद करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_platforms=<a build target label> default: "": यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain": Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> default: "": यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger": यह उस बाइनरी का पाथ है जिसका इस्तेमाल रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:lcov_merger' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator": कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी का पाथ. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट वैल्यू '//tools/test:coverage_report_generator' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support": सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:coverage_support' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह कस्टम malloc को लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के पहले, - (नेगेटिव एक्सप्रेशन) का इस्तेमाल किया जा सकता है. इसे कॉमा लगाकर अलग किए गए, कंस्ट्रेंट वैल्यू टारगेट की सूची को असाइन (=) किया जाता है. अगर कोई टारगेट, किसी भी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसके टूलचेन रिज़ॉल्यूशन को इस तरह से पूरा किया जाएगा जैसे कि उसने कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर एलान किया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64 'test' नाम वाले लक्ष्यों को छोड़कर, //demo के अंतर्गत किसी भी लक्ष्य में 'x86_64' जोड़ देगा.
टैग: loading_and_analysis
--[no]experimental_include_xcode_execution_requirements default: "false": अगर सेट है, तो हर Xcode कार्रवाई में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution, experimental
--[no]experimental_prefer_mutual_xcode default: "true": अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state, experimental
--extra_execution_platforms=<comma-separated list of options> default: "": कार्रवाइयां करने के लिए उपलब्ध प्लैटफ़ॉर्म. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले माना जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, पहले की फ़्लैग सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में एलान किए गए टूलचेन से पहले माना जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह फ़्लैग कोई कार्रवाई नहीं करता. इसे आने वाले समय में हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform": यह प्लैटफ़ॉर्म के नियम का लेबल है. इससे होस्ट सिस्टम के बारे में पता चलता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_bazel_test_exec_run_under default: "false": अगर यह विकल्प चालू है, तो "bazel test --run_under=//:runner" कमांड, एक्ज़ेक कॉन्फ़िगरेशन में "//:runner" बनाता है. यह सुविधा बंद होने पर, टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true": अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution default: "false": ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_remove_legacy_whole_archive default: "true": अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_strip_executable_safely default: "false": अगर यह सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects default: "true": अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी ईएलएफ़ टूलचेन इस सेटिंग के साथ काम करते हैं.
टैग: loading_and_analysis, affects_outputs, affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे macOS ऐप्लिकेशन बनाने के लिए, macOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से macOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--minimum_os_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह ओएस का वह कम से कम वर्शन है जिसे कंपाइल करने के लिए टारगेट किया जाता है.
टैग: loading_and_analysis, affects_outputs
--platform_mappings=<a main workspace-relative path> default: "": यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य वर्कस्पेस रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, वर्कस्पेस के रूट फ़ोल्डर में मौजूद होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> default: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह py_runtime का लेबल है. यह टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर को दिखाता है. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से tvOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह विकल्प चुना जाता है, तो यह बिल्ड से जुड़ी कार्रवाइयों के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी जाती है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes": यह xcode_config नियम का लेबल है. इसका इस्तेमाल, बिल्ड कॉन्फ़िगरेशन में Xcode का वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym default: "false": डीबग सिंबल (.dSYM) वाली फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह जानकारी गलत है, तो इसे शामिल न करें. इसकी वैल्यू फ़ॉल्स होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs
--[no]build_test_dwp default: "false": अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h": cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc": cc_proto_library, सोर्स फ़ाइलों के ऐसे सफ़िक्स सेट करता है जिन्हें वह बनाता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info default: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state default: "false": कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> default: "no": इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल कौनसे कंपाइलेशन मोड करते हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data default: "true": अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]incompatible_compact_repo_mapping_manifest default: "false": अगर यह सुविधा चालू है, तो <binary>.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन की रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन, रनफ़ाइल जनरेट करने वाले हर रेपो के लिए एक बार रेपो मैपिंग दिखाने के बजाय, सिर्फ़ एक बार दिखाती है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_filegroup_runfiles_for_data default: "false": अगर सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.
टैग: incompatible_change
--[no]legacy_external_runfiles default: "false": अगर यह सही है, तो .runfiles/repo के साथ-साथ .runfiles/wsname/external/repo में मौजूद बाहरी रिपॉज़िटरी के लिए, बिल्ड रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap default: "false": इससे यह तय किया जाता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps default: "false": अगर यह सेट है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को <code>name</code> के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर के हिसाब से भी वैरिएबल को तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है. <br> ध्यान दें कि जब तक <code>--incompatible_repo_env_ignores_action_env</code> की वैल्यू सही नहीं होती, तब तक सभी <code>name=value</code> पेयर, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.
टैग: action_command_lines
--allowed_cpu_values=<comma-separated set of options> default: "": --cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs
--[no]android_databinding_use_androidx default: "true": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args default: "true": 3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> default: "off": इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तब Android के नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. ALPHABETICAL का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से पाथ के हिसाब से क्रम से लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस तरह से क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip default: "auto": Build python executable zip; on on Windows, off on other platforms
Tags: affects_outputs
--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ऐसी सूची जिसमें Apple Catalyst बाइनरी बनाने के लिए, आर्किटेक्चर को कॉमा लगाकर अलग किया गया हो.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage default: "false": अगर बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild": इससे यह तय किया जाता है कि बाइनरी किस मोड में बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> कई बार इस्तेमाल किया गया हो: gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> default: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs
--cxxopt=<a string> कई बार इस्तेमाल किया गया हो: C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, सबसे बाद वाली वैल्यू का इस्तेमाल किया जाता है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> default: "default": इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_propeller_optimize_absolute_paths default: "true": अगर यह सेट है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_remaining_fdo_absolute_paths default: "true": अगर यह नीति सेट की जाती है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs
--[no]enable_runfiles default: "auto": runfiles symlink ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows पर बंद होता है और अन्य प्लैटफ़ॉर्म पर चालू होता है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो: अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. action_listener का इस्तेमाल करके, मौजूदा बिल्ड ऐक्शन में extra_action अटैच करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources default: "false": एपीके में Java संसाधनों को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 default: "true": android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_rewrite_dexes_with_rex default: "false": use rex tool to rewrite dex files
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files default: "false": अगर बताया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental
--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1": इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines
--[no]experimental_omitfp default: "false": अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> default: "off": आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution
--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो: हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir default: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_py_binaries_include_label default: "false": py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap default: "false": अगर collect_code_coverage चालू है, तो Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true": कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental
--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है. जैसे, `//foo/bar:file.afdo`. इसके लिए, आपको संबंधित पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है. साथ ही, यह `fdo_profile` टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, `fdo_profile` नियम की जगह लागू होगा.
टैग: affects_outputs
--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कैश मेमोरी प्रीफ़ेच करने के लिए, हिंट का इस्तेमाल करें.
टैग: affects_outputs
--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.
टैग: affects_outputs
--features=<a string> कई बार इस्तेमाल किया गया हो: टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं. --host_features भी देखें
टैग: changes_inputs, affects_outputs
--[no]force_pic default: "false": अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय पीआईसी प्री-बिल्ट लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.
टैग: loading_and_analysis, affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह उन एनवायरमेंट वैरिएबल का सेट तय करता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt> default: "opt": बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल के मोड के बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C कंपाइलर को पास करने का अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है. हालांकि, C++ सोर्स फ़ाइलों को कंपाइल करते समय इसका इस्तेमाल नहीं किया जाता.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> default: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास किए जाने वाले अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_features=<a string> कई बार इस्तेमाल किया गया हो: दी गई सुविधाएं, exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs
--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: यह exec कॉन्फ़िगरेशन के लिए Python के वर्शन को बदलता है. इसे "PY2" या "PY3" पर सेट किया जा सकता है.
टैग: loading_and_analysis, affects_outputs
--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: होस्ट टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है. हालांकि, bar.cc में यह विकल्प नहीं जोड़ा जाता.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups default: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory default: "true": अगर सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में शामिल किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets default: "false": कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]": कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ ऐसे नियमों को लागू किया जाता है जो टेस्ट नहीं किए गए हैं. हालांकि, अगर --instrument_test_targets विकल्प चालू है, तो टेस्ट किए गए नियमों को भी लागू किया जा सकता है.
टैग: affects_outputs
--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'ios_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें बताए गए सभी आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive default: "true": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated
--linkopt=<a string> कई बार इस्तेमाल किया गया हो: लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो: LTO के बैकएंड चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो: एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple macOS के बाइनरी फ़ाइलें बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.
टैग: loses_incremental_state, loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs
--[no]objc_debug_with_GLIBCXX default: "false": अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping default: "false": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines
--objccopt=<a string> कई बार इस्तेमाल किया गया हो: Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ बैकएंड ऑब्जेक्ट कंपाइल करते समय, LTO बैकएंड (under --features=thin_lto) को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों की एलटीओ बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis
--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें. Propeller प्रोफ़ाइल में कम से कम दो फ़ाइलों में से एक फ़ाइल होनी चाहिए. ये फ़ाइलें cc प्रोफ़ाइल और ld प्रोफ़ाइल हैं. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस देता है. उदाहरण के लिए, a/b/BUILD में मौजूद BUILD फ़ाइल, लेबल को इस तरह से तय करती है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नेम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]share_native_deps default: "true": अगर यह वैल्यू सही है, तो एक जैसी फ़ंक्शनैलिटी वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs
--[no]stamp default: "false": तारीख, उपयोगकर्ता नाम, होस्टनेम, वर्कस्पेस की जानकारी वगैरह के साथ बाइनरी पर स्टैंप लगाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.
टैग: affects_outputs
--stripopt=<a string> कई बार इस्तेमाल किया गया हो: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple tvOS के बाइनरी फ़ाइलें बनाने के लिए, आर्किटेक्चर की कॉमा लगाकर अलग की गई सूची.
टैग: loses_incremental_state, loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple visionOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.
टैग: affects_outputs

--[no]check_licenses default: "false": देखें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]desugar_for_android default: "true": Java 8 के बाइटकोड को डेक्सिंग से पहले डीशुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs default: "false": लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की सुविधा वाली लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints default: "true": यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps default: "true": Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental
--experimental_import_deps_checking=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कोई कार्रवाई नहीं की गई, इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है
टैग: loading_and_analysis
--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है": इस विकल्प को चालू करने पर, यह पक्का किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल न हों. नीति उल्लंघन ठीक करने के लिए की गई कार्रवाई से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.
टैग: loading_and_analysis
--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default": अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files default: "false": अगर यह चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मिलती-जुलती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains default: "false": इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules default: "false": यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule default: "false": कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]one_version_enforcement_on_java_tests default: "true": इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.
टैग: loading_and_analysis
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: --incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल करने के लिए, अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis
--[no]strict_filesets default: "false": अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> default: "off": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes default: "false": अगर यह वैल्यू सही है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित किए जाने चाहिए.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2": APK पर साइन करने के लिए इस्तेमाल किया जाने वाला तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis
--[no]device_debug_entitlements default: "true": अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो हस्ताक्षर करते समय, objc ऐप्लिकेशन में डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs
--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें: iOS पर साइन करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.
टैग: action_command_lines

--[no]incompatible_disallow_legacy_py_provider default: "true": यह कोई कार्रवाई नहीं करता है. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes default: "false": अगर यह सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_alwayslink_by_default default: "false": अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules default: "false": जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures default: "false": अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के इंस्टेंस को AnalysisFailureInfo का इंस्टेंस मिलेगा. इसमें गड़बड़ी की जानकारी होगी. इससे बिल्ड पूरा नहीं होगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन वाले नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure default: "false": अगर dex2oat की कार्रवाई पूरी नहीं होती है, तो टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय, बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो: टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की रकम को बदल देंगे. वैल्यू, HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]<float> (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4) भी हो सकता है. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में तय किए गए संसाधनों से बदल दिया जाता है.
--[no]experimental_android_use_parallel_dex2oat default: "false": android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks default: "false": ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines
--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. उदाहरण के लिए, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची देखी जा सकती है.
टैग: test_runner
--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर पर चलाने या जांच करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner
--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो: इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी वजह से इनमें से कोई भी कोशिश पूरी नहीं होती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू से है. वहीं, regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को तीन बार नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. मिलते-जुलते सबसे हाल के तर्क को प्राथमिकता दी जाती है. अगर कोई भी शर्त पूरी नहीं होती है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.
--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
टैग: test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट के टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करने के लिए कहा जाता है.
--[no]zip_undeclared_test_outputs default: "false": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो बिना बताए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

--[no]experimental_filter_library_jar_with_program_jar default: "false": ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास हटाई जा सकें.
टैग: action_command_lines, experimental
--[no]experimental_inmemory_dotd_files default: "true": अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly default: "false": इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट से जुड़े नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_starlark_cc_import default: "false": यह विकल्प चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning default: "false": क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता है और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental
--[no]incremental_dexing default: "true": यह हर जार फ़ाइल के लिए, अलग से डेक्सिंग का ज़्यादातर काम करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning default: "true": अगर इस विकल्प को सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल किया जाएगा. इससे, objc कंपाइलर को पास किए गए इनपुट के सेट को कम किया जा सकेगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies default: "false": When building a target //a:a, process headers in all targets that //a:a depends on (if header processing is enabled for the toolchain).
टैग: execution
--[no]trim_test_configuration default: "true": यह सुविधा चालू होने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*": टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.
टैग: terminal_output

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py default: "false": इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन पाएं. खास तौर पर, जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इस फ़्लैग को सेट करने पर ही इसे गलत माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed default: "true": अगर यह 'सही है', तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, ऐसे आउटपुट रूट में दिखेंगे जिसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिमलिंक, Python 2 के बजाय Python 3 के टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default default: "true": अगर यह सही है, तो `py_binary` और `py_test` टारगेट, `python_version` या `default_python_version` एट्रिब्यूट सेट नहीं करते हैं. ऐसे में, ये टारगेट डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. इस फ़्लैग को सेट करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py2_outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains default: "true": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के एक्ज़ीक्यूटेबल नेटिव नियम, Python टूलचेन के ज़रिए तय किए गए Python रनटाइम का इस्तेमाल करेंगे. इसके बजाय, वे --python_top जैसे लेगसी फ़्लैग के ज़रिए दिए गए रनटाइम का इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change
--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: Python का मुख्य वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट से बदला जाता है. भले ही, वे साफ़ तौर पर किसी वर्शन के बारे में न बताते हों. इसलिए, आम तौर पर इस फ़्लैग को सप्लाई करने की कोई वजह नहीं होती.
टैग: loading_and_analysis, affects_outputs

--[no]cache_test_results [-t] default: "auto": अगर इसे 'auto' पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें बाहरी के तौर पर मार्क नहीं किया गया है. 'नहीं' पर सेट होने पर, Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.
--[no]experimental_cancel_concurrent_tests default: "never": अगर 'on_failed' या 'on_passed' है, तो Blaze उस नतीजे के साथ पहली बार चलने वाले टेस्ट को रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_fetch_all_coverage_outputs default: "false": अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_generate_llvm_lcov default: "false": अगर यह विकल्प सही पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_j2objc_header_map default: "true": J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental
--[no]experimental_j2objc_shorter_header_path default: "false": क्या हेडर पाथ को छोटा करके जनरेट करना है. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "javabuilder": इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.
--[no]experimental_limit_android_lint_to_android_constrained_java default: "false": No-op, kept only for backwards compatibility
Tags: affects_outputs, experimental
--[no]experimental_run_android_lint_on_java_rules default: "false": java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs, experimental
--[no]explicit_java_test_deps default: "false": java_test में, TestRunner की deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.
--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, javac को पास करने के लिए अतिरिक्त विकल्प.
--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्डिंग टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये टूल, बिल्ड के दौरान एक्ज़ीक्यूट किए जाते हैं. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support default: "true": अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को तब फ़ेल कर देगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में मौजूद पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, हर शार्ड में सभी टेस्ट चलाएगा.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed default: "true": अगर यह वैल्यू सही है, तो सैंडबॉक्स की गई रणनीति के साथ खास टेस्ट चलाए जाएंगे. 'local' टैग जोड़कर, स्थानीय तौर पर सिर्फ़ एक टेस्ट रन करें
टैग: incompatible_change
--[no]incompatible_strict_action_env default: "false": अगर यह विकल्प सही है, तो Bazel ऐसे एनवायरमेंट का इस्तेमाल करता है जिसमें PATH के लिए स्टैटिक वैल्यू होती है. साथ ही, यह LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने से, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा. ऐसा तब होगा, जब शेयर की गई कैश मेमोरी का इस्तेमाल किया जा रहा हो.
टैग: loading_and_analysis, incompatible_change
--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.
--java_debug: इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इनमें बदल जाता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps default: "true": हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करें. फ़िलहाल, यह जानकारी कंपाइल-टाइम क्लासपाथ के लिए जनरेट की जाती है.
--[no]java_header_compilation default: "true": सोर्स से सीधे तौर पर ijars कंपाइल करें.
--java_language_version=<a string> default: "": Java भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट, इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": Java रनटाइम का वर्शन
--javacopt=<a string> कई बार इस्तेमाल किया गया हो: javac को पास करने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> कई बार इस्तेमाल किया गया हो: Java VM को पास करने के लिए अतिरिक्त विकल्प. इन विकल्पों को हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिया जाएगा.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किए जाने वाले बाइनरी के बारे में बताता है.
--plugin=<a build target label> कई बार इस्तेमाल किया गया हो: बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.
--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प से यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.
--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--[no]proto_profile default: "true": प्रोफ़ाइल_पाथ को प्रोटो कंपाइलर को पास करना है या नहीं.
टैग: affects_outputs, loading_and_analysis
--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल, जो C++ प्रोटो को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि j2objc protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि Java protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि JavaLite protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--protocopt=<a string> कई बार इस्तेमाल किया गया हो: प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs
--[no]runs_per_test_detects_flakes default: "false": अगर यह वैल्यू सही है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.
--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का ऐब्सलूट पाथ. अगर इसे सेट नहीं किया जाता है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन (जो Bazel सर्वर शुरू करता है) पर सेट किया जाता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. जैसे, Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी फ़ाइलों को बनाने या उन्हें चलाने में समस्याएं आ सकती हैं.
टैग: loading_and_analysis
--test_arg=<a string> कई बार इस्तेमाल किया गया हो: यह अतिरिक्त विकल्प और आर्ग्युमेंट तय करता है. इन्हें टेस्ट एक्ज़ीक्यूटेबल को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast default: "false": यह विकल्प, टेस्ट रनर को फ़ेल फ़ास्ट की जानकारी देता है. पहली गड़बड़ी होने पर, टेस्ट रनर को टेस्ट बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'shard_count' BUILD एट्रिब्यूट मौजूद होने पर ही शार्डिंग का इस्तेमाल करने के लिए, 'explicit' का इस्तेमाल करें. 'disabled' को कभी भी टेस्ट शार्डिंग का इस्तेमाल न करने के लिए सेट करें. 'forced=k' का इस्तेमाल, 'shard_count' BUILD एट्रिब्यूट के बावजूद, टेस्टिंग के लिए 'k' शार्ड लागू करने के लिए किया जाता है.
--tool_java_language_version=<a string> default: "": The Java language version used to execute the tools that are needed during a build
--tool_java_runtime_version=<a string> default: "remotejdk_11": बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

सहायता के विकल्प

--[no]incompatible_use_plus_in_repo_names default: "true": No-op.
टैग: loading_and_analysis

--help_verbosity=<long, medium or short> default: "medium": सहायता कमांड के लिए वर्बोसिटी लेवल चुनें.
टैग: terminal_output
--long [-l]: हर विकल्प के सिर्फ़ नाम के बजाय, उसकी पूरी जानकारी दिखाएं.
इनके लिए उपलब्ध है:
--help_verbosity=long

टैग: terminal_output
--short: सिर्फ़ विकल्पों के नाम दिखाओ, उनके टाइप या मतलब नहीं.
इनमें बदल जाता है:
--help_verbosity=short

टैग: terminal_output

जानकारी के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

--[no]incompatible_use_plus_in_repo_names default: "true": No-op.
टैग: loading_and_analysis

--[no]show_make_env default: "false": आउटपुट में "Make" एनवायरमेंट को शामिल करें.
टैग: affects_outputs, terminal_output

लाइसेंस के विकल्प

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

मोबाइल ऐप्लिकेशन इंस्टॉल करने के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

--mode=<classic, classic_internal_test_do_not_use or skylark> default: "skylark": no-effect फ़्लैग अब काम नहीं करता. सिर्फ़ स्काईलार्क मोड अब भी काम करता है.
टैग: loading_and_analysis, execution, incompatible_change

--adb=<a string> default: "": 'mobile-install' कमांड के लिए इस्तेमाल किया जाने वाला adb बाइनरी. अगर कोई SDK टूल नहीं दिया गया है, तो --android_sdk_channel कमांड-लाइन विकल्प में दिए गए Android SDK टूल का इस्तेमाल किया जाता है. अगर --android_sdk_channel विकल्प नहीं दिया गया है, तो डिफ़ॉल्ट SDK टूल का इस्तेमाल किया जाता है.
टैग: changes_inputs

--[no]incremental default: "false": यह तय करता है कि इंक्रीमेंटल इंस्टॉल करना है या नहीं. अगर ऐसा है, तो जिस डिवाइस पर कोड इंस्टॉल करना है उसकी स्थिति पढ़कर, गैर-ज़रूरी अतिरिक्त काम से बचें. साथ ही, उस जानकारी का इस्तेमाल करके, गैर-ज़रूरी काम से बचें. अगर यह वैल्यू 'गलत है' (डिफ़ॉल्ट रूप से), तो हमेशा पूरा इंस्टॉलेशन करें.
टैग: loading_and_analysis
--[no]split_apks default: "false": डिवाइस पर ऐप्लिकेशन को इंस्टॉल और अपडेट करने के लिए, स्प्लिट एपीके का इस्तेमाल करना है या नहीं. यह सुविधा सिर्फ़ Marshmallow या इसके बाद के वर्शन वाले डिवाइसों पर काम करती है
टैग: loading_and_analysis, affects_outputs

--adb_arg=<a string> कई बार इस्तेमाल किया गया हो: adb को पास करने के लिए अतिरिक्त आर्ग्युमेंट. आम तौर पर, इसका इस्तेमाल किसी डिवाइस पर ऐप्लिकेशन इंस्टॉल करने के लिए किया जाता है.
टैग: action_command_lines
--debug_app: ऐप्लिकेशन शुरू करने से पहले, डीबगर का इंतज़ार करना है या नहीं.
इसकी वैल्यू ये हो सकती हैं:
--start=DEBUG

टैग: execution
--device=<a string> default: "": adb डिवाइस का सीरियल नंबर. अगर इसे तय नहीं किया गया है, तो पहले डिवाइस का इस्तेमाल किया जाएगा.
टैग: action_command_lines
--start=<no, cold, warm or debug> default: "NO": ऐप्लिकेशन इंस्टॉल करने के बाद, उसे कैसे शुरू किया जाना चाहिए. इंक्रीमेंटल इंस्टॉल पर ऐप्लिकेशन की स्थिति को बनाए रखने और उसे पहले जैसा करने के लिए, इसे WARM पर सेट करें.
टैग: execution
--start_app: ऐप्लिकेशन इंस्टॉल करने के बाद उसे शुरू करना है या नहीं.
बढ़कर यह हो जाता है:
--start=COLD

टैग: execution

--[no]incompatible_use_plus_in_repo_names default: "true": No-op.
टैग: loading_and_analysis

--incremental_install_verbosity=<a string> default: "": इंक्रीमेंटल इंस्टॉल के लिए वर्बोसिटी. डीबग लॉगिंग के लिए, इसे 1 पर सेट करें.
टैग: bazel_monitoring

मॉड के विकल्प

--[no]experimental_inprocess_symlink_creation default: "true": सिंबल लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे कॉल करना है या हेल्पर प्रोसेस को सौंपना है.
टैग: loading_and_analysis, execution, experimental
--[no]experimental_remotable_source_manifests default: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_strict_fileset_output default: "false": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental
--[no]incompatible_modify_execution_info_additive default: "false": इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto": लोडिंग/विश्लेषण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto" वैल्यू, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करती है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो: कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि कई रेगुलर एक्सप्रेशन एक ही नेमोनिक पर लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z' से, सभी कार्रवाइयों के लिए एक्ज़ीक्यूशन की जानकारी में 'x' और 'z' जुड़ जाते हैं और 'y' हट जाता है. 'Genrule=+requires-x' से, Genrule की सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी में जोड़ा जाता है. '(?!Genrule).*=-requires-x' से, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी से हटा दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis

--[no]incompatible_bazel_test_exec_run_under default: "false": अगर यह विकल्प चालू है, तो "bazel test --run_under=//:runner" कमांड, एक्ज़ेक कॉन्फ़िगरेशन में "//:runner" बनाता है. यह सुविधा बंद होने पर, टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change

--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह जानकारी गलत है, तो इसे शामिल न करें. इसकी वैल्यू फ़ॉल्स होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs
--[no]incompatible_always_include_files_in_data default: "true": अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]incompatible_compact_repo_mapping_manifest default: "false": अगर यह सुविधा चालू है, तो <binary>.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन की रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन, रनफ़ाइल जनरेट करने वाले हर रेपो के लिए एक बार रेपो मैपिंग दिखाने के बजाय, सिर्फ़ एक बार दिखाती है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_filegroup_runfiles_for_data default: "false": अगर सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.
टैग: incompatible_change
--[no]legacy_external_runfiles default: "false": अगर यह सही है, तो .runfiles/repo के साथ-साथ .runfiles/wsname/external/repo में मौजूद बाहरी रिपॉज़िटरी के लिए, बिल्ड रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को <code>name</code> के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर के हिसाब से भी वैरिएबल को तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है. <br> ध्यान दें कि जब तक <code>--incompatible_repo_env_ignores_action_env</code> की वैल्यू सही नहीं होती, तब तक सभी <code>name=value</code> पेयर, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.
टैग: action_command_lines
--allowed_cpu_values=<comma-separated set of options> default: "": --cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs
--[no]collect_code_coverage default: "false": अगर बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild": इससे यह तय किया जाता है कि बाइनरी किस मोड में बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--cpu=<a string> default: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, सबसे बाद वाली वैल्यू का इस्तेमाल किया जाता है.
टैग: changes_inputs, affects_outputs
--[no]enable_runfiles default: "auto": runfiles symlink ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows पर बंद होता है और अन्य प्लैटफ़ॉर्म पर चालू होता है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो: अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. action_listener का इस्तेमाल करके, मौजूदा बिल्ड ऐक्शन में extra_action अटैच करें.
टैग: execution, experimental
--[no]experimental_collect_code_coverage_for_generated_files default: "false": अगर बताया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental
--experimental_output_paths=<off, content or strip> default: "off": आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution
--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो: हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir default: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true": कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental
--features=<a string> कई बार इस्तेमाल किया गया हो: टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं. --host_features भी देखें
टैग: changes_inputs, affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह उन एनवायरमेंट वैरिएबल का सेट तय करता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt> default: "opt": बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल के मोड के बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_cpu=<a string> default: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_features=<a string> कई बार इस्तेमाल किया गया हो: दी गई सुविधाएं, exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs
--[no]incompatible_auto_exec_groups default: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory default: "true": अगर सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में शामिल किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets default: "false": कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]": कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ ऐसे नियमों को लागू किया जाता है जो टेस्ट नहीं किए गए हैं. हालांकि, अगर --instrument_test_targets विकल्प चालू है, तो टेस्ट किए गए नियमों को भी लागू किया जा सकता है.
टैग: affects_outputs
--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]stamp default: "false": बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.
टैग: affects_outputs

--[no]check_licenses default: "false": देखें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]enforce_constraints default: "true": यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]incompatible_check_testonly_for_output_files default: "false": अगर यह चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मिलती-जुलती है.
टैग: build_file_semantics, incompatible_change
--[no]strict_filesets default: "false": अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

--[no]incompatible_config_setting_private_default_visibility default: "false": अगर incompatible_enforce_config_setting_visibility=false है, तो यह एक noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होगी. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enforce_config_setting_visibility default: "true": अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है', तो हर config_setting, हर टारगेट को दिखेगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

--[no]allow_analysis_failures default: "false": अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के इंस्टेंस को AnalysisFailureInfo का इंस्टेंस मिलेगा. इसमें गड़बड़ी की जानकारी होगी. इससे बिल्ड पूरा नहीं होगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन वाले नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
टैग: test_runner

--base_module=<"<root>" for the root module; <module>@<version> for a specific version of a module; <module> for all versions of a module; @<name> for a repo with the given apparent name; or @@<name> for a repo with the given canonical name> default: "<root>": उस मॉड्यूल के बारे में बताएं जिसके हिसाब से टारगेट रिपॉज़िटरी का आकलन किया जाएगा.
टैग: terminal_output
--charset=<utf8 or ascii> default: "utf8": ट्री के लिए इस्तेमाल किए जाने वाले वर्ण सेट को चुनता है. इसका असर सिर्फ़ टेक्स्ट आउटपुट पर पड़ता है. मान्य वैल्यू "utf8" या "ascii" हैं. डिफ़ॉल्ट रूप से यह "utf8" होता है
टैग: terminal_output
--[no]cycles default: "false": यह दिखाए गए ट्री में डिपेंडेंसी साइकल के बारे में बताता है. इन्हें आम तौर पर डिफ़ॉल्ट रूप से अनदेखा कर दिया जाता है.
टैग: terminal_output
--depth=<an integer> डिफ़ॉल्ट: "-1": डिपेंडेंसी ट्री की ज़्यादा से ज़्यादा डिसप्ले डेप्थ. डेप्थ 1 में, सीधे तौर पर जुड़ी डिपेंडेंसी दिखती हैं. उदाहरण के लिए, ट्री, पाथ, और all_paths के लिए, यह डिफ़ॉल्ट रूप से Integer.MAX_VALUE पर सेट होता है. वहीं, deps और explain के लिए, यह डिफ़ॉल्ट रूप से 1 पर सेट होता है. इसका मतलब है कि यह टारगेट लीफ़ और उनके पैरंट के अलावा, सिर्फ़ रूट के डायरेक्ट deps दिखाता है.
टैग: terminal_output
--extension_filter=<a comma-separated list of <extension>s> डिफ़ॉल्ट: ब्यौरा देखें: इन मॉड्यूल एक्सटेंशन के इस्तेमाल और उनसे जनरेट की गई रिपॉज़िटरी को सिर्फ़ तब दिखाएं, जब उनके फ़्लैग सेट हों. अगर यह विकल्प सेट किया जाता है, तो नतीजे के ग्राफ़ में सिर्फ़ वे पाथ शामिल होंगे जिनमें बताए गए एक्सटेंशन का इस्तेमाल करने वाले मॉड्यूल शामिल हैं. खाली सूची से फ़िल्टर बंद हो जाता है. इससे सभी संभावित एक्सटेंशन तय हो जाते हैं.
टैग: terminal_output
--extension_info=<hidden, usages, repos or all> default: "hidden": क्वेरी के नतीजे में, एक्सटेंशन के इस्तेमाल के बारे में कितनी जानकारी शामिल करनी है, यह तय करें. "इस्तेमाल किए गए एक्सटेंशन" में सिर्फ़ एक्सटेंशन के नाम दिखेंगे. "repos" में, use_repo की मदद से इंपोर्ट की गई रिपॉज़िटरी भी शामिल होंगी. "सभी" में, एक्सटेंशन से जनरेट की गई अन्य रिपॉज़िटरी भी दिखेंगी.
टैग: terminal_output
--extension_usages=<a comma-separated list of <module>s> default: "": उन मॉड्यूल के बारे में बताएं जिनके एक्सटेंशन के इस्तेमाल को show_extension क्वेरी में दिखाया जाएगा.
टैग: terminal_output
--from=<a comma-separated list of <module>s> default: "<root>": वे मॉड्यूल जिनसे डिपेंडेंसी ग्राफ़ क्वेरी दिखनी शुरू होगी. सटीक सिमैंटिक के लिए, हर क्वेरी के ब्यौरे की जांच करें. डिफ़ॉल्ट रूप से <root> पर सेट होता है.
टैग: terminal_output
--[no]include_builtin default: "false": डिपेंडेंसी ग्राफ़ में, पहले से मौजूद मॉड्यूल शामिल करें. इसे डिफ़ॉल्ट रूप से बंद रखा जाता है, क्योंकि इससे काफ़ी आवाज़ आती है.
टैग: terminal_output
--[no]include_unused default: "false": क्वेरी में, इस्तेमाल नहीं किए गए मॉड्यूल को भी ध्यान में रखा जाएगा और दिखाया जाएगा. ये मॉड्यूल, मॉड्यूल रिज़ॉल्यूशन ग्राफ़ में मौजूद नहीं होते हैं. ऐसा इसलिए होता है, क्योंकि ये मॉड्यूल, कम से कम ज़रूरी वर्शन चुनने या नियमों को बदलने की वजह से चुने नहीं जाते हैं. इसका असर, हर तरह की क्वेरी पर अलग-अलग पड़ सकता है. जैसे, all_paths कमांड में नए पाथ शामिल करना या explain कमांड में अतिरिक्त डिपेंडेंट शामिल करना.
टैग: terminal_output
--output=<text, json or graph> default: "text": क्वेरी के नतीजों को प्रिंट करने का फ़ॉर्मैट. क्वेरी के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: text, json, graph
टैग: terminal_output
--[no]verbose default: "false": क्वेरी में यह भी दिखेगा कि मॉड्यूल को उनके मौजूदा वर्शन में क्यों बदला गया है (अगर बदला गया है). 'एक्सप्लेन क्वेरी' के लिए, डिफ़ॉल्ट रूप से यह विकल्प सिर्फ़ सही पर सेट होता है.
टैग: terminal_output

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD मिटा दिया है, तो बिल्ड सिस्टम को शिकायत मिल सकती है. ऐसा तब होगा, जब उसे '//x:y/z' लेबल मिलेगा. हालांकि, यह लेबल अब भी package_path की किसी दूसरी एंट्री से मिल रहा होगा. --deleted_packages x/y विकल्प का इस्तेमाल करके, इस समस्या से बचा जा सकता है.
--[no]fetch default: "true": इस कमांड की मदद से, बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर कोई भी वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस से जुड़े होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट वैल्यू 'bazel info default-package-path' का आउटपुट होती है.
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

Print_action के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

--[no]incompatible_use_plus_in_repo_names default: "true": No-op.
टैग: loading_and_analysis

--print_action_mnemonics=<a string> कई बार इस्तेमाल किया गया हो: यह उन निमोनिक की सूची है जिनके हिसाब से print_action डेटा को फ़िल्टर करना है. इसे खाली छोड़ने पर, कोई फ़िल्टरिंग नहीं होती है.

क्वेरी के विकल्प

--[no]experimental_inprocess_symlink_creation default: "true": सिंबल लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे कॉल करना है या हेल्पर प्रोसेस को सौंपना है.
टैग: loading_and_analysis, execution, experimental
--[no]experimental_remotable_source_manifests default: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_strict_fileset_output default: "false": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental
--[no]incompatible_modify_execution_info_additive default: "false": इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change
--[no]keep_going [-k] डिफ़ॉल्ट: "false": गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उन पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto": लोडिंग/विश्लेषण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto" वैल्यू, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करती है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो: कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि कई रेगुलर एक्सप्रेशन एक ही नेमोनिक पर लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z' से, सभी कार्रवाइयों के लिए एक्ज़ीक्यूशन की जानकारी में 'x' और 'z' जुड़ जाते हैं और 'y' हट जाता है. 'Genrule=+requires-x' से, Genrule की सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी में जोड़ा जाता है. '(?!Genrule).*=-requires-x' से, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी से हटा दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis

--[no]incompatible_bazel_test_exec_run_under default: "false": अगर यह विकल्प चालू है, तो "bazel test --run_under=//:runner" कमांड, एक्ज़ेक कॉन्फ़िगरेशन में "//:runner" बनाता है. यह सुविधा बंद होने पर, टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change

--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह जानकारी गलत है, तो इसे शामिल न करें. इसकी वैल्यू फ़ॉल्स होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs
--[no]incompatible_always_include_files_in_data default: "true": अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]incompatible_compact_repo_mapping_manifest default: "false": अगर यह सुविधा चालू है, तो <binary>.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन की रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन, रनफ़ाइल जनरेट करने वाले हर रेपो के लिए एक बार रेपो मैपिंग दिखाने के बजाय, सिर्फ़ एक बार दिखाती है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_filegroup_runfiles_for_data default: "false": अगर सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.
टैग: incompatible_change
--[no]legacy_external_runfiles default: "false": अगर यह सही है, तो .runfiles/repo के साथ-साथ .runfiles/wsname/external/repo में मौजूद बाहरी रिपॉज़िटरी के लिए, बिल्ड रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को <code>name</code> के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर के हिसाब से भी वैरिएबल को तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है. <br> ध्यान दें कि जब तक <code>--incompatible_repo_env_ignores_action_env</code> की वैल्यू सही नहीं होती, तब तक सभी <code>name=value</code> पेयर, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.
टैग: action_command_lines
--allowed_cpu_values=<comma-separated set of options> default: "": --cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs
--[no]collect_code_coverage default: "false": अगर बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild": इससे यह तय किया जाता है कि बाइनरी किस मोड में बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--cpu=<a string> default: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, सबसे बाद वाली वैल्यू का इस्तेमाल किया जाता है.
टैग: changes_inputs, affects_outputs
--[no]enable_runfiles default: "auto": runfiles symlink ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows पर बंद होता है और अन्य प्लैटफ़ॉर्म पर चालू होता है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो: अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. action_listener का इस्तेमाल करके, मौजूदा बिल्ड ऐक्शन में extra_action अटैच करें.
टैग: execution, experimental
--[no]experimental_collect_code_coverage_for_generated_files default: "false": अगर बताया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental
--experimental_output_paths=<off, content or strip> default: "off": आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution
--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो: हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir default: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true": कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental
--features=<a string> कई बार इस्तेमाल किया गया हो: टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं. --host_features भी देखें
टैग: changes_inputs, affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह उन एनवायरमेंट वैरिएबल का सेट तय करता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt> default: "opt": बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल के मोड के बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_cpu=<a string> default: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_features=<a string> कई बार इस्तेमाल किया गया हो: दी गई सुविधाएं, exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs
--[no]incompatible_auto_exec_groups default: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory default: "true": अगर सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में शामिल किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets default: "false": कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]": कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ ऐसे नियमों को लागू किया जाता है जो टेस्ट नहीं किए गए हैं. हालांकि, अगर --instrument_test_targets विकल्प चालू है, तो टेस्ट किए गए नियमों को भी लागू किया जा सकता है.
टैग: affects_outputs
--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]stamp default: "false": बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.
टैग: affects_outputs

--[no]check_licenses default: "false": देखें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]enforce_constraints default: "true": यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]incompatible_check_testonly_for_output_files default: "false": अगर यह चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मिलती-जुलती है.
टैग: build_file_semantics, incompatible_change
--[no]strict_filesets default: "false": अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

--[no]incompatible_config_setting_private_default_visibility default: "false": अगर incompatible_enforce_config_setting_visibility=false है, तो यह एक noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होगी. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enforce_config_setting_visibility default: "true": अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है', तो हर config_setting, हर टारगेट को दिखेगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

--[no]allow_analysis_failures default: "false": अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के इंस्टेंस को AnalysisFailureInfo का इंस्टेंस मिलेगा. इसमें गड़बड़ी की जानकारी होगी. इससे बिल्ड पूरा नहीं होगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन वाले नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
टैग: test_runner

--aspect_deps=<off, conservative or precise> default: "conservative": जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तब पहलू की डिपेंडेंसी को कैसे हल करें. 'off' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'conservative' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी का नियम क्लास दिया गया हो या नहीं. 'precise' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हों. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह फ़ैसला विश्लेषण के चरण में लिया जाता है. यह चरण 'bazel query' के दौरान नहीं चलता.
टैग: build_file_semantics
--[no]consistent_labels default: "false": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे कि Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के बजाय रिपॉज़िटरी के नाम (मुख्य रिपॉज़िटरी के हिसाब से) दिखा सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects default: "false": aquery, cquery: whether to include aspect-generated actions in the output. query: no-op (aspects are always followed).
टैग: terminal_output
--[no]experimental_graphless_query default: "auto": अगर यह वैल्यू सही है, तो Query implementation का इस्तेमाल किया जाता है. इससे ग्राफ़ की कॉपी नहीं बनती. नया वर्शन सिर्फ़ --order_output=no के साथ काम करता है. साथ ही, यह सिर्फ़ आउटपुट फ़ॉर्मैट करने वाले कुछ टूल के साथ काम करता है.
टैग: build_file_semantics, eagerness_to_exit
--graph:conditional_edges_limit=<an integer> default: "4": दिखाने के लिए, शर्त वाले लेबल की ज़्यादा से ज़्यादा संख्या. -1 का मतलब है कि कोई काट-छांट नहीं की गई है और 0 का मतलब है कि कोई एनोटेशन नहीं है. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output
--[no]graph:factored default: "true": अगर यह विकल्प चुना जाता है, तो ग्राफ़ को 'फ़ैक्टर्ड' किया जाएगा. इसका मतलब है कि टोपोलॉजिकल तौर पर एक जैसे नोड को एक साथ मर्ज कर दिया जाएगा और उनके लेबल को एक साथ जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> default: "512": आउटपुट में, ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. बड़े लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि लेबल को छोटा नहीं किया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps default: "true": अगर यह विकल्प चालू है, तो क्वेरी जिस डिपेंडेंसी ग्राफ़ पर काम करती है उसमें इंप्लिसिट डिपेंडेंसी शामिल की जाएंगी. इंप्लिसिट डिपेंडेंसी ऐसी डिपेंडेंसी होती है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया जाता, लेकिन Bazel इसे जोड़ देता है. cquery के लिए, यह विकल्प हल की गई टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_aspects default: "true": aquery, cquery: whether to include aspect-generated actions in the output. query: no-op (aspects are always followed).
टैग: terminal_output
--[no]incompatible_lexicographical_output default: "true": यह विकल्प सेट होने पर, sorts --order_output=auto आउटपुट को लेक्सिकोग्राफ़िकल क्रम में लगाता है.
टैग: terminal_output, incompatible_change
--[no]incompatible_package_group_includes_double_slash default: "true": अगर यह विकल्प चालू है, तो package_group एट्रिब्यूट के `packages` एट्रिब्यूट की वैल्यू देते समय, शुरुआती `//` को शामिल किया जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope default: "false": अगर इसे सेट किया गया है और --universe_scope को सेट नहीं किया गया है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि क्वेरी एक्सप्रेशन के लिए अनुमानित --universe_scope वैल्यू, आपकी ज़रूरत के हिसाब से नहीं हो सकती.ऐसा तब होता है, जब क्वेरी एक्सप्रेशन में यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे, `allrdeps`) का इस्तेमाल किया जाता है.इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करें, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query पर जाएं. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है. इसका मतलब है कि यह `cquery` पर लागू नहीं होता.
टैग: loading_and_analysis
--[no]line_terminator_null default: "false": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया गया है.
टैग: terminal_output
--[no]nodep_deps default: "true": अगर यह विकल्प चालू है, तो "nodep" एट्रिब्यूट से मिले डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल किए जाएंगे. क्वेरी इसी ग्राफ़ पर काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` कमांड चलाएं और उसके आउटपुट को पार्स करें.
टैग: build_file_semantics
--noorder_results: नतीजों को क्रम से (डिफ़ॉल्ट) या बिना क्रम के दिखाएं. बिना क्रम वाली आउटपुट फ़ाइल तेज़ी से जनरेट होती है. हालांकि, यह सुविधा सिर्फ़ तब काम करती है, जब --output को minrank, maxrank या graph के तौर पर सेट न किया गया हो.
इनके लिए उपलब्ध है:
--order_output=no

टैग: terminal_output
--null: क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया गया है.
इनके लिए उपलब्ध है:
--line_terminator_null=true

टैग: terminal_output
--order_output=<no, deps, auto or full> default: "auto": नतीजों को क्रम से न लगाएं (no), निर्भरता के हिसाब से क्रम से लगाएं (deps) या पूरी तरह से क्रम से लगाएं (full). डिफ़ॉल्ट रूप से, यह 'auto' पर सेट होता है. इसका मतलब है कि नतीजे, आउटपुट फ़ॉर्मेटर के हिसाब से क्रम में लगाए जाते हैं. जैसे, proto, minrank, maxrank, और graph के लिए, निर्भरता के हिसाब से क्रम में लगाए जाते हैं. वहीं, अन्य सभी के लिए, पूरी तरह से क्रम में लगाए जाते हैं. जब आउटपुट पूरी तरह से क्रम में होता है, तो नोड को पूरी तरह से तय किए गए क्रम में प्रिंट किया जाता है. सबसे पहले, सभी नोड को वर्णमाला के क्रम में लगाया जाता है. इसके बाद, सूची में मौजूद हर नोड का इस्तेमाल, पोस्ट-ऑर्डर डेप्थ-फ़र्स्ट सर्च की शुरुआत के तौर पर किया जाता है. इसमें, जिन नोड पर नहीं जाया गया है उनके आउटगोइंग एज को, सक्सेसर नोड के वर्णमाला क्रम में ट्रैवर्स किया जाता है. आखिर में, नोड को उस क्रम के उलट क्रम में प्रिंट किया जाता है जिस क्रम में उन्हें देखा गया था.
टैग: terminal_output
--order_results: नतीजों को क्रम से (डिफ़ॉल्ट) या बिना क्रम के दिखाएं. बिना क्रम वाली आउटपुट फ़ाइल तेज़ी से जनरेट होती है. हालांकि, यह सुविधा सिर्फ़ तब काम करती है, जब --output को minrank, maxrank या graph के तौर पर सेट न किया गया हो.
इनके लिए उपलब्ध है:
--order_output=auto

टैग: terminal_output
--output=<a string> default: "label": क्वेरी के नतीजों को प्रिंट करने का फ़ॉर्मैट. क्वेरी के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: build, graph, streamed_jsonproto, label, label_kind, location, maxrank, minrank, package, proto, streamed_proto, xml.
टैग: terminal_output
--output_file=<a string> default: "": इस विकल्प को चुनने पर, क्वेरी के नतीजे सीधे इस फ़ाइल में लिखे जाएंगे. साथ ही, Bazel के स्टैंडर्ड आउटपुट स्ट्रीम (stdout) में कुछ भी प्रिंट नहीं किया जाएगा. आम तौर पर, बेंचमार्क में यह <code>bazel query > file</code> से ज़्यादा तेज़ होता है.
टैग: terminal_output
--[no]proto:default_values default: "true": अगर यह वैल्यू सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह वैल्यू गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack default: "false": definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, नियम के हर इंस्टेंस के लिए, Starlark कॉल स्टैक को रिकॉर्ड करता है. यह रिकॉर्डिंग, नियम की क्लास तय किए जाने के समय की जाती है.
टैग: terminal_output
--[no]proto:flatten_selects default: "true": अगर यह विकल्प चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किए गए डेटा का मतलब ऐसी सूची से है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects default: "false": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, उस सोर्स पहलू का नाम डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स पहलू से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output
--[no]proto:include_synthetic_attribute_hash default: "false": $internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack default: "false": हर नियम के इंस्टैंटिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए, स्टैक में
टैग मौजूद होने चाहिए: terminal_output
--[no]proto:locations default: "true": क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> default: "all": आउटपुट में शामिल करने के लिए, कॉमा लगाकर अलग किए गए एट्रिब्यूट की सूची. डिफ़ॉल्ट रूप से, सभी एट्रिब्यूट के लिए लागू होता है. किसी भी एट्रिब्यूट को आउटपुट न करने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प, --output=proto पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_classes default: "false": हर नियम के rule_class_key फ़ील्ड में वैल्यू डालें. साथ ही, किसी दिए गए rule_class_key वाले पहले नियम के लिए, उसके rule_class_info प्रोटो फ़ील्ड में भी वैल्यू डालें. rule_class_key फ़ील्ड, नियम क्लास की खास तौर पर पहचान करता है. साथ ही, rule_class_info फ़ील्ड, Stardoc फ़ॉर्मैट में नियम क्लास की एपीआई डेफ़िनिशन है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs default: "true": rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output
--query_file=<a string> default: "": अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.
टैग: changes_inputs
--[no]relative_locations default: "false": अगर यह विकल्प चुना जाता है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह की जानकारी रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह अलग-अलग मशीनों पर एक जैसा नहीं होता. इस विकल्प को true पर सेट करके, सभी मशीनों पर एक जैसा नतीजा पाया जा सकता है.
टैग: terminal_output
--[no]strict_test_suite default: "false": अगर यह सही है, तो test_suite में गैर-टेस्ट टारगेट मिलने पर tests() एक्सप्रेशन गड़बड़ी दिखाता है.
टैग: build_file_semantics, eagerness_to_exit
--[no]tool_deps default: "true": क्वेरी: अगर यह सुविधा बंद है, तो 'एक्ज़ीक्यूशन कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'exec configuration' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से लेकर प्रोटोकॉल कंपाइलर तक, आम तौर पर उसी 'target' प्रोग्राम के किसी हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल की ओर इशारा करता है. Cquery: अगर यह सुविधा बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर दिया जाता है जो टॉप-लेवल के उस टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं जिसने इस कॉन्फ़िगर किए गए टारगेट का पता लगाया था. इसका मतलब है कि अगर टॉप-लेवल का टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो टारगेट कॉन्फ़िगरेशन में मौजूद सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प से, हल की गई टूलचेन को नहीं हटाया जाएगा.
टैग: build_file_semantics
--universe_scope=<comma-separated list of options> default: "": कॉमा लगाकर अलग किए गए टारगेट पैटर्न का सेट (जोड़ने और घटाने वाले). क्वेरी को, ट्रांज़िटिव क्लोज़र के ज़रिए तय किए गए यूनिवर्स में किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट होते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर इस विकल्प के बारे में नहीं बताया जाता है, तो यह माना जाता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के टारगेट हैं. ध्यान दें: cquery के लिए, इस विकल्प को तय न करने पर, बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ नहीं बनाए जा सकते.
टैग: loading_and_analysis
--[no]xml:default_values default: "false": अगर यह विकल्प सही है, तो उन नियमों के एट्रिब्यूट प्रिंट किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह विकल्प गलत है, तो उन नियमों के एट्रिब्यूट प्रिंट नहीं किए जाते हैं.
टैग: terminal_output
--[no]xml:line_numbers default: "true": अगर सही है, तो एक्सएमएल आउटपुट में लाइन नंबर शामिल होते हैं. इस विकल्प को बंद करने से, अंतर को आसानी से पढ़ा जा सकता है. यह विकल्प सिर्फ़ --output=xml पर लागू होता है.
टैग: terminal_output

--experimental_repository_resolved_file=<a string> default: "": अगर यह खाली नहीं है, तो Starlark वैल्यू लिखें. इसमें Starlark रिपॉज़िटरी के उन सभी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD मिटा दिया है, तो बिल्ड सिस्टम को शिकायत मिल सकती है. ऐसा तब होगा, जब उसे '//x:y/z' लेबल मिलेगा. हालांकि, यह लेबल अब भी package_path की किसी दूसरी एंट्री से मिल रहा होगा. --deleted_packages x/y विकल्प का इस्तेमाल करके, इस समस्या से बचा जा सकता है.
--[no]fetch default: "true": इस कमांड की मदद से, बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर कोई भी वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस से जुड़े होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट वैल्यू 'bazel info default-package-path' का आउटपुट होती है.
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

रन करने के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

--[no]portable_paths default: "false": अगर यह सही है, तो ExecRequest में बदलने के लिए पाथ शामिल करता है, ताकि नतीजे के तौर पर मिले पाथ को पोर्टेबल बनाया जा सके.
टैग: affects_outputs
--[no]run default: "true": अगर यह वैल्यू 'गलत है' पर सेट है, तो बनाए गए टारगेट के लिए बनाई गई कमांड लाइन को चलाने की प्रोसेस छोड़ दें. ध्यान दें कि --script_path के साथ बनाए गए सभी बिल्ड के लिए, इस फ़्लैग को अनदेखा कर दिया जाता है.
टैग: affects_outputs
--run_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: affects_outputs

--script_path=<a path> डिफ़ॉल्ट: ब्यौरा देखें: अगर सेट है, तो दी गई फ़ाइल में एक शेल स्क्रिप्ट लिखें, जो टारगेट को शुरू करती है. अगर इस विकल्प को सेट किया जाता है, तो टारगेट को Bazel से नहीं चलाया जाता. '//foo' टारगेट को शुरू करने के लिए, 'bazel run --script_path=foo //foo && ./foo' का इस्तेमाल करें. यह 'bazel run //foo' से इस मामले में अलग है कि Bazel लॉक को रिलीज़ कर दिया जाता है और एक्ज़ीक्यूटेबल को टर्मिनल के stdin से कनेक्ट कर दिया जाता है.
टैग: affects_outputs, execution

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

बंद करने के विकल्प

--iff_heap_size_greater_than=<an integer> default: "0": अगर यह वैल्यू शून्य नहीं है, तो शटडाउन की प्रोसेस सिर्फ़ तब शुरू होगी, जब JVM की ओर से इस्तेमाल की गई कुल मेमोरी (MB में) इस वैल्यू से ज़्यादा होगी.
टैग: loses_incremental_state, eagerness_to_exit

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

सिंक करने के विकल्प

--[no]configure डिफ़ॉल्ट: "False": सिर्फ़ उन रिपॉज़िटरी को सिंक करें जिन्हें सिस्टम कॉन्फ़िगरेशन के मकसद से 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है.
टैग: changes_inputs
--[no]experimental_inprocess_symlink_creation default: "true": सिंबल लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे कॉल करना है या हेल्पर प्रोसेस को सौंपना है.
टैग: loading_and_analysis, execution, experimental
--[no]experimental_remotable_source_manifests default: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_strict_fileset_output default: "false": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental
--[no]incompatible_modify_execution_info_additive default: "false": इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change
--[no]keep_going [-k] डिफ़ॉल्ट: "false": गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उन पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto": लोडिंग/विश्लेषण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto" वैल्यू, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करती है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो: कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि कई रेगुलर एक्सप्रेशन एक ही नेमोनिक पर लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z' से, सभी कार्रवाइयों के लिए एक्ज़ीक्यूशन की जानकारी में 'x' और 'z' जुड़ जाते हैं और 'y' हट जाता है. 'Genrule=+requires-x' से, Genrule की सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी में जोड़ा जाता है. '(?!Genrule).*=-requires-x' से, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी से हटा दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis
--only=<a string> कई बार इस्तेमाल किया गया हो: अगर यह विकल्प दिया गया है, तो सिर्फ़ उन रिपॉज़िटरी को सिंक करें जिनके लिए यह विकल्प दिया गया है. अब भी सभी (या --configure विकल्प दिए जाने पर, कॉन्फ़िगर किए गए सभी) को पुराना माना जाता है.
टैग: changes_inputs

--[no]incompatible_bazel_test_exec_run_under default: "false": अगर यह विकल्प चालू है, तो "bazel test --run_under=//:runner" कमांड, एक्ज़ेक कॉन्फ़िगरेशन में "//:runner" बनाता है. यह सुविधा बंद होने पर, टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change

--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह जानकारी गलत है, तो इसे शामिल न करें. इसकी वैल्यू फ़ॉल्स होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs
--[no]incompatible_always_include_files_in_data default: "true": अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]incompatible_compact_repo_mapping_manifest default: "false": अगर यह सुविधा चालू है, तो <binary>.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन की रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन, रनफ़ाइल जनरेट करने वाले हर रेपो के लिए एक बार रेपो मैपिंग दिखाने के बजाय, सिर्फ़ एक बार दिखाती है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_filegroup_runfiles_for_data default: "false": अगर सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.
टैग: incompatible_change
--[no]legacy_external_runfiles default: "false": अगर यह सही है, तो .runfiles/repo के साथ-साथ .runfiles/wsname/external/repo में मौजूद बाहरी रिपॉज़िटरी के लिए, बिल्ड रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को <code>name</code> के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर के हिसाब से भी वैरिएबल को तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है. <br> ध्यान दें कि जब तक <code>--incompatible_repo_env_ignores_action_env</code> की वैल्यू सही नहीं होती, तब तक सभी <code>name=value</code> पेयर, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.
टैग: action_command_lines
--allowed_cpu_values=<comma-separated set of options> default: "": --cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs
--[no]collect_code_coverage default: "false": अगर बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild": इससे यह तय किया जाता है कि बाइनरी किस मोड में बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--cpu=<a string> default: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, सबसे बाद वाली वैल्यू का इस्तेमाल किया जाता है.
टैग: changes_inputs, affects_outputs
--[no]enable_runfiles default: "auto": runfiles symlink ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows पर बंद होता है और अन्य प्लैटफ़ॉर्म पर चालू होता है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो: अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. action_listener का इस्तेमाल करके, मौजूदा बिल्ड ऐक्शन में extra_action अटैच करें.
टैग: execution, experimental
--[no]experimental_collect_code_coverage_for_generated_files default: "false": अगर बताया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental
--experimental_output_paths=<off, content or strip> default: "off": आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution
--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो: हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir default: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true": कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental
--features=<a string> कई बार इस्तेमाल किया गया हो: टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं. --host_features भी देखें
टैग: changes_inputs, affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह उन एनवायरमेंट वैरिएबल का सेट तय करता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt> default: "opt": बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल के मोड के बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_cpu=<a string> default: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_features=<a string> कई बार इस्तेमाल किया गया हो: दी गई सुविधाएं, exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs
--[no]incompatible_auto_exec_groups default: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory default: "true": अगर सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में शामिल किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets default: "false": कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]": कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ ऐसे नियमों को लागू किया जाता है जो टेस्ट नहीं किए गए हैं. हालांकि, अगर --instrument_test_targets विकल्प चालू है, तो टेस्ट किए गए नियमों को भी लागू किया जा सकता है.
टैग: affects_outputs
--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]stamp default: "false": तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह के साथ बाइनरी को स्टैंप करें.
टैग: affects_outputs

--[no]check_licenses default: "false": देखें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]enforce_constraints default: "true": यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]incompatible_check_testonly_for_output_files default: "false": अगर यह चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मिलती-जुलती है.
टैग: build_file_semantics, incompatible_change
--[no]strict_filesets default: "false": अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

--[no]incompatible_config_setting_private_default_visibility default: "false": अगर incompatible_enforce_config_setting_visibility=false है, तो यह एक noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होगी. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enforce_config_setting_visibility default: "true": अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है', तो हर config_setting, हर टारगेट को दिखेगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

--[no]allow_analysis_failures default: "false": अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के इंस्टेंस को AnalysisFailureInfo का इंस्टेंस मिलेगा. इसमें गड़बड़ी की जानकारी होगी. इससे बिल्ड पूरा नहीं होगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन वाले नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
टैग: test_runner

--experimental_repository_resolved_file=<a string> default: "": अगर यह खाली नहीं है, तो Starlark वैल्यू लिखें. इसमें Starlark रिपॉज़िटरी के उन सभी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD मिटा दिया है, तो बिल्ड सिस्टम को शिकायत मिल सकती है. ऐसा तब होगा, जब उसे '//x:y/z' लेबल मिलेगा. हालांकि, यह लेबल अब भी package_path की किसी दूसरी एंट्री से मिल रहा होगा. --deleted_packages x/y विकल्प का इस्तेमाल करके, इस समस्या से बचा जा सकता है.
--[no]fetch default: "true": इस कमांड की मदद से, बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर कोई भी वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस से जुड़े होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट वैल्यू 'bazel info default-package-path' का आउटपुट होती है.
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

टेस्ट के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

--[no]incompatible_use_plus_in_repo_names default: "true": No-op.
टैग: loading_and_analysis

--[no]print_relative_test_log_paths default: "false": अगर यह सही है, तो टेस्ट लॉग का पाथ प्रिंट करते समय, 'testlogs' सुविधा वाले सिमलंक का इस्तेमाल करने वाला रिलेटिव पाथ इस्तेमाल करें. ध्यान दें - अलग कॉन्फ़िगरेशन के साथ 'बिल्ड'/'टेस्ट'/वगैरह को बाद में लागू करने से, इस सिंबल लिंक का टारगेट बदल सकता है. इससे पहले प्रिंट किया गया पाथ अब काम नहीं करेगा.
टैग: affects_outputs
--[no]test_verbose_timeout_warnings default: "false": अगर यह वैल्यू सही पर सेट है, तो टेस्ट के असल में पूरा होने का समय, टेस्ट के लिए तय किए गए टाइम आउट से मेल न खाने पर, अतिरिक्त चेतावनियां प्रिंट करें. टाइम आउट का मतलब, टेस्ट के पूरा होने के लिए तय किया गया समय होता है. यह समय, टेस्ट के लिए तय किए गए समय के बराबर या उससे ज़्यादा हो सकता है.
टैग: affects_outputs
--[no]verbose_test_summary default: "true": अगर यह विकल्प चुना जाता है, तो टेस्ट की खास जानकारी में अतिरिक्त जानकारी (समय, टेस्ट के पूरे न हो पाने की संख्या वगैरह) प्रिंट करें.
टैग: affects_outputs

वेंडर के विकल्प

test से सभी विकल्प इनहेरिट करता है.

--[no]keep_going [-k] डिफ़ॉल्ट: "false": गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उन पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto": लोडिंग/विश्लेषण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto" वैल्यू, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करती है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--[no]incompatible_config_setting_private_default_visibility default: "false": अगर incompatible_enforce_config_setting_visibility=false है, तो यह एक noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होगी. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enforce_config_setting_visibility default: "true": अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है', तो हर config_setting, हर टारगेट को दिखेगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names default: "true": No-op.
टैग: loading_and_analysis

--repo=<a string> कई बार इस्तेमाल किया गया हो: सिर्फ़ उन वेंडर के लिए रिपॉज़िटरी तय की जाती है जिनके लिए रिपॉज़िटरी तय की गई है. यह `@apparent_repo_name` या `@@canonical_repo_name` हो सकती है. इस विकल्प को कई बार सेट किया जा सकता है
टैग: changes_inputs

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD मिटा दिया है, तो बिल्ड सिस्टम को शिकायत मिल सकती है. ऐसा तब होगा, जब उसे '//x:y/z' लेबल मिलेगा. हालांकि, यह लेबल अब भी package_path की किसी दूसरी एंट्री से मिल रहा होगा. --deleted_packages x/y विकल्प का इस्तेमाल करके, इस समस्या से बचा जा सकता है.
--[no]fetch default: "true": इस कमांड की मदद से, बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर कोई भी वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस से जुड़े होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट वैल्यू 'bazel info default-package-path' का आउटपुट होती है.
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

--[no]experimental_inprocess_symlink_creation default: "true": सिंबल लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या हेल्पर प्रोसेस को डेलिगेट करना है.
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor default: "false": वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution, experimental
--[no]experimental_remotable_source_manifests default: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing default: "false": अगर यह विकल्प सही है, तो Bazel, टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.
टैग: execution, experimental
--[no]experimental_strict_fileset_output default: "false": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental
--[no]incompatible_modify_execution_info_additive default: "false": इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो: कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी देने की सुविधा होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि कई रेगुलर एक्सप्रेशन एक ही नेमोनिक पर लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z' से, सभी कार्रवाइयों के लिए एक्ज़ीक्यूशन की जानकारी में 'x' और 'z' जुड़ जाते हैं और 'y' हट जाता है. 'Genrule=+requires-x' से, Genrule की सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी में जोड़ा जाता है. '(?!Genrule).*=-requires-x' से, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, 'requires-x' को एक्ज़ीक्यूशन की जानकारी से हटा दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis
--persistent_android_dex_desugar: वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू रखें.
इनके तौर पर दिखता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution
--persistent_android_resource_processor: वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को हमेशा चालू रखें.
बढ़कर यह हो जाता है:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_dex_desugar: वर्कर्स का इस्तेमाल करके, लगातार मल्टीप्लेक्स किए गए Android dex और desugar कार्रवाइयों को चालू करें.
इनके तौर पर दिखता है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_resource_processor: वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.
इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_tools: Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (dexing, desugaring, resource processing) चालू करें.
इनके तौर पर दिखता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--[no]use_target_platform_for_tests default: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. इसके बजाय, टेस्ट एक्ज़ेक ग्रुप का इस्तेमाल नहीं करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android": android_binary नियमों के लिए, मेनिफ़ेस्ट मर्जर को चुनता है. यह फ़्लैग, लेगसी मर्जर से Android मेनिफ़ेस्ट मर्जर पर स्विच करने में मदद करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_platforms=<a build target label> default: "": यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain": Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> default: "": यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger": यह उस बाइनरी का पाथ है जिसका इस्तेमाल रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:lcov_merger' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator": कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी का पाथ. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी हो. डिफ़ॉल्ट वैल्यू '//tools/test:coverage_report_generator' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support": सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:coverage_support' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह कस्टम malloc को लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के पहले, - (नेगेटिव एक्सप्रेशन) का इस्तेमाल किया जा सकता है. इसे कॉमा लगाकर अलग किए गए, कंस्ट्रेंट वैल्यू टारगेट की सूची को असाइन (=) किया जाता है. अगर कोई टारगेट, किसी भी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसके टूलचेन रिज़ॉल्यूशन को इस तरह से पूरा किया जाएगा जैसे कि उसने कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर एलान किया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64 'test' नाम वाले लक्ष्यों को छोड़कर, //demo के अंतर्गत किसी भी लक्ष्य में 'x86_64' जोड़ देगा.
टैग: loading_and_analysis
--[no]experimental_include_xcode_execution_requirements default: "false": अगर सेट है, तो हर Xcode कार्रवाई में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution, experimental
--[no]experimental_prefer_mutual_xcode default: "true": अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state, experimental
--extra_execution_platforms=<comma-separated list of options> default: "": कार्रवाइयां करने के लिए उपलब्ध प्लैटफ़ॉर्म. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले माना जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, पहले की फ़्लैग सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन के ज़रिए WORKSPACE फ़ाइल में एलान किए गए टूलचेन से पहले माना जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह फ़्लैग कोई कार्रवाई नहीं करता. इसे आने वाले समय में हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform": यह प्लैटफ़ॉर्म के नियम का लेबल है. इससे होस्ट सिस्टम के बारे में पता चलता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_bazel_test_exec_run_under default: "false": अगर यह विकल्प चालू है, तो "bazel test --run_under=//:runner" कमांड, एक्ज़ेक कॉन्फ़िगरेशन में "//:runner" बनाता है. यह सुविधा बंद होने पर, टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true": अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution default: "false": ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_remove_legacy_whole_archive default: "true": अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_strip_executable_safely default: "false": अगर यह सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects default: "true": अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी ईएलएफ़ टूलचेन इस सेटिंग के साथ काम करते हैं.
टैग: loading_and_analysis, affects_outputs, affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: इससे macOS ऐप्लिकेशन बनाने के लिए, macOS SDK के वर्शन के बारे में पता चलता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से macOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--minimum_os_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह ओएस का वह कम से कम वर्शन है जिसे कंपाइल करने के लिए टारगेट किया जाता है.
टैग: loading_and_analysis, affects_outputs
--platform_mappings=<a main workspace-relative path> default: "": यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य वर्कस्पेस रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, वर्कस्पेस के रूट फ़ोल्डर में मौजूद होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> default: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह py_runtime का लेबल है. यह टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर को दिखाता है. अब काम नहीं करता; --incompatible_use_python_toolchains फ़्लैग की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से tvOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह विकल्प चुना जाता है, तो यह बिल्ड से जुड़ी कार्रवाइयों के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी जाती है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes": यह xcode_config नियम का लेबल है. इसका इस्तेमाल, बिल्ड कॉन्फ़िगरेशन में Xcode का वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym default: "false": डीबग सिंबल (.dSYM) वाली फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह जानकारी गलत है, तो इसे शामिल न करें. इसकी वैल्यू फ़ॉल्स होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs
--[no]build_test_dwp default: "false": अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h": cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc": cc_proto_library, सोर्स फ़ाइलों के ऐसे सफ़िक्स सेट करता है जिन्हें वह बनाता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info default: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state default: "false": कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> default: "no": इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल कौनसे कंपाइलेशन मोड करते हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data default: "true": अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]incompatible_compact_repo_mapping_manifest default: "false": अगर यह सुविधा चालू है, तो <binary>.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन की रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन, रनफ़ाइल जनरेट करने वाले हर रेपो के लिए एक बार रेपो मैपिंग दिखाने के बजाय, सिर्फ़ एक बार दिखाती है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_filegroup_runfiles_for_data default: "false": अगर सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.
टैग: incompatible_change
--[no]legacy_external_runfiles default: "false": अगर यह सही है, तो .runfiles/repo के साथ-साथ .runfiles/wsname/external/repo में मौजूद बाहरी रिपॉज़िटरी के लिए, बिल्ड रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap default: "false": इससे यह तय किया जाता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps default: "false": अगर यह सेट है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को <code>name</code> के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर के हिसाब से भी वैरिएबल को तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है. <br> ध्यान दें कि जब तक <code>--incompatible_repo_env_ignores_action_env</code> की वैल्यू सही नहीं होती, तब तक सभी <code>name=value</code> पेयर, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.
टैग: action_command_lines
--allowed_cpu_values=<comma-separated set of options> default: "": --cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs
--[no]android_databinding_use_androidx default: "true": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args default: "true": 3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> default: "off": इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तब Android के नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. ALPHABETICAL का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से पाथ के हिसाब से क्रम से लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस तरह से क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip default: "auto": Build python executable zip; on on Windows, off on other platforms
Tags: affects_outputs
--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ऐसी सूची जिसमें Apple Catalyst बाइनरी बनाने के लिए, आर्किटेक्चर को कॉमा लगाकर अलग किया गया हो.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage default: "false": अगर बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild": इससे यह तय किया जाता है कि बाइनरी किस मोड में बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> कई बार इस्तेमाल किया गया हो: gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> default: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs
--cxxopt=<a string> कई बार इस्तेमाल किया गया हो: C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, सबसे बाद वाली वैल्यू का इस्तेमाल किया जाता है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> default: "default": इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'fully' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक की जाएंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_propeller_optimize_absolute_paths default: "true": अगर यह सेट है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_remaining_fdo_absolute_paths default: "true": अगर यह नीति सेट की जाती है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs
--[no]enable_runfiles default: "auto": runfiles symlink ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows पर बंद होता है और अन्य प्लैटफ़ॉर्म पर चालू होता है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो: अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. action_listener का इस्तेमाल करके, मौजूदा बिल्ड ऐक्शन में extra_action अटैच करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources default: "false": एपीके में Java संसाधनों को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 default: "true": android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking default: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_rewrite_dexes_with_rex default: "false": use rex tool to rewrite dex files
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files default: "false": अगर बताया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental
--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1": इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines
--[no]experimental_omitfp default: "false": अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> default: "off": आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution
--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो: हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir default: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_py_binaries_include_label default: "false": py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap default: "false": अगर collect_code_coverage चालू है, तो Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true": कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental
--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है. जैसे, `//foo/bar:file.afdo`. इसके लिए, आपको संबंधित पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है. साथ ही, यह `fdo_profile` टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, `fdo_profile` नियम की जगह लागू होगा.
टैग: affects_outputs
--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कैश मेमोरी प्रीफ़ेच करने के लिए, हिंट का इस्तेमाल करें.
टैग: affects_outputs
--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.
टैग: affects_outputs
--features=<a string> कई बार इस्तेमाल किया गया हो: टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं. --host_features भी देखें
टैग: changes_inputs, affects_outputs
--[no]force_pic default: "false": अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय पीआईसी प्री-बिल्ट लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.
टैग: loading_and_analysis, affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह उन एनवायरमेंट वैरिएबल का सेट तय करता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt> default: "opt": बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल के मोड के बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो: C कंपाइलर को पास करने का अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है. हालांकि, C++ सोर्स फ़ाइलों को कंपाइल करते समय इसका इस्तेमाल नहीं किया जाता.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> default: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास किए जाने वाले अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_features=<a string> कई बार इस्तेमाल किया गया हो: दी गई सुविधाएं, exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -<feature> को तय करने पर, सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर हमेशा सकारात्मक फ़ीचर की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs
--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: यह exec कॉन्फ़िगरेशन के लिए Python के वर्शन को बदलता है. इसे "PY2" या "PY3" पर सेट किया जा सकता है.
टैग: loading_and_analysis, affects_outputs
--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: होस्ट टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है. हालांकि, bar.cc में यह विकल्प नहीं जोड़ा जाता.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups default: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory default: "true": अगर सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में शामिल किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets default: "false": कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]": कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ ऐसे नियमों को लागू किया जाता है जो टेस्ट नहीं किए गए हैं. हालांकि, अगर --instrument_test_targets विकल्प चालू है, तो टेस्ट किए गए नियमों को भी लागू किया जा सकता है.
टैग: affects_outputs
--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'ios_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें बताए गए सभी आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive default: "true": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated
--linkopt=<a string> कई बार इस्तेमाल किया गया हो: लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो: LTO के बैकएंड चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो: एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs
--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple macOS के बाइनरी फ़ाइलें बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.
टैग: loses_incremental_state, loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. यह जानकारी उपलब्ध न होने पर, 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs
--[no]objc_debug_with_GLIBCXX default: "false": अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping default: "false": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines
--objccopt=<a string> कई बार इस्तेमाल किया गया हो: Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो: कुछ बैकएंड ऑब्जेक्ट कंपाइल करते समय, LTO बैकएंड (under --features=thin_lto) को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों की एलटीओ बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs
--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis
--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें. Propeller प्रोफ़ाइल में कम से कम दो फ़ाइलों में से एक फ़ाइल होनी चाहिए. ये फ़ाइलें cc प्रोफ़ाइल और ld प्रोफ़ाइल हैं. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस देता है. उदाहरण के लिए, a/b/BUILD में मौजूद BUILD फ़ाइल, लेबल को इस तरह से तय करती है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नेम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]share_native_deps default: "true": अगर यह वैल्यू सही है, तो एक जैसी फ़ंक्शनैलिटी वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs
--[no]stamp default: "false": तारीख, उपयोगकर्ता नाम, होस्टनेम, वर्कस्पेस की जानकारी वगैरह के साथ बाइनरी पर स्टैंप लगाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.
टैग: affects_outputs
--stripopt=<a string> कई बार इस्तेमाल किया गया हो: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: Apple tvOS के बाइनरी फ़ाइलें बनाने के लिए, आर्किटेक्चर की कॉमा लगाकर अलग की गई सूची.
टैग: loses_incremental_state, loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. यह जानकारी उपलब्ध न होने पर, 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple visionOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.
टैग: affects_outputs

--[no]check_licenses default: "false": देखें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]desugar_for_android default: "true": Java 8 के बाइटकोड को डेक्सिंग से पहले डीशुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs default: "false": लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की सुविधा वाली लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints default: "true": यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps default: "true": Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental
--experimental_import_deps_checking=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कोई कार्रवाई नहीं की गई, इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है
टैग: loading_and_analysis
--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है": इस विकल्प को चालू करने पर, यह पक्का किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल न हों. नीति उल्लंघन ठीक करने के लिए की गई कार्रवाई से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.
टैग: loading_and_analysis
--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default": अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files default: "false": अगर यह चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मिलती-जुलती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains default: "false": इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules default: "false": यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule default: "false": कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]one_version_enforcement_on_java_tests default: "true": इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.
टैग: loading_and_analysis
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: --incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल करने के लिए, अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis
--[no]strict_filesets default: "false": अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> default: "off": अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes default: "false": अगर यह वैल्यू सही है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित किए जाने चाहिए.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2": APK पर साइन करने के लिए इस्तेमाल किया जाने वाला तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis
--[no]device_debug_entitlements default: "true": अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो हस्ताक्षर करते समय, objc ऐप्लिकेशन में डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs
--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें: iOS पर साइन करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.
टैग: action_command_lines

--[no]incompatible_disallow_legacy_py_provider default: "true": यह कोई कार्रवाई नहीं करता है. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes default: "false": अगर यह सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_alwayslink_by_default default: "false": अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules default: "false": जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures default: "false": अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के इंस्टेंस को AnalysisFailureInfo का इंस्टेंस मिलेगा. इसमें गड़बड़ी की जानकारी होगी. इससे बिल्ड पूरा नहीं होगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन वाले नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure default: "false": अगर dex2oat की कार्रवाई पूरी नहीं होती है, तो टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय, बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो: टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की रकम को बदल देंगे. वैल्यू, HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]<float> (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4) भी हो सकता है. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में तय किए गए संसाधनों से बदल दिया जाता है.
--[no]experimental_android_use_parallel_dex2oat default: "false": android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks default: "false": ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines
--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. उदाहरण के लिए, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची देखी जा सकती है.
टैग: test_runner
--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें: सिम्युलेटर पर चलाने या जांच करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner
--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो: इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी वजह से इनमें से कोई भी कोशिश पूरी नहीं होती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू से है. वहीं, regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को तीन बार नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. मिलते-जुलते सबसे हाल के तर्क को प्राथमिकता दी जाती है. अगर कोई भी शर्त पूरी नहीं होती है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.
--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
टैग: test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट के टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करने के लिए कहा जाता है.
--[no]zip_undeclared_test_outputs default: "false": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो बिना बताए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

--[no]experimental_filter_library_jar_with_program_jar default: "false": ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास हटाई जा सकें.
टैग: action_command_lines, experimental
--[no]experimental_inmemory_dotd_files default: "true": अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly default: "false": इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट से जुड़े नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_starlark_cc_import default: "false": यह विकल्प चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning default: "false": क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता है और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental
--[no]incremental_dexing default: "true": यह हर जार फ़ाइल के लिए, अलग से डेक्सिंग का ज़्यादातर काम करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning default: "true": अगर इस विकल्प को सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल किया जाएगा. इससे, objc कंपाइलर को पास किए गए इनपुट के सेट को कम किया जा सकेगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies default: "false": When building a target //a:a, process headers in all targets that //a:a depends on (if header processing is enabled for the toolchain).
टैग: execution
--[no]trim_test_configuration default: "true": यह सुविधा चालू होने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*": टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.
टैग: terminal_output

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py default: "false": इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन पाएं. खास तौर पर, जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इस फ़्लैग को सेट करने पर ही इसे गलत माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed default: "true": अगर यह 'सही है', तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, ऐसे आउटपुट रूट में दिखेंगे जिसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिमलिंक, Python 2 के बजाय Python 3 के टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default default: "true": अगर यह सही है, तो `py_binary` और `py_test` टारगेट, `python_version` या `default_python_version` एट्रिब्यूट सेट नहीं करते हैं. ऐसे में, ये टारगेट डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. इस फ़्लैग को सेट करने पर, यह भी सुझाव दिया जाता है कि `--incompatible_py2_outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains default: "true": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के एक्ज़ीक्यूटेबल नेटिव नियम, Python टूलचेन के ज़रिए तय किए गए Python रनटाइम का इस्तेमाल करेंगे. इसके बजाय, वे --python_top जैसे लेगसी फ़्लैग के ज़रिए दिए गए रनटाइम का इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change
--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें: Python का मुख्य वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट से बदला जाता है. भले ही, वे साफ़ तौर पर किसी वर्शन के बारे में न बताते हों. इसलिए, आम तौर पर इस फ़्लैग को सप्लाई करने की कोई वजह नहीं होती.
टैग: loading_and_analysis, affects_outputs

--[no]cache_test_results [-t] default: "auto": अगर इसे 'auto' पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें बाहरी के तौर पर मार्क नहीं किया गया है. 'नहीं' पर सेट होने पर, Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.
--[no]experimental_cancel_concurrent_tests default: "never": अगर 'on_failed' या 'on_passed' है, तो Blaze उस नतीजे के साथ पहली बार चलने वाले टेस्ट को रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_fetch_all_coverage_outputs default: "false": अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_generate_llvm_lcov default: "false": अगर यह विकल्प सही पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_j2objc_header_map default: "true": J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental
--[no]experimental_j2objc_shorter_header_path default: "false": क्या हेडर पाथ को छोटा करके जनरेट करना है. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "javabuilder": इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.
--[no]experimental_limit_android_lint_to_android_constrained_java default: "false": No-op, kept only for backwards compatibility
Tags: affects_outputs, experimental
--[no]experimental_run_android_lint_on_java_rules default: "false": java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs, experimental
--[no]explicit_java_test_deps default: "false": java_test में, TestRunner की deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.
--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, javac को पास करने के लिए अतिरिक्त विकल्प.
--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो: बिल्डिंग टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये टूल, बिल्ड के दौरान एक्ज़ीक्यूट किए जाते हैं. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support default: "true": अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को तब फ़ेल कर देगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में मौजूद पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, हर शार्ड में सभी टेस्ट चलाएगा.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed default: "true": अगर यह वैल्यू सही है, तो सैंडबॉक्स की गई रणनीति के साथ खास टेस्ट चलाए जाएंगे. 'local' टैग जोड़कर, स्थानीय तौर पर सिर्फ़ एक टेस्ट रन करें
टैग: incompatible_change
--[no]incompatible_strict_action_env default: "false": अगर यह विकल्प सही है, तो Bazel ऐसे एनवायरमेंट का इस्तेमाल करता है जिसमें PATH के लिए स्टैटिक वैल्यू होती है. साथ ही, यह LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने से, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा. ऐसा तब होगा, जब शेयर की गई कैश मेमोरी का इस्तेमाल किया जा रहा हो.
टैग: loading_and_analysis, incompatible_change
--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.
--java_debug: इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इनमें बदल जाता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps default: "true": हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करें. फ़िलहाल, यह जानकारी कंपाइल-टाइम क्लासपाथ के लिए जनरेट की जाती है.
--[no]java_header_compilation default: "true": सोर्स से सीधे तौर पर ijars कंपाइल करें.
--java_language_version=<a string> default: "": Java भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट, इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": Java रनटाइम का वर्शन
--javacopt=<a string> कई बार इस्तेमाल किया गया हो: javac को पास करने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> कई बार इस्तेमाल किया गया हो: Java VM को पास करने के लिए अतिरिक्त विकल्प. इन विकल्पों को हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिया जाएगा.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किए जाने वाले बाइनरी के बारे में बताता है.
--plugin=<a build target label> कई बार इस्तेमाल किया गया हो: बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.
--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प से यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.
--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--[no]proto_profile default: "true": प्रोफ़ाइल_पाथ को प्रोटो कंपाइलर को पास करना है या नहीं.
टैग: affects_outputs, loading_and_analysis
--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल, जो C++ प्रोटो को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि j2objc protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि Java protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain": proto_lang_toolchain() का लेबल, जो बताता है कि JavaLite protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis
--protocopt=<a string> कई बार इस्तेमाल किया गया हो: प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs
--[no]runs_per_test_detects_flakes default: "false": अगर यह वैल्यू सही है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.
--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का ऐब्सलूट पाथ. अगर इसे सेट नहीं किया जाता है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन (जो Bazel सर्वर शुरू करता है) पर सेट किया जाता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. जैसे, Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी फ़ाइलों को बनाने या उन्हें चलाने में समस्याएं आ सकती हैं.
टैग: loading_and_analysis
--test_arg=<a string> कई बार इस्तेमाल किया गया हो: यह अतिरिक्त विकल्प और आर्ग्युमेंट तय करता है. इन्हें टेस्ट एक्ज़ीक्यूटेबल को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast default: "false": यह विकल्प, टेस्ट रनर को फ़ेल फ़ास्ट की जानकारी देता है. पहली गड़बड़ी होने पर, टेस्ट रनर को टेस्ट बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'shard_count' BUILD एट्रिब्यूट मौजूद होने पर ही शार्डिंग का इस्तेमाल करने के लिए, 'explicit' का इस्तेमाल करें. 'disabled' को कभी भी टेस्ट शार्डिंग का इस्तेमाल न करने के लिए सेट करें. 'forced=k' का इस्तेमाल, 'shard_count' BUILD एट्रिब्यूट के बावजूद, टेस्टिंग के लिए 'k' शार्ड लागू करने के लिए किया जाता है.
--tool_java_language_version=<a string> default: "": The Java language version used to execute the tools that are needed during a build
--tool_java_runtime_version=<a string> default: "remotejdk_11": बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

वर्शन के विकल्प

--[no]gnu_format default: "false": अगर सेट है, तो GNU स्टैंडर्ड में बताए गए नियमों का इस्तेमाल करके, stdout में वर्शन लिखें.
टैग: affects_outputs, execution

--[no]incompatible_use_plus_in_repo_names default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

विकल्प के असर वाले टैग

`unknown`	इस विकल्प का असर क्या होगा, इसकी जानकारी नहीं है या इसके बारे में दस्तावेज़ में नहीं बताया गया है.
`no_op`	इस विकल्प से कोई असर नहीं पड़ता.
`loses_incremental_state`	इस विकल्प की वैल्यू बदलने से, इंक्रीमेंटल स्टेट में काफ़ी नुकसान हो सकता है. इससे बिल्ड की प्रोसेस धीमी हो जाती है. सर्वर के रीस्टार्ट होने या डिपेंडेंसी ग्राफ़ के बड़े हिस्से के अमान्य होने की वजह से, स्थिति मिट सकती है.
`changes_inputs`	इस विकल्प से, उन इनपुट में बदलाव होता है जिन्हें Bazel, बिल्ड के लिए इस्तेमाल करता है. जैसे, फ़ाइल सिस्टम से जुड़ी पाबंदियां, रिपॉज़िटरी के वर्शन या अन्य विकल्प.
`affects_outputs`	इस विकल्प से Bazel के आउटपुट पर असर पड़ता है. यह टैग जान-बूझकर ब्रॉड है. इसमें ट्रांज़िटिव इफ़ेक्ट शामिल हो सकते हैं. साथ ही, यह नहीं बताता कि यह किस तरह के आउटपुट पर असर डालता है.
`build_file_semantics`	इस विकल्प से BUILD या .bzl फ़ाइलों के सिमैंटिक पर असर पड़ता है.
`bazel_internal_configuration`	इस विकल्प से, Bazel के इंटरनल सिस्टम की सेटिंग पर असर पड़ता है. इस टैग का मतलब यह नहीं है कि बिल्ड आर्टफ़ैक्ट पर असर पड़ा है.
`loading_and_analysis`	इस विकल्प से, डिपेंडेंसी लोड करने और उनका विश्लेषण करने के साथ-साथ डिपेंडेंसी ग्राफ़ बनाने पर असर पड़ता है.
`execution`	इस विकल्प से, एक्ज़ीक्यूशन फ़ेज़ पर असर पड़ता है. जैसे, सैंडबॉक्सिंग या रिमोट एक्ज़ीक्यूशन से जुड़े विकल्प.
`host_machine_resource_optimizations`	इस विकल्प से एक ऑप्टिमाइज़ेशन ट्रिगर होता है. यह ऑप्टिमाइज़ेशन, मशीन के हिसाब से अलग-अलग हो सकता है. साथ ही, इस बात की कोई गारंटी नहीं है कि यह सभी मशीनों पर काम करेगा. ऑप्टिमाइज़ेशन में, परफ़ॉर्मेंस के अन्य पहलुओं के साथ समझौता करना पड़ सकता है. जैसे, मेमोरी या सीपीयू की लागत.
`eagerness_to_exit`	इस विकल्प से यह तय होता है कि Bazel किसी गड़बड़ी के बाद कितनी जल्दी बंद हो जाएगा. ऐसा तब होता है, जब गड़बड़ी के बावजूद जारी रखने और इनवॉकेशन को खत्म करने का विकल्प मौजूद होता है.
`bazel_monitoring`	इस विकल्प का इस्तेमाल, Bazel के व्यवहार और परफ़ॉर्मेंस पर नज़र रखने के लिए किया जाता है.
`terminal_output`	इस विकल्प से, Bazel के टर्मिनल आउटपुट पर असर पड़ता है.
`action_command_lines`	इस विकल्प से, एक या उससे ज़्यादा बिल्ड ऐक्शन के कमांड-लाइन आर्ग्युमेंट बदल जाते हैं.
`test_runner`	इस विकल्प से, बिल्ड के टेस्ट रनर एनवायरमेंट में बदलाव होता है.

विकल्प मेटाडेटा टैग

`experimental`	इस विकल्प से, एक्सपेरिमेंट के तौर पर उपलब्ध सुविधा चालू हो जाती है. हालांकि, इस सुविधा के काम करने की कोई गारंटी नहीं है.
`incompatible_change`	इस विकल्प से, एपीआई में ऐसा बदलाव होता है जो पहले से मौजूद एपीआई के साथ काम नहीं करता. इस विकल्प का इस्तेमाल करके, यह जांच करें कि माइग्रेशन के लिए आपका सेटअप तैयार है या नहीं. इसके अलावा, नई सुविधा का ऐक्सेस पहले पाएं
`deprecated`	यह विकल्प अब उपलब्ध नहीं है. ऐसा हो सकता है कि जिस सुविधा पर इसका असर पड़ता है वह बंद हो गई हो या जानकारी देने के लिए किसी दूसरे तरीके का इस्तेमाल किया जा रहा हो.
`immutable`	इस विकल्प को ट्रांज़िशन में नहीं बदला जा सकता.