Build Foundation ने फ़ाउंडिंग सदस्यों के तौर पर लोगों को शामिल करना शुरू कर दिया है! ईमेल पाने वाली सूची में शामिल हों, रिसर्च में हिस्सा लेने से जुड़ा कानूनी समझौता पढ़ें, और रजिस्टर करें!

Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

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

समस्या की शिकायत करें सोर्स देखें

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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`	यह कमांड, तय किए गए टेस्ट टारगेट को बिल्ड करती है और उन्हें चलाती है.
`version`	Bazel के वर्शन की जानकारी दिखाता है.

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

--[no]autodetect_server_javabase default: "true": जब --noautodetect_server_javabase पास किया जाता है, तो Bazel, bazel सर्वर को चलाने के लिए लोकल JDK पर वापस नहीं आता. इसके बजाय, यह बंद हो जाता है.
टैग: affects_outputs, loses_incremental_state
--[no]batch डिफ़ॉल्ट: "false": अगर इस विकल्प को सेट किया जाता है, तो Bazel को स्टैंडर्ड क्लाइंट/सर्वर मोड में चलाने के बजाय, सिर्फ़ क्लाइंट प्रोसेस के तौर पर चलाया जाएगा. इसमें सर्वर नहीं होगा. यह सुविधा अब काम नहीं करती और इसे हटा दिया जाएगा. अगर आपको ऐसे सर्वर से बचना है जो बंद नहीं होते हैं, तो कृपया सर्वर को बंद करें.
टैग: loses_incremental_state, bazel_internal_configuration, deprecated
--[no]batch_cpu_scheduling डिफ़ॉल्ट: "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) z.rc को अनदेखा किया जाता है, क्योंकि इससे पहले /dev/null का इस्तेमाल किया गया था. अगर यह जानकारी नहीं दी गई है, तो Bazel उस पहली .bazelrc फ़ाइल का इस्तेमाल करता है जो उसे इन दो जगहों पर मिलती है: वर्कस्पेस डायरेक्ट्री और फिर उपयोगकर्ता की होम डायरेक्ट्री. ध्यान दें: कमांड लाइन के विकल्प, हमेशा bazelrc में मौजूद किसी भी विकल्प से ज़्यादा प्राथमिकता वाले होते हैं.
टैग: changes_inputs
--[no]block_for_lock default: "true": जब --noblock_for_lock पास किया जाता है, तो Bazel चालू कमांड के पूरा होने का इंतज़ार नहीं करता, बल्कि तुरंत बंद हो जाता है.
टैग: eagerness_to_exit
--[no]client_debug डिफ़ॉल्ट: "false": अगर सही है, तो क्लाइंट से डीबग जानकारी को stderr में लॉग करें. इस विकल्प को बदलने से, सर्वर रीस्टार्ट नहीं होगा.
टैग: affects_outputs, bazel_monitoring
--connect_timeout_secs=<an integer> default: "30": क्लाइंट, सर्वर से कनेक्ट करने की हर कोशिश के लिए जितने समय तक इंतज़ार करता है
टैग: bazel_internal_configuration
--[no]expand_configs_in_place default: "true": --config फ़्लैग को एक्सपैंड करने के तरीके में बदलाव किया गया है. अब इसे एक ही जगह पर एक्सपैंड किया जाएगा. पहले, इसे सामान्य rc विकल्पों और कमांड-लाइन में तय किए गए विकल्पों के बीच एक तय जगह पर एक्सपैंड किया जाता था.
टैग: no_op, deprecated
--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": Run System.gc() when the server is idle
Tags: loses_incremental_state, host_machine_resource_optimizations
--[no]ignore_all_rc_files डिफ़ॉल्ट: "false": यह सभी rc फ़ाइलों को बंद कर देता है. भले ही, rc में बदलाव करने वाले अन्य फ़्लैग की वैल्यू कुछ भी हों. भले ही, ये फ़्लैग स्टार्टअप के विकल्पों की सूची में बाद में आते हों.
टैग: changes_inputs
--io_nice_level={-1,0,1,2,3,4,5,6,7} default: "-1": सिर्फ़ Linux पर; sys_ioprio_set सिस्टम कॉल का इस्तेमाल करके, सबसे सही तरीके से आई/ओ शेड्यूल करने के लिए, 0 से 7 तक का लेवल सेट करें. 0 सबसे ज़्यादा प्राथमिकता वाला और 7 सबसे कम प्राथमिकता वाला है. अनुमानित शेड्यूल करने की सुविधा, सिर्फ़ चौथी प्राथमिकता तक के अनुरोधों को पूरा कर सकती है. अगर इसे नेगेटिव वैल्यू पर सेट किया जाता है, तो 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 डिफ़ॉल्ट: "false": अगर यह वैल्यू सही है, तो कोई दूसरी कमांड शुरू होने पर, इस कमांड को रोका जा सकता है.
टैग: eagerness_to_exit
--server_jvm_out=<path> डिफ़ॉल्ट: ब्यौरा देखें: सर्वर के JVM के आउटपुट को लिखने की जगह. अगर इसे सेट नहीं किया जाता है, तो यह output_base में मौजूद किसी जगह पर डिफ़ॉल्ट रूप से सेट हो जाता है.
टैग: affects_outputs, loses_incremental_state
--[no]shutdown_on_low_sys_mem डिफ़ॉल्ट: "false": अगर max_idle_secs सेट है और बिल्ड सर्वर कुछ समय से इस्तेमाल नहीं किया जा रहा है, तो सिस्टम में खाली रैम कम होने पर सर्वर को बंद कर दें. सिर्फ़ Linux के लिए.
टैग: eagerness_to_exit, loses_incremental_state
--[no]system_rc default: "true": सिस्टम-वाइड bazelrc को खोजना है या नहीं.
टैग: changes_inputs
--[no]unlimit_coredumps डिफ़ॉल्ट: "false": यह विकल्प, सॉफ़्ट कोरडंप की सीमा को हार्ड लिमिट तक बढ़ाता है. इससे सामान्य स्थितियों में, सर्वर (इसमें JVM भी शामिल है) और क्लाइंट के कोरडंप बनाए जा सकते हैं. इस फ़्लैग को अपने bazelrc में एक बार चिपकाएं और इसके बारे में भूल जाएं, ताकि जब आपको ऐसी स्थिति का सामना करना पड़े जिससे कोरडंप ट्रिगर होते हैं, तो आपको कोरडंप मिलें.
टैग: bazel_internal_configuration
--[no]watchfs डिफ़ॉल्ट: "false": अगर यह विकल्प चालू है, तो Bazel हर फ़ाइल को स्कैन करने के बजाय, ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करके स्थानीय बदलावों का पता लगाने की कोशिश करता है.
टैग: deprecated
--[no]windows_enable_symlinks डिफ़ॉल्ट: "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
--host_jvm_profile=<profiler_name> default: "": प्रोफ़ाइलर/डीबगर के लिए, JVM स्टार्टअप फ़्लैग जोड़ने का आसान विकल्प. Bazel के पास, जानी-पहचानी वैल्यू की एक सूची होती है. यह सूची, हार्ड-कोड किए गए JVM स्टार्टअप फ़्लैग से मैप होती है. ऐसा हो सकता है कि Bazel, कुछ फ़ाइलों के लिए हार्डकोड किए गए पाथ खोजे.
--server_javabase=<jvm path> default: "": Bazel को चलाने के लिए इस्तेमाल किए गए JVM का पाथ.

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

--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range> default: "1048576": stdout / stderr फ़ाइलों का ज़्यादा से ज़्यादा साइज़, जिसे कंसोल पर प्रिंट किया जाएगा. -1 का मतलब है कि कोई सीमा नहीं है.
टैग: execution
--[no]incompatible_remote_dangling_symlinks default: "true": अगर इसे सही पर सेट किया जाता है और --incompatible_remote_symlinks को भी सही पर सेट किया जाता है, तो ऐक्शन आउटपुट में मौजूद सिंबल लिंक को डैंगल होने की अनुमति होती है.
टैग: execution, incompatible_change
--[no]incompatible_remote_symlinks default: "true": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैशिंग/एक्ज़ीक्यूशन प्रोटोकॉल में ऐक्शन आउटपुट में सिमलंक को इस तरह से दिखाएगा. ऐसा न होने पर, सिमलंक को फ़ॉलो किया जाएगा और उन्हें फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए, #6631 देखें.
टैग: execution, incompatible_change

--[no]incompatible_enable_proto_toolchain_resolution डिफ़ॉल्ट: "false": अगर यह सही है, तो proto lang rules, rules_proto, rules_java, और rules_cc रिपॉज़िटरी से टूलचेन तय करते हैं.
टैग: loading_and_analysis, incompatible_change

--bep_maximum_open_remote_upload_files=<an integer> default: "-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]enable_bzlmod default: "true": अगर यह सही है, तो Bzlmod डिपेंडेंसी मैनेजमेंट सिस्टम चालू हो जाता है. यह WORKSPACE से ज़्यादा प्राथमिकता लेता है. ज़्यादा जानकारी के लिए, https://bazel.build/docs/bzlmod पर जाएं.
टैग: loading_and_analysis
--[no]experimental_action_resource_set default: "true": अगर इसे सही पर सेट किया जाता है, तो ctx.actions.run() और ctx.actions.run_shell(), लोकल एक्ज़ीक्यूशन के लिए resource_set पैरामीटर स्वीकार करते हैं. ऐसा न करने पर, मेमोरी के लिए 250 एमबी और सीपीयू के लिए 1 डिफ़ॉल्ट रूप से सेट हो जाएगा.
टैग: execution, build_file_semantics, experimental
--[no]experimental_bzl_visibility default: "true": इस विकल्प को चालू करने पर, `visibility()` फ़ंक्शन जुड़ जाता है. .bzl फ़ाइलें, टॉप-लेवल के आकलन के दौरान इस फ़ंक्शन को कॉल कर सकती हैं. इससे, load() स्टेटमेंट के लिए अपनी विज़िबिलिटी सेट की जा सकती है.
टैग: loading_and_analysis, experimental
--[no]experimental_cc_shared_library डिफ़ॉल्ट: "false": अगर इसे सही पर सेट किया जाता है, तो cc_shared_library नियम के लिए ज़रूरी नियम एट्रिब्यूट और Starlark API के तरीके उपलब्ध होंगे
टैग: build_file_semantics, loading_and_analysis, experimental
--[no]experimental_disable_external_package डिफ़ॉल्ट: "false": अगर इसे true पर सेट किया जाता है, तो अपने-आप जनरेट होने वाला //external पैकेज अब उपलब्ध नहीं होगा. Bazel अब भी 'external/BUILD' फ़ाइल को पार्स नहीं कर पाएगा. हालांकि, बिना नाम वाले पैकेज से external/ तक पहुंचने वाले ग्लोब काम करेंगे.
टैग: loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_enable_android_migration_apis डिफ़ॉल्ट: "false": इस नीति को 'सही है' पर सेट करने से, Android Starlark माइग्रेशन के लिए ज़रूरी एपीआई चालू हो जाते हैं.
टैग: build_file_semantics
--[no]experimental_enable_scl_dialect डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो load() स्टेटमेंट में .scl फ़ाइलों का इस्तेमाल किया जा सकता है.
टैग: build_file_semantics
--[no]experimental_google_legacy_api डिफ़ॉल्ट: "false": अगर इसे सही पर सेट किया जाता है, तो Google के लेगसी कोड से जुड़े Starlark build API के कई एक्सपेरिमेंटल कॉम्पोनेंट दिखते हैं.
टैग: loading_and_analysis, experimental
--[no]experimental_isolated_extension_usages डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो experimental_java_library_export_do_not_use मॉड्यूल उपलब्ध होता है.
टैग: loading_and_analysis, incompatible_change
--[no]experimental_platforms_api डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो प्लैटफ़ॉर्म से जुड़े कई Starlark API चालू हो जाते हैं. ये डीबग करने के लिए काम आते हैं.
टैग: loading_and_analysis, experimental
--[no]experimental_repo_remote_exec डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो repository_rule को रिमोट एक्ज़ीक्यूशन की कुछ सुविधाएं मिलती हैं.
टैग: build_file_semantics, loading_and_analysis, experimental
--[no]experimental_sibling_repository_layout डिफ़ॉल्ट: "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]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
--[no]incompatible_depset_for_java_output_source_jars default: "true": जब यह विकल्प चालू होता है, तो Bazel, java_info.java_output[0].source_jars से सूची नहीं दिखाता. इसके बजाय, यह एक depset दिखाता है.
टैग: loading_and_analysis, 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_objc_library_transition default: "true": objc_library के कस्टम ट्रांज़िशन को बंद करें और इसके बजाय, टॉप लेवल के टारगेट से इनहेरिट करें
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_starlark_host_transitions डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो नियम एट्रिब्यूट 'cfg = "host"' सेट नहीं कर सकते. नियमों को इसके बजाय, 'cfg = "exec"' सेट करना चाहिए.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disable_target_provider_fields डिफ़ॉल्ट: "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_disallow_empty_glob डिफ़ॉल्ट: "false": अगर इसे सही पर सेट किया जाता है, तो glob() फ़ंक्शन के `allow_empty` आर्ग्युमेंट की डिफ़ॉल्ट वैल्यू गलत होती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disallow_struct_provider_syntax डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो नियम लागू करने वाले फ़ंक्शन, स्ट्रक्चर नहीं दिखा सकते. इसके बजाय, उन्हें सेवा देने वाली कंपनियों के इंस्टेंस की सूची दिखानी चाहिए.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_existing_rules_immutable_view default: "true": अगर इसे सही पर सेट किया जाता है, तो native.existing_rule और native.existing_rules, बदलने लायक डिक्शनरी के बजाय हल्के-फुल्के इम्यूटेबल व्यू ऑब्जेक्ट दिखाते हैं.
टैग: build_file_semantics, loading_and_analysis, incompatible_change
--[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 में output_jar और host_javabase पैरामीटर और कंपाइल में host_javabase पैरामीटर हटा दिए जाएंगे.
टैग: build_file_semantics, 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_new_actions_api default: "true": अगर इसे सही पर सेट किया जाता है, तो कार्रवाइयां बनाने वाला एपीआई सिर्फ़ `ctx.actions` पर उपलब्ध होता है, न कि `ctx` पर.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_no_attr_license default: "true": इस वैल्यू को सही पर सेट करने से, `attr.license` फ़ंक्शन बंद हो जाता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_no_implicit_file_export डिफ़ॉल्ट: "false": अगर इसे सेट किया जाता है, तो इस्तेमाल की गई सोर्स फ़ाइलें पैकेज के लिए निजी होती हैं. हालांकि, इन्हें साफ़ तौर पर एक्सपोर्ट किया जा सकता है. https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-24-file-visibility.md पर जाएं
टैग: build_file_semantics, incompatible_change
--[no]incompatible_no_rule_outputs_param डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो यह `rule()` Starlark फ़ंक्शन के `outputs` पैरामीटर को बंद कर देता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_provider_remove_linking_info डिफ़ॉल्ट: "false": अगर इसे सही पर सेट किया जाता है, तो लिंक करने की जानकारी के लिए ObjcProvider के एपीआई हटा दिए जाएंगे.
टैग: 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_stop_exporting_language_modules डिफ़ॉल्ट: "false": अगर यह विकल्प चालू है, तो भाषा के हिसाब से कुछ मॉड्यूल (जैसे कि `cc_common`) उपयोगकर्ता की .bzl फ़ाइलों में उपलब्ध नहीं होते. इन्हें सिर्फ़ इनसे जुड़े नियमों की रिपॉज़िटरी से कॉल किया जा सकता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_struct_has_no_methods डिफ़ॉल्ट: "false": यह स्ट्रक्चर के to_json और to_proto तरीकों को बंद कर देता है. ये तरीके, स्ट्रक्चर फ़ील्ड नेमस्पेस को खराब करते हैं. इसके बजाय, JSON के लिए json.encode या json.encode_indent का इस्तेमाल करें. साथ ही, textproto के लिए proto.encode_text का इस्तेमाल करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_top_level_aspects_require_providers डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो टॉप लेवल का आसपेक्ट, ज़रूरी सेवा देने वाली कंपनियों का सम्मान करेगा. साथ ही, यह सिर्फ़ उन टॉप लेवल के टारगेट पर चलेगा जिनके नियमों में विज्ञापन देने वाली कंपनियां, आसपेक्ट की ज़रूरी सेवा देने वाली कंपनियों की शर्तों को पूरा करती हैं.
टैग: 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 डिफ़ॉल्ट: "false": इस विकल्प को सही पर सेट करने पर, Bazel, @bazel_tools से cc_configure का इस्तेमाल करने की अनुमति नहीं देगा. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, कृपया https://github.com/bazelbuild/bazel/issues/10134 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition default: "true": अगर इसे सही पर सेट किया जाता है, तो नियम की परिभाषा के हिसाब से, निजी नियम वाले एट्रिब्यूट के दिखने की सेटिंग की जांच की जाती है. अगर एट्रिब्यूट नहीं दिखता है, तो नियम के इस्तेमाल की सेटिंग पर वापस आ जाता है.
टैग: build_file_semantics, 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

--[no]heuristically_drop_nodes डिफ़ॉल्ट: "false": अगर यह सही है, तो Blaze, FileState और DirectoryListingState नोड को हटा देगा. ऐसा, फ़ाइल और 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
--[no]track_incremental_state default: "true": अगर यह वैल्यू 'गलत' पर सेट है, तो Blaze ऐसे डेटा को सेव नहीं करेगा जिससे इंक्रीमेंटल बिल्ड पर अमान्य होने और फिर से आकलन करने की अनुमति मिलती है. ऐसा इसलिए किया जाता है, ताकि इस बिल्ड पर मेमोरी सेव की जा सके. इसके बाद के बिल्ड में, इस बिल्ड के मुकाबले कोई बढ़ोतरी नहीं होगी. आम तौर पर, इस विकल्प को false पर सेट करते समय --batch को सेट करना होता है.
टैग: loses_incremental_state

--[no]announce_rc डिफ़ॉल्ट: "false": rc विकल्पों के बारे में सूचना देनी है या नहीं.
टैग: affects_outputs
--[no]attempt_to_print_relative_paths डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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": इससे यह तय होता है कि मेमोरी खत्म होने पर, Bazel को BES/BEP अपलोड होने का कितना इंतज़ार करना चाहिए. यह फ़्लैग यह पक्का करता है कि जब JVM में GC थ्रैशिंग की समस्या हो और वह किसी भी उपयोगकर्ता थ्रेड पर काम न कर पाए, तो उसे बंद कर दिया जाए.
टैग: bazel_monitoring
--bes_outerr_buffer_size=<an integer> default: "10240": यह BEP में 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> कई बार इस्तेमाल किया गया हो: यह सूचना से जुड़े कीवर्ड की एक सूची तय करता है. इसमें कीवर्ड को सीधे तौर पर शामिल किया जाता है. --bes_keywords के ज़रिए दिए गए कीवर्ड के लिए, "user_keyword=" प्रीफ़िक्स शामिल नहीं किया जाता. यह बिल्ड सेवा के उन ऑपरेटर के लिए है जो --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> default: "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> default: "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> default: "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: "-1": named_set_of_files इवेंट के लिए, ज़्यादा से ज़्यादा एंट्री की संख्या; दो से कम वैल्यू को अनदेखा किया जाता है और इवेंट को स्प्लिट नहीं किया जाता. इसका इस्तेमाल, बिल्ड इवेंट प्रोटोकॉल में इवेंट के साइज़ को सीमित करने के लिए किया जाता है. हालांकि, यह इवेंट के साइज़ को सीधे तौर पर कंट्रोल नहीं करता है. इवेंट का कुल साइज़, सेट के स्ट्रक्चर के साथ-साथ फ़ाइल और यूआरआई की लंबाई पर निर्भर करता है. यह हैश फ़ंक्शन पर भी निर्भर कर सकता है.
टैग: affects_outputs
--[no]build_event_publish_all_actions डिफ़ॉल्ट: "false": क्या सभी कार्रवाइयों को पब्लिश किया जाना चाहिए.
टैग: affects_outputs
--build_event_text_file=<a string> default: "": अगर यह फ़ाइल खाली नहीं है, तो इसमें बिल्ड इवेंट प्रोटोकॉल का टेक्स्ट वर्शन लिखें
टैग: 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> default: "wait_for_upload_complete": इससे यह तय होता है कि --build_event_text_file के लिए, Build Event Service का अपलोड, बिल्ड पूरा होने पर ब्लॉक होना चाहिए या इनवोकेशन को तुरंत खत्म कर देना चाहिए और बैकग्राउंड में अपलोड पूरा करना चाहिए. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit
--[no]experimental_announce_profile_path डिफ़ॉल्ट: "false": इस विकल्प को चालू करने पर, JSON प्रोफ़ाइल पाथ को लॉग में जोड़ दिया जाता है.
टैग: bazel_monitoring
--[no]experimental_bep_target_summary डिफ़ॉल्ट: "false": TargetSummary इवेंट पब्लिश करने हैं या नहीं.
--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय BEP में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में Fileset के सभी रिलेटिव सिंबल लिंक पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets विकल्प की ज़रूरत होती है.
टैग: affects_outputs
--experimental_build_event_upload_max_retries=<an integer> default: "4": Bazel को बिल्ड इवेंट अपलोड करने की कोशिश ज़्यादा से ज़्यादा कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो प्रोफ़ाइलर, Linux PSI डेटा इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_resource_estimation डिफ़ॉल्ट: "false": अगर यह सेटिंग चालू है, तो प्रोफ़ाइलर, स्थानीय कार्रवाइयों के लिए सीपीयू और मेमोरी के इस्तेमाल का अनुमान इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_system_network_usage डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो प्रोफ़ाइलर सिस्टम के नेटवर्क के इस्तेमाल की जानकारी इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_worker_data_in_profiler डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो प्रोफ़ाइलर, वर्कर के संसाधन का इकट्ठा किया गया डेटा इकट्ठा करता है.
टैग: bazel_monitoring
--experimental_profile_additional_tasks=<phase, action, action_check, action_lock, action_release, action_update, action_complete, 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, action_counts, action_cache_counts, local_cpu_usage, system_cpu_usage, cpu_usage_estimation, local_memory_usage, system_memory_usage, memory_usage_estimation, system_network_up_usage, system_network_down_usage, workers_memory_usage, system_load_average, 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, pressure_stall_io, pressure_stall_memory, conflict_check, dynamic_lock or unknown> कई बार इस्तेमाल किया गया हो: इस विकल्प का इस्तेमाल करके, प्रोफ़ाइल में शामिल करने के लिए अन्य प्रोफ़ाइल टास्क तय किए जाते हैं.
टैग: bazel_monitoring
--[no]experimental_profile_include_primary_output डिफ़ॉल्ट: "false": इसमें कार्रवाई वाले इवेंट में "out" एट्रिब्यूट शामिल होता है. इसमें कार्रवाई के मुख्य आउटपुट का एक्ज़ेक पाथ होता है.
टैग: bazel_monitoring
--[no]experimental_profile_include_target_label डिफ़ॉल्ट: "false": इसमें कार्रवाई वाले इवेंट के JSON प्रोफ़ाइल डेटा में टारगेट लेबल शामिल होता है.
टैग: bazel_monitoring
--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "false": क्या रन बिल्ड इवेंट में कमांड-लाइन के बचे हुए हिस्से को शामिल करना है. इसमें बचा हुआ हिस्सा शामिल हो सकता है. डिफ़ॉल्ट रूप से, रन कमांड के बिल्ड इवेंट में बचे हुए डेटा को शामिल नहीं किया जाता. हालांकि, इसमें बचे हुए डेटा को शामिल किया जा सकता है.
टैग: affects_outputs
--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर ओओएम की समस्या आती है, तो क्या हीप डंप को मैन्युअल तरीके से आउटपुट करना है. इसमें --gc_thrashing_limits तक पहुंचने की वजह से होने वाली मैन्युअल ओओएम की समस्याएं भी शामिल हैं. डंप को <output_base>/<invocation_id>.heapdump.hprof में लिखा जाएगा. यह विकल्प, -XX:+HeapDumpOnOutOfMemoryError को बदल देता है. हालांकि, मैन्युअल ओओएम के लिए इसका कोई असर नहीं होता.
टैग: bazel_monitoring
--[no]legacy_important_outputs default: "true": इसका इस्तेमाल, TargetComplete इवेंट में लेगसी important_outputs फ़ील्ड के जनरेशन को रोकने के लिए करें. Bazel को ResultStore के साथ इंटिग्रेट करने के लिए, 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
--[no]record_full_profiler_data डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, Bazel प्रोफ़ाइलर सिर्फ़ एग्रीगेट किए गए डेटा को रिकॉर्ड करेगा. यह डेटा, तेज़ी से होने वाले कई इवेंट (जैसे, फ़ाइल की स्थिति) के लिए होता है. इस विकल्प के चालू होने पर, प्रोफ़ाइलर हर इवेंट को रिकॉर्ड करेगा. इससे प्रोफ़ाइलिंग का ज़्यादा सटीक डेटा मिलेगा, लेकिन परफ़ॉर्मेंस पर काफ़ी असर पड़ेगा. इस विकल्प का असर सिर्फ़ तब होता है, जब --profile का भी इस्तेमाल किया गया हो.
टैग: 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_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: ब्यौरा देखें: यह बताता है कि सर्किट ब्रेकर को किस रणनीति का इस्तेमाल करना है. उपलब्ध रणनीतियां "failure" हैं. विकल्प के लिए अमान्य वैल्यू होने पर, विकल्प सेट न होने पर जैसा व्यवहार होता है वैसा ही व्यवहार होता है.
टैग: execution
--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "false": इस विकल्प को बंद करने पर, रिमोट कैश में किसी कार्रवाई को अपलोड करने से पहले, इनपुट फ़ाइलों के सीटाइम की जांच नहीं की जाएगी. ऐसा हो सकता है कि कुछ मामलों में Linux कर्नल, फ़ाइलों को लिखने में देरी करे. इससे फ़ॉल्स पॉज़िटिव मिल सकते हैं.
--[no]experimental_remote_cache_async डिफ़ॉल्ट: "false": अगर यह वैल्यू सही है, तो रिमोट कैश मेमोरी I/O, स्पॉन के हिस्से के तौर पर होने के बजाय बैकग्राउंड में होगा.
--[no]experimental_remote_cache_lease_extension डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर इसे सही पर सेट किया जाता है, तो 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 डिफ़ॉल्ट: "false": अगर रिमोट डाउनलोडर काम नहीं करता है, तो लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.
--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "false": रिमोट तरीके से एक्ज़ीक्यूट करने के लिए, कीपअलाइव का इस्तेमाल करना है या नहीं.
--experimental_remote_failure_rate_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर्सिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "false": अगर इस नीति को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने के लिए, मर्कल ट्री के कैलकुलेशन को मेमोराइज़ किया जाएगा. कैश मेमोरी के फ़ुटप्रिंट को --experimental_remote_merkle_tree_cache_size कंट्रोल करता है.
--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000": रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने के लिए, मेमोइज़ किए जाने वाले मर्कल ट्री की संख्या. Java, सॉफ्ट रेफ़रंस को मैनेज करता है. इसके हिसाब से, कैश अपने-आप कम हो जाती है. हालांकि, अगर कैश का साइज़ बहुत ज़्यादा सेट किया गया है, तो मेमोरी से जुड़ी गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड होता है. सबसे सही वैल्यू, प्रोजेक्ट के साइज़ के हिसाब से अलग-अलग होती है. डिफ़ॉल्ट वैल्यू 1,000 होती है.
--[no]experimental_remote_require_cached डिफ़ॉल्ट: "false": अगर इसे 'चालू है' पर सेट किया जाता है, तो यह ज़रूरी हो जाता है कि रिमोटली की जा सकने वाली सभी कार्रवाइयों को कैश मेमोरी में सेव किया जाए. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह सुविधा, नॉन-डिटरमिनिज़्म से जुड़ी समस्याओं को हल करने में मददगार होती है. इससे यह जांच की जा सकती है कि जिन कार्रवाइयों को कैश मेमोरी में सेव किया जाना चाहिए उन्हें कैश मेमोरी में सेव किया गया है या नहीं. साथ ही, यह भी जांच की जा सकती है कि कैश मेमोरी में नए नतीजे तो नहीं डाले गए हैं.
--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: ब्यौरा देखें: यह दी गई कॉन्फ़िगरेशन फ़ाइल की मदद से, रिमोट कैश मेमोरी की कुंजी को मिटाने की सुविधा चालू करता है. यह फ़ाइल, टेक्स्ट फ़ॉर्मैट में ScrubbingConfig प्रोटोकॉल बफ़र होनी चाहिए. इस सुविधा का मकसद, अलग-अलग प्लैटफ़ॉर्म पर एक्ज़ीक्यूट की जा रही कार्रवाइयों के बीच रिमोट/डिस्क की कैश मेमोरी को शेयर करना है. हालांकि, ये कार्रवाइयां एक ही प्लैटफ़ॉर्म को टारगेट करती हैं. इसका इस्तेमाल बहुत सावधानी से करना चाहिए, क्योंकि गलत सेटिंग की वजह से कैश मेमोरी की एंट्री अनजाने में शेयर हो सकती हैं. इससे गलत बिल्ड बन सकते हैं. स्क्रबिंग से, कार्रवाई के तरीके पर कोई असर नहीं पड़ता. इससे सिर्फ़ यह तय होता है कि कार्रवाई के नतीजे को वापस पाने या सेव करने के लिए, रिमोट/डिस्क की कैश मेमोरी की कुंजी की गिनती कैसे की जाती है. इसका इस्तेमाल रिमोट एक्ज़ीक्यूशन के साथ नहीं किया जा सकता. स्क्रबिंग के कॉन्फ़िगरेशन में बदलाव करने से, लोकल फ़ाइल सिस्टम या इंटरनल कैश मेमोरी में मौजूद आउटपुट अमान्य नहीं होते. जिन कार्रवाइयों पर असर पड़ा है उन्हें फिर से लागू करने के लिए, क्लीन बिल्ड की ज़रूरत होती है. इस सुविधा का इस्तेमाल करने के लिए, आपको --host_platform को --experimental_platform_in_output_dir (आउटपुट प्रीफ़िक्स को सामान्य करने के लिए) और --incompatible_strict_action_env (एनवायरमेंट वैरिएबल को सामान्य करने के लिए) के साथ सेट करना होगा.
--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "false": अब काम नहीं करता. कोई कार्रवाई नहीं की जाती. इसके बजाय, --remote_build_event_upload=minimal का इस्तेमाल करें.
--[no]incompatible_remote_downloader_send_all_headers default: "true": क्या एक से ज़्यादा वैल्यू वाले हेडर की सभी वैल्यू, रिमोट डाउनलोडर को भेजनी हैं या सिर्फ़ पहली वैल्यू.
टैग: incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट के हिसाब से तय किए जाते हैं.
टैग: incompatible_change
--[no]incompatible_remote_results_ignore_disk default: "true": No-op
टैग: 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> डिफ़ॉल्ट: ब्यौरा देखें: होस्टनेम और इंस्टेंस का नाम, जिसका इस्तेमाल bytestream:// यूआरआई में किया जाना है. ये यूआरआई, बिल्ड इवेंट स्ट्रीम में लिखे जाते हैं. इस विकल्प को तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इससे --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. इसे सेट न करने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.
--remote_cache=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कैशिंग एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. टीएलएस को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://bazel.build/remote/caching देखें
--[no]remote_cache_compression डिफ़ॉल्ट: "false": इस सेटिंग के चालू होने पर, zstd का इस्तेमाल करके कैश मेमोरी के बड़े डेटा को कंप्रेस/डीकंप्रेस किया जाता है.
--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 string> कई बार इस्तेमाल किया गया हो: Bazel को उन आर्टफ़ैक्ट को डाउनलोड करने के लिए मजबूर करता है जो दिए गए रेगुलर एक्सप्रेशन से मेल खाते हैं. इसका इस्तेमाल, Build without the Bytes (या इसके इंटरनल वर्शन) के साथ किया जाता है.इससे क्लाइंट, कुछ ऐसे आर्टफ़ैक्ट का अनुरोध कर सकता है जिनकी ज़रूरत स्थानीय तौर पर पड़ सकती है. जैसे, आईडीई सपोर्ट. इस फ़्लैग को दोहराकर, कई रेगुलर एक्सप्रेशन तय किए जा सकते हैं.
टैग: 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 डिफ़ॉल्ट: "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.> कई बार इस्तेमाल किया गया हो: यह क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि इसका इस्तेमाल इन कामों के लिए ऑथराइज़ेशन क्रेडेंशियल पाने के लिए किया जा सके: रिपॉज़िटरी फ़ेच करना, रिमोट कैशिंग और एक्ज़ीक्यूशन, और बिल्ड इवेंट सेवा. सहायक से मिले क्रेडेंशियल को --google_default_credentials, --google_credentials, .netrc फ़ाइल या repository_ctx.download और repository_ctx.download_and_extract के auth पैरामीटर से मिले क्रेडेंशियल की तुलना में ज़्यादा प्राथमिकता दी जाती है. एक से ज़्यादा हेल्पर सेट अप करने के लिए, इसे कई बार तय किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-credential-helpers.md पर जाएं.
--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 डिफ़ॉल्ट: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, bazelrc फ़ाइलों से होस्ट-ओएस के हिसाब से कॉन्फ़िगरेशन लाइनें चुनता है. उदाहरण के लिए, अगर होस्ट ओएस Linux है और आपने bazel build कमांड का इस्तेमाल किया है, तो Bazel, build:linux से शुरू होने वाली लाइनों को चुनता है. इन ओएस आइडेंटिफ़ायर का इस्तेमाल किया जा सकता है: linux, macos, windows, freebsd, और openbsd. इस फ़्लैग को चालू करने का मतलब है कि Linux पर --config=linux, Windows पर --config=windows वगैरह का इस्तेमाल करना.
--[no]experimental_rule_extension_api डिफ़ॉल्ट: "false": Enable experimental rule extension API and subrule APIs
Tags: loading_and_analysis, experimental
--[no]experimental_windows_watchfs डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह वैल्यू सही है, तो java_binary हमेशा एक्ज़ीक्यूटेबल होता है. create_executable एट्रिब्यूट हटा दिया जाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_symlink_file_to_dir default: "true": कोई कार्रवाई नहीं.
टैग: loading_and_analysis, incompatible_change
--[no]progress_in_terminal_title डिफ़ॉल्ट: "false": टर्मिनल के टाइटल में कमांड की प्रोग्रेस दिखाएं. कई टर्मिनल टैब होने पर, यह देखने के लिए उपयोगी है कि Bazel क्या कर रहा है.
--[no]show_progress default: "true": बिल्ड के दौरान प्रोग्रेस मैसेज दिखाएं.
--show_progress_rate_limit=<a double> default: "0.2": आउटपुट में प्रोग्रेस मैसेज के बीच कम से कम सेकंड की संख्या.
--[no]show_timestamps डिफ़ॉल्ट: "false": मैसेज में टाइमस्टैंप शामिल करना
--tls_certificate=<a string> डिफ़ॉल्ट: ब्यौरा देखें: उस टीएलएस सर्टिफ़िकेट का पाथ डालें जिस पर सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.
--tls_client_certificate=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इस्तेमाल किए जाने वाले टीएलएस क्लाइंट सर्टिफ़िकेट के बारे में बताएं. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इस्तेमाल की जाने वाली टीएलएस क्लाइंट कुंजी के बारे में बताएं. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
--ui_actions_shown=<an integer> default: "8": डिटेल वाले प्रोग्रेस बार में एक साथ की जा रही कार्रवाइयों की संख्या दिखाई जाती है. हर कार्रवाई को अलग लाइन में दिखाया जाता है. प्रोग्रेस बार में हमेशा कम से कम एक दिखता है. साथ ही, एक से कम सभी संख्याओं को एक पर मैप किया जाता है.
टैग: terminal_output
--[no]watchfs डिफ़ॉल्ट: "false": Linux/macOS पर: अगर यह विकल्प सही पर सेट है, तो Bazel, हर फ़ाइल को स्कैन करने के बजाय, स्थानीय बदलावों के लिए ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करता है. Windows पर: फ़िलहाल, यह फ़्लैग काम नहीं करता है. हालांकि, इसे --experimental_windows_watchfs के साथ चालू किया जा सकता है. किसी भी ओएस पर: अगर आपका वर्कस्पेस किसी नेटवर्क फ़ाइल सिस्टम पर है और फ़ाइलों में बदलाव किसी रिमोट मशीन पर किया जाता है, तो यह तय नहीं किया जा सकता कि फ़ाइलें कैसे सेव होंगी.

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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

--dump=<text or raw> [-d] डिफ़ॉल्ट: ब्यौरा देखें: पूरी प्रोफ़ाइल का डेटा डंप करें. इसे ऐसे 'टेक्स्ट' फ़ॉर्मैट में डंप करें जिसे कोई भी व्यक्ति आसानी से पढ़ सके या स्क्रिप्ट के हिसाब से 'रॉ' फ़ॉर्मैट में डंप करें.
टैग: affects_outputs
--[no]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

Aquery के विकल्प

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--aspect_deps=<off, conservative or precise> default: "conservative": आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक होने पर, आसपेक्ट डिपेंडेंसी की समस्या कैसे हल करें. 'off' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'conservative' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी का नियम क्लास दिया गया हो या नहीं. 'precise' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हैं. ध्यान दें कि सटीक मोड में, एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह विश्लेषण के चरण में तय किया जाता है. यह चरण, 'bazel query' के दौरान नहीं चलता है.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के हिसाब से रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: 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 डिफ़ॉल्ट: "false": FileWrite, SourceSymlinkManifest, और RepoMappingManifest कार्रवाइयों के लिए फ़ाइल का कॉन्टेंट शामिल करें. यह कॉन्टेंट बड़ा हो सकता है.
टैग: terminal_output
--[no]include_param_files डिफ़ॉल्ट: "false": कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें. यह कॉन्टेंट बड़ा हो सकता है. ध्यान दें: इस फ़्लैग को चालू करने पर, --include_commandline फ़्लैग अपने-आप चालू हो जाएगा.
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash default: "true": अगर यह विकल्प चालू है, तो package_group एट्रिब्यूट के `packages` एट्रिब्यूट की वैल्यू देते समय, शुरुआती `//` को नहीं हटाया जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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
--[no]proto:default_values default: "true": अगर यह वैल्यू सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह वैल्यू गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प, --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "false": definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, हर नियम इंस्टेंस के लिए Starlark कॉल स्टैक को रिकॉर्ड करता है. यह रिकॉर्डिंग, नियम की क्लास तय किए जाने के समय की जाती है.
टैग: terminal_output
--[no]proto:flatten_selects default: "true": इस विकल्प को चालू करने पर, select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किया गया डेटा एक ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू ठीक एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "false": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, वह सोर्स ऐस्पेक्ट डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स ऐस्पेक्ट से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "false": $internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "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_inputs_and_outputs default: "true": rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output
--query_file=<a string> default: "": अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "false": अगर यह 'सही है', तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह की जानकारी रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह अलग-अलग मशीनों पर एक जैसा नहीं होता. इस विकल्प को true पर सेट करके, सभी मशीनों पर एक जैसा नतीजा पाया जा सकता है.
टैग: terminal_output
--[no]skyframe_state डिफ़ॉल्ट: "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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है

--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "false": सिमलिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false": वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution
--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, नए स्पॉन में टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग चलाएगा.
टैग: execution
--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false": इस विकल्प के चालू होने पर, फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> default: "": कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, 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 डिफ़ॉल्ट: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. टेस्ट एक्ज़ेक ग्रुप का नहीं.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_crosstool_top=<a build target label> default: "//external:android/crosstool": Android बिल्ड के लिए इस्तेमाल किए गए C++ कंपाइलर की जगह.
टैग: affects_outputs, changes_inputs, loading_and_analysis, loses_incremental_state
--android_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: Android का टारगेट grte_top.
टैग: changes_inputs, 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
--android_sdk=<a build target label> default: "@bazel_tools//tools/android:sdk": इससे उस Android SDK/प्लैटफ़ॉर्म के बारे में पता चलता है जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: 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
--crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain": C++ कोड को कंपाइल करने के लिए इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs
--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 डिफ़ॉल्ट: "false": अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution
--[no]experimental_prefer_mutual_xcode default: "true": अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए Xcode के लोकल वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state
--extra_execution_platforms=<comma-separated list of options> default: "": कार्रवाइयां करने के लिए उपलब्ध प्लैटफ़ॉर्म. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. register_execution_platforms() में बताए गए प्लैटफ़ॉर्म से पहले, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, पहले के फ़्लैग की सेटिंग को बदल देंगे.
टैग: 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> डिफ़ॉल्ट: ब्यौरा देखें: होस्ट कंपाइलेशन के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top सेट नहीं है, तो इसे अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, execution
--host_crosstool_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: डिफ़ॉल्ट रूप से, --crosstool_top और --compiler विकल्पों का इस्तेमाल, exec कॉन्फ़िगरेशन के लिए भी किया जाता है. यह फ़्लैग देने पर, Bazel दिए गए crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग: loading_and_analysis, changes_inputs, affects_outputs
--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> default: "@local_config_platform//:host": यह प्लैटफ़ॉर्म के नियम का लेबल है. इससे होस्ट सिस्टम के बारे में जानकारी मिलती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[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_android_toolchain_resolution default: "true": Android के नियमों (Starlark और नेटिव) के लिए Android SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false": ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone default: "true": अगर यह विकल्प सही है, तो Bazel, एलटीओ इंडेक्सिंग कमांड लाइनों के लिए, C++ लिंक ऐक्शन कमांड लाइनों का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग: 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_require_ctx_in_configure_features default: "true": अगर यह सही है, तो Bazel को cc_common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 देखें.
टैग: loading_and_analysis, 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 relative path> default: "": यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य Workspace रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, वर्कस्पेस के रूट फ़ोल्डर में मौजूद होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--platforms=<a build target label> default: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python2_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अब इस्तेमाल नहीं किया जा सकता. यह `--incompatible_use_python_toolchains` से बंद है.
टैग: no_op, deprecated
--python3_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अब इस्तेमाल नहीं किया जा सकता. यह `--incompatible_use_python_toolchains` से बंद है.
टैग: no_op, deprecated
--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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_proto_extra_actions डिफ़ॉल्ट: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state डिफ़ॉल्ट: "false": कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> डिफ़ॉल्ट: "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]legacy_external_runfiles default: "true": अगर यह सही है, तो .runfiles/repo के अलावा, .runfiles/wsname/external/repo में बाहरी रिपॉज़िटरी के लिए, रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap डिफ़ॉल्ट: "false": यह तय करता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps डिफ़ॉल्ट: "false": अगर यह विकल्प सेट किया जाता है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन के साथ कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--android_cpu=<a string> default: "armeabi-v7a": Android का टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]android_databinding_use_androidx default: "true": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग 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 यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. '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 डिफ़ॉल्ट: "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
टैग: affects_outputs
--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ऐसी सूची जिसमें Apple Catalyst बाइनरी बनाने के लिए, आर्किटेक्चर को कॉमा लगाकर अलग किया गया हो.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage डिफ़ॉल्ट: "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 यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_fdo_profile_absolute_path default: "true": अगर इसे सेट किया जाता है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: 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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर ऐसा तय किया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs
--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1": इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines
--[no]experimental_omitfp डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "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
--fat_apk_cpu=<comma-separated set of options> default: "armeabi-v7a": इस विकल्प को सेट करने से फ़ैट APK चालू हो जाते हैं.इनमें टारगेट किए गए सभी आर्किटेक्चर के लिए नेटिव बाइनरी होती हैं. उदाहरण के लिए, --fat_apk_cpu=x86,armeabi-v7a. अगर इस फ़्लैग को सेट किया जाता है, तो android_binary नियमों की डिपेंडेंसी के लिए --android_cpu को अनदेखा कर दिया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]fat_apk_hwasan डिफ़ॉल्ट: "false": HWASAN स्प्लिट बनाने हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--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 डिफ़ॉल्ट: "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> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों (C++ नहीं) को कंपाइल करते समय, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टूल के लिए, 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
--host_swiftcopt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ीक्यूशन टूल के लिए, swiftc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूल चेन के लिए, exec ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `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]incompatible_use_host_features default: "true": अगर सही है, तो टारगेट कॉन्फ़िगरेशन के लिए सिर्फ़ --features और एक्ज़ेक कॉन्फ़िगरेशन के लिए --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change
--[no]instrument_test_targets डिफ़ॉल्ट: "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> कई बार इस्तेमाल किया गया हो: एलटीओ बैकएंड के चरण में पास करने के लिए अतिरिक्त विकल्प (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 डिफ़ॉल्ट: "false": अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "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 फ़ाइलों के LTO बैकएंड कमांड लाइन में -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 डिफ़ॉल्ट: "false": बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.
टैग: 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
--swiftcopt=<a string> कई बार इस्तेमाल किया गया हो: Swift कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines
--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

--auto_cpu_environment_group=<a build target label> default: "": environment_group की जानकारी दें, ताकि सीपीयू वैल्यू को target_environment वैल्यू पर अपने-आप मैप किया जा सके.
टैग: changes_inputs, loading_and_analysis, experimental
--[no]check_licenses डिफ़ॉल्ट: "false": जांच करें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह विकल्प बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]desugar_for_android default: "true": Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs डिफ़ॉल्ट: "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=<off, warning or error> डिफ़ॉल्ट: "बंद है": इस विकल्प को चालू करने पर, यह जांच की जाती है कि aar_import की डिपेंडेंसी पूरी हो गई हैं या नहीं. इस नीति के उल्लंघन को ठीक करने के लिए, बिल्ड को रोका जा सकता है या सिर्फ़ चेतावनियां दिखाई जा सकती हैं.
टैग: 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 डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "false": इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false": यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "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]incompatible_validate_top_level_header_inclusions default: "true": अगर यह सही है, तो Bazel टॉप लेवल की डायरेक्ट्री के हेडर को भी शामिल करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 देखें.
टैग: loading_and_analysis, incompatible_change
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: --incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis
--[no]strict_filesets डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह वैल्यू 'सही है' पर सेट है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "environment" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: 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 पर साइन करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.
टैग: action_command_lines

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

--[no]allow_analysis_failures डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर dex2oat की कार्रवाई पूरी नहीं होती है, तो टेस्ट के दौरान dex2oat को लागू करने के बजाय, बिल्ड को ब्रेक कर दिया जाएगा.
टैग: loading_and_analysis, experimental
--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false": android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks डिफ़ॉल्ट: "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> default: "-1": टेस्ट के टाइम आउट के लिए, टेस्ट के टाइम आउट की डिफ़ॉल्ट वैल्यू (सेकंड में) बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करने के लिए कहा जाता है.
--[no]zip_undeclared_test_outputs default: "true": अगर यह वैल्यू सही है, तो बिना बताए गए टेस्ट के आउटपुट को ZIP फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

--aspect_deps=<off, conservative or precise> default: "conservative": आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक होने पर, आसपेक्ट डिपेंडेंसी की समस्या कैसे हल करें. 'off' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'conservative' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी का नियम क्लास दिया गया हो या नहीं. 'precise' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हैं. ध्यान दें कि सटीक मोड में, एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह विश्लेषण के चरण में तय किया जाता है. यह चरण, 'bazel query' के दौरान नहीं चलता है.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के हिसाब से रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: 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 डिफ़ॉल्ट: "false": FileWrite, SourceSymlinkManifest, और RepoMappingManifest कार्रवाइयों के लिए फ़ाइल का कॉन्टेंट शामिल करें. यह कॉन्टेंट बड़ा हो सकता है.
टैग: terminal_output
--[no]include_param_files डिफ़ॉल्ट: "false": कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें. यह कॉन्टेंट बड़ा हो सकता है. ध्यान दें: इस फ़्लैग को चालू करने पर, --include_commandline फ़्लैग अपने-आप चालू हो जाएगा.
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash default: "true": अगर यह विकल्प चालू है, तो package_group एट्रिब्यूट के `packages` एट्रिब्यूट की वैल्यू देते समय, शुरुआती `//` को नहीं हटाया जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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
--[no]proto:default_values default: "true": अगर यह वैल्यू सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह वैल्यू गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प, --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "false": definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, हर नियम इंस्टेंस के लिए Starlark कॉल स्टैक को रिकॉर्ड करता है. यह रिकॉर्डिंग, नियम की क्लास तय किए जाने के समय की जाती है.
टैग: terminal_output
--[no]proto:flatten_selects default: "true": इस विकल्प को चालू करने पर, select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किया गया डेटा एक ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू ठीक एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "false": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, वह सोर्स ऐस्पेक्ट डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स ऐस्पेक्ट से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "false": $internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "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_inputs_and_outputs default: "true": rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output
--query_file=<a string> default: "": अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "false": अगर यह 'सही है', तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह की जानकारी रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह अलग-अलग मशीनों पर एक जैसा नहीं होता. इस विकल्प को true पर सेट करके, सभी मशीनों पर एक जैसा नतीजा पाया जा सकता है.
टैग: terminal_output
--[no]skyframe_state डिफ़ॉल्ट: "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_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false": ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास हटाई जा सकें.
टैग: action_command_lines
--[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_objc_include_scanning डिफ़ॉल्ट: "false": Whether to perform include scanning for objective C/C++.
टैग: loading_and_analysis, execution, changes_inputs
--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "false": इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए, टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट नहीं किए गए नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू 'गलत है' पर सेट है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state
--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "false": यह नीति चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false": क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs
--[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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह वैल्यू सही है, तो Blaze पहली बार टेस्ट के सफल होने पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false": अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false": अगर सही है, तो clang के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_j2objc_header_map default: "true": J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "false": हेडर पाथ को छोटा करके जनरेट करना है या नहीं. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel> default: "javabuilder": इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.
--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "false": --experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs
--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "false": java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs
--[no]explicit_java_test_deps डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> default: "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
--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 डिफ़ॉल्ट: "false": अगर यह विकल्प चुना जाता है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.
--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का पूरा पाथ. अगर इस विकल्प को सेट नहीं किया गया है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन (जो Bazel सर्वर शुरू करता है) पर सेट किया गया है, तो Bazel इसका इस्तेमाल करता है. अगर दोनों में से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel चलता है (Windows: c:/tools/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> default: "-1": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast डिफ़ॉल्ट: "false": यह विकल्प, टेस्ट रनर को फ़ॉरवर्ड करने में तुरंत मदद करता है. टेस्ट रनर को पहली गड़बड़ी होने पर ही बंद हो जाना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "explicit": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'explicit' का इस्तेमाल सिर्फ़ तब करें, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'disabled' को कभी भी टेस्ट शार्डिंग का इस्तेमाल न करने के लिए सेट करें. 'forced=k' का इस्तेमाल करके, 'shard_count' BUILD एट्रिब्यूट की परवाह किए बिना, टेस्टिंग के लिए 'k' शार्ड लागू करें.
--tool_java_language_version=<a string> default: "": बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया गया Java भाषा का वर्शन
--tool_java_runtime_version=<a string> default: "remotejdk_11": बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इंक्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

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

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

--[no]check_up_to_date डिफ़ॉल्ट: "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 रणनीति का इस्तेमाल करके चलाया जाता है. अगर कोई नेमोनिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी नेमोनिक के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `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") डालें जिसका इस्तेमाल, डॉकर रणनीति का इस्तेमाल करते समय सैंडबॉक्स किए गए ऐक्शन को लागू करने के लिए किया जाना चाहिए. साथ ही, ऐक्शन में प्लैटफ़ॉर्म के ब्यौरे में मौजूद 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 डिफ़ॉल्ट: "false": Docker पर आधारित सैंडबॉक्सिंग चालू करें. अगर Docker इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: 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_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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो रूट को माउंट न करें. सिर्फ़ sandbox_add_mount_pair के साथ दी गई चीज़ों को माउंट करें. इनपुट फ़ाइलों को सैंडबॉक्स से सिंक करने के बजाय, सैंडबॉक्स से हार्डलिंक किया जाएगा. अगर ऐक्शन इनपुट फ़ाइलें, सैंडबॉक्स से अलग फ़ाइल सिस्टम पर मौजूद हैं, तो इनपुट फ़ाइलों को कॉपी किया जाएगा.
टैग: execution
--[no]experimental_use_semaphore_for_jobs डिफ़ॉल्ट: "false": अगर इसे सही पर सेट किया जाता है, तो एक साथ चलने वाले जॉब की संख्या को सीमित करने के लिए, सेमाफ़ोर का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution
--[no]experimental_use_windows_sandbox डिफ़ॉल्ट: "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_as_resource default: "true": यह कोई कार्रवाई नहीं करता. इसे जल्द ही हटा दिया जाएगा.
टैग: no_op
--[no]experimental_worker_cancellation डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": इस फ़्लैग को चालू करने पर, मल्टीप्लेक्स वर्कर को सैंडबॉक्स किया जाएगा. इसके लिए, हर वर्क अनुरोध के हिसाब से अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल किया जाएगा. सिर्फ़ उन वर्कर को सैंडबॉक्स किया जाएगा जिनके लिए, 'supports-multiplex-sandboxing' एक्ज़ीक्यूशन की ज़रूरी शर्त पूरी होती है.
टैग: execution
--[no]experimental_worker_sandbox_hardening डिफ़ॉल्ट: "false": इस सेटिंग के चालू होने पर, वर्कर को एक सुरक्षित सैंडबॉक्स में चलाया जाता है. हालांकि, ऐसा तब ही किया जाता है, जब लागू करने की प्रोसेस इसकी अनुमति देती हो.
टैग: execution
--[no]experimental_worker_strict_flagfiles डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो वर्कर के लिए ऐसे ऐक्शन आर्ग्युमेंट इस्तेमाल करने पर गड़बड़ी होगी जो वर्कर के स्पेसिफ़िकेशन के मुताबिक नहीं हैं. वर्कर आर्ग्युमेंट में, आर्ग्युमेंट की सूची के आखिर में सिर्फ़ एक @flagfile आर्ग्युमेंट होना चाहिए.
टैग: execution
--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations
--genrule_strategy=<comma-separated list of options> default: "": बताएं कि जनरूल को कैसे लागू करना है. इस फ़्लैग को धीरे-धीरे हटाया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरूल को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution
--high_priority_workers=<a string> कई बार इस्तेमाल किया गया हो: यह कोई कार्रवाई नहीं करता. इसे जल्द ही हटा दिया जाएगा.
टैग: execution
--[no]incompatible_remote_dangling_symlinks default: "true": अगर इसे सही पर सेट किया जाता है और --incompatible_remote_symlinks को भी सही पर सेट किया जाता है, तो ऐक्शन आउटपुट में मौजूद सिंबल लिंक को डैंगल होने की अनुमति होती है.
टैग: execution, incompatible_change
--[no]incompatible_remote_symlinks default: "true": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैशिंग/एक्ज़ीक्यूशन प्रोटोकॉल में ऐक्शन आउटपुट में सिमलंक को इस तरह से दिखाएगा. ऐसा न होने पर, सिमलंक को फ़ॉलो किया जाएगा और उन्हें फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए, #6631 देखें.
टैग: execution, incompatible_change
--[no]incompatible_sandbox_hermetic_tmp default: "true": इस विकल्प को सही पर सेट करने पर, हर Linux सैंडबॉक्स में अपनी खाली डायरेक्ट्री होगी. इसे होस्ट फ़ाइल सिस्टम के साथ /tmp शेयर करने के बजाय, /tmp के तौर पर माउंट किया जाएगा. सभी सैंडबॉक्स में होस्ट के/tmp को देखने के लिए, --sandbox_add_mount_pair=/tmp का इस्तेमाल करें.
टैग: execution
--[no]internal_spawn_scheduler डिफ़ॉल्ट: "false": यह प्लेसहोल्डर विकल्प है, ताकि हम 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 डिफ़ॉल्ट: "false": सैंडबॉक्स की गई कार्रवाइयों के लिए, साफ़ तौर पर स्यूडो टर्मिनल बनाने की सुविधा चालू करें. कुछ Linux डिस्ट्रिब्यूशन में, सैंडबॉक्स के अंदर प्रोसेस का ग्रुप आईडी 'tty' पर सेट करना ज़रूरी होता है, ताकि स्यूडोटर्मिनल काम कर सकें. अगर इसकी वजह से समस्याएं आ रही हैं, तो इस फ़्लैग को बंद किया जा सकता है, ताकि अन्य ग्रुप का इस्तेमाल किया जा सके.
टैग: execution
--sandbox_tmpfs_path=<an absolute path> कई बार इस्तेमाल किया गया हो: सैंडबॉक्स की गई कार्रवाइयों के लिए, इस ऐब्सलूट पाथ पर एक खाली डायरेक्ट्री माउंट करें. ऐसा तब करें, जब सैंडबॉक्सिंग लागू करने की सुविधा उपलब्ध हो. अगर यह सुविधा उपलब्ध नहीं है, तो इसे अनदेखा कर दिया जाएगा.
टैग: host_machine_resource_optimizations, execution
--[no]skip_incompatible_explicit_targets डिफ़ॉल्ट: "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"> कई बार इस्तेमाल किया गया हो: अगर 'वर्कर' रणनीति का इस्तेमाल किया जाता है, तो हर तरह के परसिस्टेंट वर्कर के कितने इंस्टेंस लॉन्च किए जा सकते हैं. इसे [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 डिफ़ॉल्ट: "false": इस विकल्प के चालू होने पर, बिल्ड पूरा होने के बाद सभी वर्कर बंद हो जाते हैं.
टैग: execution, host_machine_resource_optimizations
--[no]worker_sandboxing डिफ़ॉल्ट: "false": इसे चालू करने पर, वर्कर को सैंडबॉक्स वाले एनवायरमेंट में लागू किया जाएगा.
टैग: execution
--[no]worker_verbose डिफ़ॉल्ट: "false": चालू होने पर, वर्कर शुरू होने, बंद होने वगैरह के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करता है...

--target_platform_fallback=<a string> default: "": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]build default: "true": बिल्ड को एक्ज़ीक्यूट करें. यह सामान्य प्रोसेस है. --nobuild विकल्प का इस्तेमाल करने पर, बिल्ड की प्रोसेस, बिल्ड ऐक्शन को लागू करने से पहले ही रुक जाती है. अगर पैकेज लोड करने और विश्लेषण करने के चरण पूरे हो जाते हैं, तो यह विकल्प शून्य दिखाता है. यह मोड, इन चरणों की जांच करने के लिए काम आता है.
टैग: execution, affects_outputs
--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "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

--aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: टॉप-लेवल के टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा लगाकर अलग की गई लिस्ट. अगर सूची में शामिल कुछ_आस्पेक्ट, ज़रूरी_आस्पेक्ट_प्रोवाइडर के ज़रिए ज़रूरी आस्पेक्ट प्रोवाइडर तय करता है, तो कुछ_आस्पेक्ट, सूची में शामिल हर उस आस्पेक्ट के बाद चलेगा जिसके विज्ञापन देने वाले प्रोवाइडर, कुछ_आस्पेक्ट के ज़रूरी आस्पेक्ट प्रोवाइडर की ज़रूरी शर्तों को पूरा करते हैं. इसके अलावा, 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> default: "-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 डिफ़ॉल्ट: "false": यह फ़्लैग कंट्रोल करता है कि हम 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 डिफ़ॉल्ट: "false": इस विकल्प के चालू होने पर, Bazel, कार्रवाइयां करते समय 'docker run' को --privileged फ़्लैग पास करेगा. यह आपके बिल्ड के लिए ज़रूरी हो सकता है. हालांकि, इससे हर्मेटिकनेस कम हो सकता है.
टैग: execution
--[no]experimental_sandboxfs_map_symlink_targets डिफ़ॉल्ट: "false": No-op
टैग: host_machine_resource_optimizations, execution
--[no]incompatible_legacy_local_fallback डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग: execution
--[no]sandbox_fake_username डिफ़ॉल्ट: "false": सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'nobody' में बदलें.
टैग: execution
--sandbox_writable_path=<a string> कई बार इस्तेमाल किया गया हो: सैंडबॉक्स की गई कार्रवाइयों के लिए, सैंडबॉक्स में मौजूद किसी डायरेक्ट्री को लिखने लायक बनाएं. अगर सैंडबॉक्सिंग लागू करने की सुविधा काम करती है, तो इसे अनदेखा किया जाएगा.
टैग: execution

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "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]check_tests_up_to_date डिफ़ॉल्ट: "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' के लिए, बुनियादी अस्थायी डायरेक्ट्री के बारे में बताता है.

--[no]experimental_parallel_aquery_output default: "true": कोई कार्रवाई नहीं.

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers> डिफ़ॉल्ट: ब्यौरा देखें: यह ओएस सिग्नल नंबर की सूची लेता है. अगर डाइनैमिक एक्ज़ीक्यूशन की कोई लोकल ब्रांच, इनमें से किसी भी सिग्नल की वजह से बंद हो जाती है, तो रिमोट ब्रांच को पूरा होने दिया जाएगा. पर्सिस्टेंट वर्कर के लिए, इससे सिर्फ़ उन सिग्नल पर असर पड़ता है जो वर्कर प्रोसेस को बंद कर देते हैं.
टैग: execution
--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
--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 (उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, Bazel ("HOST_RAM*.67") उपलब्ध रैम का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन के बारे में क्वेरी करेगा. साथ ही, उपलब्ध रैम का 67% इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]debug_spawn_scheduler डिफ़ॉल्ट: "false"
--[no]experimental_bep_target_summary डिफ़ॉल्ट: "false": TargetSummary इवेंट पब्लिश करने हैं या नहीं.
--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय BEP में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में Fileset के सभी रिलेटिव सिंबल लिंक पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets विकल्प की ज़रूरत होती है.
टैग: affects_outputs
--experimental_build_event_upload_max_retries=<an integer> default: "4": Bazel को बिल्ड इवेंट अपलोड करने की कोशिश ज़्यादा से ज़्यादा कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s": बीईपी अपलोड करने में गड़बड़ी होने पर, एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने के लिए, शुरुआती और कम से कम देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इससे यह चुना जाता है कि बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को कैसे अपलोड करना है.
टैग: affects_outputs
--[no]experimental_collect_local_sandbox_action_metrics default: "true": अब काम नहीं करता.
टैग: execution
--[no]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_docker_verbose डिफ़ॉल्ट: "false": अगर यह विकल्प चालू है, तो Bazel, Docker सैंडबॉक्स की रणनीति के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करेगा.
टैग: execution
--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "false": अगर पैरामीटर फ़ाइलों को मटीरियलाइज़ किया जा रहा है, तो उन्हें सीधे डिस्क में लिखें.
टैग: execution
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string> default: "": अगर यह फ़ील्ड खाली नहीं है, तो उन सभी Starlark रिपॉज़िटरी नियमों की हल की गई जानकारी के साथ एक Starlark वैल्यू लिखें जिन्हें लागू किया गया था.
टैग: affects_outputs
--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "false": क्या रन बिल्ड इवेंट में कमांड-लाइन के बचे हुए हिस्से को शामिल करना है. इसमें बचा हुआ हिस्सा शामिल हो सकता है. डिफ़ॉल्ट रूप से, रन कमांड के बिल्ड इवेंट में बचे हुए डेटा को शामिल नहीं किया जाता. हालांकि, इसमें बचे हुए डेटा को शामिल किया जा सकता है.
टैग: affects_outputs
--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "false": स्ट्रीम लॉग फ़ाइलें, डिस्क पर सेव करने के बजाय सीधे रिमोट स्टोरेज पर अपलोड करता है.
टैग: affects_outputs
--explain=<a path> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प का इस्तेमाल करने पर, बिल्ड सिस्टम, बिल्ड के हर चरण के बारे में जानकारी देता है. वजह को तय की गई लॉग फ़ाइल में लिखा जाता है.
टैग: affects_outputs
--[no]ignore_unsupported_sandboxing डिफ़ॉल्ट: "false": अगर इस सिस्टम पर सैंडबॉक्स किए गए एक्ज़ीक्यूशन की सुविधा मौजूद नहीं है, तो चेतावनी न दिखाएं.
टैग: terminal_output
--[no]legacy_important_outputs default: "true": इसका इस्तेमाल, TargetComplete इवेंट में लेगसी important_outputs फ़ील्ड के जनरेशन को रोकने के लिए करें. Bazel को ResultStore के साथ इंटिग्रेट करने के लिए, important_outputs ज़रूरी हैं.
टैग: affects_outputs
--[no]materialize_param_files डिफ़ॉल्ट: "false": यह रिमोट ऐक्शन एक्ज़ीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें लिखता है. कार्रवाइयों को डीबग करते समय यह काम का होता है. यह --subcommands और --verbose_failures से पता चलता है.
टैग: execution
--max_config_changes_to_show=<an integer> default: "3": बिल्ड के विकल्पों में बदलाव होने की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नाम की दी गई संख्या तक दिखाता है. अगर दी गई संख्या -1 है, तो बदले गए सभी विकल्प दिखेंगे.
टैग: terminal_output
--max_test_output_bytes=<an integer> default: "-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 डिफ़ॉल्ट: "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> default: "short": इस एट्रिब्यूट की वैल्यू से, टेस्ट के नतीजों के लिए मनचाहा फ़ॉर्मैट तय किया जाता है. मान्य वैल्यू ये हैं: 'short' का इस्तेमाल सिर्फ़ उन टेस्ट के बारे में जानकारी प्रिंट करने के लिए किया जाता है जिन्हें पूरा किया गया है, 'terse' का इस्तेमाल सिर्फ़ उन टेस्ट के बारे में जानकारी प्रिंट करने के लिए किया जाता है जिन्हें पूरा नहीं किया जा सका, 'detailed' का इस्तेमाल उन टेस्ट केस के बारे में पूरी जानकारी प्रिंट करने के लिए किया जाता है जो पूरे नहीं किए जा सके, 'testcase' का इस्तेमाल टेस्ट केस के रिज़ॉल्यूशन में खास जानकारी प्रिंट करने के लिए किया जाता है. इससे उन टेस्ट केस के बारे में पूरी जानकारी प्रिंट नहीं होती जिन्हें पूरा नहीं किया जा सका. 'none' का इस्तेमाल खास जानकारी को हटाने के लिए किया जाता है.
टैग: terminal_output
--[no]verbose_explanations डिफ़ॉल्ट: "false": अगर --explain विकल्प चालू है, तो इससे जवाब में ज़्यादा जानकारी मिलती है. अगर --explain विकल्प चालू नहीं है, तो इसका कोई असर नहीं होगा.
टैग: affects_outputs
--[no]verbose_failures डिफ़ॉल्ट: "false": अगर कोई निर्देश काम नहीं करता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

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

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: ब्यौरा देखें: यह बताता है कि सर्किट ब्रेकर को किस रणनीति का इस्तेमाल करना है. उपलब्ध रणनीतियां "failure" हैं. विकल्प के लिए अमान्य वैल्यू होने पर, विकल्प सेट न होने पर जैसा व्यवहार होता है वैसा ही व्यवहार होता है.
टैग: execution
--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "false": इस विकल्प को बंद करने पर, रिमोट कैश में किसी कार्रवाई को अपलोड करने से पहले, इनपुट फ़ाइलों के सीटाइम की जांच नहीं की जाएगी. ऐसा हो सकता है कि कुछ मामलों में Linux कर्नल, फ़ाइलों को लिखने में देरी करे. इससे फ़ॉल्स पॉज़िटिव मिल सकते हैं.
--[no]experimental_remote_cache_async डिफ़ॉल्ट: "false": अगर यह वैल्यू सही है, तो रिमोट कैश मेमोरी I/O, स्पॉन के हिस्से के तौर पर होने के बजाय बैकग्राउंड में होगा.
--experimental_remote_cache_eviction_retries=<an integer> default: "0": अगर बिल्ड को रिमोट कैश हटाने से जुड़ी गड़बड़ी का सामना करना पड़ता है, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. शून्य से अलग वैल्यू सेट करने पर, --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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर इसे सही पर सेट किया जाता है, तो 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 डिफ़ॉल्ट: "false": अगर रिमोट डाउनलोडर काम नहीं करता है, तो लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.
--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "false": रिमोट तरीके से एक्ज़ीक्यूट करने के लिए, कीपअलाइव का इस्तेमाल करना है या नहीं.
--experimental_remote_failure_rate_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर्सिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "false": अगर इस नीति को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने के लिए, मर्कल ट्री के कैलकुलेशन को मेमोराइज़ किया जाएगा. कैश मेमोरी के फ़ुटप्रिंट को --experimental_remote_merkle_tree_cache_size कंट्रोल करता है.
--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000": रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने के लिए, मेमोइज़ किए जाने वाले मर्कल ट्री की संख्या. Java, सॉफ्ट रेफ़रंस को मैनेज करता है. इसके हिसाब से, कैश अपने-आप कम हो जाती है. हालांकि, अगर कैश का साइज़ बहुत ज़्यादा सेट किया गया है, तो मेमोरी से जुड़ी गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड होता है. सबसे सही वैल्यू, प्रोजेक्ट के साइज़ के हिसाब से अलग-अलग होती है. डिफ़ॉल्ट वैल्यू 1,000 होती है.
--[no]experimental_remote_require_cached डिफ़ॉल्ट: "false": अगर इसे 'चालू है' पर सेट किया जाता है, तो यह ज़रूरी हो जाता है कि रिमोटली की जा सकने वाली सभी कार्रवाइयों को कैश मेमोरी में सेव किया जाए. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह सुविधा, नॉन-डिटरमिनिज़्म से जुड़ी समस्याओं को हल करने में मददगार होती है. इससे यह जांच की जा सकती है कि जिन कार्रवाइयों को कैश मेमोरी में सेव किया जाना चाहिए उन्हें कैश मेमोरी में सेव किया गया है या नहीं. साथ ही, यह भी जांच की जा सकती है कि कैश मेमोरी में नए नतीजे तो नहीं डाले गए हैं.
--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: ब्यौरा देखें: यह दी गई कॉन्फ़िगरेशन फ़ाइल की मदद से, रिमोट कैश मेमोरी की कुंजी को मिटाने की सुविधा चालू करता है. यह फ़ाइल, टेक्स्ट फ़ॉर्मैट में ScrubbingConfig प्रोटोकॉल बफ़र होनी चाहिए. इस सुविधा का मकसद, अलग-अलग प्लैटफ़ॉर्म पर एक्ज़ीक्यूट की जा रही कार्रवाइयों के बीच रिमोट/डिस्क की कैश मेमोरी को शेयर करना है. हालांकि, ये कार्रवाइयां एक ही प्लैटफ़ॉर्म को टारगेट करती हैं. इसका इस्तेमाल बहुत सावधानी से करना चाहिए, क्योंकि गलत सेटिंग की वजह से कैश मेमोरी की एंट्री अनजाने में शेयर हो सकती हैं. इससे गलत बिल्ड बन सकते हैं. स्क्रबिंग से, कार्रवाई के तरीके पर कोई असर नहीं पड़ता. इससे सिर्फ़ यह तय होता है कि कार्रवाई के नतीजे को वापस पाने या सेव करने के लिए, रिमोट/डिस्क की कैश मेमोरी की कुंजी की गिनती कैसे की जाती है. इसका इस्तेमाल रिमोट एक्ज़ीक्यूशन के साथ नहीं किया जा सकता. स्क्रबिंग के कॉन्फ़िगरेशन में बदलाव करने से, लोकल फ़ाइल सिस्टम या इंटरनल कैश मेमोरी में मौजूद आउटपुट अमान्य नहीं होते. जिन कार्रवाइयों पर असर पड़ा है उन्हें फिर से लागू करने के लिए, क्लीन बिल्ड की ज़रूरत होती है. इस सुविधा का इस्तेमाल करने के लिए, आपको --host_platform को --experimental_platform_in_output_dir (आउटपुट प्रीफ़िक्स को सामान्य करने के लिए) और --incompatible_strict_action_env (एनवायरमेंट वैरिएबल को सामान्य करने के लिए) के साथ सेट करना होगा.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.
--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "false": अब काम नहीं करता. कोई कार्रवाई नहीं की जाती. इसके बजाय, --remote_build_event_upload=minimal का इस्तेमाल करें.
--[no]incompatible_remote_downloader_send_all_headers default: "true": क्या एक से ज़्यादा वैल्यू वाले हेडर की सभी वैल्यू, रिमोट डाउनलोडर को भेजनी हैं या सिर्फ़ पहली वैल्यू.
टैग: incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root डिफ़ॉल्ट: "false": अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट के हिसाब से तय किए जाते हैं.
टैग: incompatible_change
--[no]incompatible_remote_results_ignore_disk default: "true": No-op
टैग: incompatible_change
--[no]incompatible_remote_use_new_exit_code_for_lost_inputs default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, बिल्ड के दौरान रिमोट कैश मेमोरी से ब्लोब हटाने पर, एक्ज़िट कोड 34 के बजाय नया एक्ज़िट कोड 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> डिफ़ॉल्ट: ब्यौरा देखें: होस्टनेम और इंस्टेंस का नाम, जिसका इस्तेमाल bytestream:// यूआरआई में किया जाना है. ये यूआरआई, बिल्ड इवेंट स्ट्रीम में लिखे जाते हैं. इस विकल्प को तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इससे --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. इसे सेट न करने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.
--remote_cache=<a string> डिफ़ॉल्ट: ब्यौरा देखें: कैशिंग एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. टीएलएस को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://bazel.build/remote/caching देखें
--[no]remote_cache_compression डिफ़ॉल्ट: "false": इस सेटिंग के चालू होने पर, zstd का इस्तेमाल करके कैश मेमोरी के बड़े डेटा को कंप्रेस/डीकंप्रेस किया जाता है.
--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 string> कई बार इस्तेमाल किया गया हो: Bazel को उन आर्टफ़ैक्ट को डाउनलोड करने के लिए मजबूर करता है जो दिए गए रेगुलर एक्सप्रेशन से मेल खाते हैं. इसका इस्तेमाल, Build without the Bytes (या इसके इंटरनल वर्शन) के साथ किया जाता है.इससे क्लाइंट, कुछ ऐसे आर्टफ़ैक्ट का अनुरोध कर सकता है जिनकी ज़रूरत स्थानीय तौर पर पड़ सकती है. जैसे, आईडीई सपोर्ट. इस फ़्लैग को दोहराकर, कई रेगुलर एक्सप्रेशन तय किए जा सकते हैं.
टैग: 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 डिफ़ॉल्ट: "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> डिफ़ॉल्ट: "none": अगर --output_filter के बारे में नहीं बताया गया है, तो इस विकल्प की वैल्यू का इस्तेमाल करके फ़िल्टर अपने-आप बन जाता है. अनुमति वाली वैल्यू ये हैं: 'none' (किसी भी चीज़ को फ़िल्टर न करें / सब कुछ दिखाएं), 'all' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'packages' (Blaze कमांड लाइन पर बताए गए पैकेज में मौजूद नियमों से आउटपुट शामिल करें), और 'subpackages' ('packages' की तरह, लेकिन इसमें सबपैकेज भी शामिल हैं). 'packages' और 'subpackages' वैल्यू के लिए, //java/foo और //javatests/foo को एक पैकेज माना जाता है)'.
--[no]build_manual_tests डिफ़ॉल्ट: "false": 'मैन्युअल' के तौर पर टैग किए गए टेस्ट टारगेट को बनाने के लिए मजबूर करता है. 'मैन्युअल' टेस्ट को प्रोसेस से बाहर रखा जाता है. इस विकल्प से, उन्हें बनाया जा सकता है, लेकिन लागू नहीं किया जा सकता.
--build_tag_filters=<comma-separated list of options> default: "": कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. जिन टैग को शामिल नहीं करना है उन्हें तय करने के लिए, हर टैग से पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें कम से कम एक शामिल किया गया टैग हो और कोई भी बाहर रखा गया टैग न हो. इस विकल्प से, 'test' निर्देश के साथ लागू किए गए टेस्ट के सेट पर कोई असर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों से नियंत्रित होते हैं. उदाहरण के लिए, '--test_tag_filters'
--[no]build_tests_only डिफ़ॉल्ट: "false": अगर यह विकल्प चुना जाता है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.
--combined_report=<none or lcov> डिफ़ॉल्ट: "none": इससे, कवरेज की कुल रिपोर्ट का टाइप तय किया जाता है. फ़िलहाल, सिर्फ़ LCOV फ़ॉर्मैट काम करता है.
--[no]compile_one_dependency डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 के मुताबिक, सीमांकित किए गए स्पॉन प्रोटो के तौर पर लॉग करें. इससे जुड़े फ़्लैग: --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).
--execution_log_json_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें: एक्ज़ीक्यूट किए गए स्पॉन को इस फ़ाइल में लॉग करें. इसके लिए, src/main/protobuf/spawn.proto के मुताबिक, डीलिमिटेड स्पॉन प्रोटो को JSON के तौर पर दिखाएं. इससे जुड़े फ़्लैग: --execution_log_binary_file (बाइनरी protobuf फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).
--[no]execution_log_sort default: "true": यह तय करता है कि एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं, ताकि अलग-अलग इनवोकेशन के लॉग की तुलना करना आसान हो. इस विकल्प को false पर सेट करने से, इनवॉकेशन के आखिर में सीपीयू और मेमोरी का इस्तेमाल कम हो जाता है. हालांकि, इससे लॉग को नॉनडिटरमिनिस्टिक एक्ज़ीक्यूशन ऑर्डर में जनरेट किया जाता है.
--[no]expand_test_suites default: "true": विश्लेषण करने से पहले, test_suite के टारगेट को उनके कॉम्पोनेंट टेस्ट में बड़ा करें. इस फ़्लैग को चालू करने पर (डिफ़ॉल्ट रूप से), नेगेटिव टारगेट पैटर्न, टेस्ट सुइट से जुड़े टेस्ट पर लागू होंगे. ऐसा न करने पर, वे लागू नहीं होंगे. इस फ़्लैग को बंद करने से, कमांड लाइन पर टॉप-लेवल के पहलुओं को लागू करने में मदद मिलती है. इसके बाद, वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis
--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 डिफ़ॉल्ट: "false": अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. यह सिर्फ़ टॉप लेवल के टारगेट के लिए extra_actions शेड्यूल करता है.
--experimental_spawn_scheduler: कार्रवाइयों को स्थानीय और रिमोट तरीके से एक साथ चलाकर, डाइनैमिक तरीके से एक्ज़ीक्यूट करने की सुविधा चालू करें. Bazel, हर कार्रवाई को स्थानीय और रिमोट, दोनों जगहों पर शुरू करता है. इसके बाद, वह उस कार्रवाई को चुनता है जो सबसे पहले पूरी होती है. अगर किसी कार्रवाई के लिए वर्कर की ज़रूरत होती है, तो स्थानीय कार्रवाई को पर्सिस्टेंट वर्कर मोड में चलाया जाएगा. किसी कार्रवाई के लिए डाइनैमिक तरीके से एक्ज़ीक्यूशन की सुविधा चालू करने के लिए, `--internal_spawn_scheduler` और `--strategy=<mnemonic>=dynamic` फ़्लैग का इस्तेमाल करें.
बढ़कर यह हो जाता है:
--internal_spawn_scheduler
--spawn_strategy=dynamic
--[no]incompatible_dont_use_javasourceinfoprovider डिफ़ॉल्ट: "false": No-op
टैग: incompatible_change
--local_termination_grace_seconds=<an integer> default: "15": टाइम आउट की वजह से किसी लोकल प्रोसेस को बंद करने और उसे तुरंत बंद करने के बीच इंतज़ार करने का समय.
--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस के हिसाब से होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट इस्तेमाल किया जाता है.
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू होता है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.
--test_lang_filters=<comma-separated list of options> default: "": इसमें, टेस्ट की भाषाओं की कॉमा लगाकर अलग की गई सूची दी जाती है. हर भाषा से पहले '-' का इस्तेमाल करके, उन भाषाओं को तय किया जा सकता है जिन्हें शामिल नहीं करना है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जो बताई गई भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test नियम में भाषा के प्रीफ़िक्स के जैसा होना चाहिए. उदाहरण के लिए, 'cc', 'java', 'py' वगैरह. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.
--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]check_up_to_date डिफ़ॉल्ट: "false": बिल्ड न करें. बस यह देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड पूरा हो जाता है. अगर किसी चरण को पूरा करने में कोई गड़बड़ी होती है, तो इसकी सूचना दी जाती है और बिल्ड पूरा नहीं हो पाता.
टैग: execution
--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "false": सिमलिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false": वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution
--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, नए स्पॉन में टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग चलाएगा.
टैग: execution
--[no]experimental_split_xml_generation default: "true": अगर यह फ़्लैग सेट है और टेस्ट ऐक्शन से test.xml फ़ाइल जनरेट नहीं होती है, तो Bazel एक अलग ऐक्शन का इस्तेमाल करके, डमी test.xml फ़ाइल जनरेट करता है. इसमें टेस्ट लॉग शामिल होता है. ऐसा न होने पर, Bazel, टेस्ट ऐक्शन के हिस्से के तौर पर test.xml जनरेट करता है.
टैग: execution
--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false": इस विकल्प के चालू होने पर, फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution
--[no]experimental_use_semaphore_for_jobs डिफ़ॉल्ट: "false": अगर इसे सही पर सेट किया जाता है, तो एक साथ चलने वाले जॉब की संख्या को सीमित करने के लिए, सेमाफ़ोर का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution
--genrule_strategy=<comma-separated list of options> default: "": बताएं कि जनरूल को कैसे लागू करना है. इस फ़्लैग को धीरे-धीरे हटाया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरूल को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution
--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
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> default: "": कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, 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]skip_incompatible_explicit_targets डिफ़ॉल्ट: "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
--[no]use_target_platform_for_tests डिफ़ॉल्ट: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. टेस्ट एक्ज़ेक ग्रुप का नहीं.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_crosstool_top=<a build target label> default: "//external:android/crosstool": Android बिल्ड के लिए इस्तेमाल किए गए C++ कंपाइलर की जगह.
टैग: affects_outputs, changes_inputs, loading_and_analysis, loses_incremental_state
--android_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: Android का टारगेट grte_top.
टैग: changes_inputs, 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
--android_sdk=<a build target label> default: "@bazel_tools//tools/android:sdk": इससे उस Android SDK/प्लैटफ़ॉर्म के बारे में पता चलता है जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: 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
--crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain": C++ कोड को कंपाइल करने के लिए इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs
--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 डिफ़ॉल्ट: "false": अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution
--[no]experimental_prefer_mutual_xcode default: "true": अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए Xcode के लोकल वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state
--extra_execution_platforms=<comma-separated list of options> default: "": कार्रवाइयां करने के लिए उपलब्ध प्लैटफ़ॉर्म. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. register_execution_platforms() में बताए गए प्लैटफ़ॉर्म से पहले, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, पहले के फ़्लैग की सेटिंग को बदल देंगे.
टैग: 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> डिफ़ॉल्ट: ब्यौरा देखें: होस्ट कंपाइलेशन के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top सेट नहीं है, तो इसे अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, execution
--host_crosstool_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: डिफ़ॉल्ट रूप से, --crosstool_top और --compiler विकल्पों का इस्तेमाल, exec कॉन्फ़िगरेशन के लिए भी किया जाता है. यह फ़्लैग देने पर, Bazel दिए गए crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग: loading_and_analysis, changes_inputs, affects_outputs
--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> default: "@local_config_platform//:host": यह प्लैटफ़ॉर्म के नियम का लेबल है. इससे होस्ट सिस्टम के बारे में जानकारी मिलती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[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_android_toolchain_resolution default: "true": Android के नियमों (Starlark और नेटिव) के लिए Android SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false": ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone default: "true": अगर यह विकल्प सही है, तो Bazel, एलटीओ इंडेक्सिंग कमांड लाइनों के लिए, C++ लिंक ऐक्शन कमांड लाइनों का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग: 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_require_ctx_in_configure_features default: "true": अगर यह सही है, तो Bazel को cc_common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 देखें.
टैग: loading_and_analysis, 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 relative path> default: "": यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य Workspace रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, वर्कस्पेस के रूट फ़ोल्डर में मौजूद होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--platforms=<a build target label> default: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python2_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अब इस्तेमाल नहीं किया जा सकता. यह `--incompatible_use_python_toolchains` से बंद है.
टैग: no_op, deprecated
--python3_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अब इस्तेमाल नहीं किया जा सकता. यह `--incompatible_use_python_toolchains` से बंद है.
टैग: no_op, deprecated
--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 डिफ़ॉल्ट: "false": डीबग सिंबल (.dSYM) वाली फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build default: "true": बिल्ड को एक्ज़ीक्यूट करें. यह सामान्य प्रोसेस है. --nobuild विकल्प का इस्तेमाल करने पर, बिल्ड की प्रोसेस, बिल्ड ऐक्शन को लागू करने से पहले ही रुक जाती है. अगर पैकेज लोड करने और विश्लेषण करने के चरण पूरे हो जाते हैं, तो यह विकल्प शून्य दिखाता है. यह मोड, इन चरणों की जांच करने के लिए काम आता है.
टैग: execution, affects_outputs
--[no]build_runfile_links default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिंबल लिंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.
टैग: affects_outputs
--[no]build_runfile_manifests default: "true": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर ये गलत हैं, तो इन्हें शामिल न करें. इस विकल्प के गलत होने पर, स्थानीय जांच नहीं हो पाएंगी.
टैग: affects_outputs
--[no]build_test_dwp डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_proto_extra_actions डिफ़ॉल्ट: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state डिफ़ॉल्ट: "false": कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental
--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "false": जांच के साथ पैरलल में चलाने के लिए, पहलू का इस्तेमाल करके पुष्टि करने वाली कार्रवाइयां चलानी हैं या नहीं.
टैग: execution, affects_outputs
--fission=<a set of compilation modes> डिफ़ॉल्ट: "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]legacy_external_runfiles default: "true": अगर यह सही है, तो .runfiles/repo के अलावा, .runfiles/wsname/external/repo में बाहरी रिपॉज़िटरी के लिए, रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap डिफ़ॉल्ट: "false": यह तय करता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: 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
--[no]save_temps डिफ़ॉल्ट: "false": अगर यह विकल्प सेट किया जाता है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन के साथ कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--android_cpu=<a string> default: "armeabi-v7a": Android का टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]android_databinding_use_androidx default: "true": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग 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 यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. '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 डिफ़ॉल्ट: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: टॉप-लेवल के टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा लगाकर अलग की गई लिस्ट. अगर सूची में शामिल कुछ_आस्पेक्ट, ज़रूरी_आस्पेक्ट_प्रोवाइडर के ज़रिए ज़रूरी आस्पेक्ट प्रोवाइडर तय करता है, तो कुछ_आस्पेक्ट, सूची में शामिल हर उस आस्पेक्ट के बाद चलेगा जिसके विज्ञापन देने वाले प्रोवाइडर, कुछ_आस्पेक्ट के ज़रूरी आस्पेक्ट प्रोवाइडर की ज़रूरी शर्तों को पूरा करते हैं. इसके अलावा, requires एट्रिब्यूट के ज़रिए तय किए गए सभी ज़रूरी पहलुओं के बाद, some_aspect चलेगा. इसके बाद, some_aspect के पास उन पहलुओं के प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, उदाहरण के लिए '//tools:my_def.bzl%my_aspect'. इसमें 'my_aspect' एक टॉप-लेवल वैल्यू है, जो tools/my_def.bzl फ़ाइल से मिलती है
--[no]build_python_zip default: "auto": Build python executable zip; on on Windows, off on other platforms
टैग: affects_outputs
--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ऐसी सूची जिसमें Apple Catalyst बाइनरी बनाने के लिए, आर्किटेक्चर को कॉमा लगाकर अलग किया गया हो.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage डिफ़ॉल्ट: "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 यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_fdo_profile_absolute_path default: "true": अगर इसे सेट किया जाता है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: 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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर ऐसा तय किया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs
--[no]experimental_convenience_symlinks default: "normal": इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिए उपलब्ध सिमलंक (ऐसे सिमलंक जो बिल्ड के बाद वर्कस्पेस में दिखते हैं) को कैसे मैनेज किया जाएगा. संभावित वैल्यू: normal (डिफ़ॉल्ट): बिल्ड के हिसाब से, हर तरह के सुविधा वाले सिंबल लिंक बनाए या मिटाए जाएंगे. clean: सभी सिमलंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: सिंबॉलिक लिंक को अनदेखा किया जाएगा. log_only: इस मोड में, लॉग मैसेज जनरेट किए जाते हैं. ये मैसेज ऐसे होते हैं जैसे 'normal' मोड में जनरेट किए जाते हैं. हालाँकि, इस मोड में फ़ाइल सिस्टम से जुड़ी कोई कार्रवाई नहीं की जाती. यह मोड टूल के लिए फ़ायदेमंद होता है. ध्यान दें कि सिर्फ़ उन सिमलंक पर असर पड़ सकता है जिनके नाम, --symlink_prefix की मौजूदा वैल्यू से जनरेट होते हैं. अगर प्रीफ़िक्स बदलता है, तो पहले से मौजूद किसी भी सिमलंक पर कोई असर नहीं पड़ेगा.
टैग: affects_outputs
--[no]experimental_convenience_symlinks_bep_event डिफ़ॉल्ट: "false": यह फ़्लैग कंट्रोल करता है कि हम BuildEventProtocol में build eventConvenienceSymlinksIdentified पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में convenienceSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके वर्कस्पेस में बनाए गए सभी सुविधा वाले सिंबल लिंक की सूची होगी. अगर यह फ़ील्ड 'गलत है' पर सेट है, तो BuildEventProtocol में convenienceSymlinksIdentified एंट्री खाली होगी.
टैग: affects_outputs
--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1": इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines
--[no]experimental_omitfp डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "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
--fat_apk_cpu=<comma-separated set of options> default: "armeabi-v7a": इस विकल्प को सेट करने से फ़ैट APK चालू हो जाते हैं.इनमें टारगेट किए गए सभी आर्किटेक्चर के लिए नेटिव बाइनरी होती हैं. उदाहरण के लिए, --fat_apk_cpu=x86,armeabi-v7a. अगर इस फ़्लैग को सेट किया जाता है, तो android_binary नियमों की डिपेंडेंसी के लिए --android_cpu को अनदेखा कर दिया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]fat_apk_hwasan डिफ़ॉल्ट: "false": HWASAN स्प्लिट बनाने हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--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 डिफ़ॉल्ट: "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> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों (C++ नहीं) को कंपाइल करते समय, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टूल के लिए, 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
--host_swiftcopt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ीक्यूशन टूल के लिए, swiftc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूल चेन के लिए, exec ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `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]incompatible_use_host_features default: "true": अगर सही है, तो टारगेट कॉन्फ़िगरेशन के लिए सिर्फ़ --features और एक्ज़ेक कॉन्फ़िगरेशन के लिए --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change
--[no]instrument_test_targets डिफ़ॉल्ट: "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> कई बार इस्तेमाल किया गया हो: एलटीओ बैकएंड के चरण में पास करने के लिए अतिरिक्त विकल्प (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 डिफ़ॉल्ट: "false": अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "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 फ़ाइलों के LTO बैकएंड कमांड लाइन में -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 डिफ़ॉल्ट: "false": बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.
टैग: 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
--swiftcopt=<a string> कई बार इस्तेमाल किया गया हो: Swift कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines
--symlink_prefix=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह प्रीफ़िक्स, बिल्ड के बाद बनाए गए किसी भी सुविधा वाले सिमलंक के पहले जोड़ा जाता है. अगर इसे शामिल नहीं किया जाता है, तो डिफ़ॉल्ट वैल्यू, बिल्ड टूल का नाम और उसके बाद हाइफ़न होती है. अगर '/' पास किया जाता है, तो कोई सिंबल लिंक नहीं बनाया जाता और कोई चेतावनी नहीं दी जाती. चेतावनी: '/' के लिए खास सुविधा जल्द ही बंद हो जाएगी; इसके बजाय --experimental_convenience_symlinks=ignore का इस्तेमाल करें.
टैग: 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

--auto_cpu_environment_group=<a build target label> default: "": environment_group की जानकारी दें, ताकि सीपीयू वैल्यू को target_environment वैल्यू पर अपने-आप मैप किया जा सके.
टैग: changes_inputs, loading_and_analysis, experimental
--[no]check_licenses डिफ़ॉल्ट: "false": जांच करें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह विकल्प बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]desugar_for_android default: "true": Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs डिफ़ॉल्ट: "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=<off, warning or error> डिफ़ॉल्ट: "बंद है": इस विकल्प को चालू करने पर, यह जांच की जाती है कि aar_import की डिपेंडेंसी पूरी हो गई हैं या नहीं. इस नीति के उल्लंघन को ठीक करने के लिए, बिल्ड को रोका जा सकता है या सिर्फ़ चेतावनियां दिखाई जा सकती हैं.
टैग: 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 डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "false": इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false": यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "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]incompatible_validate_top_level_header_inclusions default: "true": अगर यह सही है, तो Bazel टॉप लेवल की डायरेक्ट्री के हेडर को भी शामिल करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 देखें.
टैग: loading_and_analysis, incompatible_change
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: --incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis
--[no]strict_filesets डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह वैल्यू 'सही है' पर सेट है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "environment" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: 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 पर साइन करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.
टैग: action_command_lines

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

--[no]allow_analysis_failures डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर dex2oat की कार्रवाई पूरी नहीं होती है, तो टेस्ट के दौरान dex2oat को लागू करने के बजाय, बिल्ड को ब्रेक कर दिया जाएगा.
टैग: loading_and_analysis, experimental
--[no]check_tests_up_to_date डिफ़ॉल्ट: "false": जांच न करें, बस यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी टेस्ट के नतीजे अप-टू-डेट हैं, तो टेस्टिंग पूरी हो जाती है. अगर कोई टेस्ट बनाना या उसे लागू करना ज़रूरी है, तो गड़बड़ी की सूचना दी जाती है और टेस्टिंग नहीं हो पाती. इस विकल्प का मतलब है कि --check_up_to_date का इस्तेमाल किया गया है.
टैग: execution
--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false": android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--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
--[no]ios_memleaks डिफ़ॉल्ट: "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
--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
--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
--[no]test_keep_going default: "true": इस सुविधा के बंद होने पर, टेस्ट पास न होने की वजह से पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट चलाए जाते हैं. भले ही, कुछ टेस्ट पास न हुए हों.
टैग: execution
--test_strategy=<a string> default: "": यह तय करता है कि टेस्ट चलाते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution
--test_timeout=<a single integer or comma-separated list of 4 integers> default: "-1": टेस्ट के टाइम आउट के लिए, टेस्ट के टाइम आउट की डिफ़ॉल्ट वैल्यू (सेकंड में) बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करने के लिए कहा जाता है.
--test_tmpdir=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह 'bazel test' के लिए, बुनियादी अस्थायी डायरेक्ट्री के बारे में बताता है.
--[no]zip_undeclared_test_outputs default: "true": अगर यह वैल्यू सही है, तो बिना बताए गए टेस्ट के आउटपुट को ZIP फ़ाइल में संग्रहित किया जाएगा.
टैग:test_runner

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false": ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास हटाई जा सकें.
टैग: action_command_lines
--[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_objc_include_scanning डिफ़ॉल्ट: "false": Whether to perform include scanning for objective C/C++.
टैग: loading_and_analysis, execution, changes_inputs
--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "false": इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए, टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट नहीं किए गए नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू 'गलत है' पर सेट है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state
--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "false": यह नीति चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false": क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs
--[no]incremental_dexing default: "true": यह हर जार फ़ाइल के लिए, अलग-अलग डेक्सिंग का ज़्यादातर काम करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--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 (उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, Bazel ("HOST_RAM*.67") उपलब्ध रैम का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन के बारे में क्वेरी करेगा. साथ ही, उपलब्ध रैम का 67% इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations
--[no]objc_use_dotd_pruning default: "true": अगर इस फ़्लैग को सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल किया जाएगा. इससे objc कंपाइलर को पास किए गए इनपुट के सेट को कम किया जा सकेगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "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

--[no]experimental_bep_target_summary डिफ़ॉल्ट: "false": TargetSummary इवेंट पब्लिश करने हैं या नहीं.
--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय BEP में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में Fileset के सभी रिलेटिव सिंबल लिंक पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets विकल्प की ज़रूरत होती है.
टैग: affects_outputs
--experimental_build_event_upload_max_retries=<an integer> default: "4": Bazel को बिल्ड इवेंट अपलोड करने की कोशिश ज़्यादा से ज़्यादा कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s": बीईपी अपलोड करने में गड़बड़ी होने पर, एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने के लिए, शुरुआती और कम से कम देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: ब्यौरा देखें: इससे यह चुना जाता है कि बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को कैसे अपलोड करना है.
टैग: affects_outputs
--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "false": अगर पैरामीटर फ़ाइलों को मटीरियलाइज़ किया जा रहा है, तो उन्हें सीधे डिस्क में लिखें.
टैग: execution
--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "false": क्या रन बिल्ड इवेंट में कमांड-लाइन के बचे हुए हिस्से को शामिल करना है. इसमें बचा हुआ हिस्सा शामिल हो सकता है. डिफ़ॉल्ट रूप से, रन कमांड के बिल्ड इवेंट में बचे हुए डेटा को शामिल नहीं किया जाता. हालांकि, इसमें बचे हुए डेटा को शामिल किया जा सकता है.
टैग: affects_outputs
--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "false": स्ट्रीम लॉग फ़ाइलें, डिस्क पर सेव करने के बजाय सीधे रिमोट स्टोरेज पर अपलोड करता है.
टैग: affects_outputs
--explain=<a path> डिफ़ॉल्ट: ब्यौरा देखें: इस विकल्प का इस्तेमाल करने पर, बिल्ड सिस्टम, बिल्ड के हर चरण के बारे में जानकारी देता है. वजह को तय की गई लॉग फ़ाइल में लिखा जाता है.
टैग: affects_outputs
--[no]legacy_important_outputs default: "true": इसका इस्तेमाल, TargetComplete इवेंट में लेगसी important_outputs फ़ील्ड के जनरेशन को रोकने के लिए करें. Bazel को ResultStore के साथ इंटिग्रेट करने के लिए, important_outputs ज़रूरी हैं.
टैग: affects_outputs
--[no]materialize_param_files डिफ़ॉल्ट: "false": यह रिमोट ऐक्शन एक्ज़ीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें लिखता है. कार्रवाइयों को डीबग करते समय यह काम का होता है. यह --subcommands और --verbose_failures से पता चलता है.
टैग: execution
--max_config_changes_to_show=<an integer> default: "3": बिल्ड के विकल्पों में बदलाव होने की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नाम की दी गई संख्या तक दिखाता है. अगर दी गई संख्या -1 है, तो बदले गए सभी विकल्प दिखेंगे.
टैग: terminal_output
--max_test_output_bytes=<an integer> default: "-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
--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> default: "short": इस एट्रिब्यूट की वैल्यू से, टेस्ट के नतीजों के लिए मनचाहा फ़ॉर्मैट तय किया जाता है. मान्य वैल्यू ये हैं: 'short' का इस्तेमाल सिर्फ़ उन टेस्ट के बारे में जानकारी प्रिंट करने के लिए किया जाता है जिन्हें पूरा किया गया है, 'terse' का इस्तेमाल सिर्फ़ उन टेस्ट के बारे में जानकारी प्रिंट करने के लिए किया जाता है जिन्हें पूरा नहीं किया जा सका, 'detailed' का इस्तेमाल उन टेस्ट केस के बारे में पूरी जानकारी प्रिंट करने के लिए किया जाता है जो पूरे नहीं किए जा सके, 'testcase' का इस्तेमाल टेस्ट केस के रिज़ॉल्यूशन में खास जानकारी प्रिंट करने के लिए किया जाता है. इससे उन टेस्ट केस के बारे में पूरी जानकारी प्रिंट नहीं होती जिन्हें पूरा नहीं किया जा सका. 'none' का इस्तेमाल खास जानकारी को हटाने के लिए किया जाता है.
टैग: terminal_output
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*": टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.
टैग: terminal_output
--[no]verbose_explanations डिफ़ॉल्ट: "false": अगर --explain विकल्प चालू है, तो इससे जवाब में ज़्यादा जानकारी मिलती है. अगर --explain विकल्प चालू नहीं है, तो इसका कोई असर नहीं होगा.
टैग: affects_outputs
--[no]verbose_failures डिफ़ॉल्ट: "false": अगर कोई निर्देश काम नहीं करता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

--aspects_parameters=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो: इससे कमांड-लाइन के पहलुओं के पैरामीटर की वैल्यू तय की जाती हैं. हर पैरामीटर वैल्यू को <param_name>=<param_value> के ज़रिए तय किया जाता है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param' --aspects सूची में किसी पहलू का पैरामीटर है या सूची में किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. हालांकि, एक ही पैरामीटर को एक से ज़्यादा बार वैल्यू असाइन करने की अनुमति नहीं है.
टैग: loading_and_analysis
--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो: यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह "<key>=<value>" के तौर पर एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "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
--target_pattern_file=<a string> default: "": अगर यह विकल्प सेट है, तो बिल्ड, कमांड लाइन के बजाय यहां दी गई फ़ाइल से पैटर्न पढ़ेगा. यहां और कमांड-लाइन पैटर्न में किसी फ़ाइल के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs

--experimental_remote_cache_eviction_retries=<an integer> default: "0": अगर बिल्ड को रिमोट कैश हटाने से जुड़ी गड़बड़ी का सामना करना पड़ता है, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. शून्य से अलग वैल्यू सेट करने पर, --incompatible_remote_use_new_exit_code_for_lost_inputs को डिफ़ॉल्ट रूप से सही पर सेट कर दिया जाएगा. हर कोशिश के लिए, एक नया इनवोकेशन आईडी जनरेट किया जाएगा. अगर आपने इनवोकेशन आईडी जनरेट किया है और इसे --invocation_id के साथ Bazel को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, --incompatible_remote_use_new_exit_code_for_lost_inputs फ़्लैग सेट करें और 39 वाले एक्ज़िट कोड की जांच करें.
टैग: execution
--[no]incompatible_remote_use_new_exit_code_for_lost_inputs default: "true": अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, बिल्ड के दौरान रिमोट कैश मेमोरी से ब्लोब हटाने पर, एक्ज़िट कोड 34 के बजाय नया एक्ज़िट कोड 39 इस्तेमाल करेगा.
टैग: incompatible_change

--[no]allow_analysis_cache_discard default: "true": अगर बिल्ड सिस्टम में बदलाव की वजह से, विश्लेषण वाली कैश मेमोरी को खारिज किया जा रहा है, तो इस विकल्प को 'गलत है' पर सेट करने से, Bazel बिल्ड जारी रखने के बजाय बंद हो जाएगा. अगर 'discard_analysis_cache' भी सेट है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit
--[no]build_manual_tests डिफ़ॉल्ट: "false": 'मैन्युअल' के तौर पर टैग किए गए टेस्ट टारगेट को बनाने के लिए मजबूर करता है. 'मैन्युअल' टेस्ट को प्रोसेस से बाहर रखा जाता है. इस विकल्प से, उन्हें बनाया जा सकता है, लेकिन लागू नहीं किया जा सकता.
--build_tag_filters=<comma-separated list of options> default: "": कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. जिन टैग को शामिल नहीं करना है उन्हें तय करने के लिए, हर टैग से पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें कम से कम एक शामिल किया गया टैग हो और कोई भी बाहर रखा गया टैग न हो. इस विकल्प से, 'test' निर्देश के साथ लागू किए गए टेस्ट के सेट पर कोई असर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों से नियंत्रित होते हैं. उदाहरण के लिए, '--test_tag_filters'
--[no]build_tests_only डिफ़ॉल्ट: "false": अगर यह विकल्प चुना जाता है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.
--[no]cache_test_results [-t] default: "auto": अगर इसे 'auto' पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Bazel, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है. 'नहीं' पर सेट होने पर, Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.
--[no]compile_one_dependency डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": विश्लेषण पूरा होने के तुरंत बाद, विश्लेषण की कैश मेमोरी को खारिज कर दें. इससे मेमोरी का इस्तेमाल ~10% तक कम हो जाता है. हालांकि, इसके बाद इंक्रीमेंटल बिल्ड बनाने में ज़्यादा समय लगता है.
--execution_log_binary_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें: इस फ़ाइल में, एक्ज़ीक्यूट किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, सीमांकित किए गए स्पॉन प्रोटो के तौर पर लॉग करें. इससे जुड़े फ़्लैग: --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).
--execution_log_json_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें: एक्ज़ीक्यूट किए गए स्पॉन को इस फ़ाइल में लॉग करें. इसके लिए, src/main/protobuf/spawn.proto के मुताबिक, डीलिमिटेड स्पॉन प्रोटो को JSON के तौर पर दिखाएं. इससे जुड़े फ़्लैग: --execution_log_binary_file (बाइनरी protobuf फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).
--[no]execution_log_sort default: "true": यह तय करता है कि एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं, ताकि अलग-अलग इनवोकेशन के लॉग की तुलना करना आसान हो. इस विकल्प को false पर सेट करने से, इनवॉकेशन के आखिर में सीपीयू और मेमोरी का इस्तेमाल कम हो जाता है. हालांकि, इससे लॉग को नॉनडिटरमिनिस्टिक एक्ज़ीक्यूशन ऑर्डर में जनरेट किया जाता है.
--[no]expand_test_suites default: "true": विश्लेषण करने से पहले, test_suite के टारगेट को उनके कॉम्पोनेंट टेस्ट में बड़ा करें. इस फ़्लैग को चालू करने पर (डिफ़ॉल्ट रूप से), नेगेटिव टारगेट पैटर्न, टेस्ट सुइट से जुड़े टेस्ट पर लागू होंगे. ऐसा न करने पर, वे लागू नहीं होंगे. इस फ़्लैग को बंद करने से, कमांड लाइन पर टॉप-लेवल के पहलुओं को लागू करने में मदद मिलती है. इसके बाद, वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis
--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "false": अगर यह वैल्यू सही है, तो Blaze पहली बार टेस्ट के सफल होने पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis
--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 डिफ़ॉल्ट: "false": अब इसका इस्तेमाल नहीं किया जा सकता. इसके बजाय, पहलुओं का इस्तेमाल करें. यह सिर्फ़ टॉप लेवल के टारगेट के लिए extra_actions शेड्यूल करता है.
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false": अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false": अगर सही है, तो clang के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_j2objc_header_map default: "true": J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "false": हेडर पाथ को छोटा करके जनरेट करना है या नहीं. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel> default: "javabuilder": इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.
--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "false": --experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs
--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "false": java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs
--[no]explicit_java_test_deps डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> default: "local_jdk": Java रनटाइम का वर्शन
--javacopt=<a string> कई बार इस्तेमाल किया गया हो: javac को पास करने के लिए अन्य विकल्प.
--jvmopt=<a string> कई बार इस्तेमाल किया गया हो: Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह एक बाइनरी तय करता है. इसका इस्तेमाल, उन क्लास की सूची जनरेट करने के लिए किया जाता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.
--local_termination_grace_seconds=<an integer> default: "15": टाइम आउट की वजह से किसी लोकल प्रोसेस को बंद करने और उसे तुरंत बंद करने के बीच इंतज़ार करने का समय.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह बिना शार्डिंग के डेक्सिंग करने के लिए, बाइनरी तय करता है.
--package_path=<colon-separated list of options> default: "%workspace%": पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस के हिसाब से होते हैं. अगर इसे शामिल नहीं किया जाता है या इसकी वैल्यू खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट इस्तेमाल किया जाता है.
--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
--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 डिफ़ॉल्ट: "false": अगर यह विकल्प चुना जाता है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.
--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का पूरा पाथ. अगर इस विकल्प को सेट नहीं किया गया है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन (जो Bazel सर्वर शुरू करता है) पर सेट किया गया है, तो Bazel इसका इस्तेमाल करता है. अगर दोनों में से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel चलता है (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash). ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने पर, जनरेट की गई बाइनरी फ़ाइलों को बनाने या रनटाइम में समस्याएं आ सकती हैं.
टैग: loading_and_analysis
--[no]show_loading_progress default: "true": अगर यह विकल्प चालू होता है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.
--test_arg=<a string> कई बार इस्तेमाल किया गया हो: यह अतिरिक्त विकल्पों और आर्ग्युमेंट के बारे में बताता है. इन्हें टेस्ट एक्ज़ीक्यूटेबल में पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.
--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें: यह टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट रन को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.
--test_lang_filters=<comma-separated list of options> default: "": इसमें, टेस्ट की भाषाओं की कॉमा लगाकर अलग की गई सूची दी जाती है. हर भाषा से पहले '-' का इस्तेमाल करके, उन भाषाओं को तय किया जा सकता है जिन्हें शामिल नहीं करना है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जो बताई गई भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test नियम में भाषा के प्रीफ़िक्स के जैसा होना चाहिए. उदाहरण के लिए, 'cc', 'java', 'py' वगैरह. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.
--test_result_expiration=<an integer> default: "-1": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast डिफ़ॉल्ट: "false": यह विकल्प, टेस्ट रनर को फ़ॉरवर्ड करने में तुरंत मदद करता है. टेस्ट रनर को पहली गड़बड़ी होने पर ही बंद हो जाना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "explicit": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'explicit' का इस्तेमाल सिर्फ़ तब करें, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'disabled' को कभी भी टेस्ट शार्डिंग का इस्तेमाल न करने के लिए सेट करें. 'forced=k' का इस्तेमाल करके, 'shard_count' BUILD एट्रिब्यूट की परवाह किए बिना, टेस्टिंग के लिए 'k' शार्ड लागू करें.
--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 के व्यवहार और टेस्ट कमांड पर असर पड़ता है.
--tool_java_language_version=<a string> default: "": बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया गया Java भाषा का वर्शन
--tool_java_runtime_version=<a string> default: "remotejdk_11": बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इंक्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

Canonicalize-flags के विकल्प

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

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

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

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

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

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

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

टैग: host_machine_resource_optimizations

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

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

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

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

Cquery के विकल्प

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--aspect_deps=<off, conservative or precise> default: "conservative": आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक होने पर, आसपेक्ट डिपेंडेंसी की समस्या कैसे हल करें. 'off' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'conservative' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी का नियम क्लास दिया गया हो या नहीं. 'precise' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हैं. ध्यान दें कि सटीक मोड में, एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह विश्लेषण के चरण में तय किया जाता है. यह चरण, 'bazel query' के दौरान नहीं चलता है.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के हिसाब से रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: 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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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
--[no]proto:default_values default: "true": अगर यह वैल्यू सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह वैल्यू गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प, --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "false": definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, हर नियम इंस्टेंस के लिए Starlark कॉल स्टैक को रिकॉर्ड करता है. यह रिकॉर्डिंग, नियम की क्लास तय किए जाने के समय की जाती है.
टैग: terminal_output
--[no]proto:flatten_selects default: "true": इस विकल्प को चालू करने पर, select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किया गया डेटा एक ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू ठीक एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "false": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, वह सोर्स ऐस्पेक्ट डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स ऐस्पेक्ट से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output
--[no]proto:include_configurations default: "true": चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. इस विकल्प को बंद करने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "false": $internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "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_inputs_and_outputs default: "true": rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output
--query_file=<a string> default: "": अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "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: "": यह उस फ़ाइल का नाम है जो एक Starlark फ़ंक्शन को तय करती है. इस फ़ंक्शन का नाम 'format' है और इसमें एक आर्ग्युमेंट होता है. इसे हर कॉन्फ़िगर किए गए टारगेट पर लागू किया जाता है, ताकि उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जा सके. --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> डिफ़ॉल्ट: "none": यह फ़ॉर्मैट बताता है कि cquery, ट्रांज़िशन की जानकारी किस फ़ॉर्मैट में प्रिंट करेगा.
टैग: affects_outputs
--universe_scope=<comma-separated list of options> default: "": कॉमा लगाकर अलग किए गए टारगेट पैटर्न का सेट (जोड़ने और घटाने वाले). क्वेरी को, ट्रांज़िटिव क्लोज़र के ज़रिए तय किए गए यूनिवर्स में किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट होते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर इस विकल्प के बारे में नहीं बताया जाता है, तो यह माना जाता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के टारगेट हैं. ध्यान दें: cquery के लिए, इस विकल्प को तय न करने पर, बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ बिल्ड नहीं किए जा सकते.
टैग: loading_and_analysis

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है

--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "false": सिमलिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false": वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution
--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false": सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, नए स्पॉन में टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग चलाएगा.
टैग: execution
--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false": इस विकल्प के चालू होने पर, फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.
टैग: execution
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> default: "": कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, 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 डिफ़ॉल्ट: "false": अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. टेस्ट एक्ज़ेक ग्रुप का नहीं.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें: Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_crosstool_top=<a build target label> default: "//external:android/crosstool": Android बिल्ड के लिए इस्तेमाल किए गए C++ कंपाइलर की जगह.
टैग: affects_outputs, changes_inputs, loading_and_analysis, loses_incremental_state
--android_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: Android का टारगेट grte_top.
टैग: changes_inputs, 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
--android_sdk=<a build target label> default: "@bazel_tools//tools/android:sdk": इससे उस Android SDK/प्लैटफ़ॉर्म के बारे में पता चलता है जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: 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
--crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain": C++ कोड को कंपाइल करने के लिए इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs
--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 डिफ़ॉल्ट: "false": अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution
--[no]experimental_prefer_mutual_xcode default: "true": अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए Xcode के लोकल वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state
--extra_execution_platforms=<comma-separated list of options> default: "": कार्रवाइयां करने के लिए उपलब्ध प्लैटफ़ॉर्म. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. register_execution_platforms() में बताए गए प्लैटफ़ॉर्म से पहले, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, पहले के फ़्लैग की सेटिंग को बदल देंगे.
टैग: 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> डिफ़ॉल्ट: ब्यौरा देखें: होस्ट कंपाइलेशन के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top सेट नहीं है, तो इसे अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, execution
--host_crosstool_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: डिफ़ॉल्ट रूप से, --crosstool_top और --compiler विकल्पों का इस्तेमाल, exec कॉन्फ़िगरेशन के लिए भी किया जाता है. यह फ़्लैग देने पर, Bazel दिए गए crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग: loading_and_analysis, changes_inputs, affects_outputs
--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें: अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> default: "@local_config_platform//:host": यह प्लैटफ़ॉर्म के नियम का लेबल है. इससे होस्ट सिस्टम के बारे में जानकारी मिलती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[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_android_toolchain_resolution default: "true": Android के नियमों (Starlark और नेटिव) के लिए Android SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false": ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone default: "true": अगर यह विकल्प सही है, तो Bazel, एलटीओ इंडेक्सिंग कमांड लाइनों के लिए, C++ लिंक ऐक्शन कमांड लाइनों का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग: 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_require_ctx_in_configure_features default: "true": अगर यह सही है, तो Bazel को cc_common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 देखें.
टैग: loading_and_analysis, 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 relative path> default: "": यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य Workspace रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, वर्कस्पेस के रूट फ़ोल्डर में मौजूद होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--platforms=<a build target label> default: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python2_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अब इस्तेमाल नहीं किया जा सकता. यह `--incompatible_use_python_toolchains` से बंद है.
टैग: no_op, deprecated
--python3_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें: अब इस्तेमाल नहीं किया जा सकता. यह `--incompatible_use_python_toolchains` से बंद है.
टैग: no_op, deprecated
--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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_proto_extra_actions डिफ़ॉल्ट: "false": proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state डिफ़ॉल्ट: "false": कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> डिफ़ॉल्ट: "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]legacy_external_runfiles default: "true": अगर यह सही है, तो .runfiles/repo के अलावा, .runfiles/wsname/external/repo में बाहरी रिपॉज़िटरी के लिए, रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap डिफ़ॉल्ट: "false": यह तय करता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps डिफ़ॉल्ट: "false": अगर यह विकल्प सेट किया जाता है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो: यह टारगेट कॉन्फ़िगरेशन के साथ कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. इस मामले में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, इसे name=value पेयर के हिसाब से भी तय किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकेगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.
टैग: action_command_lines
--android_cpu=<a string> default: "armeabi-v7a": Android का टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]android_databinding_use_androidx default: "true": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग 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 यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. '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 डिफ़ॉल्ट: "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
टैग: affects_outputs
--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो: ऐसी सूची जिसमें Apple Catalyst बाइनरी बनाने के लिए, आर्किटेक्चर को कॉमा लगाकर अलग किया गया हो.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage डिफ़ॉल्ट: "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 यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_fdo_profile_absolute_path default: "true": अगर इसे सेट किया जाता है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: 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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": इस विकल्प को चालू करने पर, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू हो जाती है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर ऐसा तय किया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs
--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1": इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines
--[no]experimental_omitfp डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "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
--fat_apk_cpu=<comma-separated set of options> default: "armeabi-v7a": इस विकल्प को सेट करने से फ़ैट APK चालू हो जाते हैं.इनमें टारगेट किए गए सभी आर्किटेक्चर के लिए नेटिव बाइनरी होती हैं. उदाहरण के लिए, --fat_apk_cpu=x86,armeabi-v7a. अगर इस फ़्लैग को सेट किया जाता है, तो android_binary नियमों की डिपेंडेंसी के लिए --android_cpu को अनदेखा कर दिया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]fat_apk_hwasan डिफ़ॉल्ट: "false": HWASAN स्प्लिट बनाने हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--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 डिफ़ॉल्ट: "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> कई बार इस्तेमाल किया गया हो: exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों (C++ नहीं) को कंपाइल करते समय, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टूल के लिए, 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
--host_swiftcopt=<a string> कई बार इस्तेमाल किया गया हो: एक्ज़ीक्यूशन टूल के लिए, swiftc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false": इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूल चेन के लिए, exec ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `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]incompatible_use_host_features default: "true": अगर सही है, तो टारगेट कॉन्फ़िगरेशन के लिए सिर्फ़ --features और एक्ज़ेक कॉन्फ़िगरेशन के लिए --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change
--[no]instrument_test_targets डिफ़ॉल्ट: "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> कई बार इस्तेमाल किया गया हो: एलटीओ बैकएंड के चरण में पास करने के लिए अतिरिक्त विकल्प (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 डिफ़ॉल्ट: "false": अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "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 फ़ाइलों के LTO बैकएंड कमांड लाइन में -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 डिफ़ॉल्ट: "false": बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.
टैग: 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
--swiftcopt=<a string> कई बार इस्तेमाल किया गया हो: Swift कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines
--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

--auto_cpu_environment_group=<a build target label> default: "": environment_group की जानकारी दें, ताकि सीपीयू वैल्यू को target_environment वैल्यू पर अपने-आप मैप किया जा सके.
टैग: changes_inputs, loading_and_analysis, experimental
--[no]check_licenses डिफ़ॉल्ट: "false": जांच करें कि निर्भर पैकेज की ओर से लगाई गई लाइसेंसिंग की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग: build_file_semantics
--[no]check_visibility default: "true": अगर यह विकल्प बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics
--[no]desugar_for_android default: "true": Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs डिफ़ॉल्ट: "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=<off, warning or error> डिफ़ॉल्ट: "बंद है": इस विकल्प को चालू करने पर, यह जांच की जाती है कि aar_import की डिपेंडेंसी पूरी हो गई हैं या नहीं. इस नीति के उल्लंघन को ठीक करने के लिए, बिल्ड को रोका जा सकता है या सिर्फ़ चेतावनियां दिखाई जा सकती हैं.
टैग: 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 डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "false": इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false": यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "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]incompatible_validate_top_level_header_inclusions default: "true": अगर यह सही है, तो Bazel टॉप लेवल की डायरेक्ट्री के हेडर को भी शामिल करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 देखें.
टैग: loading_and_analysis, incompatible_change
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: --incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis
--[no]strict_filesets डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह वैल्यू 'सही है' पर सेट है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "environment" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: 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 पर साइन करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.
टैग: action_command_lines

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

--[no]allow_analysis_failures डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर dex2oat की कार्रवाई पूरी नहीं होती है, तो टेस्ट के दौरान dex2oat को लागू करने के बजाय, बिल्ड को ब्रेक कर दिया जाएगा.
टैग: loading_and_analysis, experimental
--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false": android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks डिफ़ॉल्ट: "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> default: "-1": टेस्ट के टाइम आउट के लिए, टेस्ट के टाइम आउट की डिफ़ॉल्ट वैल्यू (सेकंड में) बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करने के लिए कहा जाता है.
--[no]zip_undeclared_test_outputs default: "true": अगर यह वैल्यू सही है, तो बिना बताए गए टेस्ट के आउटपुट को ZIP फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

--aspect_deps=<off, conservative or precise> default: "conservative": आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक होने पर, आसपेक्ट डिपेंडेंसी की समस्या कैसे हल करें. 'off' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'conservative' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी का नियम क्लास दिया गया हो या नहीं. 'precise' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हैं. ध्यान दें कि सटीक मोड में, एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह विश्लेषण के चरण में तय किया जाता है. यह चरण, 'bazel query' के दौरान नहीं चलता है.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के हिसाब से रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: 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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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
--[no]proto:default_values default: "true": अगर यह वैल्यू सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह वैल्यू गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प, --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "false": definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, हर नियम इंस्टेंस के लिए Starlark कॉल स्टैक को रिकॉर्ड करता है. यह रिकॉर्डिंग, नियम की क्लास तय किए जाने के समय की जाती है.
टैग: terminal_output
--[no]proto:flatten_selects default: "true": इस विकल्प को चालू करने पर, select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किया गया डेटा एक ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू ठीक एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "false": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, वह सोर्स ऐस्पेक्ट डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स ऐस्पेक्ट से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output
--[no]proto:include_configurations default: "true": चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. इस विकल्प को बंद करने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "false": $internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "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_inputs_and_outputs default: "true": rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output
--query_file=<a string> default: "": अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "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: "": यह उस फ़ाइल का नाम है जो एक Starlark फ़ंक्शन को तय करती है. इस फ़ंक्शन का नाम 'format' है और इसमें एक आर्ग्युमेंट होता है. इसे हर कॉन्फ़िगर किए गए टारगेट पर लागू किया जाता है, ताकि उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जा सके. --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> डिफ़ॉल्ट: "none": यह फ़ॉर्मैट बताता है कि cquery, ट्रांज़िशन की जानकारी किस फ़ॉर्मैट में प्रिंट करेगा.
टैग: affects_outputs
--universe_scope=<comma-separated list of options> default: "": कॉमा लगाकर अलग किए गए टारगेट पैटर्न का सेट (जोड़ने और घटाने वाले). क्वेरी को, ट्रांज़िटिव क्लोज़र के ज़रिए तय किए गए यूनिवर्स में किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट होते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर इस विकल्प के बारे में नहीं बताया जाता है, तो यह माना जाता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के टारगेट हैं. ध्यान दें: cquery के लिए, इस विकल्प को तय न करने पर, बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ बिल्ड नहीं किए जा सकते.
टैग:loading_and_analysis

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false": ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास हटाई जा सकें.
टैग: action_command_lines
--[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_objc_include_scanning डिफ़ॉल्ट: "false": Whether to perform include scanning for objective C/C++.
टैग: loading_and_analysis, execution, changes_inputs
--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "false": इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए, टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट नहीं किए गए नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू 'गलत है' पर सेट है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state
--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "false": यह नीति चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false": क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs
--[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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "false": अगर यह वैल्यू सही है, तो Blaze पहली बार टेस्ट के सफल होने पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false": अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false": अगर सही है, तो clang के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_j2objc_header_map default: "true": J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "false": हेडर पाथ को छोटा करके जनरेट करना है या नहीं. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel> default: "javabuilder": इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.
--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "false": --experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs
--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "false": java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs
--[no]explicit_java_test_deps डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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 लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> default: "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
--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 डिफ़ॉल्ट: "false": अगर यह विकल्प चुना जाता है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.
--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें: Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का पूरा पाथ. अगर इस विकल्प को सेट नहीं किया गया है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन (जो Bazel सर्वर शुरू करता है) पर सेट किया गया है, तो Bazel इसका इस्तेमाल करता है. अगर दोनों में से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel चलता है (Windows: c:/tools/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> default: "-1": इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इससे कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast डिफ़ॉल्ट: "false": यह विकल्प, टेस्ट रनर को फ़ॉरवर्ड करने में तुरंत मदद करता है. टेस्ट रनर को पहली गड़बड़ी होने पर ही बंद हो जाना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "explicit": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'explicit' का इस्तेमाल सिर्फ़ तब करें, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'disabled' को कभी भी टेस्ट शार्डिंग का इस्तेमाल न करने के लिए सेट करें. 'forced=k' का इस्तेमाल करके, 'shard_count' BUILD एट्रिब्यूट की परवाह किए बिना, टेस्टिंग के लिए 'k' शार्ड लागू करें.
--tool_java_language_version=<a string> default: "": बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया गया Java भाषा का वर्शन
--tool_java_runtime_version=<a string> default: "remotejdk_11": बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars default: "true": अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इंक्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

डंप के विकल्प

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

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

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

--[no]all डिफ़ॉल्ट: "false": यह किसी टारगेट या रिपॉज़िटरी को बनाने के लिए ज़रूरी सभी बाहरी रिपॉज़िटरी को फ़ेच करता है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--[no]configure डिफ़ॉल्ट: "false": सिर्फ़ उन रिपॉज़िटरी को फ़ेच करता है जिन्हें सिस्टम कॉन्फ़िगरेशन के मकसद से 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--[no]force डिफ़ॉल्ट: "false": अगर कोई मौजूदा रिपॉज़िटरी है, तो उसे अनदेखा करें और रिपॉज़िटरी को फिर से फ़ेच करें. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations
--[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
--repo=<a string> कई बार इस्तेमाल किया गया हो: यह सिर्फ़ बताई गई रिपॉज़िटरी को फ़ेच करता है. यह {@apparent_repo_name} या {@@canonical_repo_name} में से कोई भी हो सकती है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string> default: "": अगर यह फ़ील्ड खाली नहीं है, तो उन सभी Starlark रिपॉज़िटरी नियमों की हल की गई जानकारी के साथ एक Starlark वैल्यू लिखें जिन्हें लागू किया गया था.
टैग: affects_outputs

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

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

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.
--help_verbosity=<long, medium or short> default: "medium": सहायता कमांड के लिए वर्बोसिटी लेवल चुनें.
टैग: affects_outputs, terminal_output
--long [-l]: हर विकल्प का सिर्फ़ नाम दिखाने के बजाय, उसकी पूरी जानकारी दिखाएं.
इनके तौर पर दिखता है:
--help_verbosity=long

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

टैग: affects_outputs, terminal_output

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

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

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.
--[no]show_make_env डिफ़ॉल्ट: "false": आउटपुट में "Make" एनवायरमेंट को शामिल करो.
टैग: affects_outputs, terminal_output

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

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

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations
--mode=<classic, classic_internal_test_do_not_use or skylark> डिफ़ॉल्ट: "classic": मोबाइल ऐप्लिकेशन इंस्टॉल करने से जुड़ा विज्ञापन दिखाने का तरीका चुनें. "classic" से, मोबाइल-इंस्टॉल का मौजूदा वर्शन चलता है. "skylark" में Starlark का नया वर्शन इस्तेमाल किया जाता है. इसमें android_test के लिए सहायता उपलब्ध है.
टैग: loading_and_analysis, execution, incompatible_change

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

--[no]incremental डिफ़ॉल्ट: "false": यह तय करता है कि इंक्रीमेंटल इंस्टॉल करना है या नहीं. अगर ऐसा है, तो जिस डिवाइस पर कोड इंस्टॉल करना है उसकी स्थिति पढ़कर, गैर-ज़रूरी अतिरिक्त काम से बचें. साथ ही, उस जानकारी का इस्तेमाल करके, गैर-ज़रूरी काम से बचें. अगर यह वैल्यू 'गलत है' (डिफ़ॉल्ट रूप से), तो हमेशा पूरा इंस्टॉलेशन करें.
टैग: loading_and_analysis
--[no]split_apks डिफ़ॉल्ट: "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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.
--incremental_install_verbosity=<a string> default: "": इंक्रीमेंटल इंस्टॉल के लिए वर्बोसिटी. डीबग लॉगिंग के लिए, इसे 1 पर सेट करें.
टैग: bazel_monitoring

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

मॉड के विकल्प

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations
--[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 डिफ़ॉल्ट: "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

--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 डिफ़ॉल्ट: "false": यह दिखाए गए ट्री में डिपेंडेंसी साइकल के बारे में बताता है. इन्हें आम तौर पर डिफ़ॉल्ट रूप से अनदेखा किया जाता है.
टैग: terminal_output
--depth=<an integer> default: "-1": डिपेंडेंसी ट्री की ज़्यादा से ज़्यादा डिसप्ले डेप्थ. डेप्थ 1 में, सीधे तौर पर जुड़ी डिपेंडेंसी दिखती हैं. उदाहरण के लिए, tree, path, और 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 डिफ़ॉल्ट: "false": डिपेंडेंसी ग्राफ़ में, पहले से मौजूद मॉड्यूल शामिल करें. इस सुविधा को डिफ़ॉल्ट रूप से बंद रखा जाता है, क्योंकि इससे काफ़ी आवाज़ आती है.
टैग: terminal_output
--[no]include_unused डिफ़ॉल्ट: "false": क्वेरी में, इस्तेमाल नहीं किए गए उन मॉड्यूल को भी ध्यान में रखा जाएगा और दिखाया जाएगा जो चुने जाने के बाद, मॉड्यूल रिज़ॉल्यूशन ग्राफ़ में मौजूद नहीं हैं. ऐसा, कम से कम वर्शन चुनने या ओवरराइड करने के नियमों की वजह से होता है. इसका असर, हर तरह की क्वेरी पर अलग-अलग पड़ सकता है. जैसे, all_paths कमांड में नए पाथ शामिल करना या explain कमांड में अतिरिक्त आश्रित शामिल करना.
टैग: terminal_output
--output=<text, json or graph> default: "text": क्वेरी के नतीजों को प्रिंट करने का फ़ॉर्मैट. क्वेरी के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: टेक्स्ट, JSON, ग्राफ़
टैग: terminal_output
--[no]verbose डिफ़ॉल्ट: "false": क्वेरी में यह भी दिखेगा कि मॉड्यूल को उनके मौजूदा वर्शन में क्यों बदला गया है (अगर बदला गया है). 'व्याख्या करें' क्वेरी के लिए, डिफ़ॉल्ट रूप से यह विकल्प 'सही' पर सेट होता है.
टैग: terminal_output

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

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

Print_action के विकल्प

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है
--print_action_mnemonics=<a string> कई बार इस्तेमाल किया गया हो: यह उन निमोनिक की सूची है जिनके हिसाब से print_action डेटा को फ़िल्टर करना है. अगर इसे खाली छोड़ दिया जाता है, तो कोई फ़िल्टरिंग नहीं होती है.

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations
--[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 डिफ़ॉल्ट: "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

--aspect_deps=<off, conservative or precise> default: "conservative": आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक होने पर, आसपेक्ट डिपेंडेंसी की समस्या कैसे हल करें. 'off' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'conservative' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी का नियम क्लास दिया गया हो या नहीं. 'precise' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हैं. ध्यान दें कि सटीक मोड में, एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह विश्लेषण के चरण में तय किया जाता है. यह चरण, 'bazel query' के दौरान नहीं चलता है.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "false": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के हिसाब से रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output
--[no]experimental_graphless_query default: "auto": अगर यह वैल्यू सही है, तो क्वेरी लागू करने के ऐसे तरीके का इस्तेमाल किया जाता है जो ग्राफ़ की कॉपी नहीं बनाता. नया वर्शन सिर्फ़ --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": इस विकल्प को सेट करने पर, सॉर्ट --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 डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "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, textproto, xml.
टैग: terminal_output
--[no]proto:default_values default: "true": अगर यह वैल्यू सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह वैल्यू गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प, --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "false": definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, हर नियम इंस्टेंस के लिए Starlark कॉल स्टैक को रिकॉर्ड करता है. यह रिकॉर्डिंग, नियम की क्लास तय किए जाने के समय की जाती है.
टैग: terminal_output
--[no]proto:flatten_selects default: "true": इस विकल्प को चालू करने पर, select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किया गया डेटा एक ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू ठीक एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "false": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, वह सोर्स ऐस्पेक्ट डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स ऐस्पेक्ट से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "false": $internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "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_inputs_and_outputs default: "true": rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output
--query_file=<a string> default: "": अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "false": अगर यह 'सही है', तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह की जानकारी रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह अलग-अलग मशीनों पर एक जैसा नहीं होता. इस विकल्प को true पर सेट करके, सभी मशीनों पर एक जैसा नतीजा पाया जा सकता है.
टैग: terminal_output
--[no]strict_test_suite डिफ़ॉल्ट: "false": अगर यह सही है, तो tests() एक्सप्रेशन में गड़बड़ी होती है. ऐसा तब होता है, जब उसे ऐसी test_suite मिलती है जिसमें टेस्ट के अलावा अन्य टारगेट शामिल होते हैं.
टैग: 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 डिफ़ॉल्ट: "false": अगर यह विकल्प सही है, तो उन नियमों के एट्रिब्यूट प्रिंट किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह विकल्प गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है.
टैग: terminal_output
--[no]xml:line_numbers default: "true": अगर सही है, तो एक्सएमएल आउटपुट में लाइन नंबर शामिल होते हैं. इस विकल्प को बंद करने से, अंतर को आसानी से पढ़ा जा सकता है. यह विकल्प सिर्फ़ --output=xml पर लागू होता है.
टैग: terminal_output

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string> default: "": अगर यह फ़ील्ड खाली नहीं है, तो उन सभी Starlark रिपॉज़िटरी नियमों की हल की गई जानकारी के साथ एक Starlark वैल्यू लिखें जिन्हें लागू किया गया था.
टैग: affects_outputs

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

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

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

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

--distdir=<a path> कई बार इस्तेमाल किया गया हो: नेटवर्क ऐक्सेस करने से पहले, इन जगहों पर जाकर भी संग्रह खोजे जा सकते हैं, ताकि उन्हें डाउनलोड किया जा सके.
टैग: bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "false": अगर सेट किया जाता है, तो कैश मेमोरी में मौजूद फ़ाइल को कॉपी करने के बजाय, रिपॉज़िटरी कैश मेमोरी उसे हार्डलिंक करेगी. इसका मकसद डिस्क में जगह बचाना है.
टैग: bazel_internal_configuration
--experimental_repository_downloader_retries=<an integer> default: "0": डाउनलोड करने में हुई गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental
--experimental_scale_timeouts=<a double> default: "1.0": इस फ़ैक्टर के हिसाब से, Starlark के डेटाबेस नियमों में सभी टाइमआउट को स्केल करें. इस तरह, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले व्यक्ति की उम्मीद से ज़्यादा समय लेती हैं. इसके लिए, सोर्स कोड में बदलाव करने की ज़रूरत नहीं होती
टैग: bazel_internal_configuration, experimental
--http_connector_attempts=<an integer> default: "8": एचटीटीपी डाउनलोड के लिए, कोशिशों की ज़्यादा से ज़्यादा संख्या.
टैग: bazel_internal_configuration
--http_connector_retry_max_timeout=<An immutable length of time.> default: "0s": एचटीटीपी डाउनलोड करने की कोशिशों के लिए, ज़्यादा से ज़्यादा टाइम आउट. वैल्यू 0 होने पर, ज़्यादा से ज़्यादा समयसीमा तय नहीं की जाती.
टैग: bazel_internal_configuration
--http_timeout_scaling=<a double> default: "1.0": एचटीटीपी डाउनलोड से जुड़े सभी टाइमआउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग: bazel_internal_configuration
--repository_cache=<a path> डिफ़ॉल्ट: ब्यौरा देखें: यह डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह के बारे में बताता है. ये वैल्यू, बाहरी रिपॉज़िटरी से फ़ेच की जाती हैं. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग का इस्तेमाल करने पर, कैश मेमोरी को बंद करने का अनुरोध किया जाता है. ऐसा न करने पर, डिफ़ॉल्ट तौर पर '<output_user_root>/cache/repos/v1' का इस्तेमाल किया जाता है
टैग: bazel_internal_configuration
--[no]repository_disable_download डिफ़ॉल्ट: "false": अगर यह सेट है, तो रिपॉज़िटरी फ़ेच करने के दौरान ctx.download{,_and_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है. ctx.execute अब भी इंटरनेट ऐक्सेस करने वाले किसी भी एक्ज़ीक्यूटेबल को चला सकता है.
टैग: bazel_internal_configuration
--[no]run default: "true": अगर यह वैल्यू 'गलत है' पर सेट है, तो बनाए गए टारगेट के लिए बनाई गई कमांड लाइन को चलाने की प्रोसेस छोड़ दें.
टैग: affects_outputs

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

शटडाउन के विकल्प

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

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

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

--[no]configure डिफ़ॉल्ट: "False": सिर्फ़ उन रिपॉज़िटरी को सिंक करें जिन्हें सिस्टम कॉन्फ़िगरेशन के मकसद से 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है.
टैग: changes_inputs
--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations
--[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
--only=<a string> कई बार इस्तेमाल किया गया हो: अगर यह विकल्प दिया गया है, तो सिर्फ़ उन रिपॉज़िटरी को सिंक करें जिनके लिए यह विकल्प दिया गया है. अब भी सभी (या --configure विकल्प दिए जाने पर, कॉन्फ़िगरेशन से मिलते-जुलते सभी) विकल्पों को पुराना माना जाता है.
टैग: changes_inputs

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string> default: "": अगर यह फ़ील्ड खाली नहीं है, तो उन सभी Starlark रिपॉज़िटरी नियमों की हल की गई जानकारी के साथ एक Starlark वैल्यू लिखें जिन्हें लागू किया गया था.
टैग: affects_outputs

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

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

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

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.
--[no]print_relative_test_log_paths डिफ़ॉल्ट: "false": अगर यह सही है, तो टेस्ट लॉग का पाथ प्रिंट करते समय, ऐसे रिलेटिव पाथ का इस्तेमाल करें जो 'testlogs' सुविधा वाले सिमलंक का इस्तेमाल करता है. ध्यान दें - अलग कॉन्फ़िगरेशन के साथ 'बिल्ड'/'टेस्ट'/वगैरह को बाद में इनवोक करने से, इस सिंबल लिंक का टारगेट बदल सकता है. इससे पहले प्रिंट किया गया पाथ अब काम नहीं करेगा.
टैग: affects_outputs
--[no]test_verbose_timeout_warnings डिफ़ॉल्ट: "false": अगर यह वैल्यू सही पर सेट है, तो टेस्ट के असल में पूरा होने में लगने वाला समय, टेस्ट के लिए तय किए गए टाइम आउट से मेल न खाने पर, अतिरिक्त चेतावनियां प्रिंट करें. टाइम आउट, टेस्ट के लिए तय किया गया समय होता है. यह समय, टेस्ट के लिए साफ़ तौर पर या अनुमान के आधार पर तय किया जा सकता है.
टैग: affects_outputs
--[no]verbose_test_summary default: "true": अगर यह विकल्प चुना जाता है, तो टेस्ट की खास जानकारी में अतिरिक्त जानकारी (समय, टेस्ट के पूरे न हो पाने की संख्या वगैरह) प्रिंट करें.
टैग: affects_outputs

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": यह बताता है कि मेमोरी में मौजूद डेटा का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर पड़ने वाले दबाव से जुड़े इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

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

--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 डिफ़ॉल्ट: "false": अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `dev_dependency` के तौर पर एलान किए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel फ़ाइल रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू कुछ भी हो, MODULE.bazel फ़ाइल में हमेशा dev dependencies को अनदेखा किया जाता है.
टैग: loading_and_analysis
--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "update": इससे यह तय होता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. मान्य वैल्यू ये हैं: `update` का इस्तेमाल लॉकफ़ाइल का इस्तेमाल करने और उसमें बदलाव होने पर उसे अपडेट करने के लिए किया जाता है, `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

--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
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं होगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट रूप से, इसकी वैल्यू Integer.MAX_VALUE होती है. इसका मतलब है कि इसकी कोई सीमा नहीं होती. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर 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]experimental_command_profile डिफ़ॉल्ट: "false": यह कमांड, Java फ़्लाइट रिकॉर्डर की सीपीयू प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद profile.jfr फ़ाइल में रिकॉर्ड करती है. अलग-अलग तरह की प्रोफ़ाइलों या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमैंटिक में आने वाले समय में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "false": डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या को 20 निमोनिक तक सीमित किया जाता है. ये वे निमोनिक होते हैं जिनके लिए सबसे ज़्यादा कार्रवाइयां की गई हैं. इस विकल्प को सेट करने पर, सभी नेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन की शुरुआत किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से होती है. इसके बाद, या तो होस्ट का नाम (for `allow` and `block`) या दो पैटर्न होते हैं. इनमें से एक पैटर्न का इस्तेमाल मैच करने के लिए किया जाता है और दूसरे का इस्तेमाल विकल्प के तौर पर यूआरएल के लिए किया जाता है. इसमें बैक-रेफ़रंस की शुरुआत `$1` से होती है. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. ऐसे में, कई यूआरएल दिखाए जाएंगे.
--experimental_worker_for_repo_fetching=<off, platform or virtual> default: "off": Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर प्लैटफ़ॉर्म थ्रेड (यानी कि ओएस थ्रेड) का इस्तेमाल करता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करता है.

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो: <repository name>=<path> के फ़ॉर्मैट में, किसी रिपॉज़िटरी को लोकल पाथ से बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, `bazel info workspace` का आउटपुट होता है

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

`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`	यह विकल्प अब उपलब्ध नहीं है. ऐसा हो सकता है कि जिस सुविधा पर इसका असर पड़ता है वह बंद हो गई हो या जानकारी देने के किसी दूसरे तरीके को प्राथमिकता दी जा रही हो.