रिलीज़ होने वाले किसी भी वर्शन की जानकारी देने वाले दस्तावेज़ के लिए, कृपया "वर्शन दस्तावेज़" ड्रॉप-डाउन का इस्तेमाल करें. डिफ़ॉल्ट व्यू, head पर सबसे नए वर्शन को दिखाता है.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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`	यह बैजल विकल्पों की सूची को कैननिकल बनाता है.
`clean`	आउटपुट फ़ाइलों को हटाता है और वैकल्पिक रूप से सर्वर को रोकता है.
`coverage`	तय किए गए टेस्ट टारगेट के लिए, कोड कवरेज रिपोर्ट जनरेट करता है.
`cquery`	कॉन्फ़िगरेशन के साथ तय किए गए टारगेट को लोड करता है, उनका विश्लेषण करता है, और क्वेरी करता है.
`dump`	बेज़ेल सर्वर प्रोसेस की अंदरूनी स्थिति को डंप करता है.
`fetch`	डेटा स्टोर करने की ऐसी बाहरी जगह को फ़ेच करता है जो टारगेट सेट करने के लिए ज़रूरी शर्तें हैं.
`help`	कमांड या इंडेक्स को प्रिंट करने से जुड़ी मदद पाएं.
`info`	bazel सर्वर के बारे में रनटाइम की जानकारी दिखाता है.
`license`	इस सॉफ़्टवेयर का लाइसेंस प्रिंट करता है.
`mobile-install`	मोबाइल डिवाइस पर लक्ष्य इंस्टॉल करता है.
`mod`	Bzlmod बाहरी डिपेंडेंसी ग्राफ़ पर क्वेरी करता है
`print_action`	फ़ाइल को कंपाइल करने के लिए, कमांड लाइन आर्ग्युमेंट को प्रिंट करता है.
`query`	डिपेंडेंसी ग्राफ़ क्वेरी चलाता है.
`run`	तय किए गए टारगेट को चलाता है.
`shutdown`	यह बैजल सर्वर को बंद करता है.
`sync`	फ़ाइल फ़ोल्डर फ़ाइल में बताए गए सभी डेटा स्टोर करने की जगहों को सिंक करता है
`test`	खास टेस्ट टारगेट बनाता और चलाता है.
`vendor`	बाहरी डेटा स्टोर करने की जगहों को किसी खास फ़ोल्डर में फ़ेच करता है. यह फ़ोल्डर --vendor_der से तय किया जाता है.
`version`	bazel के लिए वर्शन की जानकारी प्रिंट करता है.

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

--[no]autodetect_server_javabase डिफ़ॉल्ट: "सही": --noautodetect_server_javabase पास होने के बाद, Bazel, bazel सर्वर चलाने के लिए लोकल JDK का इस्तेमाल करने के बजाय बाहर निकल जाता है.
टैग: affects_outputs, loses_incremental_state
--[no]batch डिफ़ॉल्ट: "गलत": अगर सेट हो, तो Bazel को स्टैंडर्ड क्लाइंट/सर्वर मोड के बजाय, बिना सर्वर के सिर्फ़ एक क्लाइंट प्रोसेस के तौर पर चलाया जाएगा. इसे अब बंद कर दिया जाएगा. साथ ही, इसे हटा दिया जाएगा. अगर आपको सर्वर को बार-बार बंद नहीं करना है, तो कृपया इसे बंद कर दें.
टैग: loses_incremental_state, bazel_internal_configuration, deprecated
--[no]batch_cpu_scheduling डिफ़ॉल्ट: "गलत": सिर्फ़ Linux पर; Blaze के लिए 'बैच' सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति ऐसे वर्कलोड के लिए फ़ायदेमंद है जो नॉन-इंटरैक्टिव हैं, लेकिन उनकी अहमियत को कम नहीं करना चाहते. 'पुरुष 2 sched_setScheduler' को देखें. गलत होने पर, Bazel सिस्टम कॉल नहीं करेगा.
टैग: host_machine_resource_optimizations
--bazelrc=<path> डिफ़ॉल्ट: विवरण देखें: उपयोगकर्ता की .bazelrc फ़ाइल की जगह, जिसमें Bazel विकल्पों की डिफ़ॉल्ट वैल्यू शामिल हैं. /dev/null यह बताता है कि आगे सभी `--bazelrc`को अनदेखा किया जाएगा. इससे उपयोगकर्ता की आरसी फ़ाइल खोजने की सुविधा बंद करने में मदद मिलती है, जैसे कि रिलीज़ बिल्ड में. इस विकल्प को एक से ज़्यादा बार भी सेट किया जा सकता है. उदाहरण के लिए, `--bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc`, 1) x.rc और y.rc पढ़ें. 2) पिछले /dev/null की वजह से, z.rc को अनदेखा कर दिया गया है. इसकी जानकारी न देने पर, Bazel पहली .bazelrc फ़ाइल का इस्तेमाल करता है, जो उसे इन दो जगहों पर मिलती है: फ़ाइल फ़ोल्डर की डायरेक्ट्री और फिर उपयोगकर्ता की होम डायरेक्ट्री. ध्यान दें: कमांड लाइन विकल्प, bazelrc में किसी भी विकल्प की जगह हमेशा लागू होंगे.
टैग: changes_inputs
--[no]block_for_lock डिफ़ॉल्ट: "सही": --noblock_for_lock पास हो जाने पर, Bazel किसी मौजूदा कमांड के पूरा होने का इंतज़ार नहीं करता. इसके बजाय, वह तुरंत बाहर निकल जाता है.
टैग: eagerness_to_exit
--[no]client_debug डिफ़ॉल्ट: "गलत": अगर सही है, तो क्लाइंट से stderr पर डीबग की जानकारी को लॉग करें. इस विकल्प को बदलने से सर्वर रीस्टार्ट नहीं होगा.
टैग: affects_outputs, bazel_monitoring
--connect_timeout_secs=<an integer> डिफ़ॉल्ट: "30": सर्वर से कनेक्ट करने की हर कोशिश के लिए क्लाइंट को कितनी देर इंतज़ार करना पड़ता है
टैग: bazel_internal_configuration
--digest_function=<hash function> डिफ़ॉल्ट: विवरण देखें: फ़ाइल डाइजेस्ट की गणना करते समय इस्तेमाल किया जाने वाला हैश फ़ंक्शन.
टैग: loses_incremental_state, bazel_internal_configuration
--[no]expand_configs_in_place डिफ़ॉल्ट: "सही": --कॉन्फ़िगरेशन फ़्लैग का दायरा बढ़ाया गया है, ताकि इसे सामान्य तरीके से आरसी विकल्पों और कमांड लाइन के बताए गए विकल्पों के बीच एक तय पॉइंट से बड़ा किया जा सके.
टैग: no_op, deprecated
--failure_detail_out=<path> डिफ़ॉल्ट: विवरण देखें: अगर इस नीति को सेट किया जाता है, तो यह ऐसी जगह के बारे में बताता है जहां सर्वर के गड़बड़ी होने का पता चलता है. साथ ही, आम तौर पर gRPC के ज़रिए इसकी रिपोर्ट नहीं की जा सकती. ऐसे में, यह Protobuf मैसेज लिखने के लिए जगह की जानकारी देता है. अगर ऐसा नहीं है, तो जगह की जानकारी ${OUTPUT_BASE}/failure_detail.rawproto पर सेट हो जाएगी.
टैग: affects_outputs, loses_incremental_state
--[no]home_rc डिफ़ॉल्ट: "सही": $Home/.bazelrc पर होम bazelrc फ़ाइल को खोजना है या नहीं
टैग: changes_inputs
--[no]idle_server_tasks डिफ़ॉल्ट: "सही": जब सर्वर कुछ समय से इस्तेमाल में न हो, तब System.gc() चलाएं
टैग: loses_incremental_state, host_machine_resource_optimizations
--[no]ignore_all_rc_files डिफ़ॉल्ट: "गलत": सभी आरसी फ़ाइलों को बंद कर देता है. इस बात से कोई फ़र्क़ नहीं पड़ता कि आरसी में बदलाव करने वाले अन्य फ़्लैग की वैल्यू कुछ भी हैं, भले ही ये फ़्लैग, स्टार्टअप के विकल्पों की सूची में बाद में आएं.
टैग: changes_inputs
--io_nice_level={-1,0,1,2,3,4,5,6,7} डिफ़ॉल्ट: "-1": सिर्फ़ Linux पर; sys_ioprio_set सिस्टम कॉल का इस्तेमाल करके, IO को सबसे अच्छी तरह शेड्यूल करने के लिए, 0-7 तक का लेवल सेट करें. सबसे ऊंची प्राथमिकता 0 है, सबसे कम प्राथमिकता 7 है. ऐसा हो सकता है कि शेड्यूलर सिर्फ़ चौथी प्राथमिकता पर काम करे. अगर वैल्यू नेगेटिव पर सेट की जाती है, तो Bazel सिस्टम कॉल नहीं करेगा.
टैग: host_machine_resource_optimizations
--local_startup_timeout_secs=<an integer> डिफ़ॉल्ट: "120": सर्वर से कनेक्ट होने के लिए क्लाइंट को ज़्यादा से ज़्यादा कितनी देर इंतज़ार करना होगा
टैग: bazel_internal_configuration
--macos_qos_class=<a string> डिफ़ॉल्ट: "डिफ़ॉल्ट": macOS पर चलाते समय, bazel सर्वर की QoS सेवा क्लास सेट करती है. इस फ़्लैग का दूसरे सभी प्लैटफ़ॉर्म पर कोई असर नहीं पड़ता. हालांकि, यह इस बात को पक्का करने के लिए काम करता है कि आरसी फ़ाइलों को बिना बदलाव के उनके बीच शेयर किया जा सके. संभावित वैल्यू ये हैं: यूज़र-इंटरैक्टिव, यूज़र-इनीशिएटेड, डिफ़ॉल्ट, उपयोगिता, और बैकग्राउंड.
टैग: host_machine_resource_optimizations
--max_idle_secs=<integer> डिफ़ॉल्ट: "10800": बिल्ड सर्वर बंद होने से पहले, कितने सेकंड तक इंतज़ार करेगा. शून्य का मतलब है कि सर्वर कभी भी शटडाउन नहीं होगा. इसे सिर्फ़ सर्वर चालू होने पर पढ़ा जाता है. इस विकल्प को बदलने से सर्वर रीस्टार्ट नहीं होगा.
टैग: eagerness_to_exit, loses_incremental_state
--output_base=<path> डिफ़ॉल्ट: विवरण देखें: अगर यह सेट है, तो आउटपुट की उस जगह के बारे में बताता है जहां सभी बिल्ड आउटपुट लिखा जाएगा. अगर ऐसा नहीं है, तो जगह की जानकारी ${OUTPUT_ROOT}/_blaze_${USER}/${MD5_OF_ हमSPACE_ROOT} होगी. ध्यान दें: अगर इस वैल्यू के लिए, Bazel के अगले न्योते में किसी एक से अलग विकल्प चुना जाता है, तो हो सकता है कि आप एक नया, अतिरिक्त Bazel सर्वर शुरू कर दें. Bazel हर आउटपुट बेस के लिए, एक सर्वर शुरू करता है. आम तौर पर, हर फ़ाइल फ़ोल्डर में एक आउटपुट बेस होता है. हालांकि, इस विकल्प का इस्तेमाल करने पर आपके हर फ़ाइल फ़ोल्डर में कई आउटपुट बेस हो सकते हैं. इस तरह, एक ही क्लाइंट के लिए एक ही मशीन पर एक साथ कई बिल्ड चलाए जा सकते हैं. Bazel सर्वर को बंद करने का तरीका जानने के लिए, 'bazel help शटडाउन' देखें.
टैग: affects_outputs, loses_incremental_state
--output_user_root=<path> डिफ़ॉल्ट: विवरण देखें: किसी उपयोगकर्ता के लिए खास डायरेक्ट्री, जिसके नीचे सभी बिल्ड आउटपुट लिखे जाते हैं. डिफ़ॉल्ट रूप से, यह $USER का फ़ंक्शन होता है. हालांकि, इसमें एक नियतांक चुनकर, बिल्ड आउटपुट को सहयोगी उपयोगकर्ताओं के बीच शेयर किया जा सकता है.
टैग: affects_outputs, loses_incremental_state
--[no]preemptible डिफ़ॉल्ट: "गलत": सही होने पर, कोई दूसरा निर्देश शुरू होने पर, इस निर्देश को रोका जा सकता है.
टैग: eagerness_to_exit
--server_jvm_out=<path> डिफ़ॉल्ट: विवरण देखें: सर्वर के जेवीएम का आउटपुट लिखने के लिए जगह. अगर इस नीति को सेट नहीं किया जाता है, तो आउटपुट_बेस में जगह डिफ़ॉल्ट रूप से सेट होती है.
टैग: affects_outputs, loses_incremental_state
--[no]shutdown_on_low_sys_mem डिफ़ॉल्ट: "गलत": अगर max_idle_secs सेट है और बिल्ड सर्वर कुछ समय के लिए इस्तेमाल में नहीं है, तो सिस्टम में बिना रैम कम होने पर सर्वर को बंद कर दें. सिर्फ़ Linux पर.
टैग: eagerness_to_exit, loses_incremental_state
--[no]system_rc डिफ़ॉल्ट: "सही": पूरे सिस्टम में bazelrc को खोजना है या नहीं, यह देखना है या नहीं.
टैग: changes_inputs
--[no]unlimit_coredumps डिफ़ॉल्ट: "गलत": सॉफ़्ट कोरडंप की सीमा को हार्ड लिमिट तक बढ़ाता है, ताकि सामान्य स्थितियों में सर्वर और क्लाइंट के कोरडंप बनाए जा सकें. इस फ़्लैग को अपने बाज़ार में एक बार लगाएं और इसके बारे में भूल जाएं. ऐसा करने से, अगर आपको असल में किसी ऐसी स्थिति का सामना करना पड़ता है जिससे कोरडंप ट्रिगर होते हैं, तो आपको कोरडंप मिल जाएंगे.
टैग: bazel_internal_configuration
--[no]watchfs डिफ़ॉल्ट: "गलत": अगर सही है, तो bazel स्थानीय बदलावों के लिए हर फ़ाइल को स्कैन करने के बजाय, ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करता है.
टैग: deprecated
--[no]windows_enable_symlinks डिफ़ॉल्ट: "गलत": अगर सही है, तो फ़ाइल को कॉपी करने के बजाय, Windows पर असली सिंबॉलिक लिंक बनाए जाएंगे. इसके लिए, Windows डेवलपर मोड को चालू करना और Windows 10 का 1703 या इसके बाद का वर्शन इंस्टॉल करना ज़रूरी है.
टैग: bazel_internal_configuration
--[no]workspace_rc डिफ़ॉल्ट: "सही": $workspace/.bazelrc पर फ़ाइल फ़ोल्डर bazelrc फ़ाइल खोजे जाने या न खोजने की सुविधा
टैग: changes_inputs

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

सभी कमांड के लिए आम तौर पर इस्तेमाल होने वाले विकल्प

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

--[no]incompatible_enable_proto_toolchain_resolution डिफ़ॉल्ट: "गलत": अगर सही है, तो प्रोटो भाषा के नियम, criteria_proto, rules_java, rules_cc डेटा स्टोर करने वालों के टूलटिप तय करते हैं.
टैग: loading_and_analysis, incompatible_change

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

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

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

--[no]enable_bzlmod डिफ़ॉल्ट: "सही": अगर वैल्यू सही है, तो Bzlmod डिपेंडेंसी मैनेजमेंट सिस्टम चालू हो जाता है. साथ ही, इसे Workspace की जगह प्राथमिकता दी जाती है. ज़्यादा जानकारी के लिए, https://bazel.build/docs/bzlmod देखें.
टैग: loading_and_analysis
--[no]enable_workspace डिफ़ॉल्ट: "सही": अगर नीति सही है, तो बाहरी डिपेंडेंसी के लिए लेगसी Workspace सिस्टम को चालू करता है. ज़्यादा जानकारी के लिए, https://bazel.build/external/overview पर जाएं.
टैग: loading_and_analysis
--[no]experimental_action_resource_set डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो लोकल एक्ज़ीक्यूशन के लिए ctx.actions.run() और ctx.actions.run_shell() संसाधन_set पैरामीटर स्वीकार होते हैं. ऐसा न करने पर, मेमोरी के लिए यह डिफ़ॉल्ट रूप से 250 एमबी और एक सीपीयू होगा.
टैग: execution, build_file_semantics, experimental
--[no]experimental_bzl_visibility डिफ़ॉल्ट: "सही": यह सुविधा चालू होने पर, ` visibility()` फ़ंक्शन जुड़ जाता है, जिसे .bzl फ़ाइलें, टॉप लेवल की जांच के दौरान कॉल कर सकती हैं. ऐसा करके, यह तय किया जा सकता है कि load() स्टेटमेंट के लिए, फ़ाइलें किसको दिखें.
टैग: loading_and_analysis, experimental
--[no]experimental_cc_shared_library डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो cc_shared_library नियम के लिए ज़रूरी नियम एट्रिब्यूट और Starlark API के तरीके उपलब्ध होंगे
टैग: build_file_semantics, loading_and_analysis, experimental
--[no]experimental_disable_external_package डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तो अपने-आप जनरेट हुआ //external पैकेज उपलब्ध नहीं होगा. Bazel अब भी 'external/BUILD' फ़ाइल को पार्स नहीं कर पाएगा. हालांकि, बिना नाम वाले पैकेज के लिए बाहरी/ तक पहुंचने वाले ग्लोब काम करेंगे.
टैग: loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_enable_android_migration_apis डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो Android Starlark माइग्रेशन के लिए ज़रूरी एपीआई चालू करता है.
टैग: build_file_semantics
--[no]experimental_enable_first_class_macros डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो फ़र्स्ट-क्लास मैक्रो तय करने के लिए `macro()` कंस्ट्रक्शन चालू करता है.
टैग: build_file_semantics
--[no]experimental_enable_scl_dialect डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो .scl फ़ाइलों को load() स्टेटमेंट में इस्तेमाल किया जा सकता है.
टैग: build_file_semantics
--[no]experimental_google_legacy_api डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो यह Google के लेगसी कोड से जुड़े Starlark बिल्ड एपीआई के प्रयोग के तौर पर उपलब्ध कई हिस्सों को दिखाता है.
टैग: loading_and_analysis, experimental
--[no]experimental_isolated_extension_usages डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो <a href="https://bazel.build/rules/lib/globals/module#use_extension"><code>use_extension</code></a> में<code>आइसोलेट</code> पैरामीटर चालू करता है.
टैग: loading_and_analysis
--[no]experimental_java_library_export डिफ़ॉल्ट: "गलत": यह सुविधा चालू होने पर, प्रयोग के तौर पर दी गई_java_library_export_do_not_use मॉड्यूल उपलब्ध होता है.
टैग: loading_and_analysis, incompatible_change
--[no]experimental_platforms_api डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो प्लैटफ़ॉर्म से जुड़े Starlark एपीआई को डीबग करने में मदद मिलती है.
टैग: loading_and_analysis, experimental
--[no]experimental_repo_remote_exec डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो रिपॉज़िटरी_रूल का इस्तेमाल करने पर, रिमोट तरीके से कुछ फ़ंक्शन लागू किए जा सकते हैं.
टैग: build_file_semantics, loading_and_analysis, experimental
--[no]experimental_sibling_repository_layout डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो नॉन-मुख्य डेटा स्टोर करने की जगहें, एक्ज़ीक्यूशन रूट में मुख्य रिपॉज़िटरी के सिमलिंक के तौर पर लगाई जाती हैं. इसका मतलब है कि डेटा स्टोर करने की सभी जगहें, $OUT_base/execution_root डायरेक्ट्री के डायरेक्ट चिल्ड्रन हैं. इसका 'आउटपुट असर' होता है, क्योंकि टॉप लेवल की असल 'external' डायरेक्ट्री के लिए, $OUT_base/execution_root/__main__/external को खाली करने का खराब असर पड़ता है.
टैग: action_command_lines, bazel_internal_configuration, loading_and_analysis, loses_incremental_state, experimental
--[no]incompatible_allow_tags_propagation डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो टैग को टारगेट से, कार्रवाइयां करने की ज़रूरी शर्तों के हिसाब से लागू किया जाएगा. ऐसा न होने पर, टैग लागू नहीं होंगे. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/8830 देखें.
टैग: build_file_semantics, experimental
--[no]incompatible_always_check_depset_elements डिफ़ॉल्ट: "सही": देखें कि हर कंस्ट्रक्टर में, डिसेट में जोड़े गए एलिमेंट मान्य हैं या नहीं. एलिमेंट ऐसे होने चाहिए जिनमें बदलाव न किया जा सके, लेकिन ऐतिहासिक तौर पर depset(direct=...) कंस्ट्रक्टर जांच करना भूल गया. डेपसेट एलिमेंट में सूचियों के बजाय, टपल का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10313 देखें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_depset_for_libraries_to_link_getter डिफ़ॉल्ट: "सही": सही होने पर, Bazel Linking_context.libraries_to_link से कोई सूची नहीं दिखाता है, लेकिन इसके बजाय डिपसेट दिखाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disable_objc_library_transition डिफ़ॉल्ट: "सही": इसके बजाय, objc_library का कस्टम ट्रांज़िशन बंद करके टॉप लेवल टारगेट से इनहेरिट करें
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_starlark_host_transitions डिफ़ॉल्ट: "गलत": अगर 'सही है' पर सेट किया जाता है, तो नियम के एट्रिब्यूट, 'cfg = "host"' को सेट नहीं कर सकते. नियमों में इसके बजाय 'cfg = "exec"' सेट होना चाहिए.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disable_target_default_provider_fields डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स के ज़रिए 'टारगेट' ऑब्जेक्ट पर, सेवा देने वाली कंपनियों को ऐक्सेस करने की सुविधा बंद करें. इसके बजाय, प्रोवाइडर-की सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, नियम लागू करने वाले फ़ंक्शन में `my_info` को ऐक्सेस करने के लिए, `ctx.attr.dep.my_info` का इस्तेमाल करने के बजाय, `ctx.attr.dep[MyInfo]` का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/9014 देखें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_target_provider_fields डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स के ज़रिए डिफ़ॉल्ट कंपनी को इस्तेमाल करने की सुविधा को बंद करें. इसके बजाय, प्रोवाइडर-की सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, `फ़ाइलों` को ऐक्सेस करने के लिए `ctx.attr.dep.files` का इस्तेमाल करने के बजाय, `ctx.attr.dep[DefaultInfo].files का इस्तेमाल करें, ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/9014 देखें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disallow_empty_glob डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तो ग्लोब() के `allow_Empty` आर्ग्युमेंट की डिफ़ॉल्ट वैल्यू 'गलत' होती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disallow_struct_provider_syntax डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो हो सकता है कि नियम लागू करने वाले फ़ंक्शन कोई निर्देश न दें. इसके बजाय, उन्हें प्रोवाइडर इंस्टेंस की सूची दिखानी होगी.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_enable_deprecated_label_apis डिफ़ॉल्ट: "सही": चालू होने पर, काम न करने वाले कुछ एपीआई (native.repository_name, लेबल.workspace_name, लेबल.relative) का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis
--[no]incompatible_existing_rules_immutable_view डिफ़ॉल्ट: "सही": अगर इसे true पर सेट किया जाता है, तो local.existing_ rules और local.existing_rules, बदले जा सकने वाले डिक्शनरी के बजाय, हल्के नहीं बदले जा सकने वाले व्यू ऑब्जेक्ट हैं.
टैग: build_file_semantics, loading_and_analysis, incompatible_change
--[no]incompatible_fail_on_unknown_attributes डिफ़ॉल्ट: "सही": यह सुविधा चालू होने पर, ऐसे टारगेट पूरे नहीं हो पाते जिनके लिए, 'कोई भी नहीं' एट्रिब्यूट की जानकारी मौजूद नहीं है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_fix_package_group_reporoot_syntax डिफ़ॉल्ट: "सही": पैकेज_ग्रुप के `packages` एट्रिब्यूट में, किसी भी रिपॉज़िटरी (डेटा स्टोर करने की जगह) में मौजूद सभी पैकेज के बजाय, मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज को दिखाने के लिए, "//..." वैल्यू का मतलब बदला जाता है. पुराने तरीके का पता लगाने के लिए, "//..." की जगह "public" में बदलाव करने की खास वैल्यू का इस्तेमाल किया जा सकता है. इस फ़्लैग के लिए --insupported_package_group_has_public_syntax को भी सक्षम किया जाना ज़रूरी है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_java_common_parameters डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो पैक_sources में आउटपुट_जार और होस्ट_जावबेस पैरामीटर और कंपाइल में मौजूद Host_javabase पैरामीटर हटा दिए जाएंगे.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_merge_fixed_and_default_shell_env डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू है, तो 'env' और 'use_default_shell_env = True', दोनों के साथ ctx.actions.run और ctx.actions.run_shell के साथ रजिस्टर की गई कार्रवाइयां, 'env' में पास की जाने वाली वैल्यू को बदलकर, डिफ़ॉल्ट शेल एनवायरमेंट से मिले एनवायरमेंट का इस्तेमाल करेंगी. अगर यह सेटिंग बंद होती है, तो इस मामले में 'env' की वैल्यू को पूरी तरह से अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_no_attr_license डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो `attr.lice` फ़ंक्शन को बंद करता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_no_implicit_file_export डिफ़ॉल्ट: "गलत": अगर इस नीति को सेट किया जाता है, तो (इस्तेमाल की गई) सोर्स फ़ाइलें तब तक निजी रहती हैं, जब तक कि इन्हें साफ़ तौर पर एक्सपोर्ट नहीं किया जाता. 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 डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो Starlark फ़ंक्शन के `role()` के `आउटपुट` पैरामीटर को बंद करता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_package_group_has_public_syntax डिफ़ॉल्ट: "सही": package_group के `packages` एट्रिब्यूट में, सभी पैकेजों या कोई पैकेज नहीं के बारे में बताने के लिए, "public" या "private" लिखने की सुविधा मिलती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_require_linker_input_cc_api डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो user create_linking_context के लिए Library_to_link के बजाय linker_inputs की ज़रूरत होगी. Linking_context के पुराने गेटर भी बंद हो जाएंगे और सिर्फ़ linker_inputs उपलब्ध रहेंगे.
टैग: build_file_semantics, loading_and_analysis, incompatible_change
--[no]incompatible_run_shell_command_string डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो actions.run_shell का कमांड पैरामीटर सिर्फ़ स्ट्रिंग स्वीकार करेगा
टैग: build_file_semantics, incompatible_change
--[no]incompatible_stop_exporting_build_file_path डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तो काम नहीं करने वाला ctx.build_file_path उपलब्ध नहीं होगा. इसकी जगह, ctx.label.package + '/BUILD' का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_stop_exporting_language_modules डिफ़ॉल्ट: "गलत": अगर यह सेटिंग चालू होती है, तो उपयोगकर्ता की .bzl फ़ाइलों में भाषा के हिसाब से बने कुछ खास मॉड्यूल (जैसे, `cc_Common`) उपलब्ध नहीं होंगे. इन्हें सिर्फ़ उनसे जुड़े नियमों को स्टोर करने की जगहों से ही कॉल किया जा सकता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_struct_has_no_methods डिफ़ॉल्ट: "सही": स्ट्रक्चर के 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 डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो टॉप लेवल वाली इमेज, ज़रूरी कंपनियों के हिसाब से होगी. साथ ही, यह टॉप लेवल के उन टारगेट पर ही काम करेगी जिनके नियमों के मुताबिक, विज्ञापन देने वाली कंपनियां ज़रूरी कंपनियों को पूरा करती हैं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_unambiguous_label_stringification डिफ़ॉल्ट: "सही": सही होने पर, 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 डिफ़ॉल्ट: "गलत": सही होने पर, Bazel @bazel_tools से cc_Configure का इस्तेमाल करने की अनुमति नहीं देगा. माइग्रेट करने से जुड़े निर्देशों और ज़्यादा जानकारी के लिए, कृपया https://github.com/bazelbuild/bazel/issues/10134 देखें.
टैग: loading_and_analysis, incompatible_change
--max_computation_steps=<a long integer> डिफ़ॉल्ट: "0": स्टारलार्क कंप्यूटेशन के तरीकों की ज़्यादा से ज़्यादा संख्या, जिसे BUILD फ़ाइल की मदद से लागू किया जा सकता है. शून्य का मतलब है कि कोई सीमा नहीं है.
टैग: build_file_semantics
--nested_set_depth_limit=<an integer> डिफ़ॉल्ट: "3500": ग्राफ़ के अंदरूनी हिस्से में, किसी depset (इसे NestedSet भी कहा जाता है) का सबसे ज़्यादा डेप्थ भी होता है. इसके ऊपर, depset() कंस्ट्रक्टर काम नहीं करेगा.
टैग: loading_and_analysis

--[no]heuristically_drop_nodes डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो मेमोरी सेव करने के लिए ब्लेज़, FileState और DirectoryListingState नोड से जुड़ी जानकारी को हटा देगा. हमें उम्मीद है कि इन नोड की ज़रूरत फिर से कम होगी. अगर ऐसा है, तो कार्यक्रम उनकी फिर से समीक्षा करेगा.
टैग: loses_incremental_state
--[no]incompatible_do_not_split_linking_cmdline डिफ़ॉल्ट: "सही": सही होने पर, Bazel अब लिंक करने के लिए इस्तेमाल किए जाने वाले कमांड लाइन फ़्लैग में बदलाव नहीं करता. साथ ही, वह यह भी तय नहीं करता कि पैरामीटर फ़ाइल में कौनसे फ़्लैग भेजे जाएंगे और कौनसे नहीं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7670 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]keep_state_after_build डिफ़ॉल्ट: "सही": गलत होने पर, बिल्ड खत्म होने पर ब्लेज़, इस बिल्ड से इनमेमोरी स्थिति को मिटा देगा. इसके बाद के बिल्ड में कोई बढ़ोतरी नहीं होगी.
टैग: loses_incremental_state
--[no]track_incremental_state डिफ़ॉल्ट: "सही": गलत होने पर, Blaze ऐसे डेटा को बनाए नहीं रखेगा जो इंक्रीमेंटल (बढ़ने वाले) बिल्ड को अमान्य और फिर से जांच करने की अनुमति देता है, ताकि इस बिल्ड में मेमोरी सेव की जा सके. इसके बाद के बिल्ड में कोई बढ़ोतरी नहीं होगी. आम तौर पर, इसे 'गलत है' पर सेट करते समय, आपको --batch की जानकारी देनी होगी.
टैग: loses_incremental_state

--[no]announce_rc डिफ़ॉल्ट: "गलत": आरसी के विकल्पों की सूचना देनी है या नहीं.
टैग: affects_outputs
--[no]attempt_to_print_relative_paths डिफ़ॉल्ट: "गलत": मैसेज की जगह की जानकारी को प्रिंट करते समय, फ़ाइल फ़ोल्डर की डायरेक्ट्री या --package_path की तय की गई किसी डायरेक्ट्री या किसी डायरेक्ट्री से जुड़े पाथ का इस्तेमाल करें.
टैग: terminal_output
--bes_backend=<a string> डिफ़ॉल्ट: "": बिल्ड इवेंट सेवा (BES) बैकएंड एंडपॉइंट के बारे में जानकारी, [SCHEME://]Host[:PORT] फ़ॉर्म में देती है. डिफ़ॉल्ट तौर पर, यह BES अपलोड को बंद करता है. काम करने वाली स्कीम, grpc और grpcs (TLS चालू किए गए जीआरपीसी) हैं. अगर कोई स्कीम नहीं दी जाती है, तो Bazel grpcs को मान लेता है.
टैग: affects_outputs
--[no]bes_check_preceding_lifecycle_events डिफ़ॉल्ट: "गलत": PublisherBuildToolEventStreamRequest पर, check_preceding_lifecycle_events_present फ़ील्ड को सेट करता है, जिसकी मदद से BES को यह पता चलता है कि उसे पहले, InvocasimpactStarted और 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 डिफ़ॉल्ट: "सही": यह बताता है कि BES लाइफ़साइकल इवेंट को पब्लिश करना है या नहीं. (डिफ़ॉल्ट रूप से 'सही' होता है).
टैग: affects_outputs
--bes_oom_finish_upload_timeout=<An immutable length of time.> डिफ़ॉल्ट: "10 मिनट": यह बताता है कि ओओएमिंग के दौरान, BES/BEP अपलोड पूरा होने में कितने समय तक बैजल को अपलोड करना चाहिए. यह फ़्लैग पक्का करता है कि जब JVM को बहुत ज़्यादा जीसी थ्रैश किया जा रहा है और यह किसी उपयोगकर्ता थ्रेड पर प्रोग्रेस नहीं कर सकती, तो उसे बंद कर दिया जाता है.
टैग: bazel_monitoring
--bes_outerr_buffer_size=<an integer> डिफ़ॉल्ट: "10240": यह तय करता है कि BEP में stdout या stderr से ज़्यादा से ज़्यादा कितना डेटा बफ़र होगा. इसके बाद, इसे प्रोग्रेस इवेंट के तौर पर रिपोर्ट किया जा सकता है. हालांकि, हर उपयोगकर्ता के कॉन्टेंट को अब भी एक ही इवेंट में रिपोर्ट किया जाता है, भले ही वह वैल्यू, --bes_outerr_chunk_size तक दी गई वैल्यू से ज़्यादा हो.
टैग: affects_outputs
--bes_outerr_chunk_size=<an integer> डिफ़ॉल्ट: "1048576": यह बताता है कि एक मैसेज में BEP को भेजे जाने वाले stdout या stderr से ज़्यादा से ज़्यादा साइज़ क्या हो.
टैग: affects_outputs
--bes_proxy=<a string> डिफ़ॉल्ट: विवरण देखें: प्रॉक्सी के ज़रिए बिल्ड इवेंट सर्विस से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--bes_results_url=<a string> डिफ़ॉल्ट: "": उस बेस यूआरएल के बारे में जानकारी देता है जहां उपयोगकर्ता, BES बैकएंड पर स्ट्रीम की गई जानकारी देख सकता है. Bazel, टर्मिनल के लिए शुरू करने वाले आईडी से जुड़े यूआरएल को आउटपुट करेगा.
टैग: terminal_output
--bes_system_keywords=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: सूचना कीवर्ड की एक सूची के बारे में बताता है, जिसे सीधे शामिल किया जाना चाहिए. इसमें --bes_keyword के ज़रिए दिए गए कीवर्ड के लिए "user_keyword=" प्रीफ़िक्स शामिल नहीं होता है. यह उन बिल्ड सेवा ऑपरेटर के लिए है जो --bes_lifecycle_events=false को सेट करते हैं और PublishinglifecycleEvent को कॉल करते समय कीवर्ड शामिल करते हैं. इस फ़्लैग का इस्तेमाल करने वाले बिल्ड सेवा ऑपरेटर को उपयोगकर्ताओं को फ़्लैग वैल्यू बदलने से रोकना चाहिए.
टैग: affects_outputs
--bes_timeout=<An immutable length of time.> डिफ़ॉल्ट: "0s": यह बताता है कि बिल्ड और टेस्ट खत्म होने के बाद, BES/BEP अपलोड को पूरा होने में कितने समय तक बैजल को अपलोड करना चाहिए. समय खत्म होने का समय तय होना एक सामान्य संख्या है. इसके बाद एक इकाई होती है: दिन (d), घंटे (h), मिनट (m), सेकंड (से) और मिलीसेकंड (मिलीसेकंड). डिफ़ॉल्ट वैल्यू '0' है. इसका मतलब है कि कोई टाइम आउट नहीं है.
टैग: affects_outputs
--bes_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete": यह बताता है कि क्या बिल्ड इवेंट सेवा अपलोड को बिल्ड पूरा होने से ब्लॉक करना चाहिए या उसे तुरंत शुरू होने से रोकना चाहिए और अपलोड को बैकग्राउंड में पूरा करना चाहिए. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'complete_async'.
टैग: eagerness_to_exit
--build_event_binary_file=<a string> डिफ़ॉल्ट: "": अगर यह खाली नहीं है, तो उस फ़ाइल के लिए बिल्ड इवेंट प्रोटोकॉल का प्रतिनिधित्व करने के लिए वैरिंट डीलिमिटेड बाइनरी तरीके लिखें. यह विकल्प लागू करता है --bes_upload_mode=wait_for_upload_complete.
टैग: affects_outputs
--[no]build_event_binary_file_path_conversion डिफ़ॉल्ट: "सही": जब भी मुमकिन हो, बिल्ड इवेंट प्रोटोकॉल के बाइनरी फ़ाइल वर्शन में मौजूद पाथ को दुनिया भर में मान्य यूआरआई में बदलें. बंद होने पर, हमेशा file:// uri स्कीम का इस्तेमाल किया जाएगा
टैग: affects_outputs
--build_event_binary_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete": यह बताता है कि --build_event_binary_file के लिए बिल्ड इवेंट सेवा अपलोड को, बिल्ड पूरा होने से ब्लॉक करना चाहिए या शुरू करने की प्रोसेस को तुरंत खत्म करना चाहिए और बैकग्राउंड में अपलोड पूरा करना चाहिए. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'complete_async'.
टैग: eagerness_to_exit
--build_event_json_file=<a string> डिफ़ॉल्ट: "": अगर यह खाली नहीं है, तो उस फ़ाइल के लिए बिल्ड इवेंट प्रोटोकॉल का JSON सीरियलाइज़ेशन लिखें. यह विकल्प लागू करता है --bes_upload_mode=wait_for_upload_complete.
टैग: affects_outputs
--[no]build_event_json_file_path_conversion डिफ़ॉल्ट: "सही": जब भी मुमकिन हो, बिल्ड इवेंट प्रोटोकॉल के json फ़ाइल वर्शन में मौजूद पाथ को दुनिया भर में मान्य यूआरआई में बदलें. बंद होने पर, हमेशा file:// uri स्कीम का इस्तेमाल किया जाएगा
टैग: affects_outputs
--build_event_json_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete": यह बताता है कि --build_event_json_file के लिए अपलोड इवेंट सेवा को बिल्ड पूरा होने से रोकना चाहिए या नहीं या उसे शुरू करने की प्रोसेस को तुरंत खत्म करके, बैकग्राउंड में पूरा होना चाहिए या नहीं. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'complete_async'.
टैग: eagerness_to_exit
--build_event_max_named_set_of_file_entries=<an integer> डिफ़ॉल्ट: "5000": एक name_set_of_files इवेंट के लिए, एंट्री की ज़्यादा से ज़्यादा संख्या; दो से छोटी वैल्यू को अनदेखा किया जाता है और इवेंट को बांटा नहीं जाता है. यह बिल्ड इवेंट प्रोटोकॉल में, इवेंट के ज़्यादा से ज़्यादा साइज़ को सीमित करने के लिए है. हालांकि, यह सीधे तौर पर इवेंट के साइज़ को कंट्रोल नहीं करता. इवेंट का कुल साइज़, सेट के स्ट्रक्चर के साथ-साथ फ़ाइल और यूआरएल की लंबाई पर निर्भर करता है. यह साइज़, हैश फ़ंक्शन पर निर्भर कर सकता है.
टैग: affects_outputs
--[no]build_event_publish_all_actions डिफ़ॉल्ट: "गलत": सभी कार्रवाइयों को पब्लिश किया जाए या नहीं.
टैग: affects_outputs
--build_event_text_file=<a string> डिफ़ॉल्ट: "": अगर यह फ़ील्ड खाली नहीं है, तो उस फ़ाइल के लिए बिल्ड इवेंट प्रोटोकॉल को टेक्स्ट के तौर पर लिखें
टैग: affects_outputs
--[no]build_event_text_file_path_conversion डिफ़ॉल्ट: "सही": जब भी मुमकिन हो, बिल्ड इवेंट प्रोटोकॉल के टेक्स्ट फ़ाइल फ़ॉर्मैट में पाथ को दुनिया भर में मान्य यूआरआई में बदलें. बंद होने पर, हमेशा file:// uri स्कीम का इस्तेमाल किया जाएगा
टैग: affects_outputs
--build_event_text_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete": यह बताता है कि --build_event_text_file के लिए बिल्ड इवेंट सेवा अपलोड को, बिल्ड पूरा होने से रोकना चाहिए या नहीं या उसे शुरू करने की प्रोसेस को तुरंत खत्म करके, बैकग्राउंड में पूरा करना चाहिए या नहीं. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'complete_async'.
टैग: eagerness_to_exit
--build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4": Bzel को एक तय सीमा तक, किसी बिल्ड इवेंट को दोबारा अपलोड करने की कोशिश करनी चाहिए.
टैग: bazel_internal_configuration
--[no]experimental_announce_profile_path डिफ़ॉल्ट: "गलत": चालू होने पर, लॉग में JSON प्रोफ़ाइल पाथ जोड़ता है.
टैग: bazel_monitoring
--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत": Targetखास इवेंट को पब्लिश करना है या नहीं.
--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत": अगर सही हो, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय BEP में फ़ाइलसेट बड़ा करें.
टैग: affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत": अगर सही हो, तो आउटपुट फ़ाइलों को प्रज़ेंट करते समय, बीईपी में मिलते-जुलते फ़ाइलसेट सिमलिंक को पूरी तरह ठीक करें. --प्रायोगिक_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s": बीईपी के अपलोड न हो पाने पर, शुरुआत में, एक्सपोनेन्शियल बैकऑफ़ के लिए कम से कम देरी. (exponent: 1.6)
टैग: bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: विवरण देखें: इसमें यह चुना जाता है कि बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को कैसे अपलोड किया जाए.
टैग: affects_outputs
--[no]experimental_collect_load_average_in_profiler डिफ़ॉल्ट: "सही": चालू होने पर, प्रोफ़ाइलर, सिस्टम के लोड की कुल औसत संख्या इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_pressure_stall_indicators डिफ़ॉल्ट: "गलत": चालू होने पर, प्रोफ़ाइलर, Linux पीएसआई डेटा इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_resource_estimation डिफ़ॉल्ट: "गलत": चालू होने पर प्रोफ़ाइलर, लोकल ऐक्शन के लिए सीपीयू और मेमोरी के इस्तेमाल का अनुमान इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_system_network_usage डिफ़ॉल्ट: "गलत": चालू होने पर, प्रोफ़ाइलर, सिस्टम के नेटवर्क के इस्तेमाल से जुड़ी जानकारी इकट्ठा करता है.
टैग: bazel_monitoring
--[no]experimental_collect_worker_data_in_profiler डिफ़ॉल्ट: "गलत": चालू होने पर, प्रोफ़ाइलर, वर्कर के इकट्ठा किए गए संसाधन का डेटा इकट्ठा करता है.
टैग: 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_full_io, pressure_stall_full_memory, pressure_stall_some_io, pressure_stall_some_memory, pressure_stall_some_cpu, conflict_check, dynamic_lock, repository_fetch or unknown> बार कई बार इस्तेमाल किया गया है: प्रोफ़ाइल में शामिल किए जाने वाले अन्य टास्क के बारे में बताता है.
टैग: bazel_monitoring
--[no]experimental_profile_include_primary_output डिफ़ॉल्ट: "गलत": कार्रवाई इवेंट में, अतिरिक्त "out" एट्रिब्यूट शामिल होता है. इसमें कार्रवाई के प्राइमरी आउटपुट का एक्ज़ेक्यूटिव पाथ होता है.
टैग: bazel_monitoring
--[no]experimental_profile_include_target_label डिफ़ॉल्ट: "गलत": कार्रवाई इवेंट के JSON प्रोफ़ाइल डेटा में टारगेट लेबल शामिल होता है.
टैग: bazel_monitoring
--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "गलत": रन बिल्ड इवेंट में कमांड-लाइन रेज़िड्यू को शामिल करना है या नहीं, जिसमें बचा हुआ पदार्थ शामिल हो सकता है. डिफ़ॉल्ट रूप से, बचा हुआ डेटा रन कमांड बिल्ड इवेंट में शामिल नहीं किया जाता है, जिसमें बचा हुआ पदार्थ शामिल हो सकता है.
टैग: affects_outputs
--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत": लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs
--experimental_workspace_rules_log_file=<a path> डिफ़ॉल्ट: विवरण देखें: Workspace के नियमों के कुछ इवेंट को इस फ़ाइल में, अलग किए गए WorkspaceEvent प्रोटो के तौर पर लॉग करें.
--[no]generate_json_trace_profile डिफ़ॉल्ट: "ऑटो": अगर इसे चालू किया जाता है, तो Bazel, बिल्ड की प्रोफ़ाइल बनाता है और आउटपुट बेस में एक फ़ाइल में JSON-फ़ॉर्मैट वाली प्रोफ़ाइल लिखता है. chrome://tracing में लोड करके प्रोफ़ाइल देखें. डिफ़ॉल्ट रूप से, Bazel सभी बिल्ड जैसे कमांड और क्वेरी के लिए प्रोफ़ाइल लिखता है.
टैग: bazel_monitoring
--[no]heap_dump_on_oom डिफ़ॉल्ट: "गलत": अगर किसी ओओएम को फेंक दिया जाता है, तो मैन्युअल तौर पर हीप डंप डालना है या नहीं (-gc_thrazing_limits तक पहुंचने की वजह से मैन्युअल ओओएम). डंप को <OUT_base>/<invo_id>.heapdump.hprof पर लिखा जाएगा. यह विकल्प, -XX:+HeapDumpOnOutOfMemoryError विकल्प को असरदार तरीके से बदल देता है, जिससे मैन्युअल OOM पर कोई असर नहीं पड़ता.
टैग: bazel_monitoring
--[no]legacy_important_outputs डिफ़ॉल्ट: "सही": TargetComplete इवेंट में, लेगसी key_ बैज फ़ील्ड के लेगसी जनरेट होने की प्रोसेस को रोकने के लिए.
टैग: affects_outputs
--logging=<0 <= an integer <= 6> डिफ़ॉल्ट: "3": लॉगिंग लेवल.
टैग: affects_outputs
--memory_profile=<a path> डिफ़ॉल्ट: विवरण देखें: अगर यह सेट है, तो फ़ेज़ के आखिर में बताई गई फ़ाइल के लिए, मेमोरी के इस्तेमाल का डेटा लिखें. साथ ही, बिल्ड के आखिर में लॉग को मास्टर करने के लिए, स्टेबल हीप का इस्तेमाल करें.
टैग: bazel_monitoring
--memory_profile_stable_heap_parameters=<integers, separated by a comma expected in pairs> डिफ़ॉल्ट: "1,0": बिल्ड के आखिर में, मेमोरी प्रोफ़ाइल के स्टेबल हीप के हिसाब से हिसाब लगाने की सुविधा को ट्यून करें. यह संख्या, कॉमा से अलग किए गए पूर्णांकों की संख्या होनी चाहिए. हर जोड़े में पहला पूर्णांक, परफ़ॉर्म किए जाने वाले जीसी की संख्या होती है. हर जोड़े में दूसरा पूर्णांक, जीसी के बीच इंतज़ार करने के लिए सेकंड की संख्या होती है. उदाहरण: 2,4,4,0 4 सेकंड के ठहराव के साथ 2 जीसी होगा, जिसके बाद शून्य सेकंड के ठहराव के साथ 4 जीसी होंगे
टैग: bazel_monitoring
--profile=<a path> डिफ़ॉल्ट: विवरण देखें: अगर सेट हो, तो Bazel को प्रोफ़ाइल करें और बताई गई फ़ाइल में डेटा लिखें. प्रोफ़ाइल का विश्लेषण करने के लिए, bazelधा-विश्लेषण-प्रोफ़ाइल का इस्तेमाल करें.
टैग: bazel_monitoring
--[no]record_full_profiler_data डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, Bazel प्रोफ़ाइलर, सिर्फ़ तेज़ी से इकट्ठा किए गए डेटा को रिकॉर्ड करेगा. हालांकि, यह कई इवेंट (जैसे कि फ़ाइल का डेटा देना) के लिए, इकट्ठा किया गया डेटा रिकॉर्ड करेगा. अगर यह विकल्प चालू है, तो प्रोफ़ाइलर हर इवेंट को रिकॉर्ड करेगा. इससे प्रोफ़ाइलर ज़्यादा सटीक डेटा मिलेगा, लेकिन परफ़ॉर्मेंस हिट होगी. विकल्प का असर सिर्फ़ तब होता है, जब --profile भी इस्तेमाल किया गया हो.
टैग: bazel_monitoring
--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "असफलता": यह चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज को कब प्रिंट करना है. मान्य वैल्यू का मतलब है `असफलता`, सिर्फ़ काम न करने पर प्रिंट करने के लिए, सिर्फ़ सफलता पर प्रिंट करने की `सफलता`, और हमेशा प्रिंट करने के लिए `सभी`.
टैग: terminal_output
--[no]slim_profile डिफ़ॉल्ट: "सही": अगर प्रोफ़ाइल बहुत बड़ी है, तो इवेंट मर्ज करके JSON प्रोफ़ाइल का साइज़ कम किया जा सकता है.
टैग: bazel_monitoring
--starlark_cpu_profile=<a string> डिफ़ॉल्ट: "": तय फ़ाइल में सभी Starlark थ्रेड के लिए सीपीयू के इस्तेमाल की एक pprof प्रोफ़ाइल लिखता है.
टैग: bazel_monitoring
--tool_tag=<a string> डिफ़ॉल्ट: "": इस बैजल कॉल को एट्रिब्यूट करने के लिए टूल का नाम.
टैग: affects_outputs, bazel_monitoring
--ui_event_filters=<Convert list of comma separated event kind to list of filters> बार कई बार इस्तेमाल किया गया है: इससे पता चलता है कि यूज़र इंटरफ़ेस (यूआई) में कौनसे इवेंट दिखाए जाएं. लीडिंग +/- का इस्तेमाल करके डिफ़ॉल्ट तौर पर इवेंट को जोड़ा या हटाया जा सकता है. इसके अलावा, सीधे तौर पर असाइन करने की सुविधा की मदद से, डिफ़ॉल्ट सेट को पूरी तरह से बदला भी जा सकता है. काम करने वाले इवेंट टाइप के सेट में INFO, DEBUG, गड़बड़ी वगैरह शामिल हैं.
टैग: terminal_output

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: विवरण देखें: सर्किट ब्रेकर के इस्तेमाल के लिए रणनीति के बारे में बताता है. उपलब्ध रणनीतियां "असफलता" हैं. विकल्प के लिए अमान्य मान पर विकल्प के जैसा व्यवहार सेट नहीं किया गया है.
टैग: execution
--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत": रिमोट कैश मेमोरी पर अपलोड करने से पहले, किसी कार्रवाई की इनपुट फ़ाइलों के समय की जांच करने की सुविधा बंद करने के लिए, इस सेटिंग को बंद करें. कुछ मामलों में, Linux kernel की वजह से फ़ाइलें लिखने में देरी हो सकती है. इसकी वजह से गलत नतीजे मिल सकते हैं.
--[no]experimental_remote_cache_async डिफ़ॉल्ट: "गलत": अगर सही है, तो रिमोट कैश I/O, स्पॉन के हिस्से के बजाय बैकग्राउंड में होगा.
--experimental_remote_cache_compression_threshold=<an integer> डिफ़ॉल्ट: "0": zstd को कंप्रेस/डिकंप्रेस करने के लिए, ब्लॉब का कम से कम साइज़ होना ज़रूरी है. अगर --remote_cache_compression सेट नहीं है, तो यह लागू नहीं होगा.
--[no]experimental_remote_cache_lease_extension डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो Bazel बिल्ड के दौरान रिमोट ऐक्शन के आउटपुट के लिए लीज़ पर ले लेगा. इसके लिए, वह समय-समय पर रिमोट कैश मेमोरी में `FindFindBlobs` कॉल भेजेगा. यह फ़्रीक्वेंसी, `--experimental_remote_cache_ttl` की वैल्यू पर आधारित है.
--experimental_remote_cache_ttl=<An immutable length of time.> डिफ़ॉल्ट: "3 घंटे": हाल ही में, डाइजेस्ट के बाद रिमोट कैश में मौजूद ब्लॉब के कम से कम TTL (टीटीएल) का रेफ़रंस दिया गया है. उदाहरण के लिए, एक Actionresults या Find भरोसाBlobs से. Bazel, blobs के TTL के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, किसी इंक्रीमेंटल बिल्ड में बार-बार GetActionनतीजे को कॉल नहीं करता. वैल्यू को असल TTL से थोड़ा कम सेट किया जाना चाहिए. ऐसा इसलिए, क्योंकि सर्वर के डाइजेस्ट लौटाने और बैजल को उन्हें पाने के समय में एक अंतर होता है.
टैग: execution
--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: विवरण देखें: किसी डायरेक्ट्री का पाथ जहां खराब आउटपुट कैप्चर किए जाएंगे.
--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो GetActionresults() और Execute() को किए जाने वाले कॉल के दौरान इनपुट रूट के मर्कल ट्री की इन-मेमोरी कॉपी और उससे जुड़ी इनपुट मैपिंग को खारिज करें. इससे मेमोरी का इस्तेमाल बहुत कम हो जाता है, लेकिन रिमोट कैश के छूट जाने या फिर से कोशिश करने पर Bazel को फिर से गिनती करनी पड़ती है.
--experimental_remote_downloader=<a string> डिफ़ॉल्ट: विवरण देखें: रिमोट एसेट एपीआई एंडपॉइंट यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जाता है. इसके साथ काम करने वाले स्कीमा हैं grpc, grpcs (TLS चालू किए गए जीआरपीसी) और 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 डिफ़ॉल्ट: "गलत": अगर रिमोट डाउनलोडर काम नहीं करता है, तो लोकल डाउनलोडर पर वापस जाएं या नहीं.
--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "गलत": रिमोट एक्ज़ीक्यूशन कॉल के लिए कीपअलाइव की सुविधा का इस्तेमाल करना है या नहीं.
--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.> डिफ़ॉल्ट: "60 सेकंड": वह अंतराल जिसमें रिमोट अनुरोधों के पूरे न हो पाने की दर का हिसाब लगाया जाता है. शून्य या ऋणात्मक मान पर विफल होने की अवधि का आकलन निष्पादन की पूरी अवधि की गणना करता है.निम्न इकाइयों का उपयोग किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s) और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution
--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो Bazel रिमोट एक्ज़ीक्यूटर के लिए, इनपुट को टूल इनपुट के तौर पर मार्क कर देगा. इसका इस्तेमाल, रिमोट परसिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो मर्कल ट्री के कैलकुलेशन को याद किया जाएगा. इससे रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने में मदद मिलेगी. कैश मेमोरी के मेमोरी फ़ुट प्रिंट को --experimental_remote_mercle_tree_cache_size से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000": रिमोट कैश हिट चेक करने की स्पीड को बेहतर बनाने के लिए, याद किए जाने वाले मर्कल ट्री की संख्या. हालांकि, Java की ओर से सॉफ़्ट रेफ़रंस को हैंडल करने के हिसाब से कैश मेमोरी में फ़ाइलें अपने-आप कम हो जाती हैं, लेकिन बहुत ज़्यादा वैल्यू पर सेट करने पर, मेमोरी से बाहर की गड़बड़ियां हो सकती हैं. अगर यह वैल्यू 0 पर सेट है, तो कैश मेमोरी का साइज़ अनलिमिटेड नहीं होता है. सबसे सही वैल्यू, प्रोजेक्ट के साइज़ के हिसाब से अलग-अलग होती है. डिफ़ॉल्ट संख्या 1000 पर सेट होती है.
--experimental_remote_output_service=<a string> डिफ़ॉल्ट: विवरण देखें: होस्ट या Host:किसी रिमोट आउटपुट सर्विस एंडपॉइंट का पोर्ट. इसके साथ काम करने वाले स्कीमा हैं grpc, grpcs (TLS चालू किए गए जीआरपीसी) और Unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
--experimental_remote_output_service_output_path_prefix=<a string> डिफ़ॉल्ट: "": वह पाथ जिसके तहत --experimental_remote_आउटपुट_service की मदद से मैनेज की जाने वाली आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. बिल्ड के लिए इस्तेमाल की जाने वाली असल आउटपुट डायरेक्ट्री, इस पाथ की डिसेंडेंट होगी और उसे आउटपुट सेवा तय करेगी.
--[no]experimental_remote_require_cached डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो लागू करें कि रिमोट तरीके से चलाए जा सकने वाली सभी कार्रवाइयां, कैश मेमोरी में सेव हो जाती हैं या वे बिल्ड को फ़ेल कर देती हैं. इससे ऐसी समस्याओं को हल करने में मदद मिलती है जो तय नहीं हैं. इससे, यह जांच करने में मदद मिलती है कि कैश मेमोरी में सेव की जाने वाली कार्रवाइयों को असल में कैश मेमोरी में सेव किया गया है या नहीं. ऐसा, कैश में नए नतीजे डाले बिना किया जाता है.
--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: विवरण देखें: सप्लाई की गई कॉन्फ़िगरेशन फ़ाइल के साथ, रिमोट कैश कुंजी को स्क्रब करने की सुविधा चालू करती है. यह कॉन्फ़िगरेशन फ़ाइल, टेक्स्ट फ़ॉर्मैट में प्रोटोकॉल बफ़र होनी चाहिए. (src/main/protobuf/remote_scrbbing.proto देखें). इस सुविधा का मकसद, एक ही प्लैटफ़ॉर्म को टारगेट करने वाले, अलग-अलग प्लैटफ़ॉर्म पर की जाने वाली कार्रवाइयों के बीच, रिमोट/डिस्क कैश मेमोरी को शेयर करना है. इसका इस्तेमाल बहुत सावधानी से करना चाहिए, क्योंकि गलत सेटिंग की वजह से गलती से कैश एंट्री शेयर हो सकती है. साथ ही, इसकी वजह से गलत बिल्ड हो सकते हैं. स्क्रबिंग से, कार्रवाई करने के तरीके पर कोई असर नहीं पड़ता. सिर्फ़ कार्रवाई के नतीजे को वापस पाने या सेव करने के लिए, रिमोट/डिस्क की कैश मेमोरी कुंजी को कैलकुलेट करने के तरीके पर कोई असर नहीं पड़ता. स्क्रब की गई कार्रवाइयां, रिमोट तरीके से एक्ज़ीक्यूशन के साथ काम नहीं करतीं. साथ ही, इन्हें हमेशा स्थानीय तौर पर एक्ज़ीक्यूट किया जाएगा. स्क्रबिंग कॉन्फ़िगरेशन में बदलाव करने से, लोकल फ़ाइल सिस्टम या इंटरनल कैश मेमोरी में मौजूद आउटपुट अमान्य नहीं होते. जिन कार्रवाइयों पर असर हुआ है उन्हें फिर से लागू करने के लिए, क्लीन बिल्ड ज़रूरी है. इस सुविधा का सही तरीके से इस्तेमाल करने के लिए, हो सकता है कि आप --experimental_platform_in_internal_direct (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --insupported_strict_action_env (एनवायरमेंट वैरिएबल को सामान्य बनाने के लिए) के साथ, कस्टम --host_platform साथ सेट करना चाहें.
--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "गलत": अब काम नहीं करता. नहीं. इसके बजाय --remote_build_event_upload=minimal का इस्तेमाल करें.
--[no]incompatible_remote_downloader_send_all_headers डिफ़ॉल्ट: "सही": कई वैल्यू वाले हेडर की सभी वैल्यू को पहले रिमोट डाउनलोडर के बजाय रिमोट डाउनलोडर को भेजा जाए या नहीं.
टैग: incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट से जुड़े होते हैं.
टैग: incompatible_change
--[no]incompatible_remote_results_ignore_disk डिफ़ॉल्ट: "सही": No-op
टैग: incompatible_change
--[no]remote_accept_cached डिफ़ॉल्ट: "सही": कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को रिमोट तरीके से स्वीकार किया जाए या नहीं.
--remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "कम से कम": अगर यह वैल्यू 'सभी' पर सेट है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड कर दिए जाते हैं. अगर इस नीति को 'मिनिमल' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. हालांकि, वे फ़ाइलें जो BEP के उपभोक्ताओं के लिए ज़रूरी होती हैं (जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल). बाइटstream:// स्कीम का इस्तेमाल, फ़ाइलों के यूआरआई के लिए हमेशा किया जाता है, भले ही वे रिमोट कैश में मौजूद न हों. डिफ़ॉल्ट रूप से 'कम से कम' सेट करें.
--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: विवरण देखें: बाइटstream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम, जिसे बिल्ड इवेंट स्ट्रीम में लिखा जाता है. इस विकल्प को तब सेट किया जा सकता है, जब बिल्ड प्रॉक्सी का इस्तेमाल करके किया जाता है. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती है. अगर इस नीति को सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.
--remote_cache=<a string> डिफ़ॉल्ट: विवरण देखें: कैश मेमोरी में सेव किए जाने वाले एंडपॉइंट का यूआरआई. इस तरह के स्कीमा के साथ काम करने वाले एचटीटीपी, https, grpc, grpcs (TLS चालू किए गए grpc) और Unix (लोकल UNIX सॉकेट) हैं. अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा के बारे में बताएं. https://bazel.build/remote/ca कार्रवाई पर जाएं
--[no]remote_cache_compression डिफ़ॉल्ट: "गलत": अगर यह सेटिंग चालू है, तो कैश ब्लॉब को zstd के साथ कंप्रेस/डिकंप्रेस करें. ऐसा तब करें, जब इसका साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.
--remote_cache_header=<a 'name=value' assignment> बार कई बार इस्तेमाल किया गया है: ऐसा हेडर तय करें जिसे कैश मेमोरी के अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके कई हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_default_exec_properties=<a 'name=value' assignment> बार कई बार इस्तेमाल किया गया है: अगर कोई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो डिफ़ॉल्ट exec प्रॉपर्टी को रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए सेट करें.
टैग: affects_outputs
--remote_default_platform_properties=<a string> डिफ़ॉल्ट: "": अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से Remote_execution_property सेट नहीं करता है, तो रिमोट एक्ज़ीक्यूशन एपीआई के लिए डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब होस्ट प्लैटफ़ॉर्म को रिमोट तरीके से एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना गया हो.
--remote_download_regex=<a valid Java regular expression> बार कई बार इस्तेमाल किया गया है: रिमोट बिल्ड आउटपुट को हर हाल में डाउनलोड करें, जिनका पाथ इस पैटर्न से मिलता-जुलता हो. भले ही, यह टूल --remote_download_returns से मेल खाता हो. इस फ़्लैग को दोहराकर कई पैटर्न तय किए जा सकते हैं.
टैग: 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> डिफ़ॉल्ट: "0": रिमोट तरीके से की जाने वाली कार्रवाइयों की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर होते हैं.
--remote_executor=<a string> डिफ़ॉल्ट: विवरण देखें: होस्ट या Host:किसी रिमोट एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट. इसके साथ काम करने वाले स्कीमा हैं grpc, grpcs (TLS चालू किए गए जीआरपीसी) और Unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
--remote_grpc_log=<a path> डिफ़ॉल्ट: विवरण देखें: अगर बताया गया हो, तो gRPC कॉल से जुड़ी जानकारी लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में, क्रम के हिसाब से बनाई गई com.google.devtools.build.lib.remote.logging.Remote नज़ारेLog.LogEntry Protobufs पर मौजूद हर मैसेज के साथ, क्रम से दिए गए प्रोटोबफ़ मैसेज के साइज़ की जानकारी मिलती है. यह सीरियल नंबर, क्रम के हिसाब से दिए गए प्रोटोबफ़ मैसेज के साइज़ को दिखाता है, जैसा कि Logtry.writeDelimitedTo(OutStream) है.
--remote_header=<a 'name=value' assignment> बार कई बार इस्तेमाल किया गया है: वह हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके कई हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_instance_name=<a string> डिफ़ॉल्ट: "": रिमोट एक्ज़ीक्यूशन एपीआई में, example_name के तौर पर पास करने की वैल्यू.
--[no]remote_local_fallback डिफ़ॉल्ट: "गलत": अगर रिमोट तौर पर एक्ज़ीक्यूशन काम नहीं कर पाता है, तो क्या उसके लिए स्टैंडअलोन लोकल ऐक्शन रणनीति का इस्तेमाल करना चाहिए.
--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "स्थानीय": नहीं, यह सुविधा अब काम नहीं करती. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 देखें.
--remote_max_connections=<an integer> डिफ़ॉल्ट: "100": एक साथ ज़्यादा से ज़्यादा कनेक्शन की संख्या को रिमोट कैश/एक्ज़ीक्यूटर तक सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है, इसलिए Bazel --remote_max_CONNECTIONs एक साथ अनुरोध कर सकता है. जीआरपीसी रिमोट कैश/एक्ज़ीक्यूटर के लिए, एक जीआरपीसी चैनल आम तौर पर एक साथ 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> डिफ़ॉल्ट: "0": रिमोट कैश मेमोरी में सेव की जाने वाली रिमोट ऐक्शन की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर होते हैं.
--remote_retries=<an integer> डिफ़ॉल्ट: "5": थोड़ी देर के लिए हुई किसी गड़बड़ी को फिर से ठीक करने की कोशिशों की ज़्यादा से ज़्यादा संख्या. अगर यह 0 पर सेट है, तो बार-बार कोशिश करने की सुविधा बंद हो जाएगी.
--remote_retry_max_delay=<An immutable length of time.> डिफ़ॉल्ट: "5s": रिमोट से दोबारा कोशिश करने के बीच, बैकऑफ़ में लगने वाला ज़्यादा से ज़्यादा समय. नीचे दी गई इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
--remote_timeout=<An immutable length of time.> डिफ़ॉल्ट: "60 सेकंड": रिमोट एक्ज़ीक्यूशन और कैश कॉल तक इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश के लिए, यह कनेक्ट करने और पढ़ने का टाइम आउट, दोनों है. नीचे दी गई इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
--[no]remote_upload_local_results डिफ़ॉल्ट: "सही": अगर रिमोट कैश मेमोरी के साथ काम करता है और उपयोगकर्ता के पास इसकी अनुमति है, तो स्थानीय तौर पर बनाई गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड किया जाए या नहीं.
--[no]remote_verify_downloads डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो Bazel सभी रिमोट डाउनलोड के हैश योग का हिसाब लगाएगा. साथ ही, अगर रिमोट तरीके से कैश मेमोरी में सेव की गई वैल्यू उम्मीद के मुताबिक नहीं होती है, तो उसे खारिज कर दिया जाएगा.

--build_metadata=<a 'name=value' assignment> बार कई बार इस्तेमाल किया गया है: किसी बिल्ड इवेंट में देने के लिए, कस्टम की-वैल्यू स्ट्रिंग पेयर.
टैग: terminal_output
--color=<yes, no or auto> डिफ़ॉल्ट: "ऑटो": आउटपुट को रंगीन बनाने के लिए टर्मिनल कंट्रोल का इस्तेमाल करें.
--config=<a string> बार कई बार इस्तेमाल किया गया है: आरसी फ़ाइलों से अतिरिक्त कॉन्फ़िगरेशन सेक्शन चुनता है. हर <command> के लिए, अगर ऐसा सेक्शन मौजूद होता है, तो यह <command>:<config> से विकल्प भी चुन लेता है; अगर यह सेक्शन किसी भी .rc फ़ाइल में मौजूद नहीं है, तो ब्लेज़ में गड़बड़ी होगी. कॉन्फ़िगरेशन सेक्शन और फ़्लैग के ऐसे कॉम्बिनेशन जो इनके समान हैं वे टूल/*.blazec कॉन्फ़िगरेशन फ़ाइलों में मौजूद हैं.
--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.> बार कई बार इस्तेमाल किया गया है: यह क्रेडेंशियल हेल्पर कॉन्फ़िगर करता है. यह <a href="https://github.com/EngFlow/क्रेडेंशियल-helper-spec">क्रेडेंशियल हेल्पर की विशेषताओं</a> का पालन करता है, ताकि रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी और एक्ज़ीक्यूशन, और बिल्ड इवेंट सेवा के लिए अनुमति देने वाले क्रेडेंशियल पाने के लिए इसका इस्तेमाल किया जा सके. हेल्पर से मिले क्रेडेंशियल को `--google_default_ क्रेडेंशियल्स`, `--google_क्रेडेंशियल`, `.netrc` फ़ाइल या `repository_ctx.download()` और `repository_ctx.download_and_extract()` की पुष्टि करने वाले पैरामीटर से दिए जाने वाले क्रेडेंशियल पर ज़्यादा प्राथमिकता दी जा सकती है. एक से ज़्यादा हेल्पर सेट अप करने के लिए, इसे कई बार तय किया जा सकता है. निर्देशों के लिए, https://blog.engflow.com/2023/10/09/configging-bazels- क्रेडेंशियल-helper/ पर जाएं.
--credential_helper_cache_duration=<An immutable length of time.> डिफ़ॉल्ट: "30 मिनट": वह डिफ़ॉल्ट अवधि जिसके लिए क्रेडेंशियल हेल्पर से मिले क्रेडेंशियल को कैश मेमोरी में सेव किया जाता है. ऐसा तब होता है, जब क्रेडेंशियल की समयसीमा खत्म होने पर हेल्पर जानकारी नहीं देता.
--credential_helper_timeout=<An immutable length of time.> डिफ़ॉल्ट: "10 सेकंड": क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. क्रेडेंशियल हेल्पर इस टाइम आउट के अंदर जवाब नहीं दे पाएंगे. उन्हें शुरू नहीं किया जा सकेगा.
--curses=<yes, no or auto> डिफ़ॉल्ट: "ऑटो": स्क्रोल होने वाले आउटपुट को कम से कम करने के लिए, टर्मिनल कर्सर के कंट्रोल का इस्तेमाल करें.
--disk_cache=<a path> डिफ़ॉल्ट: विवरण देखें: किसी ऐसी डायरेक्ट्री का पाथ जहां Bazel, ऐक्शन और आउटपुट के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बना दिया जाएगा.
--[no]enable_platform_specific_config डिफ़ॉल्ट: "गलत": अगर सही है, तो Bazel bazelrc फ़ाइलों से, होस्ट-ओएस के हिसाब से कॉन्फ़िगर की गई कॉन्फ़िगरेशन लाइन चुनता है. उदाहरण के लिए, अगर होस्ट ओएस, Linux है और आपके पास बैजल बिल्ड है, तो Bazel, create:linux से शुरू होने वाली लाइनें चुनता है. साथ काम करने वाले ओएस आइडेंटिफ़ायर, Linux, macos, windows, freebsd, और Openbsd को मिलाकर बनाए जाते हैं. इस फ़्लैग को चालू करना, Linux पर --config=linux, Windows पर --config=Windows वगैरह का इस्तेमाल करने के बराबर है.
--[no]experimental_rule_extension_api डिफ़ॉल्ट: "गलत": प्रयोग के तौर पर लागू होने वाले नियम एक्सटेंशन एपीआई और सब-नियम एपीआई चालू करें
टैग: loading_and_analysis, experimental
--[no]experimental_windows_watchfs डिफ़ॉल्ट: "गलत": सही होने पर, --watchfs के लिए एक्सपेरिमेंट के तौर पर Windows की सुविधा चालू है. अगर ऐसा नहीं है, तो Windows पर बिना किसी परेशानी के देखें. पक्का करें कि आपने --watchfs को भी चालू किया हो.
--google_auth_scopes=<comma-separated list of options> डिफ़ॉल्ट: "https://www.googleapis.com/auth/cloud-platform": Google Cloud की पुष्टि करने के दायरों की कॉमा-सेपरेटेड लिस्ट.
--google_credentials=<a string> डिफ़ॉल्ट: विवरण देखें: यह उस फ़ाइल के बारे में बताता है जिससे पुष्टि करने के क्रेडेंशियल पाने हैं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं.
--[no]google_default_credentials डिफ़ॉल्ट: "गलत": पुष्टि करने के लिए, '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.> डिफ़ॉल्ट: "20 सेकंड": आउटगोइंग gRPC कनेक्शन के लिए, कीप अलाइव टाइम आउट को कॉन्फ़िगर करता है. अगर कीप-अलाइव पिंग को --grpc_keepalive_time से चालू किया गया है, तो इतनी देर बाद भी पिंग का जवाब न मिलने पर, Bazel कनेक्शन को बंद कर देता है. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. इसकी वैल्यू को एक सेकंड से कम पर सेट करना एक गड़बड़ी है. अगर कीप-अलाइव पिंग की सुविधा बंद है, तो इस सेटिंग को अनदेखा कर दिया जाता है.
--[no]incompatible_disable_non_executable_java_binary डिफ़ॉल्ट: "गलत": अगर सही है, तो java_binary हमेशा एक्ज़ीक्यूट किया जा सकता है. create_executable एट्रिब्यूट को हटा दिया जाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_symlink_file_to_dir डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]progress_in_terminal_title डिफ़ॉल्ट: "गलत": टर्म के टाइटल में निर्देश की प्रोग्रेस दिखाएं. यह देखने के लिए उपयोगी है कि एकाधिक टर्मिनल टैब होने पर bazel क्या कर रहा है.
--[no]show_progress डिफ़ॉल्ट: "सही": बिल्ड होने के दौरान प्रोग्रेस के मैसेज दिखाएं.
--show_progress_rate_limit=<a double> डिफ़ॉल्ट: "0.2": आउटपुट में प्रोग्रेस के मैसेज के बीच कम से कम सेकंड.
--[no]show_timestamps डिफ़ॉल्ट: "गलत": मैसेज में टाइमस्टैंप शामिल करना
--tls_certificate=<a string> डिफ़ॉल्ट: विवरण देखें: किसी TLS सर्टिफ़िकेट के लिए, ऐसा पाथ बताएं जो सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसेमंद हो.
--tls_client_certificate=<a string> डिफ़ॉल्ट: विवरण देखें: इस्तेमाल करने के लिए, TLS क्लाइंट सर्टिफ़िकेट के बारे में बताएं. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string> डिफ़ॉल्ट: विवरण देखें: इस्तेमाल करने के लिए, TLS क्लाइंट कुंजी तय करें. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
--ui_actions_shown=<an integer> डिफ़ॉल्ट: "8": ज़्यादा जानकारी वाले प्रोग्रेस बार में, एक साथ की जाने वाली कार्रवाइयों की संख्या दिखाई गई है. हर कार्रवाई को एक अलग लाइन में दिखाया गया है. प्रोग्रेस बार में हमेशा कम से कम एक नंबर दिखता है और एक से कम के सभी नंबर, 1 पर मैप किए जाते हैं.
टैग: terminal_output
--[no]watchfs डिफ़ॉल्ट: "गलत": Linux/macOS पर: सही होने पर, bazel लोकल बदलावों के लिए हर फ़ाइल को स्कैन करने के बजाय, ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करता है. Windows पर: फ़िलहाल, यह फ़्लैग एक तरह से काम नहीं करता, लेकिन इसे --experimental_ windows_watchfs के साथ इस्तेमाल करके चालू किया जा सकता है. किसी भी ओएस पर: अगर आपका फ़ाइल फ़ोल्डर नेटवर्क फ़ाइल सिस्टम पर है और फ़ाइलों में रिमोट मशीन पर बदलाव किया जाता है, तो काम करने के तरीके की कोई जानकारी नहीं है.

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

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

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

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

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

Aquery के विकल्प

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव": आउटपुट फ़ॉर्मैट {xml,proto,record} में होने पर, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को कैसे ठीक करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान किए गए सभी पहलू डिपेंडेंसी जोड़े जाते हैं. इस बात से कोई फ़र्क़ नहीं पड़ता कि उन्हें डायरेक्ट डिपेंडेंसी के नियम की क्लास दी गई है या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी के नियम क्लास के आधार पर संभावित तौर पर ऐक्टिव हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट का आकलन करने के लिए, दूसरे पैकेज को लोड करना ज़रूरी है. इससे यह अन्य मोड की तुलना में धीमा हो जाएगा. इस बात का भी ध्यान रखें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में तय किया जाता है. यह प्रोसेस, 'बैजल क्वेरी' के दौरान नहीं चलाई जाती.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से लेबल निकलते हैं, जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन का इस्तेमाल किया जाता है. यह उन टूल के लिए फ़ायदेमंद है जिन्हें नियमों से निकलने वाले अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इसे चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैटर, आउटपुट को ज़्यादा पढ़ने लायक बनाने के बजाय, साफ़ तौर पर रिपॉज़िटरी के नाम (मुख्य डेटा स्टोर करने की जगह के हिसाब से) का इस्तेमाल कर सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]graph:factored डिफ़ॉल्ट: "सही": अगर सही है, तो ग्राफ़ पर 'फ़ैक्टर' उत्सर्जित होगा. इसका मतलब है कि टॉपॉलॉजिकल रूप से समान नोड एक साथ मर्ज कर दिए जाएंगे और उनके लेबल जोड़े जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> डिफ़ॉल्ट: "512": आउटपुट में ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल में काट-छांट की जाएगी; -1 का मतलब है कि कोई काट-छांट नहीं होगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel से जोड़ा गया है. cquery के लिए यह विकल्प, समाधान किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_artifacts डिफ़ॉल्ट: "सही": इससे आउटपुट में, ऐक्शन इनपुट और आउटपुट के नाम शामिल होते हैं (शायद बड़ा).
टैग: terminal_output
--[no]include_aspects डिफ़ॉल्ट: "सही": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]include_commandline डिफ़ॉल्ट: "सही": आउटपुट में, ऐक्शन कमांड लाइन का कॉन्टेंट शामिल होता है (शायद बड़ा).
टैग: terminal_output
--[no]include_file_write_contents डिफ़ॉल्ट: "गलत": FileWrite, SourceSymlinkManifest, और RepoMapping Manifest की कार्रवाइयों (संभावित तौर पर बड़ी) के लिए, फ़ाइल का कॉन्टेंट शामिल करें.
टैग: terminal_output
--[no]include_param_files डिफ़ॉल्ट: "गलत": कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें (शायद बड़ी). ध्यान दें: इस फ़्लैग को सक्षम करने से --include_commandline फ़्लैग अपने आप सक्षम हो जाएगा.
टैग: terminal_output
--[no]include_scheduling_dependencies डिफ़ॉल्ट: "गलत": इसमें कार्रवाइयों की शेड्यूलिंग डिपेंडेंसी (संभावित रूप से बड़ी) के नाम शामिल होते हैं. यह सिर्फ़ तब लागू होता है, जब --include_artifacts भी सेट की गई हो.
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, इसके पहले `//` को हटाया नहीं जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "गलत": अगर सेट और --universe_scope सेट नहीं है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई, --universe_scope वैल्यू आपकी पसंद के मुताबिक नहीं हो सकती. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है (यानी `cquery` नहीं).
टैग: loading_and_analysis
--[no]line_terminator_null डिफ़ॉल्ट: "गलत": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म करना है.
टैग: terminal_output
--[no]nodep_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो "nodep" एट्रिब्यूट के डिपेंस को उस डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics
--output=<a string> डिफ़ॉल्ट: "text": वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: text, textproto, proto, stream_proto, jsonproto.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": सही होने पर, उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": definition_stack प्रोटो फ़ील्ड को भरें, जो नियम की क्लास तय होने के समय Starlark कॉल स्टैक के हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो select() से बनाए गए कॉन्फ़िगर करने लायक एट्रिब्यूट बराबर हो जाते हैं. सूची टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप की वैल्यू शून्य हो जाती है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स पहलू के साथ भरें जिससे एट्रिब्यूट मिला है (अगर ऐसा नहीं है, तो खाली स्ट्रिंग).
टैग: terminal_output
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत": $internal_attr_has एट्रिब्यूट का हिसाब लगाना है या नहीं, इसका पता लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत": हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग: terminal_output
--[no]proto:locations डिफ़ॉल्ट: "सही": प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "सभी": आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. कोई एट्रिब्यूट आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर क्वेरी को सेट किया जाता है, तो कमांड लाइन के बजाय, यहां दी गई फ़ाइल का नाम पढ़कर सुनाया जाएगा. यहां फ़ाइल और कमांड लाइन क्वेरी के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक ऐब्सलूट पाथ होता है और यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--[no]skyframe_state डिफ़ॉल्ट: "गलत": ज़्यादा विश्लेषण किए बिना, Skyframe के मौजूदा ऐक्शन ग्राफ़ को डंप करें. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय करने की सुविधा काम नहीं करती. यह फ़्लैग सिर्फ़ --आउटपुट=प्रोटो या --आउटपुट=textproto के साथ उपलब्ध है.
टैग: terminal_output
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: बंद होने पर, क्वेरी को ऑपरेट करने वाले डिपेंडेंसी ग्राफ़ में 'exec कॉन्फ़िगरेशन' की डिपेंडेंसी शामिल नहीं होंगी. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसा कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक जाता है. आम तौर पर, यह एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल को पॉइंट करता है. Cquery: यह विकल्प बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट exec कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए exec टारगेट दिखाए जाएंगे. इस विकल्प में ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग: build_file_semantics
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा और घटाव). क्वेरी को यूनिवर्स में परफ़ॉर्म किया जा सकता है. इसके लिए, दिए गए टारगेट को हमेशा के लिए बंद करना होगा. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माने जाते हैं. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए, इस विकल्प को तय न करने से बिल्ड में रुकावट आ सकती है.
टैग: loading_and_analysis

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "गलत": सिमलिंक ट्री बनाने के लिए, डायरेक्ट फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "गलत": कर्मचारियों की मदद से, परसिस्टेंट Aar एक्सट्रैक्टर चालू करें.
टैग: execution
--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "गलत": सोर्स मेनिफ़ेस्ट कार्रवाइयों को फिर से चालू करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "गलत": अगर सही है, तो Bazel एक नए स्पॉन में टेस्ट के लिए, कवरेज पोस्टप्रोसेसिंग करेगा.
टैग: execution
--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री को ट्रैवर्स नहीं करेंगे या सिमलिंक के प्रति संवेदनशील नहीं होंगे.
टैग: execution
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> डिफ़ॉल्ट: "": गतिविधियों की जानकारी के आधार पर, उस कार्रवाई के काम करने के तरीके की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो स्क्रिप्ट को चलाने की जानकारी देती हैं. कई सामान्य कार्रवाइयां, एक्ज़ीक्यूशन की जानकारी के साथ काम करती हैं, जैसे कि Genroll, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, ऑर्डर अहम हो जाता है, क्योंकि एक ही मिनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' जोड़ता है और 'y' से हटा देता है. जेनरूल की सभी कार्रवाइयों के लिए, 'Genroll=+requires-x' को लागू करने की जानकारी में 'requires-x' जोड़ता है. '(?!GenTerms).*=-requires-x', सभी गैर-सामान्य कार्रवाइयों के लिए, निष्पादन जानकारी से '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=workerhost_machine_resource_optimizationsexecution
--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{/2/}

--modify_execution_info=AARGenerator=+supports-multiplex-workershost_machine_resource_optimizationsexecution
--persistent_multiplex_android_tools: परसिस्टेंट और मल्टीप्लेक्स किए गए Android टूल (डेक्सिंग, डिस्यूगरिंग, रिसॉर्स प्रोसेसिंग) चालू करें.
इसमें शामिल है:
  --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 डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो Bazel, टेस्ट एक्ज़ेक्यूटिव ग्रुप के बजाय, टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: विवरण देखें: Android का टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_crosstool_top=<a build target label> डिफ़ॉल्ट: "//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> डिफ़ॉल्ट: "": यह नीति उन प्लैटफ़ॉर्म को सेट करती है जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी एक फ़ैट APKs होती है, जिसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--android_sdk=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk": Android SDK टूल/प्लैटफ़ॉर्म के बारे में बताता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain": Apple और Objc नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> डिफ़ॉल्ट: "": कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: विवरण देखें: टारगेट इकट्ठा करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger": रॉ कवरेज रिपोर्ट को पोस्ट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. यह फ़िलहाल एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcow_merger' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> डिफ़ॉल्ट: "@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> डिफ़ॉल्ट: "@bazel_tools//tools/test:कवरेज_support": सहायता फ़ाइलों की वह जगह जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई के इनपुट के लिए ज़रूरी होती है. डिफ़ॉल्ट रूप से '//tools/test:coverage_support' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: विवरण देखें: यह तय करता है कि कस्टम मैलक लागू किया जाए या नहीं. यह सेटिंग, बिल्ड के नियमों में मॉलक एट्रिब्यूट को बदल देती है.
टैग: 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 डिफ़ॉल्ट: "गलत": अगर यह नीति सेट है, तो हर Xcode कार्रवाई के लिए "requires-xcode:{version}" का इस्तेमाल करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" चलाने की ज़रूरत भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution
--[no]experimental_prefer_mutual_xcode डिफ़ॉल्ट: "सही": अगर सही है, तो सबसे हाल का Xcode इस्तेमाल करें जो स्थानीय और कहीं से भी उपलब्ध हो. अगर यह गलत है या कोई भी म्यूचुअली उपलब्ध वर्शन नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state
--extra_execution_platforms=<comma-separated list of options> डिफ़ॉल्ट: "": ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन प्लैटफ़ॉर्म को वर्कस्पेस फ़ाइल में रजिस्टर_execution_platforms() के ज़रिए एलान किए गए प्लैटफ़ॉर्म से पहले लागू किया जाएगा. यह विकल्प सिर्फ़ एक बार सेट किया जा सकता है; बाद के इंस्टेंस पहले के फ़्लैग की सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन में ध्यान दिए जाने वाले नियम. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन टूलचेन का इस्तेमाल, workspace_toolchains() के ज़रिए वर्कSPACE फ़ाइल में बताए गए टूल से पहले किया जाता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: विवरण देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. क्रॉसटूल टूलचेन में डिफ़ॉल्ट वैल्यू को चुना जाता है और आपको इसे बदलने की ज़रूरत नहीं पड़ती.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: विवरण देखें: बिना किसी बटन वाला फ़्लैग. इसे आने वाली रिलीज़ से हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: विवरण देखें: अगर इसके बारे में बताया गया है, तो यह सेटिंग exec कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> डिफ़ॉल्ट: "@local_config_platform//:host": प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही": अगर सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'nonhost' सुविधाओं को चालू नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_android_toolchain_resolution डिफ़ॉल्ट: "सही": Android के नियमों (Starlark और निजी) के लिए Android SDK चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "गलत": Apple के नियमों (Starlark और निजी) के लिए, Apple SDK चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--[no]incompatible_remove_legacy_whole_archive डिफ़ॉल्ट: "सही": अगर सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_require_ctx_in_configure_features डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "गलत": सही होने पर, एक्ज़ीक्यूटेबल के लिए स्ट्रिप से जुड़ी कार्रवाई में फ़्लैग -x का इस्तेमाल किया जाएगा, जो डाइनैमिक सिंबल के रिज़ॉल्यूशन को नहीं तोड़ता है.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects डिफ़ॉल्ट: "सही": अगर टूलचेन के साथ काम करने वाला इंटरफ़ेस शेयर किया गया ऑब्जेक्ट है, तो उसका इस्तेमाल करें. फ़िलहाल, यह सेटिंग सभी ELF टूलचेन में काम करती है.
टैग: 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> डिफ़ॉल्ट: "": मैपिंग फ़ाइल की जगह, जो बताती है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं किया गया है, तो किस प्लैटफ़ॉर्म का इस्तेमाल किया जाए या पहले से मौजूद प्लैटफ़ॉर्म पर कौनसे फ़्लैग सेट किए जाएं. मुख्य फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता होना चाहिए. यह डिफ़ॉल्ट रूप से 'platform_mappings' (फ़ाइल फ़ोल्डर रूट के तहत आने वाली फ़ाइल) पर सेट होता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> डिफ़ॉल्ट: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python2_path=<a string> डिफ़ॉल्ट: विवरण देखें: अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से बंद कर दिया गया है.
टैग: no_op, deprecated
--python3_path=<a string> डिफ़ॉल्ट: विवरण देखें: अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से बंद कर दिया गया है.
टैग: no_op, deprecated
--python_path=<a string> डिफ़ॉल्ट: विवरण देखें: Python अनुवादक के ऐब्सलूट पाथ को टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains ने इसे बंद किया है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: विवरण देखें: Python इंटरप्रेटर को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains ने इसे बंद किया है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: यह tvOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, tvOS ऐप्लिकेशन बनाने के लिए किया जाएगा. इसकी जानकारी न होने पर, 'xcode_version' से tvOS के SDK टूल का डिफ़ॉल्ट वर्शन इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: WatchOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट WatchOS SDK वर्शन इस्तेमाल करता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: विवरण देखें: अगर बताया गया है, तो सही बिल्ड ऐक्शन के लिए दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर इसकी जानकारी नहीं दी गई है, तो Xcode के एक्ज़ीक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes": xcode_config नियम का लेबल. इसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन को चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत": डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build_runfile_links डिफ़ॉल्ट: "सही": अगर सही है, तो रनफ़ाइल बनाने के लिए सभी टारगेट के लिए जंगलों को आपस में लिंक किया जाता है. अगर यह गलत है, तो इन्हें सिर्फ़ तब लिखें, जब ज़रूरी हो. इसके लिए, किसी स्थानीय कार्रवाई, टेस्ट या रन कमांड का इस्तेमाल करें.
टैग: affects_outputs
--[no]build_runfile_manifests डिफ़ॉल्ट: "सही": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर गलत है, तो उन्हें मिटा दें. गलत होने पर लोकल टेस्ट नहीं चलाए जाएंगे.
टैग: affects_outputs
--[no]build_test_dwp डिफ़ॉल्ट: "गलत": यह सुविधा चालू होने पर, स्टैटिक और फ़िशन के साथ C++ टेस्ट बनाने पर, टेस्ट बाइनरी के लिए भी .dwp फ़ाइल अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h": cc_proto_library से बनाई जाने वाली हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc": cc_proto_library से बनाई जाने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत": Proto_library में, वैकल्पिक Java api वर्शन के लिए अतिरिक्त कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_proto_extra_actions डिफ़ॉल्ट: "गलत": Proto_library में, वैकल्पिक Java api वर्शन के लिए अतिरिक्त कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत": चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को, कंपाइलेशन के आउटपुट के तौर पर सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> डिफ़ॉल्ट: "नहीं": यह बताता है कि C++ के कंपाइलेशन और लिंक के लिए कौनसे कंपाइलेशन मोड, फ़्रैशन का इस्तेमाल करते हैं. यह सभी मोड चालू करने के लिए, {'Fastbuild', 'dbg', 'opt'} या विशेष वैल्यू 'yes' का कोई भी कॉम्बिनेशन हो सकता है और सभी मोड बंद करने के लिए 'no' का कोई भी कॉम्बिनेशन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही": सही होने पर, नेटिव नियम अपनी रनफ़ाइल में <code>DefaultInfo.files</code> डेटा डिपेंडेंसी जोड़ देते हैं. यह Starlark के नियमों (https://bazel.build/extending/rules#runfiles_features_to_avoid) के लिए सुझाए गए तरीके से मेल खाता है.
टैग: affects_outputs, incompatible_change
--[no]legacy_external_runfiles डिफ़ॉल्ट: "सही": अगर सही हो, तो रनफ़ाइल/डेटा स्टोर करने की जगह के लिए .runfiles/wsname/external/repo (.runfiles/repo) के अलावा, बाहरी डेटा स्टोर करने की जगहों के लिए, जंगलों को सिमलिंक करने वाला जंगल बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत": यह बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps डिफ़ॉल्ट: "गलत": अगर यह नीति सेट की जाती है, तो 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> डिफ़ॉल्ट: "armeabi-v7a": Android टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]android_databinding_use_androidx डिफ़ॉल्ट: "सही": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटाबाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "सही": Android डेटाबाइंडिंग v2 का इस्तेमाल, 3.4.0 आर्ग्युमेंट के साथ करें. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद": इससे तय होता है कि जब कोई cc_binary साफ़ तौर पर शेयर की गई लाइब्रेरी नहीं बनाती है, तो Android के नियमों के C++ डिप डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बैजल यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "वर्णमाला": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्ज़ेक्रूट के पाथ के हिसाब से क्रम में लगाया गया है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में, कॉन्फ़िगरेशन डायरेक्ट्री के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आने वाले क्रम में लगाया जाता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत": यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए रिसॉर्स को कम करने की सुविधा को चालू करती है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip डिफ़ॉल्ट: "ऑटो": Python के लिए एक्ज़ीक्यूटेबल ज़िप बनाएं. Windows पर, दूसरे प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs
--catalyst_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple Catalyst बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage डिफ़ॉल्ट: "गलत": अगर यह बताया जाता है, तो Bazel इंस्ट्रुमेंट कोड का इस्तेमाल करेगा और जहां तक मुमकिन हो, ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करेगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी भी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसकी जगह, 'bazel profile' निर्देश का इस्तेमाल करना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "Fastbuild": वह मोड तय करें जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> बार कई बार इस्तेमाल किया गया है: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> बार कई बार इस्तेमाल किया गया है: जीसीसी को पास करने के दूसरे विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> डिफ़ॉल्ट: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: विवरण देखें: सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करके, कंपाइलेशन ऑप्टिमाइज़ करें. उस ZIP फ़ाइल के पूरे पाथ का नाम बताएं जिसमें प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल हो.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: विवरण देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंटेशन से बाइनरी जनरेट करें. 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> बार कई बार इस्तेमाल किया गया है: हर --तय करें विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, आखिरी वैल्यू जीत जाती है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "डिफ़ॉल्ट": इससे तय होता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह चुनेगा कि उसे डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही": अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_runfiles डिफ़ॉल्ट: "ऑटो": रनफ़ाइल सिमलिंक ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows और दूसरे प्लैटफ़ॉर्म पर बंद है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> बार कई बार इस्तेमाल किया गया है: अब अलग-अलग पहलुओं के पक्ष में नहीं, बल्कि उनके सुझाव दिए गए हैं. मौजूदा बिल्ड ऐक्शन में अतिरिक्त_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत": APK में Java रिसॉर्स को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही": Android Databinding v2 का इस्तेमाल करें. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत": यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए रिसॉर्स को कम करने की सुविधा को चालू करती है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत": dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत": अगर इसके बारे में बताया जाता है, तो Bazel, जनरेट की गई फ़ाइलों के लिए कवरेज की जानकारी भी जनरेट करेगा.
टैग: affects_outputs
--experimental_objc_fastbuild_options=<comma-separated list of options> डिफ़ॉल्ट: "-O0,-DDEBUG=1": यह स्ट्रिंग, objc फ़ास्ट बिल्ड कंपाइलर के विकल्पों के तौर पर इस्तेमाल करती है.
टैग: action_command_lines
--[no]experimental_omitfp डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो स्टैक करने के लिए libunwind का इस्तेमाल करें. साथ ही, इसे -fomit-frame-Pointer और -fasynchronous-unwind-tables की मदद से कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> डिफ़ॉल्ट: "बंद": आउटपुट ट्री नियम में, आउटपुट लिखने के लिए किस मॉडल का इस्तेमाल करना चाहिए, खास तौर से मल्टी-प्लैटफ़ॉर्म या मल्टी-कॉन्फ़िगरेशन वाले बिल्ड के लिए. इस पर प्रयोग बहुत ज़्यादा किया जा रहा है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 देखें. स्टारलार्क कार्रवाइयां, '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 फ़ॉर्मैट में होनी चाहिए, जहां लेबल किसी प्लैटफ़ॉर्म के बारे में बताता है. साथ ही, आउटपुट पाथ में इस्तेमाल करने के लिए वैल्यू, पसंदीदा छोटा नाम है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_छिपने वाली यूआरएल सही से काम कर रही हो. नाम की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए छोटा नाम इस्तेमाल किया जाता है. सटीक स्कीम, एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है. सबसे पहले, बहुत कम मामलों में --platforms विकल्प में कोई एक वैल्यू नहीं होती. इसलिए, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए किसी छोटे नाम को --experimental_override_name_platform_in_इस_क्रिएटर ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_ बदलें_direct_legacy_heur होंगी, तो मौजूदा प्लैटफ़ॉर्म के लेबल के हिसाब से छोटे नाम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल आखिरी विकल्प के तौर पर किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत": अगर इसके बारे में बताया गया है, तो पेज पर इकट्ठा करने के लिए कोड इकट्ठा करने की सुविधा चालू होने पर, Bazel, gcov के बजाय llvm-cov कवरेज वाले मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic डिफ़ॉल्ट: "सही": कृपया इस फ़्लैग का इस्तेमाल, माइग्रेट करने या टेस्टिंग की सुझाई गई रणनीति के हिस्से के तौर पर ही करें. ध्यान दें कि अनुभव से जुड़े डेटा में कमियां हैं और हमारा सुझाव है कि सिर्फ़ --experimental_override_name_platform_in_इसी आउटपुट_डायर का इस्तेमाल करके माइग्रेट करें.
टैग: affects_outputs, experimental
--fat_apk_cpu=<comma-separated set of options> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "गलत": बिना किसी बटन वाला फ़्लैग. इसे आने वाली रिलीज़ से हटा दिया जाएगा.
टैग: no_op
--fdo_instrument=<a string> डिफ़ॉल्ट: विवरण देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर की मदद से, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान, डंप किया जाएगा.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: विवरण देखें: कम्यूनिटी को ऑप्टिमाइज़ करने के लिए, एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री, ऑटो प्रोफ़ाइल वाली 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 डिफ़ॉल्ट: "गलत": अगर यह सेटिंग चालू होती है, तो सभी 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> डिफ़ॉल्ट: "ऑप्ट": वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल होंगे. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> बार कई बार इस्तेमाल किया गया है: एक्ज़ीक्यूशन कॉन्फ़िगरेशन में C (लेकिन C++ नहीं) सोर्स फ़ाइलों को कंपाइल करते समय, C कंपाइलर को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> बार कई बार इस्तेमाल किया गया है: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के दूसरे विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> डिफ़ॉल्ट: "": होस्ट के लिए सीपीयू.
टैग: 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> बार कई बार इस्तेमाल किया गया है: exec कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का एक और विकल्प.
टैग: 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/ में bar.cc. को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन जोड़ता है.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "गलत": चालू होने पर, किसी नियम से इस्तेमाल की जाने वाली हर टूलचेन के लिए, एक एक्ज़ेक्यूटिव ग्रुप अपने-आप बन जाता है. यह नियम काम करे, इसके लिए कार्रवाइयों पर `toolchain` पैरामीटर तय करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 देखें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही": अगर सही है, तो जेनफ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets डिफ़ॉल्ट: "गलत": कवरेज की सुविधा चालू होने पर, इससे पता चलता है कि टेस्ट के नियमों को लागू करने पर विचार करना है या नहीं. यह नीति सेट होने पर, --instrumentation_filter से शामिल किए गए टेस्ट नियम लागू होते हैं. ऐसा न होने पर, टेस्ट के नियमों को कवरेज इंस्ट्रुमेंटेशन से हमेशा बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/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_ऐप्लिकेशन बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें बताए गए सभी आर्किटेक्चर शामिल हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive डिफ़ॉल्ट: "सही": अब काम नहीं करता, इसकी जगह ले ली गई है --insupported_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> बार कई बार इस्तेमाल किया गया है: एलटीओ बैकएंड चरण को पास करने का एक और विकल्प (--features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> बार कई बार इस्तेमाल किया गया है: एलटीओ को इंडेक्स करने के चरण को पास करने का एक और विकल्प (-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 डिफ़ॉल्ट: "गलत": अगर यह नीति सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --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 बैकएंड (-features=thin_lto के तहत) को चुनिंदा तरीके से पास करने के अन्य विकल्प. यह विकल्प कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां रेगुलर एक्सप्रेशन फ़िल्टर, शामिल किए गए और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची दिखाता है. 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> डिफ़ॉल्ट: विवरण देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, प्रोपेलर प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोपेलर प्रोफ़ाइल में कम से कम एक फ़ाइल होनी चाहिए. एक cc प्रोफ़ाइल और ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल स्वीकार करता है, जिसे प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, a/b/BUILD: मिटा देने वाली फ़ाइल का लेबल तय करने वाली BUILD फ़ाइल, जो कि a/b/BUILD: मिटानी-बढ़ाने से जुड़ी जानकारी( name = "propler_profile", cc_profile = "propler_cc_profile.txt", ld_profile = "profiller_ld_profile.txt",) में लेबल को परिभाषित करने वाली BUILD फ़ाइल हो सकती है. Export_files डायरेक्टिव को, Bazel को दिखाने के लिए संबंधित पैकेज में जोड़ना पड़ सकता है. विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --propler_optimize=//a/b:propler_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: विवरण देखें: प्रोपेलर ऑप्टिमाइज़ किए गए बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: विवरण देखें: प्रोपेलर ऑप्टिमाइज़ किए गए बिल्ड के लिए ld_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: विवरण देखें: 'जांच करें' और 'रन' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले शामिल करने के लिए उपसर्ग. अगर वैल्यू '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 डिफ़ॉल्ट: "सही": अगर सही है, तो एक जैसी काम करने वाली नेटिव लाइब्रेरी, अलग-अलग टारगेट के बीच शेयर की जाएंगी
टैग: loading_and_analysis, affects_outputs
--[no]stamp डिफ़ॉल्ट: "गलत": तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह के साथ बाइनरी बनाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह बताता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं ("-Wl,--strip-debug" का इस्तेमाल करके). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि स्ट्रिप iff --compilation_mode=foundbuild.
टैग: affects_outputs
--stripopt=<a string> बार कई बार इस्तेमाल किया गया है: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs
--tvos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple tvOS बाइनरी बनाने हैं.
टैग: loses_incremental_state, loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाला tvOS वर्शन. अगर इसकी जानकारी नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state
--visionos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple visionOS बाइनरी बनाने हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, स्मार्टवॉच के कम से कम वर्शन के साथ काम करने वाला वर्शन. अगर इसकी जानकारी नहीं दी गई है, तो 'watchos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: विवरण देखें: डेटा कंपाइलेशन ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_ड़ियों/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू होते हैं, जैसे कि xbinary_fdo को कभी तय नहीं किया गया हो.
टैग: affects_outputs

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: "": Environment_group का एलान करें, ताकि target_environment वैल्यू के लिए सीपीयू वैल्यू को अपने-आप मैप करने के लिए, इसका इस्तेमाल किया जा सके.
टैग: changes_inputs, loading_and_analysis, experimental
--[no]check_licenses डिफ़ॉल्ट: "गलत": इस बात की जांच करें कि डिपेंडेंट पैकेज ने जो लाइसेंसिंग पाबंदियां लगाई हैं वे बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर न डाल रही हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग: build_file_semantics
--[no]check_visibility डिफ़ॉल्ट: "सही": यह सेटिंग बंद होने पर, टारगेट डिपेंडेंसी में 'किसको दिखे' सेटिंग से जुड़ी गड़बड़ियां, चेतावनियों के तौर पर मार्क हो जाती हैं.
टैग: build_file_semantics
--[no]desugar_for_android डिफ़ॉल्ट: "सही": डेक्सिंग से पहले, Java 8 बाइटकोड को डिसुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs डिफ़ॉल्ट: "गलत": लेगसी डिवाइसों के लिए, ऐप्लिकेशन में काम करने वाली Java 8 लाइब्रेरी शामिल करनी है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints डिफ़ॉल्ट: "सही": यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर कोई टारगेट ऐसी डिपेंडेंसी है जो एक जैसे एनवायरमेंट के साथ काम नहीं करती, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps डिफ़ॉल्ट: "सही": 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> डिफ़ॉल्ट: "डिफ़ॉल्ट": सही होने पर, यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए जाने वाले सभी टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "गलत": अगर यह सुविधा चालू है, तो आउटपुट फ़ाइल वाले ज़रूरी टारगेट के लिए testonly का इस्तेमाल करें. इसके लिए, जनरेट करने वाले नियम का सिर्फ़ टेस्ट देखें. यह 'किसको दिखे' सेटिंग से मेल खाता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "गलत": चालू होने पर, विज़िबिलिटी की जांच करने की सुविधा, टूलचेन लागू करने की सुविधा पर भी लागू होती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "गलत": इस सुविधा के चालू होने पर, Android के मूल नियमों का सीधे तौर पर इस्तेमाल करने की सुविधा बंद हो जाती है. कृपया https://github.com/bazelbuild/rules_android से गए Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "गलत": नहीं. पुराने सिस्टम के साथ काम करने के लिए, इसे यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 डिफ़ॉल्ट: "सही": अगर सही है, तो 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 डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: विवरण देखें: -insupported_python_disallow_native_rules लागू करने के लिए, अनुमति वाली सूची (package_group target) का इस्तेमाल करें.
टैग: loading_and_analysis
--[no]strict_filesets डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू किया जाता है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "गड़बड़ी": जब तक बंद न हो, तब तक यह जांच करता है कि कोई proto_library टारगेट साफ़ तौर पर सभी सीधे इस्तेमाल किए जाने वाले टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद": जब तक बंद न हो, तब तक यह जांच करता है कि कोई proto_library टारगेट साफ़ तौर पर 'इंपोर्ट करें' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट किए गए के तौर पर बताए.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes डिफ़ॉल्ट: "गलत": अगर सही है, तो सिस्टम से मिलने वाले हेडर में पाथ (-isystem) को शामिल करना भी ज़रूरी होता है.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> बार कई बार इस्तेमाल किया गया है: इस बिल्ड के टारगेट एनवायरमेंट का एलान करता है. "एनवायरमेंट" नियम के लेबल का रेफ़रंस होना चाहिए. अगर तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने वाले होने चाहिए.
टैग: changes_inputs

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

--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही": नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "गलत": अगर सही हो, तो objc_library andobjc_Import में जाकर SDK_frameworks और social_sdk_frameworks के एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत": अगर सही है, तो objc_library और objc_Import में हमेशा लिंक की सुविधा वाली वैल्यू के लिए, डिफ़ॉल्ट वैल्यू को 'सही' के तौर पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत": सही होने पर, बिल्टइन py_* नियमों का इस्तेमाल करते समय कोई गड़बड़ी होती है; इसके बजाय, Rules_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत": सही होने पर, नियम को टारगेट करने से विश्लेषण नहीं हो पाता है. इसका नतीजा यह होता है कि टारगेट, गड़बड़ी की जानकारी वाले विश्लेषणFailureInfo के इंस्टेंस को लागू नहीं करेगा, न कि बिल्ड फ़ेल हो जाएगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट की मदद से, ज़्यादा से ज़्यादा ट्रांज़िटिव डिपेंडेंसी सेट करता है. इस सीमा को पार करने से नियम में गड़बड़ी होगी.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत": अगर सही dex2oat कार्रवाई के पूरा न हो पाने पर, टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> बार कई बार इस्तेमाल किया गया है: टेस्ट के लिए, रिसॉर्स की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर कोई पॉज़िटिव नंबर <value> के तौर पर दिया गया है, तो वह जांच के लिए इस्तेमाल किए जाने वाले सभी साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगा. अगर कॉमा लगाकर अलग की गई चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बड़े साइज़ के टेस्ट साइज़ के लिए, रिसॉर्स की संख्या को बदल देंगी. वैल्यू Host_RAM/Host_CPU भी हो सकती है. विकल्प के तौर पर, इसके बाद [-|*]<float> (जैसे कि मेमोरी=Host_RAM*.1,Host_RAM*.2,Host_RAM*.3,Host_RAM*.4) भी हो सकते हैं. इस फ़्लैग से तय किए गए जांच वाले डिफ़ॉल्ट रिसॉर्स, टैग में बताए गए साफ़ तौर पर उपलब्ध रिसॉर्स से बदल जाते हैं.
--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "गलत": android_test की स्पीड बढ़ाने के लिए, dex2oat का साथ-साथ इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks डिफ़ॉल्ट: "गलत": 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. जहां Run_per_test का मतलब पूर्णांक वैल्यू होती है और regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल और बाहर करने की सूची दिखाता है. इसके अलावा, --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में सभी टेस्ट चलाता है. हालांकि, foo/bar से कम वाले टेस्ट तीन बार किए जाते हैं. यह विकल्प कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए आर्ग्युमेंट को प्राथमिकता दी जाती है. अगर कुछ भी मैच नहीं करता है, तो जांच सिर्फ़ एक बार की जाती है.
--test_env=<a 'name=value' assignment with an optional value part> बार कई बार इस्तेमाल किया गया है: टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट या name=value पेयर से पढ़ी जाएगी. कई वैरिएबल के बारे में बताने के लिए, इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
टैग: test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर कोई एक पॉज़िटिव पूर्णांक मान दिया गया है, तो वह सभी कैटगरी को ओवरराइड कर देगा. अगर कॉमा लगाकर अलग किए गए चार पूर्णांकों का पता लगाया जाता है, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. किसी भी रूप में, -1 की वैल्यू ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहती है.
--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही": अगर सही है, तो टेस्ट के ऐसे आउटपुट ZIP फ़ाइल में संग्रहित किए जाएंगे जिनका एलान नहीं किया गया है.
टैग: test_runner

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव": आउटपुट फ़ॉर्मैट {xml,proto,record} में होने पर, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को कैसे ठीक करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान किए गए सभी पहलू डिपेंडेंसी जोड़े जाते हैं. इस बात से कोई फ़र्क़ नहीं पड़ता कि उन्हें डायरेक्ट डिपेंडेंसी के नियम की क्लास दी गई है या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी के नियम क्लास के आधार पर संभावित तौर पर ऐक्टिव हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट का आकलन करने के लिए, दूसरे पैकेज को लोड करना ज़रूरी है. इससे यह अन्य मोड की तुलना में धीमा हो जाएगा. इस बात का भी ध्यान रखें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में तय किया जाता है. यह प्रोसेस, 'बैजल क्वेरी' के दौरान नहीं चलाई जाती.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से लेबल निकलते हैं, जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन का इस्तेमाल किया जाता है. यह उन टूल के लिए फ़ायदेमंद है जिन्हें नियमों से निकलने वाले अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इसे चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैटर, आउटपुट को ज़्यादा पढ़ने लायक बनाने के बजाय, साफ़ तौर पर रिपॉज़िटरी के नाम (मुख्य डेटा स्टोर करने की जगह के हिसाब से) का इस्तेमाल कर सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]graph:factored डिफ़ॉल्ट: "सही": अगर सही है, तो ग्राफ़ पर 'फ़ैक्टर' उत्सर्जित होगा. इसका मतलब है कि टॉपॉलॉजिकल रूप से समान नोड एक साथ मर्ज कर दिए जाएंगे और उनके लेबल जोड़े जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> डिफ़ॉल्ट: "512": आउटपुट में ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल में काट-छांट की जाएगी; -1 का मतलब है कि कोई काट-छांट नहीं होगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel से जोड़ा गया है. cquery के लिए यह विकल्प, समाधान किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_artifacts डिफ़ॉल्ट: "सही": इससे आउटपुट में, ऐक्शन इनपुट और आउटपुट के नाम शामिल होते हैं (शायद बड़ा).
टैग: terminal_output
--[no]include_aspects डिफ़ॉल्ट: "सही": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]include_commandline डिफ़ॉल्ट: "सही": आउटपुट में, ऐक्शन कमांड लाइन का कॉन्टेंट शामिल होता है (शायद बड़ा).
टैग: terminal_output
--[no]include_file_write_contents डिफ़ॉल्ट: "गलत": FileWrite, SourceSymlinkManifest, और RepoMapping Manifest की कार्रवाइयों (संभावित तौर पर बड़ी) के लिए, फ़ाइल का कॉन्टेंट शामिल करें.
टैग: terminal_output
--[no]include_param_files डिफ़ॉल्ट: "गलत": कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें (शायद बड़ी). ध्यान दें: इस फ़्लैग को सक्षम करने से --include_commandline फ़्लैग अपने आप सक्षम हो जाएगा.
टैग: terminal_output
--[no]include_scheduling_dependencies डिफ़ॉल्ट: "गलत": इसमें कार्रवाइयों की शेड्यूलिंग डिपेंडेंसी (संभावित रूप से बड़ी) के नाम शामिल होते हैं. यह सिर्फ़ तब लागू होता है, जब --include_artifacts भी सेट की गई हो.
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, इसके पहले `//` को हटाया नहीं जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "गलत": अगर सेट और --universe_scope सेट नहीं है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई, --universe_scope वैल्यू आपकी पसंद के मुताबिक नहीं हो सकती. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है (यानी `cquery` नहीं).
टैग: loading_and_analysis
--[no]line_terminator_null डिफ़ॉल्ट: "गलत": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म करना है.
टैग: terminal_output
--[no]nodep_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो "nodep" एट्रिब्यूट के डिपेंस को उस डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics
--output=<a string> डिफ़ॉल्ट: "text": वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: text, textproto, proto, stream_proto, jsonproto.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": सही होने पर, उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": definition_stack प्रोटो फ़ील्ड को भरें, जो नियम की क्लास तय होने के समय Starlark कॉल स्टैक के हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो select() से बनाए गए कॉन्फ़िगर करने लायक एट्रिब्यूट बराबर हो जाते हैं. सूची टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप की वैल्यू शून्य हो जाती है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स पहलू के साथ भरें जिससे एट्रिब्यूट मिला है (अगर ऐसा नहीं है, तो खाली स्ट्रिंग).
टैग: terminal_output
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत": $internal_attr_has एट्रिब्यूट का हिसाब लगाना है या नहीं, इसका पता लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत": हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग: terminal_output
--[no]proto:locations डिफ़ॉल्ट: "सही": प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "सभी": आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. कोई एट्रिब्यूट आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर क्वेरी को सेट किया जाता है, तो कमांड लाइन के बजाय, यहां दी गई फ़ाइल का नाम पढ़कर सुनाया जाएगा. यहां फ़ाइल और कमांड लाइन क्वेरी के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक ऐब्सलूट पाथ होता है और यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--[no]skyframe_state डिफ़ॉल्ट: "गलत": ज़्यादा विश्लेषण किए बिना, Skyframe के मौजूदा ऐक्शन ग्राफ़ को डंप करें. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय करने की सुविधा काम नहीं करती. यह फ़्लैग सिर्फ़ --आउटपुट=प्रोटो या --आउटपुट=textproto के साथ उपलब्ध है.
टैग: terminal_output
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: बंद होने पर, क्वेरी को ऑपरेट करने वाले डिपेंडेंसी ग्राफ़ में 'exec कॉन्फ़िगरेशन' की डिपेंडेंसी शामिल नहीं होंगी. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसा कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक जाता है. आम तौर पर, यह एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल को पॉइंट करता है. Cquery: यह विकल्प बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट exec कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए exec टारगेट दिखाए जाएंगे. इस विकल्प में ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग: build_file_semantics
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा और घटाव). क्वेरी को यूनिवर्स में परफ़ॉर्म किया जा सकता है. इसके लिए, दिए गए टारगेट को हमेशा के लिए बंद करना होगा. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माने जाते हैं. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए, इस विकल्प को तय न करने से बिल्ड में रुकावट आ सकती है.
टैग: loading_and_analysis

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "गलत": LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग: action_command_lines
--[no]experimental_inmemory_dotd_files डिफ़ॉल्ट: "सही": अगर C++ .d फ़ाइलें चालू की जाती हैं, तो उन्हें डिस्क पर सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files डिफ़ॉल्ट: "सही": चालू होने पर, Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क पर सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत": इस सुविधा को चालू करने पर, --trim_test_ Configuration, सिर्फ़ testonly=1 मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन में काट-छांट नहीं करेगा. इसका मकसद, कार्रवाई से जुड़े विवाद की समस्याओं को कम करना है. ऐसा तब किया जाता है, जब गैर-जांच नियम cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_कॉन्फ़िगरेशन गलत है, तो कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state
--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "गलत": इनपुट फ़ाइलों से #include लाइनों को पार्स करके, इनपुट को C/C++ कंपाइलेशन में बदलना है या नहीं. यह कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और बढ़ोतरी को बेहतर बना सकता है. हालांकि, इससे बिल्ड टूट भी सकते हैं, क्योंकि शामिल स्कैनर, C प्रीप्रोसेसर सिमैंटिक को पूरी तरह लागू नहीं करता. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर के कंडीशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. अगर इस फ़्लैग से जुड़ी कोई समस्या है, तो उसे बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs
--[no]incremental_dexing डिफ़ॉल्ट: "सही": ज़्यादातर जार फ़ाइल को डीक्स करने का ज़्यादातर काम अलग-अलग किया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही": अगर इस नीति को सेट किया जाता है, तो clang से उत्सर्जित होने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइलेशन में पास किए गए इनपुट के सेट को हटाने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत": टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग: execution
--[no]trim_test_configuration डिफ़ॉल्ट: "सही": यह सुविधा चालू होने पर, बिल्ड के टॉप लेवल के नीचे जांच से जुड़े विकल्प हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को गैर-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में किए जाने वाले बदलावों की वजह से, टेस्ट न करने वाले नियमों का फिर से विश्लेषण नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state

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

--flag_alias=<a 'name=value' flag alias> बार कई बार इस्तेमाल किया गया है: स्टारलार्क फ़्लैग के लिए, यह छोटा नाम सेट करता है. यह तर्क के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर होता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत": यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन जाएं. आम तौर पर, जब किसी py_binary या py_test टारगेट में lead_create_init को "ऑटो" (डिफ़ॉल्ट) पर सेट किया जाता है, तो यह 'गलत' के तौर पर तब ही माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही": अगर 'सही' है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स शामिल नहीं है. इसका मतलब है कि `bazel-bin` सुविधा का सिमलिंक, Python 2 के बजाय Python 3 के टारगेट को पॉइंट करेगा. अगर इस विकल्प को चालू किया जाता है, तो `--insupported_py3_is_default` को चालू करने का भी सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही": सही होने पर, `py_binary` और `py_test` एट्रिब्यूट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. अगर इस फ़्लैग को सेट किया जाता है, तो `--insupported_py2_OUTs_are_suffixed` को सेट करने का सुझाव भी दिया जाता है.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो एक्ज़ीक्यूटेबल नेटिव Python नियम, --python_top जैसे लेगसी फ़्लैग से दिए गए रनटाइम के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल करेंगे.
टैग: 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] डिफ़ॉल्ट: "ऑटो": अगर यह नीति 'ऑटो' पर सेट है, तो Bazel फिर से टेस्ट तब करता है, जब: (1) Bazel को, जांच में हुए बदलाव या उसकी डिपेंडेंसी का पता चलता हो, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test की मदद से कई बार टेस्ट करने का अनुरोध किया गया हो या(4) जांच पहले असफल हो गई हो. अगर यह नीति 'हां' पर सेट है, तो बाहरी के तौर पर मार्क किए गए टेस्ट के अलावा, Bazel जांच के सभी नतीजों को कैश मेमोरी में सेव करेगा. अगर यह नीति 'नहीं' पर सेट है, तो Bazel जांच के किसी भी नतीजे को कैश मेमोरी में सेव नहीं करेगा.
--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत": सही होने पर, Blaze पहले सफल रन पर एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ इस्तेमाल करने पर ही काम करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो Bazel, कवरेज के दौरान हर टेस्ट के लिए पूरी कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "गलत": अगर सही है, तो क्लैंग के लिए कवरेज, एलसीओवी रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_j2objc_header_map डिफ़ॉल्ट: "सही": J2ObjC ट्रांसपिलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "गलत": छोटे हेडर पाथ के साथ जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग: affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javaBuilder": Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ चालू करें.
--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत": Android के साथ काम करने वाली लाइब्रेरी तक --experimental_run_android_lint_on_java_rules पर सीमित करें.
टैग: affects_outputs
--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत": Java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs
--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत": टेस्टरनर के डिप से गलती से डेटा हासिल करने के बजाय, java_test में JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ बैजल के लिए काम करता है.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: विवरण देखें: यह Java लॉन्चर, उन टूल में इस्तेमाल होता है जो बिल्ड होने के दौरान एक्ज़ीक्यूट होते हैं.
--host_javacopt=<a string> बार कई बार इस्तेमाल किया गया है: किसी बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल बनाते समय, javac को पास करने के ज़्यादा विकल्प.
--host_jvmopt=<a string> बार कई बार इस्तेमाल किया गया है: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, Java वीएम को पास करने के ज़्यादा विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही": अगर सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि उसके पाथ में फ़ाइल को TEST_SHARD_STATUS_FILE में जोड़ा जा सकता है, तो Bazel शार्ड किए गए टेस्ट को फ़ेल कर देगा. गलत होने पर, अगर शार्डिंग की सुविधा काम नहीं करती, तो टेस्ट रनर की वजह से हर शार्ड में सभी टेस्ट चल रहे होंगे.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही": अगर सही है, तो सैंडबॉक्स रणनीति की मदद से खास टेस्ट चलाए जाएंगे. सिर्फ़ स्थानीय स्तर पर टेस्ट चलाने के लिए 'लोकल' टैग जोड़ें
टैग: incompatible_change
--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत": अगर सही है, तो 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_internal=streamed को शामिल किया गया है.
इसमें शामिल है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps डिफ़ॉल्ट: "सही": हर Java टारगेट के लिए डिपेंडेंसी जानकारी (अभी, कंपाइल-टाइम क्लासपाथ) जनरेट करें.
--[no]java_header_compilation डिफ़ॉल्ट: "सही": सीधे सोर्स से जरार इकट्ठा करें.
--java_language_version=<a string> डिफ़ॉल्ट: "": जावा भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: विवरण देखें: Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर यह फ़्लैग खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": जावा रनटाइम वर्शन
--javacopt=<a string> बार कई बार इस्तेमाल किया गया है: javac पर भेजने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> बार कई बार इस्तेमाल किया गया है: Java वीएम को पास करने के दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: विवरण देखें: ऐसी क्लास की सूची जनरेट करने के लिए बाइनरी के बारे में बताता है जिसका इस्तेमाल लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य dex में होना चाहिए.
--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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल जिसमें C++ Protos को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल जिसमें Java Protos को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@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 डिफ़ॉल्ट: "गलत": अगर सही हो, तो कम से कम एक रन/अटेंप्ट में पास होने पर और कम से कम एक रन/अटैम फ़ेल होने पर उसे 'फ़्लेकी' स्टेटस मिल जाता है.
--shell_executable=<a path> डिफ़ॉल्ट: विवरण देखें: BZel के इस्तेमाल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को पहले Bazel सर्वर पर सेट किया गया है, जो Bazel सर्वर को शुरू करता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करेगा. यह उस ऑपरेटिंग सिस्टम के हिसाब से तय होगा जिस पर वह चलता है (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash). ध्यान दें कि अगर किसी ऐसे शेल का इस्तेमाल किया जाता है जो बैश के साथ काम नहीं करता, तो जनरेट की गई बाइनरी के रनटाइम या रनटाइम फ़ेल हो सकते हैं.
टैग: loading_and_analysis
--test_arg=<a string> बार कई बार इस्तेमाल किया गया है: उन अतिरिक्त विकल्पों और तर्क के बारे में बताता है जिन्हें टेस्ट एक्ज़ीक्यूटेबल के लिए पास किया जाना चाहिए. अलग-अलग आर्ग्युमेंट का इस्तेमाल करने के लिए, एक से ज़्यादा बार इस्तेमाल किया जा सकता है. अगर कई जांच की जाती हैं, तो सभी को एक जैसे तर्क मिलेंगे. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
--test_filter=<a string> डिफ़ॉल्ट: विवरण देखें: टेस्ट फ़्रेमवर्क पर भेजने के लिए एक फ़िल्टर तय करता है. इसका इस्तेमाल, जांच को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे बनाए गए टारगेट पर कोई असर नहीं पड़ता.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": यह विकल्प अब काम नहीं करता और इसका कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत": टेस्ट रनर पर तेज़ी से फ़ॉरवर्ड करने का विकल्प फ़ेल हो गया. पहली बार असफल होने पर, टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "अश्लील": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'साफ़ तौर पर' शार्डिंग का इस्तेमाल सिर्फ़ तब करें, जब 'sard_count' BUILD एट्रिब्यूट मौजूद हो. टेस्ट शार्डिंग का इस्तेमाल कभी नहीं करने के लिए 'बंद' है. 'forced=k' की मदद से, जांच के लिए 'k' शार्ड लागू किए जा सकते हैं, भले ही 's आम तौर पर काउंट' BUILD एट्रिब्यूट कुछ भी हो.
--tool_java_language_version=<a string> डिफ़ॉल्ट: "": जावा भाषा का वर्शन, जिसका इस्तेमाल उन टूल को चलाने के लिए किया जाता है जो बिल्ड बनाने के दौरान ज़रूरी होते हैं
--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11": बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन
--[no]use_ijars डिफ़ॉल्ट: "सही": अगर यह विकल्प चालू है, तो इस विकल्प की वजह से Java कंपाइलेशन में इंटरफ़ेस जार का इस्तेमाल होता है. इससे, कंपाइलेशन तेज़ी से बढ़ेगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

बिल्ड के विकल्प

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

--[no]check_up_to_date डिफ़ॉल्ट: "गलत": बिल न बनाएं, बस देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड पूरा हो जाता है. अगर किसी चरण को पूरा करने की ज़रूरत होती है, तो गड़बड़ी की शिकायत की जाती है और बिल्ड काम नहीं करता.
टैग: execution
--dynamic_local_execution_delay=<an integer> डिफ़ॉल्ट: "1000": अगर किसी बिल्ड के दौरान रिमोट एक्ज़ीक्यूशन तेज़ था, तो लोकल एक्ज़ीक्यूशन में कितने मिलीसेकंड में देरी होनी चाहिए?
टैग: execution, host_machine_resource_optimizations
--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment> बार कई बार इस्तेमाल किया गया है: इन याददाश्तों के इस्तेमाल के लिए, स्थानीय रणनीतियों का इस्तेमाल किया जाता है. ये रणनीतियां सबसे पहले लागू होती हैं. उदाहरण के लिए, `worker,sandboxed` ऐसी कार्रवाइयां करता है जो वर्कर रणनीति का इस्तेमाल करके लगातार काम करने वाले कर्मचारियों की मदद करती हैं और सैंडबॉक्स की गई रणनीति का इस्तेमाल करने वाली अन्य सभी कंपनियों की मदद करती हैं. अगर कोई याददाश्त नहीं दी गई है, तो रणनीतियों की इस सूची का इस्तेमाल सभी याददाश्त के लिए फ़ॉलबैक के तौर पर किया जाता है. अगर `experimental_local_lockfree_ घटना" सेट है,तो डिफ़ॉल्ट फ़ॉलबैक सूची `worker, sandboxed` या`worker,sandboxed,Standalone` है. [mnemonic=]local_strategy[,local_strategy,...] का इस्तेमाल किया जाता है
टैग: execution, host_machine_resource_optimizations
--dynamic_remote_strategy=<a '[name=]value1[,..,valueN]' assignment> बार कई बार इस्तेमाल किया गया है: इन याददाश्त के लिए रिमोट रणनीतियों का इस्तेमाल किया जाता है - सबसे पहले लागू होने वाली रणनीति का इस्तेमाल किया जाता है. अगर कोई याददाश्त नहीं दी गई है, तो रणनीतियों की इस सूची का इस्तेमाल सभी याददाश्त के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `रिमोट` होती है. इसलिए, इस फ़्लैग को आम तौर पर साफ़ तौर पर सेट करने की ज़रूरत नहीं होती. [mnemonic=]remote_strategy[,remote_strategy,...] का इस्तेमाल करता है
टैग: execution, host_machine_resource_optimizations
--experimental_docker_image=<a string> डिफ़ॉल्ट: "": Docker इमेज का नाम (जैसे कि "ubuntu:latest") तय करें, ताकि Docker रणनीति का इस्तेमाल करते समय, सैंडबॉक्स की गई कार्रवाई को लागू किया जा सके. साथ ही, प्लैटफ़ॉर्म की जानकारी में मौजूद asset_execution_property में, ऐक्शन के लिए पहले से कोई कंटेनर-इमेज एट्रिब्यूट मौजूद न हो. इस फ़्लैग की वैल्यू 'docker Run' को हूबहू पास की जाती है. ऐसा इसलिए किया जाता है, ताकि यह उसी सिंटैक्स और सिस्टम के साथ काम करता हो जिसका इस्तेमाल Docker खुद करता है.
टैग: execution
--[no]experimental_docker_use_customized_images डिफ़ॉल्ट: "सही": यह सुविधा चालू होने पर, मौजूदा उपयोगकर्ता का uid और gid इस्तेमाल करने से पहले, Docker इमेज में इंजेक्ट किया जाता है. यह तब ज़रूरी होता है, जब बिल्ड / टेस्ट इस बात पर निर्भर करता है कि उपयोगकर्ता के कंटेनर के अंदर नाम और होम डायरेक्ट्री है या नहीं. यह सुविधा डिफ़ॉल्ट रूप से चालू रहती है. हालांकि, अगर आपके मामले में इमेज को अपने-आप पसंद के मुताबिक बनाने की सुविधा काम नहीं करती या आपको लगता है कि आपको इसकी ज़रूरत नहीं है, तो इस सुविधा को बंद किया जा सकता है.
टैग: execution
--[no]experimental_dynamic_exclude_tools डिफ़ॉल्ट: "सही": सेट करने के बाद, "टूल के लिए" बनाए गए टारगेट को डाइनैमिक तौर पर एक्ज़ीक्यूशन नहीं किया जाता. ऐसे टारगेट के बढ़ने की संभावना बहुत कम होती है. इसलिए, इस तरह के टारगेट पर लोकल साइकल खर्च करने की कोई ज़रूरत नहीं होती.
टैग: execution, host_machine_resource_optimizations
--experimental_dynamic_local_load_factor=<a double> डिफ़ॉल्ट: "0": यह कंट्रोल करता है कि डाइनैमिक एक्ज़ीक्यूशन से लोकल मशीन पर कितना लोड लोड होना चाहिए. यह फ़्लैग बताता है कि डाइनैमिक एक्ज़ीक्यूशन में हम एक साथ कितनी कार्रवाइयों को शेड्यूल करेंगे. यह ब्लेज़ के उपलब्ध होने वाले सीपीयू की संख्या पर आधारित है, जिसे --local_cpu_resources फ़्लैग से कंट्रोल किया जा सकता है. अगर यह फ़्लैग 0 है, तो सभी कार्रवाइयां तुरंत स्थानीय तौर पर शेड्यूल की जाती हैं. अगर 0 से ज़्यादा है, तो स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या, उपलब्ध सीपीयू की संख्या के हिसाब से सीमित होती है. अगर < 1 है, तो शेड्यूल किए जाने के लिए इंतज़ार करने वाली कार्रवाइयों की संख्या ज़्यादा होने पर, लोड फ़ैक्टर का इस्तेमाल स्थानीय रूप से शेड्यूल की गई कार्रवाइयों की संख्या को कम करने के लिए किया जाता है. इससे क्लीन बिल्ड केस में, लोकल मशीन पर कम लोड पड़ता है, जहां लोकल मशीन ज़्यादा योगदान नहीं देती.
टैग: execution, host_machine_resource_optimizations
--experimental_dynamic_slow_remote_time=<An immutable length of time.> डिफ़ॉल्ट: "0": अगर 0 से ज़्यादा हो, तो डाइनैमिक तौर पर चलने वाली कार्रवाई के लिए ज़रूरी है कि उसे सिर्फ़ रिमोट से चलाया जाए. इसके बाद ही, हम उस कार्रवाई को लोकल एक्ज़ीक्यूशन के लिए प्राथमिकता देते हैं. ऐसा, रिमोट टाइम आउट से बचने के लिए किया जाता है. इससे रिमोट एक्ज़ीक्यूशन सिस्टम पर होने वाली कुछ समस्याएं छिप सकती हैं. रिमोट तौर पर प्रोग्राम चलाने की समस्याओं को मॉनिटर किए बिना, इस सुविधा को चालू न करें.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_enable_docker_sandbox डिफ़ॉल्ट: "गलत": डॉकर पर आधारित सैंडबॉक्सिंग चालू करें. अगर 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"> डिफ़ॉल्ट: "4": अगर वैल्यू 0 है, तो कार्रवाई पूरी होते ही सैंडबॉक्स ट्री को मिटा दें (इसकी वजह से, कार्रवाई पूरी होने में देरी हो सकती है). अगर यह संख्या शून्य से ज़्यादा है, तो एसिंक्रोनस थ्रेड पूल पर इस तरह के थ्री को मिटाने की प्रोसेस तब शुरू करें, जब बिल्ड चल रहा हो. साथ ही, जब बिल्ड चल रहा हो, तब इस फ़्लैग से तय किए गए साइज़ तक बढ़ जाए.
टैग: host_machine_resource_optimizations, execution
--experimental_sandbox_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0": अगर 0 से ज़्यादा है, तो हर Linux सैंडबॉक्स में मेमोरी की तय सीमा (एमबी में) होगी. cgroups v1 या v2 और उपयोगकर्ताओं के लिए cgroups की डायरेक्ट्री की अनुमतियां ज़रूरी हैं.
टैग: execution
--[no]experimental_shrink_worker_pool डिफ़ॉल्ट: "गलत": अगर इस सेटिंग को चालू किया जाता है, तो कर्मचारियों की मेमोरी का दबाव ज़्यादा होने पर, वर्कर पूल को छोटा किया जा सकता है. यह फ़्लैग सिर्फ़ तब काम करता है, जब 'एक्सपेरिमेंट_total_worker_memory_limit_mb' फ़्लैग चालू हो.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_split_xml_generation डिफ़ॉल्ट: "सही": अगर यह फ़्लैग सेट है और टेस्ट ऐक्शन से 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>.> डिफ़ॉल्ट: "0": अगर यह सीमा शून्य से ज़्यादा है, तो सभी कामगारों का कुल मेमोरी इस्तेमाल सीमा से ज़्यादा हो जाने पर काम न करने वाले कर्मचारियों की मौत हो सकती है.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_use_hermetic_linux_sandbox डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो रूट को माउंट न करें. सिर्फ़ sandbox_add_mount_pair के साथ दिए गए आइटम को ही माउंट करें. इनपुट फ़ाइलों को सैंडबॉक्स से सिमलिंक करने के बजाय, सैंडबॉक्स से हार्डलिंक किया जाएगा. अगर ऐक्शन इनपुट फ़ाइलें, सैंडबॉक्स से अलग किसी दूसरे फ़ाइल सिस्टम पर मौजूद हैं, तो इनपुट फ़ाइलों की कॉपी बनाई जाएगी.
टैग: execution
--[no]experimental_use_semaphore_for_jobs डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो एक साथ किए जाने वाले जॉब की संख्या को सीमित करने के लिए, सेमैपोर का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution
--[no]experimental_use_windows_sandbox डिफ़ॉल्ट: "गलत": कार्रवाइयां करने के लिए, Windows सैंडबॉक्स का इस्तेमाल करें. अगर "हां" है, तो --experimental_window_sandbox_path मान्य होना चाहिए और सैंडबॉक्सfs के साथ काम करने वाले वर्शन से मेल खाना चाहिए. अगर यह "अपने-आप" पर सेट है, तो हो सकता है कि बाइनरी मौजूद न हो या उसके साथ काम न करती हो.
टैग: execution
--experimental_windows_sandbox_path=<a string> डिफ़ॉल्ट: "BazelSandbox.exe": --experimental_use_ windows_sandbox के सही होने पर इस्तेमाल करने के लिए, Windows सैंडबॉक्स बाइनरी का पाथ. अगर कोई नाम नहीं है, तो PATH में मिलने वाले नाम की पहली बाइनरी का इस्तेमाल करें.
टैग: execution
--experimental_worker_allowlist=<comma-separated set of options> डिफ़ॉल्ट: विवरण देखें: अगर यह फ़ील्ड खाली नहीं है, तो सिर्फ़ काम करने वाले वर्कर को, दिए गए वर्कर की मेनेमोनिक के साथ इस्तेमाल करने की अनुमति दें.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_worker_as_resource डिफ़ॉल्ट: "सही": नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग: no_op
--[no]experimental_worker_cancellation डिफ़ॉल्ट: "गलत": अगर यह सुविधा चालू की जाती है, तो Bazel उन कर्मचारियों को रद्द करने के अनुरोध भेज सकता है जो उनका समर्थन करते हैं.
टैग: execution
--experimental_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0": अगर यह सीमा शून्य से ज़्यादा है, तो मेमोरी का इस्तेमाल करने पर, वर्कर की मौत हो सकती है. अगर डाइनैमिक एक्ज़ीक्यूशन और `--experimental_Dynamic_ignore_local_signals=9` के साथ इस्तेमाल नहीं किया गया है, तो इससे आपका बिल्ड क्रैश हो सकता है.
टैग: execution, host_machine_resource_optimizations
--experimental_worker_metrics_poll_interval=<An immutable length of time.> डिफ़ॉल्ट: "5s": कर्मचारियों की मेट्रिक इकट्ठा करने और शायद उन्हें हटाने की कोशिश करने के बीच का अंतराल. परफ़ॉर्मेंस की वजह से, 1 सेकंड से कम नहीं हो सकता.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_worker_multiplex_sandboxing डिफ़ॉल्ट: "गलत": यह सुविधा चालू होने पर, मल्टीप्लेक्स कर्मचारियों को सैंडबॉक्स किया जाएगा. इसके लिए, हर ऑफ़िस के अनुरोध के लिए एक अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल किया जाएगा. सिर्फ़ उन कर्मचारियों को सैंडबॉक्स किया जाएगा जिनके लिए 'support-multiplex-sandboxing' लागू करने की ज़रूरी शर्त पूरी होती है.
टैग: execution
--[no]experimental_worker_sandbox_hardening डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो लागू होने की अनुमति मिलने पर वर्कर, कड़े सैंडबॉक्स में चलाए जाते हैं.
टैग: execution
--[no]experimental_worker_strict_flagfiles डिफ़ॉल्ट: "गलत": चालू होने पर, वर्कर की शर्तों का पालन न करने वाले वर्कर के लिए दिए गए ऐक्शन आर्ग्युमेंट के इस्तेमाल से गड़बड़ी होगी. वर्कर आर्ग्युमेंट में, तर्कों की अपनी सूची के आखिरी में सिर्फ़ एक @flagfile तर्क होना चाहिए.
टैग: execution
--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": इस्तेमाल की गई मेमोरी का प्रतिशत (0-100) और इससे ज़्यादा GcTtrazingDetector, मेमोरी दबाव की घटनाओं को अपनी सीमा के हिसाब से (--gc_thrazing_limits). अगर इस नीति को 100 पर सेट किया जाता है, तो GcThrgingDetector को बंद कर दिया जाता है.
टैग: host_machine_resource_optimizations
--genrule_strategy=<comma-separated list of options> डिफ़ॉल्ट: "": जननियम लागू करने का तरीका बताएं. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> का इस्तेमाल करें या सिर्फ़ जनरेट को कंट्रोल करने के लिए --strategy=Gen rules=<value> का इस्तेमाल करें.
टैग: execution
--high_priority_workers=<a string> बार कई बार इस्तेमाल किया गया है: नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग: execution
--[no]incompatible_remote_dangling_symlinks डिफ़ॉल्ट: "सही": अगर इसे 'सही है' पर सेट किया जाता है, तो रिमोट या डिस्क की कैश मेमोरी में अपलोड किए गए सिमलिंक, लटक सकते हैं.
टैग: execution, incompatible_change
--[no]incompatible_remote_symlinks डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो Bazel हमेशा रिमोट या डिस्क कैश मेमोरी जैसे सिमलिंक अपलोड करेगा. अगर ऐसा नहीं होता है, तो नॉन-ड्रैगिंग वाले सिमलिंक (सिर्फ़ वे) उस फ़ाइल या डायरेक्ट्री के तौर पर अपलोड किए जाएंगे जिसकी ओर वे इशारा करते हैं.
टैग: execution, incompatible_change
--[no]incompatible_sandbox_hermetic_tmp डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो हर Linux सैंडबॉक्स के लिए खाली डायरेक्ट्री को /tmp के तौर पर माउंट किया जाएगा. इस फ़ाइल को होस्ट फ़ाइल सिस्टम के साथ /tmp शेयर करने के बजाय, /tmp के तौर पर माउंट किया जाएगा. सभी सैंडबॉक्स में होस्ट का/tmp देखते रहने के लिए --sandbox_add_mount_pair=/tmp का इस्तेमाल करें.
टैग: execution
--[no]internal_spawn_scheduler डिफ़ॉल्ट: "गलत": प्लेसहोल्डर का विकल्प, ताकि हम 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] डिफ़ॉल्ट: "ऑटो": चलने के लिए एक साथ किए जाने वाले जॉब की संख्या. कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<फ़्लोट>) करें, उदाहरण के लिए. "auto", "Host_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. वैल्यू 2,500 से ज़्यादा होने पर, मेमोरी से जुड़ी समस्याएं हो सकती हैं. "अपने-आप", होस्ट के संसाधनों के आधार पर सही डिफ़ॉल्ट वैल्यू को कैलकुलेट करता है.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": लोडिंग/विश्लेषण फ़ेज़ में इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. उदाहरण के लिए. "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration
--[no]reuse_sandbox_directories डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स की हुई डायरेक्ट्री में, काम न करने वाले कर्मचारी जिन डायरेक्ट्री का इस्तेमाल करते हैं उनका फिर से इस्तेमाल किया जा सकता है. ऐसा करने से, सेटअप करने में लगने वाले बेवजह शुल्क से बचा जा सकता है.
टैग: host_machine_resource_optimizations, execution
--sandbox_base=<a string> डिफ़ॉल्ट: "": इसकी मदद से, सैंडबॉक्स को इस पाथ के नीचे अपनी सैंडबॉक्स डायरेक्ट्री बनाने की सुविधा मिलती है. आपके बिल्ड /टेस्ट में कई इनपुट फ़ाइलें होने पर, tmpfs (जैसे कि/run / shm) पर कोई पाथ तय करें. इससे परफ़ॉर्मेंस बेहतर हो सकती है. ध्यान दें: कार्रवाइयों की वजह से जनरेट हुए आउटपुट और इंटरमीडिएट फ़ाइलों को होल्ड करने के लिए, आपको tmpfs पर ज़रूरत के मुताबिक रैम और खाली जगह की ज़रूरत है.
टैग: host_machine_resource_optimizations, execution
--[no]sandbox_explicit_pseudoterminal डिफ़ॉल्ट: "गलत": सैंडबॉक्स की गई कार्रवाइयों के लिए, स्यूडोटर्मिनल बनाने की सुविधा साफ़ तौर पर चालू करें. कुछ Linux डिस्ट्रिब्यूशन के लिए, सैंडबॉक्स के अंदर प्रोसेस के ग्रुप आईडी को 'tty' पर सेट करना ज़रूरी होता है, ताकि स्यूडोटर्मिनल काम कर सकें. अगर इससे समस्या हो रही है, तो इस फ़्लैग को बंद किया जा सकता है, ताकि दूसरे ग्रुप का इस्तेमाल किया जा सके.
टैग: execution
--sandbox_tmpfs_path=<an absolute path> बार कई बार इस्तेमाल किया गया है: सैंडबॉक्स की गई कार्रवाइयों के लिए, इस ऐब्सलूट पाथ पर, एक खाली और ऐसी डायरेक्ट्री को माउंट करें जो खाली हो और जिसे लिखा जा सके. अगर सैंडबॉक्सिंग सुविधा इसके साथ काम करती है, तो इसे अनदेखा कर दिया जाएगा.
टैग: host_machine_resource_optimizations, execution
--[no]skip_incompatible_explicit_targets डिफ़ॉल्ट: "गलत": कमांड लाइन में साफ़ तौर पर सूची में शामिल काम न करने वाले टारगेट को छोड़ें. डिफ़ॉल्ट रूप से, ऐसे टारगेट बनाने में गड़बड़ी होती है. हालांकि, यह विकल्प चालू होने पर उन्हें बिना किसी रुकावट के स्किप कर दिया जाता है. देखें: https://bazel.build/extending/platforms#ski चुनाव-insupported-targets
टैग: loading_and_analysis
--spawn_strategy=<comma-separated list of options> डिफ़ॉल्ट: "": यह तय करें कि डिफ़ॉल्ट तौर पर, Spwn की कार्रवाइयां कैसे होती हैं. यह सबसे ऊंची से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार करता है. हर कार्रवाई के लिए 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 (और --genनियम_strategy) से सेट की गई वैल्यू को बदल देता है, अगर इसे mnemonic Genroll के साथ इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution
--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> बार कई बार इस्तेमाल किया गया है: यह तय करें कि जिन स्पॉन ऐक्शन को लागू करने के लिए, कौनसी स्पॉन्सर रणनीति इस्तेमाल की जानी चाहिए उनमें कुछ रेगुलर एक्सप्रेशन_फ़िल्टर से मैच करने वाली जानकारी शामिल हो. रेगुलर एक्सप्रेशन फ़िल्टर मैचिंग के बारे में जानकारी पाने के लिए, --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 होगा. उसे 'स्थानीय' रणनीति के साथ 'कंपाइलिंग //foo/bar/baz' चला देगा, लेकिन क्रम विपरीत करने पर यह 'सैंडबॉक्स' के साथ चलेगा.
टैग: 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] के तौर पर बताया जा सकता है. यह सीमा वर्कर के आधार पर तय होती है, जिन्हें याददाश्त के आधार पर अलग-अलग किया जाता है. साथ ही, इन्हें स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में इस फ़्लैग से तय की गई संख्या से ज़्यादा, हर याददाश्त काम करने वाले लोगों की संख्या ज़्यादा हो सकती है. कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<फ़्लोट>) करें, उदाहरण के लिए. "auto", "Host_CPUS*.5". 'ऑटो', मशीन की क्षमता के आधार पर उचित डिफ़ॉल्ट वैल्यू कैलकुलेट करता है. "=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' रणनीति का इस्तेमाल --worker_multiplex के साथ किया जाता है, तो मल्टीप्लेक्स वर्कर प्रोसेस को एक साथ कितने WorkRequests मिल सकते हैं. हर याद के हिसाब से अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर बताया जा सकता है. यह सीमा वर्कर के आधार पर तय होती है, जिन्हें याददाश्त के आधार पर अलग-अलग किया जाता है. साथ ही, इन्हें स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में इस फ़्लैग से तय की गई संख्या से ज़्यादा, हर याददाश्त काम करने वाले लोगों की संख्या ज़्यादा हो सकती है. कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<फ़्लोट>) करें, उदाहरण के लिए. "auto", "Host_CPUS*.5". 'ऑटो', मशीन की क्षमता के आधार पर उचित डिफ़ॉल्ट वैल्यू कैलकुलेट करता है. "=value" तय नहीं किए गए स्नेमनिक के लिए डिफ़ॉल्ट सेट करता है.
टैग: execution, host_machine_resource_optimizations
--[no]worker_multiplex डिफ़ॉल्ट: "सही": अगर यह सुविधा चालू है, तो वर्कर इसके साथ काम करने पर मल्टीप्लेक्स का इस्तेमाल करेंगे.
टैग: execution, host_machine_resource_optimizations
--[no]worker_quit_after_build डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो बिल्ड पूरा होने के बाद, सभी वर्कर बाहर निकल जाते हैं.
टैग: execution, host_machine_resource_optimizations
--[no]worker_sandboxing डिफ़ॉल्ट: "गलत": यह सेटिंग चालू होने पर, वर्कर को सैंडबॉक्स एनवायरमेंट में एक्ज़ीक्यूट किया जाएगा.
टैग: execution
--[no]worker_verbose डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो वर्कर के शुरू होने, शटडाउन होने पर वर्बोस मैसेज प्रिंट करता है ...

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

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

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

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

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

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

--[no]experimental_docker_privileged डिफ़ॉल्ट: "गलत": अगर यह सेटिंग चालू की जाती है, तो Bazel कार्रवाइयों के दौरान, --प्राथमिकता वाले फ़्लैग को 'docker running' को पास कर देगा. आपके बिल्ड के लिए इसकी ज़रूरत पड़ सकती है, लेकिन इससे हर्मेटिटी कम भी हो सकती है.
टैग: execution
--[no]experimental_sandboxfs_map_symlink_targets डिफ़ॉल्ट: "गलत": No-op
टैग: host_machine_resource_optimizations, execution
--[no]incompatible_legacy_local_fallback डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तो लेगसी इंप्लिसिट फ़ॉलबैक चालू होने पर, सैंडबॉक्स की गई स्थानीय रणनीति में, लेगसी इंप्लिसिट फ़ॉलबैक चालू हो जाता है. यह फ़्लैग डिफ़ॉल्ट रूप से 'गलत' पर सेट हो जाएगा और फिर नो-ऑप बन जाएगा. इसके बजाय, फ़ॉलबैक कॉन्फ़िगर करने के लिए --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 डिफ़ॉल्ट: "सही": कार्रवाइयों के लिए डिफ़ॉल्ट रूप से, नेटवर्क का ऐक्सेस दें. ऐसा हो सकता है कि यह सभी सैंडबॉक्सिंग प्रोसेस के साथ काम न करे.
टैग: execution
--[no]sandbox_fake_hostname डिफ़ॉल्ट: "गलत": सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग: execution
--[no]sandbox_fake_username डिफ़ॉल्ट: "गलत": सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'nobody' के तौर पर सेट करें.
टैग: execution
--sandbox_writable_path=<a string> बार कई बार इस्तेमाल किया गया है: सैंडबॉक्स की गई कार्रवाइयों के लिए, सैंडबॉक्स में किसी मौजूदा डायरेक्ट्री को लिखने लायक बनाएं (अगर सैंडबॉक्सिंग की सुविधा काम करती है, तो इसे अनदेखा कर दें).
टैग: execution

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

--[no]check_tests_up_to_date डिफ़ॉल्ट: "गलत": टेस्ट न करें. बस यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी जांच के नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर किसी जांच को बनाने या लागू करने की ज़रूरत होती है, तो गड़बड़ी की रिपोर्ट की जाती है और टेस्टिंग फ़ेल हो जाती है. इस विकल्प का मतलब है --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' के तौर पर मार्क किया जाता है. आम तौर पर, वैल्यू के तौर पर सिर्फ़ एक पूर्णांक या 'डिफ़ॉल्ट' स्ट्रिंग होती है. अगर पूर्णांक है, तो सभी टेस्ट N बार तक चलाए जाएंगे. अगर यह 'डिफ़ॉल्ट' है, तो सामान्य जांचों के लिए सिर्फ़ एक बार जांच करने की कोशिश की जाएगी. साथ ही, उन टेस्ट के लिए तीन बार कोशिश की जाएगी जिन्हें उनके नियम के मुताबिक, साफ़ तौर पर अस्थिर के तौर पर मार्क किया गया है (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 से जुड़ी जांच तीन बार नहीं की जा सकतीं. यह विकल्प कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए आर्ग्युमेंट को प्राथमिकता दी जाती है. अगर कुछ भी मेल नहीं खाता है, तो व्यवहार ऊपर दिए गए 'डिफ़ॉल्ट' की तरह होता है.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": एक साथ चलाए जाने वाले लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<फ़्लोट>) करें, उदाहरण के लिए. "auto", "Host_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, लोकल टेस्ट जॉब की संख्या को एक साथ चलाने के लिए सीमित कर देंगे. इसे --jobs के लिए मान से ज़्यादा पर सेट करना बेअसर होता है.
टैग: execution
--[no]test_keep_going डिफ़ॉल्ट: "सही": यह सुविधा बंद होने पर, पास न होने वाले किसी भी टेस्ट से पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से सभी टेस्ट चलते हैं, भले ही कुछ टेस्ट पास नहीं हो पाते.
टैग: execution
--test_strategy=<a string> डिफ़ॉल्ट: "": इससे पता चलता है कि टेस्ट करते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution
--test_tmpdir=<a path> डिफ़ॉल्ट: विवरण देखें: 'bazel टेस्ट' के लिए बेस अस्थायी डायरेक्ट्री तय करता है.

--[no]experimental_parallel_aquery_output डिफ़ॉल्ट: "सही": नहीं.

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

--cache_computed_file_digests=<a long integer> डिफ़ॉल्ट: "50000": अगर यह वैल्यू 0 से ज़्यादा है, तो Bazel को कॉन्फ़िगर करें. इससे, Drive में मौजूद डाइजेस्ट फ़ाइल को हर बार ज़रूरत होने पर, फिर से कंप्यूट करने के बजाय, उनके मेटाडेटा के आधार पर मेमोरी में मौजूद फ़ाइलों को कैश मेमोरी में सेव किया जाएगा. इसे 0 पर सेट करने से सही जानकारी मिलती है, क्योंकि फ़ाइल के मेटाडेटा से फ़ाइल में किए गए सभी बदलावों को नोट नहीं किया जा सकता. अगर वैल्यू 0 नहीं है, तो यह संख्या, कैश मेमोरी में सेव की जाने वाली फ़ाइल डाइजेस्ट की संख्या के तौर पर कैश के साइज़ को दिखाती है.
--experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers> डिफ़ॉल्ट: विवरण देखें: इसमें ओएस सिग्नल नंबर की सूची होती है. अगर डाइनैमिक एक्ज़ीक्यूशन की कोई लोकल ब्रांच, इनमें से किसी भी सिग्नल की वजह से बंद हो जाती है, तो रिमोट ब्रांच को पूरा करने की अनुमति दी जाएगी. लगातार काम करने वाले कर्मचारियों पर, इससे सिर्फ़ उन संकेतों पर असर पड़ता है जिनसे कर्मचारियों की काम करने की प्रक्रिया में रुकावट आती है.
टैग: execution
--[no]experimental_enable_skyfocus डिफ़ॉल्ट: "गलत": अगर आपने वैल्यू सही है, तो इंक्रीमेंटल (बढ़ने वाले) बिल्ड के लिए, Bazel की मेमोरी फ़ुटप्रिंट कम करने के लिए --experimental_work_set का इस्तेमाल चालू करें. इस सुविधा को स्काईफ़ोकस के नाम से जाना जाता है.
टैग: host_machine_resource_optimizations
--experimental_working_set=<comma-separated list of options> डिफ़ॉल्ट: "": Sस्काईफ़ोकस के लिए काम करने का सेट. फ़ाइल फ़ोल्डर के रूट-रिलेटिव पाथ को कॉमा लगाकर अलग करें. यह एक स्टेटफ़ुल फ़्लैग है. वर्किंग सेट तय करने पर, वह बाद में शुरू होने वाली बातचीत के लिए बना रहता है, जब तक कि उसे नए सेट के साथ फिर से परिभाषित नहीं किया जाता.
टैग: host_machine_resource_optimizations
--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "Host_CPUS": स्थानीय तौर पर एक्ज़ीक्यूट किए गए बिल्ड ऐक्शन पर खर्च करने के लिए, Bazel के लिए उपलब्ध लोकल सीपीयू कोर की कुल संख्या को साफ़ तौर पर सेट करें. एक पूर्णांक या "Host_CPUS" लेता है, वैकल्पिक रूप से उसके बाद [-|*]<float> (उदाहरण के लिए, उपलब्ध आधे कोर का इस्तेमाल करने के लिए Host_CPUS*.5). डिफ़ॉल्ट रूप से, ("Host_CPUS"), Bazel, उपलब्ध सीपीयू (CPU) कोर की संख्या का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
टैग: host_machine_resource_optimizations
--local_extra_resources=<a named float, 'name=value'> बार कई बार इस्तेमाल किया गया है: Bzel के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. स्ट्रिंग-फ़्लोट पेयर में लेता है. कई तरह के अतिरिक्त संसाधनों के बारे में बताने के लिए, कई बार इस्तेमाल किया जा सकता है. Bazel, एक साथ चलने वाली कार्रवाइयों को सीमित करेगा. ऐसा, उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर किया जाएगा. टेस्ट, "संसाधन:<resoucename>:<amount>" फ़ॉर्मैट के टैग का इस्तेमाल करके, अतिरिक्त संसाधनों की ज़रूरत का एलान कर सकते हैं. उपलब्ध सीपीयू, रैम, और संसाधन इस फ़्लैग के साथ सेट नहीं किए जा सकते.
टैग: host_machine_resource_optimizations
--local_ram_resources=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "Host_RAM*.67": BZel के लिए उपलब्ध लोकल होस्ट रैम (एमबी में) की कुल संख्या को साफ़ तौर पर सेट करें, ताकि बिल्ड ऐक्शन पर खर्च किया जा सके. एक पूर्णांक या "Host_RAM" लेता है, वैकल्पिक रूप से इसके बाद [-|*]<float> (उदाहरण के लिए, उपलब्ध आधी रैम का इस्तेमाल करने के लिए Host_RAM*.5). डिफ़ॉल्ट रूप से, ("Host_RAM*.67"), Bazel, उपलब्ध रैम की मात्रा का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और इसका 67% हिस्सा इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations
--local_resources=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> बार कई बार इस्तेमाल किया गया है: Bzel पर उपलब्ध संसाधनों की संख्या सेट करें. किसी फ़्लोट या Host_RAM/Host_CPUS के लिए असाइनमेंट लेता है. इसके बाद, वैकल्पिक रूप से [-|*]<फ़्लोट> (उदाहरण के लिए, उपलब्ध रैम में से आधे का इस्तेमाल करने के लिए मेमोरी=Host_RAM*.5) का इस्तेमाल करें. कई तरह के संसाधनों के बारे में बताने के लिए, इनका एक से ज़्यादा बार इस्तेमाल किया जा सकता है. Bazel, उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, एक साथ चलने वाली कार्रवाइयों को सीमित करेगा. टेस्ट, "संसाधन:<resource name>:<amount>" फ़ॉर्मैट वाले टैग का इस्तेमाल करके, यह बता सकते हैं कि उन्हें कितने संसाधनों की ज़रूरत है. --local_{cpu|ram|extra}_resources के तय किए गए संसाधनों को बदल देता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4": Bzel को एक तय सीमा तक, किसी बिल्ड इवेंट को दोबारा अपलोड करने की कोशिश करनी चाहिए.
टैग: bazel_internal_configuration
--[no]debug_spawn_scheduler डिफ़ॉल्ट: "गलत"
--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत": Targetखास इवेंट को पब्लिश करना है या नहीं.
--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत": अगर सही हो, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय BEP में फ़ाइलसेट बड़ा करें.
टैग: affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत": अगर सही हो, तो आउटपुट फ़ाइलों को प्रज़ेंट करते समय, बीईपी में मिलते-जुलते फ़ाइलसेट सिमलिंक को पूरी तरह ठीक करें. --प्रायोगिक_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s": बीईपी के अपलोड न हो पाने पर, शुरुआत में, एक्सपोनेन्शियल बैकऑफ़ के लिए कम से कम देरी. (exponent: 1.6)
टैग: bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: विवरण देखें: इसमें यह चुना जाता है कि बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को कैसे अपलोड किया जाए.
टैग: affects_outputs
--[no]experimental_collect_local_sandbox_action_metrics डिफ़ॉल्ट: "सही": अब काम नहीं करता.
टैग: execution
--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_docker_verbose डिफ़ॉल्ट: "गलत": चालू होने पर, Bazel, Docker सैंडबॉक्स की रणनीति के बारे में ज़्यादा शब्दों वाले मैसेज प्रिंट करेगा.
टैग: execution
--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "गलत": अगर पैरामीटर फ़ाइलों को मटीरियल के तौर पर बनाया जा रहा है, तो डिस्क पर सीधे लिखकर ऐसा करें.
टैग: execution
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: "": अगर यह खाली नहीं है, तो Starlark के डेटा स्टोर करने की सुविधा के सभी नियमों की समाधान की गई जानकारी के साथ Starlark की वैल्यू लिखें. यह वैल्यू, एक्ज़ीक्यूट किए गए सभी नियमों की होनी चाहिए.
टैग: affects_outputs
--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "गलत": रन बिल्ड इवेंट में कमांड-लाइन रेज़िड्यू को शामिल करना है या नहीं, जिसमें बचा हुआ पदार्थ शामिल हो सकता है. डिफ़ॉल्ट रूप से, बचा हुआ डेटा रन कमांड बिल्ड इवेंट में शामिल नहीं किया जाता है, जिसमें बचा हुआ पदार्थ शामिल हो सकता है.
टैग: affects_outputs
--experimental_skyfocus_dump_keys=<none, count or verbose> डिफ़ॉल्ट: "कोई नहीं": Sky फ़ोकस को डीबग करने के लिए. फ़ोकस की गई SkyKeys (रूट, लीफ़, फ़ोकस की गई डीप, फ़ोकस किए गए आरडेप) को हटाएं.
टैग: terminal_output
--[no]experimental_skyfocus_dump_post_gc_stats डिफ़ॉल्ट: "गलत": Sky फ़ोकस को डीबग करने के लिए. अगर इसे चालू किया जाता है, तो हीप के साइज़ को कम करने की रिपोर्ट करने के लिए फ़ोकस करने से पहले/बाद में, मैन्युअल जीसी को ट्रिगर करें. इससे स्काईफ़ोकस इंतज़ार का समय बढ़ जाएगा.
टैग: terminal_output
--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत": लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs
--explain=<a path> डिफ़ॉल्ट: विवरण देखें: इसकी वजह से बिल्ड सिस्टम, एक्ज़ीक्यूट किए गए हर चरण की जानकारी देता है. बताई गई लॉग फ़ाइल में ही इसकी जानकारी दी गई है.
टैग: affects_outputs
--[no]ignore_unsupported_sandboxing डिफ़ॉल्ट: "गलत": अगर इस सिस्टम पर सैंडबॉक्स तरीके से प्रोग्राम चलाने की सुविधा काम नहीं करती है, तो चेतावनी प्रिंट न करें.
टैग: terminal_output
--[no]legacy_important_outputs डिफ़ॉल्ट: "सही": TargetComplete इवेंट में, लेगसी key_ बैज फ़ील्ड के लेगसी जनरेट होने की प्रोसेस को रोकने के लिए.
टैग: affects_outputs
--[no]materialize_param_files डिफ़ॉल्ट: "गलत": रिमोट ऐक्शन एक्ज़ीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें सेव करता है. कार्रवाइयों को डीबग करते समय उपयोगी होता है. यह --subcommands और --verbose_failures" से ज़ाहिर होता है.
टैग: execution
--max_config_changes_to_show=<an integer> डिफ़ॉल्ट: "3": बिल्ड के विकल्पों में बदलाव की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदली गई विकल्प के नामों की दी गई संख्या तक दिखती है. अगर दी गई संख्या -1 है, तो सभी बदले गए विकल्प दिखाए जाएंगे.
टैग: terminal_output
--max_test_output_bytes=<an integer> डिफ़ॉल्ट: "-1": हर टेस्ट-लॉग का ज़्यादा से ज़्यादा साइज़ तय करता है, जो तब उत्सर्जित हो सकता है, जब --test_OUT '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> डिफ़ॉल्ट: "0": चल रही जॉब की रिपोर्ट के बीच इंतज़ार करने का समय. डिफ़ॉल्ट वैल्यू 0 होने का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट होगी. इसके बाद, 30 सेकंड के बाद रिपोर्ट को हर मिनट में एक बार रिपोर्ट किया जाएगा. --curses चालू होने पर, प्रोग्रेस की हर सेकंड रिपोर्ट की जाती है.
टैग: affects_outputs
--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "असफलता": यह चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज को कब प्रिंट करना है. मान्य वैल्यू का मतलब है `असफलता`, सिर्फ़ काम न करने पर प्रिंट करने के लिए, सिर्फ़ सफलता पर प्रिंट करने की `सफलता`, और हमेशा प्रिंट करने के लिए `सभी`.
टैग: terminal_output
--[no]sandbox_debug डिफ़ॉल्ट: "गलत": सैंडबॉक्सिंग सुविधा के लिए, डीबग करने की सुविधाएं चालू करता है. इसमें दो चीज़ें शामिल होती हैं: पहली, बिल्ड होने के बाद सैंडबॉक्स रूट कॉन्टेंट में कोई बदलाव नहीं किया जाता; और दूसरा, एक्ज़ीक्यूशन की प्रोसेस के बारे में डीबग करने की ज़्यादा जानकारी प्रिंट करता है. इससे Bazel या Starlark के नियमों के डेवलपर को, इनपुट फ़ाइलें मौजूद न होने वगैरह की वजह से डीबग होने में मदद मिल सकती है.
टैग: terminal_output
--show_result=<an integer> डिफ़ॉल्ट: "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> डिफ़ॉल्ट: "खास जानकारी": पसंदीदा आउटपुट मोड के बारे में बताता है. मान्य वैल्यू, सिर्फ़ टेस्ट स्टेटस की खास जानकारी के लिए 'खास जानकारी' होती हैं. फ़ेल हुए टेस्ट के लिए टेस्ट लॉग भी प्रिंट करने के लिए 'गड़बड़ियां', सभी जांच के लिए 'सभी' प्रिंट, और रीयल टाइम में सभी टेस्ट के लिए 'सभी' लॉग प्रिंट करने के लिए 'गड़बड़ी' होती है. इससे --test_strategy वैल्यू पर ध्यान दिए बिना, एक बार में एक बार टेस्ट किया जाएगा.
टैग: test_runner, terminal_output, execution
--test_summary=<short, terse, detailed, none or testcase> डिफ़ॉल्ट: "छोटा": टेस्ट की खास जानकारी का पसंदीदा फ़ॉर्मैट बताता है. मान्य वैल्यू, सिर्फ़ टेस्ट किए गए टेस्ट के बारे में जानकारी प्रिंट करने के लिए 'छोटा' होती हैं, सिर्फ़ असफल जांच के बारे में जानकारी प्रिंट करने के लिए 'शॉर्ट' होती हैं, फ़ेल हुए टेस्ट केस की पूरी जानकारी प्रिंट करने के लिए 'जानकारी', 'ज़्यादा जानकारी' होती है, टेस्ट केस रिज़ॉल्यूशन में जवाब प्रिंट करने के लिए 'टेस्टकेस', फ़ेल टेस्ट केस की पूरी जानकारी प्रिंट नहीं की जाती, और जवाब को मिटाने के लिए 'कोई नहीं' होता है.
टैग: terminal_output
--[no]verbose_explanations डिफ़ॉल्ट: "गलत": अगर --एक्सप्लेनेशंस चालू है, तो यह जारी किए गए एक्सप्लेनेशंस को ज़्यादा शब्दों में दिखाता है. अगर --एक्सप्लेनेशंस चालू नहीं है, तो इसका कोई असर नहीं होगा.
टैग: affects_outputs
--[no]verbose_failures डिफ़ॉल्ट: "गलत": अगर कोई निर्देश काम नहीं करता, तो पूरी कमांड लाइन प्रिंट कर लें.
टैग: 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> डिफ़ॉल्ट: "": अगर फ़ाइल खाली नहीं है, तो वर्कस्पेस फ़ाइल के बजाय समाधान की गई फ़ाइल को पढ़ें
टैग: changes_inputs
--target_pattern_file=<a string> डिफ़ॉल्ट: "": अगर सेट किया जाता है, तो बिल्ड कमांड लाइन के बजाय, यहां दी गई फ़ाइल के पैटर्न को पढ़ेगा. यहां फ़ाइल और कमांड लाइन पैटर्न के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: विवरण देखें: सर्किट ब्रेकर के इस्तेमाल के लिए रणनीति के बारे में बताता है. उपलब्ध रणनीतियां "असफलता" हैं. विकल्प के लिए अमान्य मान पर विकल्प के जैसा व्यवहार सेट नहीं किया गया है.
टैग: execution
--experimental_downloader_config=<a string> डिफ़ॉल्ट: विवरण देखें: रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में लाइनें होती हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है. इसके बाद, होस्ट नाम (`अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक पैटर्न, मैच कराने के लिए और एक विकल्प यूआरएल के तौर पर इस्तेमाल किया जाता है. इसमें, पीछे की ओर का रेफ़रंस `$1` से शुरू होता है. इस मामले में, एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश दिए जा सकते हैं, और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत": रिमोट कैश मेमोरी पर अपलोड करने से पहले, किसी कार्रवाई की इनपुट फ़ाइलों के समय की जांच करने की सुविधा बंद करने के लिए, इस सेटिंग को बंद करें. कुछ मामलों में, Linux kernel की वजह से फ़ाइलें लिखने में देरी हो सकती है. इसकी वजह से गलत नतीजे मिल सकते हैं.
--[no]experimental_remote_cache_async डिफ़ॉल्ट: "गलत": अगर सही है, तो रिमोट कैश I/O, स्पॉन के हिस्से के बजाय बैकग्राउंड में होगा.
--experimental_remote_cache_compression_threshold=<an integer> डिफ़ॉल्ट: "0": zstd को कंप्रेस/डिकंप्रेस करने के लिए, ब्लॉब का कम से कम साइज़ होना ज़रूरी है. अगर --remote_cache_compression सेट नहीं है, तो यह लागू नहीं होगा.
--experimental_remote_cache_eviction_retries=<an integer> डिफ़ॉल्ट: "0": अगर बिल्ड में रिमोट कैश मेमोरी को हटाने में गड़बड़ी हुई है, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. एक गैर-शून्य मान अनुमान तौर पर --insupported_remote_use_new_exit_code_for_lost_inputs को सही पर सेट कर दिया जाएगा. हर बार कोशिश करने के लिए, शुरू करने का एक नया आईडी जनरेट किया जाएगा. अगर आपने शुरू करने वाला आईडी जनरेट किया है और उसे --invoct_id के साथ Bazel को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, फ़्लैग --insupported_remote_use_new_exit_code_for_lost_inputs को सेट करें और एग्ज़िट कोड 39 की जांच करें.
टैग: execution
--[no]experimental_remote_cache_lease_extension डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो Bazel बिल्ड के दौरान रिमोट ऐक्शन के आउटपुट के लिए लीज़ पर ले लेगा. इसके लिए, वह समय-समय पर रिमोट कैश मेमोरी में `FindFindBlobs` कॉल भेजेगा. यह फ़्रीक्वेंसी, `--experimental_remote_cache_ttl` की वैल्यू पर आधारित है.
--experimental_remote_cache_ttl=<An immutable length of time.> डिफ़ॉल्ट: "3 घंटे": हाल ही में, डाइजेस्ट के बाद रिमोट कैश में मौजूद ब्लॉब के कम से कम TTL (टीटीएल) का रेफ़रंस दिया गया है. उदाहरण के लिए, एक Actionresults या Find भरोसाBlobs से. Bazel, blobs के TTL के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, किसी इंक्रीमेंटल बिल्ड में बार-बार GetActionनतीजे को कॉल नहीं करता. वैल्यू को असल TTL से थोड़ा कम सेट किया जाना चाहिए. ऐसा इसलिए, क्योंकि सर्वर के डाइजेस्ट लौटाने और बैजल को उन्हें पाने के समय में एक अंतर होता है.
टैग: execution
--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: विवरण देखें: किसी डायरेक्ट्री का पाथ जहां खराब आउटपुट कैप्चर किए जाएंगे.
--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो GetActionresults() और Execute() को किए जाने वाले कॉल के दौरान इनपुट रूट के मर्कल ट्री की इन-मेमोरी कॉपी और उससे जुड़ी इनपुट मैपिंग को खारिज करें. इससे मेमोरी का इस्तेमाल बहुत कम हो जाता है, लेकिन रिमोट कैश के छूट जाने या फिर से कोशिश करने पर Bazel को फिर से गिनती करनी पड़ती है.
--experimental_remote_downloader=<a string> डिफ़ॉल्ट: विवरण देखें: रिमोट एसेट एपीआई एंडपॉइंट यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जाता है. इसके साथ काम करने वाले स्कीमा हैं grpc, grpcs (TLS चालू किए गए जीआरपीसी) और 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 डिफ़ॉल्ट: "गलत": अगर रिमोट डाउनलोडर काम नहीं करता है, तो लोकल डाउनलोडर पर वापस जाएं या नहीं.
--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "गलत": रिमोट एक्ज़ीक्यूशन कॉल के लिए कीपअलाइव की सुविधा का इस्तेमाल करना है या नहीं.
--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.> डिफ़ॉल्ट: "60 सेकंड": वह अंतराल जिसमें रिमोट अनुरोधों के पूरे न हो पाने की दर का हिसाब लगाया जाता है. शून्य या ऋणात्मक मान पर विफल होने की अवधि का आकलन निष्पादन की पूरी अवधि की गणना करता है.निम्न इकाइयों का उपयोग किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s) और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution
--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो Bazel रिमोट एक्ज़ीक्यूटर के लिए, इनपुट को टूल इनपुट के तौर पर मार्क कर देगा. इसका इस्तेमाल, रिमोट परसिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो मर्कल ट्री के कैलकुलेशन को याद किया जाएगा. इससे रिमोट कैश हिट की जांच करने की स्पीड को बेहतर बनाने में मदद मिलेगी. कैश मेमोरी के मेमोरी फ़ुट प्रिंट को --experimental_remote_mercle_tree_cache_size से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000": रिमोट कैश हिट चेक करने की स्पीड को बेहतर बनाने के लिए, याद किए जाने वाले मर्कल ट्री की संख्या. हालांकि, Java की ओर से सॉफ़्ट रेफ़रंस को हैंडल करने के हिसाब से कैश मेमोरी में फ़ाइलें अपने-आप कम हो जाती हैं, लेकिन बहुत ज़्यादा वैल्यू पर सेट करने पर, मेमोरी से बाहर की गड़बड़ियां हो सकती हैं. अगर यह वैल्यू 0 पर सेट है, तो कैश मेमोरी का साइज़ अनलिमिटेड नहीं होता है. सबसे सही वैल्यू, प्रोजेक्ट के साइज़ के हिसाब से अलग-अलग होती है. डिफ़ॉल्ट संख्या 1000 पर सेट होती है.
--experimental_remote_output_service=<a string> डिफ़ॉल्ट: विवरण देखें: होस्ट या Host:किसी रिमोट आउटपुट सर्विस एंडपॉइंट का पोर्ट. इसके साथ काम करने वाले स्कीमा हैं grpc, grpcs (TLS चालू किए गए जीआरपीसी) और Unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
--experimental_remote_output_service_output_path_prefix=<a string> डिफ़ॉल्ट: "": वह पाथ जिसके तहत --experimental_remote_आउटपुट_service की मदद से मैनेज की जाने वाली आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. बिल्ड के लिए इस्तेमाल की जाने वाली असल आउटपुट डायरेक्ट्री, इस पाथ की डिसेंडेंट होगी और उसे आउटपुट सेवा तय करेगी.
--[no]experimental_remote_require_cached डिफ़ॉल्ट: "गलत": अगर नीति को 'सही है' पर सेट किया जाता है, तो लागू करें कि रिमोट तरीके से चलाए जा सकने वाली सभी कार्रवाइयां, कैश मेमोरी में सेव हो जाती हैं या वे बिल्ड को फ़ेल कर देती हैं. इससे ऐसी समस्याओं को हल करने में मदद मिलती है जो तय नहीं हैं. इससे, यह जांच करने में मदद मिलती है कि कैश मेमोरी में सेव की जाने वाली कार्रवाइयों को असल में कैश मेमोरी में सेव किया गया है या नहीं. ऐसा, कैश में नए नतीजे डाले बिना किया जाता है.
--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: विवरण देखें: सप्लाई की गई कॉन्फ़िगरेशन फ़ाइल के साथ, रिमोट कैश कुंजी को स्क्रब करने की सुविधा चालू करती है. यह कॉन्फ़िगरेशन फ़ाइल, टेक्स्ट फ़ॉर्मैट में प्रोटोकॉल बफ़र होनी चाहिए. (src/main/protobuf/remote_scrbbing.proto देखें). इस सुविधा का मकसद, एक ही प्लैटफ़ॉर्म को टारगेट करने वाले, अलग-अलग प्लैटफ़ॉर्म पर की जाने वाली कार्रवाइयों के बीच, रिमोट/डिस्क कैश मेमोरी को शेयर करना है. इसका इस्तेमाल बहुत सावधानी से करना चाहिए, क्योंकि गलत सेटिंग की वजह से गलती से कैश एंट्री शेयर हो सकती है. साथ ही, इसकी वजह से गलत बिल्ड हो सकते हैं. स्क्रबिंग से, कार्रवाई करने के तरीके पर कोई असर नहीं पड़ता. सिर्फ़ कार्रवाई के नतीजे को वापस पाने या सेव करने के लिए, रिमोट/डिस्क की कैश मेमोरी कुंजी को कैलकुलेट करने के तरीके पर कोई असर नहीं पड़ता. स्क्रब की गई कार्रवाइयां, रिमोट तरीके से एक्ज़ीक्यूशन के साथ काम नहीं करतीं. साथ ही, इन्हें हमेशा स्थानीय तौर पर एक्ज़ीक्यूट किया जाएगा. स्क्रबिंग कॉन्फ़िगरेशन में बदलाव करने से, लोकल फ़ाइल सिस्टम या इंटरनल कैश मेमोरी में मौजूद आउटपुट अमान्य नहीं होते. जिन कार्रवाइयों पर असर हुआ है उन्हें फिर से लागू करने के लिए, क्लीन बिल्ड ज़रूरी है. इस सुविधा का सही तरीके से इस्तेमाल करने के लिए, हो सकता है कि आप --experimental_platform_in_internal_direct (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --insupported_strict_action_env (एनवायरमेंट वैरिएबल को सामान्य बनाने के लिए) के साथ, कस्टम --host_platform साथ सेट करना चाहें.
--experimental_worker_for_repo_fetching=<off, platform, virtual or auto> डिफ़ॉल्ट: "ऑटो": रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर इसे 'बंद है' पर सेट किया जाता है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेच करने की प्रोसेस रीस्टार्ट भी हो सकती है. इसके अलावा, अगर 'प्लैटफ़ॉर्म' पर सेट किया गया है, तो प्लैटफ़ॉर्म थ्रेड (जैसे कि ओएस थ्रेड) का इस्तेमाल किया जाता है या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल किया जाता है. अगर वर्चुअल थ्रेड को 'ऑटो' पर सेट किया जाता है, तो उपलब्ध होने पर वर्चुअल थ्रेड का इस्तेमाल किया जाएगा यानी JDK 21+ पर चल रहा है. ऐसा नहीं होने पर, किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता.
--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "गलत": अब काम नहीं करता. नहीं. इसके बजाय --remote_build_event_upload=minimal का इस्तेमाल करें.
--[no]incompatible_remote_downloader_send_all_headers डिफ़ॉल्ट: "सही": कई वैल्यू वाले हेडर की सभी वैल्यू को पहले रिमोट डाउनलोडर के बजाय रिमोट डाउनलोडर को भेजा जाए या नहीं.
टैग: incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट से जुड़े होते हैं.
टैग: incompatible_change
--[no]incompatible_remote_results_ignore_disk डिफ़ॉल्ट: "सही": No-op
टैग: incompatible_change
--[no]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो बिल्ड के दौरान रिमोट कैश मेमोरी ब्लॉब को हटा देती है. ऐसे में, Bazel, 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगा.
टैग: incompatible_change
--[no]remote_accept_cached डिफ़ॉल्ट: "सही": कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को रिमोट तरीके से स्वीकार किया जाए या नहीं.
--remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "कम से कम": अगर यह वैल्यू 'सभी' पर सेट है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड कर दिए जाते हैं. अगर इस नीति को 'मिनिमल' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. हालांकि, वे फ़ाइलें जो BEP के उपभोक्ताओं के लिए ज़रूरी होती हैं (जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल). बाइटstream:// स्कीम का इस्तेमाल, फ़ाइलों के यूआरआई के लिए हमेशा किया जाता है, भले ही वे रिमोट कैश में मौजूद न हों. डिफ़ॉल्ट रूप से 'कम से कम' सेट करें.
--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: विवरण देखें: बाइटstream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम, जिसे बिल्ड इवेंट स्ट्रीम में लिखा जाता है. इस विकल्प को तब सेट किया जा सकता है, जब बिल्ड प्रॉक्सी का इस्तेमाल करके किया जाता है. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती है. अगर इस नीति को सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.
--remote_cache=<a string> डिफ़ॉल्ट: विवरण देखें: कैश मेमोरी में सेव किए जाने वाले एंडपॉइंट का यूआरआई. इस तरह के स्कीमा के साथ काम करने वाले एचटीटीपी, https, grpc, grpcs (TLS चालू किए गए grpc) और Unix (लोकल UNIX सॉकेट) हैं. अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा के बारे में बताएं. https://bazel.build/remote/ca कार्रवाई पर जाएं
--[no]remote_cache_compression डिफ़ॉल्ट: "गलत": अगर यह सेटिंग चालू है, तो कैश ब्लॉब को zstd के साथ कंप्रेस/डिकंप्रेस करें. ऐसा तब करें, जब इसका साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.
--remote_cache_header=<a 'name=value' assignment> बार कई बार इस्तेमाल किया गया है: ऐसा हेडर तय करें जिसे कैश मेमोरी के अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके कई हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_default_exec_properties=<a 'name=value' assignment> बार कई बार इस्तेमाल किया गया है: अगर कोई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो डिफ़ॉल्ट exec प्रॉपर्टी को रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए सेट करें.
टैग: affects_outputs
--remote_default_platform_properties=<a string> डिफ़ॉल्ट: "": अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से Remote_execution_property सेट नहीं करता है, तो रिमोट एक्ज़ीक्यूशन एपीआई के लिए डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब होस्ट प्लैटफ़ॉर्म को रिमोट तरीके से एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना गया हो.
--remote_download_regex=<a valid Java regular expression> बार कई बार इस्तेमाल किया गया है: रिमोट बिल्ड आउटपुट को हर हाल में डाउनलोड करें, जिनका पाथ इस पैटर्न से मिलता-जुलता हो. भले ही, यह टूल --remote_download_returns से मेल खाता हो. इस फ़्लैग को दोहराकर कई पैटर्न तय किए जा सकते हैं.
टैग: 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> डिफ़ॉल्ट: "0": रिमोट तरीके से की जाने वाली कार्रवाइयों की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर होते हैं.
--remote_executor=<a string> डिफ़ॉल्ट: विवरण देखें: होस्ट या Host:किसी रिमोट एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट. इसके साथ काम करने वाले स्कीमा हैं grpc, grpcs (TLS चालू किए गए जीआरपीसी) और Unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
--remote_grpc_log=<a path> डिफ़ॉल्ट: विवरण देखें: अगर बताया गया हो, तो gRPC कॉल से जुड़ी जानकारी लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में, क्रम के हिसाब से बनाई गई com.google.devtools.build.lib.remote.logging.Remote नज़ारेLog.LogEntry Protobufs पर मौजूद हर मैसेज के साथ, क्रम से दिए गए प्रोटोबफ़ मैसेज के साइज़ की जानकारी मिलती है. यह सीरियल नंबर, क्रम के हिसाब से दिए गए प्रोटोबफ़ मैसेज के साइज़ को दिखाता है, जैसा कि Logtry.writeDelimitedTo(OutStream) है.
--remote_header=<a 'name=value' assignment> बार कई बार इस्तेमाल किया गया है: वह हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके कई हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.
--remote_instance_name=<a string> डिफ़ॉल्ट: "": रिमोट एक्ज़ीक्यूशन एपीआई में, example_name के तौर पर पास करने की वैल्यू.
--[no]remote_local_fallback डिफ़ॉल्ट: "गलत": अगर रिमोट तौर पर एक्ज़ीक्यूशन काम नहीं कर पाता है, तो क्या उसके लिए स्टैंडअलोन लोकल ऐक्शन रणनीति का इस्तेमाल करना चाहिए.
--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "स्थानीय": नहीं, यह सुविधा अब काम नहीं करती. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 देखें.
--remote_max_connections=<an integer> डिफ़ॉल्ट: "100": एक साथ ज़्यादा से ज़्यादा कनेक्शन की संख्या को रिमोट कैश/एक्ज़ीक्यूटर तक सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है, इसलिए Bazel --remote_max_CONNECTIONs एक साथ अनुरोध कर सकता है. जीआरपीसी रिमोट कैश/एक्ज़ीक्यूटर के लिए, एक जीआरपीसी चैनल आम तौर पर एक साथ 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> डिफ़ॉल्ट: "0": रिमोट कैश मेमोरी में सेव की जाने वाली रिमोट ऐक्शन की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर होते हैं.
--remote_retries=<an integer> डिफ़ॉल्ट: "5": थोड़ी देर के लिए हुई किसी गड़बड़ी को फिर से ठीक करने की कोशिशों की ज़्यादा से ज़्यादा संख्या. अगर यह 0 पर सेट है, तो बार-बार कोशिश करने की सुविधा बंद हो जाएगी.
--remote_retry_max_delay=<An immutable length of time.> डिफ़ॉल्ट: "5s": रिमोट से दोबारा कोशिश करने के बीच, बैकऑफ़ में लगने वाला ज़्यादा से ज़्यादा समय. नीचे दी गई इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
--remote_timeout=<An immutable length of time.> डिफ़ॉल्ट: "60 सेकंड": रिमोट एक्ज़ीक्यूशन और कैश कॉल तक इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश के लिए, यह कनेक्ट करने और पढ़ने का टाइम आउट, दोनों है. नीचे दी गई इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
--[no]remote_upload_local_results डिफ़ॉल्ट: "सही": अगर रिमोट कैश मेमोरी के साथ काम करता है और उपयोगकर्ता के पास इसकी अनुमति है, तो स्थानीय तौर पर बनाई गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड किया जाए या नहीं.
--[no]remote_verify_downloads डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो Bazel सभी रिमोट डाउनलोड के हैश योग का हिसाब लगाएगा. साथ ही, अगर रिमोट तरीके से कैश मेमोरी में सेव की गई वैल्यू उम्मीद के मुताबिक नहीं होती है, तो उसे खारिज कर दिया जाएगा.

--[no]allow_analysis_cache_discard डिफ़ॉल्ट: "सही": अगर बिल्ड सिस्टम में बदलाव की वजह से, विश्लेषण की कैश मेमोरी को खारिज किया जा रहा है, तो इस विकल्प को 'गलत है' पर सेट करने से, बैजल प्रोसेस जारी रखने के बजाय बाहर निकल जाएगा. 'discard_analysis_cache' के भी सेट होने पर, इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit
--auto_output_filter=<none, all, packages or subpackages> डिफ़ॉल्ट: "कोई नहीं": अगर -- callout_filter की जानकारी नहीं दी गई है, तो इस विकल्प की वैल्यू का इस्तेमाल करके, अपने-आप फ़िल्टर बनाएं. अनुमति वाली वैल्यू 'कोई नहीं' (कुछ नहीं फ़िल्टर करें / सब कुछ दिखाएं), 'सभी' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'पैकेज' (ब्लेज़ कमांड लाइन में बताए गए पैकेज के नियमों से आउटपुट शामिल करें), और 'सबपैकेज' (जैसे 'पैकेज', लेकिन सबपैकेज शामिल करें) हैं. 'packages' और 'subpackages' मानों के लिए //java/foo और //javatests/foo को एक पैकेज माना जाता है)'.
--[no]build_manual_tests डिफ़ॉल्ट: "गलत": इस नीति की मदद से, 'मैन्युअल' टैग किए गए टेस्ट टारगेट को हर हाल में बनाया जाता है. 'मैन्युअल' टेस्ट को प्रोसेस नहीं किया जाता. यह विकल्प उन्हें बनाने के लिए बाध्य करता है (लेकिन एक्ज़ीक्यूट नहीं करता).
--build_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: "": टैग की कॉमा-सेपरेटेड लिस्ट के बारे में बताता है. बाहर रखे गए टैग के बारे में बताने के लिए, हर टैग के शुरू में वैकल्पिक तौर पर '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे टारगेट बनाए जाएंगे जिनमें कम से कम एक टैग शामिल हो और उनमें बाहर रखा गया कोई टैग न हो. यह विकल्प 'टेस्ट' कमांड से लागू किए गए टेस्ट के सेट पर असर नहीं डालता. ये टेस्ट फ़िल्टर करने के विकल्पों से नियंत्रित होते हैं, जैसे कि '--test_tag_filters'
--[no]build_tests_only डिफ़ॉल्ट: "गलत": अगर निर्देश दिए गए हैं, तो सिर्फ़ *_test और test_suite के नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर दिए गए दूसरे टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई हर चीज़ बनाई जाएगी.
--combined_report=<none or lcov> डिफ़ॉल्ट: "कोई नहीं": इससे, कुल कवरेज की मनचाही रिपोर्ट के बारे में पता चलता है. फ़िलहाल, सिर्फ़ एलसीओवी का इस्तेमाल किया जा सकता है.
--[no]compile_one_dependency डिफ़ॉल्ट: "गलत": आर्ग्यूमेंट फ़ाइलों की एक डिपेंडेंसी कंपाइल करें. यह IDE में सोर्स फ़ाइलों की सिंटैक्स की जांच करने के लिए फ़ायदेमंद है. उदाहरण के लिए, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर किसी सिंगल टारगेट को फिर से बनाया जा सकता है. यह तर्क, बिना फ़्लैग वाले सभी तर्कों की व्याख्या करने के तरीके पर असर डालता है. उन्हें टारगेट करने के बजाय, वे सोर्स फ़ाइल नाम हैं. हर सोर्स फ़ाइल के नाम के लिए, एक आर्बिट्रेरी टारगेट बनाया जाएगा. यह उस पर निर्भर करेगा.
--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 डिफ़ॉल्ट: "गलत": विश्लेषण के चरण पूरे होने के तुरंत बाद, विश्लेषण की कैश मेमोरी मिटा दें. इससे मेमोरी के इस्तेमाल को ~10% तक कम कर दिया जाता है. हालांकि, अगर बिल्ड धीरे-धीरे बढ़ रहा है, तो हो जाता है.
--disk_cache=<a path> डिफ़ॉल्ट: विवरण देखें: किसी ऐसी डायरेक्ट्री का पाथ जहां Bazel, ऐक्शन और आउटपुट के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बना दिया जाएगा.
--embed_label=<a one-line string> डिफ़ॉल्ट: "": सोर्स कंट्रोल में हुए बदलाव या रिलीज़ लेबल को बाइनरी में जोड़ें
--execution_log_binary_file=<a path> डिफ़ॉल्ट: विवरण देखें: इस फ़ाइल में, एक्ज़ीक्यूट किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, लंबाई-डीलिमिटेड Spwnexe Protos के तौर पर लॉग करें. मिलते-जुलते फ़्लैग: --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_sort (क्या एक्ज़ीक्यूशन लॉग को क्रम से लगाना है), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--execution_log_json_file=<a path> डिफ़ॉल्ट: विवरण देखें: इस फ़ाइल में, एक्ज़ीक्यूट किए गए स्पॉन्स को src/main/protobuf/spawn.proto के मुताबिक, Spwn स्क्रिप्ट प्रोटोस के न्यूलाइन-डीलिमिटेड JSON रिप्रज़ेंटेशन के तौर पर लॉग करें. मिलते-जुलते फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_sort (क्या एक्ज़ीक्यूशन लॉग को क्रम से लगाना है), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--[no]execution_log_sort डिफ़ॉल्ट: "सही": एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं, जिससे उन लॉग की तुलना करना आसान हो जाता है जिन्हें शुरू किया जाता है. शुरू करने की प्रोसेस के आखिर में, सीपीयू और मेमोरी के अहम इस्तेमाल से बचने के लिए, 'गलत' पर सेट करें. ऐसा करने के लिए, नॉन-डिटर्मिनिस्टिक एक्ज़ीक्यूशन ऑर्डर में लॉग इन करें. सिर्फ़ बाइनरी और JSON फ़ॉर्मैट पर लागू होता है. कॉम्पैक्ट फ़ॉर्मैट को कभी भी क्रम से नहीं लगाया जाता.
--[no]expand_test_suites डिफ़ॉल्ट: "सही": विश्लेषण से पहले, test_Suite टारगेट को उनके कॉम्पोनेंट के टेस्ट में शामिल कर लिया जाए. डिफ़ॉल्ट रूप से यह फ़्लैग चालू होने पर, टेस्ट सुइट से जुड़े टेस्ट पर नेगेटिव टारगेट पैटर्न लागू नहीं होंगे. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड लाइन पर टॉप-लेवल के पहलू लागू किए जाते हैं: इसके बाद, वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis
--experimental_execution_log_compact_file=<a path> डिफ़ॉल्ट: विवरण देखें: इस फ़ाइल में, एक्ज़ीक्यूट किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, लंबाई से अलग किए गए exeLogEntry Protos के तौर पर लॉग करें. पूरी फ़ाइल zstd कंप्रेस की गई है. इस फ़ॉर्मैट पर अभी प्रयोग किया जा रहा है और इस पर अभी काम चल रहा है. इसे किसी भी समय बदला जा सकता है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "": अब अलग-अलग पहलुओं के पक्ष में नहीं, बल्कि उनके सुझाव दिए गए हैं. एक्सटर्नल ऐक्शन को शेड्यूल करने के लिए टारगेट के सेट को फ़िल्टर करता है.
--[no]experimental_extra_action_top_level_only डिफ़ॉल्ट: "गलत": अब अलग-अलग पहलुओं के पक्ष में नहीं, बल्कि उनके सुझाव दिए गए हैं. सिर्फ़ टॉप लेवल के टारगेट के लिए, extra_actions को शेड्यूल करता है.
--experimental_spawn_scheduler: स्थानीय और कहीं से भी एक साथ कार्रवाइयां करके, डाइनैमिक एक्ज़ीक्यूशन चालू करें. Bazel हर गेम को अलग-अलग जगहों पर भी शुरू करता है और सबसे पहले पूरा होने वाला गेम चुनता है. अगर कोई कार्रवाई, वर्कर के साथ काम करती है, तो लोकल ऐक्शन, स्थायी वर्कर मोड में चलेगा. इसके बजाय, किसी कार्रवाई को डाइनैमिक तौर पर एक्ज़ीक्यूट करने के लिए, `--internal_spawn_Scheduler` और `--strategy=<mnemonic>=Dynamic` फ़्लैग का इस्तेमाल करें.
यह इस तरह बड़ा होता है:
--internal_spawn_scheduler
--spawn_strategy=dynamic
--[no]fetch डिफ़ॉल्ट: "सही": निर्देश को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति देता है. अगर 'गलत है' पर सेट किया जाता है, तो यह निर्देश, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. कोई निर्देश मौजूद न होने पर, निर्देश काम नहीं करेगा.
--[no]incompatible_dont_use_javasourceinfoprovider डिफ़ॉल्ट: "गलत": No-op
टैग: incompatible_change
--local_termination_grace_seconds=<an integer> डिफ़ॉल्ट: "15": टाइम आउट की वजह से लोकल प्रोसेस को बंद करने और उसे तेज़ी से बंद करने के बीच इंतज़ार करने का समय.
--override_repository=<an equals-separated mapping of repository name to path> बार कई बार इस्तेमाल किया गया है: डेटा स्टोर करने की जगह को लोकल पाथ से बदलकर, <repository name>=<path> के तौर पर सेट करें. अगर दिया गया पाथ एक ऐब्सलूट पाथ है, तो इसका इस्तेमाल उसी तरह किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री से मिलती-जुलती है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट के सापेक्ष है, जो `bazel इंफ़ो वर्कस्पेस` का आउटपुट है
--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%": पैकेज खोजने की जगह के बारे में कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, बंद फ़ाइल फ़ोल्डर से मिलते-जुलते हैं. अगर इसे खाली छोड़ा जाता है या खाली किया जाता है, तो डिफ़ॉल्ट तौर पर 'bazel info default-package-path' का आउटपुट डिफ़ॉल्ट तौर पर दिखता है.
--[no]show_loading_progress डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो Bazel "Loadingpackage:" मैसेज प्रिंट करेगा.
--test_lang_filters=<comma-separated list of options> डिफ़ॉल्ट: "": जांच के लिए इस्तेमाल की जाने वाली भाषाओं की ऐसी सूची होती है जिसे कॉमा लगाकर अलग किया जाता है. बाहर रखी गई भाषाओं के बारे में बताने के लिए, हर भाषा के पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे जांच टारगेट दिखेंगे जो खास भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया जाने वाला नाम, *_test नियम में मौजूद भाषा के शुरुआती नाम से मेल खाना चाहिए. जैसे, 'cc', 'java', 'py' वगैरह में से कोई एक. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_size_filters=<comma-separated list of values: small, medium, large or enormous> डिफ़ॉल्ट: "": टेस्ट साइज़ की कॉमा-सेपरेटेड लिस्ट के बारे में बताता है. शामिल न किए गए साइज़ के बारे में बताने के लिए, हर साइज़ के पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक साइज़ शामिल होगा और उनमें कोई बाहर रखा गया साइज़ नहीं होगा. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: "": टेस्ट टैग की ऐसी सूची के बारे में बताता है जिसे कॉमा लगाकर अलग किया गया है. बाहर रखे गए टैग के बारे में बताने के लिए, हर टैग के शुरू में वैकल्पिक तौर पर '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक टैग शामिल होगा और जिनमें बाहर रखा गया कोई भी टैग मौजूद नहीं होगा. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: "": यह नीति, जांच के टाइम आउट की ऐसी सूची के बारे में बताती है जिसे कॉमा लगाकर अलग किया गया है. बाहर रखे गए टाइम आउट के बारे में बताने के लिए, हर टाइम आउट से पहले वैकल्पिक रूप से '-' लगाया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक टाइम आउट शामिल है और जिनमें बाहर रखा गया कोई भी टाइम आउट नहीं है. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--workspace_status_command=<path> डिफ़ॉल्ट: "": की/वैल्यू पेयर के तौर पर फ़ाइल फ़ोल्डर के स्टेटस की जानकारी देने के लिए, बिल्ड की शुरुआत में शुरू किया गया एक निर्देश. पूरी जानकारी के लिए उपयोगकर्ता मैन्युअल देखें. उदाहरण के लिए, Tools/buildstamp/get_workspace_status भी देखें.

--[no]check_up_to_date डिफ़ॉल्ट: "गलत": बिल न बनाएं, बस देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड पूरा हो जाता है. अगर किसी चरण को पूरा करने की ज़रूरत होती है, तो गड़बड़ी की शिकायत की जाती है और बिल्ड काम नहीं करता.
टैग: execution
--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "गलत": सिमलिंक ट्री बनाने के लिए, डायरेक्ट फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "गलत": कर्मचारियों की मदद से, परसिस्टेंट Aar एक्सट्रैक्टर चालू करें.
टैग: execution
--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "गलत": सोर्स मेनिफ़ेस्ट कार्रवाइयों को फिर से चालू करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "गलत": अगर सही है, तो Bazel एक नए स्पॉन में टेस्ट के लिए, कवरेज पोस्टप्रोसेसिंग करेगा.
टैग: execution
--[no]experimental_split_xml_generation डिफ़ॉल्ट: "सही": अगर यह फ़्लैग सेट है और टेस्ट ऐक्शन से test.xml फ़ाइल जनरेट नहीं होती है, तो Bazel एक अलग कार्रवाई का इस्तेमाल करके, टेस्ट लॉग वाली डमी test.xml फ़ाइल जनरेट करेगा. ऐसा न होने पर, Bazel, टेस्ट के तौर पर test.xml जनरेट करता है.
टैग: execution
--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री को ट्रैवर्स नहीं करेंगे या सिमलिंक के प्रति संवेदनशील नहीं होंगे.
टैग: execution
--[no]experimental_use_semaphore_for_jobs डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो एक साथ किए जाने वाले जॉब की संख्या को सीमित करने के लिए, सेमैपोर का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution
--genrule_strategy=<comma-separated list of options> डिफ़ॉल्ट: "": जननियम लागू करने का तरीका बताएं. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> का इस्तेमाल करें या सिर्फ़ जनरेट को कंट्रोल करने के लिए --strategy=Gen rules=<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] डिफ़ॉल्ट: "ऑटो": चलने के लिए एक साथ किए जाने वाले जॉब की संख्या. कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<फ़्लोट>) करें, उदाहरण के लिए. "auto", "Host_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. वैल्यू 2,500 से ज़्यादा होने पर, मेमोरी से जुड़ी समस्याएं हो सकती हैं. "अपने-आप", होस्ट के संसाधनों के आधार पर सही डिफ़ॉल्ट वैल्यू को कैलकुलेट करता है.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": लोडिंग/विश्लेषण फ़ेज़ में इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. उदाहरण के लिए. "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> डिफ़ॉल्ट: "": गतिविधियों की जानकारी के आधार पर, उस कार्रवाई के काम करने के तरीके की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो स्क्रिप्ट को चलाने की जानकारी देती हैं. कई सामान्य कार्रवाइयां, एक्ज़ीक्यूशन की जानकारी के साथ काम करती हैं, जैसे कि Genroll, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, ऑर्डर अहम हो जाता है, क्योंकि एक ही मिनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' जोड़ता है और 'y' से हटा देता है. जेनरूल की सभी कार्रवाइयों के लिए, 'Genroll=+requires-x' को लागू करने की जानकारी में 'requires-x' जोड़ता है. '(?!GenTerms).*=-requires-x', सभी गैर-सामान्य कार्रवाइयों के लिए, निष्पादन जानकारी से '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=workerhost_machine_resource_optimizationsexecution
--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{/2/}

--modify_execution_info=AARGenerator=+supports-multiplex-workershost_machine_resource_optimizationsexecution
--persistent_multiplex_android_tools: परसिस्टेंट और मल्टीप्लेक्स किए गए Android टूल (डेक्सिंग, डिस्यूगरिंग, रिसॉर्स प्रोसेसिंग) चालू करें.
इसमें शामिल है:
  --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 डिफ़ॉल्ट: "गलत": कमांड लाइन में साफ़ तौर पर सूची में शामिल काम न करने वाले टारगेट को छोड़ें. डिफ़ॉल्ट रूप से, ऐसे टारगेट बनाने में गड़बड़ी होती है. हालांकि, यह विकल्प चालू होने पर उन्हें बिना किसी रुकावट के स्किप कर दिया जाता है. देखें: https://bazel.build/extending/platforms#ski चुनाव-insupported-targets
टैग: loading_and_analysis
--spawn_strategy=<comma-separated list of options> डिफ़ॉल्ट: "": यह तय करें कि डिफ़ॉल्ट तौर पर, Spwn की कार्रवाइयां कैसे होती हैं. यह सबसे ऊंची से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार करता है. हर कार्रवाई के लिए 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 (और --genनियम_strategy) से सेट की गई वैल्यू को बदल देता है, अगर इसे mnemonic Genroll के साथ इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution
--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> बार कई बार इस्तेमाल किया गया है: यह तय करें कि जिन स्पॉन ऐक्शन को लागू करने के लिए, कौनसी स्पॉन्सर रणनीति इस्तेमाल की जानी चाहिए उनमें कुछ रेगुलर एक्सप्रेशन_फ़िल्टर से मैच करने वाली जानकारी शामिल हो. रेगुलर एक्सप्रेशन फ़िल्टर मैचिंग के बारे में जानकारी पाने के लिए, --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 होगा. उसे 'स्थानीय' रणनीति के साथ 'कंपाइलिंग //foo/bar/baz' चला देगा, लेकिन क्रम विपरीत करने पर यह 'सैंडबॉक्स' के साथ चलेगा.
टैग: execution
--[no]use_target_platform_for_tests डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो Bazel, टेस्ट एक्ज़ेक्यूटिव ग्रुप के बजाय, टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: विवरण देखें: Android का टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_crosstool_top=<a build target label> डिफ़ॉल्ट: "//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> डिफ़ॉल्ट: "": यह नीति उन प्लैटफ़ॉर्म को सेट करती है जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी एक फ़ैट APKs होती है, जिसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--android_sdk=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk": Android SDK टूल/प्लैटफ़ॉर्म के बारे में बताता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain": Apple और Objc नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> डिफ़ॉल्ट: "": कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: विवरण देखें: टारगेट इकट्ठा करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger": रॉ कवरेज रिपोर्ट को पोस्ट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. यह फ़िलहाल एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcow_merger' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> डिफ़ॉल्ट: "@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> डिफ़ॉल्ट: "@bazel_tools//tools/test:कवरेज_support": सहायता फ़ाइलों की वह जगह जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई के इनपुट के लिए ज़रूरी होती है. डिफ़ॉल्ट रूप से '//tools/test:coverage_support' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: विवरण देखें: यह तय करता है कि कस्टम मैलक लागू किया जाए या नहीं. यह सेटिंग, बिल्ड के नियमों में मॉलक एट्रिब्यूट को बदल देती है.
टैग: 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 डिफ़ॉल्ट: "गलत": अगर यह नीति सेट है, तो हर Xcode कार्रवाई के लिए "requires-xcode:{version}" का इस्तेमाल करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" चलाने की ज़रूरत भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution
--[no]experimental_prefer_mutual_xcode डिफ़ॉल्ट: "सही": अगर सही है, तो सबसे हाल का Xcode इस्तेमाल करें जो स्थानीय और कहीं से भी उपलब्ध हो. अगर यह गलत है या कोई भी म्यूचुअली उपलब्ध वर्शन नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state
--extra_execution_platforms=<comma-separated list of options> डिफ़ॉल्ट: "": ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन प्लैटफ़ॉर्म को वर्कस्पेस फ़ाइल में रजिस्टर_execution_platforms() के ज़रिए एलान किए गए प्लैटफ़ॉर्म से पहले लागू किया जाएगा. यह विकल्प सिर्फ़ एक बार सेट किया जा सकता है; बाद के इंस्टेंस पहले के फ़्लैग की सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन में ध्यान दिए जाने वाले नियम. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन टूलचेन का इस्तेमाल, workspace_toolchains() के ज़रिए वर्कSPACE फ़ाइल में बताए गए टूल से पहले किया जाता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: विवरण देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. क्रॉसटूल टूलचेन में डिफ़ॉल्ट वैल्यू को चुना जाता है और आपको इसे बदलने की ज़रूरत नहीं पड़ती.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: विवरण देखें: बिना किसी बटन वाला फ़्लैग. इसे आने वाली रिलीज़ से हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: विवरण देखें: अगर इसके बारे में बताया गया है, तो यह सेटिंग exec कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> डिफ़ॉल्ट: "@local_config_platform//:host": प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही": अगर सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'nonhost' सुविधाओं को चालू नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_android_toolchain_resolution डिफ़ॉल्ट: "सही": Android के नियमों (Starlark और निजी) के लिए Android SDK चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "गलत": Apple के नियमों (Starlark और निजी) के लिए, Apple SDK चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--[no]incompatible_remove_legacy_whole_archive डिफ़ॉल्ट: "सही": अगर सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_require_ctx_in_configure_features डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "गलत": सही होने पर, एक्ज़ीक्यूटेबल के लिए स्ट्रिप से जुड़ी कार्रवाई में फ़्लैग -x का इस्तेमाल किया जाएगा, जो डाइनैमिक सिंबल के रिज़ॉल्यूशन को नहीं तोड़ता है.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects डिफ़ॉल्ट: "सही": अगर टूलचेन के साथ काम करने वाला इंटरफ़ेस शेयर किया गया ऑब्जेक्ट है, तो उसका इस्तेमाल करें. फ़िलहाल, यह सेटिंग सभी ELF टूलचेन में काम करती है.
टैग: 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> डिफ़ॉल्ट: "": मैपिंग फ़ाइल की जगह, जो बताती है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं किया गया है, तो किस प्लैटफ़ॉर्म का इस्तेमाल किया जाए या पहले से मौजूद प्लैटफ़ॉर्म पर कौनसे फ़्लैग सेट किए जाएं. मुख्य फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता होना चाहिए. यह डिफ़ॉल्ट रूप से 'platform_mappings' (फ़ाइल फ़ोल्डर रूट के तहत आने वाली फ़ाइल) पर सेट होता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> डिफ़ॉल्ट: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python2_path=<a string> डिफ़ॉल्ट: विवरण देखें: अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से बंद कर दिया गया है.
टैग: no_op, deprecated
--python3_path=<a string> डिफ़ॉल्ट: विवरण देखें: अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से बंद कर दिया गया है.
टैग: no_op, deprecated
--python_path=<a string> डिफ़ॉल्ट: विवरण देखें: Python अनुवादक के ऐब्सलूट पाथ को टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains ने इसे बंद किया है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: विवरण देखें: Python इंटरप्रेटर को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains ने इसे बंद किया है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: यह tvOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, tvOS ऐप्लिकेशन बनाने के लिए किया जाएगा. इसकी जानकारी न होने पर, 'xcode_version' से tvOS के SDK टूल का डिफ़ॉल्ट वर्शन इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: WatchOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट WatchOS SDK वर्शन इस्तेमाल करता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: विवरण देखें: अगर बताया गया है, तो सही बिल्ड ऐक्शन के लिए दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर इसकी जानकारी नहीं दी गई है, तो Xcode के एक्ज़ीक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes": xcode_config नियम का लेबल. इसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन को चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत": डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build डिफ़ॉल्ट: "सही": बिल्ड लागू करें. आम तौर पर, ऐसा किया जाता है. --nobuild तय करने से, बिल्ड ऐक्शन को लागू करने से पहले बिल्ड बंद हो जाता है, जिससे पैकेज लोड होने और उसके विश्लेषण के चरण पूरे होने पर शून्य दिखता है. यह मोड, उन चरणों की जांच करने के लिए काम का है.
टैग: execution, affects_outputs
--[no]build_runfile_links डिफ़ॉल्ट: "सही": अगर सही है, तो रनफ़ाइल बनाने के लिए सभी टारगेट के लिए जंगलों को आपस में लिंक किया जाता है. अगर यह गलत है, तो इन्हें सिर्फ़ तब लिखें, जब ज़रूरी हो. इसके लिए, किसी स्थानीय कार्रवाई, टेस्ट या रन कमांड का इस्तेमाल करें.
टैग: affects_outputs
--[no]build_runfile_manifests डिफ़ॉल्ट: "सही": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर गलत है, तो उन्हें मिटा दें. गलत होने पर लोकल टेस्ट नहीं चलाए जाएंगे.
टैग: affects_outputs
--[no]build_test_dwp डिफ़ॉल्ट: "गलत": यह सुविधा चालू होने पर, स्टैटिक और फ़िशन के साथ C++ टेस्ट बनाने पर, टेस्ट बाइनरी के लिए भी .dwp फ़ाइल अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h": cc_proto_library से बनाई जाने वाली हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc": cc_proto_library से बनाई जाने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत": Proto_library में, वैकल्पिक Java api वर्शन के लिए अतिरिक्त कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_proto_extra_actions डिफ़ॉल्ट: "गलत": Proto_library में, वैकल्पिक Java api वर्शन के लिए अतिरिक्त कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत": चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को, कंपाइलेशन के आउटपुट के तौर पर सेव करें.
टैग: affects_outputs, experimental
--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "गलत": आसपेक्ट का इस्तेमाल करके, पुष्टि करने वाली कार्रवाइयां चलाना है या नहीं (टेस्ट के साथ पैरललिज़्म के लिए).
टैग: execution, affects_outputs
--fission=<a set of compilation modes> डिफ़ॉल्ट: "नहीं": यह बताता है कि C++ के कंपाइलेशन और लिंक के लिए कौनसे कंपाइलेशन मोड, फ़्रैशन का इस्तेमाल करते हैं. यह सभी मोड चालू करने के लिए, {'Fastbuild', 'dbg', 'opt'} या विशेष वैल्यू 'yes' का कोई भी कॉम्बिनेशन हो सकता है और सभी मोड बंद करने के लिए 'no' का कोई भी कॉम्बिनेशन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही": सही होने पर, नेटिव नियम अपनी रनफ़ाइल में <code>DefaultInfo.files</code> डेटा डिपेंडेंसी जोड़ देते हैं. यह Starlark के नियमों (https://bazel.build/extending/rules#runfiles_features_to_avoid) के लिए सुझाए गए तरीके से मेल खाता है.
टैग: affects_outputs, incompatible_change
--[no]legacy_external_runfiles डिफ़ॉल्ट: "सही": अगर सही हो, तो रनफ़ाइल/डेटा स्टोर करने की जगह के लिए .runfiles/wsname/external/repo (.runfiles/repo) के अलावा, बाहरी डेटा स्टोर करने की जगहों के लिए, जंगलों को सिमलिंक करने वाला जंगल बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत": यह बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--output_groups=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इस सूची में हर नाम के आगे + या - का इस्तेमाल किया जाता है. आउटपुट ग्रुप के डिफ़ॉल्ट सेट में, + से शुरू होने वाले ग्रुप को जोड़ा जाता है, जबकि इससे शुरू होने वाले ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप इस तारीख से पहले नहीं जोड़ा गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हटा दिया जाता है. उदाहरण के लिए, --Details_groups=+foo,+bar, डिफ़ॉल्ट सेट, foo, और बार का 'यूनियन' बनाता है. वहीं, --OUT_groups=foo,bar, डिफ़ॉल्ट सेट को ओवरराइड करता है, ताकि सिर्फ़ foo और बार बनाए गए.
टैग: execution, affects_outputs
--[no]run_validations डिफ़ॉल्ट: "सही": बिल्ड के हिस्से के तौर पर पुष्टि करने से जुड़ी कार्रवाइयां करनी हैं या नहीं. https://bazel.build/extending/rules#validation_actions
टैग देखें: execution, affects_outputs
--[no]save_temps डिफ़ॉल्ट: "गलत": अगर यह नीति सेट की जाती है, तो 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> डिफ़ॉल्ट: "armeabi-v7a": Android टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]android_databinding_use_androidx डिफ़ॉल्ट: "सही": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटाबाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "सही": Android डेटाबाइंडिंग v2 का इस्तेमाल, 3.4.0 आर्ग्युमेंट के साथ करें. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद": इससे तय होता है कि जब कोई cc_binary साफ़ तौर पर शेयर की गई लाइब्रेरी नहीं बनाती है, तो Android के नियमों के C++ डिप डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बैजल यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "वर्णमाला": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्ज़ेक्रूट के पाथ के हिसाब से क्रम में लगाया गया है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में, कॉन्फ़िगरेशन डायरेक्ट्री के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आने वाले क्रम में लगाया जाता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत": यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए रिसॉर्स को कम करने की सुविधा को चालू करती है.
टैग: affects_outputs, loading_and_analysis
--aspects=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: टॉप लेवल टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा-सेपरेटेड लिस्ट. सूची में, अगर आसपेक्ट some_aspect होता है, तो ज़रूरी_आसपेक्ट_providers के ज़रिए, ज़रूरी आसपेक्ट प्रोवाइडर तय करें. इसके बाद, some_aspect बताए गए हर पहलू के बाद चलने लगेगा. हालांकि, आसपेक्ट लिस्ट में पहले बताए गए हर पहलू के बाद, इस सूची में ऐसे सभी पहलू शामिल होंगे जिनके विज्ञापन देने वाले लोग, some_aspect ज़रूरी आसपेक्ट प्रोवाइडर को पूरा करते हैं. इसके अलावा, some_aspect, एट्रिब्यूट के बताए गए सभी ज़रूरी पहलुओं के बाद चलने लगेगा. इसके बाद some_aspect के पास उन पहलुओं की सेवा देने वाली कंपनियों की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, जैसे कि '//tools:my_def.bzl%my_aspect', जिसमें 'my_aspect' किसी फ़ाइल टूल/my_def.bzl से मिली टॉप लेवल वैल्यू है
--[no]build_python_zip डिफ़ॉल्ट: "ऑटो": Python के लिए एक्ज़ीक्यूटेबल ज़िप बनाएं. Windows पर, दूसरे प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs
--catalyst_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple Catalyst बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage डिफ़ॉल्ट: "गलत": अगर यह बताया जाता है, तो Bazel इंस्ट्रुमेंट कोड का इस्तेमाल करेगा और जहां तक मुमकिन हो, ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करेगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी भी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसकी जगह, 'bazel profile' निर्देश का इस्तेमाल करना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "Fastbuild": वह मोड तय करें जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> बार कई बार इस्तेमाल किया गया है: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> बार कई बार इस्तेमाल किया गया है: जीसीसी को पास करने के दूसरे विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> डिफ़ॉल्ट: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: विवरण देखें: सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करके, कंपाइलेशन ऑप्टिमाइज़ करें. उस ZIP फ़ाइल के पूरे पाथ का नाम बताएं जिसमें प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल हो.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: विवरण देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंटेशन से बाइनरी जनरेट करें. 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> बार कई बार इस्तेमाल किया गया है: हर --तय करें विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, आखिरी वैल्यू जीत जाती है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "डिफ़ॉल्ट": इससे तय होता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह चुनेगा कि उसे डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही": अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_runfiles डिफ़ॉल्ट: "ऑटो": रनफ़ाइल सिमलिंक ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows और दूसरे प्लैटफ़ॉर्म पर बंद है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> बार कई बार इस्तेमाल किया गया है: अब अलग-अलग पहलुओं के पक्ष में नहीं, बल्कि उनके सुझाव दिए गए हैं. मौजूदा बिल्ड ऐक्शन में अतिरिक्त_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत": APK में Java रिसॉर्स को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही": Android Databinding v2 का इस्तेमाल करें. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत": यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए रिसॉर्स को कम करने की सुविधा को चालू करती है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत": dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत": अगर इसके बारे में बताया जाता है, तो Bazel, जनरेट की गई फ़ाइलों के लिए कवरेज की जानकारी भी जनरेट करेगा.
टैग: affects_outputs
--[no]experimental_convenience_symlinks डिफ़ॉल्ट: "सामान्य": इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के सिमलिंक (बिल्ड के बाद फ़ाइल फ़ोल्डर में दिखने वाले सिमलिंक) कैसे मैनेज किए जाएंगे. संभावित वैल्यू: सामान्य (डिफ़ॉल्ट): हर तरह का सुविधा सिमलिंक बनाया या मिटाया जाएगा, जैसा कि बिल्ड से तय होता है. साफ़ करें: सभी सिमलिंक बिना किसी शर्त के हटा दिए जाएंगे. अनदेखा करें: सिमलिंक अकेले छोड़ दिए जाएंगे. Log_only: लॉग मैसेज इस तरह जनरेट करें जैसे 'सामान्य' पास कर दिए गए हों, लेकिन असल में कोई फ़ाइल सिस्टम ऑपरेशन (टूल के लिए उपयोगी) न करें. ध्यान दें कि सिर्फ़ उन सिमलिंक के नाम पर असर पड़ सकता है जिनके नाम, --मिलते-जुलते नतीजों की मौजूदा वैल्यू की वजह से जनरेट होते हैं. अगर प्रीफ़िक्स में बदलाव होता है, तो पहले से मौजूद कोई भी सिमलिंक छोड़ दिए जाएंगे.
टैग: affects_outputs
--[no]experimental_convenience_symlinks_bep_event डिफ़ॉल्ट: "गलत": इस फ़्लैग से यह कंट्रोल किया जाता है कि हम BuildEventProtocol में बिल्ड event परोसने के लिए ज़िम्मेदार होने या न होने से जुड़ी जानकारी पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में salesSymlinksIdentified के लिए एक एंट्री होगी, जिसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक शामिल होंगे. गलत होने पर, BuildEventProtocol में सुविधाSymlinksIdentified एंट्री खाली रहेगी.
टैग: affects_outputs
--experimental_objc_fastbuild_options=<comma-separated list of options> डिफ़ॉल्ट: "-O0,-DDEBUG=1": यह स्ट्रिंग, objc फ़ास्ट बिल्ड कंपाइलर के विकल्पों के तौर पर इस्तेमाल करती है.
टैग: action_command_lines
--[no]experimental_omitfp डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो स्टैक करने के लिए libunwind का इस्तेमाल करें. साथ ही, इसे -fomit-frame-Pointer और -fasynchronous-unwind-tables की मदद से कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> डिफ़ॉल्ट: "बंद": आउटपुट ट्री नियम में, आउटपुट लिखने के लिए किस मॉडल का इस्तेमाल करना चाहिए, खास तौर से मल्टी-प्लैटफ़ॉर्म या मल्टी-कॉन्फ़िगरेशन वाले बिल्ड के लिए. इस पर प्रयोग बहुत ज़्यादा किया जा रहा है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 देखें. स्टारलार्क कार्रवाइयां, '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 फ़ॉर्मैट में होनी चाहिए, जहां लेबल किसी प्लैटफ़ॉर्म के बारे में बताता है. साथ ही, आउटपुट पाथ में इस्तेमाल करने के लिए वैल्यू, पसंदीदा छोटा नाम है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_छिपने वाली यूआरएल सही से काम कर रही हो. नाम की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए छोटा नाम इस्तेमाल किया जाता है. सटीक स्कीम, एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है. सबसे पहले, बहुत कम मामलों में --platforms विकल्प में कोई एक वैल्यू नहीं होती. इसलिए, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए किसी छोटे नाम को --experimental_override_name_platform_in_इस_क्रिएटर ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_ बदलें_direct_legacy_heur होंगी, तो मौजूदा प्लैटफ़ॉर्म के लेबल के हिसाब से छोटे नाम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल आखिरी विकल्प के तौर पर किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत": अगर इसके बारे में बताया गया है, तो पेज पर इकट्ठा करने के लिए कोड इकट्ठा करने की सुविधा चालू होने पर, Bazel, gcov के बजाय llvm-cov कवरेज वाले मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic डिफ़ॉल्ट: "सही": कृपया इस फ़्लैग का इस्तेमाल, माइग्रेट करने या टेस्टिंग की सुझाई गई रणनीति के हिस्से के तौर पर ही करें. ध्यान दें कि अनुभव से जुड़े डेटा में कमियां हैं और हमारा सुझाव है कि सिर्फ़ --experimental_override_name_platform_in_इसी आउटपुट_डायर का इस्तेमाल करके माइग्रेट करें.
टैग: affects_outputs, experimental
--fat_apk_cpu=<comma-separated set of options> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "गलत": बिना किसी बटन वाला फ़्लैग. इसे आने वाली रिलीज़ से हटा दिया जाएगा.
टैग: no_op
--fdo_instrument=<a string> डिफ़ॉल्ट: विवरण देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर की मदद से, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान, डंप किया जाएगा.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: विवरण देखें: कम्यूनिटी को ऑप्टिमाइज़ करने के लिए, एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री, ऑटो प्रोफ़ाइल वाली 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 डिफ़ॉल्ट: "गलत": अगर यह सेटिंग चालू होती है, तो सभी 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> डिफ़ॉल्ट: "ऑप्ट": वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल होंगे. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> बार कई बार इस्तेमाल किया गया है: एक्ज़ीक्यूशन कॉन्फ़िगरेशन में C (लेकिन C++ नहीं) सोर्स फ़ाइलों को कंपाइल करते समय, C कंपाइलर को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> बार कई बार इस्तेमाल किया गया है: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के दूसरे विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> डिफ़ॉल्ट: "": होस्ट के लिए सीपीयू.
टैग: 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> बार कई बार इस्तेमाल किया गया है: exec कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का एक और विकल्प.
टैग: 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/ में bar.cc. को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन जोड़ता है.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "गलत": चालू होने पर, किसी नियम से इस्तेमाल की जाने वाली हर टूलचेन के लिए, एक एक्ज़ेक्यूटिव ग्रुप अपने-आप बन जाता है. यह नियम काम करे, इसके लिए कार्रवाइयों पर `toolchain` पैरामीटर तय करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 देखें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही": अगर सही है, तो जेनफ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets डिफ़ॉल्ट: "गलत": कवरेज की सुविधा चालू होने पर, इससे पता चलता है कि टेस्ट के नियमों को लागू करने पर विचार करना है या नहीं. यह नीति सेट होने पर, --instrumentation_filter से शामिल किए गए टेस्ट नियम लागू होते हैं. ऐसा न होने पर, टेस्ट के नियमों को कवरेज इंस्ट्रुमेंटेशन से हमेशा बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/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_ऐप्लिकेशन बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें बताए गए सभी आर्किटेक्चर शामिल हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive डिफ़ॉल्ट: "सही": अब काम नहीं करता, इसकी जगह ले ली गई है --insupported_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> बार कई बार इस्तेमाल किया गया है: एलटीओ बैकएंड चरण को पास करने का एक और विकल्प (--features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> बार कई बार इस्तेमाल किया गया है: एलटीओ को इंडेक्स करने के चरण को पास करने का एक और विकल्प (-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 डिफ़ॉल्ट: "गलत": अगर यह नीति सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --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 बैकएंड (-features=thin_lto के तहत) को चुनिंदा तरीके से पास करने के अन्य विकल्प. यह विकल्प कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां रेगुलर एक्सप्रेशन फ़िल्टर, शामिल किए गए और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची दिखाता है. 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> डिफ़ॉल्ट: विवरण देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, प्रोपेलर प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोपेलर प्रोफ़ाइल में कम से कम एक फ़ाइल होनी चाहिए. एक cc प्रोफ़ाइल और ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल स्वीकार करता है, जिसे प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, a/b/BUILD: मिटा देने वाली फ़ाइल का लेबल तय करने वाली BUILD फ़ाइल, जो कि a/b/BUILD: मिटानी-बढ़ाने से जुड़ी जानकारी( name = "propler_profile", cc_profile = "propler_cc_profile.txt", ld_profile = "profiller_ld_profile.txt",) में लेबल को परिभाषित करने वाली BUILD फ़ाइल हो सकती है. Export_files डायरेक्टिव को, Bazel को दिखाने के लिए संबंधित पैकेज में जोड़ना पड़ सकता है. विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --propler_optimize=//a/b:propler_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: विवरण देखें: प्रोपेलर ऑप्टिमाइज़ किए गए बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: विवरण देखें: प्रोपेलर ऑप्टिमाइज़ किए गए बिल्ड के लिए ld_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: विवरण देखें: 'जांच करें' और 'रन' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले शामिल करने के लिए उपसर्ग. अगर वैल्यू '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 डिफ़ॉल्ट: "सही": अगर सही है, तो एक जैसी काम करने वाली नेटिव लाइब्रेरी, अलग-अलग टारगेट के बीच शेयर की जाएंगी
टैग: loading_and_analysis, affects_outputs
--[no]stamp डिफ़ॉल्ट: "गलत": तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह के साथ बाइनरी बनाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह बताता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं ("-Wl,--strip-debug" का इस्तेमाल करके). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि स्ट्रिप iff --compilation_mode=foundbuild.
टैग: affects_outputs
--stripopt=<a string> बार कई बार इस्तेमाल किया गया है: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs
--symlink_prefix=<a string> डिफ़ॉल्ट: विवरण देखें: यह प्रीफ़िक्स, बिल्ड के बाद बनाए जाने वाले किसी भी सुविधा से जुड़े सिमलिंक से पहले जोड़ा जाता है. अगर इसे छोड़ा जाता है, तो डिफ़ॉल्ट वैल्यू के तौर पर बिल्ड टूल का नाम दिखेगा. इसके बाद हाइफ़न लगेगा. अगर '/' पास हो जाता है, तो कोई सिमलिंक नहीं बनाए जाते और कोई चेतावनी नहीं भेजी जाती. चेतावनी: '/' के लिए उपलब्ध खास फ़ंक्शन का इस्तेमाल जल्द ही बंद कर दिया जाएगा. इसके बजाय, --experimental_convenience_simlinks=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_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: विवरण देखें: डेटा कंपाइलेशन ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_ड़ियों/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू होते हैं, जैसे कि xbinary_fdo को कभी तय नहीं किया गया हो.
टैग: affects_outputs

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: "": Environment_group का एलान करें, ताकि target_environment वैल्यू के लिए सीपीयू वैल्यू को अपने-आप मैप करने के लिए, इसका इस्तेमाल किया जा सके.
टैग: changes_inputs, loading_and_analysis, experimental
--[no]check_licenses डिफ़ॉल्ट: "गलत": इस बात की जांच करें कि डिपेंडेंट पैकेज ने जो लाइसेंसिंग पाबंदियां लगाई हैं वे बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर न डाल रही हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग: build_file_semantics
--[no]check_visibility डिफ़ॉल्ट: "सही": यह सेटिंग बंद होने पर, टारगेट डिपेंडेंसी में 'किसको दिखे' सेटिंग से जुड़ी गड़बड़ियां, चेतावनियों के तौर पर मार्क हो जाती हैं.
टैग: build_file_semantics
--[no]desugar_for_android डिफ़ॉल्ट: "सही": डेक्सिंग से पहले, Java 8 बाइटकोड को डिसुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs डिफ़ॉल्ट: "गलत": लेगसी डिवाइसों के लिए, ऐप्लिकेशन में काम करने वाली Java 8 लाइब्रेरी शामिल करनी है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints डिफ़ॉल्ट: "सही": यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर कोई टारगेट ऐसी डिपेंडेंसी है जो एक जैसे एनवायरमेंट के साथ काम नहीं करती, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps डिफ़ॉल्ट: "सही": 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> डिफ़ॉल्ट: "डिफ़ॉल्ट": सही होने पर, यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए जाने वाले सभी टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "गलत": अगर यह सुविधा चालू है, तो आउटपुट फ़ाइल वाले ज़रूरी टारगेट के लिए testonly का इस्तेमाल करें. इसके लिए, जनरेट करने वाले नियम का सिर्फ़ टेस्ट देखें. यह 'किसको दिखे' सेटिंग से मेल खाता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "गलत": चालू होने पर, विज़िबिलिटी की जांच करने की सुविधा, टूलचेन लागू करने की सुविधा पर भी लागू होती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "गलत": इस सुविधा के चालू होने पर, Android के मूल नियमों का सीधे तौर पर इस्तेमाल करने की सुविधा बंद हो जाती है. कृपया https://github.com/bazelbuild/rules_android से गए Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "गलत": नहीं. पुराने सिस्टम के साथ काम करने के लिए, इसे यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 डिफ़ॉल्ट: "सही": अगर सही है, तो 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 डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: विवरण देखें: -insupported_python_disallow_native_rules लागू करने के लिए, अनुमति वाली सूची (package_group target) का इस्तेमाल करें.
टैग: loading_and_analysis
--[no]strict_filesets डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू किया जाता है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "गड़बड़ी": जब तक बंद न हो, तब तक यह जांच करता है कि कोई proto_library टारगेट साफ़ तौर पर सभी सीधे इस्तेमाल किए जाने वाले टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद": जब तक बंद न हो, तब तक यह जांच करता है कि कोई proto_library टारगेट साफ़ तौर पर 'इंपोर्ट करें' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट किए गए के तौर पर बताए.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes डिफ़ॉल्ट: "गलत": अगर सही है, तो सिस्टम से मिलने वाले हेडर में पाथ (-isystem) को शामिल करना भी ज़रूरी होता है.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> बार कई बार इस्तेमाल किया गया है: इस बिल्ड के टारगेट एनवायरमेंट का एलान करता है. "एनवायरमेंट" नियम के लेबल का रेफ़रंस होना चाहिए. अगर तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने वाले होने चाहिए.
टैग: changes_inputs

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

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत": अगर supported_enforce_config_setting_activity=false है, तो यह नॉप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो ऐसी कोई भी config_setting जिसके लिए साफ़ तौर पर दिखने वाला एट्रिब्यूट मौजूद नहीं है //visibility:public. अगर यह फ़्लैग सही है, तो config_setting उसी लॉजिक का पालन करती है जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही": नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "गलत": अगर सही हो, तो objc_library andobjc_Import में जाकर SDK_frameworks और social_sdk_frameworks के एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही": अगर सही है, तो config_setting को लागू करने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत": अगर सही है, तो objc_library और objc_Import में हमेशा लिंक की सुविधा वाली वैल्यू के लिए, डिफ़ॉल्ट वैल्यू को 'सही' के तौर पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत": सही होने पर, बिल्टइन py_* नियमों का इस्तेमाल करते समय कोई गड़बड़ी होती है; इसके बजाय, Rules_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत": सही होने पर, नियम को टारगेट करने से विश्लेषण नहीं हो पाता है. इसका नतीजा यह होता है कि टारगेट, गड़बड़ी की जानकारी वाले विश्लेषणFailureInfo के इंस्टेंस को लागू नहीं करेगा, न कि बिल्ड फ़ेल हो जाएगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट की मदद से, ज़्यादा से ज़्यादा ट्रांज़िटिव डिपेंडेंसी सेट करता है. इस सीमा को पार करने से नियम में गड़बड़ी होगी.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत": अगर सही dex2oat कार्रवाई के पूरा न हो पाने पर, टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--[no]check_tests_up_to_date डिफ़ॉल्ट: "गलत": टेस्ट न करें. बस यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी जांच के नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर किसी जांच को बनाने या लागू करने की ज़रूरत होती है, तो गड़बड़ी की रिपोर्ट की जाती है और टेस्टिंग फ़ेल हो जाती है. इस विकल्प का मतलब है --check_up_to_date व्यवहार.
टैग: execution
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> बार कई बार इस्तेमाल किया गया है: टेस्ट के लिए, रिसॉर्स की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर कोई पॉज़िटिव नंबर <value> के तौर पर दिया गया है, तो वह जांच के लिए इस्तेमाल किए जाने वाले सभी साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगा. अगर कॉमा लगाकर अलग की गई चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बड़े साइज़ के टेस्ट साइज़ के लिए, रिसॉर्स की संख्या को बदल देंगी. वैल्यू Host_RAM/Host_CPU भी हो सकती है. विकल्प के तौर पर, इसके बाद [-|*]<float> (जैसे कि मेमोरी=Host_RAM*.1,Host_RAM*.2,Host_RAM*.3,Host_RAM*.4) भी हो सकते हैं. इस फ़्लैग से तय किए गए जांच वाले डिफ़ॉल्ट रिसॉर्स, टैग में बताए गए साफ़ तौर पर उपलब्ध रिसॉर्स से बदल जाते हैं.
--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "गलत": 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' के तौर पर मार्क किया जाता है. आम तौर पर, वैल्यू के तौर पर सिर्फ़ एक पूर्णांक या 'डिफ़ॉल्ट' स्ट्रिंग होती है. अगर पूर्णांक है, तो सभी टेस्ट N बार तक चलाए जाएंगे. अगर यह 'डिफ़ॉल्ट' है, तो सामान्य जांचों के लिए सिर्फ़ एक बार जांच करने की कोशिश की जाएगी. साथ ही, उन टेस्ट के लिए तीन बार कोशिश की जाएगी जिन्हें उनके नियम के मुताबिक, साफ़ तौर पर अस्थिर के तौर पर मार्क किया गया है (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 से जुड़ी जांच तीन बार नहीं की जा सकतीं. यह विकल्प कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए आर्ग्युमेंट को प्राथमिकता दी जाती है. अगर कुछ भी मेल नहीं खाता है, तो व्यवहार ऊपर दिए गए 'डिफ़ॉल्ट' की तरह होता है.
टैग: execution
--[no]ios_memleaks डिफ़ॉल्ट: "गलत": 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"> डिफ़ॉल्ट: "ऑटो": एक साथ चलाए जाने वाले लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<फ़्लोट>) करें, उदाहरण के लिए. "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. जहां Run_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 डिफ़ॉल्ट: "सही": यह सुविधा बंद होने पर, पास न होने वाले किसी भी टेस्ट से पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से सभी टेस्ट चलते हैं, भले ही कुछ टेस्ट पास नहीं हो पाते.
टैग: execution
--test_strategy=<a string> डिफ़ॉल्ट: "": इससे पता चलता है कि टेस्ट करते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर कोई एक पॉज़िटिव पूर्णांक मान दिया गया है, तो वह सभी कैटगरी को ओवरराइड कर देगा. अगर कॉमा लगाकर अलग किए गए चार पूर्णांकों का पता लगाया जाता है, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. किसी भी रूप में, -1 की वैल्यू ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहती है.
--test_tmpdir=<a path> डिफ़ॉल्ट: विवरण देखें: 'bazel टेस्ट' के लिए बेस अस्थायी डायरेक्ट्री तय करता है.
--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही": अगर सही है, तो टेस्ट के ऐसे आउटपुट ZIP फ़ाइल में संग्रहित किए जाएंगे जिनका एलान नहीं किया गया है.
टैग: test_runner

--cache_computed_file_digests=<a long integer> डिफ़ॉल्ट: "50000": अगर यह वैल्यू 0 से ज़्यादा है, तो Bazel को कॉन्फ़िगर करें. इससे, Drive में मौजूद डाइजेस्ट फ़ाइल को हर बार ज़रूरत होने पर, फिर से कंप्यूट करने के बजाय, उनके मेटाडेटा के आधार पर मेमोरी में मौजूद फ़ाइलों को कैश मेमोरी में सेव किया जाएगा. इसे 0 पर सेट करने से सही जानकारी मिलती है, क्योंकि फ़ाइल के मेटाडेटा से फ़ाइल में किए गए सभी बदलावों को नोट नहीं किया जा सकता. अगर वैल्यू 0 नहीं है, तो यह संख्या, कैश मेमोरी में सेव की जाने वाली फ़ाइल डाइजेस्ट की संख्या के तौर पर कैश के साइज़ को दिखाती है.
--[no]experimental_enable_skyfocus डिफ़ॉल्ट: "गलत": अगर आपने वैल्यू सही है, तो इंक्रीमेंटल (बढ़ने वाले) बिल्ड के लिए, Bazel की मेमोरी फ़ुटप्रिंट कम करने के लिए --experimental_work_set का इस्तेमाल चालू करें. इस सुविधा को स्काईफ़ोकस के नाम से जाना जाता है.
टैग: host_machine_resource_optimizations
--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "गलत": LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग: action_command_lines
--[no]experimental_inmemory_dotd_files डिफ़ॉल्ट: "सही": अगर C++ .d फ़ाइलें चालू की जाती हैं, तो उन्हें डिस्क पर सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files डिफ़ॉल्ट: "सही": चालू होने पर, Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क पर सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत": इस सुविधा को चालू करने पर, --trim_test_ Configuration, सिर्फ़ testonly=1 मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन में काट-छांट नहीं करेगा. इसका मकसद, कार्रवाई से जुड़े विवाद की समस्याओं को कम करना है. ऐसा तब किया जाता है, जब गैर-जांच नियम cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_कॉन्फ़िगरेशन गलत है, तो कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state
--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "गलत": इनपुट फ़ाइलों से #include लाइनों को पार्स करके, इनपुट को C/C++ कंपाइलेशन में बदलना है या नहीं. यह कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और बढ़ोतरी को बेहतर बना सकता है. हालांकि, इससे बिल्ड टूट भी सकते हैं, क्योंकि शामिल स्कैनर, C प्रीप्रोसेसर सिमैंटिक को पूरी तरह लागू नहीं करता. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर के कंडीशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. अगर इस फ़्लैग से जुड़ी कोई समस्या है, तो उसे बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs
--experimental_working_set=<comma-separated list of options> डिफ़ॉल्ट: "": Sस्काईफ़ोकस के लिए काम करने का सेट. फ़ाइल फ़ोल्डर के रूट-रिलेटिव पाथ को कॉमा लगाकर अलग करें. यह एक स्टेटफ़ुल फ़्लैग है. वर्किंग सेट तय करने पर, वह बाद में शुरू होने वाली बातचीत के लिए बना रहता है, जब तक कि उसे नए सेट के साथ फिर से परिभाषित नहीं किया जाता.
टैग: host_machine_resource_optimizations
--[no]incremental_dexing डिफ़ॉल्ट: "सही": ज़्यादातर जार फ़ाइल को डीक्स करने का ज़्यादातर काम अलग-अलग किया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "Host_CPUS": स्थानीय तौर पर एक्ज़ीक्यूट किए गए बिल्ड ऐक्शन पर खर्च करने के लिए, Bazel के लिए उपलब्ध लोकल सीपीयू कोर की कुल संख्या को साफ़ तौर पर सेट करें. एक पूर्णांक या "Host_CPUS" लेता है, वैकल्पिक रूप से उसके बाद [-|*]<float> (उदाहरण के लिए, उपलब्ध आधे कोर का इस्तेमाल करने के लिए Host_CPUS*.5). डिफ़ॉल्ट रूप से, ("Host_CPUS"), Bazel, उपलब्ध सीपीयू (CPU) कोर की संख्या का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
टैग: host_machine_resource_optimizations
--local_extra_resources=<a named float, 'name=value'> बार कई बार इस्तेमाल किया गया है: Bzel के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. स्ट्रिंग-फ़्लोट पेयर में लेता है. कई तरह के अतिरिक्त संसाधनों के बारे में बताने के लिए, कई बार इस्तेमाल किया जा सकता है. Bazel, एक साथ चलने वाली कार्रवाइयों को सीमित करेगा. ऐसा, उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर किया जाएगा. टेस्ट, "संसाधन:<resoucename>:<amount>" फ़ॉर्मैट के टैग का इस्तेमाल करके, अतिरिक्त संसाधनों की ज़रूरत का एलान कर सकते हैं. उपलब्ध सीपीयू, रैम, और संसाधन इस फ़्लैग के साथ सेट नहीं किए जा सकते.
टैग: host_machine_resource_optimizations
--local_ram_resources=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "Host_RAM*.67": BZel के लिए उपलब्ध लोकल होस्ट रैम (एमबी में) की कुल संख्या को साफ़ तौर पर सेट करें, ताकि बिल्ड ऐक्शन पर खर्च किया जा सके. एक पूर्णांक या "Host_RAM" लेता है, वैकल्पिक रूप से इसके बाद [-|*]<float> (उदाहरण के लिए, उपलब्ध आधी रैम का इस्तेमाल करने के लिए Host_RAM*.5). डिफ़ॉल्ट रूप से, ("Host_RAM*.67"), Bazel, उपलब्ध रैम की मात्रा का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और इसका 67% हिस्सा इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations
--local_resources=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> बार कई बार इस्तेमाल किया गया है: Bzel पर उपलब्ध संसाधनों की संख्या सेट करें. किसी फ़्लोट या Host_RAM/Host_CPUS के लिए असाइनमेंट लेता है. इसके बाद, वैकल्पिक रूप से [-|*]<फ़्लोट> (उदाहरण के लिए, उपलब्ध रैम में से आधे का इस्तेमाल करने के लिए मेमोरी=Host_RAM*.5) का इस्तेमाल करें. कई तरह के संसाधनों के बारे में बताने के लिए, इनका एक से ज़्यादा बार इस्तेमाल किया जा सकता है. Bazel, उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, एक साथ चलने वाली कार्रवाइयों को सीमित करेगा. टेस्ट, "संसाधन:<resource name>:<amount>" फ़ॉर्मैट वाले टैग का इस्तेमाल करके, यह बता सकते हैं कि उन्हें कितने संसाधनों की ज़रूरत है. --local_{cpu|ram|extra}_resources के तय किए गए संसाधनों को बदल देता है.
टैग: host_machine_resource_optimizations
--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही": अगर इस नीति को सेट किया जाता है, तो clang से उत्सर्जित होने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइलेशन में पास किए गए इनपुट के सेट को हटाने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत": टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग: execution
--[no]trim_test_configuration डिफ़ॉल्ट: "सही": यह सुविधा चालू होने पर, बिल्ड के टॉप लेवल के नीचे जांच से जुड़े विकल्प हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को गैर-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में किए जाने वाले बदलावों की वजह से, टेस्ट न करने वाले नियमों का फिर से विश्लेषण नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state

--build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4": Bzel को एक तय सीमा तक, किसी बिल्ड इवेंट को दोबारा अपलोड करने की कोशिश करनी चाहिए.
टैग: bazel_internal_configuration
--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत": Targetखास इवेंट को पब्लिश करना है या नहीं.
--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत": अगर सही हो, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय BEP में फ़ाइलसेट बड़ा करें.
टैग: affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत": अगर सही हो, तो आउटपुट फ़ाइलों को प्रज़ेंट करते समय, बीईपी में मिलते-जुलते फ़ाइलसेट सिमलिंक को पूरी तरह ठीक करें. --प्रायोगिक_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s": बीईपी के अपलोड न हो पाने पर, शुरुआत में, एक्सपोनेन्शियल बैकऑफ़ के लिए कम से कम देरी. (exponent: 1.6)
टैग: bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: विवरण देखें: इसमें यह चुना जाता है कि बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को कैसे अपलोड किया जाए.
टैग: affects_outputs
--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "गलत": अगर पैरामीटर फ़ाइलों को मटीरियल के तौर पर बनाया जा रहा है, तो डिस्क पर सीधे लिखकर ऐसा करें.
टैग: execution
--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "गलत": रन बिल्ड इवेंट में कमांड-लाइन रेज़िड्यू को शामिल करना है या नहीं, जिसमें बचा हुआ पदार्थ शामिल हो सकता है. डिफ़ॉल्ट रूप से, बचा हुआ डेटा रन कमांड बिल्ड इवेंट में शामिल नहीं किया जाता है, जिसमें बचा हुआ पदार्थ शामिल हो सकता है.
टैग: affects_outputs
--experimental_skyfocus_dump_keys=<none, count or verbose> डिफ़ॉल्ट: "कोई नहीं": Sky फ़ोकस को डीबग करने के लिए. फ़ोकस की गई SkyKeys (रूट, लीफ़, फ़ोकस की गई डीप, फ़ोकस किए गए आरडेप) को हटाएं.
टैग: terminal_output
--[no]experimental_skyfocus_dump_post_gc_stats डिफ़ॉल्ट: "गलत": Sky फ़ोकस को डीबग करने के लिए. अगर इसे चालू किया जाता है, तो हीप के साइज़ को कम करने की रिपोर्ट करने के लिए फ़ोकस करने से पहले/बाद में, मैन्युअल जीसी को ट्रिगर करें. इससे स्काईफ़ोकस इंतज़ार का समय बढ़ जाएगा.
टैग: terminal_output
--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत": लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs
--explain=<a path> डिफ़ॉल्ट: विवरण देखें: इसकी वजह से बिल्ड सिस्टम, एक्ज़ीक्यूट किए गए हर चरण की जानकारी देता है. बताई गई लॉग फ़ाइल में ही इसकी जानकारी दी गई है.
टैग: affects_outputs
--[no]legacy_important_outputs डिफ़ॉल्ट: "सही": TargetComplete इवेंट में, लेगसी key_ बैज फ़ील्ड के लेगसी जनरेट होने की प्रोसेस को रोकने के लिए.
टैग: affects_outputs
--[no]materialize_param_files डिफ़ॉल्ट: "गलत": रिमोट ऐक्शन एक्ज़ीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें सेव करता है. कार्रवाइयों को डीबग करते समय उपयोगी होता है. यह --subcommands और --verbose_failures" से ज़ाहिर होता है.
टैग: execution
--max_config_changes_to_show=<an integer> डिफ़ॉल्ट: "3": बिल्ड के विकल्पों में बदलाव की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदली गई विकल्प के नामों की दी गई संख्या तक दिखती है. अगर दी गई संख्या -1 है, तो सभी बदले गए विकल्प दिखाए जाएंगे.
टैग: terminal_output
--max_test_output_bytes=<an integer> डिफ़ॉल्ट: "-1": हर टेस्ट-लॉग का ज़्यादा से ज़्यादा साइज़ तय करता है, जो तब उत्सर्जित हो सकता है, जब --test_OUT '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> डिफ़ॉल्ट: "0": चल रही जॉब की रिपोर्ट के बीच इंतज़ार करने का समय. डिफ़ॉल्ट वैल्यू 0 होने का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट होगी. इसके बाद, 30 सेकंड के बाद रिपोर्ट को हर मिनट में एक बार रिपोर्ट किया जाएगा. --curses चालू होने पर, प्रोग्रेस की हर सेकंड रिपोर्ट की जाती है.
टैग: affects_outputs
--show_result=<an integer> डिफ़ॉल्ट: "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> डिफ़ॉल्ट: "खास जानकारी": पसंदीदा आउटपुट मोड के बारे में बताता है. मान्य वैल्यू, सिर्फ़ टेस्ट स्टेटस की खास जानकारी के लिए 'खास जानकारी' होती हैं. फ़ेल हुए टेस्ट के लिए टेस्ट लॉग भी प्रिंट करने के लिए 'गड़बड़ियां', सभी जांच के लिए 'सभी' प्रिंट, और रीयल टाइम में सभी टेस्ट के लिए 'सभी' लॉग प्रिंट करने के लिए 'गड़बड़ी' होती है. इससे --test_strategy वैल्यू पर ध्यान दिए बिना, एक बार में एक बार टेस्ट किया जाएगा.
टैग: test_runner, terminal_output, execution
--test_summary=<short, terse, detailed, none or testcase> डिफ़ॉल्ट: "छोटा": टेस्ट की खास जानकारी का पसंदीदा फ़ॉर्मैट बताता है. मान्य वैल्यू, सिर्फ़ टेस्ट किए गए टेस्ट के बारे में जानकारी प्रिंट करने के लिए 'छोटा' होती हैं, सिर्फ़ असफल जांच के बारे में जानकारी प्रिंट करने के लिए 'शॉर्ट' होती हैं, फ़ेल हुए टेस्ट केस की पूरी जानकारी प्रिंट करने के लिए 'जानकारी', 'ज़्यादा जानकारी' होती है, टेस्ट केस रिज़ॉल्यूशन में जवाब प्रिंट करने के लिए 'टेस्टकेस', फ़ेल टेस्ट केस की पूरी जानकारी प्रिंट नहीं की जाती, और जवाब को मिटाने के लिए 'कोई नहीं' होता है.
टैग: terminal_output
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*": टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. फ़्लैग, रेगुलर एक्सप्रेशन को इस्तेमाल करता है. इसकी जांच टूलचेन टाइप और चुनिंदा टारगेट से की जाती है, ताकि यह पता लगाया जा सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है और फिर हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल है और यह सिर्फ़ टूलचेन रिज़ॉल्यूशन में विशेषज्ञों के काम का होगा.
टैग: terminal_output
--[no]verbose_explanations डिफ़ॉल्ट: "गलत": अगर --एक्सप्लेनेशंस चालू है, तो यह जारी किए गए एक्सप्लेनेशंस को ज़्यादा शब्दों में दिखाता है. अगर --एक्सप्लेनेशंस चालू नहीं है, तो इसका कोई असर नहीं होगा.
टैग: affects_outputs
--[no]verbose_failures डिफ़ॉल्ट: "गलत": अगर कोई निर्देश काम नहीं करता, तो पूरी कमांड लाइन प्रिंट कर लें.
टैग: 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> बार कई बार इस्तेमाल किया गया है: स्टारलार्क फ़्लैग के लिए, यह छोटा नाम सेट करता है. यह तर्क के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर होता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत": यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन जाएं. आम तौर पर, जब किसी py_binary या py_test टारगेट में lead_create_init को "ऑटो" (डिफ़ॉल्ट) पर सेट किया जाता है, तो यह 'गलत' के तौर पर तब ही माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही": अगर 'सही' है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स शामिल नहीं है. इसका मतलब है कि `bazel-bin` सुविधा का सिमलिंक, Python 2 के बजाय Python 3 के टारगेट को पॉइंट करेगा. अगर इस विकल्प को चालू किया जाता है, तो `--insupported_py3_is_default` को चालू करने का भी सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही": सही होने पर, `py_binary` और `py_test` एट्रिब्यूट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. अगर इस फ़्लैग को सेट किया जाता है, तो `--insupported_py2_OUTs_are_suffixed` को सेट करने का सुझाव भी दिया जाता है.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो एक्ज़ीक्यूटेबल नेटिव Python नियम, --python_top जैसे लेगसी फ़्लैग से दिए गए रनटाइम के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल करेंगे.
टैग: 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> डिफ़ॉल्ट: "": अगर सेट किया जाता है, तो बिल्ड कमांड लाइन के बजाय, यहां दी गई फ़ाइल के पैटर्न को पढ़ेगा. यहां फ़ाइल और कमांड लाइन पैटर्न के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs

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

--[no]allow_analysis_cache_discard डिफ़ॉल्ट: "सही": अगर बिल्ड सिस्टम में बदलाव की वजह से, विश्लेषण की कैश मेमोरी को खारिज किया जा रहा है, तो इस विकल्प को 'गलत है' पर सेट करने से, बैजल प्रोसेस जारी रखने के बजाय बाहर निकल जाएगा. 'discard_analysis_cache' के भी सेट होने पर, इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit
--[no]build_manual_tests डिफ़ॉल्ट: "गलत": इस नीति की मदद से, 'मैन्युअल' टैग किए गए टेस्ट टारगेट को हर हाल में बनाया जाता है. 'मैन्युअल' टेस्ट को प्रोसेस नहीं किया जाता. यह विकल्प उन्हें बनाने के लिए बाध्य करता है (लेकिन एक्ज़ीक्यूट नहीं करता).
--build_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: "": टैग की कॉमा-सेपरेटेड लिस्ट के बारे में बताता है. बाहर रखे गए टैग के बारे में बताने के लिए, हर टैग के शुरू में वैकल्पिक तौर पर '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे टारगेट बनाए जाएंगे जिनमें कम से कम एक टैग शामिल हो और उनमें बाहर रखा गया कोई टैग न हो. यह विकल्प 'टेस्ट' कमांड से लागू किए गए टेस्ट के सेट पर असर नहीं डालता. ये टेस्ट फ़िल्टर करने के विकल्पों से नियंत्रित होते हैं, जैसे कि '--test_tag_filters'
--[no]build_tests_only डिफ़ॉल्ट: "गलत": अगर निर्देश दिए गए हैं, तो सिर्फ़ *_test और test_suite के नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर दिए गए दूसरे टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई हर चीज़ बनाई जाएगी.
--[no]cache_test_results [-t] डिफ़ॉल्ट: "ऑटो": अगर यह नीति 'ऑटो' पर सेट है, तो Bazel फिर से टेस्ट तब करता है, जब: (1) Bazel को, जांच में हुए बदलाव या उसकी डिपेंडेंसी का पता चलता हो, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test की मदद से कई बार टेस्ट करने का अनुरोध किया गया हो या(4) जांच पहले असफल हो गई हो. अगर यह नीति 'हां' पर सेट है, तो बाहरी के तौर पर मार्क किए गए टेस्ट के अलावा, Bazel जांच के सभी नतीजों को कैश मेमोरी में सेव करेगा. अगर यह नीति 'नहीं' पर सेट है, तो Bazel जांच के किसी भी नतीजे को कैश मेमोरी में सेव नहीं करेगा.
--[no]compile_one_dependency डिफ़ॉल्ट: "गलत": आर्ग्यूमेंट फ़ाइलों की एक डिपेंडेंसी कंपाइल करें. यह IDE में सोर्स फ़ाइलों की सिंटैक्स की जांच करने के लिए फ़ायदेमंद है. उदाहरण के लिए, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर किसी सिंगल टारगेट को फिर से बनाया जा सकता है. यह तर्क, बिना फ़्लैग वाले सभी तर्कों की व्याख्या करने के तरीके पर असर डालता है. उन्हें टारगेट करने के बजाय, वे सोर्स फ़ाइल नाम हैं. हर सोर्स फ़ाइल के नाम के लिए, एक आर्बिट्रेरी टारगेट बनाया जाएगा. यह उस पर निर्भर करेगा.
--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 डिफ़ॉल्ट: "गलत": विश्लेषण के चरण पूरे होने के तुरंत बाद, विश्लेषण की कैश मेमोरी मिटा दें. इससे मेमोरी के इस्तेमाल को ~10% तक कम कर दिया जाता है. हालांकि, अगर बिल्ड धीरे-धीरे बढ़ रहा है, तो हो जाता है.
--execution_log_binary_file=<a path> डिफ़ॉल्ट: विवरण देखें: इस फ़ाइल में, एक्ज़ीक्यूट किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, लंबाई-डीलिमिटेड Spwnexe Protos के तौर पर लॉग करें. मिलते-जुलते फ़्लैग: --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_sort (क्या एक्ज़ीक्यूशन लॉग को क्रम से लगाना है), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--execution_log_json_file=<a path> डिफ़ॉल्ट: विवरण देखें: इस फ़ाइल में, एक्ज़ीक्यूट किए गए स्पॉन्स को src/main/protobuf/spawn.proto के मुताबिक, Spwn स्क्रिप्ट प्रोटोस के न्यूलाइन-डीलिमिटेड JSON रिप्रज़ेंटेशन के तौर पर लॉग करें. मिलते-जुलते फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_sort (क्या एक्ज़ीक्यूशन लॉग को क्रम से लगाना है), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--[no]execution_log_sort डिफ़ॉल्ट: "सही": एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं, जिससे उन लॉग की तुलना करना आसान हो जाता है जिन्हें शुरू किया जाता है. शुरू करने की प्रोसेस के आखिर में, सीपीयू और मेमोरी के अहम इस्तेमाल से बचने के लिए, 'गलत' पर सेट करें. ऐसा करने के लिए, नॉन-डिटर्मिनिस्टिक एक्ज़ीक्यूशन ऑर्डर में लॉग इन करें. सिर्फ़ बाइनरी और JSON फ़ॉर्मैट पर लागू होता है. कॉम्पैक्ट फ़ॉर्मैट को कभी भी क्रम से नहीं लगाया जाता.
--[no]expand_test_suites डिफ़ॉल्ट: "सही": विश्लेषण से पहले, test_Suite टारगेट को उनके कॉम्पोनेंट के टेस्ट में शामिल कर लिया जाए. डिफ़ॉल्ट रूप से यह फ़्लैग चालू होने पर, टेस्ट सुइट से जुड़े टेस्ट पर नेगेटिव टारगेट पैटर्न लागू नहीं होंगे. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड लाइन पर टॉप-लेवल के पहलू लागू किए जाते हैं: इसके बाद, वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis
--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत": सही होने पर, Blaze पहले सफल रन पर एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ इस्तेमाल करने पर ही काम करता है.
टैग: affects_outputs, loading_and_analysis
--experimental_execution_log_compact_file=<a path> डिफ़ॉल्ट: विवरण देखें: इस फ़ाइल में, एक्ज़ीक्यूट किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, लंबाई से अलग किए गए exeLogEntry Protos के तौर पर लॉग करें. पूरी फ़ाइल zstd कंप्रेस की गई है. इस फ़ॉर्मैट पर अभी प्रयोग किया जा रहा है और इस पर अभी काम चल रहा है. इसे किसी भी समय बदला जा सकता है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "": अब अलग-अलग पहलुओं के पक्ष में नहीं, बल्कि उनके सुझाव दिए गए हैं. एक्सटर्नल ऐक्शन को शेड्यूल करने के लिए टारगेट के सेट को फ़िल्टर करता है.
--[no]experimental_extra_action_top_level_only डिफ़ॉल्ट: "गलत": अब अलग-अलग पहलुओं के पक्ष में नहीं, बल्कि उनके सुझाव दिए गए हैं. सिर्फ़ टॉप लेवल के टारगेट के लिए, extra_actions को शेड्यूल करता है.
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो Bazel, कवरेज के दौरान हर टेस्ट के लिए पूरी कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "गलत": अगर सही है, तो क्लैंग के लिए कवरेज, एलसीओवी रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_j2objc_header_map डिफ़ॉल्ट: "सही": J2ObjC ट्रांसपिलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "गलत": छोटे हेडर पाथ के साथ जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग: affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javaBuilder": Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ चालू करें.
--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत": Android के साथ काम करने वाली लाइब्रेरी तक --experimental_run_android_lint_on_java_rules पर सीमित करें.
टैग: affects_outputs
--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत": Java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs
--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत": टेस्टरनर के डिप से गलती से डेटा हासिल करने के बजाय, java_test में JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ बैजल के लिए काम करता है.
--[no]fetch डिफ़ॉल्ट: "सही": निर्देश को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति देता है. अगर 'गलत है' पर सेट किया जाता है, तो यह निर्देश, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. कोई निर्देश मौजूद न होने पर, निर्देश काम नहीं करेगा.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: विवरण देखें: यह Java लॉन्चर, उन टूल में इस्तेमाल होता है जो बिल्ड होने के दौरान एक्ज़ीक्यूट होते हैं.
--host_javacopt=<a string> बार कई बार इस्तेमाल किया गया है: किसी बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल बनाते समय, javac को पास करने के ज़्यादा विकल्प.
--host_jvmopt=<a string> बार कई बार इस्तेमाल किया गया है: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, Java वीएम को पास करने के ज़्यादा विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही": अगर सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि उसके पाथ में फ़ाइल को TEST_SHARD_STATUS_FILE में जोड़ा जा सकता है, तो Bazel शार्ड किए गए टेस्ट को फ़ेल कर देगा. गलत होने पर, अगर शार्डिंग की सुविधा काम नहीं करती, तो टेस्ट रनर की वजह से हर शार्ड में सभी टेस्ट चल रहे होंगे.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही": अगर सही है, तो सैंडबॉक्स रणनीति की मदद से खास टेस्ट चलाए जाएंगे. सिर्फ़ स्थानीय स्तर पर टेस्ट चलाने के लिए 'लोकल' टैग जोड़ें
टैग: incompatible_change
--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत": अगर सही है, तो 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_internal=streamed को शामिल किया गया है.
इसमें शामिल है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps डिफ़ॉल्ट: "सही": हर Java टारगेट के लिए डिपेंडेंसी जानकारी (अभी, कंपाइल-टाइम क्लासपाथ) जनरेट करें.
--[no]java_header_compilation डिफ़ॉल्ट: "सही": सीधे सोर्स से जरार इकट्ठा करें.
--java_language_version=<a string> डिफ़ॉल्ट: "": जावा भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: विवरण देखें: Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर यह फ़्लैग खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": जावा रनटाइम वर्शन
--javacopt=<a string> बार कई बार इस्तेमाल किया गया है: javac पर भेजने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> बार कई बार इस्तेमाल किया गया है: Java वीएम को पास करने के दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: विवरण देखें: ऐसी क्लास की सूची जनरेट करने के लिए बाइनरी के बारे में बताता है जिसका इस्तेमाल लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य dex में होना चाहिए.
--local_termination_grace_seconds=<an integer> डिफ़ॉल्ट: "15": टाइम आउट की वजह से लोकल प्रोसेस को बंद करने और उसे तेज़ी से बंद करने के बीच इंतज़ार करने का समय.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: विवरण देखें: बिना शार्डिंग के डेक्सिंग करने के लिए, बाइनरी के बारे में बताता है.
--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल जिसमें C++ Protos को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल जिसमें Java Protos को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@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 डिफ़ॉल्ट: "गलत": अगर सही हो, तो कम से कम एक रन/अटेंप्ट में पास होने पर और कम से कम एक रन/अटैम फ़ेल होने पर उसे 'फ़्लेकी' स्टेटस मिल जाता है.
--shell_executable=<a path> डिफ़ॉल्ट: विवरण देखें: BZel के इस्तेमाल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को पहले Bazel सर्वर पर सेट किया गया है, जो Bazel सर्वर को शुरू करता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करेगा. यह उस ऑपरेटिंग सिस्टम के हिसाब से तय होगा जिस पर वह चलता है (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash). ध्यान दें कि अगर किसी ऐसे शेल का इस्तेमाल किया जाता है जो बैश के साथ काम नहीं करता, तो जनरेट की गई बाइनरी के रनटाइम या रनटाइम फ़ेल हो सकते हैं.
टैग: loading_and_analysis
--[no]show_loading_progress डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो Bazel "Loadingpackage:" मैसेज प्रिंट करेगा.
--test_arg=<a string> बार कई बार इस्तेमाल किया गया है: उन अतिरिक्त विकल्पों और तर्क के बारे में बताता है जिन्हें टेस्ट एक्ज़ीक्यूटेबल के लिए पास किया जाना चाहिए. अलग-अलग आर्ग्युमेंट का इस्तेमाल करने के लिए, एक से ज़्यादा बार इस्तेमाल किया जा सकता है. अगर कई जांच की जाती हैं, तो सभी को एक जैसे तर्क मिलेंगे. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
--test_filter=<a string> डिफ़ॉल्ट: विवरण देखें: टेस्ट फ़्रेमवर्क पर भेजने के लिए एक फ़िल्टर तय करता है. इसका इस्तेमाल, जांच को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे बनाए गए टारगेट पर कोई असर नहीं पड़ता.
--test_lang_filters=<comma-separated list of options> डिफ़ॉल्ट: "": जांच के लिए इस्तेमाल की जाने वाली भाषाओं की ऐसी सूची होती है जिसे कॉमा लगाकर अलग किया जाता है. बाहर रखी गई भाषाओं के बारे में बताने के लिए, हर भाषा के पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे जांच टारगेट दिखेंगे जो खास भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया जाने वाला नाम, *_test नियम में मौजूद भाषा के शुरुआती नाम से मेल खाना चाहिए. जैसे, 'cc', 'java', 'py' वगैरह में से कोई एक. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": यह विकल्प अब काम नहीं करता और इसका कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत": टेस्ट रनर पर तेज़ी से फ़ॉरवर्ड करने का विकल्प फ़ेल हो गया. पहली बार असफल होने पर, टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "अश्लील": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'साफ़ तौर पर' शार्डिंग का इस्तेमाल सिर्फ़ तब करें, जब 'sard_count' BUILD एट्रिब्यूट मौजूद हो. टेस्ट शार्डिंग का इस्तेमाल कभी नहीं करने के लिए 'बंद' है. 'forced=k' की मदद से, जांच के लिए 'k' शार्ड लागू किए जा सकते हैं, भले ही 's आम तौर पर काउंट' BUILD एट्रिब्यूट कुछ भी हो.
--test_size_filters=<comma-separated list of values: small, medium, large or enormous> डिफ़ॉल्ट: "": टेस्ट साइज़ की कॉमा-सेपरेटेड लिस्ट के बारे में बताता है. शामिल न किए गए साइज़ के बारे में बताने के लिए, हर साइज़ के पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक साइज़ शामिल होगा और उनमें कोई बाहर रखा गया साइज़ नहीं होगा. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: "": टेस्ट टैग की ऐसी सूची के बारे में बताता है जिसे कॉमा लगाकर अलग किया गया है. बाहर रखे गए टैग के बारे में बताने के लिए, हर टैग के शुरू में वैकल्पिक तौर पर '-' का इस्तेमाल किया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक टैग शामिल होगा और जिनमें बाहर रखा गया कोई भी टैग मौजूद नहीं होगा. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: "": यह नीति, जांच के टाइम आउट की ऐसी सूची के बारे में बताती है जिसे कॉमा लगाकर अलग किया गया है. बाहर रखे गए टाइम आउट के बारे में बताने के लिए, हर टाइम आउट से पहले वैकल्पिक रूप से '-' लगाया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक टाइम आउट शामिल है और जिनमें बाहर रखा गया कोई भी टाइम आउट नहीं है. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--tool_java_language_version=<a string> डिफ़ॉल्ट: "": जावा भाषा का वर्शन, जिसका इस्तेमाल उन टूल को चलाने के लिए किया जाता है जो बिल्ड बनाने के दौरान ज़रूरी होते हैं
--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11": बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन
--[no]use_ijars डिफ़ॉल्ट: "सही": अगर यह विकल्प चालू है, तो इस विकल्प की वजह से Java कंपाइलेशन में इंटरफ़ेस जार का इस्तेमाल होता है. इससे, कंपाइलेशन तेज़ी से बढ़ेगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

कैननिकल फ़्लैग वाले यूआरएल के विकल्प

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

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

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

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

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

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

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

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

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

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

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

टैग: host_machine_resource_optimizations

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

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

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

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

Cquery के विकल्प

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव": आउटपुट फ़ॉर्मैट {xml,proto,record} में होने पर, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को कैसे ठीक करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान किए गए सभी पहलू डिपेंडेंसी जोड़े जाते हैं. इस बात से कोई फ़र्क़ नहीं पड़ता कि उन्हें डायरेक्ट डिपेंडेंसी के नियम की क्लास दी गई है या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी के नियम क्लास के आधार पर संभावित तौर पर ऐक्टिव हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट का आकलन करने के लिए, दूसरे पैकेज को लोड करना ज़रूरी है. इससे यह अन्य मोड की तुलना में धीमा हो जाएगा. इस बात का भी ध्यान रखें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में तय किया जाता है. यह प्रोसेस, 'बैजल क्वेरी' के दौरान नहीं चलाई जाती.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से लेबल निकलते हैं, जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन का इस्तेमाल किया जाता है. यह उन टूल के लिए फ़ायदेमंद है जिन्हें नियमों से निकलने वाले अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इसे चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैटर, आउटपुट को ज़्यादा पढ़ने लायक बनाने के बजाय, साफ़ तौर पर रिपॉज़िटरी के नाम (मुख्य डेटा स्टोर करने की जगह के हिसाब से) का इस्तेमाल कर सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]graph:factored डिफ़ॉल्ट: "सही": अगर सही है, तो ग्राफ़ पर 'फ़ैक्टर' उत्सर्जित होगा. इसका मतलब है कि टॉपॉलॉजिकल रूप से समान नोड एक साथ मर्ज कर दिए जाएंगे और उनके लेबल जोड़े जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> डिफ़ॉल्ट: "512": आउटपुट में ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल में काट-छांट की जाएगी; -1 का मतलब है कि कोई काट-छांट नहीं होगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel से जोड़ा गया है. cquery के लिए यह विकल्प, समाधान किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_aspects डिफ़ॉल्ट: "सही": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, इसके पहले `//` को हटाया नहीं जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "गलत": अगर सेट और --universe_scope सेट नहीं है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई, --universe_scope वैल्यू आपकी पसंद के मुताबिक नहीं हो सकती. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है (यानी `cquery` नहीं).
टैग: loading_and_analysis
--[no]line_terminator_null डिफ़ॉल्ट: "गलत": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म करना है.
टैग: terminal_output
--[no]nodep_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो "nodep" एट्रिब्यूट के डिपेंस को उस डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics
--output=<a string> डिफ़ॉल्ट: "लेबल": वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_ kind, textproto, migrations, proto, टैग किए गए प्रोटो, jsonproto. अगर आपने 'transitions' चुना है, तो आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": सही होने पर, उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": definition_stack प्रोटो फ़ील्ड को भरें, जो नियम की क्लास तय होने के समय Starlark कॉल स्टैक के हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो select() से बनाए गए कॉन्फ़िगर करने लायक एट्रिब्यूट बराबर हो जाते हैं. सूची टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप की वैल्यू शून्य हो जाती है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स पहलू के साथ भरें जिससे एट्रिब्यूट मिला है (अगर ऐसा नहीं है, तो खाली स्ट्रिंग).
टैग: terminal_output
--[no]proto:include_configurations डिफ़ॉल्ट: "सही": चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत": $internal_attr_has एट्रिब्यूट का हिसाब लगाना है या नहीं, इसका पता लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत": हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग: terminal_output
--[no]proto:locations डिफ़ॉल्ट: "सही": प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "सभी": आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. कोई एट्रिब्यूट आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर क्वेरी को सेट किया जाता है, तो कमांड लाइन के बजाय, यहां दी गई फ़ाइल का नाम पढ़कर सुनाया जाएगा. यहां फ़ाइल और कमांड लाइन क्वेरी के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक ऐब्सलूट पाथ होता है और यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--show_config_fragments=<off, direct or transitive> डिफ़ॉल्ट: "बंद": नियम और उसकी ट्रांज़िटिव डिपेंडेंसी के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट दिखाता है. इससे, यह आकलन करने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ में कितने हिस्से में काट-छांट की जा सकती है.
टैग: affects_outputs
--starlark:expr=<a string> डिफ़ॉल्ट: "": कॉन्फ़िगर किए गए हर टारगेट को cquery के --OUT=starlark मोड में फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट 'टारगेट' से जुड़ा है. अगर --starlark:expr या --starlark:file तय नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट होगा. --starlark:expr और --starlark:file दोनों देते समय कोई गड़बड़ी हुई है.
टैग: terminal_output
--starlark:file=<a string> डिफ़ॉल्ट: "": स्टारलार्क फ़ंक्शन को तय करने वाली फ़ाइल का नाम, जिसे 'फ़ॉर्मैट' कहा जाता है. यह एक तर्क का होता है. इसे कॉन्फ़िगर किए गए हर टारगेट पर लागू करके, एक स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. --starlark:expr और --starlark:file दोनों देते समय कोई गड़बड़ी हुई है. ज़्यादा जानकारी के लिए --आउटपुट=स्टारलार्क के लिए सहायता देखें.
टैग: terminal_output
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: बंद होने पर, क्वेरी को ऑपरेट करने वाले डिपेंडेंसी ग्राफ़ में 'exec कॉन्फ़िगरेशन' की डिपेंडेंसी शामिल नहीं होंगी. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसा कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक जाता है. आम तौर पर, यह एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल को पॉइंट करता है. Cquery: यह विकल्प बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट exec कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए exec टारगेट दिखाए जाएंगे. इस विकल्प में ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग: build_file_semantics
--transitions=<full, lite or none> डिफ़ॉल्ट: "कोई नहीं": वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगा.
टैग: affects_outputs
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा और घटाव). क्वेरी को यूनिवर्स में परफ़ॉर्म किया जा सकता है. इसके लिए, दिए गए टारगेट को हमेशा के लिए बंद करना होगा. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माने जाते हैं. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए, इस विकल्प को तय न करने से बिल्ड में रुकावट आ सकती है.
टैग: loading_and_analysis

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "गलत": सिमलिंक ट्री बनाने के लिए, डायरेक्ट फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "गलत": कर्मचारियों की मदद से, परसिस्टेंट Aar एक्सट्रैक्टर चालू करें.
टैग: execution
--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "गलत": सोर्स मेनिफ़ेस्ट कार्रवाइयों को फिर से चालू करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "गलत": अगर सही है, तो Bazel एक नए स्पॉन में टेस्ट के लिए, कवरेज पोस्टप्रोसेसिंग करेगा.
टैग: execution
--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री को ट्रैवर्स नहीं करेंगे या सिमलिंक के प्रति संवेदनशील नहीं होंगे.
टैग: execution
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> डिफ़ॉल्ट: "": गतिविधियों की जानकारी के आधार पर, उस कार्रवाई के काम करने के तरीके की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो स्क्रिप्ट को चलाने की जानकारी देती हैं. कई सामान्य कार्रवाइयां, एक्ज़ीक्यूशन की जानकारी के साथ काम करती हैं, जैसे कि Genroll, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, ऑर्डर अहम हो जाता है, क्योंकि एक ही मिनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' जोड़ता है और 'y' से हटा देता है. जेनरूल की सभी कार्रवाइयों के लिए, 'Genroll=+requires-x' को लागू करने की जानकारी में 'requires-x' जोड़ता है. '(?!GenTerms).*=-requires-x', सभी गैर-सामान्य कार्रवाइयों के लिए, निष्पादन जानकारी से '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=workerhost_machine_resource_optimizationsexecution
--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{/2/}

--modify_execution_info=AARGenerator=+supports-multiplex-workershost_machine_resource_optimizationsexecution
--persistent_multiplex_android_tools: परसिस्टेंट और मल्टीप्लेक्स किए गए Android टूल (डेक्सिंग, डिस्यूगरिंग, रिसॉर्स प्रोसेसिंग) चालू करें.
इसमें शामिल है:
  --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 डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो Bazel, टेस्ट एक्ज़ेक्यूटिव ग्रुप के बजाय, टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: विवरण देखें: Android का टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_crosstool_top=<a build target label> डिफ़ॉल्ट: "//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> डिफ़ॉल्ट: "": यह नीति उन प्लैटफ़ॉर्म को सेट करती है जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी एक फ़ैट APKs होती है, जिसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--android_sdk=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk": Android SDK टूल/प्लैटफ़ॉर्म के बारे में बताता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain": Apple और Objc नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> डिफ़ॉल्ट: "": कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: विवरण देखें: टारगेट इकट्ठा करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger": रॉ कवरेज रिपोर्ट को पोस्ट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. यह फ़िलहाल एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcow_merger' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> डिफ़ॉल्ट: "@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> डिफ़ॉल्ट: "@bazel_tools//tools/test:कवरेज_support": सहायता फ़ाइलों की वह जगह जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई के इनपुट के लिए ज़रूरी होती है. डिफ़ॉल्ट रूप से '//tools/test:coverage_support' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: विवरण देखें: यह तय करता है कि कस्टम मैलक लागू किया जाए या नहीं. यह सेटिंग, बिल्ड के नियमों में मॉलक एट्रिब्यूट को बदल देती है.
टैग: 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 डिफ़ॉल्ट: "गलत": अगर यह नीति सेट है, तो हर Xcode कार्रवाई के लिए "requires-xcode:{version}" का इस्तेमाल करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" चलाने की ज़रूरत भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution
--[no]experimental_prefer_mutual_xcode डिफ़ॉल्ट: "सही": अगर सही है, तो सबसे हाल का Xcode इस्तेमाल करें जो स्थानीय और कहीं से भी उपलब्ध हो. अगर यह गलत है या कोई भी म्यूचुअली उपलब्ध वर्शन नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state
--extra_execution_platforms=<comma-separated list of options> डिफ़ॉल्ट: "": ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन प्लैटफ़ॉर्म को वर्कस्पेस फ़ाइल में रजिस्टर_execution_platforms() के ज़रिए एलान किए गए प्लैटफ़ॉर्म से पहले लागू किया जाएगा. यह विकल्प सिर्फ़ एक बार सेट किया जा सकता है; बाद के इंस्टेंस पहले के फ़्लैग की सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन में ध्यान दिए जाने वाले नियम. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन टूलचेन का इस्तेमाल, workspace_toolchains() के ज़रिए वर्कSPACE फ़ाइल में बताए गए टूल से पहले किया जाता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: विवरण देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. क्रॉसटूल टूलचेन में डिफ़ॉल्ट वैल्यू को चुना जाता है और आपको इसे बदलने की ज़रूरत नहीं पड़ती.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: विवरण देखें: बिना किसी बटन वाला फ़्लैग. इसे आने वाली रिलीज़ से हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: विवरण देखें: अगर इसके बारे में बताया गया है, तो यह सेटिंग exec कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> डिफ़ॉल्ट: "@local_config_platform//:host": प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही": अगर सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'nonhost' सुविधाओं को चालू नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_android_toolchain_resolution डिफ़ॉल्ट: "सही": Android के नियमों (Starlark और निजी) के लिए Android SDK चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "गलत": Apple के नियमों (Starlark और निजी) के लिए, Apple SDK चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--[no]incompatible_remove_legacy_whole_archive डिफ़ॉल्ट: "सही": अगर सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_require_ctx_in_configure_features डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "गलत": सही होने पर, एक्ज़ीक्यूटेबल के लिए स्ट्रिप से जुड़ी कार्रवाई में फ़्लैग -x का इस्तेमाल किया जाएगा, जो डाइनैमिक सिंबल के रिज़ॉल्यूशन को नहीं तोड़ता है.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects डिफ़ॉल्ट: "सही": अगर टूलचेन के साथ काम करने वाला इंटरफ़ेस शेयर किया गया ऑब्जेक्ट है, तो उसका इस्तेमाल करें. फ़िलहाल, यह सेटिंग सभी ELF टूलचेन में काम करती है.
टैग: 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> डिफ़ॉल्ट: "": मैपिंग फ़ाइल की जगह, जो बताती है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं किया गया है, तो किस प्लैटफ़ॉर्म का इस्तेमाल किया जाए या पहले से मौजूद प्लैटफ़ॉर्म पर कौनसे फ़्लैग सेट किए जाएं. मुख्य फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता होना चाहिए. यह डिफ़ॉल्ट रूप से 'platform_mappings' (फ़ाइल फ़ोल्डर रूट के तहत आने वाली फ़ाइल) पर सेट होता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> डिफ़ॉल्ट: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python2_path=<a string> डिफ़ॉल्ट: विवरण देखें: अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से बंद कर दिया गया है.
टैग: no_op, deprecated
--python3_path=<a string> डिफ़ॉल्ट: विवरण देखें: अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से बंद कर दिया गया है.
टैग: no_op, deprecated
--python_path=<a string> डिफ़ॉल्ट: विवरण देखें: Python अनुवादक के ऐब्सलूट पाथ को टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains ने इसे बंद किया है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: विवरण देखें: Python इंटरप्रेटर को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains ने इसे बंद किया है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: यह tvOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, tvOS ऐप्लिकेशन बनाने के लिए किया जाएगा. इसकी जानकारी न होने पर, 'xcode_version' से tvOS के SDK टूल का डिफ़ॉल्ट वर्शन इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: WatchOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट WatchOS SDK वर्शन इस्तेमाल करता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: विवरण देखें: अगर बताया गया है, तो सही बिल्ड ऐक्शन के लिए दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर इसकी जानकारी नहीं दी गई है, तो Xcode के एक्ज़ीक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes": xcode_config नियम का लेबल. इसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन को चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत": डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build_runfile_links डिफ़ॉल्ट: "सही": अगर सही है, तो रनफ़ाइल बनाने के लिए सभी टारगेट के लिए जंगलों को आपस में लिंक किया जाता है. अगर यह गलत है, तो इन्हें सिर्फ़ तब लिखें, जब ज़रूरी हो. इसके लिए, किसी स्थानीय कार्रवाई, टेस्ट या रन कमांड का इस्तेमाल करें.
टैग: affects_outputs
--[no]build_runfile_manifests डिफ़ॉल्ट: "सही": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर गलत है, तो उन्हें मिटा दें. गलत होने पर लोकल टेस्ट नहीं चलाए जाएंगे.
टैग: affects_outputs
--[no]build_test_dwp डिफ़ॉल्ट: "गलत": यह सुविधा चालू होने पर, स्टैटिक और फ़िशन के साथ C++ टेस्ट बनाने पर, टेस्ट बाइनरी के लिए भी .dwp फ़ाइल अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h": cc_proto_library से बनाई जाने वाली हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc": cc_proto_library से बनाई जाने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत": Proto_library में, वैकल्पिक Java api वर्शन के लिए अतिरिक्त कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_proto_extra_actions डिफ़ॉल्ट: "गलत": Proto_library में, वैकल्पिक Java api वर्शन के लिए अतिरिक्त कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत": चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को, कंपाइलेशन के आउटपुट के तौर पर सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> डिफ़ॉल्ट: "नहीं": यह बताता है कि C++ के कंपाइलेशन और लिंक के लिए कौनसे कंपाइलेशन मोड, फ़्रैशन का इस्तेमाल करते हैं. यह सभी मोड चालू करने के लिए, {'Fastbuild', 'dbg', 'opt'} या विशेष वैल्यू 'yes' का कोई भी कॉम्बिनेशन हो सकता है और सभी मोड बंद करने के लिए 'no' का कोई भी कॉम्बिनेशन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही": सही होने पर, नेटिव नियम अपनी रनफ़ाइल में <code>DefaultInfo.files</code> डेटा डिपेंडेंसी जोड़ देते हैं. यह Starlark के नियमों (https://bazel.build/extending/rules#runfiles_features_to_avoid) के लिए सुझाए गए तरीके से मेल खाता है.
टैग: affects_outputs, incompatible_change
--[no]legacy_external_runfiles डिफ़ॉल्ट: "सही": अगर सही हो, तो रनफ़ाइल/डेटा स्टोर करने की जगह के लिए .runfiles/wsname/external/repo (.runfiles/repo) के अलावा, बाहरी डेटा स्टोर करने की जगहों के लिए, जंगलों को सिमलिंक करने वाला जंगल बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत": यह बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps डिफ़ॉल्ट: "गलत": अगर यह नीति सेट की जाती है, तो 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> डिफ़ॉल्ट: "armeabi-v7a": Android टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]android_databinding_use_androidx डिफ़ॉल्ट: "सही": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटाबाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "सही": Android डेटाबाइंडिंग v2 का इस्तेमाल, 3.4.0 आर्ग्युमेंट के साथ करें. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद": इससे तय होता है कि जब कोई cc_binary साफ़ तौर पर शेयर की गई लाइब्रेरी नहीं बनाती है, तो Android के नियमों के C++ डिप डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बैजल यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "वर्णमाला": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्ज़ेक्रूट के पाथ के हिसाब से क्रम में लगाया गया है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में, कॉन्फ़िगरेशन डायरेक्ट्री के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आने वाले क्रम में लगाया जाता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत": यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए रिसॉर्स को कम करने की सुविधा को चालू करती है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip डिफ़ॉल्ट: "ऑटो": Python के लिए एक्ज़ीक्यूटेबल ज़िप बनाएं. Windows पर, दूसरे प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs
--catalyst_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple Catalyst बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage डिफ़ॉल्ट: "गलत": अगर यह बताया जाता है, तो Bazel इंस्ट्रुमेंट कोड का इस्तेमाल करेगा और जहां तक मुमकिन हो, ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करेगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी भी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसकी जगह, 'bazel profile' निर्देश का इस्तेमाल करना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "Fastbuild": वह मोड तय करें जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> बार कई बार इस्तेमाल किया गया है: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> बार कई बार इस्तेमाल किया गया है: जीसीसी को पास करने के दूसरे विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> डिफ़ॉल्ट: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: विवरण देखें: सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करके, कंपाइलेशन ऑप्टिमाइज़ करें. उस ZIP फ़ाइल के पूरे पाथ का नाम बताएं जिसमें प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल हो.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: विवरण देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंटेशन से बाइनरी जनरेट करें. 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> बार कई बार इस्तेमाल किया गया है: हर --तय करें विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, आखिरी वैल्यू जीत जाती है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "डिफ़ॉल्ट": इससे तय होता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह चुनेगा कि उसे डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही": अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_runfiles डिफ़ॉल्ट: "ऑटो": रनफ़ाइल सिमलिंक ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows और दूसरे प्लैटफ़ॉर्म पर बंद है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> बार कई बार इस्तेमाल किया गया है: अब अलग-अलग पहलुओं के पक्ष में नहीं, बल्कि उनके सुझाव दिए गए हैं. मौजूदा बिल्ड ऐक्शन में अतिरिक्त_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत": APK में Java रिसॉर्स को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही": Android Databinding v2 का इस्तेमाल करें. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत": यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए रिसॉर्स को कम करने की सुविधा को चालू करती है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत": dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत": अगर इसके बारे में बताया जाता है, तो Bazel, जनरेट की गई फ़ाइलों के लिए कवरेज की जानकारी भी जनरेट करेगा.
टैग: affects_outputs
--experimental_objc_fastbuild_options=<comma-separated list of options> डिफ़ॉल्ट: "-O0,-DDEBUG=1": यह स्ट्रिंग, objc फ़ास्ट बिल्ड कंपाइलर के विकल्पों के तौर पर इस्तेमाल करती है.
टैग: action_command_lines
--[no]experimental_omitfp डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो स्टैक करने के लिए libunwind का इस्तेमाल करें. साथ ही, इसे -fomit-frame-Pointer और -fasynchronous-unwind-tables की मदद से कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> डिफ़ॉल्ट: "बंद": आउटपुट ट्री नियम में, आउटपुट लिखने के लिए किस मॉडल का इस्तेमाल करना चाहिए, खास तौर से मल्टी-प्लैटफ़ॉर्म या मल्टी-कॉन्फ़िगरेशन वाले बिल्ड के लिए. इस पर प्रयोग बहुत ज़्यादा किया जा रहा है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 देखें. स्टारलार्क कार्रवाइयां, '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 फ़ॉर्मैट में होनी चाहिए, जहां लेबल किसी प्लैटफ़ॉर्म के बारे में बताता है. साथ ही, आउटपुट पाथ में इस्तेमाल करने के लिए वैल्यू, पसंदीदा छोटा नाम है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_छिपने वाली यूआरएल सही से काम कर रही हो. नाम की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए छोटा नाम इस्तेमाल किया जाता है. सटीक स्कीम, एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है. सबसे पहले, बहुत कम मामलों में --platforms विकल्प में कोई एक वैल्यू नहीं होती. इसलिए, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए किसी छोटे नाम को --experimental_override_name_platform_in_इस_क्रिएटर ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_ बदलें_direct_legacy_heur होंगी, तो मौजूदा प्लैटफ़ॉर्म के लेबल के हिसाब से छोटे नाम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल आखिरी विकल्प के तौर पर किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत": अगर इसके बारे में बताया गया है, तो पेज पर इकट्ठा करने के लिए कोड इकट्ठा करने की सुविधा चालू होने पर, Bazel, gcov के बजाय llvm-cov कवरेज वाले मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic डिफ़ॉल्ट: "सही": कृपया इस फ़्लैग का इस्तेमाल, माइग्रेट करने या टेस्टिंग की सुझाई गई रणनीति के हिस्से के तौर पर ही करें. ध्यान दें कि अनुभव से जुड़े डेटा में कमियां हैं और हमारा सुझाव है कि सिर्फ़ --experimental_override_name_platform_in_इसी आउटपुट_डायर का इस्तेमाल करके माइग्रेट करें.
टैग: affects_outputs, experimental
--fat_apk_cpu=<comma-separated set of options> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "गलत": बिना किसी बटन वाला फ़्लैग. इसे आने वाली रिलीज़ से हटा दिया जाएगा.
टैग: no_op
--fdo_instrument=<a string> डिफ़ॉल्ट: विवरण देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर की मदद से, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान, डंप किया जाएगा.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: विवरण देखें: कम्यूनिटी को ऑप्टिमाइज़ करने के लिए, एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री, ऑटो प्रोफ़ाइल वाली 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 डिफ़ॉल्ट: "गलत": अगर यह सेटिंग चालू होती है, तो सभी 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> डिफ़ॉल्ट: "ऑप्ट": वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल होंगे. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> बार कई बार इस्तेमाल किया गया है: एक्ज़ीक्यूशन कॉन्फ़िगरेशन में C (लेकिन C++ नहीं) सोर्स फ़ाइलों को कंपाइल करते समय, C कंपाइलर को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> बार कई बार इस्तेमाल किया गया है: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के दूसरे विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> डिफ़ॉल्ट: "": होस्ट के लिए सीपीयू.
टैग: 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> बार कई बार इस्तेमाल किया गया है: exec कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का एक और विकल्प.
टैग: 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/ में bar.cc. को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन जोड़ता है.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "गलत": चालू होने पर, किसी नियम से इस्तेमाल की जाने वाली हर टूलचेन के लिए, एक एक्ज़ेक्यूटिव ग्रुप अपने-आप बन जाता है. यह नियम काम करे, इसके लिए कार्रवाइयों पर `toolchain` पैरामीटर तय करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 देखें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही": अगर सही है, तो जेनफ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets डिफ़ॉल्ट: "गलत": कवरेज की सुविधा चालू होने पर, इससे पता चलता है कि टेस्ट के नियमों को लागू करने पर विचार करना है या नहीं. यह नीति सेट होने पर, --instrumentation_filter से शामिल किए गए टेस्ट नियम लागू होते हैं. ऐसा न होने पर, टेस्ट के नियमों को कवरेज इंस्ट्रुमेंटेशन से हमेशा बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/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_ऐप्लिकेशन बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें बताए गए सभी आर्किटेक्चर शामिल हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive डिफ़ॉल्ट: "सही": अब काम नहीं करता, इसकी जगह ले ली गई है --insupported_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> बार कई बार इस्तेमाल किया गया है: एलटीओ बैकएंड चरण को पास करने का एक और विकल्प (--features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> बार कई बार इस्तेमाल किया गया है: एलटीओ को इंडेक्स करने के चरण को पास करने का एक और विकल्प (-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 डिफ़ॉल्ट: "गलत": अगर यह नीति सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --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 बैकएंड (-features=thin_lto के तहत) को चुनिंदा तरीके से पास करने के अन्य विकल्प. यह विकल्प कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां रेगुलर एक्सप्रेशन फ़िल्टर, शामिल किए गए और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची दिखाता है. 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> डिफ़ॉल्ट: विवरण देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, प्रोपेलर प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोपेलर प्रोफ़ाइल में कम से कम एक फ़ाइल होनी चाहिए. एक cc प्रोफ़ाइल और ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल स्वीकार करता है, जिसे प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, a/b/BUILD: मिटा देने वाली फ़ाइल का लेबल तय करने वाली BUILD फ़ाइल, जो कि a/b/BUILD: मिटानी-बढ़ाने से जुड़ी जानकारी( name = "propler_profile", cc_profile = "propler_cc_profile.txt", ld_profile = "profiller_ld_profile.txt",) में लेबल को परिभाषित करने वाली BUILD फ़ाइल हो सकती है. Export_files डायरेक्टिव को, Bazel को दिखाने के लिए संबंधित पैकेज में जोड़ना पड़ सकता है. विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --propler_optimize=//a/b:propler_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: विवरण देखें: प्रोपेलर ऑप्टिमाइज़ किए गए बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: विवरण देखें: प्रोपेलर ऑप्टिमाइज़ किए गए बिल्ड के लिए ld_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: विवरण देखें: 'जांच करें' और 'रन' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले शामिल करने के लिए उपसर्ग. अगर वैल्यू '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 डिफ़ॉल्ट: "सही": अगर सही है, तो एक जैसी काम करने वाली नेटिव लाइब्रेरी, अलग-अलग टारगेट के बीच शेयर की जाएंगी
टैग: loading_and_analysis, affects_outputs
--[no]stamp डिफ़ॉल्ट: "गलत": तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह के साथ बाइनरी बनाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह बताता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं ("-Wl,--strip-debug" का इस्तेमाल करके). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि स्ट्रिप iff --compilation_mode=foundbuild.
टैग: affects_outputs
--stripopt=<a string> बार कई बार इस्तेमाल किया गया है: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs
--tvos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple tvOS बाइनरी बनाने हैं.
टैग: loses_incremental_state, loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाला tvOS वर्शन. अगर इसकी जानकारी नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state
--visionos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple visionOS बाइनरी बनाने हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, स्मार्टवॉच के कम से कम वर्शन के साथ काम करने वाला वर्शन. अगर इसकी जानकारी नहीं दी गई है, तो 'watchos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: विवरण देखें: डेटा कंपाइलेशन ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_ड़ियों/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू होते हैं, जैसे कि xbinary_fdo को कभी तय नहीं किया गया हो.
टैग: affects_outputs

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: "": Environment_group का एलान करें, ताकि target_environment वैल्यू के लिए सीपीयू वैल्यू को अपने-आप मैप करने के लिए, इसका इस्तेमाल किया जा सके.
टैग: changes_inputs, loading_and_analysis, experimental
--[no]check_licenses डिफ़ॉल्ट: "गलत": इस बात की जांच करें कि डिपेंडेंट पैकेज ने जो लाइसेंसिंग पाबंदियां लगाई हैं वे बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर न डाल रही हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग: build_file_semantics
--[no]check_visibility डिफ़ॉल्ट: "सही": यह सेटिंग बंद होने पर, टारगेट डिपेंडेंसी में 'किसको दिखे' सेटिंग से जुड़ी गड़बड़ियां, चेतावनियों के तौर पर मार्क हो जाती हैं.
टैग: build_file_semantics
--[no]desugar_for_android डिफ़ॉल्ट: "सही": डेक्सिंग से पहले, Java 8 बाइटकोड को डिसुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs डिफ़ॉल्ट: "गलत": लेगसी डिवाइसों के लिए, ऐप्लिकेशन में काम करने वाली Java 8 लाइब्रेरी शामिल करनी है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints डिफ़ॉल्ट: "सही": यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर कोई टारगेट ऐसी डिपेंडेंसी है जो एक जैसे एनवायरमेंट के साथ काम नहीं करती, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps डिफ़ॉल्ट: "सही": 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> डिफ़ॉल्ट: "डिफ़ॉल्ट": सही होने पर, यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए जाने वाले सभी टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "गलत": अगर यह सुविधा चालू है, तो आउटपुट फ़ाइल वाले ज़रूरी टारगेट के लिए testonly का इस्तेमाल करें. इसके लिए, जनरेट करने वाले नियम का सिर्फ़ टेस्ट देखें. यह 'किसको दिखे' सेटिंग से मेल खाता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "गलत": चालू होने पर, विज़िबिलिटी की जांच करने की सुविधा, टूलचेन लागू करने की सुविधा पर भी लागू होती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "गलत": इस सुविधा के चालू होने पर, Android के मूल नियमों का सीधे तौर पर इस्तेमाल करने की सुविधा बंद हो जाती है. कृपया https://github.com/bazelbuild/rules_android से गए Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "गलत": नहीं. पुराने सिस्टम के साथ काम करने के लिए, इसे यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 डिफ़ॉल्ट: "सही": अगर सही है, तो 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 डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: विवरण देखें: -insupported_python_disallow_native_rules लागू करने के लिए, अनुमति वाली सूची (package_group target) का इस्तेमाल करें.
टैग: loading_and_analysis
--[no]strict_filesets डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू किया जाता है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "गड़बड़ी": जब तक बंद न हो, तब तक यह जांच करता है कि कोई proto_library टारगेट साफ़ तौर पर सभी सीधे इस्तेमाल किए जाने वाले टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद": जब तक बंद न हो, तब तक यह जांच करता है कि कोई proto_library टारगेट साफ़ तौर पर 'इंपोर्ट करें' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट किए गए के तौर पर बताए.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes डिफ़ॉल्ट: "गलत": अगर सही है, तो सिस्टम से मिलने वाले हेडर में पाथ (-isystem) को शामिल करना भी ज़रूरी होता है.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> बार कई बार इस्तेमाल किया गया है: इस बिल्ड के टारगेट एनवायरमेंट का एलान करता है. "एनवायरमेंट" नियम के लेबल का रेफ़रंस होना चाहिए. अगर तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने वाले होने चाहिए.
टैग: changes_inputs

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

--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही": नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "गलत": अगर सही हो, तो objc_library andobjc_Import में जाकर SDK_frameworks और social_sdk_frameworks के एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत": अगर सही है, तो objc_library और objc_Import में हमेशा लिंक की सुविधा वाली वैल्यू के लिए, डिफ़ॉल्ट वैल्यू को 'सही' के तौर पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत": सही होने पर, बिल्टइन py_* नियमों का इस्तेमाल करते समय कोई गड़बड़ी होती है; इसके बजाय, Rules_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत": सही होने पर, नियम को टारगेट करने से विश्लेषण नहीं हो पाता है. इसका नतीजा यह होता है कि टारगेट, गड़बड़ी की जानकारी वाले विश्लेषणFailureInfo के इंस्टेंस को लागू नहीं करेगा, न कि बिल्ड फ़ेल हो जाएगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट की मदद से, ज़्यादा से ज़्यादा ट्रांज़िटिव डिपेंडेंसी सेट करता है. इस सीमा को पार करने से नियम में गड़बड़ी होगी.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत": अगर सही dex2oat कार्रवाई के पूरा न हो पाने पर, टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> बार कई बार इस्तेमाल किया गया है: टेस्ट के लिए, रिसॉर्स की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर कोई पॉज़िटिव नंबर <value> के तौर पर दिया गया है, तो वह जांच के लिए इस्तेमाल किए जाने वाले सभी साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगा. अगर कॉमा लगाकर अलग की गई चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बड़े साइज़ के टेस्ट साइज़ के लिए, रिसॉर्स की संख्या को बदल देंगी. वैल्यू Host_RAM/Host_CPU भी हो सकती है. विकल्प के तौर पर, इसके बाद [-|*]<float> (जैसे कि मेमोरी=Host_RAM*.1,Host_RAM*.2,Host_RAM*.3,Host_RAM*.4) भी हो सकते हैं. इस फ़्लैग से तय किए गए जांच वाले डिफ़ॉल्ट रिसॉर्स, टैग में बताए गए साफ़ तौर पर उपलब्ध रिसॉर्स से बदल जाते हैं.
--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "गलत": android_test की स्पीड बढ़ाने के लिए, dex2oat का साथ-साथ इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks डिफ़ॉल्ट: "गलत": 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. जहां Run_per_test का मतलब पूर्णांक वैल्यू होती है और regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल और बाहर करने की सूची दिखाता है. इसके अलावा, --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में सभी टेस्ट चलाता है. हालांकि, foo/bar से कम वाले टेस्ट तीन बार किए जाते हैं. यह विकल्प कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए आर्ग्युमेंट को प्राथमिकता दी जाती है. अगर कुछ भी मैच नहीं करता है, तो जांच सिर्फ़ एक बार की जाती है.
--test_env=<a 'name=value' assignment with an optional value part> बार कई बार इस्तेमाल किया गया है: टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट या name=value पेयर से पढ़ी जाएगी. कई वैरिएबल के बारे में बताने के लिए, इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
टैग: test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर कोई एक पॉज़िटिव पूर्णांक मान दिया गया है, तो वह सभी कैटगरी को ओवरराइड कर देगा. अगर कॉमा लगाकर अलग किए गए चार पूर्णांकों का पता लगाया जाता है, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. किसी भी रूप में, -1 की वैल्यू ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहती है.
--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही": अगर सही है, तो टेस्ट के ऐसे आउटपुट ZIP फ़ाइल में संग्रहित किए जाएंगे जिनका एलान नहीं किया गया है.
टैग: test_runner

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव": आउटपुट फ़ॉर्मैट {xml,proto,record} में होने पर, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को कैसे ठीक करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान किए गए सभी पहलू डिपेंडेंसी जोड़े जाते हैं. इस बात से कोई फ़र्क़ नहीं पड़ता कि उन्हें डायरेक्ट डिपेंडेंसी के नियम की क्लास दी गई है या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी के नियम क्लास के आधार पर संभावित तौर पर ऐक्टिव हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट का आकलन करने के लिए, दूसरे पैकेज को लोड करना ज़रूरी है. इससे यह अन्य मोड की तुलना में धीमा हो जाएगा. इस बात का भी ध्यान रखें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में तय किया जाता है. यह प्रोसेस, 'बैजल क्वेरी' के दौरान नहीं चलाई जाती.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से लेबल निकलते हैं, जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन का इस्तेमाल किया जाता है. यह उन टूल के लिए फ़ायदेमंद है जिन्हें नियमों से निकलने वाले अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इसे चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैटर, आउटपुट को ज़्यादा पढ़ने लायक बनाने के बजाय, साफ़ तौर पर रिपॉज़िटरी के नाम (मुख्य डेटा स्टोर करने की जगह के हिसाब से) का इस्तेमाल कर सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]graph:factored डिफ़ॉल्ट: "सही": अगर सही है, तो ग्राफ़ पर 'फ़ैक्टर' उत्सर्जित होगा. इसका मतलब है कि टॉपॉलॉजिकल रूप से समान नोड एक साथ मर्ज कर दिए जाएंगे और उनके लेबल जोड़े जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> डिफ़ॉल्ट: "512": आउटपुट में ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल में काट-छांट की जाएगी; -1 का मतलब है कि कोई काट-छांट नहीं होगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel से जोड़ा गया है. cquery के लिए यह विकल्प, समाधान किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_aspects डिफ़ॉल्ट: "सही": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, इसके पहले `//` को हटाया नहीं जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "गलत": अगर सेट और --universe_scope सेट नहीं है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई, --universe_scope वैल्यू आपकी पसंद के मुताबिक नहीं हो सकती. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है (यानी `cquery` नहीं).
टैग: loading_and_analysis
--[no]line_terminator_null डिफ़ॉल्ट: "गलत": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म करना है.
टैग: terminal_output
--[no]nodep_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो "nodep" एट्रिब्यूट के डिपेंस को उस डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics
--output=<a string> डिफ़ॉल्ट: "लेबल": वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_ kind, textproto, migrations, proto, टैग किए गए प्रोटो, jsonproto. अगर आपने 'transitions' चुना है, तो आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": सही होने पर, उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": definition_stack प्रोटो फ़ील्ड को भरें, जो नियम की क्लास तय होने के समय Starlark कॉल स्टैक के हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो select() से बनाए गए कॉन्फ़िगर करने लायक एट्रिब्यूट बराबर हो जाते हैं. सूची टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप की वैल्यू शून्य हो जाती है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स पहलू के साथ भरें जिससे एट्रिब्यूट मिला है (अगर ऐसा नहीं है, तो खाली स्ट्रिंग).
टैग: terminal_output
--[no]proto:include_configurations डिफ़ॉल्ट: "सही": चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत": $internal_attr_has एट्रिब्यूट का हिसाब लगाना है या नहीं, इसका पता लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत": हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग: terminal_output
--[no]proto:locations डिफ़ॉल्ट: "सही": प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "सभी": आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. कोई एट्रिब्यूट आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर क्वेरी को सेट किया जाता है, तो कमांड लाइन के बजाय, यहां दी गई फ़ाइल का नाम पढ़कर सुनाया जाएगा. यहां फ़ाइल और कमांड लाइन क्वेरी के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक ऐब्सलूट पाथ होता है और यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--show_config_fragments=<off, direct or transitive> डिफ़ॉल्ट: "बंद": नियम और उसकी ट्रांज़िटिव डिपेंडेंसी के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट दिखाता है. इससे, यह आकलन करने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ में कितने हिस्से में काट-छांट की जा सकती है.
टैग: affects_outputs
--starlark:expr=<a string> डिफ़ॉल्ट: "": कॉन्फ़िगर किए गए हर टारगेट को cquery के --OUT=starlark मोड में फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट 'टारगेट' से जुड़ा है. अगर --starlark:expr या --starlark:file तय नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट होगा. --starlark:expr और --starlark:file दोनों देते समय कोई गड़बड़ी हुई है.
टैग: terminal_output
--starlark:file=<a string> डिफ़ॉल्ट: "": स्टारलार्क फ़ंक्शन को तय करने वाली फ़ाइल का नाम, जिसे 'फ़ॉर्मैट' कहा जाता है. यह एक तर्क का होता है. इसे कॉन्फ़िगर किए गए हर टारगेट पर लागू करके, एक स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. --starlark:expr और --starlark:file दोनों देते समय कोई गड़बड़ी हुई है. ज़्यादा जानकारी के लिए --आउटपुट=स्टारलार्क के लिए सहायता देखें.
टैग: terminal_output
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: बंद होने पर, क्वेरी को ऑपरेट करने वाले डिपेंडेंसी ग्राफ़ में 'exec कॉन्फ़िगरेशन' की डिपेंडेंसी शामिल नहीं होंगी. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसा कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक जाता है. आम तौर पर, यह एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल को पॉइंट करता है. Cquery: यह विकल्प बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट exec कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए exec टारगेट दिखाए जाएंगे. इस विकल्प में ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग: build_file_semantics
--transitions=<full, lite or none> डिफ़ॉल्ट: "कोई नहीं": वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगा.
टैग: affects_outputs
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा और घटाव). क्वेरी को यूनिवर्स में परफ़ॉर्म किया जा सकता है. इसके लिए, दिए गए टारगेट को हमेशा के लिए बंद करना होगा. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माने जाते हैं. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए, इस विकल्प को तय न करने से बिल्ड में रुकावट आ सकती है.
टैग: loading_and_analysis

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "गलत": LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग: action_command_lines
--[no]experimental_inmemory_dotd_files डिफ़ॉल्ट: "सही": अगर C++ .d फ़ाइलें चालू की जाती हैं, तो उन्हें डिस्क पर सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files डिफ़ॉल्ट: "सही": चालू होने पर, Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क पर सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत": इस सुविधा को चालू करने पर, --trim_test_ Configuration, सिर्फ़ testonly=1 मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन में काट-छांट नहीं करेगा. इसका मकसद, कार्रवाई से जुड़े विवाद की समस्याओं को कम करना है. ऐसा तब किया जाता है, जब गैर-जांच नियम cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_कॉन्फ़िगरेशन गलत है, तो कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state
--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "गलत": इनपुट फ़ाइलों से #include लाइनों को पार्स करके, इनपुट को C/C++ कंपाइलेशन में बदलना है या नहीं. यह कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और बढ़ोतरी को बेहतर बना सकता है. हालांकि, इससे बिल्ड टूट भी सकते हैं, क्योंकि शामिल स्कैनर, C प्रीप्रोसेसर सिमैंटिक को पूरी तरह लागू नहीं करता. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर के कंडीशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. अगर इस फ़्लैग से जुड़ी कोई समस्या है, तो उसे बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs
--[no]incremental_dexing डिफ़ॉल्ट: "सही": ज़्यादातर जार फ़ाइल को डीक्स करने का ज़्यादातर काम अलग-अलग किया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही": अगर इस नीति को सेट किया जाता है, तो clang से उत्सर्जित होने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइलेशन में पास किए गए इनपुट के सेट को हटाने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत": टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग: execution
--[no]trim_test_configuration डिफ़ॉल्ट: "सही": यह सुविधा चालू होने पर, बिल्ड के टॉप लेवल के नीचे जांच से जुड़े विकल्प हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को गैर-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में किए जाने वाले बदलावों की वजह से, टेस्ट न करने वाले नियमों का फिर से विश्लेषण नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state

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

--flag_alias=<a 'name=value' flag alias> बार कई बार इस्तेमाल किया गया है: स्टारलार्क फ़्लैग के लिए, यह छोटा नाम सेट करता है. यह तर्क के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर होता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत": यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन जाएं. आम तौर पर, जब किसी py_binary या py_test टारगेट में lead_create_init को "ऑटो" (डिफ़ॉल्ट) पर सेट किया जाता है, तो यह 'गलत' के तौर पर तब ही माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही": अगर 'सही' है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स शामिल नहीं है. इसका मतलब है कि `bazel-bin` सुविधा का सिमलिंक, Python 2 के बजाय Python 3 के टारगेट को पॉइंट करेगा. अगर इस विकल्प को चालू किया जाता है, तो `--insupported_py3_is_default` को चालू करने का भी सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही": सही होने पर, `py_binary` और `py_test` एट्रिब्यूट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. अगर इस फ़्लैग को सेट किया जाता है, तो `--insupported_py2_OUTs_are_suffixed` को सेट करने का सुझाव भी दिया जाता है.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो एक्ज़ीक्यूटेबल नेटिव Python नियम, --python_top जैसे लेगसी फ़्लैग से दिए गए रनटाइम के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल करेंगे.
टैग: 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] डिफ़ॉल्ट: "ऑटो": अगर यह नीति 'ऑटो' पर सेट है, तो Bazel फिर से टेस्ट तब करता है, जब: (1) Bazel को, जांच में हुए बदलाव या उसकी डिपेंडेंसी का पता चलता हो, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test की मदद से कई बार टेस्ट करने का अनुरोध किया गया हो या(4) जांच पहले असफल हो गई हो. अगर यह नीति 'हां' पर सेट है, तो बाहरी के तौर पर मार्क किए गए टेस्ट के अलावा, Bazel जांच के सभी नतीजों को कैश मेमोरी में सेव करेगा. अगर यह नीति 'नहीं' पर सेट है, तो Bazel जांच के किसी भी नतीजे को कैश मेमोरी में सेव नहीं करेगा.
--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत": सही होने पर, Blaze पहले सफल रन पर एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ इस्तेमाल करने पर ही काम करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो Bazel, कवरेज के दौरान हर टेस्ट के लिए पूरी कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "गलत": अगर सही है, तो क्लैंग के लिए कवरेज, एलसीओवी रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_j2objc_header_map डिफ़ॉल्ट: "सही": J2ObjC ट्रांसपिलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "गलत": छोटे हेडर पाथ के साथ जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग: affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javaBuilder": Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ चालू करें.
--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत": Android के साथ काम करने वाली लाइब्रेरी तक --experimental_run_android_lint_on_java_rules पर सीमित करें.
टैग: affects_outputs
--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत": Java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs
--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत": टेस्टरनर के डिप से गलती से डेटा हासिल करने के बजाय, java_test में JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ बैजल के लिए काम करता है.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: विवरण देखें: यह Java लॉन्चर, उन टूल में इस्तेमाल होता है जो बिल्ड होने के दौरान एक्ज़ीक्यूट होते हैं.
--host_javacopt=<a string> बार कई बार इस्तेमाल किया गया है: किसी बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल बनाते समय, javac को पास करने के ज़्यादा विकल्प.
--host_jvmopt=<a string> बार कई बार इस्तेमाल किया गया है: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, Java वीएम को पास करने के ज़्यादा विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही": अगर सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि उसके पाथ में फ़ाइल को TEST_SHARD_STATUS_FILE में जोड़ा जा सकता है, तो Bazel शार्ड किए गए टेस्ट को फ़ेल कर देगा. गलत होने पर, अगर शार्डिंग की सुविधा काम नहीं करती, तो टेस्ट रनर की वजह से हर शार्ड में सभी टेस्ट चल रहे होंगे.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही": अगर सही है, तो सैंडबॉक्स रणनीति की मदद से खास टेस्ट चलाए जाएंगे. सिर्फ़ स्थानीय स्तर पर टेस्ट चलाने के लिए 'लोकल' टैग जोड़ें
टैग: incompatible_change
--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत": अगर सही है, तो 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_internal=streamed को शामिल किया गया है.
इसमें शामिल है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps डिफ़ॉल्ट: "सही": हर Java टारगेट के लिए डिपेंडेंसी जानकारी (अभी, कंपाइल-टाइम क्लासपाथ) जनरेट करें.
--[no]java_header_compilation डिफ़ॉल्ट: "सही": सीधे सोर्स से जरार इकट्ठा करें.
--java_language_version=<a string> डिफ़ॉल्ट: "": जावा भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: विवरण देखें: Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर यह फ़्लैग खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": जावा रनटाइम वर्शन
--javacopt=<a string> बार कई बार इस्तेमाल किया गया है: javac पर भेजने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> बार कई बार इस्तेमाल किया गया है: Java वीएम को पास करने के दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: विवरण देखें: ऐसी क्लास की सूची जनरेट करने के लिए बाइनरी के बारे में बताता है जिसका इस्तेमाल लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य dex में होना चाहिए.
--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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल जिसमें C++ Protos को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल जिसमें Java Protos को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@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 डिफ़ॉल्ट: "गलत": अगर सही हो, तो कम से कम एक रन/अटेंप्ट में पास होने पर और कम से कम एक रन/अटैम फ़ेल होने पर उसे 'फ़्लेकी' स्टेटस मिल जाता है.
--shell_executable=<a path> डिफ़ॉल्ट: विवरण देखें: BZel के इस्तेमाल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को पहले Bazel सर्वर पर सेट किया गया है, जो Bazel सर्वर को शुरू करता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करेगा. यह उस ऑपरेटिंग सिस्टम के हिसाब से तय होगा जिस पर वह चलता है (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash). ध्यान दें कि अगर किसी ऐसे शेल का इस्तेमाल किया जाता है जो बैश के साथ काम नहीं करता, तो जनरेट की गई बाइनरी के रनटाइम या रनटाइम फ़ेल हो सकते हैं.
टैग: loading_and_analysis
--test_arg=<a string> बार कई बार इस्तेमाल किया गया है: उन अतिरिक्त विकल्पों और तर्क के बारे में बताता है जिन्हें टेस्ट एक्ज़ीक्यूटेबल के लिए पास किया जाना चाहिए. अलग-अलग आर्ग्युमेंट का इस्तेमाल करने के लिए, एक से ज़्यादा बार इस्तेमाल किया जा सकता है. अगर कई जांच की जाती हैं, तो सभी को एक जैसे तर्क मिलेंगे. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
--test_filter=<a string> डिफ़ॉल्ट: विवरण देखें: टेस्ट फ़्रेमवर्क पर भेजने के लिए एक फ़िल्टर तय करता है. इसका इस्तेमाल, जांच को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे बनाए गए टारगेट पर कोई असर नहीं पड़ता.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": यह विकल्प अब काम नहीं करता और इसका कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत": टेस्ट रनर पर तेज़ी से फ़ॉरवर्ड करने का विकल्प फ़ेल हो गया. पहली बार असफल होने पर, टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "अश्लील": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'साफ़ तौर पर' शार्डिंग का इस्तेमाल सिर्फ़ तब करें, जब 'sard_count' BUILD एट्रिब्यूट मौजूद हो. टेस्ट शार्डिंग का इस्तेमाल कभी नहीं करने के लिए 'बंद' है. 'forced=k' की मदद से, जांच के लिए 'k' शार्ड लागू किए जा सकते हैं, भले ही 's आम तौर पर काउंट' BUILD एट्रिब्यूट कुछ भी हो.
--tool_java_language_version=<a string> डिफ़ॉल्ट: "": जावा भाषा का वर्शन, जिसका इस्तेमाल उन टूल को चलाने के लिए किया जाता है जो बिल्ड बनाने के दौरान ज़रूरी होते हैं
--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11": बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन
--[no]use_ijars डिफ़ॉल्ट: "सही": अगर यह विकल्प चालू है, तो इस विकल्प की वजह से Java कंपाइलेशन में इंटरफ़ेस जार का इस्तेमाल होता है. इससे, कंपाइलेशन तेज़ी से बढ़ेगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

डंप के विकल्प

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

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

--[no]action_cache डिफ़ॉल्ट: "गलत": कैश मेमोरी में डेटा को डंप करने की कार्रवाई.
टैग: bazel_monitoring
--memory=<none, shallow or deep> डिफ़ॉल्ट: "कोई नहीं": किसी दिए गए Skyframe नोड का मेमोरी इस्तेमाल कम करें.
टैग: bazel_monitoring
--memory_package=<a string> डिफ़ॉल्ट: विवरण देखें: वह पैकेज जिसकी मेमोरी का इस्तेमाल नहीं करना है.
टैग: bazel_monitoring
--memory_starlark_module=<a build target label> डिफ़ॉल्ट: विवरण देखें: Starlark मॉड्यूल, जिसकी मेमोरी का इस्तेमाल नहीं किया जाना चाहिए.
टैग: bazel_monitoring
--[no]packages डिफ़ॉल्ट: "गलत": डंप पैकेज की कैश मेमोरी का कॉन्टेंट.
टैग: bazel_monitoring
--[no]rule_classes डिफ़ॉल्ट: "गलत": डंप नियम की क्लास.
टैग: bazel_monitoring
--[no]rules डिफ़ॉल्ट: "गलत": डंप के नियम, जिनमें संख्या और मेमोरी के इस्तेमाल की जानकारी शामिल होती है (अगर मेमोरी को ट्रैक किया जाता है).
टैग: bazel_monitoring
--skyframe=<off, summary, count, value, deps, rdeps or function_graph> डिफ़ॉल्ट: "बंद": डंप स्काईफ़्रेम ग्राफ़: 'off', 'summary', 'count', 'value', 'deps', 'rdeps' या 'Function_graph'.
टैग: bazel_monitoring
--skykey_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: ".*": आउटपुट के लिए, SkyKey नामों का रेगुलर एक्सप्रेशन फ़िल्टर. सिर्फ़ --skyframe=deps, rdeps, section_graph के साथ इस्तेमाल किया जाता.
टैग: bazel_monitoring
--skylark_memory=<a string> डिफ़ॉल्ट: विवरण देखें: किसी खास पाथ के लिए, एक ऐसी मेमोरी प्रोफ़ाइल को हटा देता है जो pprof के साथ काम करने वाली मेमोरी में होती है. ज़्यादा जानने के लिए, कृपया https://github.com/google/pprof पर जाएं.
टैग: bazel_monitoring

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

फ़ेच के विकल्प

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

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

--[no]all डिफ़ॉल्ट: "गलत": किसी भी टारगेट या डेटा स्टोर करने की जगह को बनाने के लिए, ज़रूरी सभी बाहरी डेटा स्टोर करने की जगह को फ़ेच करता है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": इस्तेमाल की गई मेमोरी का प्रतिशत (0-100) और इससे ज़्यादा GcTtrazingDetector, मेमोरी दबाव की घटनाओं को अपनी सीमा के हिसाब से (--gc_thrazing_limits). अगर इस नीति को 100 पर सेट किया जाता है, तो GcThrgingDetector को बंद कर दिया जाता है.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": लोडिंग/विश्लेषण फ़ेज़ में इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. उदाहरण के लिए, "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

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

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव": आउटपुट फ़ॉर्मैट {xml,proto,record} में होने पर, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को कैसे ठीक करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान किए गए सभी पहलू डिपेंडेंसी जोड़े जाते हैं. इस बात से कोई फ़र्क़ नहीं पड़ता कि उन्हें डायरेक्ट डिपेंडेंसी के नियम की क्लास दी गई है या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी के नियम क्लास के आधार पर संभावित तौर पर ऐक्टिव हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट का आकलन करने के लिए, दूसरे पैकेज को लोड करना ज़रूरी है. इससे यह अन्य मोड की तुलना में धीमा हो जाएगा. इस बात का भी ध्यान रखें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में तय किया जाता है. यह प्रोसेस, 'बैजल क्वेरी' के दौरान नहीं चलाई जाती.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से लेबल निकलते हैं, जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन का इस्तेमाल किया जाता है. यह उन टूल के लिए फ़ायदेमंद है जिन्हें नियमों से निकलने वाले अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इसे चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैटर, आउटपुट को ज़्यादा पढ़ने लायक बनाने के बजाय, साफ़ तौर पर रिपॉज़िटरी के नाम (मुख्य डेटा स्टोर करने की जगह के हिसाब से) का इस्तेमाल कर सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]graph:factored डिफ़ॉल्ट: "सही": अगर सही है, तो ग्राफ़ पर 'फ़ैक्टर' उत्सर्जित होगा. इसका मतलब है कि टॉपॉलॉजिकल रूप से समान नोड एक साथ मर्ज कर दिए जाएंगे और उनके लेबल जोड़े जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> डिफ़ॉल्ट: "512": आउटपुट में ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल में काट-छांट की जाएगी; -1 का मतलब है कि कोई काट-छांट नहीं होगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel से जोड़ा गया है. cquery के लिए यह विकल्प, समाधान किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_aspects डिफ़ॉल्ट: "सही": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, इसके पहले `//` को हटाया नहीं जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "गलत": अगर सेट और --universe_scope सेट नहीं है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई, --universe_scope वैल्यू आपकी पसंद के मुताबिक नहीं हो सकती. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है (यानी `cquery` नहीं).
टैग: loading_and_analysis
--[no]line_terminator_null डिफ़ॉल्ट: "गलत": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म करना है.
टैग: terminal_output
--[no]nodep_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो "nodep" एट्रिब्यूट के डिपेंस को उस डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics
--output=<a string> डिफ़ॉल्ट: "लेबल": वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_ kind, textproto, migrations, proto, टैग किए गए प्रोटो, jsonproto. अगर आपने 'transitions' चुना है, तो आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": सही होने पर, उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": definition_stack प्रोटो फ़ील्ड को भरें, जो नियम की क्लास तय होने के समय Starlark कॉल स्टैक के हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो select() से बनाए गए कॉन्फ़िगर करने लायक एट्रिब्यूट बराबर हो जाते हैं. सूची टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप की वैल्यू शून्य हो जाती है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स पहलू के साथ भरें जिससे एट्रिब्यूट मिला है (अगर ऐसा नहीं है, तो खाली स्ट्रिंग).
टैग: terminal_output
--[no]proto:include_configurations डिफ़ॉल्ट: "सही": चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत": $internal_attr_has एट्रिब्यूट का हिसाब लगाना है या नहीं, इसका पता लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत": हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग: terminal_output
--[no]proto:locations डिफ़ॉल्ट: "सही": प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "सभी": आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. कोई एट्रिब्यूट आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर क्वेरी को सेट किया जाता है, तो कमांड लाइन के बजाय, यहां दी गई फ़ाइल का नाम पढ़कर सुनाया जाएगा. यहां फ़ाइल और कमांड लाइन क्वेरी के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक ऐब्सलूट पाथ होता है और यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--show_config_fragments=<off, direct or transitive> डिफ़ॉल्ट: "बंद": नियम और उसकी ट्रांज़िटिव डिपेंडेंसी के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट दिखाता है. इससे, यह आकलन करने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ में कितने हिस्से में काट-छांट की जा सकती है.
टैग: affects_outputs
--starlark:expr=<a string> डिफ़ॉल्ट: "": कॉन्फ़िगर किए गए हर टारगेट को cquery के --OUT=starlark मोड में फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट 'टारगेट' से जुड़ा है. अगर --starlark:expr या --starlark:file तय नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट होगा. --starlark:expr और --starlark:file दोनों देते समय कोई गड़बड़ी हुई है.
टैग: terminal_output
--starlark:file=<a string> डिफ़ॉल्ट: "": स्टारलार्क फ़ंक्शन को तय करने वाली फ़ाइल का नाम, जिसे 'फ़ॉर्मैट' कहा जाता है. यह एक तर्क का होता है. इसे कॉन्फ़िगर किए गए हर टारगेट पर लागू करके, एक स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. --starlark:expr और --starlark:file दोनों देते समय कोई गड़बड़ी हुई है. ज़्यादा जानकारी के लिए --आउटपुट=स्टारलार्क के लिए सहायता देखें.
टैग: terminal_output
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: बंद होने पर, क्वेरी को ऑपरेट करने वाले डिपेंडेंसी ग्राफ़ में 'exec कॉन्फ़िगरेशन' की डिपेंडेंसी शामिल नहीं होंगी. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसा कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक जाता है. आम तौर पर, यह एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल को पॉइंट करता है. Cquery: यह विकल्प बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट exec कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए exec टारगेट दिखाए जाएंगे. इस विकल्प में ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग: build_file_semantics
--transitions=<full, lite or none> डिफ़ॉल्ट: "कोई नहीं": वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगा.
टैग: affects_outputs
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा और घटाव). क्वेरी को यूनिवर्स में परफ़ॉर्म किया जा सकता है. इसके लिए, दिए गए टारगेट को हमेशा के लिए बंद करना होगा. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माने जाते हैं. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए, इस विकल्प को तय न करने से बिल्ड में रुकावट आ सकती है.
टैग: loading_and_analysis

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: "": अगर यह खाली नहीं है, तो Starlark के डेटा स्टोर करने की सुविधा के सभी नियमों की समाधान की गई जानकारी के साथ Starlark की वैल्यू लिखें. यह वैल्यू, एक्ज़ीक्यूट किए गए सभी नियमों की होनी चाहिए.
टैग: affects_outputs

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

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

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

--[no]all डिफ़ॉल्ट: "गलत": किसी भी टारगेट या डेटा स्टोर करने की जगह को बनाने के लिए, ज़रूरी सभी बाहरी डेटा स्टोर करने की जगह को फ़ेच करता है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "गलत": सिमलिंक ट्री बनाने के लिए, डायरेक्ट फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "गलत": कर्मचारियों की मदद से, परसिस्टेंट Aar एक्सट्रैक्टर चालू करें.
टैग: execution
--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "गलत": सोर्स मेनिफ़ेस्ट कार्रवाइयों को फिर से चालू करना है या नहीं
टैग: loading_and_analysis, execution, experimental
--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "गलत": अगर सही है, तो Bazel एक नए स्पॉन में टेस्ट के लिए, कवरेज पोस्टप्रोसेसिंग करेगा.
टैग: execution
--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री को ट्रैवर्स नहीं करेंगे या सिमलिंक के प्रति संवेदनशील नहीं होंगे.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": लोडिंग/विश्लेषण फ़ेज़ में इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. उदाहरण के लिए. "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> डिफ़ॉल्ट: "": गतिविधियों की जानकारी के आधार पर, उस कार्रवाई के काम करने के तरीके की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो स्क्रिप्ट को चलाने की जानकारी देती हैं. कई सामान्य कार्रवाइयां, एक्ज़ीक्यूशन की जानकारी के साथ काम करती हैं, जैसे कि Genroll, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, ऑर्डर अहम हो जाता है, क्योंकि एक ही मिनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' जोड़ता है और 'y' से हटा देता है. जेनरूल की सभी कार्रवाइयों के लिए, 'Genroll=+requires-x' को लागू करने की जानकारी में 'requires-x' जोड़ता है. '(?!GenTerms).*=-requires-x', सभी गैर-सामान्य कार्रवाइयों के लिए, निष्पादन जानकारी से '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=workerhost_machine_resource_optimizationsexecution
--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{/2/}

--modify_execution_info=AARGenerator=+supports-multiplex-workershost_machine_resource_optimizationsexecution
--persistent_multiplex_android_tools: परसिस्टेंट और मल्टीप्लेक्स किए गए Android टूल (डेक्सिंग, डिस्यूगरिंग, रिसॉर्स प्रोसेसिंग) चालू करें.
इसमें शामिल है:
  --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 डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो Bazel, टेस्ट एक्ज़ेक्यूटिव ग्रुप के बजाय, टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा.
टैग: execution

--android_compiler=<a string> डिफ़ॉल्ट: विवरण देखें: Android का टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--android_crosstool_top=<a build target label> डिफ़ॉल्ट: "//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> डिफ़ॉल्ट: "": यह नीति उन प्लैटफ़ॉर्म को सेट करती है जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी एक फ़ैट APKs होती है, जिसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--android_sdk=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk": Android SDK टूल/प्लैटफ़ॉर्म के बारे में बताता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state
--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain": Apple और Objc नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs
--cc_output_directory_tag=<a string> डिफ़ॉल्ट: "": कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs
--compiler=<a string> डिफ़ॉल्ट: विवरण देखें: टारगेट इकट्ठा करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution
--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger": रॉ कवरेज रिपोर्ट को पोस्ट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. यह फ़िलहाल एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcow_merger' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_report_generator=<a build target label> डिफ़ॉल्ट: "@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> डिफ़ॉल्ट: "@bazel_tools//tools/test:कवरेज_support": सहायता फ़ाइलों की वह जगह जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई के इनपुट के लिए ज़रूरी होती है. डिफ़ॉल्ट रूप से '//tools/test:coverage_support' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--custom_malloc=<a build target label> डिफ़ॉल्ट: विवरण देखें: यह तय करता है कि कस्टम मैलक लागू किया जाए या नहीं. यह सेटिंग, बिल्ड के नियमों में मॉलक एट्रिब्यूट को बदल देती है.
टैग: 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 डिफ़ॉल्ट: "गलत": अगर यह नीति सेट है, तो हर Xcode कार्रवाई के लिए "requires-xcode:{version}" का इस्तेमाल करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" चलाने की ज़रूरत भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution
--[no]experimental_prefer_mutual_xcode डिफ़ॉल्ट: "सही": अगर सही है, तो सबसे हाल का Xcode इस्तेमाल करें जो स्थानीय और कहीं से भी उपलब्ध हो. अगर यह गलत है या कोई भी म्यूचुअली उपलब्ध वर्शन नहीं है, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state
--extra_execution_platforms=<comma-separated list of options> डिफ़ॉल्ट: "": ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन प्लैटफ़ॉर्म को वर्कस्पेस फ़ाइल में रजिस्टर_execution_platforms() के ज़रिए एलान किए गए प्लैटफ़ॉर्म से पहले लागू किया जाएगा. यह विकल्प सिर्फ़ एक बार सेट किया जा सकता है; बाद के इंस्टेंस पहले के फ़्लैग की सेटिंग को बदल देंगे.
टैग: execution
--extra_toolchains=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन में ध्यान दिए जाने वाले नियम. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर दिखाया जा सकता है. इन टूलचेन का इस्तेमाल, workspace_toolchains() के ज़रिए वर्कSPACE फ़ाइल में बताए गए टूल से पहले किया जाता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--grte_top=<a label> डिफ़ॉल्ट: विवरण देखें: चेक-इन की गई libc लाइब्रेरी का लेबल. क्रॉसटूल टूलचेन में डिफ़ॉल्ट वैल्यू को चुना जाता है और आपको इसे बदलने की ज़रूरत नहीं पड़ती.
टैग: action_command_lines, affects_outputs
--host_compiler=<a string> डिफ़ॉल्ट: विवरण देखें: बिना किसी बटन वाला फ़्लैग. इसे आने वाली रिलीज़ से हटा दिया जाएगा.
टैग: loading_and_analysis, execution
--host_grte_top=<a label> डिफ़ॉल्ट: विवरण देखें: अगर इसके बारे में बताया गया है, तो यह सेटिंग exec कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> डिफ़ॉल्ट: "@local_config_platform//:host": प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही": अगर सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'nonhost' सुविधाओं को चालू नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_android_toolchain_resolution डिफ़ॉल्ट: "सही": Android के नियमों (Starlark और निजी) के लिए Android SDK चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "गलत": Apple के नियमों (Starlark और निजी) के लिए, Apple SDK चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--[no]incompatible_remove_legacy_whole_archive डिफ़ॉल्ट: "सही": अगर सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_require_ctx_in_configure_features डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "गलत": सही होने पर, एक्ज़ीक्यूटेबल के लिए स्ट्रिप से जुड़ी कार्रवाई में फ़्लैग -x का इस्तेमाल किया जाएगा, जो डाइनैमिक सिंबल के रिज़ॉल्यूशन को नहीं तोड़ता है.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects डिफ़ॉल्ट: "सही": अगर टूलचेन के साथ काम करने वाला इंटरफ़ेस शेयर किया गया ऑब्जेक्ट है, तो उसका इस्तेमाल करें. फ़िलहाल, यह सेटिंग सभी ELF टूलचेन में काम करती है.
टैग: 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> डिफ़ॉल्ट: "": मैपिंग फ़ाइल की जगह, जो बताती है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं किया गया है, तो किस प्लैटफ़ॉर्म का इस्तेमाल किया जाए या पहले से मौजूद प्लैटफ़ॉर्म पर कौनसे फ़्लैग सेट किए जाएं. मुख्य फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता होना चाहिए. यह डिफ़ॉल्ट रूप से 'platform_mappings' (फ़ाइल फ़ोल्डर रूट के तहत आने वाली फ़ाइल) पर सेट होता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable
--platforms=<a build target label> डिफ़ॉल्ट: "": प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.
टैग: affects_outputs, changes_inputs, loading_and_analysis
--python2_path=<a string> डिफ़ॉल्ट: विवरण देखें: अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से बंद कर दिया गया है.
टैग: no_op, deprecated
--python3_path=<a string> डिफ़ॉल्ट: विवरण देखें: अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से बंद कर दिया गया है.
टैग: no_op, deprecated
--python_path=<a string> डिफ़ॉल्ट: विवरण देखें: Python अनुवादक के ऐब्सलूट पाथ को टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains ने इसे बंद किया है.
टैग: loading_and_analysis, affects_outputs
--python_top=<a build target label> डिफ़ॉल्ट: विवरण देखें: Python इंटरप्रेटर को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains ने इसे बंद किया है.
टैग: loading_and_analysis, affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: यह tvOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, tvOS ऐप्लिकेशन बनाने के लिए किया जाएगा. इसकी जानकारी न होने पर, 'xcode_version' से tvOS के SDK टूल का डिफ़ॉल्ट वर्शन इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: WatchOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट WatchOS SDK वर्शन इस्तेमाल करता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: विवरण देखें: अगर बताया गया है, तो सही बिल्ड ऐक्शन के लिए दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर इसकी जानकारी नहीं दी गई है, तो Xcode के एक्ज़ीक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes": xcode_config नियम का लेबल. इसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन को चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत": डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग: affects_outputs, action_command_lines
--[no]build_runfile_links डिफ़ॉल्ट: "सही": अगर सही है, तो रनफ़ाइल बनाने के लिए सभी टारगेट के लिए जंगलों को आपस में लिंक किया जाता है. अगर यह गलत है, तो इन्हें सिर्फ़ तब लिखें, जब ज़रूरी हो. इसके लिए, किसी स्थानीय कार्रवाई, टेस्ट या रन कमांड का इस्तेमाल करें.
टैग: affects_outputs
--[no]build_runfile_manifests डिफ़ॉल्ट: "सही": अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर गलत है, तो उन्हें मिटा दें. गलत होने पर लोकल टेस्ट नहीं चलाए जाएंगे.
टैग: affects_outputs
--[no]build_test_dwp डिफ़ॉल्ट: "गलत": यह सुविधा चालू होने पर, स्टैटिक और फ़िशन के साथ C++ टेस्ट बनाने पर, टेस्ट बाइनरी के लिए भी .dwp फ़ाइल अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h": cc_proto_library से बनाई जाने वाली हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc": cc_proto_library से बनाई जाने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत": Proto_library में, वैकल्पिक Java api वर्शन के लिए अतिरिक्त कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_proto_extra_actions डिफ़ॉल्ट: "गलत": Proto_library में, वैकल्पिक Java api वर्शन के लिए अतिरिक्त कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत": चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को, कंपाइलेशन के आउटपुट के तौर पर सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> डिफ़ॉल्ट: "नहीं": यह बताता है कि C++ के कंपाइलेशन और लिंक के लिए कौनसे कंपाइलेशन मोड, फ़्रैशन का इस्तेमाल करते हैं. यह सभी मोड चालू करने के लिए, {'Fastbuild', 'dbg', 'opt'} या विशेष वैल्यू 'yes' का कोई भी कॉम्बिनेशन हो सकता है और सभी मोड बंद करने के लिए 'no' का कोई भी कॉम्बिनेशन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही": सही होने पर, नेटिव नियम अपनी रनफ़ाइल में <code>DefaultInfo.files</code> डेटा डिपेंडेंसी जोड़ देते हैं. यह Starlark के नियमों (https://bazel.build/extending/rules#runfiles_features_to_avoid) के लिए सुझाए गए तरीके से मेल खाता है.
टैग: affects_outputs, incompatible_change
--[no]legacy_external_runfiles डिफ़ॉल्ट: "सही": अगर सही हो, तो रनफ़ाइल/डेटा स्टोर करने की जगह के लिए .runfiles/wsname/external/repo (.runfiles/repo) के अलावा, बाहरी डेटा स्टोर करने की जगहों के लिए, जंगलों को सिमलिंक करने वाला जंगल बनाएं.
टैग: affects_outputs
--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत": यह बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps डिफ़ॉल्ट: "गलत": अगर यह नीति सेट की जाती है, तो 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> डिफ़ॉल्ट: "armeabi-v7a": Android टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]android_databinding_use_androidx डिफ़ॉल्ट: "सही": AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटाबाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "सही": Android डेटाबाइंडिंग v2 का इस्तेमाल, 3.4.0 आर्ग्युमेंट के साथ करें. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद": इससे तय होता है कि जब कोई cc_binary साफ़ तौर पर शेयर की गई लाइब्रेरी नहीं बनाती है, तो Android के नियमों के C++ डिप डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बैजल यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "वर्णमाला": Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्ज़ेक्रूट के पाथ के हिसाब से क्रम में लगाया गया है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में, कॉन्फ़िगरेशन डायरेक्ट्री के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आने वाले क्रम में लगाया जाता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत": यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए रिसॉर्स को कम करने की सुविधा को चालू करती है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip डिफ़ॉल्ट: "ऑटो": Python के लिए एक्ज़ीक्यूटेबल ज़िप बनाएं. Windows पर, दूसरे प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs
--catalyst_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple Catalyst बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage डिफ़ॉल्ट: "गलत": अगर यह बताया जाता है, तो Bazel इंस्ट्रुमेंट कोड का इस्तेमाल करेगा और जहां तक मुमकिन हो, ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करेगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी भी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसकी जगह, 'bazel profile' निर्देश का इस्तेमाल करना चाहिए.
टैग: affects_outputs
--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "Fastbuild": वह मोड तय करें जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--conlyopt=<a string> बार कई बार इस्तेमाल किया गया है: C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs
--copt=<a string> बार कई बार इस्तेमाल किया गया है: जीसीसी को पास करने के दूसरे विकल्प.
टैग: action_command_lines, affects_outputs
--cpu=<a string> डिफ़ॉल्ट: "": टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs
--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: विवरण देखें: सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करके, कंपाइलेशन ऑप्टिमाइज़ करें. उस ZIP फ़ाइल के पूरे पाथ का नाम बताएं जिसमें प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल हो.
टैग: affects_outputs
--cs_fdo_instrument=<a string> डिफ़ॉल्ट: विवरण देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंटेशन से बाइनरी जनरेट करें. 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> बार कई बार इस्तेमाल किया गया है: हर --तय करें विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, आखिरी वैल्यू जीत जाती है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "डिफ़ॉल्ट": इससे तय होता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह चुनेगा कि उसे डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही": अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs
--[no]enable_runfiles डिफ़ॉल्ट: "ऑटो": रनफ़ाइल सिमलिंक ट्री चालू करें; डिफ़ॉल्ट रूप से, यह Windows और दूसरे प्लैटफ़ॉर्म पर बंद है.
टैग: affects_outputs
--experimental_action_listener=<a build target label> बार कई बार इस्तेमाल किया गया है: अब अलग-अलग पहलुओं के पक्ष में नहीं, बल्कि उनके सुझाव दिए गए हैं. मौजूदा बिल्ड ऐक्शन में अतिरिक्त_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental
--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत": APK में Java रिसॉर्स को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही": Android Databinding v2 का इस्तेमाल करें. इस फ़्लैग को इस्तेमाल करने की ज़रूरत नहीं है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत": यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए रिसॉर्स को कम करने की सुविधा को चालू करती है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत": dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत": अगर इसके बारे में बताया जाता है, तो Bazel, जनरेट की गई फ़ाइलों के लिए कवरेज की जानकारी भी जनरेट करेगा.
टैग: affects_outputs
--experimental_objc_fastbuild_options=<comma-separated list of options> डिफ़ॉल्ट: "-O0,-DDEBUG=1": यह स्ट्रिंग, objc फ़ास्ट बिल्ड कंपाइलर के विकल्पों के तौर पर इस्तेमाल करती है.
टैग: action_command_lines
--[no]experimental_omitfp डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो स्टैक करने के लिए libunwind का इस्तेमाल करें. साथ ही, इसे -fomit-frame-Pointer और -fasynchronous-unwind-tables की मदद से कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental
--experimental_output_paths=<off, content or strip> डिफ़ॉल्ट: "बंद": आउटपुट ट्री नियम में, आउटपुट लिखने के लिए किस मॉडल का इस्तेमाल करना चाहिए, खास तौर से मल्टी-प्लैटफ़ॉर्म या मल्टी-कॉन्फ़िगरेशन वाले बिल्ड के लिए. इस पर प्रयोग बहुत ज़्यादा किया जा रहा है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 देखें. स्टारलार्क कार्रवाइयां, '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 फ़ॉर्मैट में होनी चाहिए, जहां लेबल किसी प्लैटफ़ॉर्म के बारे में बताता है. साथ ही, आउटपुट पाथ में इस्तेमाल करने के लिए वैल्यू, पसंदीदा छोटा नाम है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_छिपने वाली यूआरएल सही से काम कर रही हो. नाम की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए छोटा नाम इस्तेमाल किया जाता है. सटीक स्कीम, एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है. सबसे पहले, बहुत कम मामलों में --platforms विकल्प में कोई एक वैल्यू नहीं होती. इसलिए, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए किसी छोटे नाम को --experimental_override_name_platform_in_इस_क्रिएटर ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_ बदलें_direct_legacy_heur होंगी, तो मौजूदा प्लैटफ़ॉर्म के लेबल के हिसाब से छोटे नाम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल आखिरी विकल्प के तौर पर किया जाता है.
टैग: affects_outputs, experimental
--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत": अगर इसके बारे में बताया गया है, तो पेज पर इकट्ठा करने के लिए कोड इकट्ठा करने की सुविधा चालू होने पर, Bazel, gcov के बजाय llvm-cov कवरेज वाले मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental
--[no]experimental_use_platforms_in_output_dir_legacy_heuristic डिफ़ॉल्ट: "सही": कृपया इस फ़्लैग का इस्तेमाल, माइग्रेट करने या टेस्टिंग की सुझाई गई रणनीति के हिस्से के तौर पर ही करें. ध्यान दें कि अनुभव से जुड़े डेटा में कमियां हैं और हमारा सुझाव है कि सिर्फ़ --experimental_override_name_platform_in_इसी आउटपुट_डायर का इस्तेमाल करके माइग्रेट करें.
टैग: affects_outputs, experimental
--fat_apk_cpu=<comma-separated set of options> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "गलत": बिना किसी बटन वाला फ़्लैग. इसे आने वाली रिलीज़ से हटा दिया जाएगा.
टैग: no_op
--fdo_instrument=<a string> डिफ़ॉल्ट: विवरण देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर की मदद से, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान, डंप किया जाएगा.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: विवरण देखें: कम्यूनिटी को ऑप्टिमाइज़ करने के लिए, एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री, ऑटो प्रोफ़ाइल वाली 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 डिफ़ॉल्ट: "गलत": अगर यह सेटिंग चालू होती है, तो सभी 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> डिफ़ॉल्ट: "ऑप्ट": वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल होंगे. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines
--host_conlyopt=<a string> बार कई बार इस्तेमाल किया गया है: एक्ज़ीक्यूशन कॉन्फ़िगरेशन में C (लेकिन C++ नहीं) सोर्स फ़ाइलों को कंपाइल करते समय, C कंपाइलर को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs
--host_copt=<a string> बार कई बार इस्तेमाल किया गया है: exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के दूसरे विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> डिफ़ॉल्ट: "": होस्ट के लिए सीपीयू.
टैग: 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> बार कई बार इस्तेमाल किया गया है: exec कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने का एक और विकल्प.
टैग: 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/ में bar.cc. को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन जोड़ता है.
टैग: action_command_lines, affects_outputs
--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "गलत": चालू होने पर, किसी नियम से इस्तेमाल की जाने वाली हर टूलचेन के लिए, एक एक्ज़ेक्यूटिव ग्रुप अपने-आप बन जाता है. यह नियम काम करे, इसके लिए कार्रवाइयों पर `toolchain` पैरामीटर तय करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 देखें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही": अगर सही है, तो जेनफ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change
--[no]instrument_test_targets डिफ़ॉल्ट: "गलत": कवरेज की सुविधा चालू होने पर, इससे पता चलता है कि टेस्ट के नियमों को लागू करने पर विचार करना है या नहीं. यह नीति सेट होने पर, --instrumentation_filter से शामिल किए गए टेस्ट नियम लागू होते हैं. ऐसा न होने पर, टेस्ट के नियमों को कवरेज इंस्ट्रुमेंटेशन से हमेशा बाहर रखा जाता है.
टैग: affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/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_ऐप्लिकेशन बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें बताए गए सभी आर्किटेक्चर शामिल हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive डिफ़ॉल्ट: "सही": अब काम नहीं करता, इसकी जगह ले ली गई है --insupported_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> बार कई बार इस्तेमाल किया गया है: एलटीओ बैकएंड चरण को पास करने का एक और विकल्प (--features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs
--ltoindexopt=<a string> बार कई बार इस्तेमाल किया गया है: एलटीओ को इंडेक्स करने के चरण को पास करने का एक और विकल्प (-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 डिफ़ॉल्ट: "गलत": अगर यह नीति सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines
--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत": लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --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 बैकएंड (-features=thin_lto के तहत) को चुनिंदा तरीके से पास करने के अन्य विकल्प. यह विकल्प कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां रेगुलर एक्सप्रेशन फ़िल्टर, शामिल किए गए और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची दिखाता है. 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> डिफ़ॉल्ट: विवरण देखें: बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, प्रोपेलर प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोपेलर प्रोफ़ाइल में कम से कम एक फ़ाइल होनी चाहिए. एक cc प्रोफ़ाइल और ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल स्वीकार करता है, जिसे प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, a/b/BUILD: मिटा देने वाली फ़ाइल का लेबल तय करने वाली BUILD फ़ाइल, जो कि a/b/BUILD: मिटानी-बढ़ाने से जुड़ी जानकारी( name = "propler_profile", cc_profile = "propler_cc_profile.txt", ld_profile = "profiller_ld_profile.txt",) में लेबल को परिभाषित करने वाली BUILD फ़ाइल हो सकती है. Export_files डायरेक्टिव को, Bazel को दिखाने के लिए संबंधित पैकेज में जोड़ना पड़ सकता है. विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --propler_optimize=//a/b:propler_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: विवरण देखें: प्रोपेलर ऑप्टिमाइज़ किए गए बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: विवरण देखें: प्रोपेलर ऑप्टिमाइज़ किए गए बिल्ड के लिए ld_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: विवरण देखें: 'जांच करें' और 'रन' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले शामिल करने के लिए उपसर्ग. अगर वैल्यू '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 डिफ़ॉल्ट: "सही": अगर सही है, तो एक जैसी काम करने वाली नेटिव लाइब्रेरी, अलग-अलग टारगेट के बीच शेयर की जाएंगी
टैग: loading_and_analysis, affects_outputs
--[no]stamp डिफ़ॉल्ट: "गलत": तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह के साथ बाइनरी बनाएं.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह बताता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं ("-Wl,--strip-debug" का इस्तेमाल करके). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि स्ट्रिप iff --compilation_mode=foundbuild.
टैग: affects_outputs
--stripopt=<a string> बार कई बार इस्तेमाल किया गया है: '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs
--tvos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple tvOS बाइनरी बनाने हैं.
टैग: loses_incremental_state, loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाला tvOS वर्शन. अगर इसकी जानकारी नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state
--visionos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple visionOS बाइनरी बनाने हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_cpus=<comma-separated list of options> बार कई बार इस्तेमाल किया गया है: कॉमा-सेपरेटेड आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: विवरण देखें: टारगेट सिम्युलेटर और डिवाइसों के लिए, स्मार्टवॉच के कम से कम वर्शन के साथ काम करने वाला वर्शन. अगर इसकी जानकारी नहीं दी गई है, तो 'watchos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state
--xbinary_fdo=<a build target label> डिफ़ॉल्ट: विवरण देखें: डेटा कंपाइलेशन ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_ड़ियों/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू होते हैं, जैसे कि xbinary_fdo को कभी तय नहीं किया गया हो.
टैग: affects_outputs

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: "": Environment_group का एलान करें, ताकि target_environment वैल्यू के लिए सीपीयू वैल्यू को अपने-आप मैप करने के लिए, इसका इस्तेमाल किया जा सके.
टैग: changes_inputs, loading_and_analysis, experimental
--[no]check_licenses डिफ़ॉल्ट: "गलत": इस बात की जांच करें कि डिपेंडेंट पैकेज ने जो लाइसेंसिंग पाबंदियां लगाई हैं वे बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर न डाल रही हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग: build_file_semantics
--[no]check_visibility डिफ़ॉल्ट: "सही": यह सेटिंग बंद होने पर, टारगेट डिपेंडेंसी में 'किसको दिखे' सेटिंग से जुड़ी गड़बड़ियां, चेतावनियों के तौर पर मार्क हो जाती हैं.
टैग: build_file_semantics
--[no]desugar_for_android डिफ़ॉल्ट: "सही": डेक्सिंग से पहले, Java 8 बाइटकोड को डिसुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]desugar_java8_libs डिफ़ॉल्ट: "गलत": लेगसी डिवाइसों के लिए, ऐप्लिकेशन में काम करने वाली Java 8 लाइब्रेरी शामिल करनी है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental
--[no]enforce_constraints डिफ़ॉल्ट: "सही": यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर कोई टारगेट ऐसी डिपेंडेंसी है जो एक जैसे एनवायरमेंट के साथ काम नहीं करती, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics
--[no]experimental_check_desugar_deps डिफ़ॉल्ट: "सही": 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> डिफ़ॉल्ट: "डिफ़ॉल्ट": सही होने पर, यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए जाने वाले सभी टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit
--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "गलत": अगर यह सुविधा चालू है, तो आउटपुट फ़ाइल वाले ज़रूरी टारगेट के लिए testonly का इस्तेमाल करें. इसके लिए, जनरेट करने वाले नियम का सिर्फ़ टेस्ट देखें. यह 'किसको दिखे' सेटिंग से मेल खाता है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "गलत": चालू होने पर, विज़िबिलिटी की जांच करने की सुविधा, टूलचेन लागू करने की सुविधा पर भी लागू होती है.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "गलत": इस सुविधा के चालू होने पर, Android के मूल नियमों का सीधे तौर पर इस्तेमाल करने की सुविधा बंद हो जाती है. कृपया https://github.com/bazelbuild/rules_android से गए Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "गलत": नहीं. पुराने सिस्टम के साथ काम करने के लिए, इसे यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change
--[no]incompatible_python_disable_py2 डिफ़ॉल्ट: "सही": अगर सही है, तो 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 डिफ़ॉल्ट: "सही": यह फ़्लैग अभी नहीं बनाया गया है और इसे हटाने के लिए शेड्यूल किया गया है.
टैग: no_op, incompatible_change
--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: विवरण देखें: -insupported_python_disallow_native_rules लागू करने के लिए, अनुमति वाली सूची (package_group target) का इस्तेमाल करें.
टैग: loading_and_analysis
--[no]strict_filesets डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू किया जाता है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "गड़बड़ी": जब तक बंद न हो, तब तक यह जांच करता है कि कोई proto_library टारगेट साफ़ तौर पर सभी सीधे इस्तेमाल किए जाने वाले टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद": जब तक बंद न हो, तब तक यह जांच करता है कि कोई proto_library टारगेट साफ़ तौर पर 'इंपोर्ट करें' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट किए गए के तौर पर बताए.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes डिफ़ॉल्ट: "गलत": अगर सही है, तो सिस्टम से मिलने वाले हेडर में पाथ (-isystem) को शामिल करना भी ज़रूरी होता है.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> बार कई बार इस्तेमाल किया गया है: इस बिल्ड के टारगेट एनवायरमेंट का एलान करता है. "एनवायरमेंट" नियम के लेबल का रेफ़रंस होना चाहिए. अगर तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने वाले होने चाहिए.
टैग: changes_inputs

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

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत": अगर supported_enforce_config_setting_activity=false है, तो यह नॉप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो ऐसी कोई भी config_setting जिसके लिए साफ़ तौर पर दिखने वाला एट्रिब्यूट मौजूद नहीं है //visibility:public. अगर यह फ़्लैग सही है, तो config_setting उसी लॉजिक का पालन करती है जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही": नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "गलत": अगर सही हो, तो objc_library andobjc_Import में जाकर SDK_frameworks और social_sdk_frameworks के एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही": अगर सही है, तो config_setting को लागू करने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत": अगर सही है, तो objc_library और objc_Import में हमेशा लिंक की सुविधा वाली वैल्यू के लिए, डिफ़ॉल्ट वैल्यू को 'सही' के तौर पर सेट करें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत": सही होने पर, बिल्टइन py_* नियमों का इस्तेमाल करते समय कोई गड़बड़ी होती है; इसके बजाय, Rules_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत": सही होने पर, नियम को टारगेट करने से विश्लेषण नहीं हो पाता है. इसका नतीजा यह होता है कि टारगेट, गड़बड़ी की जानकारी वाले विश्लेषणFailureInfo के इंस्टेंस को लागू नहीं करेगा, न कि बिल्ड फ़ेल हो जाएगा.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट की मदद से, ज़्यादा से ज़्यादा ट्रांज़िटिव डिपेंडेंसी सेट करता है. इस सीमा को पार करने से नियम में गड़बड़ी होगी.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत": अगर सही dex2oat कार्रवाई के पूरा न हो पाने पर, टेस्ट रनटाइम के दौरान dex2oat को एक्ज़ीक्यूट करने के बजाय बिल्ड टूट जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> बार कई बार इस्तेमाल किया गया है: टेस्ट के लिए, रिसॉर्स की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर कोई पॉज़िटिव नंबर <value> के तौर पर दिया गया है, तो वह जांच के लिए इस्तेमाल किए जाने वाले सभी साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगा. अगर कॉमा लगाकर अलग की गई चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बड़े साइज़ के टेस्ट साइज़ के लिए, रिसॉर्स की संख्या को बदल देंगी. वैल्यू Host_RAM/Host_CPU भी हो सकती है. विकल्प के तौर पर, इसके बाद [-|*]<float> (जैसे कि मेमोरी=Host_RAM*.1,Host_RAM*.2,Host_RAM*.3,Host_RAM*.4) भी हो सकते हैं. इस फ़्लैग से तय किए गए जांच वाले डिफ़ॉल्ट रिसॉर्स, टैग में बताए गए साफ़ तौर पर उपलब्ध रिसॉर्स से बदल जाते हैं.
--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "गलत": android_test की स्पीड बढ़ाने के लिए, dex2oat का साथ-साथ इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental
--[no]ios_memleaks डिफ़ॉल्ट: "गलत": 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. जहां Run_per_test का मतलब पूर्णांक वैल्यू होती है और regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल और बाहर करने की सूची दिखाता है. इसके अलावा, --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में सभी टेस्ट चलाता है. हालांकि, foo/bar से कम वाले टेस्ट तीन बार किए जाते हैं. यह विकल्प कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए आर्ग्युमेंट को प्राथमिकता दी जाती है. अगर कुछ भी मैच नहीं करता है, तो जांच सिर्फ़ एक बार की जाती है.
--test_env=<a 'name=value' assignment with an optional value part> बार कई बार इस्तेमाल किया गया है: टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट या name=value पेयर से पढ़ी जाएगी. कई वैरिएबल के बारे में बताने के लिए, इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
टैग: test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1": टेस्ट के टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर कोई एक पॉज़िटिव पूर्णांक मान दिया गया है, तो वह सभी कैटगरी को ओवरराइड कर देगा. अगर कॉमा लगाकर अलग किए गए चार पूर्णांकों का पता लगाया जाता है, तो वे छोटे, सामान्य, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. किसी भी रूप में, -1 की वैल्यू ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहती है.
--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही": अगर सही है, तो टेस्ट के ऐसे आउटपुट ZIP फ़ाइल में संग्रहित किए जाएंगे जिनका एलान नहीं किया गया है.
टैग: test_runner

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव": आउटपुट फ़ॉर्मैट {xml,proto,record} में होने पर, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को कैसे ठीक करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान किए गए सभी पहलू डिपेंडेंसी जोड़े जाते हैं. इस बात से कोई फ़र्क़ नहीं पड़ता कि उन्हें डायरेक्ट डिपेंडेंसी के नियम की क्लास दी गई है या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी के नियम क्लास के आधार पर संभावित तौर पर ऐक्टिव हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट का आकलन करने के लिए, दूसरे पैकेज को लोड करना ज़रूरी है. इससे यह अन्य मोड की तुलना में धीमा हो जाएगा. इस बात का भी ध्यान रखें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में तय किया जाता है. यह प्रोसेस, 'बैजल क्वेरी' के दौरान नहीं चलाई जाती.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से लेबल निकलते हैं, जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन का इस्तेमाल किया जाता है. यह उन टूल के लिए फ़ायदेमंद है जिन्हें नियमों से निकलने वाले अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इसे चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैटर, आउटपुट को ज़्यादा पढ़ने लायक बनाने के बजाय, साफ़ तौर पर रिपॉज़िटरी के नाम (मुख्य डेटा स्टोर करने की जगह के हिसाब से) का इस्तेमाल कर सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]graph:factored डिफ़ॉल्ट: "सही": अगर सही है, तो ग्राफ़ पर 'फ़ैक्टर' उत्सर्जित होगा. इसका मतलब है कि टॉपॉलॉजिकल रूप से समान नोड एक साथ मर्ज कर दिए जाएंगे और उनके लेबल जोड़े जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> डिफ़ॉल्ट: "512": आउटपुट में ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल में काट-छांट की जाएगी; -1 का मतलब है कि कोई काट-छांट नहीं होगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel से जोड़ा गया है. cquery के लिए यह विकल्प, समाधान किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_aspects डिफ़ॉल्ट: "सही": क्वेरी, क्वेरी: आउटपुट में पहलू के आधार पर जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (जवाबों को हमेशा फ़ॉलो किया जाता है).
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, इसके पहले `//` को हटाया नहीं जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "गलत": अगर सेट और --universe_scope सेट नहीं है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई, --universe_scope वैल्यू आपकी पसंद के मुताबिक नहीं हो सकती. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है (यानी `cquery` नहीं).
टैग: loading_and_analysis
--[no]line_terminator_null डिफ़ॉल्ट: "गलत": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म करना है.
टैग: terminal_output
--[no]nodep_deps डिफ़ॉल्ट: "सही": अगर इसे चालू किया जाता है, तो "nodep" एट्रिब्यूट के डिपेंस को उस डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics
--output=<a string> डिफ़ॉल्ट: "लेबल": वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_ kind, textproto, migrations, proto, टैग किए गए प्रोटो, jsonproto. अगर आपने 'transitions' चुना है, तो आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": सही होने पर, उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": definition_stack प्रोटो फ़ील्ड को भरें, जो नियम की क्लास तय होने के समय Starlark कॉल स्टैक के हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो select() से बनाए गए कॉन्फ़िगर करने लायक एट्रिब्यूट बराबर हो जाते हैं. सूची टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप की वैल्यू शून्य हो जाती है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स पहलू के साथ भरें जिससे एट्रिब्यूट मिला है (अगर ऐसा नहीं है, तो खाली स्ट्रिंग).
टैग: terminal_output
--[no]proto:include_configurations डिफ़ॉल्ट: "सही": चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत": $internal_attr_has एट्रिब्यूट का हिसाब लगाना है या नहीं, इसका पता लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत": हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग: terminal_output
--[no]proto:locations डिफ़ॉल्ट: "सही": प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "सभी": आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. कोई एट्रिब्यूट आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर क्वेरी को सेट किया जाता है, तो कमांड लाइन के बजाय, यहां दी गई फ़ाइल का नाम पढ़कर सुनाया जाएगा. यहां फ़ाइल और कमांड लाइन क्वेरी के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक ऐब्सलूट पाथ होता है और यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--show_config_fragments=<off, direct or transitive> डिफ़ॉल्ट: "बंद": नियम और उसकी ट्रांज़िटिव डिपेंडेंसी के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट दिखाता है. इससे, यह आकलन करने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ में कितने हिस्से में काट-छांट की जा सकती है.
टैग: affects_outputs
--starlark:expr=<a string> डिफ़ॉल्ट: "": कॉन्फ़िगर किए गए हर टारगेट को cquery के --OUT=starlark मोड में फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट 'टारगेट' से जुड़ा है. अगर --starlark:expr या --starlark:file तय नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट होगा. --starlark:expr और --starlark:file दोनों देते समय कोई गड़बड़ी हुई है.
टैग: terminal_output
--starlark:file=<a string> डिफ़ॉल्ट: "": स्टारलार्क फ़ंक्शन को तय करने वाली फ़ाइल का नाम, जिसे 'फ़ॉर्मैट' कहा जाता है. यह एक तर्क का होता है. इसे कॉन्फ़िगर किए गए हर टारगेट पर लागू करके, एक स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. --starlark:expr और --starlark:file दोनों देते समय कोई गड़बड़ी हुई है. ज़्यादा जानकारी के लिए --आउटपुट=स्टारलार्क के लिए सहायता देखें.
टैग: terminal_output
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: बंद होने पर, क्वेरी को ऑपरेट करने वाले डिपेंडेंसी ग्राफ़ में 'exec कॉन्फ़िगरेशन' की डिपेंडेंसी शामिल नहीं होंगी. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसा कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक जाता है. आम तौर पर, यह एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल को पॉइंट करता है. Cquery: यह विकल्प बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट exec कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए exec टारगेट दिखाए जाएंगे. इस विकल्प में ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग: build_file_semantics
--transitions=<full, lite or none> डिफ़ॉल्ट: "कोई नहीं": वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगा.
टैग: affects_outputs
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा और घटाव). क्वेरी को यूनिवर्स में परफ़ॉर्म किया जा सकता है. इसके लिए, दिए गए टारगेट को हमेशा के लिए बंद करना होगा. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माने जाते हैं. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए, इस विकल्प को तय न करने से बिल्ड में रुकावट आ सकती है.
टैग: loading_and_analysis

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

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "गलत": LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग: action_command_lines
--[no]experimental_inmemory_dotd_files डिफ़ॉल्ट: "सही": अगर C++ .d फ़ाइलें चालू की जाती हैं, तो उन्हें डिस्क पर सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_inmemory_jdeps_files डिफ़ॉल्ट: "सही": चालू होने पर, Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क पर सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental
--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत": इस सुविधा को चालू करने पर, --trim_test_ Configuration, सिर्फ़ testonly=1 मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन में काट-छांट नहीं करेगा. इसका मकसद, कार्रवाई से जुड़े विवाद की समस्याओं को कम करना है. ऐसा तब किया जाता है, जब गैर-जांच नियम cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_कॉन्फ़िगरेशन गलत है, तो कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state
--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental
--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "गलत": इनपुट फ़ाइलों से #include लाइनों को पार्स करके, इनपुट को C/C++ कंपाइलेशन में बदलना है या नहीं. यह कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और बढ़ोतरी को बेहतर बना सकता है. हालांकि, इससे बिल्ड टूट भी सकते हैं, क्योंकि शामिल स्कैनर, C प्रीप्रोसेसर सिमैंटिक को पूरी तरह लागू नहीं करता. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर के कंडीशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. अगर इस फ़्लैग से जुड़ी कोई समस्या है, तो उसे बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs
--[no]incremental_dexing डिफ़ॉल्ट: "सही": ज़्यादातर जार फ़ाइल को डीक्स करने का ज़्यादातर काम अलग-अलग किया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही": अगर इस नीति को सेट किया जाता है, तो clang से उत्सर्जित होने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइलेशन में पास किए गए इनपुट के सेट को हटाने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत": टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग: execution
--[no]trim_test_configuration डिफ़ॉल्ट: "सही": यह सुविधा चालू होने पर, बिल्ड के टॉप लेवल के नीचे जांच से जुड़े विकल्प हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को गैर-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में किए जाने वाले बदलावों की वजह से, टेस्ट न करने वाले नियमों का फिर से विश्लेषण नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state

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

--flag_alias=<a 'name=value' flag alias> बार कई बार इस्तेमाल किया गया है: स्टारलार्क फ़्लैग के लिए, यह छोटा नाम सेट करता है. यह तर्क के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर होता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत": यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बन जाएं. आम तौर पर, जब किसी py_binary या py_test टारगेट में lead_create_init को "ऑटो" (डिफ़ॉल्ट) पर सेट किया जाता है, तो यह 'गलत' के तौर पर तब ही माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही": अगर 'सही' है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इसमें '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स शामिल नहीं है. इसका मतलब है कि `bazel-bin` सुविधा का सिमलिंक, Python 2 के बजाय Python 3 के टारगेट को पॉइंट करेगा. अगर इस विकल्प को चालू किया जाता है, तो `--insupported_py3_is_default` को चालू करने का भी सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही": सही होने पर, `py_binary` और `py_test` एट्रिब्यूट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. अगर इस फ़्लैग को सेट किया जाता है, तो `--insupported_py2_OUTs_are_suffixed` को सेट करने का सुझाव भी दिया जाता है.
टैग: loading_and_analysis, affects_outputs, incompatible_change
--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो एक्ज़ीक्यूटेबल नेटिव Python नियम, --python_top जैसे लेगसी फ़्लैग से दिए गए रनटाइम के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल करेंगे.
टैग: 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] डिफ़ॉल्ट: "ऑटो": अगर यह नीति 'ऑटो' पर सेट है, तो Bazel फिर से टेस्ट तब करता है, जब: (1) Bazel को, जांच में हुए बदलाव या उसकी डिपेंडेंसी का पता चलता हो, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test की मदद से कई बार टेस्ट करने का अनुरोध किया गया हो या(4) जांच पहले असफल हो गई हो. अगर यह नीति 'हां' पर सेट है, तो बाहरी के तौर पर मार्क किए गए टेस्ट के अलावा, Bazel जांच के सभी नतीजों को कैश मेमोरी में सेव करेगा. अगर यह नीति 'नहीं' पर सेट है, तो Bazel जांच के किसी भी नतीजे को कैश मेमोरी में सेव नहीं करेगा.
--deleted_packages=<comma-separated list of package names> बार कई बार इस्तेमाल किया गया है: ऐसे पैकेज के नामों की कॉमा-सेपरेटेड लिस्ट जिन्हें बिल्ड सिस्टम अपने-आप नहीं मानेगा, भले ही वे पैकेज पाथ में कहीं भी दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD को मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, लेकिन वह अब भी किसी दूसरी Package_path एंट्री में मौजूद है, तो इसकी शिकायत हो सकती है. --deleted_packages x/y को तय करने से इस समस्या से बचा जा सकता है.
--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत": सही होने पर, Blaze पहले सफल रन पर एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ इस्तेमाल करने पर ही काम करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत": अगर वैल्यू सही है, तो Bazel, कवरेज के दौरान हर टेस्ट के लिए पूरी कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "गलत": अगर सही है, तो क्लैंग के लिए कवरेज, एलसीओवी रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis
--[no]experimental_j2objc_header_map डिफ़ॉल्ट: "सही": J2ObjC ट्रांसपिलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "गलत": छोटे हेडर पाथ के साथ जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग: affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javaBuilder": Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ चालू करें.
--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत": Android के साथ काम करने वाली लाइब्रेरी तक --experimental_run_android_lint_on_java_rules पर सीमित करें.
टैग: affects_outputs
--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत": Java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs
--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत": टेस्टरनर के डिप से गलती से डेटा हासिल करने के बजाय, java_test में JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ बैजल के लिए काम करता है.
--[no]fetch डिफ़ॉल्ट: "सही": निर्देश को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति देता है. अगर 'गलत है' पर सेट किया जाता है, तो यह निर्देश, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. कोई निर्देश मौजूद न होने पर, निर्देश काम नहीं करेगा.
--host_java_launcher=<a build target label> डिफ़ॉल्ट: विवरण देखें: यह Java लॉन्चर, उन टूल में इस्तेमाल होता है जो बिल्ड होने के दौरान एक्ज़ीक्यूट होते हैं.
--host_javacopt=<a string> बार कई बार इस्तेमाल किया गया है: किसी बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल बनाते समय, javac को पास करने के ज़्यादा विकल्प.
--host_jvmopt=<a string> बार कई बार इस्तेमाल किया गया है: बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, Java वीएम को पास करने के ज़्यादा विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही": अगर सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि उसके पाथ में फ़ाइल को TEST_SHARD_STATUS_FILE में जोड़ा जा सकता है, तो Bazel शार्ड किए गए टेस्ट को फ़ेल कर देगा. गलत होने पर, अगर शार्डिंग की सुविधा काम नहीं करती, तो टेस्ट रनर की वजह से हर शार्ड में सभी टेस्ट चल रहे होंगे.
टैग: incompatible_change
--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही": अगर सही है, तो सैंडबॉक्स रणनीति की मदद से खास टेस्ट चलाए जाएंगे. सिर्फ़ स्थानीय स्तर पर टेस्ट चलाने के लिए 'लोकल' टैग जोड़ें
टैग: incompatible_change
--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत": अगर सही है, तो 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_internal=streamed को शामिल किया गया है.
इसमें शामिल है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results
--[no]java_deps डिफ़ॉल्ट: "सही": हर Java टारगेट के लिए डिपेंडेंसी जानकारी (अभी, कंपाइल-टाइम क्लासपाथ) जनरेट करें.
--[no]java_header_compilation डिफ़ॉल्ट: "सही": सीधे सोर्स से जरार इकट्ठा करें.
--java_language_version=<a string> डिफ़ॉल्ट: "": जावा भाषा का वर्शन
--java_launcher=<a build target label> डिफ़ॉल्ट: विवरण देखें: Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर यह फ़्लैग खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.
--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk": जावा रनटाइम वर्शन
--javacopt=<a string> बार कई बार इस्तेमाल किया गया है: javac पर भेजने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string> बार कई बार इस्तेमाल किया गया है: Java वीएम को पास करने के दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: विवरण देखें: ऐसी क्लास की सूची जनरेट करने के लिए बाइनरी के बारे में बताता है जिसका इस्तेमाल लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य dex में होना चाहिए.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: विवरण देखें: बिना शार्डिंग के डेक्सिंग करने के लिए, बाइनरी के बारे में बताता है.
--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain": proto_lang_toolchain() का लेबल जिसमें C++ Protos को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain": proto_lang_toolchain() का लेबल जिसमें Java Protos को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@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 डिफ़ॉल्ट: "गलत": अगर सही हो, तो कम से कम एक रन/अटेंप्ट में पास होने पर और कम से कम एक रन/अटैम फ़ेल होने पर उसे 'फ़्लेकी' स्टेटस मिल जाता है.
--shell_executable=<a path> डिफ़ॉल्ट: विवरण देखें: BZel के इस्तेमाल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को पहले Bazel सर्वर पर सेट किया गया है, जो Bazel सर्वर को शुरू करता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करेगा. यह उस ऑपरेटिंग सिस्टम के हिसाब से तय होगा जिस पर वह चलता है (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash). ध्यान दें कि अगर किसी ऐसे शेल का इस्तेमाल किया जाता है जो बैश के साथ काम नहीं करता, तो जनरेट की गई बाइनरी के रनटाइम या रनटाइम फ़ेल हो सकते हैं.
टैग: loading_and_analysis
--[no]show_loading_progress डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो Bazel "Loadingpackage:" मैसेज प्रिंट करेगा.
--test_arg=<a string> बार कई बार इस्तेमाल किया गया है: उन अतिरिक्त विकल्पों और तर्क के बारे में बताता है जिन्हें टेस्ट एक्ज़ीक्यूटेबल के लिए पास किया जाना चाहिए. अलग-अलग आर्ग्युमेंट का इस्तेमाल करने के लिए, एक से ज़्यादा बार इस्तेमाल किया जा सकता है. अगर कई जांच की जाती हैं, तो सभी को एक जैसे तर्क मिलेंगे. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
--test_filter=<a string> डिफ़ॉल्ट: विवरण देखें: टेस्ट फ़्रेमवर्क पर भेजने के लिए एक फ़िल्टर तय करता है. इसका इस्तेमाल, जांच को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे बनाए गए टारगेट पर कोई असर नहीं पड़ता.
--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1": यह विकल्प अब काम नहीं करता और इसका कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत": टेस्ट रनर पर तेज़ी से फ़ॉरवर्ड करने का विकल्प फ़ेल हो गया. पहली बार असफल होने पर, टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "अश्लील": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'साफ़ तौर पर' शार्डिंग का इस्तेमाल सिर्फ़ तब करें, जब 'sard_count' BUILD एट्रिब्यूट मौजूद हो. टेस्ट शार्डिंग का इस्तेमाल कभी नहीं करने के लिए 'बंद' है. 'forced=k' की मदद से, जांच के लिए 'k' शार्ड लागू किए जा सकते हैं, भले ही 's आम तौर पर काउंट' BUILD एट्रिब्यूट कुछ भी हो.
--tool_java_language_version=<a string> डिफ़ॉल्ट: "": जावा भाषा का वर्शन, जिसका इस्तेमाल उन टूल को चलाने के लिए किया जाता है जो बिल्ड बनाने के दौरान ज़रूरी होते हैं
--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11": बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन
--[no]use_ijars डिफ़ॉल्ट: "सही": अगर यह विकल्प चालू है, तो इस विकल्प की वजह से Java कंपाइलेशन में इंटरफ़ेस जार का इस्तेमाल होता है. इससे, कंपाइलेशन तेज़ी से बढ़ेगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.
--help_verbosity=<long, medium or short> डिफ़ॉल्ट: "मीडियम": यह चुनें कि सहायता निर्देश में कितनी शब्दों का इस्तेमाल किया जाए.
टैग: terminal_output
--long [-l]: हर विकल्प के नाम की जगह उसकी पूरी जानकारी दिखाएं.
इसमें बड़ा होता है:
--help_verbosity=long

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

टैग: terminal_output

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

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

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

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

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.
--[no]show_make_env डिफ़ॉल्ट: "गलत": आउटपुट में "बनाएं" एनवायरमेंट शामिल करें.
टैग: affects_outputs, terminal_output

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

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

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

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

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

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

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

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

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

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

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

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

टैग: execution

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.
--incremental_install_verbosity=<a string> डिफ़ॉल्ट: "": इंक्रीमेंटल इंस्टॉल के लिए कितने शब्दों में जानकारी दी जाए. डीबग लॉग करने के लिए, वैल्यू को 1 पर सेट करें.
टैग: bazel_monitoring

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

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

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

मॉड के विकल्प

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": इस्तेमाल की गई मेमोरी का प्रतिशत (0-100) और इससे ज़्यादा GcTtrazingDetector, मेमोरी दबाव की घटनाओं को अपनी सीमा के हिसाब से (--gc_thrazing_limits). अगर इस नीति को 100 पर सेट किया जाता है, तो GcThrgingDetector को बंद कर दिया जाता है.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": लोडिंग/विश्लेषण फ़ेज़ में इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. उदाहरण के लिए, "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

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

--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> डिफ़ॉल्ट: "<root>": ऐसा मॉड्यूल बताएं जिससे तय किए गए टारगेट डेटा स्टोर करने की जगह को समझा जाएगा.
टैग: terminal_output
--charset=<utf8 or ascii> डिफ़ॉल्ट: "utf8": ट्री के लिए इस्तेमाल करने के लिए वर्ण सेट चुनता है. सिर्फ़ टेक्स्ट आउटपुट पर असर पड़ता है. मान्य वैल्यू "utf8" या "ascii" हैं. डिफ़ॉल्ट "utf8" है
टैग: terminal_output
--[no]cycles डिफ़ॉल्ट: "गलत": दिखाए गए ट्री में डिपेंडेंसी साइकल की जानकारी देता है, जिन्हें आम तौर पर डिफ़ॉल्ट रूप से अनदेखा किया जाता है.
टैग: terminal_output
--depth=<an integer> डिफ़ॉल्ट: "-1": डिपेंडेंसी ट्री की ज़्यादा से ज़्यादा डिसप्ले डेप्थ. उदाहरण के लिए, 1 की डेप्थ डायरेक्ट डिपेंडेंसी दिखाता है. ट्री, पाथ, और all_paths के लिए, यह डिफ़ॉल्ट रूप से Integer.MAX_VALUE होता है. वहीं, डिप्स और यह वैल्यू 1 के लिए डिफ़ॉल्ट रूप से 1 होता है. यह टारगेट किए गए पत्तों और उनके पैरंट के अलावा, सिर्फ़ रूट की पूरी जानकारी दिखाता है.
टैग: terminal_output
--extension_filter=<a comma-separated list of <extension>s> डिफ़ॉल्ट: विवरण देखें: इन मॉड्यूल एक्सटेंशन के इस्तेमाल और इनसे जनरेट हुए डेटा को सिर्फ़ तब दिखाएं, जब इनसे जुड़े फ़्लैग सेट हों. अगर यह सेट किया जाता है, तो नतीजे के ग्राफ़ में सिर्फ़ ऐसे पाथ शामिल किए जाएंगे जिनमें दिए गए एक्सटेंशन का इस्तेमाल करने वाले मॉड्यूल मौजूद हों. खाली सूची से, फ़िल्टर बंद हो जाता है और सभी संभावित एक्सटेंशन लागू हो जाते हैं.
टैग: terminal_output
--extension_info=<hidden, usages, repos or all> डिफ़ॉल्ट: "छिपाया गया": तय करें कि क्वेरी के नतीजे में एक्सटेंशन के इस्तेमाल के बारे में कितनी जानकारी शामिल करनी है. "इस्तेमाल" में सिर्फ़ एक्सटेंशन के नाम दिखेंगे. "repos" में, access_repo से इंपोर्ट किए गए डेटा स्टोर करने की जगहें भी शामिल होंगी, और "सभी" में, एक्सटेंशन से जनरेट किए गए दूसरे डेटा स्टोर करने की जगहें भी दिखेंगी.
टैग: terminal_output
--extension_usages=<a comma-separated list of <module>s> डिफ़ॉल्ट: "": ऐसे मॉड्यूल तय करें जिनके एक्सटेंशन का इस्तेमाल Show_extension क्वेरी में दिखाया जाएगा.
टैग: terminal_output
--from=<a comma-separated list of <module>s> डिफ़ॉल्ट: "<root>": ऐसे मॉड्यूल जिनसे शुरू होने वाले डिपेंडेंसी ग्राफ़ क्वेरी दिखेगी. सही सिमैंटिक के लिए हर क्वेरी के ब्यौरे की जांच करें. डिफ़ॉल्ट <root>.
टैग: terminal_output
--[no]include_builtin डिफ़ॉल्ट: "गलत": डिपेंडेंसी ग्राफ़ में, बिल्ट-इन मॉड्यूल शामिल करें. डिफ़ॉल्ट रूप से बंद होता है, क्योंकि इसमें काफ़ी शोर होता है.
टैग: terminal_output
--[no]include_unused डिफ़ॉल्ट: "गलत": क्वेरी में, इस्तेमाल न किए जाने वाले मॉड्यूल का भी ध्यान रखा जाएगा, जो चुने जाने के बाद मॉड्यूल रिज़ॉल्यूशन ग्राफ़ में मौजूद नहीं होते. ऐसा मिनिमम-वर्शन चुनने या बदलने के नियमों की वजह से होता है. हर क्वेरी टाइप पर इसका अलग-अलग असर हो सकता है. जैसे, all_paths कमांड में नए पाथ शामिल करना या एक्सप्लेनेशन कमांड में अतिरिक्त डिपेंडेंट शामिल करना.
टैग: terminal_output
--output=<text, json or graph> डिफ़ॉल्ट: "text": वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए इन वैल्यू की अनुमति है: text, json, ग्राफ़
टैग: terminal_output
--[no]verbose डिफ़ॉल्ट: "गलत": क्वेरी में, मॉड्यूल को उनके मौजूदा वर्शन में ले जाने की वजह भी दिखेगी (अगर बदलाव किए गए हैं). डिफ़ॉल्ट तौर पर, यह वैल्यू सिर्फ़ जानकारी देने वाली क्वेरी के लिए 'सही' पर सेट होती है.
टैग: terminal_output

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

Print_action के विकल्प

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": इस्तेमाल की गई मेमोरी का प्रतिशत (0-100) और इससे ज़्यादा GcTtrazingDetector, मेमोरी दबाव की घटनाओं को अपनी सीमा के हिसाब से (--gc_thrazing_limits). अगर इस नीति को 100 पर सेट किया जाता है, तो GcThrgingDetector को बंद कर दिया जाता है.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": लोडिंग/विश्लेषण फ़ेज़ में इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. उदाहरण के लिए, "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

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

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

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

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

टैग: terminal_output
--output=<a string> डिफ़ॉल्ट: "लेबल": वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: बिल्ड, ग्राफ़, stream_jsonproto, लेबल, लेबल_काइंड, लोकेशन, maxrank, minrank, पैकेज, proto, Stream_proto, xml.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": सही होने पर, उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": definition_stack प्रोटो फ़ील्ड को भरें, जो नियम की क्लास तय होने के समय Starlark कॉल स्टैक के हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": अगर यह सेटिंग चालू होती है, तो select() से बनाए गए कॉन्फ़िगर करने लायक एट्रिब्यूट बराबर हो जाते हैं. सूची टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप की वैल्यू शून्य हो जाती है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स पहलू के साथ भरें जिससे एट्रिब्यूट मिला है (अगर ऐसा नहीं है, तो खाली स्ट्रिंग).
टैग: terminal_output
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत": $internal_attr_has एट्रिब्यूट का हिसाब लगाना है या नहीं, इसका पता लगाना है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत": हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग: terminal_output
--[no]proto:locations डिफ़ॉल्ट: "सही": प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "सभी": आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. कोई एट्रिब्यूट आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर क्वेरी को सेट किया जाता है, तो कमांड लाइन के बजाय, यहां दी गई फ़ाइल का नाम पढ़कर सुनाया जाएगा. यहां फ़ाइल और कमांड लाइन क्वेरी के बारे में बताना एक गड़बड़ी है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक ऐब्सलूट पाथ होता है और यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--[no]strict_test_suite डिफ़ॉल्ट: "गलत": सही होने पर, अगर test() एक्सप्रेशन ऐसे test_suite से मिलता है, जिसमें नॉन-टेस्ट टारगेट मौजूद हैं, तो यह गड़बड़ी का मैसेज दिखाता है.
टैग: build_file_semantics, eagerness_to_exit
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: बंद होने पर, क्वेरी को ऑपरेट करने वाले डिपेंडेंसी ग्राफ़ में 'exec कॉन्फ़िगरेशन' की डिपेंडेंसी शामिल नहीं होंगी. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसा कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक जाता है. आम तौर पर, यह एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल को पॉइंट करता है. Cquery: यह विकल्प बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट exec कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए exec टारगेट दिखाए जाएंगे. इस विकल्प में ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग: build_file_semantics
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा और घटाव). क्वेरी को यूनिवर्स में परफ़ॉर्म किया जा सकता है. इसके लिए, दिए गए टारगेट को हमेशा के लिए बंद करना होगा. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माने जाते हैं. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए, इस विकल्प को तय न करने से बिल्ड में रुकावट आ सकती है.
टैग: loading_and_analysis
--[no]xml:default_values डिफ़ॉल्ट: "गलत": सही होने पर, नियम के एट्रिब्यूट जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है उन्हें प्रिंट किया जाता है. ऐसा न होने पर, उन्हें हटा दिया जाता है.
टैग: terminal_output
--[no]xml:line_numbers डिफ़ॉल्ट: "सही": अगर सही है, तो एक्सएमएल आउटपुट में लाइन नंबर शामिल होते हैं. इस विकल्प को बंद करने से, पढ़ने में मुश्किल हो सकती है. यह विकल्प सिर्फ़ --internal=xml पर लागू होता है.
टैग: terminal_output

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: "": अगर यह खाली नहीं है, तो Starlark के डेटा स्टोर करने की सुविधा के सभी नियमों की समाधान की गई जानकारी के साथ Starlark की वैल्यू लिखें. यह वैल्यू, एक्ज़ीक्यूट किए गए सभी नियमों की होनी चाहिए.
टैग: affects_outputs

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

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

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

रन के विकल्प

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

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

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

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

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

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

--[no]configure डिफ़ॉल्ट: "गलत": सिर्फ़ सिंक करने के लिए डेटा स्टोर करने की जगहें, सिस्टम कॉन्फ़िगरेशन के लिए 'कॉन्फ़िगर करें' के तौर पर मार्क की गई हैं.
टैग: changes_inputs
--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": इस्तेमाल की गई मेमोरी का प्रतिशत (0-100) और इससे ज़्यादा GcTtrazingDetector, मेमोरी दबाव की घटनाओं को अपनी सीमा के हिसाब से (--gc_thrazing_limits). अगर इस नीति को 100 पर सेट किया जाता है, तो GcThrgingDetector को बंद कर दिया जाता है.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": लोडिंग/विश्लेषण फ़ेज़ में इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. उदाहरण के लिए. "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration
--only=<a string> बार कई बार इस्तेमाल किया गया है: अगर यह विकल्प दिया गया है, तो इस विकल्प के साथ बताए गए डेटा स्टोर करने की जगह को ही सिंक करें. फिर भी सभी (या सभी कॉन्फ़िगर जैसे, कॉन्फ़िगरेशन) को पुराना मानें.
टैग: changes_inputs

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

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: "": अगर यह खाली नहीं है, तो Starlark के डेटा स्टोर करने की सुविधा के सभी नियमों की समाधान की गई जानकारी के साथ Starlark की वैल्यू लिखें. यह वैल्यू, एक्ज़ीक्यूट किए गए सभी नियमों की होनी चाहिए.
टैग: affects_outputs

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

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

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

जांच के विकल्प

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.
--[no]print_relative_test_log_paths डिफ़ॉल्ट: "गलत": अगर सही है, तो किसी टेस्ट लॉग का पाथ प्रिंट करते समय, ऐसे रिलेटिव पाथ का इस्तेमाल करें जो 'टेस्टलॉग' सुविधा सिमलिंक का इस्तेमाल करता हो. ध्यान दें - बाद में किसी अलग कॉन्फ़िगरेशन के साथ 'build'/'test'/वगैरह शुरू करने पर इस सिमलिंक का टारगेट बदल सकता है, जिसकी वजह से पाथ पहले से प्रिंट हो जाता है और अब काम का नहीं रहता.
टैग: affects_outputs
--[no]test_verbose_timeout_warnings डिफ़ॉल्ट: "गलत": अगर सही हो, तो अतिरिक्त चेतावनियां प्रिंट करें. ऐसा तब करें, जब जांच के चलने का असल समय, टेस्ट में बताए गए टाइम आउट (चाहे साफ़ तौर पर बताया गया हो या साफ़ तौर पर) से मेल न खाता हो.
टैग: affects_outputs
--[no]verbose_test_summary डिफ़ॉल्ट: "सही": अगर सही है, तो टेस्ट की खास जानकारी में अतिरिक्त जानकारी (समय, रन नहीं होने की संख्या वगैरह) प्रिंट करें.
टैग: affects_outputs

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

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

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

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

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100": इस्तेमाल की गई मेमोरी का प्रतिशत (0-100) और इससे ज़्यादा GcTtrazingDetector, मेमोरी दबाव की घटनाओं को अपनी सीमा के हिसाब से (--gc_thrazing_limits). अगर इस नीति को 100 पर सेट किया जाता है, तो GcThrgingDetector को बंद कर दिया जाता है.
टैग: 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"> डिफ़ॉल्ट: "ऑटो": लोडिंग/विश्लेषण फ़ेज़ में इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. उदाहरण के लिए. "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

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

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

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

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

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

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

--[no]incompatible_depset_for_java_output_source_jars डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही": No-op
टैग: no_op, incompatible_change
--[no]separate_aspect_deps डिफ़ॉल्ट: "सही": No-op
टैग: no_op

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5": अगर इन सीमाओं तक पहुंचा जा सकता है, तो GcTthergingDetector, OOM के साथ Bazel को क्रैश कर सकती है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. यहां पीरियड एक अवधि होती है और संख्या एक पॉज़िटिव पूर्णांक होती है. अगर <period> में एक के बाद एक पूरे जीसी का इस्तेमाल <count> करने के बाद भी, तय किए गए समय के अंदर की गई जगह (पुराने जेन हीप) के --gc_thraअगले_threshold का प्रतिशत मौजूद है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय करने के लिए, उन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह गै़र-ज़रूरी स्काईफ़्रेम स्थिति को कम कर देगा. यह हर बार बोले जाने पर कई बार तक होगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि पूरे जीसी इवेंट की वजह से कभी भी गिरावट ट्रिगर नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो पूरा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत की सीमा से ज़्यादा होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसका रिटेन किए गए हीप प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के सेट किए गए थ्रेशोल्ड से ज़्यादा हो गया है, तो कोई छोटा GC इवेंट होने पर, यह ग़ैर-ज़रूरी अस्थायी Skyframe स्थिति को कम कर देगा. हर बार शुरू करने पर यह बार तक की सीमा तक ही काम करेगा. डिफ़ॉल्ट तौर पर Integer.MAX_VALUE; असरदार तरीके से अनलिमिटेड. शून्य का मतलब है कि छोटी-मोटी जीसी इवेंट में गिरावट नहीं होगी. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने और बरकरार रखे गए हीप के प्रतिशत के थ्रेशोल्ड को पार करने पर, Skyframe की स्थिति को कम नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bzel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह ग़ैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग की वजह से, वॉल टाइम के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: विवरण देखें: कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. साथ काम करने वाले किसी एक प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलोक या लॉक) में से कोई एक आर्ग्युमेंट के तौर पर दिया जाना चाहिए. आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम पर एक फ़ाइल के लिए प्रोफ़ाइल बनाई जाती है. दूसरी तरह की प्रोफ़ाइल या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सिमेंटिक में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.
--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत": डिफ़ॉल्ट रूप से, ऐक्शन के टाइप की संख्या 20 याद रखने की क्षमता तक सीमित होती है. इसमें सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने से सभी याददाश्त के आंकड़े लिखे जाएंगे.

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

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

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

विकल्प इफ़ेक्ट टैग

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

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

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