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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

या

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

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

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

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

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

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

-<short_form> <value>

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

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

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

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

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

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

या यहां बताए गए तरीके से, जबरन बंद किया जा सकता है:

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

निर्देश

analyze-profile	बिल्ड प्रोफ़ाइल के डेटा का विश्लेषण करता है.
aquery	दिए गए टारगेट का विश्लेषण करता है और ऐक्शन ग्राफ़ से क्वेरी करता है.
build	तय किए गए टारगेट बनाता है.
canonicalize-flags	bazel के विकल्पों की सूची को कैननिकल बनाता है.
clean	आउटपुट फ़ाइलों को हटाता है और सर्वर को बंद कर देता है.
coverage	तय किए गए टेस्ट टारगेट के लिए, कोड कवरेज रिपोर्ट जनरेट करता है.
cquery	कॉन्फ़िगरेशन के साथ तय किए गए टारगेट को लोड करता है, उनका विश्लेषण करता है, और उनसे जुड़ी क्वेरी करता है.
dump	bazel सर्वर प्रोसेस की इंटरनल स्टेटस को डंप करता है.
fetch	टारगेट के लिए ज़रूरी बाहरी डेटा स्टोर करने की जगहों को फ़ेच करता है.
help	निर्देशों या इंडेक्स के लिए मदद प्रिंट करता है.
info	bazel सर्वर के बारे में रनटाइम की जानकारी दिखाता है.
license	इस सॉफ़्टवेयर का लाइसेंस प्रिंट करता है.
mobile-install	मोबाइल डिवाइसों पर टारगेट इंस्टॉल करता है.
mod	Bzlmod के बाहरी डिपेंडेंसी ग्राफ़ से क्वेरी करता है
print_action	किसी फ़ाइल को कंपाइल करने के लिए, कमांड लाइन के आर्ग्युमेंट प्रिंट करता है.
query	डिपेंडेंसी ग्राफ़ की क्वेरी को लागू करता है.
run	तय किए गए टारगेट को चलाता है.
shutdown	bazel सर्वर को बंद कर देता है.
sync	Workspace फ़ाइल में बताई गई सभी रिपॉज़िटरी सिंक करता है
test	तय किए गए टेस्ट टारगेट बनाता है और उन्हें चलाता है.
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 के लिए 'बैच' सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति उन वर्कलोड के लिए काम की है जो इंटरैक्टिव नहीं हैं, लेकिन जिनकी नीस वैल्यू कम नहीं करनी है. 'man 2 sched_setscheduler' देखें. अगर यह 'गलत है' पर सेट है, तो Bazel कोई सिस्टम कॉल नहीं करता.
टैग: host_machine_resource_optimizations

--bazelrc=<path> डिफ़ॉल्ट: जानकारी देखें

उपयोगकर्ता की .bazelrc फ़ाइल की जगह, जिसमें Bazel के विकल्पों की डिफ़ॉल्ट वैल्यू होती हैं. /dev/null से पता चलता है कि आगे की सभी `--bazelrc`को अनदेखा कर दिया जाएगा. यह रिलीज़ बिल्ड में, उपयोगकर्ता की rc फ़ाइल की खोज को बंद करने के लिए काम आता है. इस विकल्प को कई बार भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, `--bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc` के साथ, 1) x.rc और y.rc पढ़े जाते हैं. 2) पहले से मौजूद /dev/null की वजह से, z.rc को अनदेखा कर दिया जाता है. अगर कोई फ़ाइल नहीं चुनी जाती है, तो Bazel इन दो जगहों पर मिली पहली .bazelrc फ़ाइल का इस्तेमाल करता है: वर्कस्पेस डायरेक्ट्री और फिर उपयोगकर्ता की होम डायरेक्ट्री. ध्यान दें: कमांड-लाइन के विकल्प, bazelrc में मौजूद किसी भी विकल्प से हमेशा बेहतर होंगे.
टैग: changes_inputs

--[no]block_for_lock डिफ़ॉल्ट: "सही"

--noblock_for_lock का इस्तेमाल करने पर, Bazel किसी चल रही कमांड के पूरा होने का इंतज़ार नहीं करता. इसके बजाय, वह तुरंत बाहर निकल जाता है.
टैग: eagerness_to_exit

--[no]client_debug डिफ़ॉल्ट: "गलत"

अगर यह 'सही है' पर सेट है, तो क्लाइंट से डीबग की जानकारी को stderr में लॉग करें. इस विकल्प को बदलने से, सर्वर फिर से शुरू नहीं होगा.
टैग: affects_outputs, bazel_monitoring

--connect_timeout_secs=<an integer> डिफ़ॉल्ट: "30"

सर्वर से कनेक्ट करने के हर प्रयास के लिए, क्लाइंट को इंतज़ार करने में लगने वाला समय
टैग: bazel_internal_configuration

--[no]expand_configs_in_place डिफ़ॉल्ट: "सही"

--config फ़्लैग के एक्सपैंशन को बदला गया है, ताकि यह सामान्य rc विकल्पों और कमांड-लाइन के तय विकल्पों के बीच, तय किए गए पॉइंट के एक्सपैंशन के बजाय, इन-प्लेस किया जा सके.
टैग: no_op, deprecated

--failure_detail_out=<path> डिफ़ॉल्ट: जानकारी देखें

अगर यह सेट है, तो सर्वर में कोई गड़बड़ी होने पर, failure_detail protobuf मैसेज लिखने के लिए जगह तय की जाती है. ऐसा तब होता है, जब सामान्य तौर पर gRPC के ज़रिए गड़बड़ी की शिकायत नहीं की जा सकती. ऐसा न करने पर, फ़ाइल की जगह ${OUTPUT_BASE}/failure_detail.rawproto होगी.
टैग: affects_outputs, loses_incremental_state

--[no]home_rc डिफ़ॉल्ट: "सही"

क्या $HOME/.bazelrc पर होम bazelrc फ़ाइल खोजी जानी चाहिए या नहीं
टैग: changes_inputs

--[no]idle_server_tasks डिफ़ॉल्ट: "सही"

सर्वर के खाली होने पर System.gc() चलाएं
टैग: loses_incremental_state, host_machine_resource_optimizations

--[no]ignore_all_rc_files डिफ़ॉल्ट: "गलत"

यह सभी rc फ़ाइलों को बंद कर देता है. भले ही, rc में बदलाव करने वाले अन्य फ़्लैग की वैल्यू कुछ भी हो. भले ही, ये फ़्लैग स्टार्टअप विकल्पों की सूची में बाद में आएं.
टैग: changes_inputs

--io_nice_level={-1,0,1,2,3,4,5,6,7} डिफ़ॉल्ट: "-1"

सिर्फ़ Linux पर; sys_ioprio_set सिस्टम कॉल का इस्तेमाल करके, बेहतर आईओ शेड्यूलिंग के लिए 0 से 7 के बीच कोई लेवल सेट करें. 0 सबसे ज़्यादा प्राथमिकता है और 7 सबसे कम प्राथमिकता है. अनुमानित शेड्यूलर, सिर्फ़ प्राथमिकता 4 तक के अनुरोधों को पूरा कर सकता है. अगर इसे किसी नेगेटिव वैल्यू पर सेट किया जाता है, तो Bazel कोई सिस्टम कॉल नहीं करता.
टैग: host_machine_resource_optimizations

--local_startup_timeout_secs=<an integer> डिफ़ॉल्ट: "120"

क्लाइंट, सर्वर से कनेक्ट होने में ज़्यादा से ज़्यादा कितना समय इंतज़ार कर सकता है
टैग: bazel_internal_configuration

--macos_qos_class=<a string> डिफ़ॉल्ट: "default"

MacOS पर चलने पर, bazel सर्वर की QoS सेवा क्लास सेट करता है. इस फ़्लैग का अन्य सभी प्लैटफ़ॉर्म पर कोई असर नहीं पड़ता. हालांकि, यह पक्का करने के लिए यह सुविधा उपलब्ध है कि rc फ़ाइलों को बिना किसी बदलाव के उन प्लैटफ़ॉर्म के बीच शेयर किया जा सके. संभावित वैल्यू: उपयोगकर्ता के इंटरैक्टिव, उपयोगकर्ता से शुरू की गई, डिफ़ॉल्ट, यूटिलिटी, और बैकग्राउंड.
टैग: host_machine_resource_optimizations

--max_idle_secs=<integer> डिफ़ॉल्ट: "10800"

बिल्ड सर्वर बंद होने से पहले, कुछ सेकंड तक इंतज़ार करेगा. शून्य का मतलब है कि सर्वर कभी बंद नहीं होगा. यह सिर्फ़ सर्वर के शुरू होने पर पढ़ा जाता है. इस विकल्प को बदलने से सर्वर फिर से शुरू नहीं होगा.
टैग: eagerness_to_exit, loses_incremental_state

--output_base=<path> डिफ़ॉल्ट: जानकारी देखें

अगर यह सेट है, तो यह आउटपुट की उस जगह की जानकारी देता है जहां सभी बिल्ड आउटपुट लिखे जाएंगे. ऐसा न करने पर, जगह ${OUTPUT_ROOT}/_blaze_${USER}/${MD5_OF_WORKSPACE_ROOT} होगी. ध्यान दें: अगर इस वैल्यू के लिए, एक से अगले Bazel इंवोकेशन के लिए कोई दूसरा विकल्प तय किया जाता है, तो हो सकता है कि आप एक नया, अतिरिक्त Bazel सर्वर शुरू करें. Bazel, हर तय किए गए आउटपुट बेस के लिए एक ही सर्वर शुरू करता है. आम तौर पर, हर वर्कस्पेस में एक आउटपुट बेस होता है. हालांकि, इस विकल्प की मदद से हर वर्कस्पेस में कई आउटपुट बेस हो सकते हैं. इससे एक ही मशीन पर एक ही क्लाइंट के लिए, एक साथ कई बिल्ड चलाए जा सकते हैं. Bazel सर्वर को बंद करने का तरीका जानने के लिए, 'bazel help shutdown' देखें.
टैग: affects_outputs, loses_incremental_state

--output_user_root=<path> डिफ़ॉल्ट: जानकारी देखें

यह उपयोगकर्ता के हिसाब से बनाई गई डायरेक्ट्री होती है. इसमें सभी बिल्ड आउटपुट लिखे जाते हैं. डिफ़ॉल्ट रूप से, यह $USER का फ़ंक्शन होता है. हालांकि, किसी कॉन्स्टेंट को बताकर, बिल्ड आउटपुट को साथ मिलकर काम करने वाले उपयोगकर्ताओं के बीच शेयर किया जा सकता है.
टैग: affects_outputs, loses_incremental_state

--[no]preemptible डिफ़ॉल्ट: "गलत"

अगर इसकी वैल्यू 'सही है' पर सेट है, तो कोई दूसरा निर्देश मिलने पर, पहले दिए गए निर्देश को रोका जा सकता है.
टैग: eagerness_to_exit

--server_jvm_out=<path> डिफ़ॉल्ट: जानकारी देखें

सर्वर के JVM के आउटपुट को लिखने की जगह. अगर यह सेट नहीं है, तो यह output_base में मौजूद किसी जगह पर डिफ़ॉल्ट रूप से सेट हो जाता है.
टैग: 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 डिफ़ॉल्ट: "गलत"

सामान्य स्थितियों में सर्वर (इसमें JVM भी शामिल है) और क्लाइंट के कोर्डंप को बनाने के लिए, सॉफ्ट कोर्डंप की सीमा को हार्ड सीमा तक बढ़ाता है. इस फ़्लैग को अपनी bazelrc में एक बार चिपकाएं और इसके बारे में भूल जाएं, ताकि आपको असल में किसी ऐसी स्थिति का सामना करने पर कोरडंप मिल सके जो उन्हें ट्रिगर करता है.
टैग: 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 को चलाने वाले JVM को पास करने के लिए फ़्लैग.

--host_jvm_debug

JVM के स्टार्टअप के लिए कुछ अतिरिक्त फ़्लैग जोड़ने का आसान विकल्प. इनकी वजह से, JVM स्टार्टअप के दौरान तब तक इंतज़ार करता है, जब तक कि Eclipse जैसे JDWP-compliant डीबगर से पोर्ट 5005 से कनेक्ट नहीं किया जाता.
इस तरह बड़ा होता है:
  --host_jvm_args=-Xdebug
  --host_jvm_args=-Xrunjdwp:transport=dt_socket,server=y,address=5005

--host_jvm_profile=<profiler_name> डिफ़ॉल्ट: ""

प्रॉफ़ाइलर/डीबगर के हिसाब से JVM के स्टार्टअप फ़्लैग जोड़ने के लिए आसान विकल्प. Bazel में ऐसी जानी-पहचानी वैल्यू की सूची होती है जिन्हें यह हार्डकोड किए गए JVM स्टार्टअप फ़्लैग पर मैप करता है. ऐसा हो सकता है कि यह कुछ फ़ाइलों के लिए, हार्डकोड किए गए कुछ पाथ खोजता हो.

--server_javabase=<jvm path> डिफ़ॉल्ट: ""

Bazel को खुद चलाने के लिए इस्तेमाल किए जाने वाले JVM का पाथ.

सभी निर्देशों के लिए सामान्य विकल्प

बिल्ड को कंट्रोल करने वाले विकल्प:

--experimental_oom_more_eagerly_threshold=<an integer> डिफ़ॉल्ट: "100"

अगर इस फ़्लैग को 100 से कम वैल्यू पर सेट किया जाता है, तो दो बार जीसी (कंपाइलर के दौरान मेमोरी खाली करने की प्रोसेस) होने के बाद भी, अगर (पुराने जनरेशन) हेप का यह प्रतिशत से ज़्यादा है, तो Bazel ओवर मेमोरी हो जाएगा.
टैग: host_machine_resource_optimizations

--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range> डिफ़ॉल्ट: "1048576"

stdout / stderr फ़ाइलों का ज़्यादा से ज़्यादा साइज़, जो कंसोल पर प्रिंट किया जाएगा. -1 का मतलब है कि कोई सीमा नहीं है.
टैग: execution

ऐक्शन को लागू करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--[no]incompatible_enable_proto_toolchain_resolution डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो प्रोटो लैंग नियम, rules_proto, rules_java, rules_cc रिपॉज़िटरी से टूलचेन तय करते हैं.
टैग: loading_and_analysis, incompatible_change

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपनी पसंद के मुताबिक आउटपुट कॉन्फ़िगर कर सकता है. इससे, आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--repo_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इससे, अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं, जो सिर्फ़ रिपॉज़िटरी के नियमों के लिए उपलब्ध होते हैं. ध्यान दें कि रिपॉज़िटरी के नियमों में पूरा एनवायरमेंट दिखता है. हालांकि, इस तरीके से कॉन्फ़िगरेशन की जानकारी को विकल्पों के ज़रिए रिपॉज़िटरी में भेजा जा सकता है. ऐसा करने पर, ऐक्शन ग्राफ़ अमान्य नहीं होता.
टैग: action_command_lines

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]check_bzl_visibility डिफ़ॉल्ट: "सही"

अगर इसे बंद किया जाता है, तो .bzl लोड होने से जुड़ी गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics

इस विकल्प से, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]enable_bzlmod डिफ़ॉल्ट: "गलत"

अगर यह 'सही' पर सेट है, तो Bzlmod डिपेंडेंसी मैनेजमेंट सिस्टम चालू हो जाता है. यह WORKSPACE के मुकाबले प्राथमिकता पाता है. ज़्यादा जानकारी के लिए, https://bazel.build/docs/bzlmod देखें.
टैग: loading_and_analysis

--[no]experimental_action_resource_set डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो ctx.actions.run() और ctx.actions.run_shell() स्थानीय तौर पर लागू करने के लिए, resource_set पैरामीटर स्वीकार करते हैं. ऐसा न करने पर, डिफ़ॉल्ट रूप से मेमोरी के लिए 250 एमबी और एक सीपीयू सेट हो जाएगा.
टैग: execution, build_file_semantics, experimental

--[no]experimental_allow_tags_propagation डिफ़ॉल्ट: "गलत"

अगर इसे 'सही' पर सेट किया जाता है, तो टैग को टारगेट से ऐक्शन लागू करने की ज़रूरी शर्तों पर भेजा जाएगा. ऐसा न करने पर, टैग नहीं भेजे जाएंगे. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/8830 पर जाएं.
टैग: build_file_semantics, experimental

--[no]experimental_analysis_test_call डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो analysis_test नेटिव कॉल उपलब्ध होता है.
टैग: loading_and_analysis, 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' फ़ाइल को पार्स नहीं कर पाएगा. हालांकि, नाम न दिए गए पैकेज से external/ में पहुंचने वाले ग्लोब काम करेंगे.
टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_enable_android_migration_apis डिफ़ॉल्ट: "गलत"

अगर इसे 'सही' पर सेट किया जाता है, तो Android Starlark माइग्रेशन के साथ काम करने के लिए ज़रूरी एपीआई चालू हो जाते हैं.
टैग: build_file_semantics

--[no]experimental_get_fixed_configured_action_env डिफ़ॉल्ट: "गलत"

अगर यह चालू है, तो action.env, सुविधाओं के कॉन्फ़िगरेशन के ज़रिए तय किए गए एनवायरमेंट वैरिएबल भी दिखाएगा.
टैग: loading_and_analysis, experimental

--[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>isolate</code> पैरामीटर चालू हो जाता है.
टैग: loading_and_analysis

--[no]experimental_lazy_template_expansion डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो ctx.actions.expand_template() फ़ंक्शन, वैल्यू बदलने की सुविधा के लिए TemplateDict पैरामीटर स्वीकार करता है.
टैग: execution, build_file_semantics, experimental

--[no]experimental_platforms_api डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो प्लैटफ़ॉर्म से जुड़े कई Starlark API चालू हो जाते हैं. ये डीबग करने के लिए काम के होते हैं.
टैग: loading_and_analysis, experimental

--[no]experimental_repo_remote_exec डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो repository_rule को रिमोट से चलाने की कुछ सुविधाएं मिलती हैं.
टैग: build_file_semantics, loading_and_analysis, experimental

--[no]experimental_sibling_repository_layout डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो नॉन-मुख्य रिपॉज़िटरी को, मुख्य रिपॉज़िटरी के सिमलिंक के तौर पर, एक्सीक्यूशन रूट में लगाया जाता है. इसका मतलब है कि सभी रिपॉज़िटरी, $output_base/execution_root डायरेक्ट्री के डायरेक्ट चाइल्ड हैं. इसका एक असर यह भी है कि असल टॉप-लेवल 'external' डायरेक्ट्री के लिए, $output_base/execution_root/__main__/external को खाली कर दिया जाता है.
टैग: action_command_lines, bazel_internal_configuration, loading_and_analysis, loses_incremental_state, 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 से सूची नहीं दिखाता, बल्कि इसके बजाय एक depset दिखाता है.
टैग: 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_provider_fields डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स की मदद से, 'टारगेट' ऑब्जेक्ट पर उपलब्ध कराने वाली सेवाओं को ऐक्सेस करने की सुविधा बंद कर दें. इसके बजाय, provider-key सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, नियम लागू करने वाले फ़ंक्शन में `my_info` को ऐक्सेस करने के लिए, `ctx.attr.dep.my_info` के बजाय `ctx.attr.dep[MyInfo]` का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/9014 देखें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_disallow_empty_glob डिफ़ॉल्ट: "गलत"

अगर इसे 'सही' पर सेट किया जाता है, तो glob() के `allow_empty` आर्ग्युमेंट की डिफ़ॉल्ट वैल्यू 'गलत' होती है.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_disallow_legacy_javainfo डिफ़ॉल्ट: "सही"

अब काम नहीं करता. कोई कार्रवाई नहीं.
टैग: 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, Label.workspace_name, Label.relative) का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--[no]incompatible_existing_rules_immutable_view डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो native.existing_rule और native.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 डिफ़ॉल्ट: "सही"

package_group के `packages` एट्रिब्यूट में, वैल्यू "//..." का मतलब बदलकर, किसी भी रिपॉज़िटरी के सभी पैकेज के बजाय, मौजूदा रिपॉज़िटरी के सभी पैकेज का रेफ़रंस दिया जाता है. पुराना व्यवहार पाने के लिए, "//..." के बजाय खास वैल्यू "public" का इस्तेमाल किया जा सकता है. इस फ़्लैग के लिए, --incompatible_package_group_has_public_syntax भी चालू होना चाहिए.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_java_common_parameters डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो pack_sources में output_jar और host_javabase पैरामीटर और compile में host_javabase पैरामीटर हटा दिए जाएंगे.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_merge_fixed_and_default_shell_env डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो ctx.actions.run और ctx.actions.run_shell के साथ रजिस्टर की गई ऐसी कार्रवाइयां जो 'env' और 'use_default_shell_env = True', दोनों के साथ सेट की गई हैं वे डिफ़ॉल्ट शेल एनवायरमेंट से मिले एनवायरमेंट का इस्तेमाल करेंगी. इसके लिए, वे 'env' में दी गई वैल्यू को बदल देंगी. अगर यह बंद है, तो इस मामले में 'env' की वैल्यू को पूरी तरह से अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_new_actions_api डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो कार्रवाइयां बनाने के लिए एपीआई सिर्फ़ `ctx.actions` पर उपलब्ध होता है, न कि `ctx` पर.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_no_attr_license डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो `attr.license` फ़ंक्शन बंद हो जाता है.
टैग: 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 डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो `rule()` Starlark फ़ंक्शन के `outputs` पैरामीटर को बंद कर दिया जाता है.
टैग: 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 डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो create_linking_context नियम के लिए, libraries_to_link के बजाय linker_inputs की ज़रूरत होगी. linking_context के पुराने getter भी बंद कर दिए जाएंगे और सिर्फ़ 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_language_modules डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो भाषा के हिसाब से बने कुछ मॉड्यूल (जैसे, `cc_common`), उपयोगकर्ता की .bzl फ़ाइलों में उपलब्ध नहीं होते. साथ ही, इन्हें सिर्फ़ उनके नियमों के रिपॉज़िटरी से ही कॉल किया जा सकता है.
टैग: 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

--[no]incompatible_visibility_private_attributes_at_definition डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो नियम की परिभाषा के हिसाब से निजी नियम के एट्रिब्यूट की दिखने की स्थिति की जांच की जाती है. अगर एट्रिब्यूट नहीं दिखते हैं, तो नियम के इस्तेमाल की जांच की जाती है.
टैग: build_file_semantics, incompatible_change

--max_computation_steps=<a long integer> डिफ़ॉल्ट: "0"

Starlark कैलकुलेशन के चरणों की ज़्यादा से ज़्यादा संख्या, जो BUILD फ़ाइल से लागू की जा सकती है. शून्य का मतलब है कि कोई सीमा नहीं है.
टैग: build_file_semantics

--nested_set_depth_limit=<an integer> डिफ़ॉल्ट: "3500"

किसी depset (जिसे नेस्टेड सेट भी कहा जाता है) के अंदर मौजूद ग्राफ़ की ज़्यादा से ज़्यादा गहराई. इस गहराई से ज़्यादा होने पर, depset() कन्स्ट्रक्टर काम नहीं करेगा.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--[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 डिफ़ॉल्ट: "सही"

अगर यह वैल्यू 'गलत' है, तो बिल्ड पूरा होने पर Blaze, इस बिल्ड से इन-मेमोरी स्टेटस को हटा देगा. इसके बाद के बिल्ड में, इस बिल्ड के मुकाबले कोई बढ़ोतरी नहीं होगी.
टैग: loses_incremental_state

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्टेटस के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्टेटस को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

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

[SCHEME://]HOST[:PORT] फ़ॉर्मैट में, बिल्ड इवेंट सेवा (बीईएस) के बैकएंड एंडपॉइंट की जानकारी देता है. डिफ़ॉल्ट रूप से, BES अपलोड की सुविधा बंद रहती है. इन स्कीम का इस्तेमाल किया जा सकता है: grpc और grpcs (TLS चालू होने पर grpc). अगर कोई स्कीम नहीं दी गई है, तो Bazel grpcs को मान लेता है.
टैग: affects_outputs

--[no]bes_check_preceding_lifecycle_events डिफ़ॉल्ट: "गलत"

PublishBuildToolEventStreamRequest पर check_preceding_lifecycle_events_present फ़ील्ड सेट करता है. इससे BES को यह पता चलता है कि क्या उसे पहले मौजूदा टूल इवेंट से मैच करने वाले InvocationAttemptStarted और BuildEnqueued इवेंट मिले हैं.
टैग: affects_outputs

--bes_header=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

NAME=VALUE फ़ॉर्म में कोई हेडर तय करें. इसे BES अनुरोधों में शामिल किया जाएगा. एक से ज़्यादा हेडर पास करने के लिए, फ़्लैग को कई बार डालें. एक ही नाम के लिए एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
टैग: affects_outputs

--bes_instance_name=<a string> डिफ़ॉल्ट: जानकारी देखें

उस इंस्टेंस का नाम बताता है जिसके तहत BES, अपलोड किए गए बीईपी को सेव करेगा. डिफ़ॉल्ट रूप से, यह वैल्यू शून्य पर सेट होती है.
टैग: 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 मीटर"

यह तय करता है कि OOM होने पर, bazel को BES/BEP अपलोड पूरा होने में कितना इंतज़ार करना चाहिए. यह फ़्लैग, JVM के ज़्यादा GC थ्रैश होने और किसी भी उपयोगकर्ता थ्रेड पर प्रोग्रेस न होने पर, प्रोसेस को बंद करने की सुविधा देता है.
टैग: 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> डिफ़ॉल्ट: जानकारी देखें

प्रॉक्सी के ज़रिए, Build Event Service से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.

--bes_results_url=<a string> डिफ़ॉल्ट: ""

उस बेस यूआरएल की जानकारी देता है जहां उपयोगकर्ता, BES बैकएंड पर स्ट्रीम की गई जानकारी देख सकता है. Bazel, टर्मिनल में अनुरोध आईडी के साथ जोड़ा गया यूआरएल दिखाएगा.
टैग: terminal_output

--bes_timeout=<An immutable length of time.> डिफ़ॉल्ट: "0s"

इससे पता चलता है कि बिल्ड और टेस्ट पूरा होने के बाद, bazel को BES/BEP अपलोड पूरा होने में कितना इंतज़ार करना चाहिए. समयसीमा के तौर पर कोई ऐसी प्राकृतिक संख्या डालें जिसके बाद समय की इकाई हो. जैसे: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). इसकी डिफ़ॉल्ट वैल्यू '0' होती है. इसका मतलब है कि कोई टाइम आउट नहीं है.
टैग: affects_outputs

--build_event_binary_file=<a string> डिफ़ॉल्ट: ""

अगर फ़ाइल में कोई जानकारी है, तो उस फ़ाइल में बिल्ड इवेंट प्रोटोकॉल के बाइनरी वर्शन को लिखें. यह वर्शन, वैरिएंट के बीच में विराम लगाकर लिखा जाता है. इस विकल्प का मतलब है --bes_upload_mode=wait_for_upload_complete.
टैग: affects_outputs

--[no]build_event_binary_file_path_conversion डिफ़ॉल्ट: "सही"

जब भी हो सके, बिल्ड इवेंट प्रोटोकॉल के बाइनरी फ़ाइल रेप्रज़ेंटेशन में पाथ को ग्लोबल तौर पर मान्य यूआरआई में बदलें. अगर इसे बंद किया जाता है, तो file:// यूआरआई स्कीम का हमेशा इस्तेमाल किया जाएगा
टैग: affects_outputs

--build_event_json_file=<a string> डिफ़ॉल्ट: ""

अगर फ़ाइल में कोई जानकारी है, तो उसमें बिल्ड इवेंट प्रोटोकॉल का JSON क्रम लिखें.
टैग: affects_outputs

--[no]build_event_json_file_path_conversion डिफ़ॉल्ट: "सही"

जब भी हो सके, तो बिल्ड इवेंट प्रोटोकॉल के JSON फ़ाइल रेप्रज़ेंटेशन में मौजूद पाथ को, दुनिया भर में मान्य यूआरआई में बदलें. अगर इसे बंद किया जाता है, तो file:// यूआरआई स्कीम का हमेशा इस्तेमाल किया जाएगा
टैग: affects_outputs

--build_event_max_named_set_of_file_entries=<an integer> डिफ़ॉल्ट: "-1"

named_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:// यूआरआई स्कीम का हमेशा इस्तेमाल किया जाएगा
टैग: affects_outputs

--[no]experimental_announce_profile_path डिफ़ॉल्ट: "गलत"

अगर यह चालू है, तो लॉग में JSON प्रोफ़ाइल का पाथ जोड़ता है.
टैग: affects_outputs, bazel_monitoring

--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत"

TargetSummary इवेंट पब्लिश करने हैं या नहीं.

--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs

--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में रिलेटिव फ़ाइलसेट के लिंक को पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs

--experimental_build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4"

Bazel को बिल्ड इवेंट को अपलोड करने की कोशिश कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s"

बीईपी अपलोड न हो पाने पर, एक्सपोनेंशियल बैकऑफ़ की वजह से होने वाली शुरुआती देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration

--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुनता है.
टैग: affects_outputs

--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, process_time, remote_queue, remote_setup, fetch, 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, local_cpu_usage, system_cpu_usage, local_memory_usage, system_memory_usage, 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 or unknown> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इससे, प्रोफ़ाइल में शामिल किए जाने वाले अन्य प्रोफ़ाइल टास्क तय किए जाते हैं.
टैग: affects_outputs, bazel_monitoring

--[no]experimental_profile_include_primary_output डिफ़ॉल्ट: "गलत"

ऐक्शन इवेंट में अतिरिक्त "out" एट्रिब्यूट शामिल करता है. इसमें ऐक्शन के प्राइमरी आउटपुट का exec पाथ शामिल होता है.
टैग: affects_outputs, bazel_monitoring

--[no]experimental_profile_include_target_label डिफ़ॉल्ट: "गलत"

ऐक्शन इवेंट के JSON प्रोफ़ाइल डेटा में टारगेट लेबल शामिल करता है.
टैग: affects_outputs, bazel_monitoring

--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत"

लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs

--experimental_workspace_rules_log_file=<a path> डिफ़ॉल्ट: जानकारी देखें

Workspace के नियमों से जुड़े कुछ इवेंट को, इस फ़ाइल में WorkspaceEvent प्रोटो के तौर पर लॉग करें.

--[no]generate_json_trace_profile डिफ़ॉल्ट: "auto"

अगर यह विकल्प चालू है, तो Bazel, बिल्ड की प्रोफ़ाइल बनाता है और आउटपुट बेस में मौजूद फ़ाइल में JSON फ़ॉर्मैट की प्रोफ़ाइल लिखता है. chrome://tracing पर जाकर प्रोफ़ाइल देखें. डिफ़ॉल्ट रूप से, Bazel सभी बिल्ड-जैसे निर्देशों और क्वेरी के लिए प्रोफ़ाइल लिखता है.
टैग: affects_outputs, bazel_monitoring

--[no]heap_dump_on_oom डिफ़ॉल्ट: "गलत"

ओवर मेमोरी (ओओएम) होने पर, मैन्युअल तरीके से हेप डंप आउटपुट करना है या नहीं. इसमें --experimental_oom_more_eagerly_threshold की वजह से होने वाले ओओएम भी शामिल हैं. डंप, <output_base>/<invocation_id>.heapdump.hprof में सेव किया जाएगा. यह विकल्प, -XX:+HeapDumpOnOutOfMemoryError को बदल देता है. इसका कोई असर नहीं पड़ता, क्योंकि OOM को पकड़ा जाता है और Runtime#halt पर रीडायरेक्ट किया जाता है.
टैग: bazel_monitoring

--[no]legacy_important_outputs डिफ़ॉल्ट: "सही"

TargetComplete इवेंट में, लेगसी important_outputs फ़ील्ड जनरेट होने से रोकने के लिए, इसका इस्तेमाल करें. Bazel से ResultStore इंटिग्रेशन के लिए, important_outputs ज़रूरी है.
टैग: affects_outputs

--logging=<0 <= an integer <= 6> डिफ़ॉल्ट: "3"

लॉगिंग लेवल.
टैग: affects_outputs

--memory_profile=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर सेट किया गया है, तो फ़ेज़ खत्म होने पर, तय की गई फ़ाइल में मेमोरी के इस्तेमाल का डेटा लिखें. साथ ही, बिल्ड खत्म होने पर, स्टेबल हेप को मास्टर लॉग में लिखें.
टैग: affects_outputs, bazel_monitoring

--memory_profile_stable_heap_parameters=<integers, separated by a comma expected in pairs> डिफ़ॉल्ट: "1,0"

बिल्ड के आखिर में, स्टैबल हीप के हिसाब से मेमोरी प्रोफ़ाइल को ट्यून करें. यह एक सम संख्या होनी चाहिए और पूर्णांकों को कॉमा से अलग किया जाना चाहिए. हर पेयर में, पहला इंटिजर, GC की संख्या होती है. हर जोड़े में दूसरा पूर्णांक, जीसी के बीच इंतज़ार करने के लिए सेकंड की संख्या है. उदाहरण: 2,4,4,0 का मतलब है कि 4 सेकंड के लिए रोके गए दो जीसी के बाद, बिना किसी रोक के चार जीसी आएंगे
टैग: bazel_monitoring

--profile=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर सेट है, तो Bazel की प्रोफ़ाइल बनाएं और तय की गई फ़ाइल में डेटा लिखें. प्रोफ़ाइल का विश्लेषण करने के लिए, bazel analyze-profile का इस्तेमाल करें.
टैग: affects_outputs, bazel_monitoring

--[no]slim_profile डिफ़ॉल्ट: "सही"

अगर प्रोफ़ाइल का साइज़ बहुत बड़ा हो जाता है, तो इवेंट मर्ज करके JSON प्रोफ़ाइल का साइज़ कम किया जा सकता है.
टैग: affects_outputs, bazel_monitoring

--starlark_cpu_profile=<a string> डिफ़ॉल्ट: ""

यह फ़ंक्शन, बताई गई फ़ाइल में Starlark थ्रेड के सीपीयू इस्तेमाल की pprof प्रोफ़ाइल लिखता है.
टैग: bazel_monitoring

--tool_tag=<a string> डिफ़ॉल्ट: ""

इस Bazel को कॉल करने के लिए, टूल का नाम.
टैग: affects_outputs, bazel_monitoring

--ui_event_filters=<Convert list of comma separated event kind to list of filters> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह तय करता है कि यूज़र इंटरफ़ेस (यूआई) में कौनसे इवेंट दिखाने हैं. डिफ़ॉल्ट इवेंट में, +/- का इस्तेमाल करके इवेंट जोड़े या हटाए जा सकते हैं. इसके अलावा, सीधे असाइनमेंट की मदद से, डिफ़ॉल्ट सेट को पूरी तरह से बदला जा सकता है. काम करने वाले इवेंट टाइप के सेट में INFO, DEBUG, ERROR वगैरह शामिल हैं.
टैग: terminal_output

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है.:

--build_metadata=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड इवेंट में देने के लिए, कस्टम की-वैल्यू स्ट्रिंग पेयर.
टैग: terminal_output

--color=<yes, no or auto> डिफ़ॉल्ट: "auto"

आउटपुट को रंगीन करने के लिए, टर्मिनल कंट्रोल का इस्तेमाल करें.

--config=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

rc फ़ाइलों से अन्य कॉन्फ़िगरेशन सेक्शन चुनता है. साथ ही, हर <command> के लिए, <command>:<config> से विकल्प भी लेता है. हालांकि, ऐसा तब ही होता है, जब ऐसा सेक्शन मौजूद हो. अगर यह सेक्शन किसी .rc फ़ाइल में मौजूद नहीं है, तो Blaze गड़बड़ी के साथ काम करना बंद कर देता है. ये कॉन्फ़िगरेशन सेक्शन और फ़्लैग कॉम्बिनेशन, tools/*.blazerc कॉन्फ़िगरेशन फ़ाइलों में मौजूद होते हैं.

--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.> एक से ज़्यादा बार इस्तेमाल किए जाने पर

रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी में सेव करने, और उसे लागू करने के साथ-साथ, इवेंट की बिल्ड सेवा के लिए अनुमति के क्रेडेंशियल पाने के लिए, क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है. किसी हेल्पर से मिले क्रेडेंशियल, --google_default_credentials, --google_credentials, .netrc फ़ाइल या repository_ctx.download और repository_ctx.download_and_extract के auth पैरामीटर से मिले क्रेडेंशियल से ज़्यादा प्राथमिकता पाते हैं. एक से ज़्यादा हेल्पर सेट अप करने के लिए, कई बार इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-credential-helpers.md देखें.

--credential_helper_cache_duration=<An immutable length of time.> डिफ़ॉल्ट: "30 मीटर"

क्रेडेंशियल हेल्पर से मिले क्रेडेंशियल को कैश मेमोरी में सेव रखने की अवधि. किसी दूसरी वैल्यू के साथ कॉल करने पर, पहले से मौजूद एंट्री के लाइफ़टाइम में बदलाव होगा. कैश मेमोरी मिटाने के लिए, शून्य पास करें. इस फ़्लैग के बावजूद, क्लीन कमांड हमेशा कैश मेमोरी मिटाता है.

--credential_helper_timeout=<An immutable length of time.> डिफ़ॉल्ट: "10s"

क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. अगर क्रेडेंशियल हेल्पर इस टाइम आउट के अंदर जवाब नहीं देते हैं, तो अनुरोध पूरा नहीं होगा.

--curses=<yes, no or auto> डिफ़ॉल्ट: "auto"

आउटपुट को कम से कम स्क्रोल करने के लिए, टर्मिनल कर्सर कंट्रोल का इस्तेमाल करें.

--[no]enable_platform_specific_config डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel, bazelrc फ़ाइलों से होस्ट-ओएस के हिसाब से कॉन्फ़िगरेशन लाइनें चुनता है. उदाहरण के लिए, अगर होस्ट ओएस Linux है और आपने bazel build चलाया है, तो Bazel, build:linux से शुरू होने वाली लाइनें चुनता है. इस्तेमाल किए जा सकने वाले ओएस आइडेंटिफ़ायर में linux, macos, windows, freebsd, और openbsd शामिल हैं. इस फ़्लैग को चालू करना, Linux पर --config=linux, Windows पर --config=windows वगैरह का इस्तेमाल करने के बराबर है.

--[no]experimental_skymeld_ui डिफ़ॉल्ट: "गलत"

जब विश्लेषण और लागू करने की प्रोसेस एक साथ चल रही हो, तो दोनों की प्रोग्रेस दिखाता है.
टैग: terminal_output

--[no]experimental_windows_watchfs डिफ़ॉल्ट: "गलत"

अगर यह 'सही' पर सेट है, तो --watchfs के लिए, एक्सपेरिमेंट के तौर पर उपलब्ध Windows की सहायता चालू हो जाती है. अगर ऐसा नहीं है, तो Windows पर --watchfs काम नहीं करेगा. --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.> डिफ़ॉल्ट: "20s"

आउटगोइंग gRPC कनेक्शन के लिए, 'कनेक्शन बनाए रखने की सुविधा' का टाइम आउट कॉन्फ़िगर करता है. अगर --grpc_keepalive_time के साथ, 'किंग-ऐलिव' पिंग चालू किए जाते हैं, तो Bazel इस समयावधि के बाद पिंग का जवाब न मिलने पर, कनेक्शन को टाइम आउट कर देता है. समय को सेकंड के हिसाब से ज़्यादा सटीक माना जाता है. एक सेकंड से कम की वैल्यू सेट करने पर गड़बड़ी का मैसेज दिखता है. अगर 'किंग-ऐलिव' पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.

--[no]incompatible_disallow_symlink_file_to_dir डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो `ctx.actions.symlink` किसी फ़ाइल को डायरेक्ट्री में सिंबललिंक करने की अनुमति नहीं देगा.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_rule_name_parameter डिफ़ॉल्ट: "सही"

अगर इस पैरामीटर को 'सही है' पर सेट किया जाता है, तो `rule` को `name` पैरामीटर के साथ नहीं बुलाया जा सकता.
टैग: 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"

ज़्यादा जानकारी वाले प्रोग्रेस बार में, एक साथ की जा रही कार्रवाइयों की संख्या; हर कार्रवाई को एक अलग लाइन में दिखाया जाता है. प्रोग्रेस बार में हमेशा कम से कम एक नंबर दिखता है. एक से कम के सभी नंबर, एक पर मैप किए जाते हैं.
टैग: terminal_output

--[no]watchfs डिफ़ॉल्ट: "गलत"

Linux/macOS पर: अगर यह विकल्प 'सही' है, तो bazel हर फ़ाइल में बदलाव की जांच करने के बजाय, स्थानीय बदलावों के लिए ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करता है. Windows पर: फ़िलहाल, यह फ़्लैग काम नहीं करता. हालांकि, इसे --experimental_windows_watchfs के साथ चालू किया जा सकता है. किसी भी ओएस पर: अगर आपका फ़ाइल फ़ोल्डर, नेटवर्क फ़ाइल सिस्टम पर है और फ़ाइलों में किसी रिमोट मशीन से बदलाव किया जाता है, तो फ़ाइलों के सिंक होने का तरीका तय नहीं होता.

Analyze-profile के विकल्प

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--dump=<text or raw> [-d] डिफ़ॉल्ट: ब्यौरा देखें

पूरी प्रोफ़ाइल का डेटा डंप, इंसान के पढ़ने लायक 'टेक्स्ट' फ़ॉर्मैट या स्क्रिप्ट के हिसाब से 'रॉ' फ़ॉर्मैट में आउटपुट करता है.
टैग: affects_outputs

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

Aquery के विकल्प

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में किए गए बदलावों की वजह से, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में, सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

क्वेरी के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंजर्वेटिव"

अगर आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने की ज़रूरत होती है. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी एस्पेक्ट का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह 'bazel क्वेरी' के दौरान नहीं चलता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, <code>Label</code> इंस्टेंस पर लागू Starlark <code>str</code> फ़ंक्शन की तरह लेबल दिखाता है. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट को ज़्यादा आसानी से पढ़ने लायक बनाने के लिए, आउटपुट फ़ॉर्मैटर, मुख्य रिपॉज़िटरी के हिसाब से, रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output

--[no]deduplicate_depsets डिफ़ॉल्ट: "सही"

फ़ाइनल प्रोटो/टेक्स्टप्रोटो/JSON आउटपुट में, dep_set_of_files के ऐसे चाइल्ड एलिमेंट को हटाएं जो लीफ़ एलिमेंट नहीं हैं. इससे उन डेपसेट की डुप्लीकेट कॉपी नहीं हटती हैं जो एक ही पैरंट के साथ शेयर नहीं की जाती हैं. इससे, कार्रवाइयों के इनपुट आर्टफ़ैक्ट की असरदार सूची पर कोई असर नहीं पड़ता.
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल काट दिए जाएंगे; -1 का मतलब है कि लेबल काटा नहीं जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो डिपेंडेंसी ग्राफ़ में, ऐसी डिपेंडेंसी शामिल होंगी जिन पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics

--[no]include_artifacts डिफ़ॉल्ट: "सही"

आउटपुट में कार्रवाई के इनपुट और आउटपुट के नाम शामिल होते हैं. ये नाम बड़े हो सकते हैं.
टैग: terminal_output

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]include_commandline डिफ़ॉल्ट: "सही"

आउटपुट में ऐक्शन कमांड लाइन का कॉन्टेंट शामिल होता है. यह कॉन्टेंट काफ़ी बड़ा हो सकता है.
टैग: terminal_output

--[no]include_file_write_contents डिफ़ॉल्ट: "गलत"

FileWrite और SourceSymlinkManifest कार्रवाइयों के लिए फ़ाइल का कॉन्टेंट शामिल करें. यह कॉन्टेंट काफ़ी बड़ा हो सकता है.
टैग: terminal_output

--[no]include_param_files डिफ़ॉल्ट: "गलत"

कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें. यह कॉन्टेंट बड़ा हो सकता है. ध्यान दें: इस फ़्लैग को चालू करने पर, --include_commandline फ़्लैग अपने-आप चालू हो जाएगा.
टैग: terminal_output

--[no]incompatible_display_source_file_location डिफ़ॉल्ट: "सही"

डिफ़ॉल्ट रूप से True, सोर्स फ़ाइल का टारगेट दिखाता है. अगर यह सही है, तो जगह की जानकारी वाले आउटपुट में, सोर्स फ़ाइलों की पहली लाइन की जगह दिखती है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग: 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 की वैल्यू सेट नहीं है, तो --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" एट्रिब्यूट से जुड़ी डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics

--output=<a string> डिफ़ॉल्ट: "text"

वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. aquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: text, textproto, proto, jsonproto.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह फ़ील्ड, नियम के इंस्टेंस के लिए Starlark कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की गई थी.
टैग: terminal_output

--[no]proto:flatten_selects डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची के टाइप के लिए, फ़्लैट किया गया रिप्रज़ेंटेशन एक सूची होती है, जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप को शून्य पर फ़्लैट कर दिया जाता है.
टैग: build_file_semantics

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत"

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत"

हर नियम के इंस्टैंशिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output

--[no]proto:locations डिफ़ॉल्ट: "सही"

क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है या नहीं.
टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "all"

आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा से अलग की गई सूची. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output

--query_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां फ़ाइल के साथ-साथ कमांड-लाइन क्वेरी भी डालना गलत है.
टैग: changes_inputs

--[no]relative_locations डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output

--[no]skyframe_state डिफ़ॉल्ट: "गलत"

ज़्यादा विश्लेषण किए बिना, Skyframe से मौजूदा ऐक्शन ग्राफ़ को डंप करें. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय करने की सुविधा उपलब्ध नहीं है. यह फ़्लैग सिर्फ़ --output=proto या --output=textproto के साथ उपलब्ध है.
टैग: terminal_output

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: अगर यह विकल्प बंद है, तो 'होस्ट कॉन्फ़िगरेशन' या 'एक्सीक्यूशन' टारगेट पर निर्भरता, उस डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए सभी टारगेट को फ़िल्टर कर दिया जाता है. ये ऐसे टारगेट होते हैं जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, होस्ट या एक्सीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न (जोड़ने और घटाने वाले) का कॉमा लगाकर बनाया गया सेट. क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प में इनपुट के तौर पर वे टारगेट डाले जाते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, इस विकल्प का असर कॉन्फ़िगरेशन और ट्रांज़िशन पर पड़ सकता है. अगर यह विकल्प नहीं दिया गया है, तो क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट को टॉप-लेवल टारगेट माना जाता है. ध्यान दें: cquery के लिए, इस विकल्प को न बताने पर, हो सकता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल विकल्पों के साथ बिल्ड न हो पाएं.
टैग: loading_and_analysis

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'रिज़ॉल्यूशन में गड़बड़ी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` या मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--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_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,...> डिफ़ॉल्ट: ""

ऐक्शन के मेनिमोनिक के आधार पर, ऐक्शन के लागू होने की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो प्रोग्राम के चलने की जानकारी दिखाती हैं. कई सामान्य कार्रवाइयां, प्रोग्राम के चलने की जानकारी दिखाती हैं. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम का ध्यान रखना ज़रूरी है, क्योंकि एक ही मेनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' को जोड़ता है और 'y' को हटा देता है. 'Genrule=+requires-x', सभी Genrule कार्रवाइयों के लिए, लागू करने की जानकारी में 'requires-x' जोड़ता है. '(?!Genrule).*=-requires-x', Genrule से जुड़ी सभी कार्रवाइयों के लिए, कार्रवाइयों के लागू होने की जानकारी से 'requires-x' को हटा देता है.
टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar ऐक्शन को लगातार चालू रखें.
इस तरह बड़ा होता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

वर्कर का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को लगातार चालू रखने की सुविधा चालू करें.
इस तरह बड़ा होता है:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की लगातार होने वाली मल्टीप्लेक्स की गई कार्रवाइयां चालू करें.
इस तरह बड़ा होता है:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के ऐसे टूल चालू करना जो लगातार काम करते हैं और एक से ज़्यादा काम करते हैं. जैसे, डीकंपाइल करना, डीसुगर करना, और संसाधन प्रोसेस करना.
इस तरह बड़ा होता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, 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 टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए जाते हैं, तो बाइनरी एक फ़ैट APK होती है. इसमें, टारगेट किए गए हर प्लैटफ़ॉर्म के लिए नेटिव बाइनरी होती हैं.
टैग: 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_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

Apple टारगेट कंपाइलर. टूलचेन के वैरिएंट (उदाहरण के लिए, xcode-beta) चुनने के लिए मददगार.
टैग: affects_outputs, 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

--apple_grte_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Apple का टारगेट grte_top.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs, explicit_in_output_path

--compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger"

बाइनरी की जगह, जिसका इस्तेमाल कवरेज की रॉ रिपोर्ट को पोस्ट-प्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, '//tools/test:lcov_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:coverage_support"

कोड कवरेज इकट्ठा करने वाली हर टेस्ट ऐक्शन के इनपुट पर ज़रूरी सहायता फ़ाइलों की जगह. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_support' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

C++ कोड को कंपाइल करने के लिए, क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--custom_malloc=<a build target label> डिफ़ॉल्ट: जानकारी देखें

malloc फ़ंक्शन को पसंद के मुताबिक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs

--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के आगे - (नेगेटिव एक्सप्रेशन) लगाने का विकल्प होता है. यह सूची, कॉमा लगाकर अलग की गई पाबंदी की वैल्यू के टारगेट की सूची को (=) असाइन करती है. अगर कोई टारगेट किसी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा जैसे उसने शर्त की वैल्यू को, लागू करने से जुड़ी शर्तों के तौर पर बताया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64, //demo के तहत मौजूद किसी भी टारगेट में 'x86_64' जोड़ देगा. हालांकि, जिन टारगेट के नाम में 'test' शामिल है उनमें यह पैरामीटर नहीं जोड़ा जाएगा.
टैग: loading_and_analysis

--[no]experimental_enable_objc_cc_deps डिफ़ॉल्ट: "सही"

इससे objc_* नियमों को cc_library पर निर्भर करने की अनुमति मिलती है. साथ ही, --ios_multi_cpu में दी गई किसी भी वैल्यू के लिए, --cpu को "ios_<--ios_cpu>" पर सेट करके, किसी भी objc डिपेंडेंसी को बनाया जाता है.
टैग: loading_and_analysis, incompatible_change

--[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, लोकल और रिमोट, दोनों जगहों पर उपलब्ध है. अगर यह फ़ॉल्स है या दोनों डिवाइसों पर एक ही वर्शन उपलब्ध नहीं है, तो xcode-select की मदद से चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state

--extra_execution_platforms=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे प्लैटफ़ॉर्म जो ऐक्शन चलाने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को एग्ज़ैक्ट टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() की मदद से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले इस्तेमाल किया जाएगा.
टैग: execution

--extra_toolchains=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों को ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन की मदद से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले इस्तेमाल किया जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--grte_top=<a label> डिफ़ॉल्ट: जानकारी देखें

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़े.
टैग: action_command_lines, affects_outputs

--host_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

होस्ट कोड को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top सेट नहीं किया गया है, तो इसे अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, execution

--host_crosstool_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

डिफ़ॉल्ट रूप से, होस्ट कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler विकल्पों का भी इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया जाता है, तो Bazel दिए गए crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--host_grte_top=<a label> डिफ़ॉल्ट: जानकारी देखें

अगर यह सेटिंग तय की जाती है, तो यह होस्ट कॉन्फ़िगरेशन के लिए, libc टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> डिफ़ॉल्ट: ""

होस्ट सिस्टम के बारे में बताने वाले प्लैटफ़ॉर्म नियम का लेबल.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_disable_expand_if_all_available_in_flag_set डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, flag_sets में expand_if_all_available को तय करने की अनुमति नहीं देगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7008 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'नॉन-होस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, 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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, lto इंडेक्सिंग कमांड लाइन के लिए C++ लिंक ऐक्शन कमांड लाइन का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_cpu_and_compiler_attributes_from_cc_toolchain डिफ़ॉल्ट: "सही"

अगर यह सही है, तो cc_toolchain.cpu और cc_toolchain.compiler एट्रिब्यूट सेट होने पर, Bazel शिकायत करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7075 देखें.
टैग: loading_and_analysis, 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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel को cc_common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 पर जाएं.
टैग: loading_and_analysis, 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

--platforms=<a build target label> डिफ़ॉल्ट: ""

मौजूदा निर्देश के लिए टारगेट किए गए प्लैटफ़ॉर्म के बारे में बताने वाले, प्लैटफ़ॉर्म के नियमों के लेबल.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--python2_path=<a string> डिफ़ॉल्ट: जानकारी देखें

अब काम नहीं करता. `--incompatible_use_python_toolchains` से बंद कर दिया गया है.
टैग: no_op, deprecated

--python3_path=<a string> डिफ़ॉल्ट: जानकारी देखें

अब काम नहीं करता. `--incompatible_use_python_toolchains` से बंद कर दिया गया है.
टैग: no_op, deprecated

--python_path=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs

--python_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर को दिखाता है. अब काम नहीं करता; --incompatible_use_python_toolchains की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs

--target_platform_fallback=<a build target label> डिफ़ॉल्ट: "@local_config_platform//:host"

किसी प्लैटफ़ॉर्म के नियम का लेबल. इसका इस्तेमाल तब किया जाना चाहिए, जब कोई टारगेट प्लैटफ़ॉर्म सेट न किया गया हो और कोई भी प्लैटफ़ॉर्म मैपिंग, फ़्लैग के मौजूदा सेट से मैच न करती हो.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट tvOS SDK टूल के वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: जानकारी देखें

अगर यह एट्रिब्यूट तय किया गया है, तो काम की बिल्ड ऐक्शन के लिए, दिए गए वर्शन के Xcode का इस्तेमाल किया जाता है. अगर यह जानकारी नहीं दी गई है, तो Xcode के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"

xcode_config नियम का लेबल, जिसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]apple_enable_auto_dsym_dbg डिफ़ॉल्ट: "गलत"

डीबग बिल्ड के लिए, डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करने की सुविधा को ज़बरदस्ती चालू करना है या नहीं.
टैग: affects_outputs, action_command_lines

--[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 list of options> डिफ़ॉल्ट: ".pb.h"

cc_proto_library से बनने वाली हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated list 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> डिफ़ॉल्ट: "no"

यह बताता है कि 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/repo के अलावा, .runfiles/wsname/external/repo में बाहरी रिपॉज़िटरी के लिए, runfiles के सिर्फ़ लिंक वाले फ़ॉरेस्ट बनाएं.
टैग: 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 पेयर से तय किया जा सकता है. नाम से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. वहीं, 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 के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "गलत"

3.4.0 आर्ग्युमेंट के साथ Android databinding v2 का इस्तेमाल करना
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद"

यह तय करता है कि जब cc_binary साफ़ तौर पर कोई शेयर की गई लाइब्रेरी न बनाए, तो Android नियमों के C++ डिपेंडेंसी डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "alphabetical"

Android बाइनरी के लिए, मेनिफ़ेस्ट मर्ज करने वाले टूल को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अंग्रेज़ी वर्णमाला के क्रम में का मतलब है कि मेनिफ़ेस्ट, execroot के हिसाब से पाथ के हिसाब से क्रम में लगाए जाते हैं. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--apple_bitcode=<'mode' or 'platform=mode', where 'mode' is none, embedded_markers or embedded, and 'platform' is ios, visionos, watchos, tvos, macos or catalyst> एक से ज़्यादा बार इस्तेमाल किए जाने पर

डिवाइस आर्किटेक्चर को टारगेट करने वाले कंपाइल करने के चरणों के लिए, Apple का बिटकोड मोड तय करें. वैल्यू, '[platform=]mode' फ़ॉर्मैट में होती हैं. इसमें प्लैटफ़ॉर्म (जो 'ios', 'macos', 'tvos' या 'watchos' होना चाहिए) की वैल्यू देना ज़रूरी नहीं है. अगर यह एट्रिब्यूट दिया गया है, तो बिटकोड मोड खास तौर पर उस प्लैटफ़ॉर्म के लिए लागू होता है. अगर इसे नहीं दिया गया है, तो यह सभी प्लैटफ़ॉर्म के लिए लागू होता है. मोड 'none', 'embedded_markers' या 'embedded' होना चाहिए. यह विकल्प कई बार दिया जा सकता है.
टैग: loses_incremental_state

--[no]build_python_zip डिफ़ॉल्ट: "auto"

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 coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "fastbuild"

बाइनरी को जिस मोड में बनाया जाएगा उसके बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines, explicit_in_output_path

--conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

gcc को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs, explicit_in_output_path

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ नाम बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाले FDO इंस्ट्रूमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाने वाली cs_fdo_profile, जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs

--cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

हर --define विकल्प, किसी बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default"

यह तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "auto"

रनफ़ाइल्स के सिमलिंक ट्री को चालू करें; यह डिफ़ॉल्ट रूप से, Windows और अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में जावा संसाधनों को कंप्रेस करना
टैग: 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 APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: 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

--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत"

अगर यह तय किया गया है, तो collect_code_coverage चालू होने पर, Bazel gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--fat_apk_cpu=<comma-separated list 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 डिफ़ॉल्ट: "गलत"

HWASAN स्प्लिट बनाने हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--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") जनरेट करते हैं. साथ ही, लिंक करने के लिए, PIC वाली पहले से बनी लाइब्रेरी का इस्तेमाल किया जाता है, न कि PIC वाली लाइब्रेरी का. इसके अलावा, लिंक करने पर पोज़िशन-इंडिपेंडेंट एक्सीक्यूटेबल ("-pie") जनरेट होते हैं.
टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट या एक्सीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए, उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. वहीं, name=value पेयर से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से अलग सेट किया जाएगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> डिफ़ॉल्ट: "opt"

बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे, यह बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--host_conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए gcc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--host_cpu=<a string> डिफ़ॉल्ट: ""

होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए gcc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--host_features=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> की वैल्यू सबमिट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक सुविधाएं, हमेशा सकारात्मक सुविधाओं की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

होस्ट कॉन्फ़िगरेशन के लिए, Python के वर्शन को बदल देता है. यह "PY2" या "PY3" हो सकता है.
टैग: loading_and_analysis, affects_outputs

--host_linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट या exec कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, 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, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--host_swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए, swiftc को पास करने के अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--[no]incompatible_avoid_conflict_dlls डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Windows पर cc_library से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (DLLs) का नाम बदलकर name_{hash}.dll कर दिया जाएगा. यहां हैश का हिसाब, RepositoryName और DLL के पैकेज पाथ के आधार पर लगाया जाता है. यह विकल्प तब काम आता है, जब आपके पास एक ऐसा पैकेज हो जो एक ही नाम वाली कई cc_library पर निर्भर हो (उदाहरण के लिए, //foo/bar1:utils और //foo/bar2:utils).
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही"

अगर यह सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_use_host_features डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए --features और exec कॉन्फ़िगरेशन के लिए --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change

--[no]incompatible_use_platforms_repo_for_constraints डिफ़ॉल्ट: "सही"

अगर यह 'सही' है, तो @bazel_tools से पाबंदी की सेटिंग हटा दी जाती हैं.
टैग: 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_application बनाने के लिए, कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची. इसका नतीजा एक यूनिवर्सल बाइनरी होता है, जिसमें सभी तय किए गए आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive डिफ़ॉल्ट: "सही"

अब काम नहीं करता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में, linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर, alwayslink=1 का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ बैकएंड चरण (--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

--[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, bar.cc को छोड़कर //foo/ में मौजूद सभी 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. यहां regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. option_1 से option_n, कमांड लाइन के मनमुताबिक विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, bar.o को छोड़कर //foo/ में मौजूद सभी o फ़ाइलों की LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: जानकारी देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. इस फ़्लैग में एक बिल्ड लेबल डाला जा सकता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस होना चाहिए. उदाहरण के लिए, a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",) में मौजूद, लेबल की जानकारी देने वाली BUILD फ़ाइल. इन फ़ाइलों को Bazel को दिखाने के लिए, उससे जुड़े पैकेज में exports_files डायरेक्टिव जोड़ना पड़ सकता है. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, 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" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि --compilation_mode=fastbuild के लिए, स्ट्रिप करें.
टैग: affects_outputs

--stripopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप करने के लिए पास किए जाने वाले अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Swift कंपाइलेशन के लिए पास करने के अन्य विकल्प.
टैग: action_command_lines

--tvos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं. इन आर्किटेक्चर को कॉमा लगाकर अलग किया गया है.
टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, काम करने वाला कम से कम tvOS वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐप्लिकेशन के लिए, Apple visionOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐप्लिकेशन के लिए, Apple watchOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू रहेंगे. ऐसा तब भी होगा, जब xbinary_fdo का इस्तेमाल न किया गया हो.
टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: ""

cpu वैल्यू को target_environment वैल्यू पर अपने-आप मैप करने के लिए, environment_group का इस्तेमाल करें.
टैग: 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_allow_android_library_deps_without_srcs डिफ़ॉल्ट: "गलत"

srcs-less android_library नियमों को, डिपेंडेंसी के साथ इस्तेमाल करने की अनुमति देने से रोकने के लिए फ़्लैग. इसे डिफ़ॉल्ट रूप से रोल आउट करने के लिए, डेपो को खाली करना होगा.
टैग: eagerness_to_exit, loading_and_analysis

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

अगर यह सही है, तो यह जांच की जाती है कि कोई Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो आउटपुट फ़ाइलों के तौर पर इस्तेमाल होने वाले टारगेट के लिए, सिर्फ़ टेस्ट करने की सुविधा देखें. इसके लिए, जनरेट करने वाले नियम के लिए सिर्फ़ टेस्ट करने की सुविधा देखें. यह, 'डिवाइस किसे दिखे' सेटिंग की जांच से मेल खाता है.
टैग: 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_force_strict_header_check_from_starlark डिफ़ॉल्ट: "सही"

अगर चालू है, तो Starlark API में हेडर की सख्त जांच सेट करें
टैग: loading_and_analysis, changes_inputs, incompatible_change

--[no]incompatible_validate_top_level_header_inclusions डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, टॉप लेवल डायरेक्ट्री हेडर में शामिल किए गए एलिमेंट की भी पुष्टि करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]strict_filesets डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइल सेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है. check_fileset_dependencies_recursively बंद होने पर, यह काम नहीं करता.
टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच की जाती है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद"

जब तक यह विकल्प बंद नहीं किया जाता, तब तक यह जांच की जाती है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर एक्सपोर्ट के तौर पर दिखाता है या नहीं.
टैग: 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"

APKs पर साइन करने के लिए इस्तेमाल करने के लिए लागू करना
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements डिफ़ॉल्ट: "सही"

अगर यह सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: जानकारी देखें

iOS साइनिंग के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक, यह सर्टिफ़िकेट की पासकोड वाली पहचान की प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम का (सबस्ट्रिंग) हो सकता है.
टैग: action_command_lines

इस विकल्प से, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही"

काम नहीं करता. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के AnalysisFailureInfo के इंस्टेंस का प्रॉपेगेशन होता है. इसमें गड़बड़ी की जानकारी होती है. इससे बिल्ड पूरा न होने की स्थिति नहीं होती.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा को पार करने पर, नियम से जुड़ी गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental

--[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. यहां runs_per_test, पूर्णांक वैल्यू के लिए है और regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैरिएबल की वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.
टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1"

टेस्ट टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर चार पूर्णांकों को कॉमा लगाकर अलग-अलग किया गया है, तो वे कम, सामान्य, ज़्यादा, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों ही फ़ॉर्म में, -1 की वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहा जाता है.

--tvos_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में tvOS ऐप्लिकेशन चलाते समय, सिम्युलेट किया जाने वाला डिवाइस. जैसे, 'Apple TV 1080p'. डिवाइसों की सूची देखने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला tvOS का वर्शन.
टैग: test_runner

--watchos_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में watchOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है. उदाहरण के लिए, 'Apple Watch - 38mm'. डिवाइसों की सूची देखने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--watchos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या उसकी जांच करते समय, सिम्युलेटर पर चलाया जाने वाला watchOS वर्शन.
टैग: test_runner

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही"

अगर यह सही है, तो बिना एलान किए किए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

क्वेरी के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंजर्वेटिव"

अगर आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने की ज़रूरत होती है. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी एस्पेक्ट का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह 'bazel क्वेरी' के दौरान नहीं चलता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, <code>Label</code> इंस्टेंस पर लागू Starlark <code>str</code> फ़ंक्शन की तरह लेबल दिखाता है. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट को ज़्यादा आसानी से पढ़ने लायक बनाने के लिए, आउटपुट फ़ॉर्मैटर, मुख्य रिपॉज़िटरी के हिसाब से, रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output

--[no]deduplicate_depsets डिफ़ॉल्ट: "सही"

फ़ाइनल प्रोटो/टेक्स्टप्रोटो/JSON आउटपुट में, dep_set_of_files के ऐसे चाइल्ड एलिमेंट को हटाएं जो लीफ़ एलिमेंट नहीं हैं. इससे उन डेपसेट की डुप्लीकेट कॉपी नहीं हटती हैं जो एक ही पैरंट के साथ शेयर नहीं की जाती हैं. इससे, कार्रवाइयों के इनपुट आर्टफ़ैक्ट की असरदार सूची पर कोई असर नहीं पड़ता.
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल काट दिए जाएंगे; -1 का मतलब है कि लेबल काटा नहीं जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो डिपेंडेंसी ग्राफ़ में, ऐसी डिपेंडेंसी शामिल होंगी जिन पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics

--[no]include_artifacts डिफ़ॉल्ट: "सही"

आउटपुट में कार्रवाई के इनपुट और आउटपुट के नाम शामिल होते हैं. ये नाम बड़े हो सकते हैं.
टैग: terminal_output

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]include_commandline डिफ़ॉल्ट: "सही"

आउटपुट में ऐक्शन कमांड लाइन का कॉन्टेंट शामिल होता है. यह कॉन्टेंट काफ़ी बड़ा हो सकता है.
टैग: terminal_output

--[no]include_file_write_contents डिफ़ॉल्ट: "गलत"

FileWrite और SourceSymlinkManifest कार्रवाइयों के लिए फ़ाइल का कॉन्टेंट शामिल करें. यह कॉन्टेंट काफ़ी बड़ा हो सकता है.
टैग: terminal_output

--[no]include_param_files डिफ़ॉल्ट: "गलत"

कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें. यह कॉन्टेंट बड़ा हो सकता है. ध्यान दें: इस फ़्लैग को चालू करने पर, --include_commandline फ़्लैग अपने-आप चालू हो जाएगा.
टैग: terminal_output

--[no]incompatible_display_source_file_location डिफ़ॉल्ट: "सही"

डिफ़ॉल्ट रूप से True, सोर्स फ़ाइल का टारगेट दिखाता है. अगर यह सही है, तो जगह की जानकारी वाले आउटपुट में, सोर्स फ़ाइलों की पहली लाइन की जगह दिखती है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग: 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 की वैल्यू सेट नहीं है, तो --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" एट्रिब्यूट से जुड़ी डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics

--output=<a string> डिफ़ॉल्ट: "text"

वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. aquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: text, textproto, proto, jsonproto.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह फ़ील्ड, नियम के इंस्टेंस के लिए Starlark कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की गई थी.
टैग: terminal_output

--[no]proto:flatten_selects डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची के टाइप के लिए, फ़्लैट किया गया रिप्रज़ेंटेशन एक सूची होती है, जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप को शून्य पर फ़्लैट कर दिया जाता है.
टैग: build_file_semantics

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत"

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत"

हर नियम के इंस्टैंशिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output

--[no]proto:locations डिफ़ॉल्ट: "सही"

क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है या नहीं.
टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "all"

आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा से अलग की गई सूची. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output

--query_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां फ़ाइल के साथ-साथ कमांड-लाइन क्वेरी भी डालना गलत है.
टैग: changes_inputs

--[no]relative_locations डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output

--[no]skyframe_state डिफ़ॉल्ट: "गलत"

ज़्यादा विश्लेषण किए बिना, Skyframe से मौजूदा ऐक्शन ग्राफ़ को डंप करें. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय करने की सुविधा उपलब्ध नहीं है. यह फ़्लैग सिर्फ़ --output=proto या --output=textproto के साथ उपलब्ध है.
टैग: terminal_output

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: अगर यह विकल्प बंद है, तो 'होस्ट कॉन्फ़िगरेशन' या 'एक्सीक्यूशन' टारगेट पर निर्भरता, उस डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए सभी टारगेट को फ़िल्टर कर दिया जाता है. ये ऐसे टारगेट होते हैं जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, होस्ट या एक्सीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न (जोड़ने और घटाने वाले) का कॉमा लगाकर बनाया गया सेट. क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प में इनपुट के तौर पर वे टारगेट डाले जाते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, इस विकल्प का असर कॉन्फ़िगरेशन और ट्रांज़िशन पर पड़ सकता है. अगर यह विकल्प नहीं दिया गया है, तो क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट को टॉप-लेवल टारगेट माना जाता है. ध्यान दें: cquery के लिए, इस विकल्प को न बताने पर, हो सकता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल विकल्पों के साथ बिल्ड न हो पाएं.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]collapse_duplicate_defines डिफ़ॉल्ट: "गलत"

चालू होने पर, बिल्ड के शुरुआती दौर में ग़ैर-ज़रूरी --defines हटा दिए जाएंगे. इससे, मिलते-जुलते कुछ खास तरह के बिल्ड के लिए, विश्लेषण कैश मेमोरी को बेवजह नहीं मिटाया जाता.
टैग: loading_and_analysis, loses_incremental_state

--[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_objc_include_scanning डिफ़ॉल्ट: "गलत"

क्या C/C++ के लिए स्कैनिंग शामिल की जानी चाहिए.
टैग: loading_and_analysis, execution, changes_inputs

--[no]experimental_parse_headers_skipped_if_corresponding_srcs_found डिफ़ॉल्ट: "गलत"

अगर parse_headers सुविधा चालू है, तो एक ही टारगेट में एक ही बेसनेम वाला सोर्स मिलने पर, यह सुविधा अलग हेडर कंपाइल ऐक्शन नहीं बनाती.
टैग: loading_and_analysis, affects_outputs

--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत"

चालू होने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, cc_test नियमों पर निर्भर न करने वाले नियमों के लिए, कार्रवाई से जुड़ी समस्याओं को कम करना है. अगर --trim_test_configuration को 'गलत है' पर सेट किया जाता है, तो इसका कोई असर नहीं पड़ता.
टैग: 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 डिफ़ॉल्ट: "सही"

यह हर Jar फ़ाइल के लिए, इंडेक्स करने का ज़्यादातर काम अलग से करता है.
टैग: 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

--[no]use_singlejar_apkbuilder डिफ़ॉल्ट: "सही"

इस विकल्प का इस्तेमाल नहीं किया जा सकता. अब यह सुविधा काम नहीं करती और इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान, डीबग की जानकारी प्रिंट करें. इस फ़्लैग में रेगुलर एक्सप्रेशन का इस्तेमाल किया जाता है. इस एक्सप्रेशन की जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता लगाया जा सके कि किस टूल को डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. ऐसा हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए ही काम का हो.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत"

यह फ़्लैग, डिफ़ॉल्ट तरीके को बदल देता है, ताकि Python टारगेट के रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बनें. खास तौर पर, जब py_binary या py_test टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिंबललिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, `--incompatible_py3_is_default` को भी चालू करने का सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से PY3 का इस्तेमाल किया जाएगा, न कि PY2 का. अगर यह फ़्लैग सेट किया जाता है, तो हमारा सुझाव है कि आप `--incompatible_py2_outputs_are_suffixed` को भी सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python टूलचेन से तय किए गए Python रनटाइम का इस्तेमाल किया जाएगा. ऐसा --python_top जैसे लेगसी फ़्लैग से दिए गए रनटाइम के बजाय किया जाएगा.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

Python के मुख्य वर्शन का मोड, या तो `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट बदल देते हैं. भले ही, वे साफ़ तौर पर किसी वर्शन की जानकारी न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs, explicit_in_output_path

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "auto"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो 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 डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो clang के लिए कवरेज से 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 डिफ़ॉल्ट: "गलत"

--experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java लॉन्चर, उन टूल का इस्तेमाल करता है जो किसी बिल्ड के दौरान चलाए जाते हैं.

--host_javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, javac को पास करने के लिए अन्य विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "गलत"

अगर यह 'सही' है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. एक्सक्लूज़िव टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: 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_output=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 डिफ़ॉल्ट: "सही"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: "8"

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--legacy_main_dex_list_generator=<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++ प्रोटो कोड को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जिसमें Java प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जो JavaLite प्रोटो को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

protobuf कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो जिस शर्ड में कम से कम एक रन/अटैंप पास होता है और कम से कम एक रन/अटैंप फ़ेल होता है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: जानकारी देखें

Bazel के इस्तेमाल के लिए, शेल की एक्ज़ीक्यूटेबल फ़ाइल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन Bazel को पहली बार इस्तेमाल करने पर BAZEL_SH एनवायरमेंट वैरिएबल सेट है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel काम करता है. जैसे, Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने पर, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में गड़बड़ियां हो सकती हैं.
टैग: loading_and_analysis

--test_arg=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--test_filter=<a string> डिफ़ॉल्ट: जानकारी देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, चलाए जाने वाले टेस्ट की संख्या को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे यह तय नहीं होता कि कौनसे टारगेट बनाए जाएं.

--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1"

इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत"

टेस्ट रनर को फ़ेल फ़ास्ट विकल्प फ़ॉरवर्ड करता है. टेस्ट रनर को पहली बार फ़ेल होने पर, टेस्ट को रोक देना चाहिए.

--test_sharding_strategy=<explicit or disabled> डिफ़ॉल्ट: "explicit"

टेस्ट के लिए, शार्डिंग की रणनीति तय करें: 'explicit', ताकि सिर्फ़ तब शार्डिंग का इस्तेमाल किया जा सके, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'बंद है', ताकि टेस्ट के लिए डेटा को अलग-अलग हिस्सों में बांटने की सुविधा का कभी भी इस्तेमाल न किया जाए.

--tool_java_language_version=<a string> डिफ़ॉल्ट: "8"

Java भाषा का वह वर्शन जिसका इस्तेमाल, बिल्ड के दौरान ज़रूरी टूल चलाने के लिए किया जाता है

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन इंटरफ़ेस के लिए jar का इस्तेमाल करता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में, सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

लोकल रणनीतियां, दिए गए मेमोनेमिक के लिए इस्तेमाल करने के लिए. 'local' को मेनिमोन के तौर पर पास करने पर, बिना बताए गए मेनिमोन के लिए डिफ़ॉल्ट सेट हो जाता है. [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 की रणनीति का इस्तेमाल करते समय, सैंडबॉक्स की गई कार्रवाई को लागू करने के लिए, Docker इमेज का नाम (उदाहरण के लिए, "ubuntu:latest") डालें. साथ ही, यह भी पक्का करें कि प्लैटफ़ॉर्म के ब्यौरे में, कार्रवाई की remote_execution_properties में पहले से ही कंटेनर-इमेज एट्रिब्यूट मौजूद न हो. इस फ़्लैग की वैल्यू को 'docker run' में बिना किसी बदलाव के पास किया जाता है. इसलिए, यह Docker के सिंटैक्स और तरीकों के साथ काम करता है.
टैग: execution

--[no]experimental_docker_use_customized_images डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो Docker इमेज का इस्तेमाल करने से पहले, मौजूदा उपयोगकर्ता के uid और gid को उसमें इंजेक्ट करता है. अगर आपका बिल्ड / टेस्ट, कंटेनर में उपयोगकर्ता के नाम और होम डायरेक्ट्री पर निर्भर करता है, तो यह ज़रूरी है. यह सुविधा डिफ़ॉल्ट रूप से चालू रहती है. हालांकि, अगर आपके लिए इमेज को अपने-आप पसंद के मुताबिक बनाने की सुविधा काम नहीं करती है या आपको इसकी ज़रूरत नहीं है, तो इसे बंद किया जा सकता है.
टैग: execution

--[no]experimental_dynamic_exclude_tools डिफ़ॉल्ट: "सही"

सेट होने पर, "टूल के लिए" बनाए गए टारगेट, डाइनैमिक तरीके से लागू नहीं होते. ऐसे टारगेट को धीरे-धीरे बनाने की संभावना बहुत कम होती है. इसलिए, इन पर लोकल साइकल खर्च करने का कोई फ़ायदा नहीं है.
टैग: execution, host_machine_resource_optimizations

--experimental_dynamic_local_load_factor=<a double> डिफ़ॉल्ट: "0"

यह कंट्रोल करता है कि डाइनैमिक तरीके से लागू होने वाले फ़ंक्शन से, लोकल मशीन पर कितना लोड डाला जाए. इस फ़्लैग से यह तय होता है कि डाइनैमिक तरीके से लागू होने वाली कितनी कार्रवाइयों को एक साथ शेड्यूल किया जाएगा. यह Blaze के हिसाब से उपलब्ध सीपीयू की संख्या पर आधारित होता है. इसे --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 पर आधारित सैंडबॉक्सिंग की सुविधा चालू करें. अगर Docker इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं पड़ेगा.
टैग: execution

--experimental_persistent_javac

परफ़ॉर्मेंस को बेहतर बनाने के लिए, एक्सपेरिमेंट के तौर पर उपलब्ध Java कंपाइलर को चालू करें.
इस तरह बड़ा होता है:
  --strategy=Javac=worker
  --strategy=JavaIjar=local
  --strategy=JavaDeployJar=local
  --strategy=JavaSourceJar=local
  --strategy=Turbine=local

टैग: execution, host_machine_resource_optimizations

--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"> डिफ़ॉल्ट: "0"

अगर 0 है, तो कोई कार्रवाई पूरी होने के तुरंत बाद सैंडबॉक्स ट्री मिटाएं. इससे कार्रवाई पूरी होने में देरी होती है. अगर यह शून्य से ज़्यादा है, तो ऐसे थ्री को एक असाइनोक्रोनस थ्रेड पूल में मिटाएं. यह पूल, बिल्ड के चलने के दौरान एक साइज़ का होता है और सर्वर के खाली होने पर, इस फ़्लैग में बताए गए साइज़ तक बढ़ जाता है.
टैग: host_machine_resource_optimizations, execution

--experimental_sandboxfs_path=<a string> डिफ़ॉल्ट: "sandboxfs"

--experimental_use_sandboxfs के 'सही' होने पर इस्तेमाल करने के लिए, sandboxfs बाइनरी का पाथ. अगर सिर्फ़ नाम दिया गया है, तो PATH में मौजूद उस नाम की पहली बाइनरी का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution

--[no]experimental_split_xml_generation डिफ़ॉल्ट: "सही"

अगर यह फ़्लैग सेट है और कोई टेस्ट ऐक्शन, test.xml फ़ाइल जनरेट नहीं करता है, तो Bazel एक अलग ऐक्शन का इस्तेमाल करके, टेस्ट लॉग वाली डमी test.xml फ़ाइल जनरेट करता है. ऐसा न करने पर, Bazel टेस्ट ऐक्शन के हिस्से के तौर पर test.xml जनरेट करता है.
टैग: execution

--experimental_total_worker_memory_limit_mb=<an integer, 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_sandboxfs डिफ़ॉल्ट: "गलत"

लिंक सिंबल ट्री बनाने के बजाय, ऐक्शन की execroot डायरेक्ट्री बनाने के लिए sandboxfs का इस्तेमाल करें. अगर "हां" है, तो --experimental_sandboxfs_path से दी गई बाइनरी मान्य होनी चाहिए और sandboxfs के साथ काम करने वाले वर्शन से मेल खानी चाहिए. अगर "अपने-आप" है, तो हो सकता है कि बाइनरी मौजूद न हो या काम न कर रही हो.
टैग: host_machine_resource_optimizations, execution

--[no]experimental_use_windows_sandbox डिफ़ॉल्ट: "गलत"

कार्रवाइयां चलाने के लिए, Windows सैंडबॉक्स का इस्तेमाल करें. अगर "हां" है, तो --experimental_windows_sandbox_path से दी गई बाइनरी मान्य होनी चाहिए और sandboxfs के साथ काम करने वाले वर्शन से मेल खानी चाहिए. अगर "अपने-आप" है, तो हो सकता है कि बाइनरी मौजूद न हो या काम न कर रही हो.

--experimental_windows_sandbox_path=<a string> डिफ़ॉल्ट: "BazelSandbox.exe"

Windows सैंडबॉक्स बाइनरी का पाथ, जिसका इस्तेमाल तब किया जाता है, जब --experimental_use_windows_sandbox सही हो. अगर सिर्फ़ नाम दिया गया है, तो PATH में मौजूद उस नाम की पहली बाइनरी का इस्तेमाल करें.

--[no]experimental_worker_as_resource डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो वर्कर्स को ResourceManager से रिसॉर्स के तौर पर हासिल किया जाता है.
टैग: execution, host_machine_resource_optimizations

--[no]experimental_worker_cancellation डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो Bazel उन वर्कर्स को रद्द करने के अनुरोध भेज सकता है जो उन्हें सहायता देते हैं.
टैग: execution

--[no]experimental_worker_multiplex डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो एक्सपेरिमेंट के तौर पर उपलब्ध मल्टीप्लेक्सिंग की सुविधा का इस्तेमाल करने वाले वर्कर्स, उस सुविधा का इस्तेमाल करेंगे.
टैग: execution, host_machine_resource_optimizations

--[no]experimental_worker_multiplex_sandboxing डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो मल्टीप्लेक्स वर्कर्स को सैंडबॉक्स किया जाएगा. इसके लिए, हर वर्क रिक्वेस्ट के लिए एक अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल किया जाएगा. सिर्फ़ उन वर्कर्स को सैंडबॉक्स किया जाएगा जिनमें 'supports-multiplex-sandboxing' एक्सीक्यूशन की ज़रूरी शर्तें मौजूद हैं.
टैग: execution

--[no]experimental_worker_strict_flagfiles डिफ़ॉल्ट: "गलत"

अगर इसे चालू किया जाता है, तो वर्कर्स के लिए कार्रवाइयों के ऐसे आर्ग्युमेंट से गड़बड़ी होगी जो वर्कर्स की खास बातों का पालन नहीं करते. वर्कर्स के आर्ग्युमेंट में, आखिरी आर्ग्युमेंट के तौर पर एक @flagfile आर्ग्युमेंट होना चाहिए.
टैग: execution

--genrule_strategy=<comma-separated list of options> डिफ़ॉल्ट: ""

genrules को लागू करने का तरीका बताएं. इस फ़्लैग को बंद कर दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरेटिव नियमों को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution

--high_priority_workers=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ज़्यादा प्राथमिकता के साथ चलाए जाने वाले वर्कर के मेमोनेमिक. जब ज़्यादा प्राथमिकता वाले वर्कर्स चल रहे होते हैं, तो अन्य सभी वर्कर्स को कम कर दिया जाता है.
टैग: execution

--[no]incompatible_remote_dangling_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है और --incompatible_remote_symlinks भी 'सही' पर सेट होता है, तो ऐक्शन आउटपुट में मौजूद सिंकलिंक को लटकने की अनुमति होती है.
टैग: execution, incompatible_change

--[no]incompatible_remote_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैश मेमोरी/कार्रवाई के आउटपुट में सिमलिंक को इस तरह दिखाएगा. ऐसा न करने पर, लिंक किए गए फ़ोल्डर को फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए, #6631 देखें.
टैग: execution, incompatible_change

--[no]incompatible_sandbox_hermetic_tmp डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो हर Linux सैंडबॉक्स में /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] डिफ़ॉल्ट: "auto"

एक साथ चलने वाली जॉब की संख्या. यह फ़ंक्शन कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) भी हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. 2500 से ज़्यादा वैल्यू से, मेमोरी से जुड़ी समस्याएं हो सकती हैं. "auto", होस्ट के संसाधनों के आधार पर, डिफ़ॉल्ट रूप से सही साइज़ का हिसाब लगाता है.
टैग: host_machine_resource_optimizations, execution

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 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

--spawn_strategy=<comma-separated list of options> डिफ़ॉल्ट: ""

बताएं कि स्पॉन ऐक्शन डिफ़ॉल्ट रूप से कैसे लागू होते हैं. इसमें रणनीतियों की सूची को कॉमा लगाकर, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के क्रम में लिखा जाता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली उस रणनीति को चुनता है जो कार्रवाई को पूरा कर सकती है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy=<a '[name=]value1[,..,valueN]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्पैन करने से जुड़ी अन्य कार्रवाइयों के कलेक्शन को डिस्ट्रिब्यूट करने का तरीका बताएं. इसमें रणनीतियों की सूची को कॉमा लगाकर, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के क्रम में लिखा जाता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली उस रणनीति को चुनता है जो कार्रवाई को पूरा कर सकती है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग, --spawn_strategy से सेट की गई वैल्यू को बदल देता है. साथ ही, अगर Genrule के साथ मेमोनिक का इस्तेमाल किया जाता है, तो --genrule_strategy से सेट की गई वैल्यू को भी बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्पैन ऐक्शन को लागू करने के लिए, किस स्पैन रणनीति का इस्तेमाल किया जाना चाहिए. यह रणनीति, किसी खास regex_filter से मैच करने वाली जानकारी के लिए तय की जाती है. regex_filter मैचिंग के बारे में जानकारी के लिए, --per_file_copt देखें. ब्यौरे से मैच करने वाले पहले रेगुलर एक्सप्रेशन फ़िल्टर का इस्तेमाल किया जाता है. यह विकल्प, रणनीति तय करने के लिए अन्य फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि अगर ऐक्शन के ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो लोकल रणनीति का इस्तेमाल करके ऐक्शन चलाएं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed, 'Compiling //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा. हालांकि, क्रम को उलटने पर, इसे 'sandboxed' के साथ चलाया जाएगा.
टैग: execution

--worker_extra_flag=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अतिरिक्त कमांड-फ़्लैग, जिन्हें --persistent_worker के अलावा वर्कर्स प्रोसेस को पास किया जाएगा.इनका नाम, याद रखने में आसान शब्दों से मिलता-जुलता होता है. जैसे, --worker_extra_flag=Javac=--debug.
टैग: execution, host_machine_resource_optimizations

--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> एक से ज़्यादा बार इस्तेमाल किए जाने पर

'वर्कर्स' रणनीति का इस्तेमाल करने पर, वर्कर्स प्रोसेस (जैसे कि पर्सिस्टेंट Java कंपाइलर) के कितने इंस्टेंस लॉन्च किए जा सकते हैं. हर वर्कर्स मेमोनिक के लिए अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर तय किया जा सकता है. यह फ़ंक्शन कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) भी हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". 'auto', मशीन की क्षमता के आधार पर डिफ़ॉल्ट रूप से सही साइज़ का हिसाब लगाता है. "=value", बिना बताए गए मेमोनिक के लिए डिफ़ॉल्ट सेट करता है.
टैग: execution, host_machine_resource_optimizations

--worker_max_multiplex_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> एक से ज़्यादा बार इस्तेमाल किए जाने पर

--experimental_worker_multiplex के साथ 'वर्कर्स' रणनीति का इस्तेमाल करने पर, मल्टीप्लेक्स वर्कर्स प्रोसेस को एक साथ कितने वर्क रिक्वेस्ट मिल सकते हैं. हर वर्कर्स मेमोनिक के लिए अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर तय किया जा सकता है. यह फ़ंक्शन कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) भी हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". 'auto', मशीन की क्षमता के आधार पर डिफ़ॉल्ट रूप से सही साइज़ का हिसाब लगाता है. "=value", बिना बताए गए मेमोनिक के लिए डिफ़ॉल्ट सेट करता है.
टैग: execution, host_machine_resource_optimizations

--[no]worker_quit_after_build डिफ़ॉल्ट: "गलत"

इस विकल्प के चालू होने पर, बिल्ड पूरा होने के बाद सभी वर्कर्स बंद हो जाते हैं.
टैग: execution, host_machine_resource_optimizations

--[no]worker_sandboxing डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो वर्कर सैंडबॉक्स वाले एनवायरमेंट में चलेंगे.
टैग: execution

--[no]worker_verbose डिफ़ॉल्ट: "गलत"

अगर यह चालू है, तो वर्कर्स के शुरू होने, बंद होने वगैरह पर ज़्यादा जानकारी वाले मैसेज प्रिंट करता है

ऐक्शन को लागू करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--[no]incompatible_disable_runtimes_filegroups डिफ़ॉल्ट: "गलत"

अब काम नहीं करता.
टैग: action_command_lines, loading_and_analysis, deprecated, incompatible_change

--[no]incompatible_dont_emit_static_libgcc डिफ़ॉल्ट: "सही"

अब काम नहीं करता.
टैग: action_command_lines, loading_and_analysis, deprecated, incompatible_change

--[no]incompatible_linkopts_in_user_link_flags डिफ़ॉल्ट: "सही"

अब काम नहीं करता.
टैग: action_command_lines, loading_and_analysis, deprecated, incompatible_change

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]build डिफ़ॉल्ट: "सही"

बिल्ड को लागू करें; यह सामान्य तरीका है. --nobuild का इस्तेमाल करने पर, बिल्ड ऐक्शन लागू करने से पहले ही बिल्ड रुक जाता है. अगर पैकेज लोड करने और विश्लेषण के चरण सही तरीके से पूरे हो जाते हैं, तो यह शून्य दिखाता है. यह मोड, उन चरणों की जांच करने के लिए काम का है.
टैग: execution, affects_outputs

--[no]experimental_run_validations डिफ़ॉल्ट: "सही"

इसके बजाय, --run_validations का इस्तेमाल करें.
टैग: execution, affects_outputs

--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "गलत"

क्या टेस्ट के साथ पैरलल तरीके से काम करने के लिए, आसपेक्ट का इस्तेमाल करके पुष्टि करने की कार्रवाइयां चलानी हैं.
टैग: execution, affects_outputs

--output_groups=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इनमें से हर नाम के आगे + या - लगाने का विकल्प होता है. + लगाने पर, ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ दिया जाता है. वहीं, - लगाने पर, ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप के नाम में प्रीफ़िक्स नहीं जोड़ा गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हटा दिया जाता है. उदाहरण के लिए, --output_groups=+foo,+bar, डिफ़ॉल्ट सेट, foo, और bar का यूनियन बनाता है. वहीं, --output_groups=foo,bar, डिफ़ॉल्ट सेट को बदल देता है, ताकि सिर्फ़ foo और bar बनाए जाएं.
टैग: execution, affects_outputs

--[no]run_validations डिफ़ॉल्ट: "सही"

बिल्ड के हिस्से के तौर पर, पुष्टि करने वाली कार्रवाइयां चलानी हैं या नहीं. https://bazel.build/rules/rules#validation_actions पर जाएं
टैग: execution, affects_outputs

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--aspects=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टॉप-लेवल टारगेट पर लागू किए जाने वाले आसपेक्ट की सूची, जिसमें कॉमा लगाकर आसपेक्ट को अलग किया गया है. अगर सूची में, किसी एस्पेक्ट some_aspect के लिए, ज़रूरी एस्पेक्ट की सेवा देने वाली कंपनियों की जानकारी, required_aspect_providers के ज़रिए दी गई है, तो some_aspect उन सभी एस्पेक्ट के बाद चलेगा जिनके लिए विज्ञापन में बताई गई कंपनियां, some_aspect के लिए ज़रूरी एस्पेक्ट की सेवा देने वाली कंपनियों की ज़रूरी शर्तें पूरी करती हैं. इसके अलावा, some_aspect, ज़रूरी एट्रिब्यूट की वैल्यू देने के बाद ही चलेगा. इसके बाद, some_aspect के पास उन एस्पेक्ट के प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, उदाहरण के लिए, '//tools:my_def.bzl%my_aspect', जहां 'my_aspect', tools/my_def.bzl फ़ाइल की टॉप-लेवल वैल्यू है

--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1"

बीईपी आर्टफ़ैक्ट अपलोड करने के दौरान, ज़्यादा से ज़्यादा कितनी फ़ाइलें खोली जा सकती हैं.
टैग: affects_outputs

--[no]experimental_convenience_symlinks डिफ़ॉल्ट: "normal"

इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिंक (बिल्ड के बाद वर्कस्पेस में दिखने वाले लिंक) को कैसे मैनेज किया जाएगा. संभावित वैल्यू: सामान्य (डिफ़ॉल्ट): हर तरह का सुविधाजनक सिंबललिंक बनाया या मिटाया जाएगा. यह, बिल्ड के हिसाब से तय किया जाएगा. clean: सभी सिंबललिंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: इससे सिमलिनक नहीं हटेंगे. log_only: लॉग मैसेज जनरेट करें, जैसे कि 'normal' पास किया गया हो. हालांकि, फ़ाइल सिस्टम पर कोई कार्रवाई न करें. यह टूल के लिए काम का है. ध्यान दें कि सिर्फ़ उन सिमलिंक पर असर पड़ सकता है जिनके नाम --symlink_prefix की मौजूदा वैल्यू से जनरेट किए गए हैं. प्रीफ़िक्स बदलने पर, पहले से मौजूद सिमलिंक में कोई बदलाव नहीं होगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks_bep_event डिफ़ॉल्ट: "गलत"

इस फ़्लैग से यह कंट्रोल होता है कि हम BuildEventProtocol में, बिल्ड eventConvenienceSymlinksIdentified को पोस्ट करेंगे या नहीं. अगर वैल्यू 'सही है' पर सेट है, तो BuildEventProtocol में convenienceSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधाजनक लिंक की सूची होगी. अगर यह 'गलत' है, तो BuildEventProtocol में convenienceSymlinksIdentified एंट्री खाली होगी.
टैग: affects_outputs

--experimental_multi_cpu=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अब काम नहीं करता. कोई कार्रवाई नहीं.
टैग: affects_outputs, experimental

--remote_download_minimal

स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=minimal.
इस तरह बड़ा होता है:
  --nobuild_runfile_links
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=minimal

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> डिफ़ॉल्ट: "all"

अगर इसे 'कम से कम' पर सेट किया जाता है, तो स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होता. हालांकि, स्थानीय कार्रवाइयों के लिए ज़रूरी आउटपुट डाउनलोड किए जाते हैं. 'toplevel' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह लोकल मशीन पर टॉप लेवल टारगेट के आउटपुट भी डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की समस्या है, तो दोनों विकल्पों से बिल्ड करने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs

--remote_download_symlink_template=<a string> डिफ़ॉल्ट: ""

रिमोट बिल्ड आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबल लिंक बनाएं. सिंबल लिंक का टारगेट, टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये क्रमशः ऑब्जेक्ट के हैश और बाइट में साइज़ में बदल जाते हैं. उदाहरण के लिए, ये सिंबल लिंक किसी ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर सीएएस से ऑब्जेक्ट लोड करता है.
टैग: affects_outputs

--remote_download_toplevel

सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट को लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=toplevel.
इस तरह बड़ा होता है:
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=toplevel

टैग: affects_outputs

--symlink_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

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

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]experimental_docker_privileged डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो कार्रवाइयां चलाते समय Bazel, 'docker run' को --privileged फ़्लैग पास करेगा. हो सकता है कि आपके बिल्ड के लिए यह ज़रूरी हो, लेकिन इससे डिवाइस के अंदर गैस या नमी के घुसने की संभावना बढ़ सकती है.
टैग: execution

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--[no]experimental_sandboxfs_map_symlink_targets डिफ़ॉल्ट: "गलत"

अगर यह 'सही' है, तो सैंडबॉक्स में कार्रवाई के इनपुट के तौर पर बताए गए सिंबल लिंक के टारगेट को मैप करता है. यह सुविधा, सिर्फ़ उन गड़बड़ी वाले नियमों को ठीक करने के लिए है जो अपने-आप ठीक नहीं होते. ऐसे सभी नियम ठीक होने के बाद, इस सुविधा को हटा दिया जाना चाहिए.
टैग: host_machine_resource_optimizations, execution

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

--[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 डिफ़ॉल्ट: "सही"

कार्रवाइयों के लिए, डिफ़ॉल्ट रूप से नेटवर्क ऐक्सेस की अनुमति दें; ऐसा हो सकता है कि यह सभी सैंडबॉक्सिंग लागू करने के साथ काम न करे.

--[no]sandbox_fake_hostname डिफ़ॉल्ट: "गलत"

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग: execution

--[no]sandbox_fake_username डिफ़ॉल्ट: "गलत"

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'कोई नहीं' में बदलें.
टैग: execution

--sandbox_writable_path=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सैंडबॉक्स की गई कार्रवाइयों के लिए, सैंडबॉक्स में मौजूद किसी डायरेक्ट्री को लिखने लायक बनाएं. ऐसा तब ही करें, जब सैंडबॉक्सिंग लागू करने की सुविधा काम करती हो. ऐसा न करने पर, डायरेक्ट्री को अनदेखा कर दिया जाएगा.
टैग: execution

इस विकल्प से, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की गई
टैग: no_op, deprecated, experimental

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: 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]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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर कोई टेस्ट पूरा नहीं हो पाता है, तो तय की गई संख्या तक हर टेस्ट को फिर से आज़माया जाएगा. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश की गई है उन्हें टेस्ट की खास जानकारी में 'अमान्य' के तौर पर मार्क किया जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक या स्ट्रिंग 'default' होती है. अगर यह एक पूर्णांक है, तो सभी टेस्ट 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"> डिफ़ॉल्ट: "auto"

एक साथ चलने वाली लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. यह फ़ंक्शन कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) भी हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, एक साथ चलने वाली लोकल टेस्ट जॉब की संख्या को सीमित कर देंगे. --jobs की वैल्यू से ज़्यादा वैल्यू सेट करने का कोई फ़ायदा नहीं है.
टैग: execution

--[no]test_keep_going डिफ़ॉल्ट: "सही"

अगर यह विकल्प बंद है, तो कोई भी टेस्ट पास न होने पर पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट चलाए जाते हैं. भले ही, कुछ टेस्ट पास न हों.
टैग: execution

--test_strategy=<a string> डिफ़ॉल्ट: ""

यह बताता है कि टेस्ट करते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution

--test_tmpdir=<a path> डिफ़ॉल्ट: जानकारी देखें

'bazel test' के इस्तेमाल के लिए, बेस टेम्पररी डायरेक्ट्री तय करता है.

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]announce डिफ़ॉल्ट: "गलत"

अब काम नहीं करता. कोई कार्रवाई नहीं की जाती.
टैग: affects_outputs

--[no]debug_spawn_scheduler डिफ़ॉल्ट: "गलत"

--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत"

TargetSummary इवेंट पब्लिश करने हैं या नहीं.

--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs

--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में रिलेटिव फ़ाइलसेट के लिंक को पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs

--experimental_build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4"

Bazel को बिल्ड इवेंट को अपलोड करने की कोशिश कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s"

बीईपी अपलोड न हो पाने पर, एक्सपोनेंशियल बैकऑफ़ की वजह से होने वाली शुरुआती देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration

--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुनता है.
टैग: affects_outputs

--[no]experimental_collect_local_sandbox_action_metrics डिफ़ॉल्ट: "सही"

सैंडबॉक्सिंग का इस्तेमाल करके स्थानीय तौर पर की गई कार्रवाइयों के लिए, कार्रवाइयों के आंकड़े रिकॉर्ड किए जाते हैं. जैसे, उपयोगकर्ता और सिस्टम का समय
टैग: execution

--[no]experimental_docker_verbose डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो Bazel, Docker सैंडबॉक्स की रणनीति के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करेगा.
टैग: execution

--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "गलत"

अगर पैरामीटर फ़ाइलों को मेटालाइज़ किया जा रहा है, तो डिस्क में सीधे लिखकर ऐसा करें.
टैग: execution

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

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

--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत"

लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs

--explain=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे बिल्ड सिस्टम, बिल्ड के हर चरण के बारे में जानकारी देता है. जानकारी, बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग: affects_outputs

--[no]legacy_important_outputs डिफ़ॉल्ट: "सही"

TargetComplete इवेंट में, लेगसी important_outputs फ़ील्ड जनरेट होने से रोकने के लिए, इसका इस्तेमाल करें. Bazel से ResultStore इंटिग्रेशन के लिए, important_outputs ज़रूरी है.
टैग: 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_output 'errors' या 'all' हो. यह विकल्प, बहुत ज़्यादा गड़बड़ी वाले टेस्ट आउटपुट से आउटपुट को भरने से रोकने के लिए मददगार होता है. लॉग के साइज़ में टेस्ट हेडर शामिल होता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट या तो पूरा होता है या नहीं होता.
टैग: test_runner, terminal_output, execution

--output_filter=<a valid Java regular expression> डिफ़ॉल्ट: जानकारी देखें

सिर्फ़ उन नियमों के लिए चेतावनियां दिखाता है जिनका नाम, दिए गए रेगुलर एक्सप्रेशन से मेल खाता है.
टैग: affects_outputs

--progress_report_interval=<an integer in 0-3600 range> डिफ़ॉल्ट: "0"

अभी चल रही जॉब की रिपोर्ट के बीच के सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद, फिर 30 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, प्रोग्रेस हर मिनट में रिपोर्ट की जाएगी. --curses चालू होने पर, प्रोग्रेस हर सेकंड रिपोर्ट की जाती है.
टैग: affects_outputs

--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "failure"

चुनें कि रिमोट से चलाए गए निर्देशों के मैसेज कब प्रिंट किए जाएं. मान्य वैल्यू: सिर्फ़ गड़बड़ियों पर प्रिंट करने के लिए `failure`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए `success`, और हमेशा प्रिंट करने के लिए `all`.
टैग: terminal_output

--[no]sandbox_debug डिफ़ॉल्ट: "गलत"

सैंडबॉक्सिंग की सुविधा के लिए, डीबग करने की सुविधाएं चालू करता है. इसमें दो चीज़ें शामिल हैं: पहला, बिल्ड के बाद सैंडबॉक्स के रूट कॉन्टेंट में कोई बदलाव नहीं किया जाता (अगर sandboxfs का इस्तेमाल किया जा रहा है, तो फ़ाइल सिस्टम को माउंट किया जाता है); और दूसरा, प्रोग्राम को चलाने पर डीबग करने से जुड़ी अतिरिक्त जानकारी प्रिंट की जाती है. इससे 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> डिफ़ॉल्ट: "short"

यह टेस्ट की खास जानकारी के लिए, मनचाहा फ़ॉर्मैट तय करता है. मान्य वैल्यू: 'short', सिर्फ़ चलाए गए टेस्ट की जानकारी प्रिंट करने के लिए, 'terse', सिर्फ़ उन टेस्ट की जानकारी प्रिंट करने के लिए जो पूरे नहीं हुए, 'detailed', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'testcase', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'none', खास जानकारी को हटाने के लिए.
टैग: terminal_output

--[no]verbose_explanations डिफ़ॉल्ट: "गलत"

--explain चालू होने पर, दी गई जानकारी को ज़्यादा शब्दों में दिखाता है. अगर --explain चालू नहीं है, तो इसका कोई असर नहीं पड़ता.
टैग: affects_outputs

--[no]verbose_failures डिफ़ॉल्ट: "गलत"

अगर कोई निर्देश काम नहीं करता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

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

अगर यह फ़ील्ड खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय, बताई गई ठीक की गई फ़ाइल को पढ़ें
टैग: changes_inputs

--target_pattern_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो बिल्ड, कमांड लाइन के बजाय यहां बताई गई फ़ाइल से पैटर्न पढ़ेगा. यहां फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न भी बताना गलत है.
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें

सर्किट ब्रेकर के इस्तेमाल के लिए रणनीति तय करता है. उपलब्ध रणनीतियां "फ़ेल्योर" हैं. विकल्प के लिए अमान्य वैल्यू देने पर, विकल्प के लिए सेट किया गया व्यवहार नहीं दिखता.
टैग: execution

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत"

किसी ऐक्शन की इनपुट फ़ाइलों को रिमोट कैश मेमोरी में अपलोड करने से पहले, उनकी ctime की जांच करने की सुविधा बंद करने के लिए, इसे बंद करें. कुछ मामलों में, Linux kernel फ़ाइलों को लिखने में देरी कर सकता है. इस वजह से, गलत नतीजे मिल सकते हैं.

--experimental_remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "all"

अगर इसे 'सभी' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड हो जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते.हालांकि, BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों (जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल) को अपलोड किया जाता है. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का हमेशा इस्तेमाल किया जाता है. भले ही, वे रिमोट कैश मेमोरी में मौजूद न हों. डिफ़ॉल्ट रूप से 'सभी' पर सेट होता है.

--[no]experimental_remote_cache_async डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो स्पॉन के हिस्से के तौर पर होने के बजाय, रिमोट कैश मेमोरी का I/O बैकग्राउंड में होगा.

--[no]experimental_remote_cache_compression डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो zstd की मदद से कैश मेमोरी ब्लॉब को कंप्रेस/डिकंप्रेस करें.

--experimental_remote_cache_eviction_retries=<an integer> डिफ़ॉल्ट: "0"

अगर बिल्ड को रिमोट कैश मेमोरी खाली करने से जुड़ी गड़बड़ी का पता चलता है, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. शून्य से ज़्यादा की वैल्यू से, --incompatible_remote_use_new_exit_code_for_lost_inputs को अपने-आप 'सही' पर सेट कर दिया जाएगा. हर कोशिश के लिए, एक नया आह्वान आईडी जनरेट होगा. अगर आपने invocation आईडी जनरेट किया है और उसे --invocation_id के साथ Bazel को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, --incompatible_remote_use_new_exit_code_for_lost_inputs फ़्लैग सेट करें और एग्ज़िट कोड 39 देखें.
टैग: execution

--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.

--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "गलत"

अगर इसे 'सही' पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़ी इनपुट मैपिंग की मेमोरी में मौजूद कॉपी को हटा दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में डेटा न मिलने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कैलकुलेट करना पड़ता है.

--experimental_remote_downloader=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट एसेट एपीआई एंडपॉइंट का यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाएगा. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

--[no]experimental_remote_downloader_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.

--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "गलत"

रिमोट तरीके से प्रोसेस करने के लिए, 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.> डिफ़ॉल्ट: "60s"

वह इंटरवल जिसमें रिमोट अनुरोधों के पूरा न होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, गड़बड़ी की अवधि को पूरे एक्सीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution

--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, इनपुट को रिमोट एक्सीक्यूटर के लिए टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर लगातार काम करने वाले वर्कर लागू करने के लिए किया जा सकता है.

--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेर्कल ट्री कैलकुलेशन को मेमोइज़ किया जाएगा. कैश मेमोरी का फ़ुटप्रिंट, --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.

--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000"

रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेमोज़ करने वाले मेर्कल ट्री की संख्या. भले ही, सॉफ़्ट रेफ़रंस को मैनेज करने के लिए Java, कैश मेमोरी को अपने-आप कम करता है, लेकिन बहुत ज़्यादा सेट करने पर, मेमोरी खत्म होने की गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड हो जाता है. प्रोजेक्ट के साइज़ के हिसाब से, ऑप्टिमम वैल्यू अलग-अलग होती है. डिफ़ॉल्ट रूप से 1,000.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो यह पक्का करें कि दूर से चलने वाली सभी कार्रवाइयां कैश मेमोरी में सेव हों. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह सुविधा, नॉन-डिटरमिनिस्टिक समस्याओं को हल करने में मदद करती है. इससे यह जांच की जा सकती है कि कैश मेमोरी में सेव की जानी वाली कार्रवाइयां, असल में कैश मेमोरी में सेव की गई हैं या नहीं. ऐसा करने के लिए, कैश मेमोरी में नए नतीजे इंजेक्ट नहीं किए जाते.

--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो BEP से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तौर पर कैश मेमोरी में कैश नहीं किया जा सकता.

--[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 डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो --noremote_upload_local_results और --noremote_accept_cached, डिस्क कैश मेमोरी पर लागू नहीं होंगे. अगर किसी कॉम्बाइन कैश का इस्तेमाल किया जाता है, तो: --noremote_upload_local_results का इस्तेमाल करने पर, नतीजे डिस्क कैश में सेव हो जाएंगे, लेकिन रिमोट कैश में अपलोड नहीं होंगे. --noremote_accept_cached का इस्तेमाल करने पर, Bazel डिस्क कैश मेमोरी में नतीजों की जांच करेगा, लेकिन रिमोट कैश मेमोरी में नहीं. no-remote-exec कार्रवाइयों से डिस्क कैश पर असर पड़ सकता है. ज़्यादा जानकारी के लिए, #8216 देखें.
टैग: incompatible_change

--[no]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो अगर बिल्ड के दौरान रिमोट कैश मेमोरी, ब्लॉब को हटाती है, तो Bazel 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगी.
टैग: incompatible_change

--[no]remote_accept_cached डिफ़ॉल्ट: "सही"

क्या कार्रवाई के रिमोट कैश मेमोरी में सेव किए गए नतीजों को स्वीकार करना है.

--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट स्ट्रीम में लिखे गए bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम. यह विकल्प तब सेट किया जा सकता है, जब किसी प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इसकी वजह से, --remote_executor और --remote_instance_name की वैल्यू, रिमोट इकसेक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. सेट न होने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.

--remote_cache=<a string> डिफ़ॉल्ट: जानकारी देखें

कैश मेमोरी में डेटा सेव करने वाले एंडपॉइंट का यूआरआई. इन स्कीम का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा की जानकारी दें. https://bazel.build/remote/caching पर जाएं

--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_properties सेट नहीं है, तो रिमोट एक्सीक्यूशन एपीआई के लिए सेट की जाने वाली डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. अगर होस्ट प्लैटफ़ॉर्म को रिमोट तौर पर चलाने के लिए, एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल भी किया जाएगा.

--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 या HOST:PORT. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा की वैल्यू दें.

--remote_grpc_log=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर यह पैरामीटर दिया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए, फ़ाइल का पाथ. इस लॉग में, सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry protobufs का क्रम होता है. हर मैसेज के आगे एक वैरिएंट होता है, जो सीरियलाइज़ किए गए अगले protobuf मैसेज का साइज़ दिखाता है. यह साइज़, LogEntry.writeDelimitedTo(OutputStream) तरीके से दिखाया जाता है.

--remote_header=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसा हेडर डालें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. एक से ज़्यादा हेडर पास करने के लिए, फ़्लैग को कई बार डालें. एक ही नाम के लिए एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.

--remote_instance_name=<a string> डिफ़ॉल्ट: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट तरीके से लागू करने की प्रोसेस पूरी न होने पर, स्टैंडअलोन लोकल तरीके से लागू करने की रणनीति का इस्तेमाल करना है या नहीं.

--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "local"

काम नहीं करता, अब इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

--remote_max_connections=<an integer> डिफ़ॉल्ट: "100"

रिमोट कैश मेमोरी/एग्ज़ीक्यूटर पर एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, यह तय करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एग्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को मैनेज कर सकता है. इसलिए, Bazel एक साथ `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations

--remote_proxy=<a string> डिफ़ॉल्ट: जानकारी देखें

प्रॉक्सी के ज़रिए रिमोट कैश मेमोरी से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.

--remote_result_cache_priority=<an integer> डिफ़ॉल्ट: "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.> डिफ़ॉल्ट: "60s"

रिमोट तरीके से एक्सीक्यूशन और कैश मेमोरी कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट और पढ़ने के लिए टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--[no]remote_upload_local_results डिफ़ॉल्ट: "सही"

अगर रिमोट कैश मेमोरी में कार्रवाई के नतीजे अपलोड किए जा सकते हैं और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या लोकल तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.

--[no]remote_verify_downloads डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो Bazel सभी रिमोट डाउनलोड के हैश का कुल हिसाब लगाएगा. साथ ही, अगर रिमोट से कैश मेमोरी में सेव की गई वैल्यू, उम्मीद के मुताबिक नहीं होती हैं, तो उन्हें खारिज कर देगा.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--[no]allow_analysis_cache_discard डिफ़ॉल्ट: "सही"

अगर बिल्ड सिस्टम में हुए बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज किया जाता है, तो इस विकल्प को 'गलत है' पर सेट करने से, bazel बिल्ड जारी रखने के बजाय बंद हो जाएगा. अगर 'discard_analysis_cache' भी सेट है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit

--auto_output_filter=<none, all, packages or subpackages> डिफ़ॉल्ट: "none"

अगर --output_filter की वैल्यू नहीं दी गई है, तो इस विकल्प की वैल्यू का इस्तेमाल करके, अपने-आप फ़िल्टर बन जाता है. इस विकल्प के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: 'none' (कुछ भी फ़िल्टर न करें / सब कुछ दिखाएं), 'all' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'packages' (Blaze कमांड लाइन पर बताए गए पैकेज में नियमों का आउटपुट शामिल करें), और 'subpackages' ('packages' की तरह, लेकिन इसमें सब-पैकेज भी शामिल हैं). 'पैकेज' और 'सब-पैकेज' वैल्यू के लिए, //java/foo और //javatests/foo को एक पैकेज माना जाता है)'.

--[no]build_manual_tests डिफ़ॉल्ट: "गलत"

'मैन्युअल' के तौर पर टैग किए गए टेस्ट टारगेट को बनाने के लिए मजबूर करता है. 'मैन्युअल' टेस्ट को प्रोसेस से बाहर रखा जाता है. इस विकल्प की मदद से, उन्हें बनाने के लिए मजबूर किया जाता है (हालांकि, उन्हें लागू नहीं किया जाता).

--build_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प का असर, 'test' कमांड के साथ चलाए गए टेस्ट के सेट पर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों से कंट्रोल किए जाते हैं. उदाहरण के लिए, '--test_tag_filters'

--[no]build_tests_only डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चुना जाता है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.

--combined_report=<none or lcov> डिफ़ॉल्ट: "none"

यह बताता है कि कवरेज की कुल रिपोर्ट किस तरह की होनी चाहिए. फ़िलहाल, सिर्फ़ LCOV का इस्तेमाल किया जा सकता है.

--[no]compile_one_dependency डिफ़ॉल्ट: "गलत"

आर्ग्युमेंट फ़ाइलों की एक डिपेंडेंसी को कॉम्पाइल करें. यह आईडीई में सोर्स फ़ाइलों के सिंटैक्स की जांच करने के लिए मददगार है. उदाहरण के लिए, बदलाव करने/बिल्ड करने/जांच करने के दौरान, गड़बड़ियों का पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर किसी एक टारगेट को फिर से बनाकर. इस आर्ग्युमेंट से, उन सभी आर्ग्युमेंट के इस्तेमाल के तरीके पर असर पड़ता है जो फ़्लैग नहीं हैं. ये आर्ग्युमेंट, बिल्ड करने के टारगेट के बजाय सोर्स फ़ाइल के नाम होते हैं. हर सोर्स फ़ाइल नाम के लिए, उस पर निर्भर कोई भी टारगेट बनाया जाएगा.

--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.> एक से ज़्यादा बार इस्तेमाल किए जाने पर

रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी में सेव करने, और उसे लागू करने के साथ-साथ, इवेंट की बिल्ड सेवा के लिए अनुमति के क्रेडेंशियल पाने के लिए, क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है. किसी हेल्पर से मिले क्रेडेंशियल, --google_default_credentials, --google_credentials, .netrc फ़ाइल या repository_ctx.download और repository_ctx.download_and_extract के auth पैरामीटर से मिले क्रेडेंशियल से ज़्यादा प्राथमिकता पाते हैं. एक से ज़्यादा हेल्पर सेट अप करने के लिए, कई बार इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-credential-helpers.md देखें.

--credential_helper_cache_duration=<An immutable length of time.> डिफ़ॉल्ट: "30 मीटर"

क्रेडेंशियल हेल्पर से मिले क्रेडेंशियल को कैश मेमोरी में सेव रखने की अवधि. किसी दूसरी वैल्यू के साथ कॉल करने पर, पहले से मौजूद एंट्री के लाइफ़टाइम में बदलाव होगा. कैश मेमोरी मिटाने के लिए, शून्य पास करें. इस फ़्लैग के बावजूद, क्लीन कमांड हमेशा कैश मेमोरी मिटाता है.

--credential_helper_timeout=<An immutable length of time.> डिफ़ॉल्ट: "10s"

क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. अगर क्रेडेंशियल हेल्पर इस टाइम आउट के अंदर जवाब नहीं देते हैं, तो अनुरोध पूरा नहीं होगा.

--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 के मुताबिक, इस फ़ाइल में, स्पान किए गए प्रोटो को डेलिमिटर के तौर पर लॉग करें. लॉग को पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, कॉल के आखिर में, इसे एक तय क्रम में क्रम से लगाया जाता है. यह सीपीयू और मेमोरी के लिए ज़्यादा खर्चीला हो सकता है. मिलते-जुलते फ़्लैग: --execution_log_json_file (क्रम में लगा टेक्स्ट JSON फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम का बाइनरी प्रोटोबस फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--execution_log_json_file=<a path> डिफ़ॉल्ट: जानकारी देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में लॉग किए गए स्पैन को, स्पैन प्रोटो के बीच में लगाए गए ब्रैकेट के JSON रेप्रज़ेंटेशन के तौर पर लॉग करें. लॉग को पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, कॉल के आखिर में, इसे एक तय क्रम में क्रम से लगाया जाता है. यह सीपीयू और मेमोरी के लिए ज़्यादा खर्चीला हो सकता है. मिलते-जुलते फ़्लैग: मिलते-जुलते फ़्लैग: --execution_log_binary_file (क्रम में लगाए गए बाइनरी प्रोटोबस फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम के लगाए गए बाइनरी प्रोटोबस फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--[no]execution_log_sort डिफ़ॉल्ट: "सही"

चल रहे कोड के लॉग को क्रम से लगाना है या नहीं. मेमोरी की परफ़ॉर्मेंस को बेहतर बनाने के लिए, इसे 'गलत' पर सेट करें. हालांकि, ऐसा करने पर लॉग को तय क्रम में नहीं बनाया जा सकेगा.

--[no]expand_test_suites डिफ़ॉल्ट: "सही"

विश्लेषण से पहले, test_suite टारगेट को उनके कॉम्पोनेंट टेस्ट में बड़ा करें. यह फ़्लैग चालू होने पर (डिफ़ॉल्ट रूप से), नेगेटिव टारगेट पैटर्न, टेस्ट सुइट से जुड़े टेस्ट पर लागू होंगे. ऐसा न होने पर, ये पैटर्न लागू नहीं होंगे. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड-लाइन पर टॉप-लेवल के पहलू लागू किए जाते हैं: तब वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis

--experimental_execution_log_file=<a path> डिफ़ॉल्ट: जानकारी देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में, स्पान किए गए प्रोटो को डेलिमिटर के तौर पर लॉग करें. यह फ़ाइल, स्पैन के लागू होने के क्रम में लिखी जाती है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (ऑर्डर किया गया बाइनरी प्रोटोबस फ़ॉर्मैट), --execution_log_json_file (ऑर्डर किया गया टेक्स्ट JSON फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--[no]experimental_execution_log_spawn_metrics डिफ़ॉल्ट: "गलत"

स्पैन लॉग में, स्पैन मेट्रिक शामिल करें.

--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: ""

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. extra_actions को शेड्यूल करने के लिए, टारगेट के सेट को फ़िल्टर करता है.

--[no]experimental_extra_action_top_level_only डिफ़ॉल्ट: "गलत"

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. सिर्फ़ टॉप लेवल टारगेट के लिए extra_actions शेड्यूल करता है.

--[no]experimental_prioritize_local_actions डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो सिर्फ़ स्थानीय तौर पर चलने वाली कार्रवाइयों को संसाधन हासिल करने का पहला मौका दिया जाता है. डाइनैमिक तौर पर चलने वाले वर्कर को दूसरा मौका मिलता है. डाइनैमिक तौर पर चलने वाली स्टैंडअलोन कार्रवाइयों को आखिरी मौका मिलता है.
टैग: execution

--experimental_spawn_scheduler

कार्रवाइयों को एक साथ स्थानीय और रिमोट तौर पर चलाकर, डाइनैमिक तरीके से लागू करने की सुविधा चालू करें. Bazel, हर कार्रवाई को स्थानीय और रिमोट तौर पर शुरू करता है. साथ ही, वह उस कार्रवाई को चुनता है जो सबसे पहले पूरी होती है. अगर कोई कार्रवाई, वर्कर के साथ काम करती है, तो लोकल कार्रवाई, पर्सिस्टेंट वर्कर मोड में चलेगी. किसी एक ऐक्शन के लिए डाइनैमिक तरीके से प्रोसेस करने की सुविधा चालू करने के लिए, `--internal_spawn_scheduler` और `--strategy=<mnemonic>=dynamic` फ़्लैग का इस्तेमाल करें.
इस तरह बड़ा होता है:
  --internal_spawn_scheduler
  --spawn_strategy=dynamic

--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.> डिफ़ॉल्ट: "20s"

आउटगोइंग gRPC कनेक्शन के लिए, 'कनेक्शन बनाए रखने की सुविधा' का टाइम आउट कॉन्फ़िगर करता है. अगर --grpc_keepalive_time के साथ, 'किंग-ऐलिव' पिंग चालू किए जाते हैं, तो Bazel इस समयावधि के बाद पिंग का जवाब न मिलने पर, कनेक्शन को टाइम आउट कर देता है. समय को सेकंड के हिसाब से ज़्यादा सटीक माना जाता है. एक सेकंड से कम की वैल्यू सेट करने पर गड़बड़ी का मैसेज दिखता है. अगर 'किंग-ऐलिव' पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.

--[no]ignore_unsupported_sandboxing डिफ़ॉल्ट: "गलत"

अगर इस सिस्टम पर सैंडबॉक्स में चलाने की सुविधा काम नहीं करती, तो चेतावनी न दिखाएं.

--[no]incompatible_dont_use_javasourceinfoprovider डिफ़ॉल्ट: "गलत"

कोई कार्रवाई नहीं करने वाले
टैग: incompatible_change

--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_CPUS"

Bazel के लिए उपलब्ध स्थानीय सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_CPUS" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_CPUS*.5, उपलब्ध सीपीयू कोर के आधे हिस्से का इस्तेमाल करने के लिए).डिफ़ॉल्ट रूप से, ("HOST_CPUS"), Bazel उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.

--local_extra_resources=<a named float, 'name=value'> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Bazel के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. स्ट्रिंग-फ़्लोट पेयर को इस्तेमाल करता है. एक से ज़्यादा तरह के अतिरिक्त संसाधनों की जानकारी देने के लिए, कई बार इस्तेमाल किया जा सकता है. Bazel, उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों की संख्या को सीमित कर देगा. टेस्ट, "resources:<resoucename>:<amount>" फ़ॉर्मैट के टैग का इस्तेमाल करके, यह बता सकते हैं कि उन्हें कितने अतिरिक्त संसाधनों की ज़रूरत है. इस फ़्लैग की मदद से, उपलब्ध सीपीयू, रैम, और संसाधनों को सेट नहीं किया जा सकता.

--local_ram_resources=<an integer, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_RAM*.67"

Bazel के लिए, स्थानीय होस्ट की कुल रैम (एमबी में) को साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_RAM" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_RAM*.5, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, ("HOST_RAM*.67") के लिए, Bazel उपलब्ध रैम की मात्रा का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और उसका 67% इस्तेमाल करेगा.

--local_termination_grace_seconds=<an integer> डिफ़ॉल्ट: "15"

टाइम आउट की वजह से किसी स्थानीय प्रोसेस को बंद करने और उसे जबरदस्ती बंद करने के बीच इंतज़ार करने का समय.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--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 कमांड पर असर पड़ता है.

--test_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

टेस्ट टैग की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. आपको सिर्फ़ ऐसे टेस्ट टारगेट मिलेंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: ""

टेस्ट टाइम आउट की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टाइम आउट की जानकारी देने के लिए, हर टाइम आउट के पहले '-' लगाया जा सकता है. सिर्फ़ ऐसे टेस्ट टारगेट दिखेंगे जिनमें कम से कम एक शामिल किया गया टाइम आउट हो और कोई बाहर रखा गया टाइम आउट न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--tls_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

उस TLS सर्टिफ़िकेट का पाथ डालें जिस पर सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.

--tls_client_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट की जानकारी दें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट पासकोड भी देना होगा.

--tls_client_key=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट पासकोड डालें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.

--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_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

--genrule_strategy=<comma-separated list of options> डिफ़ॉल्ट: ""

genrules को लागू करने का तरीका बताएं. इस फ़्लैग को बंद कर दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरेटिव नियमों को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution

--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> [-j] डिफ़ॉल्ट: "auto"

एक साथ चलने वाली जॉब की संख्या. यह फ़ंक्शन कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) भी हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. 2500 से ज़्यादा वैल्यू से, मेमोरी से जुड़ी समस्याएं हो सकती हैं. "auto", होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट तौर पर सही साइज़ का हिसाब लगाता है.
टैग: host_machine_resource_optimizations, execution

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> डिफ़ॉल्ट: ""

ऐक्शन के मेनिमोनिक के आधार पर, ऐक्शन के लागू होने की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो प्रोग्राम के चलने की जानकारी दिखाती हैं. कई सामान्य कार्रवाइयां, प्रोग्राम के चलने की जानकारी दिखाती हैं. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम का ध्यान रखना ज़रूरी है, क्योंकि एक ही मेनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' को जोड़ता है और 'y' को हटा देता है. 'Genrule=+requires-x', सभी Genrule कार्रवाइयों के लिए, लागू करने की जानकारी में 'requires-x' जोड़ता है. '(?!Genrule).*=-requires-x', Genrule से जुड़ी सभी कार्रवाइयों के लिए, कार्रवाइयों के लागू होने की जानकारी से 'requires-x' को हटा देता है.
टैग: execution, affects_outputs, loading_and_analysis

--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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की लगातार होने वाली कई कार्रवाइयों को चालू करें.
इस तरह बड़ा होता है:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के ऐसे टूल चालू करना जो लगातार काम करते हैं और एक से ज़्यादा काम करते हैं. जैसे, डीकंपाइल करना, डीसुगर करना, और संसाधन प्रोसेस करना.
इस तरह बड़ा होता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--spawn_strategy=<comma-separated list of options> डिफ़ॉल्ट: ""

बताएं कि स्पॉन ऐक्शन डिफ़ॉल्ट रूप से कैसे लागू होते हैं. इसमें रणनीतियों की सूची को कॉमा लगाकर, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के क्रम में लिखा जाता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली उस रणनीति को चुनता है जो कार्रवाई को पूरा कर सकती है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy=<a '[name=]value1[,..,valueN]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्पैन करने से जुड़ी अन्य कार्रवाइयों के कलेक्शन को डिस्ट्रिब्यूट करने का तरीका बताएं. इसमें रणनीतियों की सूची को कॉमा लगाकर, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के क्रम में लिखा जाता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली उस रणनीति को चुनता है जो कार्रवाई को पूरा कर सकती है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग, --spawn_strategy से सेट की गई वैल्यू को बदल देता है. साथ ही, अगर Genrule के साथ mnemonic का इस्तेमाल किया जाता है, तो --genrule_strategy से सेट की गई वैल्यू को भी बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्पैन ऐक्शन को लागू करने के लिए, किस स्पैन रणनीति का इस्तेमाल किया जाना चाहिए. यह रणनीति, किसी खास regex_filter से मैच करने वाली जानकारी के लिए तय की जाती है. regex_filter मैचिंग के बारे में जानकारी के लिए, --per_file_copt देखें. ब्यौरे से मैच करने वाले पहले रेगुलर एक्सप्रेशन फ़िल्टर का इस्तेमाल किया जाता है. यह विकल्प, रणनीति तय करने के लिए अन्य फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि अगर ऐक्शन के ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो लोकल रणनीति का इस्तेमाल करके ऐक्शन चलाएं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed, 'Compiling //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा. हालांकि, क्रम को उलटने पर, इसे 'sandboxed' के साथ चलाया जाएगा.
टैग: execution

ऐक्शन को लागू करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--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 टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए जाते हैं, तो बाइनरी एक फ़ैट APK होती है. इसमें, टारगेट किए गए हर प्लैटफ़ॉर्म के लिए नेटिव बाइनरी होती हैं.
टैग: 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_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

Apple टारगेट कंपाइलर. टूलचेन के वैरिएंट (उदाहरण के लिए, xcode-beta) चुनने के लिए मददगार.
टैग: affects_outputs, 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

--apple_grte_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Apple का टारगेट grte_top.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs, explicit_in_output_path

--compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger"

बाइनरी की जगह, जिसका इस्तेमाल कवरेज की रॉ रिपोर्ट को पोस्ट-प्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, '//tools/test:lcov_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:coverage_support"

कोड कवरेज इकट्ठा करने वाली हर टेस्ट ऐक्शन के इनपुट पर ज़रूरी सहायता फ़ाइलों की जगह. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_support' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

C++ कोड को कंपाइल करने के लिए, क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--custom_malloc=<a build target label> डिफ़ॉल्ट: जानकारी देखें

malloc फ़ंक्शन को पसंद के मुताबिक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs

--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के आगे - (नेगेटिव एक्सप्रेशन) लगाने का विकल्प होता है. यह सूची, कॉमा लगाकर अलग की गई पाबंदी की वैल्यू के टारगेट की सूची को (=) असाइन करती है. अगर कोई टारगेट किसी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा जैसे उसने शर्त की वैल्यू को, लागू करने से जुड़ी शर्तों के तौर पर बताया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64, //demo के तहत मौजूद किसी भी टारगेट में 'x86_64' जोड़ देगा. हालांकि, जिन टारगेट के नाम में 'test' शामिल है उनमें यह पैरामीटर नहीं जोड़ा जाएगा.
टैग: loading_and_analysis

--[no]experimental_enable_objc_cc_deps डिफ़ॉल्ट: "सही"

इससे objc_* नियमों को cc_library पर निर्भर करने की अनुमति मिलती है. साथ ही, --ios_multi_cpu में दी गई किसी भी वैल्यू के लिए, --cpu को "ios_<--ios_cpu>" पर सेट करके, किसी भी objc डिपेंडेंसी को बनाया जाता है.
टैग: loading_and_analysis, incompatible_change

--[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, लोकल और रिमोट, दोनों जगहों पर उपलब्ध होता है. अगर यह फ़ॉल्स है या दोनों डिवाइसों पर एक ही वर्शन उपलब्ध नहीं है, तो xcode-select की मदद से चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state

--extra_execution_platforms=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे प्लैटफ़ॉर्म जो ऐक्शन चलाने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को एग्ज़ैक्ट टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() की मदद से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले इस्तेमाल किया जाएगा.
टैग: execution

--extra_toolchains=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों को ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन की मदद से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले इस्तेमाल किया जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--grte_top=<a label> डिफ़ॉल्ट: जानकारी देखें

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़े.
टैग: action_command_lines, affects_outputs

--host_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

होस्ट कोड को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top सेट नहीं किया गया है, तो इसे अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, execution

--host_crosstool_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

डिफ़ॉल्ट रूप से, होस्ट कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler विकल्पों का भी इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया जाता है, तो Bazel दिए गए crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--host_grte_top=<a label> डिफ़ॉल्ट: जानकारी देखें

अगर यह सेटिंग तय की जाती है, तो यह होस्ट कॉन्फ़िगरेशन के लिए, libc टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> डिफ़ॉल्ट: ""

होस्ट सिस्टम के बारे में बताने वाले प्लैटफ़ॉर्म नियम का लेबल.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_disable_expand_if_all_available_in_flag_set डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, flag_sets में expand_if_all_available को तय करने की अनुमति नहीं देगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7008 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'नॉन-होस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, 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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, lto इंडेक्सिंग कमांड लाइन के लिए C++ लिंक ऐक्शन कमांड लाइन का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_cpu_and_compiler_attributes_from_cc_toolchain डिफ़ॉल्ट: "सही"

अगर यह सही है, तो cc_toolchain.cpu और cc_toolchain.compiler एट्रिब्यूट सेट होने पर, Bazel शिकायत करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7075 देखें.
टैग: loading_and_analysis, 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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel को cc_common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 पर जाएं.
टैग: loading_and_analysis, 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

--platforms=<a build target label> डिफ़ॉल्ट: ""

मौजूदा निर्देश के लिए टारगेट किए गए प्लैटफ़ॉर्म के बारे में बताने वाले, प्लैटफ़ॉर्म के नियमों के लेबल.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--python2_path=<a string> डिफ़ॉल्ट: जानकारी देखें

अब काम नहीं करता. `--incompatible_use_python_toolchains` से बंद कर दिया गया है.
टैग: no_op, deprecated

--python3_path=<a string> डिफ़ॉल्ट: जानकारी देखें

अब काम नहीं करता. `--incompatible_use_python_toolchains` से बंद कर दिया गया है.
टैग: no_op, deprecated

--python_path=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs

--python_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर को दिखाता है. अब काम नहीं करता; --incompatible_use_python_toolchains की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs

--target_platform_fallback=<a build target label> डिफ़ॉल्ट: "@local_config_platform//:host"

किसी प्लैटफ़ॉर्म के नियम का लेबल. इसका इस्तेमाल तब किया जाना चाहिए, जब कोई टारगेट प्लैटफ़ॉर्म सेट न किया गया हो और कोई भी प्लैटफ़ॉर्म मैपिंग, फ़्लैग के मौजूदा सेट से मैच न करती हो.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट tvOS SDK टूल के वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: जानकारी देखें

अगर यह एट्रिब्यूट तय किया गया है, तो काम की बिल्ड ऐक्शन के लिए, दिए गए वर्शन के Xcode का इस्तेमाल किया जाता है. अगर यह जानकारी नहीं दी गई है, तो Xcode के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"

xcode_config नियम का लेबल, जिसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]apple_enable_auto_dsym_dbg डिफ़ॉल्ट: "गलत"

डीबग बिल्ड के लिए, डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करने की सुविधा को ज़बरदस्ती चालू करना है या नहीं.
टैग: affects_outputs, action_command_lines

--[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 list of options> डिफ़ॉल्ट: ".pb.h"

cc_proto_library से बनने वाली हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated list 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_run_validations डिफ़ॉल्ट: "सही"

इसके बजाय, --run_validations का इस्तेमाल करें.
टैग: execution, affects_outputs

--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत"

कंपाइलेशन के आउटपुट के तौर पर, चालू और अनुरोध किए गए फ़ीचर की स्थिति सेव करें.
टैग: affects_outputs, experimental

--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "गलत"

क्या टेस्ट के साथ पैरलल तरीके से काम करने के लिए, आसपेक्ट का इस्तेमाल करके पुष्टि करने की कार्रवाइयां चलानी हैं.
टैग: execution, affects_outputs

--fission=<a set of compilation modes> डिफ़ॉल्ट: "no"

यह बताता है कि C++ कंपाइलेशन और लिंक के लिए, कौनसे कंपाइलेशन मोड फ़िज़न का इस्तेमाल करते हैं. यह {'fastbuild', 'dbg', 'opt'} या सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू का कोई भी कॉम्बिनेशन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही"

अगर यह सही है, तो नेटिव नियम अपने रनफ़ाइल में डेटा डिपेंडेंसी की <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 सिमलिंक फ़ॉरेस्ट बनाएं. साथ ही, .runfiles/repo में भी बनाएं.
टैग: affects_outputs

--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत"

यह बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs

--output_groups=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इनमें से हर नाम के आगे + या - लगाने का विकल्प होता है. + लगाने पर, ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ दिया जाता है. वहीं, - लगाने पर, ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप के नाम में प्रीफ़िक्स नहीं जोड़ा गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हटा दिया जाता है. उदाहरण के लिए, --output_groups=+foo,+bar, डिफ़ॉल्ट सेट, foo, और bar का यूनियन बनाता है. वहीं, --output_groups=foo,bar, डिफ़ॉल्ट सेट को बदल देता है, ताकि सिर्फ़ foo और bar बनाए जाएं.
टैग: execution, affects_outputs

--[no]run_validations डिफ़ॉल्ट: "सही"

बिल्ड के हिस्से के तौर पर, पुष्टि करने वाली कार्रवाइयां चलानी हैं या नहीं. https://bazel.build/rules/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 पेयर से तय किया जा सकता है. नाम से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. वहीं, 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 के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "गलत"

3.4.0 आर्ग्युमेंट के साथ Android databinding v2 का इस्तेमाल करना
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद"

यह तय करता है कि जब cc_binary साफ़ तौर पर कोई शेयर की गई लाइब्रेरी न बनाए, तो Android नियमों के C++ डिपेंडेंसी डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "alphabetical"

Android बाइनरी के लिए, मेनिफ़ेस्ट मर्ज करने वाले टूल को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अंग्रेज़ी वर्णमाला के क्रम में का मतलब है कि मेनिफ़ेस्ट, execroot के हिसाब से पाथ के हिसाब से क्रम में लगाए जाते हैं. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--apple_bitcode=<'mode' or 'platform=mode', where 'mode' is none, embedded_markers or embedded, and 'platform' is ios, visionos, watchos, tvos, macos or catalyst> एक से ज़्यादा बार इस्तेमाल किए जाने पर

डिवाइस आर्किटेक्चर को टारगेट करने वाले कंपाइल करने के चरणों के लिए, Apple का बिटकोड मोड तय करें. वैल्यू, '[platform=]mode' फ़ॉर्मैट में होती हैं. इसमें प्लैटफ़ॉर्म (जो 'ios', 'macos', 'tvos' या 'watchos' होना चाहिए) की वैल्यू देना ज़रूरी नहीं है. अगर यह एट्रिब्यूट दिया गया है, तो बिटकोड मोड खास तौर पर उस प्लैटफ़ॉर्म के लिए लागू होता है. अगर इसे नहीं दिया गया है, तो यह सभी प्लैटफ़ॉर्म के लिए लागू होता है. मोड 'none', 'embedded_markers' या 'embedded' होना चाहिए. यह विकल्प कई बार दिया जा सकता है.
टैग: loses_incremental_state

--aspects=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टॉप-लेवल टारगेट पर लागू किए जाने वाले आसपेक्ट की सूची, जिसमें कॉमा लगाकर आसपेक्ट को अलग किया गया है. अगर सूची में, किसी एस्पेक्ट some_aspect के लिए, ज़रूरी एस्पेक्ट की सेवा देने वाली कंपनियों की जानकारी, required_aspect_providers के ज़रिए दी गई है, तो some_aspect उन सभी एस्पेक्ट के बाद चलेगा जिनके लिए विज्ञापन में बताई गई कंपनियां, some_aspect के लिए ज़रूरी एस्पेक्ट की सेवा देने वाली कंपनियों की ज़रूरी शर्तें पूरी करती हैं. इसके अलावा, some_aspect, ज़रूरी एट्रिब्यूट की वैल्यू देने के बाद ही चलेगा. इसके बाद, some_aspect के पास उन एस्पेक्ट के प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, उदाहरण के लिए, '//tools:my_def.bzl%my_aspect', जहां 'my_aspect', tools/my_def.bzl फ़ाइल की टॉप-लेवल वैल्यू है

--[no]build_python_zip डिफ़ॉल्ट: "auto"

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 coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "fastbuild"

बाइनरी को जिस मोड में बनाया जाएगा उसके बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines, explicit_in_output_path

--conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

gcc को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs, explicit_in_output_path

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ नाम बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाले FDO इंस्ट्रूमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाने वाली cs_fdo_profile, जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs

--cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

हर --define विकल्प, किसी बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default"

यह तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "auto"

रनफ़ाइल्स के सिमलिंक ट्री को चालू करें; यह डिफ़ॉल्ट रूप से, Windows और अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में जावा संसाधनों को कंप्रेस करना
टैग: 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 APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: 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 डिफ़ॉल्ट: "normal"

इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिंक (बिल्ड के बाद वर्कस्पेस में दिखने वाले लिंक) को कैसे मैनेज किया जाएगा. संभावित वैल्यू: सामान्य (डिफ़ॉल्ट): हर तरह का सुविधाजनक सिंबललिंक बनाया या मिटाया जाएगा. यह, बिल्ड के हिसाब से तय किया जाएगा. clean: सभी सिंबललिंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: इससे सिमलिनक नहीं हटेंगे. log_only: लॉग मैसेज जनरेट करें, जैसे कि 'normal' पास किया गया हो. हालांकि, फ़ाइल सिस्टम पर कोई कार्रवाई न करें. यह टूल के लिए काम का है. ध्यान दें कि सिर्फ़ उन सिमलिंक पर असर पड़ सकता है जिनके नाम --symlink_prefix की मौजूदा वैल्यू से जनरेट किए गए हैं. प्रीफ़िक्स बदलने पर, पहले से मौजूद सिमलिंक में कोई बदलाव नहीं होगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks_bep_event डिफ़ॉल्ट: "गलत"

इस फ़्लैग से यह कंट्रोल होता है कि हम BuildEventProtocol में, बिल्ड eventConvenienceSymlinksIdentified को पोस्ट करेंगे या नहीं. अगर वैल्यू 'सही है' पर सेट है, तो BuildEventProtocol में convenienceSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधाजनक लिंक की सूची होगी. अगर यह 'गलत' है, तो BuildEventProtocol में convenienceSymlinksIdentified एंट्री खाली होगी.
टैग: affects_outputs

--experimental_multi_cpu=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अब काम नहीं करता. कोई कार्रवाई नहीं.
टैग: affects_outputs, experimental

--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

--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत"

अगर यह तय किया गया है, तो collect_code_coverage चालू होने पर, Bazel gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--fat_apk_cpu=<comma-separated list 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 डिफ़ॉल्ट: "गलत"

HWASAN स्प्लिट बनाने हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--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") जनरेट करते हैं. साथ ही, लिंक करने के लिए, PIC वाली पहले से बनी लाइब्रेरी का इस्तेमाल किया जाता है, न कि PIC वाली लाइब्रेरी का. इसके अलावा, लिंक करने पर पोज़िशन-इंडिपेंडेंट एक्सीक्यूटेबल ("-pie") जनरेट होते हैं.
टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट या एक्सीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए, उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. वहीं, name=value पेयर से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से अलग सेट किया जाएगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> डिफ़ॉल्ट: "opt"

बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे, यह बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--host_conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए gcc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--host_cpu=<a string> डिफ़ॉल्ट: ""

होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए gcc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--host_features=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> की वैल्यू सबमिट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक सुविधाएं, हमेशा सकारात्मक सुविधाओं की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

होस्ट कॉन्फ़िगरेशन के लिए, Python के वर्शन को बदल देता है. यह "PY2" या "PY3" हो सकता है.
टैग: loading_and_analysis, affects_outputs

--host_linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट या exec कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, 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, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--host_swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए, swiftc को पास करने के अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--[no]incompatible_avoid_conflict_dlls डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Windows पर cc_library से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (DLLs) का नाम बदलकर name_{hash}.dll कर दिया जाएगा. यहां हैश का हिसाब, RepositoryName और DLL के पैकेज पाथ के आधार पर लगाया जाता है. यह विकल्प तब काम आता है, जब आपके पास एक ऐसा पैकेज हो जो एक ही नाम वाली कई cc_library पर निर्भर हो (उदाहरण के लिए, //foo/bar1:utils और //foo/bar2:utils).
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही"

अगर यह सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_use_host_features डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए --features और exec कॉन्फ़िगरेशन के लिए --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change

--[no]incompatible_use_platforms_repo_for_constraints डिफ़ॉल्ट: "सही"

अगर यह 'सही' है, तो @bazel_tools से पाबंदी की सेटिंग हटा दी जाती हैं.
टैग: 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_application बनाने के लिए, कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची. इसका नतीजा एक यूनिवर्सल बाइनरी होता है, जिसमें सभी तय किए गए आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive डिफ़ॉल्ट: "सही"

अब काम नहीं करता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में, linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर, alwayslink=1 का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ बैकएंड चरण (--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

--[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, bar.cc को छोड़कर //foo/ में मौजूद सभी 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. यहां regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. option_1 से option_n, कमांड लाइन के मनमुताबिक विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, bar.o को छोड़कर //foo/ में मौजूद सभी o फ़ाइलों की LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: जानकारी देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. इस फ़्लैग में एक बिल्ड लेबल डाला जा सकता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस होना चाहिए. उदाहरण के लिए, a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",) में मौजूद, लेबल की जानकारी देने वाली BUILD फ़ाइल. इन फ़ाइलों को Bazel को दिखाने के लिए, उससे जुड़े पैकेज में exports_files डायरेक्टिव जोड़ना पड़ सकता है. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, 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" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि --compilation_mode=fastbuild के लिए, स्ट्रिप करें.
टैग: affects_outputs

--stripopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप करने के लिए पास किए जाने वाले अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Swift कंपाइलेशन के लिए पास करने के अन्य विकल्प.
टैग: action_command_lines

--symlink_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

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

--tvos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं. इन आर्किटेक्चर को कॉमा लगाकर अलग किया गया है.
टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, काम करने वाला कम से कम tvOS वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐप्लिकेशन के लिए, Apple visionOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐप्लिकेशन के लिए, Apple watchOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू रहेंगे. ऐसा तब भी होगा, जब xbinary_fdo का इस्तेमाल न किया गया हो.
टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: ""

cpu वैल्यू को target_environment वैल्यू पर अपने-आप मैप करने के लिए, environment_group का इस्तेमाल करें.
टैग: 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_allow_android_library_deps_without_srcs डिफ़ॉल्ट: "गलत"

srcs-less android_library नियमों को, डिपेंडेंसी के साथ इस्तेमाल करने की अनुमति देने से रोकने के लिए फ़्लैग. इसे डिफ़ॉल्ट रूप से रोल आउट करने के लिए, डेपो को खाली करना होगा.
टैग: eagerness_to_exit, loading_and_analysis

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

अगर यह सही है, तो यह जांच की जाती है कि कोई Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो आउटपुट फ़ाइलों के तौर पर इस्तेमाल होने वाले टारगेट के लिए, सिर्फ़ टेस्ट करने की सुविधा देखें. इसके लिए, जनरेट करने वाले नियम के लिए सिर्फ़ टेस्ट करने की सुविधा देखें. यह, 'डिवाइस किसे दिखे' सेटिंग की जांच से मेल खाता है.
टैग: 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_force_strict_header_check_from_starlark डिफ़ॉल्ट: "सही"

अगर चालू है, तो Starlark API में हेडर की सख्त जांच सेट करें
टैग: loading_and_analysis, changes_inputs, incompatible_change

--[no]incompatible_validate_top_level_header_inclusions डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, टॉप लेवल डायरेक्ट्री हेडर में शामिल किए गए एलिमेंट की भी पुष्टि करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]strict_filesets डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइल सेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है. check_fileset_dependencies_recursively बंद होने पर, यह काम नहीं करता.
टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच की जाती है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद"

जब तक यह विकल्प बंद नहीं किया जाता, तब तक यह जांच की जाती है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर एक्सपोर्ट के तौर पर दिखाता है या नहीं.
टैग: 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"

APKs पर साइन करने के लिए इस्तेमाल करने के लिए लागू करना
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements डिफ़ॉल्ट: "सही"

अगर यह सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: जानकारी देखें

iOS साइनिंग के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक, यह सर्टिफ़िकेट की पासकोड वाली पहचान की प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम का (सबस्ट्रिंग) हो सकता है.
टैग: action_command_lines

इस विकल्प से, Starlark भाषा के सेमेंटेक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=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_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के AnalysisFailureInfo के इंस्टेंस का प्रॉपेगेशन होता है. इसमें गड़बड़ी की जानकारी होती है. इससे बिल्ड पूरा न होने की स्थिति नहीं होती.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा को पार करने पर, नियम से जुड़ी गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो dex2oat कार्रवाई के पूरा न होने पर, टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, बिल्ड बंद हो जाएगा.
टैग: loading_and_analysis, experimental

--[no]check_tests_up_to_date डिफ़ॉल्ट: "गलत"

टेस्ट न चलाएं, सिर्फ़ यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी टेस्ट के नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर किसी टेस्ट को बनाने या चलाने की ज़रूरत है, तो गड़बड़ी की सूचना दी जाती है और टेस्ट पूरा नहीं होता. इस विकल्प का मतलब है कि --check_up_to_date का इस्तेमाल किया जा रहा है.
टैग: execution

--[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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर कोई टेस्ट पूरा नहीं हो पाता है, तो तय की गई संख्या तक हर टेस्ट को फिर से आज़माया जाएगा. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश की गई है उन्हें टेस्ट की खास जानकारी में 'अमान्य' के तौर पर मार्क किया जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक या स्ट्रिंग 'default' होती है. अगर यह एक पूर्णांक है, तो सभी टेस्ट 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"> डिफ़ॉल्ट: "auto"

एक साथ चलने वाली लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. यह फ़ंक्शन कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) भी हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, एक साथ चलने वाली लोकल टेस्ट जॉब की संख्या को सीमित कर देंगे. --jobs की वैल्यू से ज़्यादा वैल्यू सेट करने का कोई फ़ायदा नहीं है.
टैग: execution

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह हर टेस्ट को कितनी बार चलाने के लिए तय करता है. अगर इनमें से किसी भी कोशिश में किसी वजह से सफलता नहीं मिलती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test, पूर्णांक वैल्यू के लिए है और regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, उसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ '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 की वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहा जाता है.

--test_tmpdir=<a path> डिफ़ॉल्ट: जानकारी देखें

'bazel test' के इस्तेमाल के लिए, बेस टेम्पररी डायरेक्ट्री तय करता है.

--tvos_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में tvOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है, जैसे कि 'Apple TV 1080p'. डिवाइसों की सूची देखने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला tvOS का वर्शन.
टैग: test_runner

--watchos_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में watchOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है. उदाहरण के लिए, 'Apple Watch - 38mm'. डिवाइसों की सूची देखने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--watchos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या उसकी जांच करते समय, सिम्युलेटर पर चलाया जाने वाला watchOS वर्शन.
टैग: test_runner

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही"

अगर यह सही है, तो बिना एलान किए किए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]collapse_duplicate_defines डिफ़ॉल्ट: "गलत"

चालू होने पर, बिल्ड में पहले से मौजूद --defines को हटा दिया जाएगा. इससे, मिलते-जुलते कुछ खास तरह के बिल्ड के लिए, विश्लेषण कैश मेमोरी को बेवजह नहीं मिटाया जाता.
टैग: loading_and_analysis, loses_incremental_state

--[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_objc_include_scanning डिफ़ॉल्ट: "गलत"

क्या C/C++ के लिए स्कैनिंग शामिल की जानी चाहिए.
टैग: loading_and_analysis, execution, changes_inputs

--[no]experimental_parse_headers_skipped_if_corresponding_srcs_found डिफ़ॉल्ट: "गलत"

अगर parse_headers सुविधा चालू है, तो एक ही टारगेट में एक ही बेसनेम वाला सोर्स मिलने पर, यह सुविधा अलग हेडर कंपाइल ऐक्शन नहीं बनाती.
टैग: loading_and_analysis, affects_outputs

--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत"

चालू होने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, cc_test नियमों पर निर्भर न करने वाले नियमों के लिए, कार्रवाई से जुड़ी समस्याओं को कम करना है. अगर --trim_test_configuration को 'गलत है' पर सेट किया जाता है, तो इसका कोई असर नहीं पड़ता.
टैग: 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 डिफ़ॉल्ट: "सही"

यह हर Jar फ़ाइल के लिए, इंडेक्स करने का ज़्यादातर काम अलग से करता है.
टैग: 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

--[no]use_singlejar_apkbuilder डिफ़ॉल्ट: "सही"

इस विकल्प का इस्तेमाल नहीं किया जा सकता. अब यह सुविधा काम नहीं करती और इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]announce डिफ़ॉल्ट: "गलत"

अब काम नहीं करता. कोई कार्रवाई नहीं की जाती.
टैग: affects_outputs

--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत"

TargetSummary इवेंट पब्लिश करने हैं या नहीं.

--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs

--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में रिलेटिव फ़ाइलसेट के लिंक को पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs

--experimental_build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4"

Bazel को बिल्ड इवेंट को अपलोड करने की कोशिश कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s"

बीईपी अपलोड न हो पाने पर, एक्सपोनेंशियल बैकऑफ़ की वजह से होने वाली शुरुआती देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration

--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुनता है.
टैग: affects_outputs

--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "गलत"

अगर पैरामीटर फ़ाइलों को मेटालाइज़ किया जा रहा है, तो डिस्क में सीधे लिखकर ऐसा करें.
टैग: execution

--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत"

लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs

--explain=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे बिल्ड सिस्टम, बिल्ड के हर चरण के बारे में जानकारी देता है. जानकारी, बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग: affects_outputs

--[no]legacy_important_outputs डिफ़ॉल्ट: "सही"

TargetComplete इवेंट में, लेगसी important_outputs फ़ील्ड जनरेट होने से रोकने के लिए, इसका इस्तेमाल करें. Bazel से ResultStore इंटिग्रेशन के लिए, important_outputs ज़रूरी है.
टैग: 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_output 'errors' या 'all' हो. यह विकल्प, बहुत ज़्यादा गड़बड़ी वाले टेस्ट आउटपुट से आउटपुट को भरने से रोकने के लिए मददगार होता है. लॉग के साइज़ में टेस्ट हेडर शामिल होता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट या तो पूरा होता है या नहीं होता.
टैग: test_runner, terminal_output, execution

--output_filter=<a valid Java regular expression> डिफ़ॉल्ट: जानकारी देखें

सिर्फ़ उन नियमों के लिए चेतावनियां दिखाता है जिनका नाम, दिए गए रेगुलर एक्सप्रेशन से मेल खाता है.
टैग: affects_outputs

--progress_report_interval=<an integer in 0-3600 range> डिफ़ॉल्ट: "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> डिफ़ॉल्ट: "short"

यह टेस्ट की खास जानकारी के लिए, मनचाहा फ़ॉर्मैट तय करता है. मान्य वैल्यू: 'short', सिर्फ़ चलाए गए टेस्ट की जानकारी प्रिंट करने के लिए, 'terse', सिर्फ़ उन टेस्ट की जानकारी प्रिंट करने के लिए जो पूरे नहीं हुए, 'detailed', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'testcase', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'none', खास जानकारी को हटाने के लिए.
टैग: terminal_output

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान, डीबग की जानकारी प्रिंट करें. इस फ़्लैग में रेगुलर एक्सप्रेशन का इस्तेमाल किया जाता है. इस एक्सप्रेशन की जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता लगाया जा सके कि किस टूल को डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. ऐसा हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए ही काम का हो.
टैग: terminal_output

--[no]verbose_explanations डिफ़ॉल्ट: "गलत"

--explain चालू होने पर, दी गई जानकारी को ज़्यादा शब्दों में दिखाता है. अगर --explain चालू नहीं है, तो इसका कोई असर नहीं पड़ता.
टैग: affects_outputs

--[no]verbose_failures डिफ़ॉल्ट: "गलत"

अगर कोई निर्देश काम नहीं करता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--aspects_parameters=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कमांड-लाइन के आसपेक्ट पैरामीटर की वैल्यू तय करता है. हर पैरामीटर की वैल्यू, <param_name>=<param_value> के ज़रिए तय की जाती है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param', --aspects सूची में किसी पहलू का पैरामीटर है या सूची में किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. हालांकि, एक ही पैरामीटर को एक से ज़्यादा बार वैल्यू असाइन करने की अनुमति नहीं है.
टैग: loading_and_analysis

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत"

यह फ़्लैग, डिफ़ॉल्ट तरीके को बदल देता है, ताकि Python टारगेट के रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बनें. खास तौर पर, जब py_binary या py_test टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिंबललिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, `--incompatible_py3_is_default` को भी चालू करने का सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से PY2 के बजाय PY3 का इस्तेमाल किया जाएगा. अगर यह फ़्लैग सेट किया जाता है, तो हमारा सुझाव है कि आप `--incompatible_py2_outputs_are_suffixed` को भी सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python टूलचेन से तय किए गए Python रनटाइम का इस्तेमाल किया जाएगा. ऐसा --python_top जैसे लेगसी फ़्लैग से दिए गए रनटाइम के बजाय किया जाएगा.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

Python के मुख्य वर्शन का मोड, या तो `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट बदल देते हैं. भले ही, वे साफ़ तौर पर किसी वर्शन की जानकारी न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs, explicit_in_output_path

--target_pattern_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो बिल्ड, कमांड लाइन के बजाय यहां बताई गई फ़ाइल से पैटर्न पढ़ेगा. यहां फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न भी बताना गलत है.
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_remote_cache_eviction_retries=<an integer> डिफ़ॉल्ट: "0"

अगर बिल्ड को रिमोट कैश मेमोरी खाली करने से जुड़ी गड़बड़ी का पता चलता है, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. शून्य से ज़्यादा की वैल्यू से, --incompatible_remote_use_new_exit_code_for_lost_inputs को अपने-आप 'सही' पर सेट कर दिया जाएगा. हर कोशिश के लिए, एक नया आह्वान आईडी जनरेट होगा. अगर आपने invocation आईडी जनरेट किया है और उसे --invocation_id के साथ Bazel को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, --incompatible_remote_use_new_exit_code_for_lost_inputs फ़्लैग सेट करें और एग्ज़िट कोड 39 देखें.
टैग: execution

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा गया है.:

--[no]allow_analysis_cache_discard डिफ़ॉल्ट: "सही"

अगर बिल्ड सिस्टम में हुए बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज किया जाता है, तो इस विकल्प को 'गलत है' पर सेट करने से, bazel बिल्ड जारी रखने के बजाय बंद हो जाएगा. अगर 'discard_analysis_cache' भी सेट है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit

--[no]build_manual_tests डिफ़ॉल्ट: "गलत"

'मैन्युअल' के तौर पर टैग किए गए टेस्ट टारगेट को बनाने के लिए मजबूर करता है. 'मैन्युअल' टेस्ट को प्रोसेस से बाहर रखा जाता है. इस विकल्प की मदद से, उन्हें बनाने के लिए मजबूर किया जाता है (हालांकि, उन्हें लागू नहीं किया जाता).

--build_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प का असर, 'test' कमांड के साथ चलाए गए टेस्ट के सेट पर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों से कंट्रोल किए जाते हैं. उदाहरण के लिए, '--test_tag_filters'

--[no]build_tests_only डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चुना जाता है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.

--[no]cache_test_results [-t] डिफ़ॉल्ट: "auto"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो Bazel किसी टेस्ट को फिर से सिर्फ़ तब चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट चलाने का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. 'हां' पर सेट होने पर, Bazel, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजों को कैश मेमोरी में सेव नहीं करता.

--[no]compile_one_dependency डिफ़ॉल्ट: "गलत"

आर्ग्युमेंट फ़ाइलों की एक डिपेंडेंसी को कॉम्पाइल करें. यह आईडीई में सोर्स फ़ाइलों के सिंटैक्स की जांच करने के लिए मददगार है. उदाहरण के लिए, बदलाव करने/बिल्ड करने/जांच करने के दौरान, गड़बड़ियों का पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर किसी एक टारगेट को फिर से बनाकर. इस आर्ग्युमेंट से, उन सभी आर्ग्युमेंट के इस्तेमाल के तरीके पर असर पड़ता है जो फ़्लैग नहीं हैं. ये आर्ग्युमेंट, बिल्ड करने के टारगेट के बजाय सोर्स फ़ाइल के नाम होते हैं. हर सोर्स फ़ाइल नाम के लिए, उस पर निर्भर कोई भी टारगेट बनाया जाएगा.

--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 के मुताबिक, इस फ़ाइल में, स्पान किए गए प्रोटो को डेलिमिटर के तौर पर लॉग करें. लॉग को पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, कॉल के आखिर में, इसे एक तय क्रम में क्रम से लगाया जाता है. यह सीपीयू और मेमोरी के लिए ज़्यादा खर्चीला हो सकता है. मिलते-जुलते फ़्लैग: --execution_log_json_file (क्रम में लगा टेक्स्ट JSON फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम का बाइनरी प्रोटोबस फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--execution_log_json_file=<a path> डिफ़ॉल्ट: जानकारी देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में लॉग किए गए स्पैन को, स्पैन प्रोटो के बीच में लगाए गए ब्रैकेट के JSON रेप्रज़ेंटेशन के तौर पर लॉग करें. लॉग को पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, कॉल के आखिर में, इसे एक तय क्रम में क्रम से लगाया जाता है. यह सीपीयू और मेमोरी के लिए ज़्यादा खर्चीला हो सकता है. मिलते-जुलते फ़्लैग: मिलते-जुलते फ़्लैग: --execution_log_binary_file (क्रम में लगाए गए बाइनरी प्रोटोबस फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम के लगाए गए बाइनरी प्रोटोबस फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--[no]execution_log_sort डिफ़ॉल्ट: "सही"

चल रहे कोड के लॉग को क्रम से लगाना है या नहीं. मेमोरी की परफ़ॉर्मेंस को बेहतर बनाने के लिए, इसे 'गलत' पर सेट करें. हालांकि, ऐसा करने पर लॉग को तय क्रम में नहीं बनाया जा सकेगा.

--[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_file=<a path> डिफ़ॉल्ट: जानकारी देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में, स्पान किए गए प्रोटो को डेलिमिटर के तौर पर लॉग करें. यह फ़ाइल, स्पैन के लागू होने के क्रम में लिखी जाती है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (ऑर्डर किया गया बाइनरी प्रोटोबस फ़ॉर्मैट), --execution_log_json_file (ऑर्डर किया गया टेक्स्ट JSON फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--[no]experimental_execution_log_spawn_metrics डिफ़ॉल्ट: "गलत"

स्पैन लॉग में, स्पैन मेट्रिक शामिल करें.

--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: ""

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. extra_actions को शेड्यूल करने के लिए, टारगेट के सेट को फ़िल्टर करता है.

--[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 डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो clang के लिए कवरेज से 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 डिफ़ॉल्ट: "गलत"

--experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs

--[no]experimental_prioritize_local_actions डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो सिर्फ़ स्थानीय तौर पर चलने वाली कार्रवाइयों को संसाधन हासिल करने का पहला मौका दिया जाता है. डाइनैमिक तौर पर चलने वाले वर्कर को दूसरा मौका मिलता है. डाइनैमिक तौर पर चलने वाली स्टैंडअलोन कार्रवाइयों को आखिरी मौका मिलता है.
टैग: execution

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java लॉन्चर, उन टूल का इस्तेमाल करता है जो किसी बिल्ड के दौरान चलाए जाते हैं.

--host_javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, javac को पास करने के लिए अन्य विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "गलत"

अगर यह 'सही' है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. एक्सक्लूज़िव टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: 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_output=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 डिफ़ॉल्ट: "सही"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: "8"

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: जानकारी देखें

लेगसी मल्टीडेक्स को कंपाइल करते समय, मुख्य डेक्स में शामिल होने वाली क्लास की सूची जनरेट करने के लिए, इस्तेमाल की जाने वाली बाइनरी के बारे में बताता है.

--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_CPUS"

Bazel के लिए उपलब्ध स्थानीय सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_CPUS" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_CPUS*.5, उपलब्ध सीपीयू कोर के आधे हिस्से का इस्तेमाल करने के लिए).डिफ़ॉल्ट रूप से, ("HOST_CPUS"), Bazel सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा, ताकि उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाया जा सके.

--local_extra_resources=<a named float, 'name=value'> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Bazel के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. स्ट्रिंग-फ़्लोट पेयर को इस्तेमाल करता है. एक से ज़्यादा तरह के अतिरिक्त संसाधनों की जानकारी देने के लिए, कई बार इस्तेमाल किया जा सकता है. Bazel, उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों की संख्या को सीमित कर देगा. टेस्ट, "resources:<resoucename>:<amount>" फ़ॉर्मैट के टैग का इस्तेमाल करके, यह बता सकते हैं कि उन्हें कितने अतिरिक्त संसाधनों की ज़रूरत है. इस फ़्लैग की मदद से, उपलब्ध सीपीयू, रैम, और संसाधनों को सेट नहीं किया जा सकता.

--local_ram_resources=<an integer, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_RAM*.67"

Bazel के लिए, स्थानीय होस्ट की कुल रैम (एमबी में) को साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_RAM" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_RAM*.5, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, ("HOST_RAM*.67") के लिए, Bazel उपलब्ध रैम की मात्रा का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और उसका 67% इस्तेमाल करेगा.

--local_termination_grace_seconds=<an integer> डिफ़ॉल्ट: "15"

टाइम आउट की वजह से किसी स्थानीय प्रोसेस को बंद करने और उसे जबरदस्ती बंद करने के बीच इंतज़ार करने का समय.

--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++ प्रोटो कोड को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जिसमें Java प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जो JavaLite प्रोटो को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

protobuf कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो जिस शर्ड में कम से कम एक रन/अटैंप पास होता है और कम से कम एक रन/अटैंप फ़ेल होता है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: जानकारी देखें

Bazel के इस्तेमाल के लिए, शेल की एक्ज़ीक्यूटेबल फ़ाइल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन Bazel को पहली बार इस्तेमाल करने पर BAZEL_SH एनवायरमेंट वैरिएबल सेट है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel काम करता है. जैसे, Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने पर, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में गड़बड़ियां हो सकती हैं.
टैग: loading_and_analysis

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--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 or disabled> डिफ़ॉल्ट: "explicit"

टेस्ट के लिए, शार्ड करने की रणनीति तय करें: 'explicit', ताकि सिर्फ़ तब शार्डिंग का इस्तेमाल किया जा सके, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'बंद है', ताकि टेस्ट के लिए डेटा को अलग-अलग हिस्सों में बांटने की सुविधा का कभी भी इस्तेमाल न किया जाए.

--test_size_filters=<comma-separated list of values: small, medium, large or enormous> डिफ़ॉल्ट: ""

यह टेस्ट साइज़ की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए साइज़ की जानकारी देने के लिए, हर साइज़ के आगे '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. आपको सिर्फ़ ऐसे टेस्ट टारगेट मिलेंगे जिनमें शामिल किए गए कम से कम एक साइज़ शामिल हो और बाहर रखे गए कोई साइज़ शामिल न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

टेस्ट टैग की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. आपको सिर्फ़ ऐसे टेस्ट टारगेट मिलेंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: ""

टेस्ट टाइम आउट की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टाइम आउट की जानकारी देने के लिए, हर टाइम आउट के पहले '-' लगाया जा सकता है. आपको सिर्फ़ ऐसे टेस्ट टारगेट दिखेंगे जिनमें कम से कम एक शामिल किया गया टाइम आउट हो और कोई बाहर रखा गया टाइम आउट न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--tool_java_language_version=<a string> डिफ़ॉल्ट: "8"

Java भाषा का वह वर्शन जिसका इस्तेमाल, बिल्ड के दौरान ज़रूरी टूल चलाने के लिए किया जाता है

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन इंटरफ़ेस के लिए jar का इस्तेमाल करता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

Canonicalize-flags के विकल्प

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में, सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]canonicalize_policy डिफ़ॉल्ट: "गलत"

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

--[no]show_warnings डिफ़ॉल्ट: "गलत"

पार्सर की चेतावनियों को स्टैंडर्ड गड़बड़ी के तौर पर दिखाएं. जैसे, फ़्लैग के विकल्पों में विरोध होने पर.
टैग: affects_outputs, terminal_output

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की गई
टैग: no_op, deprecated, experimental

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: 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

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय, बताई गई ठीक की गई फ़ाइल को पढ़ें
टैग: changes_inputs

--for_command=<a string> डिफ़ॉल्ट: "build"

वह कमांड जिसके लिए विकल्पों को कैननिकल किया जाना चाहिए.
टैग: affects_outputs, terminal_output

--invocation_policy=<a string> डिफ़ॉल्ट: ""

कैनोनिकल किए जाने वाले विकल्पों पर, अनुरोध करने की नीति लागू करता है.
टैग: affects_outputs, terminal_output

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--deleted_packages=<comma-separated list of package names> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो हो सकता है कि वह शिकायत करे. ऐसा तब होगा, जब वह लेबल किसी अन्य package_path एंट्री से उपलब्ध कराया गया हो. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में किए गए बदलावों की वजह से, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में, सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]async डिफ़ॉल्ट: "गलत"

अगर यह 'सही' है, तो आउटपुट की सफ़ाई असाइनमेंट के साथ-साथ नहीं की जाती. यह निर्देश पूरा होने के बाद, उसी क्लाइंट में नए निर्देशों को सुरक्षित तरीके से लागू किया जा सकता है. भले ही, डेटा मिटाने की प्रोसेस बैकग्राउंड में जारी रह सकती है.
टैग: host_machine_resource_optimizations

--[no]expunge डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो clean इस bazel इंस्टेंस के लिए पूरा वर्किंग ट्री हटा देता है. इसमें, bazel की बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर bazel सर्वर चल रहा है, तो उसे बंद कर देता है.
टैग: host_machine_resource_optimizations

--expunge_async

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

टैग: host_machine_resource_optimizations

--[no]remove_all_convenience_symlinks डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो वर्कस्पेस में मौजूद, symlink_prefix प्रीफ़िक्स वाले सभी सिंकलिंक मिटा दिए जाएंगे. इस फ़्लैग के बिना, सिर्फ़ पहले से तय किए गए सफ़िक्स वाले सिंबललिंक हटाए जाते हैं.
टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी की सूचना दी जा सकती है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी देने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से बढ़ाएं. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

Cquery के विकल्प

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में किए गए बदलावों की वजह से, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में, सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग का इस्तेमाल करने पर, कैश मेमोरी की सुविधा बंद हो जाती है.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

क्वेरी के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंजर्वेटिव"

अगर आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने की ज़रूरत होती है. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी एस्पेक्ट का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह 'bazel क्वेरी' के दौरान नहीं चलता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, <code>Label</code> इंस्टेंस पर लागू Starlark <code>str</code> फ़ंक्शन की तरह लेबल दिखाता है. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट को ज़्यादा आसानी से पढ़ने लायक बनाने के लिए, आउटपुट फ़ॉर्मैटर, मुख्य रिपॉज़िटरी के हिसाब से, रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल काट दिए जाएंगे; -1 का मतलब है कि लेबल काटा नहीं जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो डिपेंडेंसी ग्राफ़ में, ऐसी डिपेंडेंसी शामिल होंगी जिन पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]incompatible_display_source_file_location डिफ़ॉल्ट: "सही"

डिफ़ॉल्ट रूप से True, सोर्स फ़ाइल का टारगेट दिखाता है. अगर यह सही है, तो जगह की जानकारी वाले आउटपुट में, सोर्स फ़ाइलों की पहली लाइन की जगह दिखती है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग: 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 की वैल्यू सेट नहीं है, तो --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" एट्रिब्यूट से जुड़ी डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics

--output=<a string> डिफ़ॉल्ट: "लेबल"

वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_kind, textproto, transitions, proto, jsonproto. 'ट्रांज़िशन' चुनने पर, आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह फ़ील्ड, नियम के इंस्टेंस के लिए Starlark कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की गई थी.
टैग: terminal_output

--[no]proto:flatten_selects डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची के टाइप के लिए, फ़्लैट किया गया रिप्रज़ेंटेशन एक सूची होती है, जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप को शून्य पर फ़्लैट कर दिया जाता है.
टैग: build_file_semantics

--[no]proto:include_configurations डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो प्रोटो आउटपुट में कॉन्फ़िगरेशन की जानकारी शामिल होगी. बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत"

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत"

हर नियम के इंस्टैंशिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output

--[no]proto:locations डिफ़ॉल्ट: "सही"

क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है या नहीं.
टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "all"

आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा से अलग की गई सूची. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: 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 के --output=starlark मोड में, कॉन्फ़िगर किए गए हर टारगेट को फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट, 'target' से बंधा होता है. अगर --starlark:expr और --starlark:file, दोनों में से किसी का भी इस्तेमाल नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट हो जाएगा. --starlark:expr और --starlark:file, दोनों को इस्तेमाल करना गड़बड़ी है.
टैग: terminal_output

--starlark:file=<a string> डिफ़ॉल्ट: ""

इस फ़ाइल में, एक आर्ग्युमेंट वाला 'format' नाम का Starlark फ़ंक्शन तय किया गया है. यह फ़ंक्शन, कॉन्फ़िगर किए गए हर टारगेट को स्ट्रिंग के तौर पर फ़ॉर्मैट करने के लिए लागू किया जाता है. --starlark:expr और --starlark:file, दोनों को इस्तेमाल करना गड़बड़ी है. ज़्यादा जानकारी के लिए, --output=starlark के लिए सहायता देखें.
टैग: terminal_output

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: अगर यह विकल्प बंद है, तो 'होस्ट कॉन्फ़िगरेशन' या 'एक्सीक्यूशन' टारगेट पर निर्भरता, उस डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए सभी टारगेट को फ़िल्टर कर दिया जाता है. ये ऐसे टारगेट होते हैं जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, होस्ट या एक्सीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics

--transitions=<full, lite or none> डिफ़ॉल्ट: "none"

वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगी.
टैग: affects_outputs

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न (जोड़ने और घटाने वाले) का कॉमा लगाकर बनाया गया सेट. क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प में इनपुट के तौर पर वे टारगेट डाले जाते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, इस विकल्प का असर कॉन्फ़िगरेशन और ट्रांज़िशन पर पड़ सकता है. अगर यह विकल्प नहीं दिया गया है, तो क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट को टॉप-लेवल टारगेट माना जाता है. ध्यान दें: cquery के लिए, इस विकल्प को न बताने पर, हो सकता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल विकल्पों के साथ बिल्ड न हो पाएं.
टैग: loading_and_analysis

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--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_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,...> डिफ़ॉल्ट: ""

ऐक्शन के मेनिमोनिक के आधार पर, ऐक्शन के लागू होने की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो प्रोग्राम के चलने की जानकारी दिखाती हैं. कई सामान्य कार्रवाइयां, प्रोग्राम के चलने की जानकारी दिखाती हैं. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम का ध्यान रखना ज़रूरी है, क्योंकि एक ही मेनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' को जोड़ता है और 'y' को हटा देता है. 'Genrule=+requires-x', सभी Genrule कार्रवाइयों के लिए, लागू करने की जानकारी में 'requires-x' जोड़ता है. '(?!Genrule).*=-requires-x', Genrule से जुड़ी सभी कार्रवाइयों के लिए, कार्रवाइयों के लागू होने की जानकारी से 'requires-x' को हटा देता है.
टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar ऐक्शन को लगातार चालू रखें.
इस तरह बड़ा होता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

वर्कर का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को लगातार चालू रखने की सुविधा चालू करें.
इस तरह बड़ा होता है:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की लगातार होने वाली कई कार्रवाइयों को चालू करें.
इस तरह बड़ा होता है:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के ऐसे टूल चालू करना जो लगातार काम करते हैं और एक से ज़्यादा काम करते हैं. जैसे, डीकंपाइल करना, डीसुगर करना, और संसाधन प्रोसेस करना.
इस तरह बड़ा होता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, 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 टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए जाते हैं, तो बाइनरी एक फ़ैट APK होती है. इसमें, टारगेट किए गए हर प्लैटफ़ॉर्म के लिए नेटिव बाइनरी होती हैं.
टैग: 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_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

Apple टारगेट कंपाइलर. टूलचेन के वैरिएंट (उदाहरण के लिए, xcode-beta) चुनने के लिए मददगार.
टैग: affects_outputs, 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

--apple_grte_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Apple का टारगेट grte_top.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs, explicit_in_output_path

--compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger"

बाइनरी की जगह, जिसका इस्तेमाल कवरेज की रॉ रिपोर्ट को पोस्ट-प्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, '//tools/test:lcov_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:coverage_support"

कोड कवरेज इकट्ठा करने वाली हर टेस्ट ऐक्शन के इनपुट पर ज़रूरी सहायता फ़ाइलों की जगह. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_support' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

C++ कोड को कंपाइल करने के लिए, क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--custom_malloc=<a build target label> डिफ़ॉल्ट: जानकारी देखें

malloc फ़ंक्शन को पसंद के मुताबिक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs

--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के आगे - (नेगेटिव एक्सप्रेशन) लगाने का विकल्प होता है. यह सूची, कॉमा लगाकर अलग की गई पाबंदी की वैल्यू के टारगेट की सूची को (=) असाइन करती है. अगर कोई टारगेट किसी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा जैसे उसने शर्त की वैल्यू को, लागू करने से जुड़ी शर्तों के तौर पर बताया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64, //demo के तहत मौजूद किसी भी टारगेट में 'x86_64' जोड़ देगा. हालांकि, जिन टारगेट के नाम में 'test' शामिल है उनमें यह पैरामीटर नहीं जोड़ा जाएगा.
टैग: loading_and_analysis

--[no]experimental_enable_objc_cc_deps डिफ़ॉल्ट: "सही"

इससे objc_* नियमों को cc_library पर निर्भर करने की अनुमति मिलती है. साथ ही, --ios_multi_cpu में दी गई किसी भी वैल्यू के लिए, --cpu को "ios_<--ios_cpu>" पर सेट करके, किसी भी objc डिपेंडेंसी को बनाया जाता है.
टैग: loading_and_analysis, incompatible_change

--[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, लोकल और रिमोट, दोनों जगहों पर उपलब्ध होता है. अगर यह फ़ॉल्स है या दोनों डिवाइसों पर एक ही वर्शन उपलब्ध नहीं है, तो xcode-select की मदद से चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state

--extra_execution_platforms=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे प्लैटफ़ॉर्म जो ऐक्शन चलाने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को एग्ज़ैक्ट टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() की मदद से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले इस्तेमाल किया जाएगा.
टैग: execution

--extra_toolchains=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों को ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन की मदद से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले इस्तेमाल किया जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--grte_top=<a label> डिफ़ॉल्ट: जानकारी देखें

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़े.
टैग: action_command_lines, affects_outputs

--host_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

होस्ट कोड को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top सेट नहीं किया गया है, तो इसे अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, execution

--host_crosstool_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

डिफ़ॉल्ट रूप से, होस्ट कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler विकल्पों का भी इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया जाता है, तो Bazel दिए गए crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--host_grte_top=<a label> डिफ़ॉल्ट: जानकारी देखें

अगर यह सेटिंग तय की जाती है, तो यह होस्ट कॉन्फ़िगरेशन के लिए, libc टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> डिफ़ॉल्ट: ""

होस्ट सिस्टम के बारे में बताने वाले प्लैटफ़ॉर्म नियम का लेबल.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_disable_expand_if_all_available_in_flag_set डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, flag_sets में expand_if_all_available को तय करने की अनुमति नहीं देगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7008 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'नॉन-होस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, 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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, lto इंडेक्सिंग कमांड लाइन के लिए C++ लिंक ऐक्शन कमांड लाइन का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_cpu_and_compiler_attributes_from_cc_toolchain डिफ़ॉल्ट: "सही"

अगर यह सही है, तो cc_toolchain.cpu और cc_toolchain.compiler एट्रिब्यूट सेट होने पर, Bazel शिकायत करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7075 देखें.
टैग: loading_and_analysis, 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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel को cc_common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 पर जाएं.
टैग: loading_and_analysis, 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

--platforms=<a build target label> डिफ़ॉल्ट: ""

मौजूदा निर्देश के लिए टारगेट किए गए प्लैटफ़ॉर्म के बारे में बताने वाले, प्लैटफ़ॉर्म के नियमों के लेबल.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--python2_path=<a string> डिफ़ॉल्ट: जानकारी देखें

अब काम नहीं करता. `--incompatible_use_python_toolchains` से बंद कर दिया गया है.
टैग: no_op, deprecated

--python3_path=<a string> डिफ़ॉल्ट: जानकारी देखें

अब काम नहीं करता. `--incompatible_use_python_toolchains` से बंद कर दिया गया है.
टैग: no_op, deprecated

--python_path=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs

--python_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर को दिखाता है. अब काम नहीं करता; --incompatible_use_python_toolchains की वजह से बंद है.
टैग: loading_and_analysis, affects_outputs

--target_platform_fallback=<a build target label> डिफ़ॉल्ट: "@local_config_platform//:host"

किसी प्लैटफ़ॉर्म के नियम का लेबल. इसका इस्तेमाल तब किया जाना चाहिए, जब कोई टारगेट प्लैटफ़ॉर्म सेट न किया गया हो और कोई भी प्लैटफ़ॉर्म मैपिंग, फ़्लैग के मौजूदा सेट से मैच न करती हो.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट tvOS SDK टूल के वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: जानकारी देखें

अगर यह एट्रिब्यूट तय किया गया है, तो काम की बिल्ड ऐक्शन के लिए, दिए गए वर्शन के Xcode का इस्तेमाल किया जाता है. अगर यह जानकारी नहीं दी गई है, तो Xcode के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"

xcode_config नियम का लेबल, जिसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]apple_enable_auto_dsym_dbg डिफ़ॉल्ट: "गलत"

डीबग बिल्ड के लिए, डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करने की सुविधा को ज़बरदस्ती चालू करना है या नहीं.
टैग: affects_outputs, action_command_lines

--[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 list of options> डिफ़ॉल्ट: ".pb.h"

cc_proto_library से बनने वाली हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated list 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> डिफ़ॉल्ट: "no"

यह बताता है कि 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/repo के अलावा, .runfiles/wsname/external/repo में बाहरी रिपॉज़िटरी के लिए, runfiles के सिर्फ़ लिंक वाले फ़ॉरेस्ट बनाएं.
टैग: 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 पेयर से तय किया जा सकता है. नाम से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. वहीं, 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 के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "गलत"

3.4.0 आर्ग्युमेंट के साथ Android databinding v2 का इस्तेमाल करना
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद"

यह तय करता है कि जब cc_binary साफ़ तौर पर कोई शेयर की गई लाइब्रेरी न बनाए, तो Android नियमों के C++ डिपेंडेंसी डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "alphabetical"

Android बाइनरी के लिए, मेनिफ़ेस्ट मर्ज करने वाले टूल को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अंग्रेज़ी वर्णमाला के क्रम में का मतलब है कि मेनिफ़ेस्ट, execroot के हिसाब से पाथ के हिसाब से क्रम में लगाए जाते हैं. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--apple_bitcode=<'mode' or 'platform=mode', where 'mode' is none, embedded_markers or embedded, and 'platform' is ios, visionos, watchos, tvos, macos or catalyst> एक से ज़्यादा बार इस्तेमाल किए जाने पर

डिवाइस आर्किटेक्चर को टारगेट करने वाले कंपाइल करने के चरणों के लिए, Apple का बिटकोड मोड तय करें. वैल्यू, '[platform=]mode' फ़ॉर्मैट में होती हैं. इसमें प्लैटफ़ॉर्म (जो 'ios', 'macos', 'tvos' या 'watchos' होना चाहिए) की वैल्यू देना ज़रूरी नहीं है. अगर यह एट्रिब्यूट दिया गया है, तो बिटकोड मोड खास तौर पर उस प्लैटफ़ॉर्म के लिए लागू होता है. अगर इसे नहीं दिया गया है, तो यह सभी प्लैटफ़ॉर्म के लिए लागू होता है. मोड 'none', 'embedded_markers' या 'embedded' होना चाहिए. यह विकल्प कई बार दिया जा सकता है.
टैग: loses_incremental_state

--[no]build_python_zip डिफ़ॉल्ट: "auto"

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 coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "fastbuild"

बाइनरी को जिस मोड में बनाया जाएगा उसके बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines, explicit_in_output_path

--conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

gcc को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs, explicit_in_output_path

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ नाम बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाले FDO इंस्ट्रूमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाने वाली cs_fdo_profile, जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs

--cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

हर --define विकल्प, किसी बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default"

यह तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "auto"

रनफ़ाइल्स के सिमलिंक ट्री को चालू करें; यह डिफ़ॉल्ट रूप से, Windows और अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में जावा संसाधनों को कंप्रेस करना
टैग: 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 APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: 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

--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत"

अगर यह तय किया गया है, तो collect_code_coverage चालू होने पर, Bazel gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--fat_apk_cpu=<comma-separated list 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 डिफ़ॉल्ट: "गलत"

HWASAN स्प्लिट बनाने हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--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") जनरेट करते हैं. साथ ही, लिंक करने के लिए, PIC वाली पहले से बनी लाइब्रेरी का इस्तेमाल किया जाता है, न कि PIC वाली लाइब्रेरी का. इसके अलावा, लिंक करने पर पोज़िशन-इंडिपेंडेंट एक्सीक्यूटेबल ("-pie") जनरेट होते हैं.
टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट या एक्सीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए, उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. वहीं, name=value पेयर से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से अलग सेट किया जाएगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> डिफ़ॉल्ट: "opt"

बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे, यह बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--host_conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए gcc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--host_cpu=<a string> डिफ़ॉल्ट: ""

होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए gcc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--host_features=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> की वैल्यू सबमिट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक सुविधाएं, हमेशा सकारात्मक सुविधाओं की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

होस्ट कॉन्फ़िगरेशन के लिए, Python के वर्शन को बदल देता है. यह "PY2" या "PY3" हो सकता है.
टैग: loading_and_analysis, affects_outputs

--host_linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट या exec कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, 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, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--host_swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

होस्ट टूल के लिए, swiftc को पास करने के अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--[no]incompatible_avoid_conflict_dlls डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Windows पर cc_library से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (DLLs) का नाम बदलकर name_{hash}.dll कर दिया जाएगा. यहां हैश का हिसाब, RepositoryName और DLL के पैकेज पाथ के आधार पर लगाया जाता है. यह विकल्प तब काम आता है, जब आपके पास एक ऐसा पैकेज हो जो एक ही नाम वाली कई cc_library पर निर्भर हो (उदाहरण के लिए, //foo/bar1:utils और //foo/bar2:utils).
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही"

अगर यह सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_use_host_features डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए --features और exec कॉन्फ़िगरेशन के लिए --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change

--[no]incompatible_use_platforms_repo_for_constraints डिफ़ॉल्ट: "सही"

अगर यह 'सही' है, तो @bazel_tools से पाबंदी की सेटिंग हटा दी जाती हैं.
टैग: 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_application बनाने के लिए, कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची. इसका नतीजा एक यूनिवर्सल बाइनरी होता है, जिसमें सभी तय किए गए आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive डिफ़ॉल्ट: "सही"

अब काम नहीं करता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में, linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर, alwayslink=1 का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ बैकएंड चरण (--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

--[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, bar.cc को छोड़कर //foo/ में मौजूद सभी 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. यहां regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. option_1 से option_n, कमांड लाइन के मनमुताबिक विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, bar.o को छोड़कर //foo/ में मौजूद सभी o फ़ाइलों की LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: जानकारी देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. इस फ़्लैग में एक बिल्ड लेबल डाला जा सकता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस होना चाहिए. उदाहरण के लिए, a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",) में मौजूद, लेबल की जानकारी देने वाली BUILD फ़ाइल. इन फ़ाइलों को Bazel को दिखाने के लिए, उससे जुड़े पैकेज में exports_files डायरेक्टिव जोड़ना पड़ सकता है. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, 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" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि --compilation_mode=fastbuild के लिए, स्ट्रिप करें.
टैग: affects_outputs

--stripopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप करने के लिए पास किए जाने वाले अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Swift कंपाइलेशन के लिए पास करने के अन्य विकल्प.
टैग: action_command_lines

--tvos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं. इन आर्किटेक्चर को कॉमा लगाकर अलग किया गया है.
टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, काम करने वाला कम से कम tvOS वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐप्लिकेशन के लिए, Apple visionOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐप्लिकेशन के लिए, Apple watchOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू रहेंगे. ऐसा तब भी होगा, जब xbinary_fdo का इस्तेमाल न किया गया हो.
टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: ""

cpu वैल्यू को target_environment वैल्यू पर अपने-आप मैप करने के लिए, environment_group का इस्तेमाल करें.
टैग: 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_allow_android_library_deps_without_srcs डिफ़ॉल्ट: "गलत"

srcs-less android_library नियमों को, डिपेंडेंसी के साथ इस्तेमाल करने की अनुमति देने से रोकने के लिए फ़्लैग. इसे डिफ़ॉल्ट रूप से रोल आउट करने के लिए, डेपो को खाली करना होगा.
टैग: eagerness_to_exit, loading_and_analysis

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

अगर यह सही है, तो यह जांच की जाती है कि कोई Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो आउटपुट फ़ाइलों के तौर पर इस्तेमाल होने वाले टारगेट के लिए, सिर्फ़ टेस्ट करने की सुविधा देखें. इसके लिए, जनरेट करने वाले नियम के लिए सिर्फ़ टेस्ट करने की सुविधा देखें. यह, 'डिवाइस किसे दिखे' सेटिंग की जांच से मेल खाता है.
टैग: 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_force_strict_header_check_from_starlark डिफ़ॉल्ट: "सही"

अगर चालू है, तो Starlark API में हेडर की सख्त जांच सेट करें
टैग: loading_and_analysis, changes_inputs, incompatible_change

--[no]incompatible_validate_top_level_header_inclusions डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, टॉप लेवल डायरेक्ट्री हेडर में शामिल किए गए एलिमेंट की भी पुष्टि करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]strict_filesets डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइल सेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है. check_fileset_dependencies_recursively बंद होने पर, यह काम नहीं करता.
टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच की जाती है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद"

जब तक यह विकल्प बंद नहीं किया जाता, तब तक यह जांच की जाती है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर एक्सपोर्ट के तौर पर दिखाता है या नहीं.
टैग: 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"

APKs पर साइन करने के लिए इस्तेमाल करने के लिए लागू करना
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements डिफ़ॉल्ट: "सही"

अगर यह सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: जानकारी देखें

iOS साइनिंग के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक, यह सर्टिफ़िकेट की पासकोड वाली पहचान की प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम का (सबस्ट्रिंग) हो सकता है.
टैग: action_command_lines

इस विकल्प से, Starlark भाषा के सेमेंटेक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही"

काम नहीं करता. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के AnalysisFailureInfo के इंस्टेंस का प्रॉपेगेशन होता है. इसमें गड़बड़ी की जानकारी होती है. इससे बिल्ड पूरा न होने की स्थिति नहीं होती.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा को पार करने पर, नियम से जुड़ी गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो dex2oat कार्रवाई के पूरा न होने पर, टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, बिल्ड बंद हो जाएगा.
टैग: loading_and_analysis, experimental

--[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. यहां runs_per_test, पूर्णांक वैल्यू के लिए है और regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैरिएबल की वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.
टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1"

टेस्ट टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर चार पूर्णांकों को कॉमा लगाकर अलग-अलग किया गया है, तो वे कम, सामान्य, ज़्यादा, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों ही फ़ॉर्म में, -1 की वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहा जाता है.

--tvos_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में tvOS ऐप्लिकेशन चलाते समय, सिम्युलेट किया जाने वाला डिवाइस. जैसे, 'Apple TV 1080p'. डिवाइसों की सूची देखने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला tvOS का वर्शन.
टैग: test_runner

--watchos_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में watchOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है. उदाहरण के लिए, 'Apple Watch - 38mm'. डिवाइसों की सूची देखने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--watchos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या उसकी जांच करते समय, सिम्युलेटर पर चलाया जाने वाला watchOS वर्शन.
टैग: test_runner

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही"

अगर यह सही है, तो बिना एलान किए किए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

क्वेरी आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंजर्वेटिव"

अगर आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने की ज़रूरत होती है. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी एस्पेक्ट का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह 'bazel क्वेरी' के दौरान नहीं चलता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, <code>Label</code> इंस्टेंस पर लागू Starlark <code>str</code> फ़ंक्शन की तरह लेबल दिखाता है. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट को ज़्यादा आसानी से पढ़ने लायक बनाने के लिए, आउटपुट फ़ॉर्मैटर, मुख्य रिपॉज़िटरी के हिसाब से, रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल काट दिए जाएंगे; -1 का मतलब है कि लेबल काटा नहीं जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो डिपेंडेंसी ग्राफ़ में, ऐसी डिपेंडेंसी शामिल होंगी जिन पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]incompatible_display_source_file_location डिफ़ॉल्ट: "सही"

डिफ़ॉल्ट रूप से True, सोर्स फ़ाइल का टारगेट दिखाता है. अगर यह सही है, तो जगह की जानकारी वाले आउटपुट में, सोर्स फ़ाइलों की पहली लाइन की जगह दिखती है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए है.
टैग: 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 की वैल्यू सेट नहीं है, तो --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" एट्रिब्यूट से जुड़ी डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics

--output=<a string> डिफ़ॉल्ट: "लेबल"

वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_kind, textproto, transitions, proto, jsonproto. 'ट्रांज़िशन' चुनने पर, आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह फ़ील्ड, नियम के इंस्टेंस के लिए Starlark कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की गई थी.
टैग: terminal_output

--[no]proto:flatten_selects डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची के टाइप के लिए, फ़्लैट किया गया रिप्रज़ेंटेशन एक सूची होती है, जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप को शून्य पर फ़्लैट कर दिया जाता है.
टैग: build_file_semantics

--[no]proto:include_configurations डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो प्रोटो आउटपुट में कॉन्फ़िगरेशन की जानकारी शामिल होगी. बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत"

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत"

हर नियम के इंस्टैंशिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output

--[no]proto:locations डिफ़ॉल्ट: "सही"

क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है या नहीं.
टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "all"

आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा से अलग की गई सूची. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: 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 के --output=starlark मोड में, कॉन्फ़िगर किए गए हर टारगेट को फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट, 'target' से बंधा होता है. अगर --starlark:expr और --starlark:file, दोनों में से किसी का भी इस्तेमाल नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट हो जाएगा. --starlark:expr और --starlark:file, दोनों को इस्तेमाल करना गड़बड़ी है.
टैग: terminal_output

--starlark:file=<a string> डिफ़ॉल्ट: ""

इस फ़ाइल में, एक आर्ग्युमेंट वाला 'format' नाम का Starlark फ़ंक्शन तय किया गया है. यह फ़ंक्शन, कॉन्फ़िगर किए गए हर टारगेट को स्ट्रिंग के तौर पर फ़ॉर्मैट करने के लिए लागू किया जाता है. --starlark:expr और --starlark:file, दोनों को इस्तेमाल करना गड़बड़ी है. ज़्यादा जानकारी के लिए, --output=starlark के लिए सहायता देखें.
टैग: terminal_output

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: अगर यह विकल्प बंद है, तो 'होस्ट कॉन्फ़िगरेशन' या 'एक्सीक्यूशन' टारगेट पर निर्भरता, उस डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए सभी टारगेट को फ़िल्टर कर दिया जाता है. ये ऐसे टारगेट होते हैं जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, होस्ट या एक्सीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics

--transitions=<full, lite or none> डिफ़ॉल्ट: "none"

वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगी.
टैग: affects_outputs

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न (जोड़ने और घटाने वाले) का कॉमा लगाकर बनाया गया सेट. क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प में इनपुट के तौर पर वे टारगेट डाले जाते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, इस विकल्प का असर कॉन्फ़िगरेशन और ट्रांज़िशन पर पड़ सकता है. अगर यह विकल्प नहीं दिया गया है, तो क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट को टॉप-लेवल टारगेट माना जाता है. ध्यान दें: cquery के लिए, इस विकल्प को न बताने पर, हो सकता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल विकल्पों के साथ बिल्ड न हो पाएं.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]collapse_duplicate_defines डिफ़ॉल्ट: "गलत"

चालू होने पर, बिल्ड में पहले से मौजूद --defines को हटा दिया जाएगा. इससे, मिलते-जुलते कुछ खास तरह के बिल्ड के लिए, विश्लेषण कैश मेमोरी को बेवजह नहीं मिटाया जाता.
टैग: loading_and_analysis, loses_incremental_state

--[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_objc_include_scanning डिफ़ॉल्ट: "गलत"

क्या C/C++ के लिए स्कैनिंग शामिल की जानी चाहिए.
टैग: loading_and_analysis, execution, changes_inputs

--[no]experimental_parse_headers_skipped_if_corresponding_srcs_found डिफ़ॉल्ट: "गलत"

अगर parse_headers सुविधा चालू है, तो एक ही टारगेट में एक ही बेसनेम वाला सोर्स मिलने पर, यह सुविधा अलग हेडर कंपाइल ऐक्शन नहीं बनाती.
टैग: loading_and_analysis, affects_outputs

--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत"

चालू होने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, cc_test नियमों पर निर्भर न करने वाले नियमों के लिए, कार्रवाई से जुड़ी समस्याओं को कम करना है. अगर --trim_test_configuration को 'गलत है' पर सेट किया जाता है, तो इसका कोई असर नहीं पड़ता.
टैग: 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 डिफ़ॉल्ट: "सही"

यह हर Jar फ़ाइल के लिए, इंडेक्स करने का ज़्यादातर काम अलग से करता है.
टैग: 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

--[no]use_singlejar_apkbuilder डिफ़ॉल्ट: "सही"

इस विकल्प का इस्तेमाल नहीं किया जा सकता. अब यह सुविधा काम नहीं करती और इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान, डीबग की जानकारी प्रिंट करें. इस फ़्लैग में रेगुलर एक्सप्रेशन का इस्तेमाल किया जाता है. इस एक्सप्रेशन की जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता लगाया जा सके कि किस टूल को डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. ऐसा हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए ही काम का हो.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत"

यह फ़्लैग, डिफ़ॉल्ट तरीके को बदल देता है, ताकि Python टारगेट के रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बनें. खास तौर पर, जब py_binary या py_test टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिंबललिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, `--incompatible_py3_is_default` को भी चालू करने का सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से PY3 का इस्तेमाल किया जाएगा, न कि PY2 का. अगर यह फ़्लैग सेट किया जाता है, तो हमारा सुझाव है कि आप `--incompatible_py2_outputs_are_suffixed` को भी सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python टूलचेन से तय किए गए Python रनटाइम का इस्तेमाल किया जाएगा. ऐसा --python_top जैसे लेगसी फ़्लैग से दिए गए रनटाइम के बजाय किया जाएगा.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

Python के मुख्य वर्शन का मोड, या तो `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट बदल देते हैं. भले ही, वे साफ़ तौर पर किसी वर्शन की जानकारी न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs, explicit_in_output_path

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "auto"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो 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 डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो clang के लिए कवरेज से 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 डिफ़ॉल्ट: "गलत"

--experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java लॉन्चर, उन टूल का इस्तेमाल करता है जो किसी बिल्ड के दौरान चलाए जाते हैं.

--host_javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, javac को पास करने के लिए अन्य विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "गलत"

अगर यह 'सही' है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. एक्सक्लूज़िव टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: 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_output=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 डिफ़ॉल्ट: "सही"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: "8"

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--legacy_main_dex_list_generator=<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++ प्रोटो कोड को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जिसमें Java प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जो JavaLite प्रोटो को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

protobuf कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो जिस शर्ड में कम से कम एक रन/अटैंप पास होता है और कम से कम एक रन/अटैंप फ़ेल होता है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: जानकारी देखें

Bazel के इस्तेमाल के लिए, शेल की एक्ज़ीक्यूटेबल फ़ाइल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन Bazel को पहली बार इस्तेमाल करने पर BAZEL_SH एनवायरमेंट वैरिएबल सेट है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel काम करता है. जैसे, Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने पर, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में गड़बड़ियां हो सकती हैं.
टैग: loading_and_analysis

--test_arg=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--test_filter=<a string> डिफ़ॉल्ट: जानकारी देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, चलाए जाने वाले टेस्ट की संख्या को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे यह तय नहीं होता कि कौनसे टारगेट बनाए जाएं.

--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1"

इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत"

टेस्ट रनर को फ़ेल फ़ास्ट विकल्प फ़ॉरवर्ड करता है. टेस्ट रनर को पहली बार फ़ेल होने पर, टेस्ट को रोक देना चाहिए.

--test_sharding_strategy=<explicit or disabled> डिफ़ॉल्ट: "explicit"

टेस्ट के लिए, शार्ड करने की रणनीति तय करें: 'explicit', ताकि सिर्फ़ तब शार्डिंग का इस्तेमाल किया जा सके, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'बंद है', ताकि टेस्ट के लिए डेटा को अलग-अलग हिस्सों में बांटने की सुविधा का कभी भी इस्तेमाल न किया जाए.

--tool_java_language_version=<a string> डिफ़ॉल्ट: "8"

Java भाषा का वह वर्शन जिसका इस्तेमाल, बिल्ड के दौरान ज़रूरी टूल चलाने के लिए किया जाता है

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन इंटरफ़ेस के लिए jar का इस्तेमाल करता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]action_cache डिफ़ॉल्ट: "गलत"

कार्रवाई की कैश मेमोरी में सेव कॉन्टेंट को डंप करें.
टैग: bazel_monitoring

--[no]packages डिफ़ॉल्ट: "गलत"

पैकेज की कैश मेमोरी में सेव कॉन्टेंट को डंप करें.
टैग: bazel_monitoring

--[no]rule_classes डिफ़ॉल्ट: "गलत"

नियम की क्लास को डंप करें.
टैग: bazel_monitoring

--[no]rules डिफ़ॉल्ट: "गलत"

डंप के नियम, जिनमें गिनती और मेमोरी के इस्तेमाल की जानकारी शामिल है (अगर मेमोरी को ट्रैक किया जाता है).
टैग: bazel_monitoring

--skyframe=<off, summary, count, deps or rdeps> डिफ़ॉल्ट: "बंद"

Skyframe ग्राफ़ को डंप करें: 'off', 'summary', 'count', 'deps' या 'rdeps'.
टैग: bazel_monitoring

--skykey_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: ".*"

आउटपुट के लिए, SkyKey के नामों का रेगुलर एक्सप्रेशन फ़िल्टर. इसका इस्तेमाल सिर्फ़ --skyframe=deps, rdeps के साथ किया जाता है.
टैग: bazel_monitoring

--skylark_memory=<a string> डिफ़ॉल्ट: जानकारी देखें

यह, दिए गए पाथ में pprof के साथ काम करने वाली मेमोरी प्रोफ़ाइल को डंप करता है. ज़्यादा जानने के लिए, कृपया https://github.com/google/pprof पर जाएं.
टैग: bazel_monitoring

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]incompatible_remote_dangling_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है और --incompatible_remote_symlinks भी 'सही' पर सेट होता है, तो ऐक्शन आउटपुट में मौजूद सिंकलिंक को लटकने की अनुमति होती है.
टैग: execution, incompatible_change

--[no]incompatible_remote_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैश मेमोरी/कार्रवाई के आउटपुट में सिमलिंक को इस तरह दिखाएगा. ऐसा न करने पर, लिंक किए गए फ़ोल्डर को फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए, #6631 देखें.
टैग: execution, incompatible_change

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1"

बीईपी आर्टफ़ैक्ट अपलोड करने के दौरान, ज़्यादा से ज़्यादा कितनी फ़ाइलें खोली जा सकती हैं.
टैग: affects_outputs

--remote_download_minimal

स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=minimal.
इस तरह बड़ा होता है:
  --nobuild_runfile_links
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=minimal

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> डिफ़ॉल्ट: "all"

अगर इसे 'कम से कम' पर सेट किया जाता है, तो स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होता. हालांकि, स्थानीय कार्रवाइयों के लिए ज़रूरी आउटपुट डाउनलोड किए जाते हैं. 'toplevel' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह लोकल मशीन पर टॉप लेवल टारगेट के आउटपुट भी डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की समस्या है, तो दोनों विकल्पों से बिल्ड करने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs

--remote_download_symlink_template=<a string> डिफ़ॉल्ट: ""

रिमोट बिल्ड आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबल लिंक बनाएं. सिंबल लिंक का टारगेट, टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये क्रमशः ऑब्जेक्ट के हैश और बाइट में साइज़ में बदल जाते हैं. उदाहरण के लिए, ये सिंबल लिंक किसी ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर सीएएस से ऑब्जेक्ट लोड करता है.
टैग: affects_outputs

--remote_download_toplevel

सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट को लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=toplevel.
इस तरह बड़ा होता है:
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=toplevel

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की गई
टैग: no_op, deprecated, experimental

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: 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

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

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

--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "failure"

चुनें कि रिमोट से चलाए गए निर्देशों के मैसेज कब प्रिंट किए जाएं. मान्य वैल्यू: सिर्फ़ गड़बड़ियों पर प्रिंट करने के लिए `failure`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए `success`, और हमेशा प्रिंट करने के लिए `all`.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें

सर्किट ब्रेकर के इस्तेमाल के लिए रणनीति तय करता है. उपलब्ध रणनीतियां "फ़ेल्योर" हैं. विकल्प के लिए अमान्य वैल्यू देने पर, विकल्प के लिए सेट किया गया व्यवहार नहीं दिखता.
टैग: execution

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत"

किसी ऐक्शन की इनपुट फ़ाइलों को रिमोट कैश मेमोरी में अपलोड करने से पहले, उनकी ctime की जांच करने की सुविधा बंद करने के लिए, इसे बंद करें. कुछ मामलों में, Linux kernel फ़ाइलों को लिखने में देरी कर सकता है. इस वजह से, गलत नतीजे मिल सकते हैं.

--experimental_remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "all"

अगर इसे 'सभी' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड हो जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते.हालांकि, BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों (जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल) को अपलोड किया जाता है. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का हमेशा इस्तेमाल किया जाता है. भले ही, वे रिमोट कैश मेमोरी में मौजूद न हों. डिफ़ॉल्ट रूप से 'सभी' पर सेट होता है.

--[no]experimental_remote_cache_async डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो स्पॉन के हिस्से के तौर पर होने के बजाय, रिमोट कैश मेमोरी का I/O बैकग्राउंड में होगा.

--[no]experimental_remote_cache_compression डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो zstd की मदद से कैश मेमोरी ब्लॉब को कंप्रेस/डिकंप्रेस करें.

--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.

--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "गलत"

अगर इसे 'सही' पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़ी इनपुट मैपिंग की मेमोरी में मौजूद कॉपी को हटा दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में डेटा न मिलने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कैलकुलेट करना पड़ता है.

--experimental_remote_downloader=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट एसेट एपीआई एंडपॉइंट का यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाएगा. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

--[no]experimental_remote_downloader_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.

--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "गलत"

रिमोट तरीके से प्रोसेस करने के लिए, 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.> डिफ़ॉल्ट: "60s"

वह इंटरवल जिसमें रिमोट अनुरोधों के पूरा न होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, गड़बड़ी की अवधि को पूरे एक्सीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution

--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, इनपुट को रिमोट एक्सीक्यूटर के लिए टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर लगातार काम करने वाले वर्कर लागू करने के लिए किया जा सकता है.

--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेर्कल ट्री कैलकुलेशन को मेमोइज़ किया जाएगा. कैश मेमोरी का फ़ुटप्रिंट, --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.

--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000"

रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेमोज़ करने वाले मेर्कल ट्री की संख्या. भले ही, सॉफ़्ट रेफ़रंस को मैनेज करने के लिए Java, कैश मेमोरी को अपने-आप कम करता है, लेकिन बहुत ज़्यादा सेट करने पर, मेमोरी खत्म होने की गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड हो जाता है. प्रोजेक्ट के साइज़ के हिसाब से, ऑप्टिमम वैल्यू अलग-अलग होती है. डिफ़ॉल्ट रूप से 1,000 पर सेट होती है.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो यह पक्का करें कि दूर से चलने वाली सभी कार्रवाइयां कैश मेमोरी में सेव हों. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह सुविधा, नॉन-डिटरमिनिस्टिक समस्याओं को हल करने में मदद करती है. इससे यह जांच की जा सकती है कि कैश मेमोरी में सेव की जानी वाली कार्रवाइयां, असल में कैश मेमोरी में सेव की गई हैं या नहीं. ऐसा करने के लिए, कैश मेमोरी में नए नतीजे इंजेक्ट नहीं किए जाते.

--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो BEP से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तौर पर कैश मेमोरी में कैश नहीं किया जा सकता.

--[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 डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो --noremote_upload_local_results और --noremote_accept_cached, डिस्क कैश मेमोरी पर लागू नहीं होंगे. अगर किसी कॉम्बाइन कैश का इस्तेमाल किया जाता है, तो: --noremote_upload_local_results से, नतीजे डिस्क कैश में सेव हो जाएंगे, लेकिन रिमोट कैश में अपलोड नहीं होंगे. --noremote_accept_cached का इस्तेमाल करने पर, Bazel डिस्क कैश मेमोरी में नतीजों की जांच करेगा, लेकिन रिमोट कैश मेमोरी में नहीं. no-remote-exec कार्रवाइयों से डिस्क कैश पर असर पड़ सकता है. ज़्यादा जानकारी के लिए, #8216 देखें.
टैग: incompatible_change

--[no]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो अगर बिल्ड के दौरान रिमोट कैश मेमोरी, ब्लॉब को हटाती है, तो Bazel 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगी.
टैग: incompatible_change

--[no]remote_accept_cached डिफ़ॉल्ट: "सही"

क्या कार्रवाई के रिमोट कैश मेमोरी में सेव किए गए नतीजों को स्वीकार करना है.

--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट स्ट्रीम में लिखे गए bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम. यह विकल्प तब सेट किया जा सकता है, जब किसी प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इसकी वजह से, --remote_executor और --remote_instance_name की वैल्यू, रिमोट इकसेक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. सेट न होने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.

--remote_cache=<a string> डिफ़ॉल्ट: जानकारी देखें

कैश मेमोरी में डेटा सेव करने वाले एंडपॉइंट का यूआरआई. इन स्कीम का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा की जानकारी दें. https://bazel.build/remote/caching पर जाएं

--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_properties सेट नहीं है, तो रिमोट एक्सीक्यूशन एपीआई के लिए सेट की जाने वाली डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. अगर होस्ट प्लैटफ़ॉर्म को रिमोट तौर पर चलाने के लिए, एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल भी किया जाएगा.

--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 या HOST:PORT. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा की वैल्यू दें.

--remote_grpc_log=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर यह पैरामीटर दिया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए, फ़ाइल का पाथ. इस लॉग में, सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry protobufs का क्रम होता है. हर मैसेज के आगे एक वैरिएंट होता है, जो सीरियलाइज़ किए गए अगले protobuf मैसेज का साइज़ दिखाता है. यह साइज़, LogEntry.writeDelimitedTo(OutputStream) तरीके से दिखाया जाता है.

--remote_header=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसा हेडर डालें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. एक से ज़्यादा हेडर पास करने के लिए, फ़्लैग को कई बार डालें. एक ही नाम के लिए एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.

--remote_instance_name=<a string> डिफ़ॉल्ट: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट तरीके से लागू करने की प्रोसेस पूरी न होने पर, स्टैंडअलोन लोकल तरीके से लागू करने की रणनीति का इस्तेमाल करना है या नहीं.

--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "local"

काम नहीं करता, अब इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

--remote_max_connections=<an integer> डिफ़ॉल्ट: "100"

रिमोट कैश मेमोरी/एग्ज़ीक्यूटर पर एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, यह तय करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एग्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को मैनेज कर सकता है. इसलिए, Bazel एक साथ `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations

--remote_proxy=<a string> डिफ़ॉल्ट: जानकारी देखें

प्रॉक्सी के ज़रिए रिमोट कैश मेमोरी से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.

--remote_result_cache_priority=<an integer> डिफ़ॉल्ट: "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.> डिफ़ॉल्ट: "60s"

रिमोट तरीके से एक्सीक्यूशन और कैश मेमोरी कॉल के लिए इंतज़ार करने की ज़्यादा से ज़्यादा समयावधि. REST कैश मेमोरी के लिए, यह कनेक्ट और पढ़ने के लिए टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--[no]remote_upload_local_results डिफ़ॉल्ट: "सही"

अगर रिमोट कैश मेमोरी में कार्रवाई के नतीजे अपलोड किए जा सकते हैं और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या लोकल तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.

--[no]remote_verify_downloads डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो Bazel सभी रिमोट डाउनलोड के हैश का कुल हिसाब लगाएगा. साथ ही, अगर रिमोट से कैश मेमोरी में सेव की गई वैल्यू, उम्मीद के मुताबिक नहीं होती हैं, तो उन्हें खारिज कर देगा.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.> एक से ज़्यादा बार इस्तेमाल किए जाने पर

रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी में सेव करने, और उसे लागू करने के साथ-साथ, इवेंट की बिल्ड सेवा के लिए अनुमति के क्रेडेंशियल पाने के लिए, क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है. किसी हेल्पर से मिले क्रेडेंशियल, --google_default_credentials, --google_credentials, .netrc फ़ाइल या repository_ctx.download और repository_ctx.download_and_extract के auth पैरामीटर से मिले क्रेडेंशियल से ज़्यादा प्राथमिकता पाते हैं. एक से ज़्यादा हेल्पर सेट अप करने के लिए, कई बार इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-credential-helpers.md देखें.

--credential_helper_cache_duration=<An immutable length of time.> डिफ़ॉल्ट: "30 मीटर"

क्रेडेंशियल हेल्पर से मिले क्रेडेंशियल को कैश मेमोरी में सेव रखने की अवधि. किसी दूसरी वैल्यू के साथ कॉल करने पर, पहले से मौजूद एंट्री के लाइफ़टाइम में बदलाव होगा. कैश मेमोरी मिटाने के लिए, शून्य पास करें. इस फ़्लैग के बावजूद, क्लीन कमांड हमेशा कैश मेमोरी मिटाता है.

--credential_helper_timeout=<An immutable length of time.> डिफ़ॉल्ट: "10s"

क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. अगर क्रेडेंशियल हेल्पर इस टाइम आउट के अंदर जवाब नहीं देते हैं, तो अनुरोध पूरा नहीं होगा.

--deleted_packages=<comma-separated list of package names> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो हो सकता है कि वह शिकायत करे. ऐसा तब होगा, जब वह लेबल किसी अन्य package_path एंट्री से उपलब्ध कराया गया हो. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--disk_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.

--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.> डिफ़ॉल्ट: "20s"

आउटगोइंग gRPC कनेक्शन के लिए, 'कनेक्शन बनाए रखने की सुविधा' का टाइम आउट कॉन्फ़िगर करता है. अगर --grpc_keepalive_time के साथ, 'किंग-ऐलिव' पिंग चालू किए जाते हैं, तो Bazel इस समयावधि के बाद पिंग का जवाब न मिलने पर, कनेक्शन को टाइम आउट कर देता है. समय को सेकंड के हिसाब से ज़्यादा सटीक माना जाता है. एक सेकंड से कम की वैल्यू सेट करने पर गड़बड़ी का मैसेज दिखता है. अगर 'किंग-ऐलिव' पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--tls_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

उस TLS सर्टिफ़िकेट का पाथ डालें जिस पर सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.

--tls_client_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट की जानकारी दें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट पासकोड भी देना होगा.

--tls_client_key=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट पासकोड डालें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--help_verbosity=<long, medium or short> डिफ़ॉल्ट: "medium"

सहायता कमांड के लिए, ज़्यादा जानकारी देने का विकल्प चुनें.
टैग: affects_outputs, terminal_output

--long [-l]

हर विकल्प के नाम के बजाय, उसका पूरा ब्यौरा दिखाएं.
इस तरह बड़ा होता है:
  --help_verbosity=long

टैग: affects_outputs, terminal_output

--short

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

टैग: affects_outputs, terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. ये विकल्प, अन्य कैटगरी में नहीं आते.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--[no]show_make_env डिफ़ॉल्ट: "गलत"

आउटपुट में "Make" एनवायरमेंट शामिल करें.
टैग: affects_outputs, terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--mode=<classic, classic_internal_test_do_not_use or skylark> डिफ़ॉल्ट: "क्लासिक"

mobile-install को चलाने का तरीका चुनें. "classic", mobile-install का मौजूदा वर्शन चलाता है. "skylark", Starlark के नए वर्शन का इस्तेमाल करता है. इसमें android_test की सुविधा काम करती है.
टैग: loading_and_analysis, execution, incompatible_change

ऐक्शन लागू करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--adb=<a string> डिफ़ॉल्ट: ""

'mobile-install' कमांड के लिए इस्तेमाल किया जाने वाला adb बाइनरी. अगर कोई वैल्यू नहीं दी गई है, तो --android_sdk कमांड लाइन विकल्प से तय किए गए Android SDK टूल का इस्तेमाल किया जाता है. अगर --android_sdk का इस्तेमाल नहीं किया गया है, तो डिफ़ॉल्ट 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

ऐसे विकल्प जिनसे इस बात पर असर पड़ता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--incremental_install_verbosity=<a string> डिफ़ॉल्ट: ""

इंक्रीमेंटल इंस्टॉल के लिए ज़्यादा जानकारी. डीबग लॉगिंग के लिए, इस वैल्यू को 1 पर सेट करें.
टैग: bazel_monitoring

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

मोड के विकल्प

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

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

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की गई
टैग: no_op, deprecated, experimental

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: 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

`mod` सब-कमांड के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--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, सीधे डिपेंडेंसी दिखाता है. tree, path, और all_paths के लिए, यह डिफ़ॉल्ट रूप से Integer.MAX_VALUE पर सेट होता है. वहीं, deps और explain के लिए, यह डिफ़ॉल्ट रूप से 1 पर सेट होता है. यह सिर्फ़ टारगेट लीफ़ और उनके पैरंट के अलावा, रूट के डायरेक्ट डिपेंडेंसी दिखाता है.
टैग: terminal_output

--extension_filter=<a comma-separated list of <extension>s> डिफ़ॉल्ट: जानकारी देखें

सिर्फ़ तब इन मॉड्यूल एक्सटेंशन और उनके जनरेट किए गए रिपॉज़िटरी के इस्तेमाल को दिखाएं, जब उनके फ़्लैग सेट हों. अगर यह सेट है, तो नतीजों के ग्राफ़ में सिर्फ़ वे पाथ शामिल होंगे जिनमें बताए गए एक्सटेंशन का इस्तेमाल करने वाले मॉड्यूल शामिल हैं. खाली सूची, फ़िल्टर को बंद कर देती है. साथ ही, सभी संभावित एक्सटेंशन को असरदार तरीके से बताती है.
टैग: terminal_output

--extension_info=<hidden, usages, repos or all> डिफ़ॉल्ट: "hidden"

बताएं कि क्वेरी के नतीजे में, एक्सटेंशन के इस्तेमाल के बारे में कितनी जानकारी शामिल करनी है. "इस्तेमाल" में सिर्फ़ एक्सटेंशन के नाम दिखेंगे. "रिपॉज़िटरी" में, use_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 कमांड में नए पाथ शामिल करना या explain कमांड में अतिरिक्त डिपेंडेंट शामिल करना.
टैग: terminal_output

--output=<text, json or graph> डिफ़ॉल्ट: "text"

क्वेरी के नतीजों को जिस फ़ॉर्मैट में प्रिंट करना है. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: टेक्स्ट, जेएसओएन, ग्राफ़
टैग: terminal_output

--[no]verbose डिफ़ॉल्ट: "गलत"

क्वेरी में यह भी दिखेगा कि मॉड्यूल को उनके मौजूदा वर्शन में क्यों बदला गया (अगर बदला गया है). यह सिर्फ़ 'एक्सप्लेन क्वेरी' के लिए डिफ़ॉल्ट रूप से 'सही' पर सेट होता है.
टैग: terminal_output

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--deleted_packages=<comma-separated list of package names> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो हो सकता है कि वह शिकायत करे. ऐसा तब होगा, जब वह लेबल किसी अन्य package_path एंट्री से उपलब्ध कराया गया हो. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

Print_action के विकल्प

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--print_action_mnemonics=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इसमें उन मेमोनिम की सूची होती है जिनके हिसाब से print_action डेटा को फ़िल्टर किया जाता है. खाली छोड़ने पर, कोई फ़िल्टर नहीं किया जाता.

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]incompatible_remote_dangling_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है और --incompatible_remote_symlinks भी 'सही' पर सेट होता है, तो ऐक्शन आउटपुट में मौजूद सिंकलिंक को लटकने की अनुमति होती है.
टैग: execution, incompatible_change

--[no]incompatible_remote_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैश मेमोरी/कार्रवाई के आउटपुट में सिमलिंक को इस तरह दिखाएगा. ऐसा न करने पर, लिंक किए गए फ़ोल्डर को फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए, #6631 देखें.
टैग: execution, incompatible_change

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1"

बीईपी आर्टफ़ैक्ट अपलोड करने के दौरान, ज़्यादा से ज़्यादा कितनी फ़ाइलें खोली जा सकती हैं.
टैग: affects_outputs

--remote_download_minimal

स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=minimal.
इस तरह बड़ा होता है:
  --nobuild_runfile_links
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=minimal

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> डिफ़ॉल्ट: "all"

अगर इसे 'कम से कम' पर सेट किया जाता है, तो स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होता. हालांकि, स्थानीय कार्रवाइयों के लिए ज़रूरी आउटपुट डाउनलोड किए जाते हैं. 'toplevel' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह लोकल मशीन पर टॉप लेवल टारगेट के आउटपुट भी डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की समस्या है, तो दोनों विकल्पों से बिल्ड करने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs

--remote_download_symlink_template=<a string> डिफ़ॉल्ट: ""

रिमोट बिल्ड आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबल लिंक बनाएं. सिंबल लिंक का टारगेट, टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये क्रमशः ऑब्जेक्ट के हैश और बाइट में साइज़ में बदल जाते हैं. उदाहरण के लिए, ये सिंबल लिंक किसी ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर सीएएस से ऑब्जेक्ट लोड करता है.
टैग: affects_outputs

--remote_download_toplevel

सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट को लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=toplevel.
इस तरह बड़ा होता है:
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=toplevel

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की गई
टैग: no_op, deprecated, experimental

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: 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

क्वेरी के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंजर्वेटिव"

अगर आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने की ज़रूरत होती है. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी एस्पेक्ट का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह 'bazel क्वेरी' के दौरान नहीं चलता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, <code>Label</code> इंस्टेंस पर लागू Starlark <code>str</code> फ़ंक्शन की तरह लेबल दिखाता है. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट को ज़्यादा आसानी से पढ़ने लायक बनाने के लिए, आउटपुट फ़ॉर्मैटर, मुख्य रिपॉज़िटरी के हिसाब से, रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output

--[no]experimental_graphless_query डिफ़ॉल्ट: "auto"

अगर यह सही है, तो क्वेरी लागू करने के लिए उस तरीके का इस्तेमाल किया जाता है जो ग्राफ़ की कॉपी नहीं बनाता. नए तरीके में, सिर्फ़ --order_output=no और आउटपुट फ़ॉर्मैटर के सबसेट का इस्तेमाल किया जा सकता है.
टैग: build_file_semantics, eagerness_to_exit

--graph:conditional_edges_limit=<an integer> डिफ़ॉल्ट: "4"

शर्त वाले लेबल की ज़्यादा से ज़्यादा संख्या. -1 का मतलब है कि टेक्स्ट को छोटा नहीं किया गया है और 0 का मतलब है कि एनोटेशन नहीं है. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल काट दिए जाएंगे; -1 का मतलब है कि लेबल काटा नहीं जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो डिपेंडेंसी ग्राफ़ में, ऐसी डिपेंडेंसी शामिल होंगी जिन पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]incompatible_display_source_file_location डिफ़ॉल्ट: "सही"

डिफ़ॉल्ट रूप से True, सोर्स फ़ाइल का टारगेट दिखाता है. अगर यह सही है, तो जगह की जानकारी वाले आउटपुट में, सोर्स फ़ाइलों की पहली लाइन की जगह दिखती है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग: terminal_output, incompatible_change

--[no]incompatible_lexicographical_output डिफ़ॉल्ट: "सही"

अगर यह विकल्प सेट है, तो --order_output=auto आउटपुट को वर्णमाला के क्रम में क्रम से लगाया जाता है.
टैग: 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 की वैल्यू सेट नहीं है, तो --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" एट्रिब्यूट से जुड़ी डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics

--noorder_results

नतीजों को डिफ़ॉल्ट रूप से, डिपेंडेंसी के क्रम में या बिना किसी क्रम के दिखाएं. बिना क्रम के आउटपुट की सुविधा तेज़ी से काम करती है. हालांकि, यह सिर्फ़ तब काम करती है, जब --output में minrank, maxrank या graph न हो.
इस तरह बड़ा होता है:
  --order_output=no

टैग: terminal_output

--null

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

टैग: terminal_output

--order_output=<no, deps, auto or full> डिफ़ॉल्ट: "auto"

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

--order_results

नतीजों को डिफ़ॉल्ट रूप से, डिपेंडेंसी के क्रम में या बिना किसी क्रम के दिखाएं. बिना क्रम के आउटपुट की सुविधा तेज़ी से काम करती है. हालांकि, यह सिर्फ़ तब काम करती है, जब --output में minrank, maxrank या graph न हो.
इस तरह बड़ा होता है:
  --order_output=auto

टैग: terminal_output

--output=<a string> डिफ़ॉल्ट: "लेबल"

क्वेरी के नतीजों को जिस फ़ॉर्मैट में प्रिंट करना है. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: build, graph, streamed_jsonproto, label, label_kind, location, maxrank, minrank, package, proto, xml.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह फ़ील्ड, नियम के इंस्टेंस के लिए Starlark कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की गई थी.
टैग: terminal_output

--[no]proto:flatten_selects डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची के टाइप के लिए, फ़्लैट किया गया रिप्रज़ेंटेशन एक सूची होती है, जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप को शून्य पर फ़्लैट कर दिया जाता है.
टैग: build_file_semantics

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत"

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत"

हर नियम के इंस्टैंशिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output

--[no]proto:locations डिफ़ॉल्ट: "सही"

क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है या नहीं.
टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "all"

आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा से अलग की गई सूची. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output

--query_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां फ़ाइल के साथ-साथ कमांड-लाइन क्वेरी भी डालना गलत है.
टैग: changes_inputs

--[no]relative_locations डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output

--[no]strict_test_suite डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो tests() एक्सप्रेशन गड़बड़ी दिखाता है. ऐसा तब होता है, जब उसे test_suite में ऐसे टारगेट मिलते हैं जो टेस्ट नहीं हैं.
टैग: build_file_semantics, eagerness_to_exit

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: अगर यह विकल्प बंद है, तो 'होस्ट कॉन्फ़िगरेशन' या 'एक्सीक्यूशन' टारगेट पर निर्भरता, उस डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए सभी टारगेट को फ़िल्टर कर दिया जाता है. ये ऐसे टारगेट होते हैं जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, होस्ट या एक्सीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: 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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो एक्सएमएल आउटपुट में लाइन नंबर शामिल होते हैं. इस विकल्प को बंद करने से, बदलावों को पढ़ना आसान हो सकता है. यह विकल्प सिर्फ़ --output=xml पर लागू होता है.
टैग: terminal_output

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

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

--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "failure"

चुनें कि रिमोट से चलाए गए निर्देशों के मैसेज कब प्रिंट किए जाएं. मान्य वैल्यू: सिर्फ़ गड़बड़ियों पर प्रिंट करने के लिए `failure`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए `success`, और हमेशा प्रिंट करने के लिए `all`.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें

सर्किट ब्रेकर के इस्तेमाल के लिए रणनीति तय करता है. उपलब्ध रणनीतियां "फ़ेल्योर" हैं. विकल्प के लिए अमान्य वैल्यू देने पर, विकल्प के लिए सेट किया गया व्यवहार नहीं दिखता.
टैग: execution

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत"

किसी ऐक्शन की इनपुट फ़ाइलों को रिमोट कैश मेमोरी में अपलोड करने से पहले, उनकी ctime की जांच करने की सुविधा बंद करने के लिए, इसे बंद करें. कुछ मामलों में, Linux kernel फ़ाइलों को लिखने में देरी कर सकता है. इस वजह से, गलत नतीजे मिल सकते हैं.

--experimental_remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "all"

अगर इसे 'सभी' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड हो जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते.हालांकि, BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों (जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल) को अपलोड किया जाता है. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का हमेशा इस्तेमाल किया जाता है. भले ही, वे रिमोट कैश मेमोरी में मौजूद न हों. डिफ़ॉल्ट रूप से 'सभी' पर सेट होता है.

--[no]experimental_remote_cache_async डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो स्पॉन के हिस्से के तौर पर होने के बजाय, रिमोट कैश मेमोरी का I/O बैकग्राउंड में होगा.

--[no]experimental_remote_cache_compression डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो zstd की मदद से कैश मेमोरी ब्लॉब को कंप्रेस/डिकंप्रेस करें.

--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.

--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "गलत"

अगर इसे 'सही' पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़ी इनपुट मैपिंग की मेमोरी में मौजूद कॉपी को हटा दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में डेटा न मिलने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कैलकुलेट करना पड़ता है.

--experimental_remote_downloader=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट एसेट एपीआई एंडपॉइंट का यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाएगा. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

--[no]experimental_remote_downloader_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.

--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "गलत"

रिमोट तरीके से प्रोसेस करने के लिए, 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.> डिफ़ॉल्ट: "60s"

वह इंटरवल जिसमें रिमोट अनुरोधों के पूरा न होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, गड़बड़ी की अवधि को पूरे एक्सीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution

--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, इनपुट को रिमोट एक्सीक्यूटर के लिए टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर लगातार काम करने वाले वर्कर लागू करने के लिए किया जा सकता है.

--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेर्कल ट्री कैलकुलेशन को मेमोइज़ किया जाएगा. कैश मेमोरी का फ़ुटप्रिंट, --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.

--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000"

रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेमोज़ करने वाले मेर्कल ट्री की संख्या. भले ही, सॉफ़्ट रेफ़रंस को मैनेज करने के लिए Java, कैश मेमोरी को अपने-आप कम करता है, लेकिन बहुत ज़्यादा सेट करने पर, मेमोरी खत्म होने की गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड हो जाता है. प्रोजेक्ट के साइज़ के हिसाब से, ऑप्टिमम वैल्यू अलग-अलग होती है. डिफ़ॉल्ट रूप से 1,000.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो यह पक्का करें कि दूर से चलने वाली सभी कार्रवाइयां कैश मेमोरी में सेव हों. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह सुविधा, नॉन-डिटरमिनिस्टिक समस्याओं को हल करने में मदद करती है. इससे यह जांच की जा सकती है कि कैश मेमोरी में सेव की जानी वाली कार्रवाइयां, असल में कैश मेमोरी में सेव की गई हैं या नहीं. ऐसा करने के लिए, कैश मेमोरी में नए नतीजे इंजेक्ट नहीं किए जाते.

--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो BEP से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तौर पर कैश मेमोरी में कैश नहीं किया जा सकता.

--[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 डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो --noremote_upload_local_results और --noremote_accept_cached, डिस्क कैश मेमोरी पर लागू नहीं होंगे. अगर किसी कॉम्बाइन किए गए कैश का इस्तेमाल किया जाता है, तो: --noremote_upload_local_results का इस्तेमाल करने पर, नतीजे डिस्क कैश में सेव हो जाएंगे, लेकिन रिमोट कैश में अपलोड नहीं होंगे. --noremote_accept_cached का इस्तेमाल करने पर, Bazel डिस्क कैश मेमोरी में नतीजों की जांच करेगा, लेकिन रिमोट कैश मेमोरी में नहीं. no-remote-exec कार्रवाइयों से डिस्क कैश पर असर पड़ सकता है. ज़्यादा जानकारी के लिए, #8216 देखें.
टैग: incompatible_change

--[no]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो अगर बिल्ड के दौरान रिमोट कैश मेमोरी, ब्लॉब को हटाती है, तो Bazel 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगी.
टैग: incompatible_change

--[no]remote_accept_cached डिफ़ॉल्ट: "सही"

क्या कार्रवाई के रिमोट कैश मेमोरी में सेव किए गए नतीजों को स्वीकार करना है.

--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट स्ट्रीम में लिखे गए bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम. यह विकल्प तब सेट किया जा सकता है, जब किसी प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इसकी वजह से, --remote_executor और --remote_instance_name की वैल्यू, रिमोट इकसेक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. सेट न होने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.

--remote_cache=<a string> डिफ़ॉल्ट: जानकारी देखें

कैश मेमोरी में डेटा सेव करने वाले एंडपॉइंट का यूआरआई. इन स्कीम का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा की जानकारी दें. https://bazel.build/remote/caching पर जाएं

--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_properties सेट नहीं है, तो रिमोट एक्सीक्यूशन एपीआई के लिए सेट की जाने वाली डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. अगर होस्ट प्लैटफ़ॉर्म को रिमोट तौर पर चलाने के लिए, एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल भी किया जाएगा.

--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 या HOST:PORT. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा की वैल्यू दें.

--remote_grpc_log=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर यह पैरामीटर दिया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए, फ़ाइल का पाथ. इस लॉग में, सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry protobufs का क्रम होता है. हर मैसेज के आगे एक वैरिएंट होता है, जो सीरियलाइज़ किए गए अगले protobuf मैसेज का साइज़ दिखाता है. यह साइज़, LogEntry.writeDelimitedTo(OutputStream) तरीके से दिखाया जाता है.

--remote_header=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसा हेडर डालें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. एक से ज़्यादा हेडर पास करने के लिए, फ़्लैग को कई बार डालें. एक ही नाम के लिए एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.

--remote_instance_name=<a string> डिफ़ॉल्ट: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट तरीके से लागू करने की प्रोसेस पूरी न होने पर, स्टैंडअलोन लोकल तरीके से लागू करने की रणनीति का इस्तेमाल करना है या नहीं.

--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "local"

काम नहीं करता, अब इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

--remote_max_connections=<an integer> डिफ़ॉल्ट: "100"

रिमोट कैश मेमोरी/एग्ज़ीक्यूटर पर एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, यह तय करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एग्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को मैनेज कर सकता है. इसलिए, Bazel एक साथ `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations

--remote_proxy=<a string> डिफ़ॉल्ट: जानकारी देखें

प्रॉक्सी के ज़रिए रिमोट कैश मेमोरी से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.

--remote_result_cache_priority=<an integer> डिफ़ॉल्ट: "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.> डिफ़ॉल्ट: "60s"

रिमोट तरीके से एक्सीक्यूशन और कैश मेमोरी कॉल के लिए इंतज़ार करने की ज़्यादा से ज़्यादा समयावधि. REST कैश मेमोरी के लिए, यह कनेक्ट और पढ़ने के लिए टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--[no]remote_upload_local_results डिफ़ॉल्ट: "सही"

अगर रिमोट कैश मेमोरी में कार्रवाई के नतीजे अपलोड किए जा सकते हैं और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या लोकल तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.

--[no]remote_verify_downloads डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो Bazel सभी रिमोट डाउनलोड के हैश का कुल हिसाब लगाएगा. साथ ही, अगर रिमोट से कैश मेमोरी में सेव की गई वैल्यू, उम्मीद के मुताबिक नहीं होती हैं, तो उन्हें खारिज कर देगा.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.> एक से ज़्यादा बार इस्तेमाल किए जाने पर

रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी में सेव करने, और उसे लागू करने के साथ-साथ, इवेंट की बिल्ड सेवा के लिए अनुमति के क्रेडेंशियल पाने के लिए, क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है. किसी हेल्पर से मिले क्रेडेंशियल, --google_default_credentials, --google_credentials, .netrc फ़ाइल या repository_ctx.download और repository_ctx.download_and_extract के auth पैरामीटर से मिले क्रेडेंशियल से ज़्यादा प्राथमिकता पाते हैं. एक से ज़्यादा हेल्पर सेट अप करने के लिए, कई बार इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-credential-helpers.md देखें.

--credential_helper_cache_duration=<An immutable length of time.> डिफ़ॉल्ट: "30 मीटर"

क्रेडेंशियल हेल्पर से मिले क्रेडेंशियल को कैश मेमोरी में सेव रखने की अवधि. किसी दूसरी वैल्यू के साथ कॉल करने पर, पहले से मौजूद एंट्री के लाइफ़टाइम में बदलाव होगा. कैश मेमोरी मिटाने के लिए, शून्य पास करें. इस फ़्लैग के बावजूद, क्लीन कमांड हमेशा कैश मेमोरी मिटाता है.

--credential_helper_timeout=<An immutable length of time.> डिफ़ॉल्ट: "10s"

क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. अगर क्रेडेंशियल हेल्पर इस टाइम आउट के अंदर जवाब नहीं देते हैं, तो अनुरोध पूरा नहीं होगा.

--deleted_packages=<comma-separated list of package names> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो हो सकता है कि वह शिकायत करे. ऐसा तब होगा, जब वह लेबल किसी अन्य package_path एंट्री से उपलब्ध कराया गया हो. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--disk_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.

--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.> डिफ़ॉल्ट: "20s"

आउटगोइंग gRPC कनेक्शन के लिए, 'कनेक्शन बनाए रखने की सुविधा' का टाइम आउट कॉन्फ़िगर करता है. अगर --grpc_keepalive_time के साथ, 'किंग-ऐलिव' पिंग चालू किए जाते हैं, तो Bazel इस समयावधि के बाद पिंग का जवाब न मिलने पर, कनेक्शन को टाइम आउट कर देता है. समय को सेकंड के हिसाब से ज़्यादा सटीक माना जाता है. एक सेकंड से कम की वैल्यू सेट करने पर गड़बड़ी का मैसेज दिखता है. अगर 'किंग-ऐलिव' पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--tls_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

उस TLS सर्टिफ़िकेट का पाथ डालें जिस पर सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.

--tls_client_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट की जानकारी दें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट पासकोड भी देना होगा.

--tls_client_key=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट पासकोड डालें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--script_path=<a path> डिफ़ॉल्ट: जानकारी देखें

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

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--iff_heap_size_greater_than=<an integer> डिफ़ॉल्ट: "0"

अगर यह वैल्यू शून्य से ज़्यादा है, तो सर्वर सिर्फ़ तब बंद होगा, जब JVM का इस्तेमाल की गई कुल मेमोरी (एमबी में) इस वैल्यू से ज़्यादा हो.
टैग: loses_incremental_state, eagerness_to_exit

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]configure डिफ़ॉल्ट: "गलत"

सिर्फ़ उन रिपॉज़िटरी को सिंक करें जिन्हें सिस्टम कॉन्फ़िगरेशन के लिए, 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है.
टैग: changes_inputs

--[no]incompatible_remote_dangling_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है और --incompatible_remote_symlinks भी 'सही' पर सेट होता है, तो ऐक्शन आउटपुट में मौजूद सिंकलिंक को लटकने की अनुमति होती है.
टैग: execution, incompatible_change

--[no]incompatible_remote_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैश मेमोरी/कार्रवाई के आउटपुट में सिमलिंक को इस तरह दिखाएगा. ऐसा न करने पर, लिंक किए गए फ़ोल्डर को फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए, #6631 देखें.
टैग: execution, incompatible_change

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--only=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर यह विकल्प दिया जाता है, तो सिर्फ़ इस विकल्प में बताई गई रिपॉज़िटरी सिंक करें. हालांकि, अब भी सभी (या --configure के दिए जाने पर, configure जैसे सभी) को पुराना माना जाता है.
टैग: changes_inputs

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1"

बीईपी आर्टफ़ैक्ट अपलोड करने के दौरान, ज़्यादा से ज़्यादा कितनी फ़ाइलें खोली जा सकती हैं.
टैग: affects_outputs

--remote_download_minimal

स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=minimal.
इस तरह बड़ा होता है:
  --nobuild_runfile_links
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=minimal

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> डिफ़ॉल्ट: "all"

अगर इसे 'कम से कम' पर सेट किया जाता है, तो स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होता. हालांकि, स्थानीय कार्रवाइयों के लिए ज़रूरी आउटपुट डाउनलोड किए जाते हैं. 'toplevel' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह लोकल मशीन पर टॉप लेवल टारगेट के आउटपुट भी डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की समस्या है, तो दोनों विकल्पों से बिल्ड में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs

--remote_download_symlink_template=<a string> डिफ़ॉल्ट: ""

रिमोट बिल्ड आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबल लिंक बनाएं. सिंबल लिंक का टारगेट, टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये क्रमशः ऑब्जेक्ट के हैश और बाइट में साइज़ में बदल जाते हैं. उदाहरण के लिए, ये सिंबल लिंक किसी ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर सीएएस से ऑब्जेक्ट लोड करता है.
टैग: affects_outputs

--remote_download_toplevel

सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट को लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=toplevel.
इस तरह बड़ा होता है:
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=toplevel

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की गई
टैग: no_op, deprecated, experimental

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: 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

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

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

--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "failure"

चुनें कि रिमोट से चलाए गए निर्देशों के मैसेज कब प्रिंट किए जाएं. मान्य वैल्यू: सिर्फ़ गड़बड़ियों पर प्रिंट करने के लिए `failure`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए `success`, और हमेशा प्रिंट करने के लिए `all`.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें

सर्किट ब्रेकर के इस्तेमाल के लिए रणनीति तय करता है. उपलब्ध रणनीतियां "फ़ेल्योर" हैं. विकल्प के लिए अमान्य वैल्यू देने पर, विकल्प के लिए सेट किया गया व्यवहार नहीं दिखता.
टैग: execution

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत"

किसी ऐक्शन की इनपुट फ़ाइलों को रिमोट कैश मेमोरी में अपलोड करने से पहले, उनकी ctime की जांच करने की सुविधा बंद करने के लिए, इसे बंद करें. कुछ मामलों में, Linux kernel फ़ाइलों को लिखने में देरी कर सकता है. इस वजह से, गलत नतीजे मिल सकते हैं.

--experimental_remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "all"

अगर इसे 'सभी' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड हो जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते.हालांकि, BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों (जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल) को अपलोड किया जाता है. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का हमेशा इस्तेमाल किया जाता है. भले ही, वे रिमोट कैश मेमोरी में मौजूद न हों. डिफ़ॉल्ट रूप से 'सभी' पर सेट होता है.

--[no]experimental_remote_cache_async डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो स्पॉन के हिस्से के तौर पर होने के बजाय, रिमोट कैश मेमोरी का I/O बैकग्राउंड में होगा.

--[no]experimental_remote_cache_compression डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो zstd की मदद से कैश मेमोरी ब्लॉब को कंप्रेस/डिकंप्रेस करें.

--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.

--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "गलत"

अगर इसे 'सही' पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़ी इनपुट मैपिंग की मेमोरी में मौजूद कॉपी को हटा दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में डेटा न मिलने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कैलकुलेट करना पड़ता है.

--experimental_remote_downloader=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट एसेट एपीआई एंडपॉइंट का यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाएगा. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

--[no]experimental_remote_downloader_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.

--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "गलत"

रिमोट तरीके से प्रोसेस करने के लिए, 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.> डिफ़ॉल्ट: "60s"

वह इंटरवल जिसमें रिमोट अनुरोधों के पूरा न होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, गड़बड़ी की अवधि को पूरे एक्सीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution

--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, इनपुट को रिमोट एक्सीक्यूटर के लिए टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर लगातार काम करने वाले वर्कर लागू करने के लिए किया जा सकता है.

--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेर्कल ट्री कैलकुलेशन को मेमोइज़ किया जाएगा. कैश मेमोरी का फ़ुटप्रिंट, --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.

--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000"

रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेमोज़ करने वाले मेर्कल ट्री की संख्या. भले ही, सॉफ़्ट रेफ़रंस को मैनेज करने के लिए Java, कैश मेमोरी को अपने-आप कम करता है, लेकिन बहुत ज़्यादा सेट करने पर, मेमोरी खत्म होने की गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड हो जाता है. प्रोजेक्ट के साइज़ के हिसाब से, ऑप्टिमम वैल्यू अलग-अलग होती है. डिफ़ॉल्ट रूप से 1,000 पर सेट होती है.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो यह पक्का करें कि दूर से चलने वाली सभी कार्रवाइयां कैश मेमोरी में सेव हों. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह सुविधा, नॉन-डिटरमिनिस्टिक समस्याओं को हल करने में मदद करती है. इससे यह जांच की जा सकती है कि कैश मेमोरी में सेव की जानी वाली कार्रवाइयां, असल में कैश मेमोरी में सेव की गई हैं या नहीं. ऐसा करने के लिए, कैश मेमोरी में नए नतीजे इंजेक्ट नहीं किए जाते.

--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो BEP से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तौर पर कैश मेमोरी में कैश नहीं किया जा सकता.

--[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 डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो --noremote_upload_local_results और --noremote_accept_cached, डिस्क कैश मेमोरी पर लागू नहीं होंगे. अगर किसी कॉम्बाइन कैश का इस्तेमाल किया जाता है, तो: --noremote_upload_local_results का इस्तेमाल करने पर, नतीजे डिस्क कैश में सेव हो जाएंगे, लेकिन रिमोट कैश में अपलोड नहीं होंगे. --noremote_accept_cached का इस्तेमाल करने पर, Bazel डिस्क कैश मेमोरी में नतीजों की जांच करेगा, लेकिन रिमोट कैश मेमोरी में नहीं. no-remote-exec कार्रवाइयों से डिस्क कैश पर असर पड़ सकता है. ज़्यादा जानकारी के लिए, #8216 देखें.
टैग: incompatible_change

--[no]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो अगर बिल्ड के दौरान रिमोट कैश मेमोरी, ब्लॉब को हटाती है, तो Bazel 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगी.
टैग: incompatible_change

--[no]remote_accept_cached डिफ़ॉल्ट: "सही"

क्या कार्रवाई के रिमोट कैश मेमोरी में सेव किए गए नतीजों को स्वीकार करना है.

--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट स्ट्रीम में लिखे गए bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम. यह विकल्प तब सेट किया जा सकता है, जब किसी प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इसकी वजह से, --remote_executor और --remote_instance_name की वैल्यू, रिमोट इकसेक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. सेट न होने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.

--remote_cache=<a string> डिफ़ॉल्ट: जानकारी देखें

कैश मेमोरी में डेटा सेव करने वाले एंडपॉइंट का यूआरआई. इन स्कीम का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा की जानकारी दें. https://bazel.build/remote/caching पर जाएं

--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_properties सेट नहीं है, तो रिमोट एक्सीक्यूशन एपीआई के लिए सेट की जाने वाली डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. अगर होस्ट प्लैटफ़ॉर्म को रिमोट तौर पर चलाने के लिए, एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल भी किया जाएगा.

--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 या HOST:PORT. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा की वैल्यू दें.

--remote_grpc_log=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर यह पैरामीटर दिया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए, फ़ाइल का पाथ. इस लॉग में, सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry protobufs का क्रम होता है. हर मैसेज के आगे एक वैरिएंट होता है, जो सीरियलाइज़ किए गए अगले protobuf मैसेज का साइज़ दिखाता है. यह साइज़, LogEntry.writeDelimitedTo(OutputStream) तरीके से दिखाया जाता है.

--remote_header=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसा हेडर डालें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. एक से ज़्यादा हेडर पास करने के लिए, फ़्लैग को कई बार डालें. एक ही नाम के लिए एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.

--remote_instance_name=<a string> डिफ़ॉल्ट: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट तरीके से लागू करने की प्रोसेस पूरी न होने पर, स्टैंडअलोन लोकल तरीके से लागू करने की रणनीति का इस्तेमाल करना है या नहीं.

--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "local"

काम नहीं करता, अब इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

--remote_max_connections=<an integer> डिफ़ॉल्ट: "100"

रिमोट कैश मेमोरी/एग्ज़ीक्यूटर पर एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, यह तय करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एग्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को मैनेज कर सकता है. इसलिए, Bazel एक साथ `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations

--remote_proxy=<a string> डिफ़ॉल्ट: जानकारी देखें

प्रॉक्सी के ज़रिए रिमोट कैश मेमोरी से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.

--remote_result_cache_priority=<an integer> डिफ़ॉल्ट: "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.> डिफ़ॉल्ट: "60s"

रिमोट तरीके से एक्सीक्यूशन और कैश मेमोरी कॉल के लिए इंतज़ार करने की ज़्यादा से ज़्यादा समयावधि. REST कैश मेमोरी के लिए, यह कनेक्ट और पढ़ने के लिए टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--[no]remote_upload_local_results डिफ़ॉल्ट: "सही"

अगर रिमोट कैश मेमोरी में कार्रवाई के नतीजे अपलोड किए जा सकते हैं और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या लोकल तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.

--[no]remote_verify_downloads डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो Bazel सभी रिमोट डाउनलोड के हैश का कुल हिसाब लगाएगा. साथ ही, अगर रिमोट से कैश मेमोरी में सेव की गई वैल्यू, उम्मीद के मुताबिक नहीं होती हैं, तो उन्हें खारिज कर देगा.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.> एक से ज़्यादा बार इस्तेमाल किए जाने पर

रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी में सेव करने, और उसे लागू करने के साथ-साथ, इवेंट की बिल्ड सेवा के लिए अनुमति के क्रेडेंशियल पाने के लिए, क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है. किसी हेल्पर से मिले क्रेडेंशियल, --google_default_credentials, --google_credentials, .netrc फ़ाइल या repository_ctx.download और repository_ctx.download_and_extract के auth पैरामीटर से मिले क्रेडेंशियल से ज़्यादा प्राथमिकता पाते हैं. एक से ज़्यादा हेल्पर सेट अप करने के लिए, कई बार इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-credential-helpers.md देखें.

--credential_helper_cache_duration=<An immutable length of time.> डिफ़ॉल्ट: "30 मीटर"

क्रेडेंशियल हेल्पर से मिले क्रेडेंशियल को कैश मेमोरी में सेव रखने की अवधि. किसी दूसरी वैल्यू के साथ कॉल करने पर, पहले से मौजूद एंट्री के लाइफ़टाइम में बदलाव होगा. कैश मेमोरी मिटाने के लिए, शून्य पास करें. इस फ़्लैग के बावजूद, क्लीन कमांड हमेशा कैश मेमोरी मिटाता है.

--credential_helper_timeout=<An immutable length of time.> डिफ़ॉल्ट: "10s"

क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. अगर क्रेडेंशियल हेल्पर इस टाइम आउट के अंदर जवाब नहीं देते हैं, तो अनुरोध पूरा नहीं होगा.

--deleted_packages=<comma-separated list of package names> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो हो सकता है कि वह शिकायत करे. ऐसा तब होगा, जब वह लेबल किसी अन्य package_path एंट्री से उपलब्ध कराया गया हो. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--disk_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.

--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.> डिफ़ॉल्ट: "20s"

आउटगोइंग gRPC कनेक्शन के लिए, 'कनेक्शन बनाए रखने की सुविधा' का टाइम आउट कॉन्फ़िगर करता है. अगर --grpc_keepalive_time के साथ, 'किंग-ऐलिव' पिंग चालू किए जाते हैं, तो Bazel इस समयावधि के बाद पिंग का जवाब न मिलने पर, कनेक्शन को टाइम आउट कर देता है. समय को सेकंड के हिसाब से ज़्यादा सटीक माना जाता है. एक सेकंड से कम की वैल्यू सेट करने पर गड़बड़ी का मैसेज दिखता है. अगर 'किंग-ऐलिव' पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--tls_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

उस TLS सर्टिफ़िकेट का पाथ डालें जिस पर सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.

--tls_client_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट की जानकारी दें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट पासकोड भी देना होगा.

--tls_client_key=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट पासकोड डालें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.

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

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]incompatible_remote_dangling_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है और --incompatible_remote_symlinks भी 'सही' पर सेट होता है, तो ऐक्शन आउटपुट में मौजूद सिंकलिंक को लटकने की अनुमति होती है.
टैग: execution, incompatible_change

--[no]incompatible_remote_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैश मेमोरी/कार्रवाई के आउटपुट में सिमलिंक को इस तरह दिखाएगा. ऐसा न करने पर, लिंक किए गए फ़ोल्डर को फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए, #6631 देखें.
टैग: execution, incompatible_change

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपनी पसंद के मुताबिक आउटपुट कॉन्फ़िगर कर सकता है. इससे, आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1"

बीईपी आर्टफ़ैक्ट अपलोड करने के दौरान, ज़्यादा से ज़्यादा कितनी फ़ाइलें खोली जा सकती हैं.
टैग: affects_outputs

--remote_download_minimal

स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=minimal.
इस तरह बड़ा होता है:
  --nobuild_runfile_links
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=minimal

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> डिफ़ॉल्ट: "all"

अगर इसे 'कम से कम' पर सेट किया जाता है, तो स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होता. हालांकि, स्थानीय कार्रवाइयों के लिए ज़रूरी आउटपुट डाउनलोड किए जाते हैं. 'toplevel' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह लोकल मशीन पर टॉप लेवल टारगेट के आउटपुट भी डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की समस्या है, तो दोनों विकल्पों से बिल्ड करने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs

--remote_download_symlink_template=<a string> डिफ़ॉल्ट: ""

रिमोट बिल्ड आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबल लिंक बनाएं. सिंबल लिंक का टारगेट, टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये क्रमशः ऑब्जेक्ट के हैश और बाइट में साइज़ में बदल जाते हैं. उदाहरण के लिए, ये सिंबल लिंक किसी ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर सीएएस से ऑब्जेक्ट लोड करता है.
टैग: affects_outputs

--remote_download_toplevel

सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट को लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, इन फ़्लैग का शॉर्टकट है: --experimental_inmemory_jdeps_files, --experimental_inmemory_dotd_files, --experimental_action_cache_store_output_metadata, और --remote_download_outputs=toplevel.
इस तरह बड़ा होता है:
  --experimental_inmemory_jdeps_files
  --experimental_inmemory_dotd_files
  --experimental_action_cache_store_output_metadata
  --remote_download_outputs=toplevel

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--[no]print_relative_test_log_paths डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो किसी टेस्ट लॉग के पाथ को प्रिंट करते समय, रिलेटिव पाथ का इस्तेमाल करें. यह पाथ, 'testlogs' सुविधा वाले सिंबललिंक का इस्तेमाल करता है. ध्यान दें - किसी दूसरे कॉन्फ़िगरेशन के साथ 'बिल्ड'/'टेस्ट'/वगैरह को फिर से शुरू करने पर, इस सिंबललिंक का टारगेट बदल सकता है. इससे, पहले प्रिंट किया गया पाथ अब काम का नहीं रह जाता.
टैग: affects_outputs

--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "failure"

चुनें कि रिमोट से चलाए गए निर्देशों के मैसेज कब प्रिंट किए जाएं. मान्य वैल्यू: सिर्फ़ गड़बड़ियों पर प्रिंट करने के लिए `failure`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए `success`, और हमेशा प्रिंट करने के लिए `all`.
टैग: terminal_output

--[no]test_verbose_timeout_warnings डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट के असल समय और टेस्ट के लिए तय किए गए टाइम आउट (चाहे वह तय किया गया हो या नहीं) के मेल न खाने पर, अतिरिक्त चेतावनियां प्रिंट करें.
टैग: affects_outputs

--[no]verbose_test_summary डिफ़ॉल्ट: "सही"

अगर यह सही है, तो टेस्ट की खास जानकारी में ज़्यादा जानकारी (समय, बिना काम किए हुए रन की संख्या वगैरह) प्रिंट करें.
टैग: affects_outputs

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें

सर्किट ब्रेकर के इस्तेमाल के लिए रणनीति तय करता है. उपलब्ध रणनीतियां "फ़ेल्योर" हैं. विकल्प के लिए अमान्य वैल्यू देने पर, विकल्प के लिए सेट किया गया व्यवहार नहीं दिखता.
टैग: execution

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत"

किसी ऐक्शन की इनपुट फ़ाइलों को रिमोट कैश मेमोरी में अपलोड करने से पहले, उनकी ctime की जांच करने की सुविधा बंद करने के लिए, इसे बंद करें. कुछ मामलों में, Linux kernel फ़ाइलों को लिखने में देरी कर सकता है. इस वजह से, गलत नतीजे मिल सकते हैं.

--experimental_remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "all"

अगर इसे 'सभी' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड हो जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते.हालांकि, BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों (जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल) को अपलोड किया जाता है. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का हमेशा इस्तेमाल किया जाता है. भले ही, वे रिमोट कैश मेमोरी में मौजूद न हों. डिफ़ॉल्ट रूप से 'सभी' पर सेट होता है.

--[no]experimental_remote_cache_async डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो स्पॉन के हिस्से के तौर पर होने के बजाय, रिमोट कैश मेमोरी का I/O बैकग्राउंड में होगा.

--[no]experimental_remote_cache_compression डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो zstd की मदद से कैश मेमोरी ब्लॉब को कंप्रेस/डिकंप्रेस करें.

--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.

--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "गलत"

अगर इसे 'सही' पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़ी इनपुट मैपिंग की मेमोरी में मौजूद कॉपी को हटा दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में डेटा न मिलने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कैलकुलेट करना पड़ता है.

--experimental_remote_downloader=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट एसेट एपीआई एंडपॉइंट का यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाएगा. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

--[no]experimental_remote_downloader_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.

--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "गलत"

रिमोट तरीके से प्रोसेस करने के लिए, 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.> डिफ़ॉल्ट: "60s"

वह इंटरवल जिसमें रिमोट अनुरोधों के पूरा न होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, गड़बड़ी की अवधि को पूरे एक्सीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution

--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, इनपुट को रिमोट एक्सीक्यूटर के लिए टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर लगातार काम करने वाले वर्कर लागू करने के लिए किया जा सकता है.

--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेर्कल ट्री कैलकुलेशन को मेमोइज़ किया जाएगा. कैश मेमोरी का फ़ुटप्रिंट, --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.

--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000"

रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेमोज़ करने वाले मेर्कल ट्री की संख्या. भले ही, सॉफ़्ट रेफ़रंस को मैनेज करने के लिए Java, कैश मेमोरी को अपने-आप कम करता है, लेकिन बहुत ज़्यादा सेट करने पर, मेमोरी खत्म होने की गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड हो जाता है. प्रोजेक्ट के साइज़ के हिसाब से, ऑप्टिमम वैल्यू अलग-अलग होती है. डिफ़ॉल्ट रूप से 1,000.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो यह पक्का करें कि दूर से चलने वाली सभी कार्रवाइयां कैश मेमोरी में सेव हों. ऐसा न होने पर, बिल्ड पूरा नहीं होगा. यह सुविधा, नॉन-डिटरमिनिस्टिक समस्याओं को हल करने में मदद करती है. इससे यह जांच की जा सकती है कि कैश मेमोरी में सेव की जानी वाली कार्रवाइयां, असल में कैश मेमोरी में सेव की गई हैं या नहीं. ऐसा करने के लिए, कैश मेमोरी में नए नतीजे इंजेक्ट नहीं किए जाते.

--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो BEP से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तौर पर कैश मेमोरी में कैश नहीं किया जा सकता.

--[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 डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो --noremote_upload_local_results और --noremote_accept_cached, डिस्क कैश मेमोरी पर लागू नहीं होंगे. अगर किसी कॉम्बाइन कैश का इस्तेमाल किया जाता है, तो: --noremote_upload_local_results का इस्तेमाल करने पर, नतीजे डिस्क कैश में सेव हो जाएंगे, लेकिन रिमोट कैश में अपलोड नहीं होंगे. --noremote_accept_cached का इस्तेमाल करने पर, Bazel डिस्क कैश मेमोरी में नतीजों की जांच करेगा, लेकिन रिमोट कैश मेमोरी में नहीं. no-remote-exec कार्रवाइयों से डिस्क कैश पर असर पड़ सकता है. ज़्यादा जानकारी के लिए, #8216 देखें.
टैग: incompatible_change

--[no]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो अगर बिल्ड के दौरान रिमोट कैश मेमोरी, ब्लॉब को हटाती है, तो Bazel 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगी.
टैग: incompatible_change

--[no]remote_accept_cached डिफ़ॉल्ट: "सही"

क्या कार्रवाई के रिमोट कैश मेमोरी में सेव किए गए नतीजों को स्वीकार करना है.

--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट स्ट्रीम में लिखे गए bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम. यह विकल्प तब सेट किया जा सकता है, जब किसी प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इसकी वजह से, --remote_executor और --remote_instance_name की वैल्यू, रिमोट इकसेक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. सेट न होने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.

--remote_cache=<a string> डिफ़ॉल्ट: जानकारी देखें

कैश मेमोरी में डेटा सेव करने वाले एंडपॉइंट का यूआरआई. इन स्कीम का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा की जानकारी दें. https://bazel.build/remote/caching पर जाएं

--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_properties सेट नहीं है, तो रिमोट एक्सीक्यूशन एपीआई के लिए सेट की जाने वाली डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. अगर होस्ट प्लैटफ़ॉर्म को रिमोट तौर पर चलाने के लिए, एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल भी किया जाएगा.

--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 या HOST:PORT. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा की वैल्यू दें.

--remote_grpc_log=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर यह पैरामीटर दिया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए, फ़ाइल का पाथ. इस लॉग में, सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry protobufs का क्रम होता है. हर मैसेज के आगे एक वैरिएंट होता है, जो सीरियलाइज़ किए गए अगले protobuf मैसेज का साइज़ दिखाता है. यह साइज़, LogEntry.writeDelimitedTo(OutputStream) तरीके से दिखाया जाता है.

--remote_header=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसा हेडर डालें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. एक से ज़्यादा हेडर पास करने के लिए, फ़्लैग को कई बार डालें. एक ही नाम के लिए एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.

--remote_instance_name=<a string> डिफ़ॉल्ट: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट तरीके से लागू करने की प्रोसेस पूरी न होने पर, स्टैंडअलोन लोकल तरीके से लागू करने की रणनीति का इस्तेमाल करना है या नहीं.

--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "local"

काम नहीं करता, अब इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

--remote_max_connections=<an integer> डिफ़ॉल्ट: "100"

रिमोट कैश मेमोरी/एग्ज़ीक्यूटर पर एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, यह तय करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एग्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को मैनेज कर सकता है. इसलिए, Bazel एक साथ `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations

--remote_proxy=<a string> डिफ़ॉल्ट: जानकारी देखें

प्रॉक्सी के ज़रिए रिमोट कैश मेमोरी से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.

--remote_result_cache_priority=<an integer> डिफ़ॉल्ट: "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.> डिफ़ॉल्ट: "60s"

रिमोट तौर पर लागू करने और कैश मेमोरी कॉल के लिए इंतज़ार करने की ज़्यादा से ज़्यादा समयावधि. REST कैश मेमोरी के लिए, यह कनेक्ट और पढ़ने के लिए टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--[no]remote_upload_local_results डिफ़ॉल्ट: "सही"

अगर रिमोट कैश मेमोरी में कार्रवाई के नतीजे अपलोड किए जा सकते हैं और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या लोकल तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.

--[no]remote_verify_downloads डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो Bazel सभी रिमोट डाउनलोड के हैश का कुल हिसाब लगाएगा. साथ ही, अगर रिमोट से कैश मेमोरी में सेव की गई वैल्यू, उम्मीद के मुताबिक नहीं होती हैं, तो उन्हें खारिज कर देगा.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.> एक से ज़्यादा बार इस्तेमाल किए जाने पर

रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी में सेव करने, और उसे लागू करने के साथ-साथ, इवेंट की बिल्ड सेवा के लिए अनुमति के क्रेडेंशियल पाने के लिए, क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है. किसी हेल्पर से मिले क्रेडेंशियल, --google_default_credentials, --google_credentials, .netrc फ़ाइल या repository_ctx.download और repository_ctx.download_and_extract के auth पैरामीटर से मिले क्रेडेंशियल से ज़्यादा प्राथमिकता पाते हैं. एक से ज़्यादा हेल्पर सेट अप करने के लिए, कई बार इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-credential-helpers.md देखें.

--credential_helper_cache_duration=<An immutable length of time.> डिफ़ॉल्ट: "30 मीटर"

क्रेडेंशियल हेल्पर से मिले क्रेडेंशियल को कैश मेमोरी में सेव रखने की अवधि. किसी दूसरी वैल्यू के साथ कॉल करने पर, पहले से मौजूद एंट्री के लाइफ़टाइम में बदलाव होगा. कैश मेमोरी मिटाने के लिए, शून्य पास करें. इस फ़्लैग के बावजूद, क्लीन कमांड हमेशा कैश मेमोरी मिटाता है.

--credential_helper_timeout=<An immutable length of time.> डिफ़ॉल्ट: "10s"

क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. अगर क्रेडेंशियल हेल्पर इस टाइम आउट के अंदर जवाब नहीं देते हैं, तो अनुरोध पूरा नहीं होगा.

--disk_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.

--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.> डिफ़ॉल्ट: "20s"

आउटगोइंग gRPC कनेक्शन के लिए, 'कनेक्शन बनाए रखने की सुविधा' का टाइम आउट कॉन्फ़िगर करता है. अगर --grpc_keepalive_time के साथ, 'किंग-ऐलिव' पिंग चालू किए जाते हैं, तो Bazel इस समयावधि के बाद पिंग का जवाब न मिलने पर, कनेक्शन को टाइम आउट कर देता है. समय को सेकंड के हिसाब से ज़्यादा सटीक माना जाता है. एक सेकंड से कम की वैल्यू सेट करने पर गड़बड़ी का मैसेज दिखता है. अगर 'किंग-ऐलिव' पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

--tls_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

उस TLS सर्टिफ़िकेट का पाथ डालें जिस पर सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.

--tls_client_certificate=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट की जानकारी दें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट पासकोड भी देना होगा.

--tls_client_key=<a string> डिफ़ॉल्ट: जानकारी देखें

इस्तेमाल करने के लिए TLS क्लाइंट पासकोड डालें. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.

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

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक करेगी. ऐसा डिस्क स्पेस बचाने के लिए किया जाता है.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_urls_as_default_canonical_id डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो अगर कैननिकल_आईडी की वैल्यू नहीं दी गई है, तो रिपॉज़िटरी के डाउनलोड किए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल करें. इससे यूआरएल में बदलाव होता है, ताकि फ़ाइल को फिर से डाउनलोड किया जा सके. भले ही, कैश मेमोरी में उसी हैश वाली फ़ाइल मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने पर, कैश मेमोरी में गड़बड़ी वाली रिपॉज़िटरी को छिपाया न जा रहा हो.
टैग: loading_and_analysis, experimental

--[no]experimental_repository_disable_download डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो बाहरी रिपॉज़िटरी डाउनलोड करने की अनुमति नहीं है.
टैग: experimental

--experimental_repository_downloader_retries=<an integer> डिफ़ॉल्ट: "0"

डाउनलोड करने से जुड़ी गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग: experimental

--experimental_scale_timeouts=<a double> डिफ़ॉल्ट: "1.0"

Starlark रिपॉज़िटरी के नियमों में मौजूद सभी टाइम आउट को इस फ़ैक्टर के हिसाब से स्केल करें. इस तरह, सोर्स कोड में बदलाव किए बिना, बाहरी रिपॉज़िटरी को उन मशीनों पर काम करने के लिए बनाया जा सकता है जो नियम बनाने वाले की उम्मीद से धीमी हैं
टैग: bazel_internal_configuration, experimental

--http_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: bazel_internal_configuration

--repository_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

बाहरी रिपॉज़िटरी को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताता है. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग देने का मतलब है कि कैश मेमोरी की सुविधा बंद कर दी जाए.
टैग: bazel_internal_configuration

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--[no]gnu_format डिफ़ॉल्ट: "गलत"

अगर सेट है, तो GNU स्टैंडर्ड में बताए गए नियमों का इस्तेमाल करके, वर्शन को स्टैंडआउट में लिखें.
टैग: affects_outputs, execution

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--experimental_repository_hash_file=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो यह किसी ऐसी फ़ाइल की जानकारी देता है जिसमें हल की गई वैल्यू होती है. इस वैल्यू की पुष्टि, रिपॉज़िटरी डायरेक्ट्री के हैश से की जानी चाहिए
टैग: affects_outputs, experimental

--experimental_verify_repository_rules=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर रिपॉज़िटरी के उन नियमों की सूची है जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो --experimental_repository_hash_file से कोई फ़ाइल तय की जा सकती है.
टैग: affects_outputs, experimental

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]experimental_allow_top_level_aspects_parameters डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती
टैग: no_op, deprecated, experimental

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update or error> डिफ़ॉल्ट: "बंद"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर लॉकफ़ाइल अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. लॉकफ़ाइल से न तो पढ़ने और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह Workspace के रूट से जुड़ा होता है. यह `bazel info workspace` का आउटपुट होता है

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

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

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

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

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