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

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]

निर्देश

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

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

--[no]autodetect_server_javabase default: "true"

जब --noautodetect_server_javabase पास किया जाता है, तो Bazel, bazel सर्वर को चलाने के लिए लोकल JDK पर वापस नहीं आता. इसके बजाय, यह बंद हो जाता है.
टैग: affects_outputs, loses_incremental_state

--[no]batch डिफ़ॉल्ट: "false"

अगर इस विकल्प को सेट किया जाता है, तो Bazel को स्टैंडर्ड क्लाइंट/सर्वर मोड में चलाने के बजाय, सिर्फ़ क्लाइंट प्रोसेस के तौर पर चलाया जाएगा. इसमें सर्वर नहीं होगा. यह सुविधा अब काम नहीं करती और इसे हटा दिया जाएगा. अगर आपको सर्वर को बंद करने में समस्या आ रही है, तो कृपया सर्वर को बंद करने के लिए इस तरीके का इस्तेमाल करें.
टैग: loses_incremental_state, bazel_internal_configuration, deprecated

--[no]batch_cpu_scheduling डिफ़ॉल्ट: "false"

सिर्फ़ Linux पर; Blaze के लिए 'batch' सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति उन वर्कलोड के लिए काम की है जिनमें इंटरैक्ट नहीं किया जाता, लेकिन वे अपनी नाइस वैल्यू को कम नहीं करना चाहते. 'man 2 sched_setscheduler' देखें. अगर यह नीति 'गलत है' पर सेट है, तो Bazel सिस्टम कॉल नहीं करेगा.
टैग: host_machine_resource_optimizations

--bazelrc=<path> कई बार इस्तेमाल किया गया हो

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

--[no]block_for_lock default: "true"

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

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

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

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

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

--digest_function=<hash function> डिफ़ॉल्ट: ब्यौरा देखें

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

--experimental_cgroup_parent=<path> डिफ़ॉल्ट: ब्यौरा देखें

वह cgroup जहां Bazel सर्वर को ऐब्सलूट पाथ के तौर पर शुरू करना है. सर्वर प्रोसेस, हर उस कंट्रोलर के लिए तय किए गए cgroup में शुरू की जाएगी जिसके लिए यह सुविधा उपलब्ध है. उदाहरण के लिए, अगर इस फ़्लैग की वैल्यू /build/bazel है और सीपीयू और मेमोरी कंट्रोलर को क्रमशः /sys/fs/cgroup/cpu और /sys/fs/cgroup/memory पर माउंट किया गया है, तो सर्वर को cgroups /sys/fs/cgroup/cpu/build/bazel और /sys/fs/cgroup/memory/build/bazel में शुरू किया जाएगा.अगर बताया गया cgroup, एक या उससे ज़्यादा कंट्रोलर के लिए लिखने लायक नहीं है, तो यह गड़बड़ी नहीं है. इस विकल्प का उन प्लैटफ़ॉर्म पर कोई असर नहीं पड़ता जिन पर cgroup काम नहीं करते.
टैग: bazel_monitoring, execution

--[no]experimental_run_in_user_cgroup डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो Bazel सर्वर को systemd-run के साथ चलाया जाएगा. साथ ही, उपयोगकर्ता के पास cgroup का मालिकाना हक होगा. इस फ़्लैग का असर सिर्फ़ Linux पर पड़ता है.
टैग: bazel_monitoring, execution

--failure_detail_out=<path> डिफ़ॉल्ट: ब्यौरा देखें

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

--[no]home_rc default: "true"

$HOME/.bazelrc पर होम bazelrc फ़ाइल ढूंढनी है या नहीं
टैग: changes_inputs

--[no]idle_server_tasks default: "true"

Run System.gc() when the server is idle
Tags: loses_incremental_state, host_machine_resource_optimizations

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

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

--io_nice_level={-1,0,1,2,3,4,5,6,7} default: "-1"

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

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

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

--macos_qos_class=<a string> default: "default"

macOS पर Bazel सर्वर चलाने पर, QoS सेवा क्लास सेट करता है. इस फ़्लैग का असर अन्य सभी प्लैटफ़ॉर्म पर नहीं पड़ता. हालांकि, इसे इसलिए इस्तेमाल किया जाता है, ताकि यह पक्का किया जा सके कि rc फ़ाइलों को बिना किसी बदलाव के इन प्लैटफ़ॉर्म के बीच शेयर किया जा सके. संभावित वैल्यू ये हैं: user-interactive, user-initiated, default, utility, और background.
टैग: host_machine_resource_optimizations

--max_idle_secs=<integer> default: "10800"

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

--output_base=<path> डिफ़ॉल्ट: ब्यौरा देखें

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

--output_user_root=<path> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

--[no]quiet डिफ़ॉल्ट: "false"

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

--server_jvm_out=<path> डिफ़ॉल्ट: ब्यौरा देखें

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

--[no]shutdown_on_low_sys_mem डिफ़ॉल्ट: "false"

अगर max_idle_secs सेट है और बिल्ड सर्वर कुछ समय से इस्तेमाल नहीं किया जा रहा है, तो सिस्टम में खाली रैम कम होने पर सर्वर को बंद कर दें. सिर्फ़ Linux के लिए.
टैग: eagerness_to_exit, loses_incremental_state

--[no]system_rc default: "true"

सिस्टम-वाइड bazelrc को खोजना है या नहीं.
टैग: changes_inputs

--[no]unlimit_coredumps डिफ़ॉल्ट: "false"

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

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

अगर यह विकल्प चालू है, तो Bazel हर फ़ाइल को स्कैन करने के बजाय, ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करके स्थानीय बदलावों का पता लगाने की कोशिश करता है.
टैग: deprecated

--[no]windows_enable_symlinks डिफ़ॉल्ट: "false"

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

--[no]workspace_rc default: "true"

$workspace/.bazelrc पर मौजूद वर्कस्पेस की bazelrc फ़ाइल को देखना है या नहीं
टैग: changes_inputs

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

--host_jvm_args=<jvm_arg> कई बार इस्तेमाल किया गया हो

Blaze को चलाने वाले JVM को पास किए जाने वाले फ़्लैग.

--host_jvm_debug

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

--server_javabase=<jvm path> default: ""

Bazel को चलाने के लिए इस्तेमाल किए गए JVM का पाथ.

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

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

--distdir=<a path> कई बार इस्तेमाल किया गया हो

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

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

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

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

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

--experimental_scale_timeouts=<a double> default: "1.0"

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

--http_connector_attempts=<an integer> default: "8"

http से डाउनलोड करने के लिए, ज़्यादा से ज़्यादा कोशिशें.
टैग: bazel_internal_configuration

--http_connector_retry_max_timeout=<An immutable length of time.> default: "0s"

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

--http_max_parallel_downloads=<an integer> default: "8"

साथ-साथ डाउनलोड होने वाली एचटीटीपी फ़ाइलों की ज़्यादा से ज़्यादा संख्या.
टैग: bazel_internal_configuration

--http_timeout_scaling=<a double> default: "1.0"

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

--[no]incompatible_disable_native_repo_rules डिफ़ॉल्ट: "false"

अगर यह विकल्प 'गलत है' पर सेट है, तो WORKSPACE में नेटिव रीपो नियमों का इस्तेमाल किया जा सकता है. अगर ऐसा नहीं है, तो Starlark रीपो नियमों का इस्तेमाल करना होगा. नेटिव रेपो के नियमों में local_repository, new_local_repository, और local_config_platform शामिल हैं. इस फ़्लैग को सेट करने पर, Bzlmod में local_config_platform बिल्ट-इन मॉड्यूल भी उपलब्ध नहीं होता है. इसके बजाय, `@platforms//host` का इस्तेमाल करें.
टैग: bazel_internal_configuration

--repo_contents_cache=<a path> default: ""

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

--repo_contents_cache_gc_idle_delay=<An immutable length of time.> default: "5m"

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

--repo_contents_cache_gc_max_age=<An immutable length of time.> डिफ़ॉल्ट: "14d"

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

--repository_cache=<a path> डिफ़ॉल्ट: ब्यौरा देखें

यह डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह के बारे में बताता है. ये वैल्यू, बाहरी रिपॉज़िटरी से फ़ेच की जाती हैं. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग का इस्तेमाल करने पर, कैश मेमोरी को बंद करने का अनुरोध किया जाता है. ऐसा न करने पर, डिफ़ॉल्ट रूप से '<--output_user_root>/cache/repos/v1' का इस्तेमाल किया जाता है
टैग: bazel_internal_configuration

--[no]repository_disable_download डिफ़ॉल्ट: "false"

अगर यह सेट है, तो रिपॉज़िटरी फ़ेच करने के दौरान ctx.download{,_and_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है. ctx.execute अब भी इंटरनेट ऐक्सेस करने वाले किसी भी एक्ज़ीक्यूटेबल को चला सकता है.
टैग: bazel_internal_configuration

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range> default: "1048576"

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

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

यह बताता है कि मेमोरी का कितना प्रतिशत (0 से 100) इस्तेमाल किया जा रहा है. इससे ज़्यादा इस्तेमाल होने पर, GcThrashingDetector, मेमोरी पर दबाव डालने वाले इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

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

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

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

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

--bep_maximum_open_remote_upload_files=<an integer> default: "-1"

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

--[no]experimental_strict_repo_env डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो रिपॉज़िटरी के नियमों और मॉड्यूल एक्सटेंशन में सिर्फ़ `PATH`, `PATHEXT` (Windows पर) और `--repo_env` से साफ़ तौर पर तय की गई एनवायरमेंट वैरिएबल शामिल होंगे. ध्यान दें कि जब तक `--incompatible_repo_env_ignores_action_env` सही नहीं होता, तब तक `--action_env=NAME=VALUE` भी शामिल रहेगा.
टैग: loading_and_analysis, experimental

--[no]incompatible_repo_env_ignores_action_env डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो <code>--action_env=NAME=VALUE</code> का असर, रिपॉज़िटरी के नियम और मॉड्यूल एक्सटेंशन एनवायरमेंट पर नहीं पड़ेगा.
टैग: loading_and_analysis, incompatible_change

--remote_download_all

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

टैग: affects_outputs

--remote_download_minimal

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

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> default: "toplevel"

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

--remote_download_symlink_template=<a string> default: ""

इस विकल्प को चुनने पर, रिमोट बिल्ड के आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबॉलिक लिंक बनाए जाते हैं. सिंबॉलिक लिंक के टारगेट को टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये ऑब्जेक्ट के हैश और साइज़ को बाइट में दिखाते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक, FUSE फ़ाइल सिस्टम की ओर इशारा कर सकते हैं. यह सिस्टम, CAS से ऑब्जेक्ट को ज़रूरत के हिसाब से लोड करता है.
टैग: affects_outputs

--remote_download_toplevel

यह सिर्फ़ टॉप लेवल के टारगेट के रिमोट आउटपुट को स्थानीय मशीन पर डाउनलोड करता है. यह फ़्लैग, --remote_download_outputs=toplevel के लिए उपनाम है.
इनके लिए उपलब्ध है:
  --remote_download_outputs=toplevel

टैग: affects_outputs

--repo_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो

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

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

--[no]check_bzl_visibility default: "true"

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

--[no]incompatible_enforce_starlark_utf8 डिफ़ॉल्ट: "warning"

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

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

--[no]enable_bzlmod default: "true"

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

--[no]enable_workspace डिफ़ॉल्ट: "false"

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

--[no]experimental_bzl_visibility default: "true"

इस विकल्प को चालू करने पर, `visibility()` फ़ंक्शन जुड़ जाता है. .bzl फ़ाइलें, टॉप-लेवल के आकलन के दौरान इस फ़ंक्शन को कॉल कर सकती हैं. इससे, load() स्टेटमेंट के लिए अपनी विज़िबिलिटी सेट की जा सकती है.
टैग: loading_and_analysis, experimental

--[no]experimental_cc_shared_library डिफ़ॉल्ट: "false"

अगर इसे सही पर सेट किया जाता है, तो cc_shared_library नियम के लिए ज़रूरी नियम एट्रिब्यूट और Starlark API के तरीके उपलब्ध होंगे
टैग: build_file_semantics, loading_and_analysis, experimental

--[no]experimental_disable_external_package डिफ़ॉल्ट: "false"

अगर इसे true पर सेट किया जाता है, तो अपने-आप जनरेट होने वाला //external पैकेज अब उपलब्ध नहीं होगा. Bazel अब भी 'external/BUILD' फ़ाइल को पार्स नहीं कर पाएगा. हालांकि, बिना नाम वाले पैकेज से external/ तक पहुंचने वाले ग्लोब काम करेंगे.
टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_dormant_deps डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो attr.label(materializer=), attr(for_dependency_resolution=), attr.dormant_label(), attr.dormant_label_list() और rule(for_dependency_resolution=) का इस्तेमाल किया जा सकता है.
टैग: build_file_semantics, experimental

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

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

--[no]experimental_enable_first_class_macros default: "true"

अगर इसे सही पर सेट किया जाता है, तो सिंबॉलिक मैक्रो तय करने के लिए `macro()` कंस्ट्रक्ट चालू हो जाता है.
टैग: build_file_semantics

--[no]experimental_enable_scl_dialect default: "true"

अगर इसे 'सही है' पर सेट किया जाता है, तो load() स्टेटमेंट में .scl फ़ाइलों का इस्तेमाल किया जा सकता है.
टैग: build_file_semantics

--[no]experimental_enable_starlark_set default: "true"

अगर यह सही है, तो Starlark में सेट डेटा टाइप और set() कंस्ट्रक्टर को चालू करें.
टैग: build_file_semantics, experimental

--[no]experimental_google_legacy_api डिफ़ॉल्ट: "false"

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

--[no]experimental_isolated_extension_usages डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो <a href="https://bazel.build/rules/lib/globals/module#use_extension"><code>use_extension</code></a> फ़ंक्शन में<code>isolate</code> पैरामीटर चालू हो जाता है.
टैग: loading_and_analysis

--[no]experimental_java_library_export डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो experimental_java_library_export_do_not_use मॉड्यूल उपलब्ध होता है.
टैग: loading_and_analysis, incompatible_change

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

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

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

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

--[no]experimental_repository_ctx_execute_wasm डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो repository_ctx के `load_wasm` और `execute_wasm` तरीके चालू हो जाते हैं.
टैग: loading_and_analysis, experimental

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

अगर इसे सही पर सेट किया जाता है, तो मुख्य नहीं हैं ऐसी रिपॉज़िटरी को एक्ज़ीक्यूशन रूट में मुख्य रिपॉज़िटरी के सिमलंक के तौर पर प्लांट किया जाता है. इसका मतलब है कि सभी रिपॉज़िटरी, $output_base/execution_root डायरेक्ट्री की चाइल्ड डायरेक्ट्री होती हैं. इससे, $output_base/execution_root/__main__/external डायरेक्ट्री, असली टॉप-लेवल की 'external' डायरेक्ट्री के लिए खाली हो जाती है.
टैग: action_command_lines, bazel_internal_configuration, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_single_package_toolchain_binding डिफ़ॉल्ट: "false"

इस सुविधा के चालू होने पर, register_toolchain फ़ंक्शन में ऐसे टारगेट पैटर्न शामिल नहीं हो सकते जो एक से ज़्यादा पैकेज को रेफ़र करते हों.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_allow_tags_propagation default: "true"

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

--[no]incompatible_always_check_depset_elements default: "true"

सभी कंस्ट्रक्टर में, डिपसेट में जोड़े गए एलिमेंट की वैधता की जांच करें. तत्वों में बदलाव नहीं किया जा सकता. हालांकि, पहले depset(direct=...) कंस्ट्रक्टर इसकी जांच नहीं करता था. डिपसेट एलिमेंट में सूचियों के बजाय टपल का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10313 पर जाएं.
टैग: build_file_semantics, incompatible_change

--incompatible_autoload_externally=<comma-separated set of options> default: "+@rules_python,+java_common,+JavaInfo,+JavaPluginInfo,ProguardSpecProvider,java_binary,java_import,java_library,java_plugin,java_test,java_runtime,java_toolchain,java_package_configuration,@com_google_protobuf,@rules_shell,+@rules_android"

यह नियमों (या अन्य सिंबल) की कॉमा-सेपरेटेड लिस्ट होती है. ये नियम पहले Bazel का हिस्सा थे और अब इन्हें उनकी बाहरी रिपॉज़िटरी से वापस पाना है. इस फ़्लैग का इस्तेमाल, नियमों को Bazel से बाहर माइग्रेट करने के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/23043 पर भी जाएं. किसी फ़ाइल में अपने-आप लोड होने वाला सिंबल, इस तरह काम करता है जैसे Bazel में बनी उसकी परिभाषा को किसी बाहरी रिपॉज़िटरी में मौजूद उसकी कैननिकल नई परिभाषा से बदल दिया गया हो. BUILD फ़ाइल के लिए, इसका मतलब है कि load() स्टेटमेंट को अपने-आप जोड़ना. .bzl फ़ाइल के लिए, यह load() स्टेटमेंट होता है या `native` ऑब्जेक्ट के फ़ील्ड में बदलाव होता है. यह इस बात पर निर्भर करता है कि अपने-आप लोड होने वाला सिंबल कोई नियम है या नहीं. Bazel, उन सभी सिंबल की एक हार्डकोड की गई सूची बनाए रखता है जिन्हें अपने-आप लोड किया जा सकता है. इस फ़्लैग में सिर्फ़ वे सिंबल दिख सकते हैं. Bazel को हर सिंबल के लिए, बाहरी रिपॉज़िटरी में नई परिभाषा की जगह के बारे में पता होता है. साथ ही, उसे उन रिपॉज़िटरी के बारे में भी पता होता है जिन्हें अपने-आप लोड नहीं करना चाहिए, ताकि साइकल न बन पाएं. इस फ़्लैग में "+foo" की सूची में मौजूद आइटम की वजह से, foo सिंबल अपने-आप लोड हो जाता है. हालांकि, foo की उन रिपॉज़िटरी में ऐसा नहीं होता जिन्हें छूट मिली है. इनमें, Bazel के तय किए गए foo का वर्शन अब भी उपलब्ध है. ऊपर दिए गए उदाहरण के मुताबिक, "foo" की सूची में शामिल आइटम, अपने-आप लोड होने की सुविधा को ट्रिगर करता है. हालांकि, Bazel की ओर से तय किया गया foo का वर्शन, उन रिपॉज़िटरी के लिए उपलब्ध नहीं कराया जाता जिन्हें शामिल नहीं किया गया है. इससे यह पक्का होता है कि foo की बाहरी रिपॉज़िटरी, foo के Bazel के पुराने वर्शन पर निर्भर नहीं है "-foo" की सूची का कोई आइटम, अपने-आप लोड होने की सुविधा को ट्रिगर नहीं करता है. हालांकि, इससे Bazel के तय किए गए foo के वर्शन को पूरे वर्कस्पेस में ऐक्सेस नहीं किया जा सकता. इस कुकी का इस्तेमाल यह पुष्टि करने के लिए किया जाता है कि Bazel से foo की परिभाषा मिटाने के लिए, वर्कस्पेस तैयार है. अगर इस फ़्लैग में किसी सिंबल का नाम नहीं दिया गया है, तो वह सामान्य तरीके से काम करता रहेगा. न तो अपने-आप लोड होने की सुविधा काम करेगी और न ही Bazel के तय किए गए वर्शन को छिपाया जाएगा. कॉन्फ़िगरेशन के लिए, https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/packages/AutoloadSymbols.java देखें. शॉर्टकट के तौर पर, पूरी रिपॉज़िटरी का भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, +@rules_python से सभी Python नियम अपने-आप लोड हो जाएंगे.
टैग: loses_incremental_state, build_file_semantics, incompatible_change

--[no]incompatible_depset_for_libraries_to_link_getter default: "true"

इस विकल्प को सही पर सेट करने पर, Bazel, linking_context.libraries_to_link से सूची नहीं दिखाता है. इसके बजाय, यह एक depset दिखाता है.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disable_autoloads_in_main_repo डिफ़ॉल्ट: "false"

यह विकल्प कंट्रोल करता है कि मुख्य रिपॉज़िटरी में, अपने-आप लोड होने वाली फ़ाइलें (इन्हें --incompatible_autoload_externally विकल्प से सेट किया जाता है) चालू हैं या नहीं. इस सुविधा को चालू करने पर, Bazel में पहले से मौजूद नियमों (या अन्य सिंबल) में लोड स्टेटमेंट होने चाहिए. उन्हें जोड़ने के लिए, buildifier का इस्तेमाल करें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disable_objc_library_transition default: "true"

objc_library के कस्टम ट्रांज़िशन को बंद करें और इसके बजाय, टॉप लेवल के टारगेट से इनहेरिट करें (Bazel में कोई कार्रवाई नहीं)
टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_starlark_host_transitions डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो नियम एट्रिब्यूट 'cfg = "host"' सेट नहीं कर सकते. नियमों को इसके बजाय, 'cfg = "exec"' सेट करना चाहिए.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disable_target_default_provider_fields डिफ़ॉल्ट: "false"

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

--[no]incompatible_disable_target_provider_fields डिफ़ॉल्ट: "false"

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

--[no]incompatible_disallow_ctx_resolve_tools default: "true"

अगर इसे 'सही है' पर सेट किया जाता है, तो ctx.resolve_tools API को कॉल करने पर हमेशा गड़बड़ी होती है. इस एपीआई के इस्तेमाल को, ctx.actions.run या ctx.actions.run_shell के लिए, एक्ज़ीक्यूटेबल या टूल आर्ग्युमेंट से बदला जाना चाहिए.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disallow_empty_glob default: "true"

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

--[no]incompatible_disallow_struct_provider_syntax default: "true"

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

--[no]incompatible_enable_deprecated_label_apis default: "true"

अगर यह सेटिंग चालू है, तो हटाए जा चुके कुछ एपीआई (native.repository_name, Label.workspace_name, Label.relative) का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--[no]incompatible_fail_on_unknown_attributes default: "true"

अगर यह सुविधा चालू है, तो उन टारगेट के लिए विज्ञापन नहीं दिखाए जाएंगे जिनके लिए अज्ञात एट्रिब्यूट की वैल्यू 'कोई नहीं' पर सेट है.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_fix_package_group_reporoot_syntax default: "true"

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

--[no]incompatible_java_common_parameters default: "true"

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

--[no]incompatible_locations_prefers_executable default: "true"

अगर फ़ाइलों की संख्या एक से ज़्यादा है, तो क्या एक्ज़ीक्यूटेबल फ़ाइल देने वाला टारगेट, $(locations ...) एक्सपैंशन के तहत <code>DefaultInfo.files</code&gt> में मौजूद फ़ाइलों के बजाय एक्ज़ीक्यूटेबल फ़ाइल में बदल जाता है.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_merge_fixed_and_default_shell_env default: "true"

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

--[no]incompatible_no_attr_license default: "true"

इस वैल्यू को सही पर सेट करने से, `attr.license` फ़ंक्शन बंद हो जाता है.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_no_implicit_file_export डिफ़ॉल्ट: "false"

अगर इसे सेट किया जाता है, तो इस्तेमाल की गई सोर्स फ़ाइलें पैकेज के लिए निजी होती हैं. हालांकि, इन्हें साफ़ तौर पर एक्सपोर्ट किया जा सकता है. https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-24-file-visibility.md पर जाएं
टैग: build_file_semantics, incompatible_change

--[no]incompatible_no_implicit_watch_label default: "true"

अगर यह वैल्यू सही है, तो <code>repository_ctx</code> पर मौजूद ऐसे तरीके जो लेबल पास करते हैं वे उस लेबल के तहत मौजूद फ़ाइल में होने वाले बदलावों को अपने-आप ट्रैक नहीं करेंगे. भले ही, <code>watch = "no"</code> हो. साथ ही, <code>repository_ctx.path</code> की वजह से, अब लौटाए गए पाथ को ट्रैक नहीं किया जाएगा. इसके बजाय, <code>repository_ctx.watch</code> का इस्तेमाल करें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_no_rule_outputs_param डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो यह `rule()` Starlark फ़ंक्शन के `outputs` पैरामीटर को बंद कर देता है.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_package_group_has_public_syntax default: "true"

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

--[no]incompatible_require_linker_input_cc_api default: "true"

अगर इसे सही पर सेट किया जाता है, तो create_linking_context नियम के लिए, libraries_to_link के बजाय linker_inputs की ज़रूरत होगी. linking_context के पुराने गेटर भी बंद हो जाएंगे. सिर्फ़ linker_inputs उपलब्ध होंगे.
टैग: build_file_semantics, loading_and_analysis, incompatible_change

--[no]incompatible_resolve_select_keys_eagerly डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो .bzl फ़ाइलों में select() को पास की गई डिक्शनरी में मौजूद स्ट्रिंग कुंजियों को, फ़ाइल के हिसाब से लेबल में तुरंत बदल दिया जाता है. इसके बजाय, उन्हें BUILD फ़ाइल के हिसाब से इंटरप्रेट किया जाता है जिससे वे आखिर में लोड होती हैं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_run_shell_command_string default: "true"

अगर इसे सही पर सेट किया जाता है, तो actions.run_shell के कमांड पैरामीटर में सिर्फ़ स्ट्रिंग स्वीकार की जाएगी
टैग: build_file_semantics, incompatible_change

--[no]incompatible_simplify_unconditional_selects_in_rule_attrs default: "true"

अगर यह वैल्यू सही है, तो कॉन्फ़िगर किए जा सकने वाले नियम एट्रिब्यूट को आसान बनाएं. इनमें सिर्फ़ बिना शर्त वाले विकल्प शामिल होते हैं. उदाहरण के लिए, अगर किसी नियम एट्रिब्यूट को ["a"] + select("//conditions:default", ["b"]) असाइन किया जाता है, तो इसे ["a", "b"] के तौर पर सेव किया जाता है. इस विकल्प से, सिंबॉलिक मैक्रो या एट्रिब्यूट की डिफ़ॉल्ट वैल्यू के एट्रिब्यूट पर कोई असर नहीं पड़ता.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_stop_exporting_build_file_path डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो ctx.build_file_path उपलब्ध नहीं होगा. इसके बजाय, ctx.label.package + '/BUILD' का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_stop_exporting_language_modules डिफ़ॉल्ट: "false"

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

--[no]incompatible_top_level_aspects_require_providers default: "true"

इस एट्रिब्यूट की वैल्यू 'सही है' पर सेट होने पर, टॉप लेवल का आसपेक्ट, सेवा देने वाली ज़रूरी कंपनियों के साथ काम करेगा. साथ ही, यह सिर्फ़ उन टॉप लेवल के टारगेट पर काम करेगा जिनके नियमों में, सेवा देने वाली ज़रूरी कंपनियों के विज्ञापन दिखाए गए हैं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_unambiguous_label_stringification default: "true"

'सही' होने पर, Bazel, @//foo:bar लेबल को //foo:bar के बजाय @//foo:bar में बदल देगा. इससे सिर्फ़ str(), % ऑपरेटर वगैरह के व्यवहार पर असर पड़ता है. repr() के व्यवहार में कोई बदलाव नहीं होता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15916 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_use_cc_configure_from_rules_cc डिफ़ॉल्ट: "false"

इस विकल्प को सही पर सेट करने पर, Bazel, @bazel_tools से cc_configure का इस्तेमाल करने की अनुमति नहीं देगा. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, कृपया https://github.com/bazelbuild/bazel/issues/10134 देखें.
टैग: loading_and_analysis, incompatible_change

--max_computation_steps=<a long integer> default: "0"

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

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

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

--repositories_without_autoloads=<comma-separated set of options> default: ""

अतिरिक्त रिपॉज़िटरी की सूची (Bazel को पहले से पता है कि किन रिपॉज़िटरी में ऑटोलोड नहीं जोड़े जाने हैं). इसमें आम तौर पर ऐसी रिपॉज़िटरी शामिल होनी चाहिए जिन पर ऐसी रिपॉज़िटरी निर्भर करती है जो अपने-आप लोड हो सकती है. इसलिए, इससे साइकल बन सकता है.
टैग: loses_incremental_state, build_file_semantics, incompatible_change

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

--allow_yanked_versions=<a string> कई बार इस्तेमाल किया गया हो

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

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

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

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

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

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

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

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

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

--module_mirrors=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो

इस विकल्प का इस्तेमाल करके, उन यूआरएल के बारे में बताया जाता है जहां Bazel मॉड्यूल के सोर्स यूआरएल मिल सकते हैं. ये यूआरएल, रजिस्ट्री से मिले मिरर यूआरएल के अलावा होते हैं और इन्हें प्राथमिकता दी जाती है. इस फ़्लैग को हर रजिस्ट्री के लिए सेट किया जा सकता है. इसके लिए, इस सिंटैक्स का इस्तेमाल करें: `--module_mirrors=<registry>=<mirror1>[,<mirror2>,...]` (उदाहरण के लिए, `--module_mirrors=https://bcr.bazel.build=https://mirror.example.com`). इसे मिरर यूआरएल की कॉमा लगाकर अलग की गई सूची के तौर पर भी सेट किया जा सकता है. यह सूची उन सभी रजिस्ट्री पर लागू होती है जिनके पास कोई सूची नहीं है (उदाहरण के लिए, `--module_mirrors=https://mirror1,https://mirror2`). रजिस्ट्री से तय किए गए मिरर के अलावा किसी अन्य मिरर का इस्तेमाल बंद करने के लिए, इसे खाली वैल्यू पर सेट करें. इस फ़्लैग का बाद में इस्तेमाल करने पर, पहले इस्तेमाल किए गए फ़्लैग की सेटिंग बदल जाती है. ऐसा तब होता है, जब दोनों फ़्लैग के लिए एक ही रजिस्ट्री का इस्तेमाल किया गया हो या किसी भी रजिस्ट्री का इस्तेमाल न किया गया हो. समय के साथ, मिरर के डिफ़ॉल्ट सेट में बदलाव हो सकता है. हालांकि, मिरर से किए गए सभी डाउनलोड की पुष्टि, रजिस्ट्री में सेव किए गए हैश से की जाती है. इसलिए, इन्हें लॉकफ़ाइल से पिन किया जाता है.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> कई बार इस्तेमाल किया गया हो

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

--registry=<a string> कई बार इस्तेमाल किया गया हो

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

--vendor_dir=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> default: "1s:2,20s:3,1m:5"

ये सीमाएं तय करती हैं कि अगर ये सीमाएं पूरी हो जाती हैं, तो GcThrashingDetector, Bazel को OOM के साथ क्रैश कर देगा. हर सीमा को <period>:<count> के तौर पर तय किया जाता है. इसमें अवधि, समयावधि होती है और गिनती, पॉज़िटिव पूर्णांक होता है. अगर <period> में लगातार <count> बार फ़ुल जीसी होने के बाद भी, पुराने जनरेशन के हीप का --gc_thrashing_threshold प्रतिशत से ज़्यादा हिस्सा इस्तेमाल किया जाता है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--[no]heuristically_drop_nodes डिफ़ॉल्ट: "false"

अगर यह सही है, तो Blaze, FileState और DirectoryListingState नोड को हटा देगा. ऐसा, फ़ाइल और DirectoryListing नोड के पूरा होने के बाद किया जाएगा, ताकि मेमोरी को बचाया जा सके. हमें उम्मीद है कि इन नोड की ज़रूरत दोबारा नहीं पड़ेगी. अगर ऐसा होता है, तो प्रोग्राम उनकी फिर से समीक्षा करेगा.
टैग: loses_incremental_state

--[no]incompatible_do_not_split_linking_cmdline default: "true"

इस विकल्प को सही पर सेट करने पर, Bazel लिंकिंग के लिए इस्तेमाल किए गए कमांड लाइन फ़्लैग में बदलाव नहीं करता. साथ ही, यह भी तय नहीं करता कि कौनसे फ़्लैग पैरामीटर फ़ाइल में जाएंगे और कौनसे नहीं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7670 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]keep_state_after_build default: "true"

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

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

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

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

Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट वैल्यू 10 होती है. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं किया जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> default: "85"

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

--[no]track_incremental_state default: "true"

अगर यह वैल्यू false पर सेट है, तो Blaze ऐसे डेटा को सेव नहीं करेगा जिससे इंक्रीमेंटल बिल्ड पर अमान्य होने और फिर से आकलन करने की अनुमति मिलती है. ऐसा इसलिए किया जाता है, ताकि इस बिल्ड पर मेमोरी सेव की जा सके. इसके बाद के बिल्ड में, इस बिल्ड के मुकाबले कोई बढ़ोतरी नहीं होगी. आम तौर पर, इस विकल्प को false पर सेट करते समय --batch को सेट करना होता है.
टैग: loses_incremental_state

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

--[no]announce_rc डिफ़ॉल्ट: "false"

rc विकल्पों के बारे में सूचना देनी है या नहीं.
टैग: affects_outputs

--[no]attempt_to_print_relative_paths डिफ़ॉल्ट: "false"

मैसेज के लोकेशन वाले हिस्से को प्रिंट करते समय, वर्कस्पेस डायरेक्ट्री या --package_path से तय की गई डायरेक्ट्री में से किसी एक के हिसाब से पाथ का इस्तेमाल करने की कोशिश करें.
टैग: terminal_output

--bes_backend=<a string> default: ""

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

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

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

--bes_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--bes_instance_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--bes_keywords=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

यह सूचना वाले कीवर्ड की एक सूची तय करता है. इन कीवर्ड को BES में पब्लिश किए गए कीवर्ड के डिफ़ॉल्ट सेट में जोड़ा जाता है ("command_name=<command_name> ", "protocol_name=BEP"). डिफ़ॉल्ट रूप से, इसकी वैल्यू 'कोई नहीं' होती है.
टैग: affects_outputs

--[no]bes_lifecycle_events default: "true"

इससे पता चलता है कि BES के लाइफ़साइकल इवेंट पब्लिश करने हैं या नहीं. (डिफ़ॉल्ट रूप से 'true' पर सेट होता है).
टैग: affects_outputs

--bes_oom_finish_upload_timeout=<An immutable length of time.> default: "10m"

इससे यह तय होता है कि Bazel को BES/BEP अपलोड होने का कितना समय तक इंतज़ार करना चाहिए. यह फ़्लैग यह पक्का करता है कि जब JVM में GC थ्रैशिंग की समस्या हो और वह किसी भी उपयोगकर्ता थ्रेड पर काम न कर पाए, तो उसे बंद कर दिया जाए.
टैग: bazel_monitoring

--bes_outerr_buffer_size=<an integer> default: "10240"

यह BEP में stdout या stderr के ज़्यादा से ज़्यादा साइज़ के बारे में बताता है. इस साइज़ तक पहुंचने के बाद, इसे प्रोग्रेस इवेंट के तौर पर रिपोर्ट किया जाता है. अलग-अलग राइट अब भी एक ही इवेंट में रिपोर्ट किए जाते हैं. भले ही, वे --bes_outerr_chunk_size तक तय की गई वैल्यू से ज़्यादा हों.
टैग: affects_outputs

--bes_outerr_chunk_size=<an integer> default: "1048576"

इस विकल्प से, stdout या stderr का ज़्यादा से ज़्यादा साइज़ तय किया जाता है. यह साइज़, बीईपी को भेजे जाने वाले एक मैसेज के लिए होता है.
टैग: affects_outputs

--bes_proxy=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--bes_results_url=<a string> default: ""

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

--bes_system_keywords=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

यह सूचना से जुड़े कीवर्ड की एक सूची तय करता है. इसमें कीवर्ड को सीधे तौर पर शामिल किया जाता है. --bes_keywords के ज़रिए दिए गए कीवर्ड के लिए, "user_keyword=" प्रीफ़िक्स शामिल नहीं किया जाता. यह बिल्ड सेवा के उन ऑपरेटर के लिए है जो --bes_lifecycle_events=false सेट करते हैं और PublishLifecycleEvent को कॉल करते समय कीवर्ड शामिल करते हैं. इस फ़्लैग का इस्तेमाल करके सेवा बनाने वाले ऑपरेटर को, उपयोगकर्ताओं को फ़्लैग की वैल्यू बदलने से रोकना चाहिए.
टैग: affects_outputs

--bes_timeout=<An immutable length of time.> default: "0s"

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

--bes_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> default: "wait_for_upload_complete"

इससे यह तय होता है कि Build Event Service के अपलोड की वजह से, बिल्ड पूरा होने में रुकावट आनी चाहिए या इसे तुरंत बंद कर देना चाहिए और बैकग्राउंड में अपलोड पूरा करना चाहिए. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit

--build_event_binary_file=<a string> default: ""

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

--[no]build_event_binary_file_path_conversion default: "true"

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

--build_event_binary_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> default: "wait_for_upload_complete"

इससे यह तय होता है कि --build_event_binary_file के लिए, Build Event Service का अपलोड, बिल्ड पूरा होने में रुकावट डालेगा या इनवोकेशन को तुरंत खत्म कर देगा और बैकग्राउंड में अपलोड पूरा करेगा. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit

--build_event_json_file=<a string> default: ""

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

--[no]build_event_json_file_path_conversion default: "true"

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

--build_event_json_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> default: "wait_for_upload_complete"

इससे यह तय होता है कि --build_event_json_file के लिए, Build Event Service का अपलोड, बिल्ड पूरा होने पर ब्लॉक होना चाहिए या तुरंत इनवोकेशन बंद कर देना चाहिए और बैकग्राउंड में अपलोड पूरा करना चाहिए. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit

--build_event_max_named_set_of_file_entries=<an integer> default: "5000"

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

--[no]build_event_publish_all_actions डिफ़ॉल्ट: "false"

क्या सभी कार्रवाइयों को पब्लिश किया जाना चाहिए.
टैग: affects_outputs

--build_event_text_file=<a string> default: ""

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

--[no]build_event_text_file_path_conversion default: "true"

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

--build_event_text_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> default: "wait_for_upload_complete"

इससे यह तय होता है कि --build_event_text_file के लिए, Build Event Service का अपलोड, बिल्ड पूरा होने पर ब्लॉक होना चाहिए या तुरंत इनवॉकेशन खत्म होना चाहिए और बैकग्राउंड में अपलोड पूरा होना चाहिए. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'fully_async' में से कोई एक.
टैग: eagerness_to_exit

--build_event_upload_max_retries=<an integer> default: "4"

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

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

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

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

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

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

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

--experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both> कई बार इस्तेमाल किया गया हो

यह तय करें कि TargetComplete/AspectComplete BEP इवेंट में, आउटपुट ग्रुप की फ़ाइलें कैसे दिखाई जाएंगी. वैल्यू, आउटपुट ग्रुप के नाम को 'NAMED_SET_OF_FILES_ONLY', 'INLINE_ONLY' या 'BOTH' में से किसी एक को असाइन की जाती हैं. डिफ़ॉल्ट वैल्यू 'NAMED_SET_OF_FILES_ONLY' होती है. अगर किसी आउटपुट ग्रुप को दोहराया जाता है, तो दिखने वाली फ़ाइनल वैल्यू का इस्तेमाल किया जाता है. डिफ़ॉल्ट वैल्यू, कवरेज आर्टफ़ैक्ट के लिए मोड को BOTH पर सेट करती है: --experimental_build_event_output_group_mode=baseline.lcov=both
टैग: affects_outputs

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> default: "1s"

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

--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--[no]experimental_collect_load_average_in_profiler default: "true"

इस विकल्प के चालू होने पर, प्रोफ़ाइलर सिस्टम के कुल लोड का औसत इकट्ठा करता है.
टैग: bazel_monitoring

--[no]experimental_collect_pressure_stall_indicators डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो प्रोफ़ाइलर, Linux PSI डेटा इकट्ठा करता है.
टैग: bazel_monitoring

--[no]experimental_collect_resource_estimation डिफ़ॉल्ट: "false"

अगर यह सेटिंग चालू है, तो प्रोफ़ाइलर, स्थानीय कार्रवाइयों के लिए सीपीयू और मेमोरी के इस्तेमाल का अनुमान इकट्ठा करता है.
टैग: bazel_monitoring

--[no]experimental_collect_skyframe_counts_in_profiler डिफ़ॉल्ट: "false"

इस सुविधा के चालू होने पर, प्रोफ़ाइलर, Skyframe ग्राफ़ में समय के साथ SkyFunction की संख्या इकट्ठा करता है. यह संख्या, मुख्य फ़ंक्शन टाइप के लिए होती है. जैसे, कॉन्फ़िगर किए गए टारगेट और कार्रवाइयों को पूरा करना. इससे परफ़ॉर्मेंस पर असर पड़ सकता है, क्योंकि यह हर प्रोफ़ाइलिंग टाइम यूनिट पर पूरे Skyframe ग्राफ़ पर जाता है. परफ़ॉर्मेंस के लिए ज़रूरी मेज़रमेंट के साथ इस फ़्लैग का इस्तेमाल न करें.
टैग: bazel_monitoring

--[no]experimental_collect_system_network_usage default: "true"

अगर यह सुविधा चालू है, तो प्रोफ़ाइलर सिस्टम के नेटवर्क के इस्तेमाल की जानकारी इकट्ठा करता है.
टैग: bazel_monitoring

--[no]experimental_collect_worker_data_in_profiler डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो प्रोफ़ाइलर, वर्कर के संसाधन का इकट्ठा किया गया डेटा इकट्ठा करता है.
टैग: bazel_monitoring

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: ब्यौरा देखें

यह कुकी, कमांड की अवधि के लिए Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करती है. प्रोफ़ाइलिंग के लिए इस्तेमाल किए जा सकने वाले इवेंट टाइप (cpu, wall, alloc या lock) में से किसी एक को आर्ग्युमेंट के तौर पर दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम वाली फ़ाइल में लिखा जाता है. ज़्यादा प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, आने वाले समय में इस फ़्लैग के सिंटैक्स और सिमैंटिक में बदलाव किया जा सकता है. इसलिए, इसका इस्तेमाल अपने जोखिम पर करें.

--experimental_profile_additional_tasks=<phase, action, discover_inputs, action_check, action_lock, action_update, action_complete, action_rewinding, bzlmod, info, create_package, remote_execution, local_execution, scanner, local_parse, upload_time, remote_process_time, remote_queue, remote_setup, fetch, local_process_time, vfs_stat, vfs_dir, vfs_readlink, vfs_md5, vfs_xattr, vfs_delete, vfs_open, vfs_read, vfs_write, vfs_glob, vfs_vmfs_stat, vfs_vmfs_dir, vfs_vmfs_read, wait, thread_name, thread_sort_index, skyframe_eval, skyfunction, critical_path, critical_path_component, handle_gc_notification, local_action_counts, starlark_parser, starlark_user_fn, starlark_builtin_fn, starlark_user_compiled_fn, starlark_repository_fn, starlark_thread_context, action_fs_staging, remote_cache_check, remote_download, remote_network, filesystem_traversal, worker_execution, worker_setup, worker_borrow, worker_working, worker_copying_outputs, credential_helper, conflict_check, dynamic_lock, repository_fetch, repository_vendor, repo_cache_gc_wait, spawn_log, wasm_load, wasm_exec or unknown> कई बार इस्तेमाल किया गया हो

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

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

इसमें कार्रवाई वाले इवेंट में "out" एट्रिब्यूट शामिल होता है. इसमें कार्रवाई के मुख्य आउटपुट का एक्ज़ेक पाथ होता है.
टैग: bazel_monitoring

--[no]experimental_profile_include_target_configuration डिफ़ॉल्ट: "false"

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

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

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

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

यह BEP ActionSummary और BuildGraphMetrics के आउटपुट को कंट्रोल करता है. साथ ही, ActionData में मौजूद निमोनिक की संख्या और BuildGraphMetrics.AspectCount/RuleClassCount में रिपोर्ट की गई एंट्री की संख्या को सीमित करता है. डिफ़ॉल्ट रूप से, टाइप की संख्या को टॉप 20 तक सीमित किया जाता है. यह संख्या, ActionData के लिए की गई कार्रवाइयों की संख्या और RuleClass और Asepcts के लिए इंस्टेंस की संख्या के हिसाब से तय की जाती है. इस विकल्प को सेट करने पर, सभी निमोनिक, नियम क्लास, और पहलुओं के लिए आंकड़े लिखे जाएंगे.

--[no]experimental_record_skyframe_metrics डिफ़ॉल्ट: "false"

यह फ़्लैग, BEP BuildGraphMetrics के आउटपुट को कंट्रोल करता है. इसमें Skykeys, RuleClasses, और Aspects के बारे में Skyframe मेट्रिक को कंप्यूट करने में लगने वाला समय शामिल है. इस फ़्लैग को फ़ॉल्स पर सेट करने पर, BEP में BuildGraphMetrics.rule_count और aspectfields नहीं भरे जाएंगे.

--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "false"

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

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

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

--experimental_workspace_rules_log_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

--[no]generate_json_trace_profile default: "auto"

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

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

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

--jvm_heap_histogram_internal_object_pattern=<a valid Java regular expression> डिफ़ॉल्ट: "jdk\.internal\.vm\.Filler.+"

JDK21+ JVM हीप मेमोरी कलेक्शन के लिए, मैचिंग लॉजिक को बदलने वाला रेगुलर एक्सप्रेशन. हम मेमोरी के इस्तेमाल से जुड़ी सटीक मेट्रिक पाने के लिए, G1 GC के इंटरनल इंप्लीमेंटेशन की ऐसी जानकारी पर भरोसा कर रहे हैं जो समय के साथ बदलती रहती है. इस विकल्प की मदद से, हम इंटरनल इंप्लीमेंटेशन में होने वाले बदलावों के हिसाब से खुद को ढाल सकते हैं. इसके लिए, हमें बाइनरी रिलीज़ का इंतज़ार नहीं करना पड़ता. Passed to JDK Matcher.find()

--[no]legacy_important_outputs डिफ़ॉल्ट: "false"

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

--logging=<0 <= an integer <= 6> default: "3"

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

--memory_profile=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

--memory_profile_stable_heap_parameters=<integers, separated by a comma expected in pairs> default: "1,0"

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

--profile=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

--[no]record_full_profiler_data डिफ़ॉल्ट: "false"

डिफ़ॉल्ट रूप से, Bazel प्रोफ़ाइलर सिर्फ़ एग्रीगेट किया गया डेटा रिकॉर्ड करेगा. यह डेटा, तेज़ी से होने वाले कई इवेंट (जैसे, फ़ाइल की स्थिति) के लिए होता है. इस विकल्प के चालू होने पर, प्रोफ़ाइलर हर इवेंट को रिकॉर्ड करेगा. इससे प्रोफ़ाइलिंग का ज़्यादा सटीक डेटा मिलेगा, लेकिन परफ़ॉर्मेंस पर काफ़ी असर पड़ेगा. इस विकल्प का असर सिर्फ़ तब होता है, जब --profile का भी इस्तेमाल किया गया हो.
टैग: bazel_monitoring

--[no]redirect_local_instrumentation_output_writes डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है और इसे इस्तेमाल किया जा सकता है, तो इंस्ट्रुमेंटेशन आउटपुट को उस मशीन पर स्थानीय तौर पर लिखा जाता है जिस पर Bazel चल रहा है.
टैग: bazel_monitoring

--remote_print_execution_messages=<failure, success or all> default: "failure"

रिमोट एक्ज़ीक्यूशन के मैसेज प्रिंट करने की फ़्रीक्वेंसी चुनें. मान्य वैल्यू ये हैं: `failure` का इस्तेमाल सिर्फ़ उन टेस्ट के लिए किया जाता है जो पास नहीं हुए हैं, `success` का इस्तेमाल सिर्फ़ उन टेस्ट के लिए किया जाता है जो पास हो गए हैं, और `all` का इस्तेमाल हमेशा किया जाता है.
टैग: terminal_output

--[no]slim_profile default: "true"

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

--starlark_cpu_profile=<a string> default: ""

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

--tool_tag=<a string> default: ""

इस Bazel इनवोकेशन को एट्रिब्यूट करने के लिए टूल का नाम.
टैग: affects_outputs, bazel_monitoring

--ui_event_filters=<Convert list of comma separated event kind to list of filters> कई बार इस्तेमाल किया गया हो

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

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

--experimental_resolved_file_instead_of_workspace=<a string> default: ""

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

रिमोट कैशिंग और एक्ज़ीक्यूशन के विकल्प:

--downloader_config=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: ब्यौरा देखें

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

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

zstd का इस्तेमाल करके कंप्रेस/डीकंप्रेस करने के लिए, कम से कम ब्लोब साइज़ ज़रूरी है. जब तक --remote_cache_compression सेट नहीं किया जाता, तब तक यह विकल्प काम नहीं करता.

--[no]experimental_remote_cache_lease_extension डिफ़ॉल्ट: "false"

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

--experimental_remote_cache_ttl=<An immutable length of time.> default: "3h"

डाइजेस्ट का हाल ही में रेफ़रंस दिए जाने के बाद, रिमोट कैश में मौजूद ब्लॉब का कम से कम टीटीएल. उदाहरण के लिए, ActionResult या FindMissingBlobs. Bazel, ब्लॉब के टीटीएल के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, इंक्रीमेंटल बिल्ड में GetActionResult को बार-बार कॉल नहीं करता है. वैल्यू को असली टीटीएल से थोड़ा कम सेट किया जाना चाहिए, क्योंकि सर्वर के डाइजेस्ट वापस भेजने और Bazel के उन्हें पाने के बीच कुछ समय लगता है.
टैग: execution

--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: ब्यौरा देखें

यह उस डायरेक्ट्री का पाथ है जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.

--[no]experimental_remote_discard_merkle_trees default: "true"

अगर इसे सही पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़े इनपुट मैपिंग की इन-मेमोरी कॉपी को खारिज कर दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में मौजूद न होने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कंप्यूट करना होगा.

--experimental_remote_downloader=<a string> डिफ़ॉल्ट: ब्यौरा देखें

रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाना है. grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. इस लिंक पर जानकारी पाएं: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

--[no]experimental_remote_downloader_local_fallback डिफ़ॉल्ट: "false"

अगर रिमोट डाउनलोडर काम नहीं करता है, तो लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.

--[no]experimental_remote_downloader_propagate_credentials डिफ़ॉल्ट: "false"

netrc और क्रेडेंशियल हेल्पर से रिमोट डाउनलोडर सर्वर को क्रेडेंशियल भेजने हैं या नहीं. सर्वर के लिए, `http_header_url:<url-index>:<header-key>` क्वालिफ़ायर का इस्तेमाल करना ज़रूरी है. इसमें `<url-index>`, FetchBlobRequest के `uris` फ़ील्ड में मौजूद यूआरएल की 0 पर आधारित पोज़िशन होती है. यूआरएल के हिसाब से तय किए गए हेडर को ग्लोबल हेडर से ज़्यादा प्राथमिकता दी जानी चाहिए.

--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "false"

रिमोट तरीके से एक्ज़ीक्यूट करने के लिए, कीपअलाइव का इस्तेमाल करना है या नहीं.

--experimental_remote_failure_rate_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "10"

यह विकल्प, किसी समयावधि के लिए, फ़ेल होने की दर को प्रतिशत में सेट करता है. इसके बाद, यह रिमोट कैश/एक्ज़ीक्यूटर को कॉल करना बंद कर देता है. डिफ़ॉल्ट रूप से इसकी वैल्यू 10 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
टैग: execution

--experimental_remote_failure_window_interval=<An immutable length of time.> default: "60s"

वह समयावधि जिसमें रिमोट अनुरोधों के फ़ेल होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, फ़ेल होने की अवधि को पूरे एक्ज़ीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution

--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर्सिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.

--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "false"

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

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

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

--experimental_remote_output_service=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--experimental_remote_output_service_output_path_prefix=<a string> default: ""

यह वह पाथ है जिसके तहत, --experimental_remote_output_service से मैनेज की गई आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. बिल्ड के लिए इस्तेमाल की जाने वाली आउटपुट डायरेक्ट्री, इस पाथ की डिसेंडेंट होगी. साथ ही, इसे आउटपुट सेवा तय करेगी.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "false"

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

--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: ब्यौरा देखें

यह विकल्प, दी गई कॉन्फ़िगरेशन फ़ाइल की मदद से रिमोट कैश मेमोरी की कुंजी को मिटाने की सुविधा चालू करता है. यह फ़ाइल, टेक्स्ट फ़ॉर्मैट में प्रोटोकॉल बफ़र होनी चाहिए. इसके बारे में ज़्यादा जानने के लिए, src/main/protobuf/remote_scrubbing.proto देखें. इस सुविधा का मकसद, अलग-अलग प्लैटफ़ॉर्म पर एक्ज़ीक्यूट की जा रही कार्रवाइयों के बीच रिमोट/डिस्क कैश मेमोरी को शेयर करना है. हालांकि, ये कार्रवाइयां एक ही प्लैटफ़ॉर्म को टारगेट करती हैं. इसका इस्तेमाल बहुत सावधानी से करना चाहिए, क्योंकि गलत सेटिंग की वजह से कैश मेमोरी की एंट्री अनजाने में शेयर हो सकती हैं. इससे गलत बिल्ड बन सकते हैं. स्क्रबिंग से, कार्रवाई के तरीके पर कोई असर नहीं पड़ता. इससे सिर्फ़ यह तय होता है कि कार्रवाई के नतीजे को वापस पाने या सेव करने के लिए, रिमोट/डिस्क कैश मेमोरी की कुंजी की गिनती कैसे की जाती है. स्क्रब की गई कार्रवाइयां, रिमोट एक्ज़ीक्यूशन के साथ काम नहीं करती हैं. इसलिए, इन्हें हमेशा स्थानीय तौर पर ही एक्ज़ीक्यूट किया जाएगा. स्क्रबिंग के कॉन्फ़िगरेशन में बदलाव करने से, लोकल फ़ाइल सिस्टम या इंटरनल कैश मेमोरी में मौजूद आउटपुट अमान्य नहीं होते. जिन कार्रवाइयों पर असर पड़ा है उन्हें फिर से लागू करने के लिए, क्लीन बिल्ड की ज़रूरत होती है. इस सुविधा का इस्तेमाल करने के लिए, आपको --host_platform को --experimental_platform_in_output_dir (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --incompatible_strict_action_env (एनवायरमेंट वैरिएबल को सामान्य बनाने के लिए) के साथ सेट करना होगा.

--experimental_worker_for_repo_fetching=<off, platform, virtual or auto> default: "auto"

Repo फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. 'बंद है' पर सेट होने पर, किसी भी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. साथ ही, रीपो फ़ेच करने की प्रोसेस को फिर से शुरू किया जा सकता है. ऐसा न होने पर, वर्चुअल वर्कर थ्रेड का इस्तेमाल करता है.

--[no]guard_against_concurrent_changes default: "lite"

इसे 'full' पर सेट करें, ताकि रिमोट कैश में अपलोड करने से पहले, किसी कार्रवाई की सभी इनपुट फ़ाइलों के ctime की जांच की जा सके. ऐसा हो सकता है कि कुछ मामलों में Linux कर्नल, फ़ाइलों को लिखने में देरी करे. इससे फ़ॉल्स पॉज़िटिव मिल सकते हैं. डिफ़ॉल्ट रूप से, यह 'lite' पर सेट होता है. यह सिर्फ़ मुख्य रिपॉज़िटरी में मौजूद सोर्स फ़ाइलों की जांच करता है. इसे 'बंद है' पर सेट करने से, सभी जांच बंद हो जाती हैं. हमारा सुझाव है कि ऐसा न करें. ऐसा इसलिए, क्योंकि जब किसी सोर्स फ़ाइल में बदलाव किया जाता है, तब हो सकता है कि कैश मेमोरी में मौजूद डेटा खराब हो जाए. ऐसा तब होता है, जब कोई ऐसी कार्रवाई चल रही हो जिसमें उस फ़ाइल का इस्तेमाल इनपुट के तौर पर किया जा रहा हो.
टैग: execution

--[no]incompatible_remote_local_fallback_for_remote_cache डिफ़ॉल्ट: "false"

Whether --remote_local_fallback applies to --remote_cache.

--[no]remote_accept_cached default: "true"

रिमोटली कैश मेमोरी में सेव किए गए ऐक्शन के नतीजों को स्वीकार करना है या नहीं.

--remote_build_event_upload=<all or minimal> default: "minimal"

अगर इसे 'all' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश में अपलोड किए जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो बीईपी से रेफ़र की गई लोकल आउटपुट फ़ाइलों को रिमोट कैश में अपलोड नहीं किया जाता. हालांकि, बीईपी के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों को अपलोड किया जाता है. जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का इस्तेमाल हमेशा किया जाता है. भले ही, वे रिमोट कैश में मौजूद न हों. डिफ़ॉल्ट रूप से 'minimal' पर सेट होता है.

--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

होस्टनेम और इंस्टेंस का नाम, जिसका इस्तेमाल bytestream:// यूआरआई में किया जाना है. ये यूआरआई, बिल्ड इवेंट स्ट्रीम में लिखे जाते हैं. इस विकल्प को तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इससे --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इसे सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.

--remote_cache=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कैशिंग एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. टीएलएस को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://bazel.build/remote/caching देखें

--[no]remote_cache_async default: "true"

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

--[no]remote_cache_compression डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो कैश मेमोरी के बड़े ऑब्जेक्ट को zstd की मदद से कंप्रेस/डिकंप्रेस करें. ऐसा तब करें, जब उनका साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.

--remote_cache_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

कैश मेमोरी के अनुरोधों में शामिल किए जाने वाले हेडर के बारे में बताएं: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.

--remote_default_exec_properties=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

डिफ़ॉल्ट exec प्रॉपर्टी सेट करें, ताकि अगर कोई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो उन्हें रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल किया जा सके.
टैग: affects_outputs

--remote_default_platform_properties=<a string> default: ""

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

--remote_download_regex=<a valid Java regular expression> कई बार इस्तेमाल किया गया हो

इस पैटर्न से मेल खाने वाले पाथ के रिमोट बिल्ड आउटपुट को डाउनलोड करने के लिए मजबूर करें. भले ही, --remote_download_outputs का इस्तेमाल किया गया हो या नहीं. इस फ़्लैग को दोहराकर, कई पैटर्न तय किए जा सकते हैं.
टैग: affects_outputs

--remote_downloader_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--remote_exec_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

ऐसा हेडर तय करें जिसे एक्ज़ीक्यूशन के अनुरोधों में शामिल किया जाएगा: --remote_exec_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.

--remote_execution_priority=<an integer> default: "0"

रिमोट तरीके से की जाने वाली कार्रवाइयों की प्राथमिकता. प्राथमिकता की खास वैल्यू का सिमैंटिक, सर्वर पर निर्भर करता है.

--remote_executor=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--remote_grpc_log=<a path> डिफ़ॉल्ट: ब्यौरा देखें

अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में, क्रम से लगाए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry प्रोटोबफ़ होते हैं. हर मैसेज के पहले एक वैरिएंट होता है, जो क्रम से लगाए गए अगले प्रोटोबफ़ मैसेज के साइज़ को दिखाता है. ऐसा LogEntry.writeDelimitedTo(OutputStream) तरीके से किया जाता है.

--remote_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

ऐसा हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.

--remote_instance_name=<a string> default: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "false"

अगर रिमोट एक्सीक्यूशन काम नहीं करता है, तो क्या स्टैंडअलोन लोकल एक्सीक्यूशन की रणनीति पर वापस जाना है.

--remote_local_fallback_strategy=<a string> default: "local"

अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

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

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

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

रिमोट कैश/एक्ज़ीक्यूटर से एक साथ कनेक्ट किए जा सकने वाले कनेक्शन की ज़्यादा से ज़्यादा संख्या को सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एक्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर 100 से ज़्यादा एक साथ किए गए अनुरोधों को हैंडल कर सकता है. इसे --remote_max_concurrency_per_connection कंट्रोल करता है. इसलिए, Bazel एक साथ `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations

--remote_proxy=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--remote_result_cache_priority=<an integer> default: "0"

रिमोट ऐक्शन की प्राथमिकता, जिसे रिमोट कैश मेमोरी में सेव किया जाना है. प्राथमिकता की खास वैल्यू का सिमैंटिक, सर्वर पर निर्भर करता है.

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

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

--remote_retry_max_delay=<An immutable length of time.> default: "5s"

रीमोट तरीके से फिर से कोशिश करने के बीच ज़्यादा से ज़्यादा बैकऑफ़ डिले. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--remote_timeout=<An immutable length of time.> default: "60s"

रिमोट एक्ज़ीक्यूशन और कैश मेमोरी के कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश के लिए, यह कनेक्ट और रीड, दोनों के लिए टाइम आउट होता है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--[no]remote_upload_local_results default: "true"

अगर रिमोट कैश मेमोरी इस सुविधा के साथ काम करती है और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या स्थानीय तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.

--[no]remote_verify_downloads default: "true"

इस विकल्प को सही पर सेट करने पर, Bazel सभी रिमोट डाउनलोड के हैश का योग कंप्यूट करेगा. साथ ही, अगर रिमोट से कैश की गई वैल्यू, अनुमानित वैल्यू से मेल नहीं खाती हैं, तो उन्हें खारिज कर देगा.

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

--build_metadata=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--color=<yes, no or auto> default: "auto"

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

--config=<a string> कई बार इस्तेमाल किया गया हो

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

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

यह विकल्प, <a href="https://github.com/EngFlow/credential-helper-spec">क्रेडेंशियल हेल्पर स्पेसिफ़िकेशन</a> के मुताबिक क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है. इसका इस्तेमाल, रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी और एक्ज़ीक्यूशन, और बिल्ड इवेंट सेवा के लिए अनुमति वाले क्रेडेंशियल पाने के लिए किया जाता है. सहायता करने वाले व्यक्ति की ओर से दिए गए क्रेडेंशियल को `--google_default_credentials`, `--google_credentials`, `.netrc` फ़ाइल या `repository_ctx.download()` और `repository_ctx.download_and_extract()` के लिए auth पैरामीटर की ओर से दिए गए क्रेडेंशियल से ज़्यादा प्राथमिकता दी जाती है. एक से ज़्यादा हेल्पर सेट अप करने के लिए, इसे कई बार तय किया जा सकता है. निर्देशों के लिए, https://blog.engflow.com/2023/10/09/configuring-bazels-credential-helper/ पर जाएं.

--credential_helper_cache_duration=<An immutable length of time.> default: "30m"

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

--credential_helper_timeout=<An immutable length of time.> default: "10s"

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

--curses=<yes, no or auto> default: "auto"

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

--disk_cache=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

--experimental_disk_cache_gc_idle_delay=<An immutable length of time.> default: "5m"

डिस्क कैश मेमोरी की गार्बेज कलेक्शन की प्रोसेस शुरू होने से पहले, सर्वर को कितने समय तक बंद रहना चाहिए. कचरा इकट्ठा करने की नीति तय करने के लिए, --experimental_disk_cache_gc_max_size और/या --experimental_disk_cache_gc_max_age सेट करें.

--experimental_disk_cache_gc_max_age=<An immutable length of time.> default: "0"

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

--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier> default: "0"

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

--experimental_install_base_gc_max_age=<An immutable length of time.> default: "30d"

इंस्टॉल किए गए ऐप्लिकेशन को कितने समय तक इस्तेमाल न करने पर, उसे ट्रैश में भेजा जा सकता है. अगर यह वैल्यू शून्य नहीं है, तो सर्वर के पास कोई काम न होने पर, वह अन्य इंस्टॉल बेस से गार्बेज इकट्ठा करने की कोशिश करेगा.
टैग: host_machine_resource_optimizations

--[no]experimental_rule_extension_api default: "true"

Enable experimental rule extension API and subrule APIs
Tags: loading_and_analysis, experimental

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

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

--google_auth_scopes=<comma-separated list of options> default: "https://www.googleapis.com/auth/cloud-platform"

Google Cloud की पुष्टि करने के स्कोप की कॉमा लगाकर अलग की गई सूची.

--google_credentials=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इस विकल्प का इस्तेमाल करके, उस फ़ाइल के बारे में बताया जाता है जिससे पुष्टि करने वाले क्रेडेंशियल पाने हैं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं.

--[no]google_default_credentials डिफ़ॉल्ट: "false"

पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं. यह सुविधा डिफ़ॉल्ट रूप से बंद होती है.

--grpc_keepalive_time=<An immutable length of time.> डिफ़ॉल्ट: ब्यौरा देखें

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

--grpc_keepalive_timeout=<An immutable length of time.> default: "20s"

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

--[no]incompatible_disable_non_executable_java_binary डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो java_binary हमेशा एक्ज़ीक्यूटेबल होता है. create_executable एट्रिब्यूट हटा दिया जाता है.
टैग: loading_and_analysis, incompatible_change

--inject_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो

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

--invocation_id=<a UUID> default: ""

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

--override_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो

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

--[no]progress_in_terminal_title डिफ़ॉल्ट: "false"

टर्मिनल के टाइटल में कमांड की प्रोग्रेस दिखाएं. कई टर्मिनल टैब होने पर, यह देखने के लिए उपयोगी है कि Bazel क्या कर रहा है.

--[no]show_progress default: "true"

बिल्ड के दौरान प्रोग्रेस मैसेज दिखाएं.

--show_progress_rate_limit=<a double> default: "0.2"

आउटपुट में प्रोग्रेस मैसेज के बीच कम से कम सेकंड की संख्या.

--[no]show_timestamps डिफ़ॉल्ट: "false"

मैसेज में टाइमस्टैंप शामिल करना

--tls_certificate=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--tls_client_certificate=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इस्तेमाल किए जाने वाले टीएलएस क्लाइंट सर्टिफ़िकेट के बारे में बताएं. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.

--tls_client_key=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इस्तेमाल की जाने वाली टीएलएस क्लाइंट कुंजी के बारे में बताएं. साथ ही, क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.

--ui_actions_shown=<an integer> default: "8"

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

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

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

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

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

--[no]incompatible_use_plus_in_repo_names default: "true"

No-op.
टैग: loading_and_analysis

लॉगिंग के शब्दों की संख्या, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

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

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

Aquery के विकल्प

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

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

--[no]incompatible_use_plus_in_repo_names default: "true"

कोई कार्रवाई नहीं.
टैग: loading_and_analysis

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

--aspect_deps=<off, conservative or precise> default: "conservative"

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

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

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

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "false"

aquery, cquery: whether to include aspect-generated actions in the output. query: no-op (aspects are always followed).
टैग: terminal_output

--[no]graph:factored default: "true"

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

--graph:node_limit=<an integer> default: "512"

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

--[no]implicit_deps default: "true"

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

--[no]include_artifacts default: "true"

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

--[no]include_aspects default: "true"

aquery, cquery: whether to include aspect-generated actions in the output. query: no-op (aspects are always followed).
टैग: terminal_output

--[no]include_commandline default: "true"

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

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

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

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

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

--[no]include_pruned_inputs default: "true"

इसमें कार्रवाई के ऐसे इनपुट शामिल होते हैं जिन्हें कार्रवाई पूरी होने के दौरान हटाया गया था. इससे सिर्फ़ उन कार्रवाइयों पर असर पड़ता है जो इनपुट का पता लगाती हैं और पिछले इनवोकेशन में पूरी हो चुकी हैं. यह विकल्प सिर्फ़ तब काम करता है, जब --include_artifacts भी सेट किया गया हो.
टैग: terminal_output

--[no]incompatible_package_group_includes_double_slash default: "true"

अगर यह विकल्प चालू है, तो package_group एट्रिब्यूट के `packages` एट्रिब्यूट की वैल्यू देते समय, शुरुआती `//` को नहीं हटाया जाएगा.
टैग: terminal_output, incompatible_change

--[no]infer_universe_scope डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और --universe_scope को सेट नहीं किया गया है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि क्वेरी एक्सप्रेशन के लिए अनुमानित --universe_scope वैल्यू, आपकी ज़रूरत के हिसाब से नहीं हो सकती.ऐसा तब होता है, जब क्वेरी एक्सप्रेशन में यूनीवर्सल स्कोप वाले फ़ंक्शन (जैसे, `allrdeps`) का इस्तेमाल किया जाता है.इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करें, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query पर जाएं. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है. इसका मतलब है कि यह `cquery` पर लागू नहीं होता.
टैग: loading_and_analysis

--[no]line_terminator_null डिफ़ॉल्ट: "false"

क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया गया है.
टैग: terminal_output

--[no]nodep_deps default: "true"

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

--output=<a string> default: "text"

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

--output_file=<a string> default: ""

इस विकल्प को चुनने पर, क्वेरी के नतीजे सीधे इस फ़ाइल में लिखे जाएंगे. साथ ही, Bazel के स्टैंडर्ड आउटपुट स्ट्रीम (stdout) में कुछ भी प्रिंट नहीं किया जाएगा. आम तौर पर, बेंचमार्क में यह <code>bazel query &gt; file</code> से ज़्यादा तेज़ होता है.
टैग: terminal_output

--[no]proto:default_values default: "true"

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

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

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

--[no]proto:flatten_selects default: "true"

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

--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "false"

हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, वह सोर्स ऐस्पेक्ट डालें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स ऐस्पेक्ट से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.
टैग: terminal_output

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

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

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

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

--[no]proto:locations default: "true"

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

--proto:output_rule_attrs=<comma-separated list of options> default: "all"

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

--[no]proto:rule_classes डिफ़ॉल्ट: "false"

हर नियम के rule_class_key फ़ील्ड में वैल्यू डालें. साथ ही, दिए गए rule_class_key वाले पहले नियम के लिए, उसके rule_class_info प्रोटो फ़ील्ड में भी वैल्यू डालें. rule_class_key फ़ील्ड, नियम क्लास की खास तौर पर पहचान करता है. साथ ही, rule_class_info फ़ील्ड, Stardoc फ़ॉर्मैट में नियम क्लास की एपीआई डेफ़िनिशन है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs default: "true"

rule_input और rule_output फ़ील्ड में वैल्यू भरनी है या नहीं.
टैग: terminal_output

--query_file=<a string> default: ""

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

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

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

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

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

--[no]tool_deps default: "true"

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

--universe_scope=<comma-separated list of options> default: ""

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

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]experimental_inprocess_symlink_creation default: "true"

सिंबॉलिक लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या हेल्पर प्रोसेस को सौंपना है.
टैग: loading_and_analysis, execution, experimental

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false"

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution, experimental

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false"

अगर यह सही है, तो Bazel, नए स्पॉन में टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग चलाएगा.
टैग: execution, experimental

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false"

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

--[no]incompatible_modify_execution_info_additive डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो

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

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू रखें.
इनके तौर पर दिखता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

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

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. टेस्ट एक्ज़ेक ग्रुप का नहीं.
टैग: execution

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

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android"

android_binary नियमों के लिए, मेनिफ़ेस्ट मर्जर को चुनने का विकल्प. यह फ़्लैग, लेगसी मर्जर से Android मेनिफ़ेस्ट मर्जर पर ट्रांज़िशन करने में मदद करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_platforms=<a build target label> default: ""

यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--apple_crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain"

Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs

--cc_output_directory_tag=<a string> default: ""

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

--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger"

यह उस बाइनरी का पाथ है जिसका इस्तेमाल रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी मौजूद हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:lcov_merger' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए जाने वाले बाइनरी का पाथ. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी मौजूद हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:coverage_report_generator' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support"

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

--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> कई बार इस्तेमाल किया गया हो

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

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "false"

अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution, experimental

--[no]experimental_prefer_mutual_xcode default: "true"

अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए Xcode के लोकल वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state, experimental

--extra_execution_platforms=<comma-separated list of options> default: ""

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

--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

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

--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

यह फ़्लैग कोई कार्रवाई नहीं करता. आने वाले समय में इसे हटा दिया जाएगा.
टैग: loading_and_analysis, execution

--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

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

--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform"

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

--[no]incompatible_bazel_test_exec_run_under डिफ़ॉल्ट: "false"

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

--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true"

अगर यह वैल्यू सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाएं चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false"

ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive default: "true"

अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "false"

अगर यह सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change

--[no]interface_shared_objects default: "true"

अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी 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 main workspace-relative path> default: ""

यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य Workspace रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, सीधे तौर पर वर्कस्पेस रूट में होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable

--platforms=<a build target label> default: ""

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

--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

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

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

--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes"

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

ऐसे विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:

--[no]apple_generate_dsym डिफ़ॉल्ट: "false"

डीबग सिंबल (.dSYM) वाली फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines

--[no]build_runfile_links default: "true"

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

--[no]build_runfile_manifests default: "true"

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

--[no]build_test_dwp डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h"

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

--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc"

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

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "false"

proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "false"

कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental

--fission=<a set of compilation modes> डिफ़ॉल्ट: "no"

इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल कौनसे कंपाइलेशन मोड करते हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.
टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाए गए व्यवहार से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest डिफ़ॉल्ट: "false"

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

--[no]incompatible_filegroup_runfiles_for_data डिफ़ॉल्ट: "false"

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

--[no]legacy_external_runfiles डिफ़ॉल्ट: "false"

अगर यह सही है, तो .runfiles/repo के अलावा, .runfiles/wsname/external/repo में बाहरी रिपॉज़िटरी के लिए, रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs

--[no]objc_generate_linkmap डिफ़ॉल्ट: "false"

यह तय करता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs

--[no]save_temps डिफ़ॉल्ट: "false"

अगर यह विकल्प सेट किया जाता है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

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

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो

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

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs

--[no]android_databinding_use_androidx default: "true"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args default: "true"

3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> default: "off"

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

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical"

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

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

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

--[no]build_python_zip default: "auto"

Build python executable zip; on on Windows, off on other platforms
Tags: affects_outputs

--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

--[no]collect_code_coverage डिफ़ॉल्ट: "false"

अगर ऐसा बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

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

--conlyopt=<a string> कई बार इस्तेमाल किया गया हो

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

--copt=<a string> कई बार इस्तेमाल किया गया हो

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

--cpu=<a string> default: ""

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

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--cxxopt=<a string> कई बार इस्तेमाल किया गया हो

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

--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--dynamic_mode=<off, default or fully> default: "default"

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

--[no]enable_propeller_optimize_absolute_paths default: "true"

अगर यह सेट है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs

--[no]enable_remaining_fdo_absolute_paths default: "true"

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

--[no]enable_runfiles default: "auto"

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

--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो

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

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

एपीके में Java संसाधनों को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 default: "true"

android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "false"

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

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "false"

dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental

--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "false"

अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off, content or strip> default: "off"

आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental

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

अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental

--[no]experimental_py_binaries_include_label डिफ़ॉल्ट: "false"

py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.
टैग: affects_outputs, experimental

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

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

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental

--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है. जैसे, `//foo/bar:file.afdo`. आपको संबंधित पैकेज में `exports_files` डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है. साथ ही, यह `fdo_profile` टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, `fdo_profile` नियम की जगह लागू होगा.
टैग: affects_outputs

--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कैश मेमोरी प्रीफ़ेच करने के लिए, हिंट का इस्तेमाल करें.
टैग: affects_outputs

--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--features=<a string> कई बार इस्तेमाल किया गया हो

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

--[no]force_pic डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय पीआईसी प्री-बिल्ट लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.
टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो

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

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

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

--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों (C++ नहीं) को कंपाइल करते समय, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_copt=<a string> कई बार इस्तेमाल किया गया हो

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

--host_cpu=<a string> default: ""

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

--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

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

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

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

--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो

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

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है. हालांकि, bar.cc में यह विकल्प नहीं जोड़ा जाता.
टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false"

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, exec ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

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

--[no]instrument_test_targets डिफ़ॉल्ट: "false"

कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगेक्स) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ गैर-टेस्ट नियमों को लागू किया जाता है, जब तक कि --instrument_test_targets चालू न हो.
टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

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

--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

--[no]legacy_whole_archive default: "true"

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

--linkopt=<a string> कई बार इस्तेमाल किया गया हो

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

--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ बैकएंड के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple macOS के बाइनरी फ़ाइलें बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.
टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "false"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

--objccopt=<a string> कई बार इस्तेमाल किया गया हो

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

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto). इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों के LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.
टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

--[no]share_native_deps default: "true"

अगर यह वैल्यू सही है, तो एक जैसी फ़ंक्शनैलिटी वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "false"

बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.
टैग: affects_outputs

--stripopt=<a string> कई बार इस्तेमाल किया गया हो

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

--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, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करेगा:

--[no]check_licenses डिफ़ॉल्ट: "false"

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

--[no]check_visibility default: "true"

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

--[no]desugar_for_android default: "true"

Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "false"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 के साथ काम करने वाली लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints default: "true"

यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की डिपेंडेंसी ऐसे एनवायरमेंट के साथ काम नहीं करती हैं जिनके साथ टारगेट काम करता है, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics

--[no]experimental_check_desugar_deps default: "true"

Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental

--experimental_import_deps_checking=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कोई कार्रवाई नहीं की गई. इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है
टैग: loading_and_analysis

--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है"

इसे चालू करने पर, यह लागू किया जाता है कि java_binary नियम में, क्लासपाथ पर एक ही क्लास फ़ाइल का एक से ज़्यादा वर्शन नहीं हो सकता. इस नीति के उल्लंघन की वजह से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.
टैग: loading_and_analysis

--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default"

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

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

अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "false"

इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false"

यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_python_disable_py2 default: "true"

अगर यह वैल्यू 'सही है' पर सेट है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]one_version_enforcement_on_java_tests default: "true"

इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.
टैग: loading_and_analysis

--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

--incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis

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

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

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

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

--strict_public_imports=<off, warn, error, strict or default> default: "off"

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

--[no]strict_system_includes डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही है' पर सेट है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.
टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "environment" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

ऐसे विकल्प जिनसे बिल्ड के हस्ताक्षर करने के आउटपुट पर असर पड़ता है:

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2"

APK पर साइन करने के लिए इस्तेमाल किया जाने वाला तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements default: "true"

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

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

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

--[no]incompatible_disallow_legacy_py_provider default: "true"

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

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "false"

अगर यह सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "false"

जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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

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

If true, an analysis failure of a rule target results in the target's propagation of an instance of AnalysisFailureInfo containing the error description, instead of resulting in a build failure.
टैग: loading_and_analysis, experimental

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

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

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

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

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की रकम को बदल देंगे. वैल्यू, HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]<float> (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4) भी जोड़ा जा सकता है. हालांकि, यह ज़रूरी नहीं है. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में बताए गए संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false"

android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "false"

ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. उदाहरण के लिए, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची पाई जा सकती है.
टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर पर चलाने या टेस्ट करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो

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

--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो

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

--test_timeout=<a single integer or comma-separated list of 4 integers> default: "-1"

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

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "false"

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

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

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false"

ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास को हटाया जा सके.
टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files default: "true"

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलें सीधे रिमोट बिल्ड नोड से मेमोरी में पास की जाएंगी. इन्हें डिस्क में नहीं लिखा जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files default: "true"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly default: "true"

इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए, टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट नहीं किए गए नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू 'गलत है' पर सेट है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "false"

यह विकल्प चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing default: "true"

यह हर जार फ़ाइल के लिए, अलग से डेक्सिंग का ज़्यादातर काम करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning default: "true"

अगर इस फ़्लैग को सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल किया जाएगा. इससे objc कंपाइलर को पास किए गए इनपुट के सेट को कम किया जा सकेगा.
टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "false"

जब टारगेट //a:a बनाया जा रहा हो, तब उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग चालू हो.
टैग: execution

--[no]trim_test_configuration default: "true"

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

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

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*"

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

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

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो

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

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

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

--[no]incompatible_py2_outputs_are_suffixed default: "true"

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

--[no]incompatible_py3_is_default default: "true"

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

--[no]incompatible_use_python_toolchains default: "true"

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

--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

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

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

--[no]cache_test_results [-t] default: "auto"

अगर इसे 'auto' पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Bazel, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है. 'नहीं' पर सेट होने पर, Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.

--[no]experimental_cancel_concurrent_tests default: "never"

अगर 'on_failed' या 'on_passed' विकल्प चुना जाता है, तो Blaze उस नतीजे के साथ पहली बार चलने वाले टेस्ट को रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false"

अगर सही है, तो clang के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_j2objc_header_map default: "true"

J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental

--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "false"

क्या हेडर पाथ को छोटा करके जनरेट करना है. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental

--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "javabuilder"

इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.

--[no]experimental_java_header_compilation_direct_deps डिफ़ॉल्ट: "false"

हेडर और सामान्य कंपाइलेशन के लिए अलग-अलग आउटपुट इस्तेमाल करें.
टैग: experimental

--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं की गई, इसे सिर्फ़ पुराने वर्शन के साथ काम करने के लिए रखा गया है
टैग: affects_outputs, experimental

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

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

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

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

--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो

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

--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो

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

--[no]incompatible_check_sharding_support default: "true"

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

--[no]incompatible_exclusive_test_sandboxed default: "true"

अगर यह वैल्यू सही है, तो सैंडबॉक्स की गई रणनीति के साथ खास टेस्ट चलाए जाएंगे. 'local' टैग जोड़कर, स्थानीय तौर पर सिर्फ़ एक टेस्ट रन करें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है, तो Bazel ऐसे एनवायरमेंट का इस्तेमाल करता है जिसमें PATH के लिए स्टैटिक वैल्यू होती है. साथ ही, यह LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने से, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा. ऐसा तब होगा, जब शेयर की गई कैश मेमोरी का इस्तेमाल किया जा रहा हो.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

--java_debug

इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इनमें बदल जाता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps default: "true"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करें. फ़िलहाल, यह जानकारी कंपाइल-टाइम क्लासपाथ के लिए जनरेट की जाती है.

--[no]java_header_compilation default: "true"

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

--java_language_version=<a string> default: ""

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

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--java_runtime_version=<a string> default: "local_jdk"

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

--javacopt=<a string> कई बार इस्तेमाल किया गया हो

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

--jvmopt=<a string> कई बार इस्तेमाल किया गया हो

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

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह एक बाइनरी तय करता है. इसका इस्तेमाल, उन क्लास की सूची जनरेट करने के लिए किया जाता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह बिना शार्डिंग के डेक्सिंग करने के लिए, बाइनरी तय करता है.

--plugin=<a build target label> कई बार इस्तेमाल किया गया हो

बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

इस विकल्प से यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.

--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis

--[no]proto_profile default: "true"

प्रोफ़ाइल_पाथ को प्रोटो कंपाइलर को पास करना है या नहीं.
टैग: affects_outputs, loading_and_analysis

--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain"

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

--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

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

--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जो बताता है कि Java protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जो बताता है कि JavaLite protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> कई बार इस्तेमाल किया गया हो

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

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

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

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

--test_arg=<a string> कई बार इस्तेमाल किया गया हो

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

--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--test_result_expiration=<an integer> default: "-1"

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

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

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

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit"

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

--tool_java_language_version=<a string> default: ""

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

--tool_java_runtime_version=<a string> default: "remotejdk_11"

The Java runtime version used to execute tools during the build

--[no]use_ijars default: "true"

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

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

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]check_up_to_date डिफ़ॉल्ट: "false"

बिल्ड न करें. बस यह देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड पूरा हो जाता है. अगर किसी चरण को पूरा करने में कोई गड़बड़ी होती है, तो इसकी सूचना दी जाती है और बिल्ड पूरा नहीं हो पाता.
टैग: execution

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

अगर बिल्ड के दौरान कम से कम एक बार रिमोट एक्ज़ीक्यूशन तेज़ था, तो लोकल एक्ज़ीक्यूशन को कितने मिलीसेकंड तक डिले किया जाना चाहिए?
टैग: execution, host_machine_resource_optimizations

--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो

दिए गए नेमोनिक के लिए, क्रम से स्थानीय रणनीतियां इस्तेमाल की जाती हैं. सबसे पहले लागू होने वाली रणनीति का इस्तेमाल किया जाता है. उदाहरण के लिए, `worker,sandboxed` ऐसे ऐक्शन चलाता है जो वर्कर रणनीति का इस्तेमाल करके, लगातार काम करने वाले वर्कर के साथ काम करते हैं. साथ ही, सैंडबॉक्स वाली रणनीति का इस्तेमाल करके, अन्य सभी ऐक्शन चलाता है. अगर कोई नेमोनिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी नेमोनिक के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `worker,sandboxed` होती है. अगर`experimental_local_lockfree_output` सेट है, तो यह सूची `worker,sandboxed,standalone` होती है. Takes [mnemonic=]local_strategy[,local_strategy,...]
टैग: execution, host_machine_resource_optimizations

--dynamic_remote_strategy=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो

दिए गए नेमोनिक के लिए, क्रम से रिमोट रणनीतियां इस्तेमाल की जाती हैं. सबसे पहले लागू होने वाली रणनीति का इस्तेमाल किया जाता है. अगर कोई नेमोनिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी नेमोनिक के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `remote` होती है. इसलिए, आम तौर पर इस फ़्लैग को साफ़ तौर पर सेट करने की ज़रूरत नहीं होती. Takes [mnemonic=]remote_strategy[,remote_strategy,...]
टैग: execution, host_machine_resource_optimizations

--experimental_docker_image=<a string> default: ""

डॉकर इमेज का वह नाम (जैसे, "ubuntu:latest") डालें जिसका इस्तेमाल, डॉकर रणनीति का इस्तेमाल करते समय सैंडबॉक्स किए गए ऐक्शन को लागू करने के लिए किया जाना चाहिए. साथ ही, ऐक्शन में प्लैटफ़ॉर्म के ब्यौरे में मौजूद remote_execution_properties में पहले से ही container-image एट्रिब्यूट नहीं होना चाहिए. इस फ़्लैग की वैल्यू को 'docker run' में पास किया जाता है. इसलिए, यह Docker के सिंटैक्स और मेकैनिज़्म के साथ काम करता है.
टैग: execution

--[no]experimental_docker_use_customized_images default: "true"

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

--[no]experimental_dynamic_exclude_tools default: "true"

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

--experimental_dynamic_local_load_factor=<a double> default: "0"

इससे यह कंट्रोल किया जाता है कि डाइनैमिक एक्ज़ीक्यूशन से लोकल मशीन पर कितना लोड डाला जाए. यह फ़्लैग, डाइनैमिक एक्ज़ीक्यूशन में एक साथ शेड्यूल की जाने वाली कार्रवाइयों की संख्या को अडजस्ट करता है. यह इस बात पर निर्भर करता है कि Blaze के हिसाब से कितने सीपीयू उपलब्ध हैं. इसे --local_cpu_resources फ़्लैग की मदद से कंट्रोल किया जा सकता है. अगर इस फ़्लैग की वैल्यू 0 है, तो सभी कार्रवाइयों को तुरंत स्थानीय तौर पर शेड्यूल किया जाता है. अगर वैल्यू > 0 है, तो स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या, उपलब्ध सीपीयू की संख्या के हिसाब से तय होती है. अगर यह वैल्यू < 1 है, तो लोड फ़ैक्टर का इस्तेमाल, स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या को कम करने के लिए किया जाता है. ऐसा तब किया जाता है, जब शेड्यूल की जाने वाली कार्रवाइयों की संख्या ज़्यादा हो. इससे क्लीन बिल्ड के मामले में लोकल मशीन पर लोड कम हो जाता है. इसमें लोकल मशीन का योगदान ज़्यादा नहीं होता.
टैग: execution, host_machine_resource_optimizations

--experimental_dynamic_slow_remote_time=<An immutable length of time.> default: "0"

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

--[no]experimental_enable_docker_sandbox डिफ़ॉल्ट: "false"

Docker पर आधारित सैंडबॉक्सिंग चालू करें. अगर Docker इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: execution

--[no]experimental_inmemory_sandbox_stashes डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो reuse_sandbox_directories के लिए, स्टैश किए गए सैंडबॉक्स के कॉन्टेंट को मेमोरी में ट्रैक किया जाएगा. इससे, दोबारा इस्तेमाल के दौरान ज़रूरी I/O की मात्रा कम हो जाती है. बिल्ड के हिसाब से, यह फ़्लैग वॉल टाइम को बेहतर बना सकता है. बिल्ड के आधार पर, यह फ़्लैग काफ़ी ज़्यादा मेमोरी इस्तेमाल कर सकता है.
टैग: host_machine_resource_optimizations, execution

--experimental_sandbox_async_tree_delete_idle_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "4"

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

--experimental_sandbox_enforce_resources_regexp=<a valid Java regular expression> default: ""

अगर यह विकल्प सही पर सेट है, तो जिन कार्रवाइयों के नेमोनिक, इनपुट किए गए रेगुलर एक्सप्रेशन से मेल खाते हैं उनके लिए संसाधन के अनुरोधों पर सीमाएं लागू की जाएंगी. अगर संसाधन का टाइप इसकी अनुमति देता है, तो --experimental_sandbox_limits की वैल्यू को बदल दिया जाएगा. उदाहरण के लिए, अगर किसी टेस्ट में cpu:3 और resources:memory:10 तय किया गया है, तो वह ज़्यादा से ज़्यादा तीन सीपीयू और 10 मेगाबाइट मेमोरी के साथ चलेगा.
टैग: execution

--experimental_sandbox_limits=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> कई बार इस्तेमाल किया गया हो

अगर वैल्यू > 0 है, तो हर Linux सैंडबॉक्स को तय किए गए संसाधन के लिए, दी गई रकम तक सीमित कर दिया जाएगा. इसके लिए, --incompatible_use_new_cgroup_implementation फ़्लैग की ज़रूरत होती है. साथ ही, यह --experimental_sandbox_memory_limit_mb फ़्लैग को बदल देता है. इसके लिए, cgroups v1 या v2 और उपयोगकर्ताओं को cgroups डायरेक्ट्री का ऐक्सेस देने की अनुमतियां ज़रूरी हैं.
टैग: execution

--experimental_sandbox_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0"

अगर वैल्यू > 0 है, तो हर Linux सैंडबॉक्स को दी गई मेमोरी (MB में) तक सीमित कर दिया जाएगा. इसके लिए, cgroups v1 या v2 और उपयोगकर्ताओं को cgroups डायरेक्ट्री का ऐक्सेस देने की अनुमतियां ज़रूरी हैं.
टैग: execution

--[no]experimental_shrink_worker_pool डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो वर्कर पूल छोटा हो सकता है. ऐसा तब होता है, जब वर्कर की मेमोरी पर ज़्यादा दबाव पड़ता है. यह फ़्लैग सिर्फ़ तब काम करता है, जब experimental_total_worker_memory_limit_mb फ़्लैग चालू हो.
टैग: execution, host_machine_resource_optimizations

--[no]experimental_split_xml_generation default: "true"

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

--experimental_total_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0"

अगर यह सीमा शून्य से ज़्यादा है, तो हो सकता है कि सभी वर्कर के कुल मेमोरी इस्तेमाल की सीमा से ज़्यादा होने पर, कुछ वर्कर बंद हो जाएं.
टैग: execution, host_machine_resource_optimizations

--[no]experimental_use_hermetic_linux_sandbox डिफ़ॉल्ट: "false"

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

--[no]experimental_use_semaphore_for_jobs default: "true"

अगर इसे सही पर सेट किया जाता है, तो एक साथ चलने वाले जॉब की संख्या को सीमित करने के लिए, सेमाफ़ोर का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution

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

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

--experimental_windows_sandbox_path=<a string> default: "BazelSandbox.exe"

Windows सैंडबॉक्स के बाइनरी का पाथ. इसका इस्तेमाल तब किया जाता है, जब --experimental_use_windows_sandbox की वैल्यू सही होती है. अगर कोई बेयर नेम है, तो PATH में मिले उस नाम के पहले बाइनरी का इस्तेमाल करें.
टैग: execution

--experimental_worker_allowlist=<comma-separated set of options> डिफ़ॉल्ट: ब्यौरा देखें

अगर यह फ़ील्ड खाली नहीं है, तो सिर्फ़ दिए गए वर्कर की-मोनिक के साथ परसिस्टेंट वर्कर का इस्तेमाल करने की अनुमति दें.
टैग: execution, host_machine_resource_optimizations

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

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

--experimental_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0"

अगर यह सीमा शून्य से ज़्यादा है, तो वर्कर की मेमोरी का इस्तेमाल सीमा से ज़्यादा होने पर, वर्कर बंद किए जा सकते हैं. अगर इस विकल्प का इस्तेमाल, डाइनैमिक एक्ज़ीक्यूशन और `--experimental_dynamic_ignore_local_signals=9` के साथ नहीं किया जाता है, तो आपका बिल्ड क्रैश हो सकता है.
टैग: execution, host_machine_resource_optimizations

--experimental_worker_metrics_poll_interval=<An immutable length of time.> default: "5s"

यह वर्कर की मेट्रिक इकट्ठा करने और वर्कर को हटाने की कोशिश करने के बीच का इंटरवल होता है. परफ़ॉर्मेंस की वजह से, इसे एक सेकंड से कम नहीं किया जा सकता.
टैग: execution, host_machine_resource_optimizations

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

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

--[no]experimental_worker_sandbox_hardening डिफ़ॉल्ट: "false"

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

--experimental_worker_sandbox_inmemory_tracking=<a string> कई बार इस्तेमाल किया गया हो

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

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

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

--genrule_strategy=<comma-separated list of options> default: ""

बताएं कि जनरूल को कैसे लागू करना है. इस फ़्लैग को धीरे-धीरे हटाया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरूल को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution

--[no]incompatible_sandbox_hermetic_tmp default: "true"

इस विकल्प को सही पर सेट करने पर, हर Linux सैंडबॉक्स में अपनी खाली डायरेक्ट्री होगी. इसे होस्ट फ़ाइल सिस्टम के साथ /tmp शेयर करने के बजाय, /tmp के तौर पर माउंट किया जाएगा. सभी सैंडबॉक्स में होस्ट के/tmp को देखने के लिए, --sandbox_add_mount_pair=/tmp का इस्तेमाल करें.
टैग: execution

--[no]incompatible_use_new_cgroup_implementation डिफ़ॉल्ट: "false"

अगर यह सही है, तो cgroup के लिए नए तरीके का इस्तेमाल करें. पुराना तरीका सिर्फ़ मेमोरी कंट्रोलर के साथ काम करता है और --experimental_sandbox_limits की वैल्यू को अनदेखा करता है.
टैग: execution

--[no]internal_spawn_scheduler default: "true"

यह प्लेसहोल्डर विकल्प है, ताकि हम Blaze में यह बता सकें कि स्पॉन शेड्यूलर चालू था या नहीं.
टैग: execution, host_machine_resource_optimizations

--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> [-j] default: "auto"

एक साथ चलने वाले जॉब की संख्या. यह पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, विकल्प के तौर पर कोई कार्रवाई ([-|*]<float>) की जा सकती है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". वैल्यू, 1 से 5000 के बीच होनी चाहिए. 2500 से ज़्यादा वैल्यू की वजह से मेमोरी से जुड़ी समस्याएं हो सकती हैं. "auto" विकल्प, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू का हिसाब लगाता है.
टैग: host_machine_resource_optimizations, execution

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto"

लोडिंग/विश्लेषण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto" विकल्प, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--[no]reuse_sandbox_directories default: "true"

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

--sandbox_base=<a string> default: ""

इस पाथ के नीचे सैंडबॉक्स को अपनी सैंडबॉक्स डायरेक्ट्री बनाने की अनुमति देता है. अगर आपके बिल्ड /टेस्ट में कई इनपुट फ़ाइलें हैं, तो परफ़ॉर्मेंस को बेहतर बनाने के लिए, tmpfs पर कोई पाथ (जैसे कि/run / shm) तय करें. ध्यान दें: कार्रवाइयां चलाने से जनरेट हुई आउटपुट और इंटरमीडिएट फ़ाइलों को सेव करने के लिए, आपके पास tmpfs पर ज़रूरत के मुताबिक रैम और खाली जगह होनी चाहिए.
टैग: host_machine_resource_optimizations, execution

--[no]sandbox_explicit_pseudoterminal डिफ़ॉल्ट: "false"

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

--sandbox_tmpfs_path=<an absolute path> कई बार इस्तेमाल किया गया हो

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

--[no]skip_incompatible_explicit_targets डिफ़ॉल्ट: "false"

कमांड लाइन पर साफ़ तौर पर दिए गए, काम न करने वाले टारगेट को छोड़ें. डिफ़ॉल्ट रूप से, ऐसे टारगेट बनाने पर गड़बड़ी होती है. हालांकि, इस विकल्प के चालू होने पर, इन्हें चुपचाप तरीके से छोड़ दिया जाता है. देखें: https://bazel.build/extending/platforms#skipping-incompatible-targets
टैग: loading_and_analysis

--spawn_strategy=<comma-separated list of options> default: ""

इससे यह तय किया जाता है कि स्पॉन की कार्रवाइयों को डिफ़ॉल्ट रूप से कैसे लागू किया जाता है. यह सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता तक की रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार करता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली ऐसी रणनीति चुनता है जो कार्रवाई को पूरा कर सकती है. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" होती है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो

यह तय करें कि अन्य स्पॉन कार्रवाइयों के कंपाइलेशन को कैसे डिस्ट्रिब्यूट किया जाए. यह सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता तक की रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार करता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली ऐसी रणनीति चुनता है जो कार्रवाई को पूरा कर सकती है. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" होती है. यह फ़्लैग, --spawn_strategy से सेट की गई वैल्यू को बदल देता है. अगर इसका इस्तेमाल नेमोनिक Genrule के साथ किया जाता है, तो यह --genrule_strategy से सेट की गई वैल्यू को भी बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> कई बार इस्तेमाल किया गया हो

यह तय करें कि regex_filter से मेल खाने वाले ब्यौरे वाले स्पॉन ऐक्शन को लागू करने के लिए, किस स्पॉन रणनीति का इस्तेमाल किया जाना चाहिए. regex_filter मैचिंग के बारे में ज़्यादा जानने के लिए, --per_file_copt देखें. ब्यौरे से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. यह विकल्प, रणनीति तय करने के लिए अन्य फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि अगर कार्रवाइयों के ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो लोकल रणनीति का इस्तेमाल करके कार्रवाइयां चलाएं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed, 'Compiling //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा. हालांकि, क्रम बदलने पर इसे 'sandboxed' रणनीति के साथ चलाया जाएगा.
टैग: execution

--worker_extra_flag=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

--persistent_worker के अलावा, वर्कर प्रोसेस को पास किए जाने वाले अतिरिक्त कमांड-फ़्लैग.इन्हें नेमोनिक के हिसाब से सेट किया जाता है. उदाहरण के लिए, --worker_extra_flag=Javac=--debug.
टैग: execution, host_machine_resource_optimizations

--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> कई बार इस्तेमाल किया गया हो

अगर 'worker' रणनीति का इस्तेमाल किया जाता है, तो हर तरह के परसिस्टेंट वर्कर के कितने इंस्टेंस लॉन्च किए जा सकते हैं. इसे [name=value] के तौर पर तय किया जा सकता है, ताकि हर नेमोनिक के लिए अलग वैल्यू दी जा सके. यह सीमा वर्कर कुंजियों पर आधारित होती है. इन्हें नेमोनिक के आधार पर अलग-अलग किया जाता है. हालांकि, इन्हें स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में हर नेमोनिक के लिए, इस फ़्लैग में बताई गई संख्या से ज़्यादा वर्कर हो सकते हैं. यह पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, विकल्प के तौर पर कोई कार्रवाई ([-|*]<float>) की जा सकती है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". 'auto' विकल्प, मशीन की क्षमता के आधार पर डिफ़ॉल्ट वैल्यू का हिसाब लगाता है. "=value" से, उन निमोनिक के लिए डिफ़ॉल्ट वैल्यू सेट की जाती है जिनके बारे में जानकारी नहीं दी गई है.
टैग: execution, host_machine_resource_optimizations

--worker_max_multiplex_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> कई बार इस्तेमाल किया गया हो

अगर --worker_multiplex के साथ 'worker' रणनीति का इस्तेमाल किया जाता है, तो मल्टीप्लेक्स वर्कर प्रोसेस को एक साथ कितने WorkRequest मिल सकते हैं. इसे [name=value] के तौर पर तय किया जा सकता है, ताकि हर नेमोनिक के लिए अलग वैल्यू दी जा सके. यह सीमा वर्कर कुंजियों पर आधारित होती है. इन्हें नेमोनिक के आधार पर अलग-अलग किया जाता है. हालांकि, इन्हें स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में हर नेमोनिक के लिए, इस फ़्लैग में बताई गई संख्या से ज़्यादा वर्कर हो सकते हैं. यह पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, विकल्प के तौर पर कोई कार्रवाई ([-|*]<float>) की जा सकती है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". 'auto' विकल्प, मशीन की क्षमता के आधार पर डिफ़ॉल्ट वैल्यू का हिसाब लगाता है. "=value" से, उन निमोनिक के लिए डिफ़ॉल्ट वैल्यू सेट की जाती है जिनके बारे में जानकारी नहीं दी गई है.
टैग: execution, host_machine_resource_optimizations

--[no]worker_multiplex default: "true"

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

--[no]worker_quit_after_build डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, बिल्ड पूरा होने के बाद सभी वर्कर बंद हो जाते हैं.
टैग: execution, host_machine_resource_optimizations

--[no]worker_sandboxing डिफ़ॉल्ट: "false"

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

--[no]worker_verbose डिफ़ॉल्ट: "false"

चालू होने पर, वर्कर शुरू होने, बंद होने वगैरह के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करता है...

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]build default: "true"

बिल्ड को एक्ज़ीक्यूट करें. यह सामान्य प्रोसेस है. --nobuild विकल्प का इस्तेमाल करने पर, बिल्ड की प्रोसेस, बिल्ड ऐक्शन को लागू करने से पहले ही रुक जाती है. अगर पैकेज लोड करने और विश्लेषण करने के चरण पूरे हो जाते हैं, तो यह विकल्प शून्य दिखाता है. यह मोड, इन चरणों की जांच करने के लिए काम आता है.
टैग: execution, affects_outputs

--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "false"

जांच के साथ पैरलल में चलाने के लिए, पहलू का इस्तेमाल करके पुष्टि करने वाली कार्रवाइयां चलानी हैं या नहीं.
टैग: execution, affects_outputs

--output_groups=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इनमें से हर नाम के पहले, + या - का इस्तेमाल किया जा सकता है. + से शुरू होने वाले ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ा जाता है. वहीं, - से शुरू होने वाले ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप में प्रीफ़िक्स नहीं है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट शामिल नहीं किया जाता. उदाहरण के लिए, --output_groups=+foo,+bar से, डिफ़ॉल्ट सेट, foo, और bar का यूनियन बनता है. वहीं, --output_groups=foo,bar से डिफ़ॉल्ट सेट बदल जाता है, ताकि सिर्फ़ foo और bar बनाए जा सकें.
टैग: execution, affects_outputs

--[no]run_validations default: "true"

बिल्ड के हिस्से के तौर पर, पुष्टि करने वाली कार्रवाइयां करनी हैं या नहीं. https://bazel.build/extending/rules#validation_actions पर जाएं
टैग: execution, affects_outputs

--serialized_frontier_profile=<a string> default: ""

सीरियल किए गए फ़्रंटियर बाइट की प्रोफ़ाइल डंप करें. इससे आउटपुट पाथ के बारे में पता चलता है.
टैग: bazel_monitoring

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

--aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

टॉप-लेवल के टारगेट पर लागू किए जाने वाले पहलुओं की सूची, जिसमें उन्हें कॉमा लगाकर अलग किया गया है. अगर सूची में, आसपेक्ट some_aspect, required_aspect_providers के ज़रिए ज़रूरी आसपेक्ट प्रोवाइडर तय करता है, तो some_aspect, आसपेक्ट की सूची में उससे पहले बताए गए हर उस आसपेक्ट के बाद चलेगा जिसके विज्ञापन देने वाले प्रोवाइडर, some_aspect के ज़रूरी आसपेक्ट प्रोवाइडर की ज़रूरी शर्तों को पूरा करते हैं. इसके अलावा, requires एट्रिब्यूट के ज़रिए तय किए गए सभी ज़रूरी पहलुओं के बाद, some_aspect चलेगा. इसके बाद, some_aspect के पास उन पहलुओं के प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, उदाहरण के लिए '//tools:my_def.bzl%my_aspect'. इसमें 'my_aspect' एक टॉप-लेवल वैल्यू है, जो tools/my_def.bzl फ़ाइल से मिलती है

--bep_maximum_open_remote_upload_files=<an integer> default: "-1"

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

--[no]experimental_convenience_symlinks default: "normal"

इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिए उपलब्ध कराए गए सिंबल लिंक (ऐसे सिंबल लिंक जो बिल्ड के बाद वर्कस्पेस में दिखते हैं) को कैसे मैनेज किया जाएगा. संभावित वैल्यू: normal (डिफ़ॉल्ट): बिल्ड के हिसाब से, हर तरह के सुविधा वाले सिंबल लिंक बनाए या मिटाए जाएंगे. clean: सभी सिमलंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: इस विकल्प को चुनने पर, सिंबॉलिक लिंक न तो बनाए जाएंगे और न ही हटाए जाएंगे. log_only: इस मोड में, लॉग मैसेज जनरेट किए जाते हैं. ये मैसेज ऐसे होते हैं जैसे 'normal' मोड में जनरेट किए जाते हैं. हालाँकि, इस मोड में फ़ाइल सिस्टम से जुड़ी कोई कार्रवाई नहीं की जाती. यह मोड टूल के लिए फ़ायदेमंद होता है. ध्यान दें कि सिर्फ़ उन सिमलंक पर असर पड़ सकता है जिनके नाम, --symlink_prefix की मौजूदा वैल्यू से जनरेट किए गए हैं. अगर प्रीफ़िक्स बदलता है, तो पहले से मौजूद किसी भी सिमलंक पर कोई असर नहीं पड़ेगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks_bep_event default: "true"

यह फ़्लैग कंट्रोल करता है कि हम BuildEventProtocol में build eventConvenienceSymlinksIdentified पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में convenienceSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके वर्कस्पेस में बनाए गए सभी सुविधा वाले सिंबल लिंक की सूची होगी. अगर यह वैल्यू 'गलत है', तो BuildEventProtocol में convenienceSymlinksIdentified एंट्री खाली होगी.
टैग: affects_outputs

--remote_download_all

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

टैग: affects_outputs

--remote_download_minimal

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

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> default: "toplevel"

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

--remote_download_symlink_template=<a string> default: ""

इस विकल्प को चुनने पर, रिमोट बिल्ड के आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबॉलिक लिंक बनाए जाते हैं. सिंबॉलिक लिंक के टारगेट को टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये ऑब्जेक्ट के हैश और साइज़ को बाइट में दिखाते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक, FUSE फ़ाइल सिस्टम की ओर इशारा कर सकते हैं. यह सिस्टम, CAS से ऑब्जेक्ट को ज़रूरत के हिसाब से लोड करता है.
टैग: affects_outputs

--remote_download_toplevel

यह सिर्फ़ टॉप लेवल के टारगेट के रिमोट आउटपुट को स्थानीय मशीन पर डाउनलोड करता है. यह फ़्लैग, --remote_download_outputs=toplevel के लिए उपनाम है.
इनके लिए उपलब्ध है:
  --remote_download_outputs=toplevel

टैग: affects_outputs

--symlink_prefix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

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

--[no]experimental_docker_privileged डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, Bazel, कार्रवाइयां करते समय 'docker run' को --privileged फ़्लैग पास करेगा. यह आपके बिल्ड के लिए ज़रूरी हो सकता है. हालांकि, इससे हर्मेटिकनेस कम हो सकता है.
टैग: execution

--[no]experimental_sandboxfs_map_symlink_targets डिफ़ॉल्ट: "false"

No-op
टैग: host_machine_resource_optimizations, execution

--[no]incompatible_legacy_local_fallback डिफ़ॉल्ट: "false"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स की गई रणनीति से लोकल रणनीति पर अपने-आप फ़ॉलबैक होने की लेगसी सुविधा चालू हो जाती है. यह फ़्लैग आखिर में डिफ़ॉल्ट रूप से 'बंद है' पर सेट हो जाएगा. इसके बाद, यह काम नहीं करेगा. फ़ॉलबैक को कॉन्फ़िगर करने के लिए, --strategy, --spawn_strategy या --dynamic_local_strategy का इस्तेमाल करें.
टैग: execution, incompatible_change

--sandbox_add_mount_pair=<a single path or a 'source:target' pair> कई बार इस्तेमाल किया गया हो

सैंडबॉक्स में माउंट करने के लिए, अतिरिक्त पाथ पेयर जोड़ें.
टैग: execution

--sandbox_block_path=<a string> कई बार इस्तेमाल किया गया हो

सैंडबॉक्स की गई कार्रवाइयों के लिए, इस पाथ का ऐक्सेस न दें.
टैग: execution

--[no]sandbox_default_allow_network default: "true"

कार्रवाइयों के लिए, नेटवर्क ऐक्सेस को डिफ़ॉल्ट रूप से अनुमति दें. ऐसा हो सकता है कि यह सुविधा, सैंडबॉक्सिंग की सभी सुविधाओं के साथ काम न करे.
टैग: execution

--[no]sandbox_fake_hostname डिफ़ॉल्ट: "false"

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग: execution

--[no]sandbox_fake_username डिफ़ॉल्ट: "false"

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'nobody' में बदलें.
टैग: execution

--sandbox_writable_path=<a string> कई बार इस्तेमाल किया गया हो

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

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

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "false"

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

--[no]incompatible_enforce_config_setting_visibility default: "true"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है' पर सेट है, तो हर config_setting, हर टारगेट को दिखेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_use_plus_in_repo_names default: "true"

कोई कार्रवाई नहीं.
टैग: loading_and_analysis

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

--[no]check_tests_up_to_date डिफ़ॉल्ट: "false"

जांच न करें, बस यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी टेस्ट के नतीजे अप-टू-डेट हैं, तो टेस्टिंग पूरी हो जाती है. अगर कोई टेस्ट बनाना या उसे लागू करना ज़रूरी है, तो गड़बड़ी की सूचना दी जाती है और टेस्टिंग नहीं हो पाती. इस विकल्प का मतलब है कि --check_up_to_date का इस्तेमाल किया गया है.
टैग: execution

--flaky_test_attempts=<a positive integer, the string "default", or test_regex@attempts. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो

अगर कोई टेस्ट पूरा नहीं होता है, तो उसे तय की गई संख्या तक फिर से आज़माया जाएगा. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश करनी पड़ी उन्हें टेस्ट की खास जानकारी में 'FLAKY' के तौर पर मार्क किया जाता है. आम तौर पर, दी गई वैल्यू सिर्फ़ एक पूर्णांक या 'default' स्ट्रिंग होती है. अगर यह पूर्णांक है, तो सभी टेस्ट N बार चलाए जाएंगे. अगर 'default' चुना जाता है, तो सामान्य टेस्ट के लिए सिर्फ़ एक बार और ऐसे टेस्ट के लिए तीन बार कोशिश की जाएगी जिन्हें नियम के हिसाब से, साफ़ तौर पर फ़्लेकी के तौर पर मार्क किया गया है (flaky=1 एट्रिब्यूट). वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. यहां flaky_test_attempts का मतलब ऊपर दिया गया है. साथ ही, regex_filter का मतलब, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची है. --runs_per_test भी देखें. उदाहरण: --flaky_test_attempts=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार डिफ़्लेक करता है. हालांकि, foo/bar में मौजूद टेस्ट को तीन बार डिफ़्लेक नहीं करता. इस विकल्प को कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए उस तर्क को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई भी वैल्यू मेल नहीं खाती है, तो 'default' के तौर पर ऊपर दिए गए तरीके का इस्तेमाल किया जाता है.
टैग: execution

--local_test_jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto"

एक साथ चलाए जा सकने वाले लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. यह पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, विकल्प के तौर पर कोई कार्रवाई ([-|*]<float>) की जा सकती है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". 0 का मतलब है कि लोकल संसाधनों का इस्तेमाल करके, एक साथ चलाए जा सकने वाले लोकल टेस्ट जॉब की संख्या को सीमित किया जाएगा. इसे --jobs की वैल्यू से ज़्यादा पर सेट करने से कोई फ़र्क़ नहीं पड़ता.
टैग: execution

--[no]test_keep_going default: "true"

इसे बंद करने पर, टेस्ट पास न होने की वजह से पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट चलाए जाते हैं. भले ही, कुछ टेस्ट पास न हुए हों.
टैग: execution

--test_strategy=<a string> default: ""

यह तय करता है कि टेस्ट चलाते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution

--test_tmpdir=<a path> डिफ़ॉल्ट: ब्यौरा देखें

यह 'bazel test' के लिए, बुनियादी अस्थायी डायरेक्ट्री के बारे में बताता है.

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

--cache_computed_file_digests=<a long integer> default: "50000"

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

--[no]experimental_cpu_load_scheduling डिफ़ॉल्ट: "false"

इससे सीपीयू लोड के आधार पर, एक्सपेरिमेंट के तौर पर स्थानीय तौर पर एक्ज़ीक्यूट होने वाले शेड्यूल को चालू किया जाता है. इसमें एक-एक करके कार्रवाइयों का अनुमान नहीं लगाया जाता. एक्सपेरिमेंट के तौर पर उपलब्ध शेड्यूलिंग की सुविधा से, ज़्यादा कोर वाली पावरफ़ुल मशीनों पर लोकल बिल्ड के लिए काफ़ी फ़ायदा मिला है. इसे --local_resources=cpu=HOST_CPUS के साथ इस्तेमाल करने का सुझाव दिया जाता है
टैग: execution

--experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers> डिफ़ॉल्ट: ब्यौरा देखें

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

--[no]experimental_enable_skyfocus डिफ़ॉल्ट: "false"

अगर सही है, तो --experimental_working_set का इस्तेमाल करने की सुविधा चालू करें. इससे इंक्रीमेंटल बिल्ड के लिए, Bazel के मेमोरी फ़ुटप्रिंट को कम किया जा सकता है. इस सुविधा को Skyfocus कहा जाता है.
टैग: host_machine_resource_optimizations

--experimental_working_set=<comma-separated list of options> default: ""

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

--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_CPUS"

Bazel के लिए, लोकल सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें, ताकि Bazel, स्थानीय तौर पर एक्ज़ीक्यूट की गई बिल्ड कार्रवाइयों पर खर्च कर सके. यह पूर्णांक या "HOST_CPUS" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_CPUS*.5 का इस्तेमाल करके, उपलब्ध सीपीयू कोर का आधा हिस्सा इस्तेमाल किया जा सकता है). डिफ़ॉल्ट रूप से, ("HOST_CPUS") Bazel, सिस्टम कॉन्फ़िगरेशन के बारे में क्वेरी करेगा, ताकि उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाया जा सके.
टैग: host_machine_resource_optimizations

--local_extra_resources=<a named float, 'name=value'> कई बार इस्तेमाल किया गया हो

Bazel के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. यह स्ट्रिंग-फ़्लोट पेयर लेता है. इसका इस्तेमाल कई बार किया जा सकता है, ताकि अलग-अलग तरह के अतिरिक्त संसाधनों के बारे में बताया जा सके. Bazel, उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों को सीमित करेगा. जांचें, "resources:<resoucename>:<amount>" फ़ॉर्मैट वाले टैग का इस्तेमाल करके, यह तय कर सकती हैं कि उन्हें कितने अतिरिक्त संसाधनों की ज़रूरत है. इस फ़्लैग की मदद से, उपलब्ध सीपीयू, रैम, और संसाधनों को सेट नहीं किया जा सकता.
टैग: host_machine_resource_optimizations

--local_ram_resources=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_RAM*.67"

Bazel के लिए, लोकल होस्ट रैम की कुल रकम (एमबी में) साफ़ तौर पर सेट करें. इसका इस्तेमाल, स्थानीय तौर पर एक्ज़ीक्यूट किए गए बिल्ड ऐक्शन पर किया जाएगा. यह पूर्णांक या "HOST_RAM" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_RAM*.5 का इस्तेमाल करके, उपलब्ध रैम का आधा हिस्सा इस्तेमाल किया जा सकता है). डिफ़ॉल्ट रूप से, ("HOST_RAM*.67"), Bazel सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा, ताकि उपलब्ध रैम का अनुमान लगाया जा सके. इसके बाद, वह इसका 67% इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations

--local_resources=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> कई बार इस्तेमाल किया गया हो

Bazel के लिए उपलब्ध संसाधनों की संख्या सेट करें. यह फ़्लोट या HOST_RAM/HOST_CPUS को असाइनमेंट में लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए memory=HOST_RAM*.5) का इस्तेमाल किया जा सकता है. इसका इस्तेमाल कई बार किया जा सकता है, ताकि अलग-अलग तरह के संसाधनों के बारे में बताया जा सके. Bazel, उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों को सीमित करेगा. जांचें कि "resources:<resource name>:<amount>" फ़ॉर्मैट वाले टैग का इस्तेमाल करके, ज़रूरी संसाधनों की संख्या का एलान किया जा सकता है. यह --local_{cpu|ram|extra}_resources में बताए गए संसाधनों को बदलता है.
टैग: host_machine_resource_optimizations

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

--build_event_upload_max_retries=<an integer> default: "4"

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

--[no]debug_spawn_scheduler डिफ़ॉल्ट: "false"

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

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

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

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

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

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

--experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both> कई बार इस्तेमाल किया गया हो

यह तय करें कि TargetComplete/AspectComplete BEP इवेंट में, आउटपुट ग्रुप की फ़ाइलें कैसे दिखाई जाएंगी. वैल्यू, आउटपुट ग्रुप के नाम को 'NAMED_SET_OF_FILES_ONLY', 'INLINE_ONLY' या 'BOTH' में से किसी एक को असाइन की जाती हैं. डिफ़ॉल्ट वैल्यू 'NAMED_SET_OF_FILES_ONLY' होती है. अगर किसी आउटपुट ग्रुप को दोहराया जाता है, तो दिखने वाली फ़ाइनल वैल्यू का इस्तेमाल किया जाता है. डिफ़ॉल्ट वैल्यू, कवरेज आर्टफ़ैक्ट के लिए मोड को BOTH पर सेट करती है: --experimental_build_event_output_group_mode=baseline.lcov=both
टैग: affects_outputs

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> default: "1s"

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

--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--[no]experimental_docker_verbose डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो Bazel, Docker सैंडबॉक्स की रणनीति के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करेगा.
टैग: execution

--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "false"

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

--experimental_repository_resolved_file=<a string> default: ""

अगर यह फ़ील्ड खाली नहीं है, तो Starlark वैल्यू लिखें. इसमें Starlark रिपॉज़िटरी के उन सभी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "false"

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

--experimental_skyfocus_dump_keys=<none, count or verbose> डिफ़ॉल्ट: "none"

Skyfocus को डीबग करने के लिए. फ़ोकस किए गए SkyKeys (रूट, पत्तियां, फ़ोकस किए गए deps, फ़ोकस किए गए rdeps) को डंप करें.
टैग: terminal_output

--[no]experimental_skyfocus_dump_post_gc_stats डिफ़ॉल्ट: "false"

Skyfocus को डीबग करने के लिए. अगर यह विकल्प चालू है, तो फ़ोकस करने से पहले/बाद में मैन्युअल जीसी को ट्रिगर करें, ताकि हीप साइज़ में हुई कमी की जानकारी दी जा सके. इससे Skyfocus के इंतज़ार का समय बढ़ जाएगा.
टैग: terminal_output

--experimental_skyfocus_handling_strategy=<strict or warn> default: "strict"

वर्किंग सेट के बाहर के बदलावों को मैनेज करने के लिए Skyfocus की रणनीतियां.
टैग: eagerness_to_exit

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

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

--explain=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

--[no]ignore_unsupported_sandboxing डिफ़ॉल्ट: "false"

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

--[no]legacy_important_outputs डिफ़ॉल्ट: "false"

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

--[no]materialize_param_files डिफ़ॉल्ट: "false"

यह रिमोट ऐक्शन एक्ज़ीक्यूशन या कैश मेमोरी का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें लिखता है. कार्रवाइयों को डीबग करते समय यह काम का होता है. यह --subcommands और --verbose_failures से पता चलता है.
टैग: execution

--max_config_changes_to_show=<an integer> default: "3"

बिल्ड के विकल्पों में बदलाव होने की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नाम की दी गई संख्या तक दिखाता है. अगर दी गई संख्या -1 है, तो बदले गए सभी विकल्प दिखेंगे.
टैग: terminal_output

--max_test_output_bytes=<an integer> default: "-1"

यह हर टेस्ट लॉग के लिए ज़्यादा से ज़्यादा साइज़ तय करता है. यह साइज़ तब लागू होता है, जब --test_output की वैल्यू 'errors' या 'all' पर सेट हो. यह विकल्प, टेस्ट के बहुत ज़्यादा शोर वाले आउटपुट से आउटपुट को ज़्यादा जानकारी से भरने से बचने के लिए फ़ायदेमंद है. टेस्ट हेडर को लॉग के साइज़ में शामिल किया जाता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट पूरा या कुछ भी नहीं होता है.
टैग: test_runner, terminal_output, execution

--output_filter=<a valid Java regular expression> डिफ़ॉल्ट: ब्यौरा देखें

सिर्फ़ उन नियमों के लिए चेतावनियां और कार्रवाई के आउटपुट दिखाता है जिनके नाम, दिए गए रेगुलर एक्सप्रेशन से मेल खाते हैं.
टैग: affects_outputs

--progress_report_interval=<an integer in 0-3600 range> default: "0"

यह विकल्प, अब भी चल रहे जॉब की रिपोर्ट के बीच इंतज़ार करने के लिए सेकंड की संख्या तय करता है. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड के बाद और फिर हर मिनट में एक बार प्रोग्रेस की रिपोर्ट दी जाएगी. --curses विकल्प चालू होने पर, हर सेकंड में प्रोग्रेस की जानकारी मिलती है.
टैग: affects_outputs

--remote_print_execution_messages=<failure, success or all> default: "failure"

रिमोट एक्ज़ीक्यूशन के मैसेज प्रिंट करने की फ़्रीक्वेंसी चुनें. मान्य वैल्यू ये हैं: `failure` का इस्तेमाल सिर्फ़ उन टेस्ट के लिए किया जाता है जो पास नहीं हुए हैं, `success` का इस्तेमाल सिर्फ़ उन टेस्ट के लिए किया जाता है जो पास हो गए हैं, और `all` का इस्तेमाल हमेशा किया जाता है.
टैग: terminal_output

--[no]sandbox_debug डिफ़ॉल्ट: "false"

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

--show_result=<an integer> default: "1"

बिल्ड के नतीजे दिखाओ. हर टारगेट के लिए, यह बताएं कि उसे अप-टू-डेट किया गया है या नहीं. अगर हां, तो बनाई गई आउटपुट फ़ाइलों की सूची दें. प्रिंट की गई फ़ाइलें, शेल में कॉपी करके चिपकाने के लिए सुविधाजनक स्ट्रिंग होती हैं, ताकि उन्हें एक्ज़ीक्यूट किया जा सके. इस विकल्प के लिए, पूर्णांक आर्ग्युमेंट की ज़रूरत होती है. यह टारगेट की वह थ्रेशोल्ड संख्या होती है जिसके ऊपर, नतीजे की जानकारी प्रिंट नहीं की जाती. इसलिए, शून्य की वजह से मैसेज नहीं दिखता है और MAX_INT की वजह से, नतीजे हमेशा प्रिंट होते हैं. डिफ़ॉल्ट रूप से, इसकी वैल्यू एक होती है. अगर किसी टारगेट के लिए कोई कॉन्टेंट नहीं बनाया गया है, तो उसके नतीजों को हटाया जा सकता है, ताकि आउटपुट तय सीमा के अंदर रहे.
टैग: affects_outputs

--[no]subcommands [-s] डिफ़ॉल्ट: "false"

बिल्ड के दौरान लागू की गई सब-कमांड दिखाएं. इससे जुड़े फ़्लैग: --execution_log_json_file, --execution_log_binary_file (उप-कमांड को टूल के हिसाब से फ़ॉर्मैट की गई फ़ाइल में लॉग करने के लिए).
टैग: terminal_output

--test_output=<summary, errors, all or streamed> default: "summary"

इससे, आउटपुट का पसंदीदा मोड तय किया जाता है. इसे `--test_summary` के साथ भ्रमित न करें. यह कमांड पूरी होने पर प्रिंट की गई टेस्ट की खास जानकारी को कंट्रोल करता है. मान्य वैल्यू ये हैं: - `summary` (डिफ़ॉल्ट) का इस्तेमाल, फ़ेल हुए टेस्ट की खास जानकारी प्रिंट करने के लिए किया जाता है, - `errors` का इस्तेमाल, फ़ेल हुए टेस्ट के लिए टेस्ट लॉग भी प्रिंट करने के लिए किया जाता है, - `all` का इस्तेमाल, सभी टेस्ट के लिए खास जानकारी और लॉग प्रिंट करने के लिए किया जाता है और - `streamed` का इस्तेमाल, सभी टेस्ट के लॉग को रीयल टाइम में आउटपुट करने के लिए किया जाता है. इससे टेस्ट को `--test_strategy` वैल्यू के बावजूद, एक-एक करके स्थानीय तौर पर चलाने के लिए मजबूर किया जाएगा.
टैग: test_runner, terminal_output, execution

--test_summary=<short, short_uncached, terse, detailed, detailed_uncached, none or testcase> default: "short"

इस एट्रिब्यूट की वैल्यू से, टेस्ट के नतीजों के लिए मनचाहा फ़ॉर्मैट तय किया जाता है. मान्य वैल्यू ये हैं: - `short` से उन सभी टेस्ट की सूची मिलती है जो पूरे हो चुके हैं. - `short_uncached` का इस्तेमाल उन टेस्ट की सूची बनाने के लिए किया जाता है जो पूरी तरह से चले हैं. इसमें कैश मेमोरी में सेव किए गए टेस्ट शामिल नहीं होते. - `terse` का इस्तेमाल सिर्फ़ उन टेस्ट को सूची में शामिल करने के लिए करें जो फ़ेल हो गए हैं और जिनमें गड़बड़ी है. - `detailed` का इस्तेमाल उन टेस्ट की सूची बनाने के लिए किया जाता है जो पूरे हो चुके हैं. साथ ही, इससे उनके टेस्ट केस भी दिखते हैं. - `detailed_uncached` का इस्तेमाल उन टेस्ट की सूची बनाने के लिए किया जाता है जो पूरे हो चुके हैं और उनके टेस्ट केस, साथ ही, इसमें कैश मेमोरी में सेव किए गए टेस्ट शामिल नहीं होते. - `testcase` का इस्तेमाल, टेस्ट केस के नतीजे की खास जानकारी को प्रिंट करने के लिए किया जाता है. इसमें फ़ेल हुए टेस्ट केस के बारे में ज़्यादा जानकारी नहीं होती. - `none` का इस्तेमाल करके, खास जानकारी को हटाया जा सकता है.
टैग: terminal_output

--[no]verbose_explanations डिफ़ॉल्ट: "false"

अगर --explain विकल्प चालू है, तो इससे जवाब में ज़्यादा जानकारी मिलती है. अगर --explain विकल्प चालू नहीं है, तो इसका कोई असर नहीं होगा.
टैग: affects_outputs

--[no]verbose_failures डिफ़ॉल्ट: "false"

अगर कोई निर्देश काम नहीं करता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

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

--aspects_parameters=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

इससे कमांड-लाइन के पहलुओं के पैरामीटर की वैल्यू तय की जाती हैं. हर पैरामीटर वैल्यू को <param_name>=<param_value> के ज़रिए तय किया जाता है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param' --aspects सूची में मौजूद किसी पहलू का पैरामीटर है या सूची में मौजूद किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. हालांकि, एक ही पैरामीटर को एक से ज़्यादा बार वैल्यू असाइन करने की अनुमति नहीं है.
टैग: loading_and_analysis

--target_pattern_file=<a string> default: ""

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

रिमोट कैशिंग और एक्ज़ीक्यूशन के विकल्प:

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: ब्यौरा देखें

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

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

zstd का इस्तेमाल करके कंप्रेस/डीकंप्रेस करने के लिए, कम से कम ब्लोब साइज़ ज़रूरी है. जब तक --remote_cache_compression सेट नहीं किया जाता, तब तक यह विकल्प काम नहीं करता.

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

अगर बिल्ड के दौरान, रिमोट कैश से जुड़ी कोई ऐसी अस्थायी गड़बड़ी होती है जिसकी वजह से बिल्ड पूरा नहीं हो पाता है, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. उदाहरण के लिए, यह तब लागू होता है, जब रिमोट कैश से आर्टफ़ैक्ट हटा दिए जाते हैं या कैश फ़ेल होने की कुछ स्थितियों में ऐसा होता है. शून्य से अलग वैल्यू सेट करने पर, --incompatible_remote_use_new_exit_code_for_lost_inputs को डिफ़ॉल्ट रूप से सही पर सेट कर दिया जाएगा. हर कोशिश के लिए, एक नया इनवोकेशन आईडी जनरेट किया जाएगा. अगर आपने इनवोकेशन आईडी जनरेट किया है और इसे --invocation_id के साथ Bazel को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, --incompatible_remote_use_new_exit_code_for_lost_inputs फ़्लैग सेट करें और 39 वाले एक्ज़िट कोड की जांच करें.
टैग: execution

--[no]experimental_remote_cache_lease_extension डिफ़ॉल्ट: "false"

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

--experimental_remote_cache_ttl=<An immutable length of time.> default: "3h"

डाइजेस्ट का हाल ही में रेफ़रंस दिए जाने के बाद, रिमोट कैश में मौजूद ब्लॉब का कम से कम टीटीएल. उदाहरण के लिए, ActionResult या FindMissingBlobs. Bazel, ब्लॉब के टीटीएल के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, इंक्रीमेंटल बिल्ड में GetActionResult को बार-बार कॉल नहीं करता है. वैल्यू को असली टीटीएल से थोड़ा कम सेट किया जाना चाहिए, क्योंकि सर्वर के डाइजेस्ट वापस भेजने और Bazel के उन्हें पाने के बीच कुछ समय लगता है.
टैग: execution

--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: ब्यौरा देखें

यह उस डायरेक्ट्री का पाथ है जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.

--[no]experimental_remote_discard_merkle_trees default: "true"

अगर इसे सही पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़े इनपुट मैपिंग की इन-मेमोरी कॉपी को खारिज कर दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में मौजूद न होने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कंप्यूट करना होगा.

--experimental_remote_downloader=<a string> डिफ़ॉल्ट: ब्यौरा देखें

रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाना है. grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. इस लिंक पर जानकारी पाएं: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

--[no]experimental_remote_downloader_local_fallback डिफ़ॉल्ट: "false"

अगर रिमोट डाउनलोडर काम नहीं करता है, तो लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.

--[no]experimental_remote_downloader_propagate_credentials डिफ़ॉल्ट: "false"

netrc और क्रेडेंशियल हेल्पर से रिमोट डाउनलोडर सर्वर को क्रेडेंशियल भेजने हैं या नहीं. सर्वर के लिए, `http_header_url:<url-index>:<header-key>` क्वालिफ़ायर का इस्तेमाल करना ज़रूरी है. इसमें `<url-index>`, FetchBlobRequest के `uris` फ़ील्ड में मौजूद यूआरएल की 0 पर आधारित पोज़िशन होती है. यूआरएल के हिसाब से तय किए गए हेडर को ग्लोबल हेडर से ज़्यादा प्राथमिकता दी जानी चाहिए.

--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "false"

रिमोट तरीके से एक्ज़ीक्यूट करने के लिए, कीपअलाइव का इस्तेमाल करना है या नहीं.

--experimental_remote_failure_rate_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "10"

यह विकल्प, किसी समयावधि के लिए, फ़ेल होने की दर को प्रतिशत में सेट करता है. इसके बाद, यह रिमोट कैश/एक्ज़ीक्यूटर को कॉल करना बंद कर देता है. डिफ़ॉल्ट रूप से इसकी वैल्यू 10 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
टैग: execution

--experimental_remote_failure_window_interval=<An immutable length of time.> default: "60s"

वह समयावधि जिसमें रिमोट अनुरोधों के फ़ेल होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, फ़ेल होने की अवधि को पूरे एक्ज़ीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution

--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर्सिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.

--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "false"

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

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

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

--experimental_remote_output_service=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--experimental_remote_output_service_output_path_prefix=<a string> default: ""

यह वह पाथ है जिसके तहत, --experimental_remote_output_service से मैनेज की गई आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. बिल्ड के लिए इस्तेमाल की जाने वाली आउटपुट डायरेक्ट्री, इस पाथ की डिसेंडेंट होगी. साथ ही, इसे आउटपुट सेवा तय करेगी.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "false"

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

--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: ब्यौरा देखें

यह विकल्प, दी गई कॉन्फ़िगरेशन फ़ाइल की मदद से रिमोट कैश मेमोरी की कुंजी को मिटाने की सुविधा चालू करता है. यह फ़ाइल, टेक्स्ट फ़ॉर्मैट में प्रोटोकॉल बफ़र होनी चाहिए. इसके बारे में ज़्यादा जानने के लिए, src/main/protobuf/remote_scrubbing.proto देखें. इस सुविधा का मकसद, अलग-अलग प्लैटफ़ॉर्म पर एक्ज़ीक्यूट की जा रही कार्रवाइयों के बीच रिमोट/डिस्क कैश मेमोरी को शेयर करना है. हालांकि, ये कार्रवाइयां एक ही प्लैटफ़ॉर्म को टारगेट करती हैं. इसका इस्तेमाल बहुत सावधानी से करना चाहिए, क्योंकि गलत सेटिंग की वजह से कैश मेमोरी की एंट्री अनजाने में शेयर हो सकती हैं. इससे गलत बिल्ड बन सकते हैं. स्क्रबिंग से, कार्रवाई के तरीके पर कोई असर नहीं पड़ता. इससे सिर्फ़ यह तय होता है कि कार्रवाई के नतीजे को वापस पाने या सेव करने के लिए, रिमोट/डिस्क कैश मेमोरी की कुंजी की गिनती कैसे की जाती है. स्क्रब की गई कार्रवाइयां, रिमोट एक्ज़ीक्यूशन के साथ काम नहीं करती हैं. इसलिए, इन्हें हमेशा स्थानीय तौर पर ही एक्ज़ीक्यूट किया जाएगा. स्क्रबिंग के कॉन्फ़िगरेशन में बदलाव करने से, लोकल फ़ाइल सिस्टम या इंटरनल कैश मेमोरी में मौजूद आउटपुट अमान्य नहीं होते. जिन कार्रवाइयों पर असर पड़ा है उन्हें फिर से लागू करने के लिए, क्लीन बिल्ड की ज़रूरत होती है. इस सुविधा का इस्तेमाल करने के लिए, आपको --host_platform को --experimental_platform_in_output_dir (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --incompatible_strict_action_env (एनवायरमेंट वैरिएबल को सामान्य बनाने के लिए) के साथ सेट करना होगा.

--[no]guard_against_concurrent_changes default: "lite"

इसे 'full' पर सेट करें, ताकि रिमोट कैश में अपलोड करने से पहले, किसी कार्रवाई की सभी इनपुट फ़ाइलों के ctime की जांच की जा सके. ऐसा हो सकता है कि कुछ मामलों में Linux कर्नल, फ़ाइलों को लिखने में देरी करे. इससे फ़ॉल्स पॉज़िटिव मिल सकते हैं. डिफ़ॉल्ट रूप से, यह 'lite' पर सेट होता है. यह सिर्फ़ मुख्य रिपॉज़िटरी में मौजूद सोर्स फ़ाइलों की जांच करता है. इसे 'बंद है' पर सेट करने से, सभी जांच बंद हो जाती हैं. हमारा सुझाव है कि ऐसा न करें. ऐसा इसलिए, क्योंकि जब किसी सोर्स फ़ाइल में बदलाव किया जाता है, तब हो सकता है कि कैश मेमोरी में मौजूद डेटा खराब हो जाए. ऐसा तब होता है, जब कोई ऐसी कार्रवाई चल रही हो जिसमें उस फ़ाइल का इस्तेमाल इनपुट के तौर पर किया जा रहा हो.
टैग: execution

--[no]incompatible_remote_local_fallback_for_remote_cache डिफ़ॉल्ट: "false"

Whether --remote_local_fallback applies to --remote_cache.

--[no]incompatible_remote_use_new_exit_code_for_lost_inputs default: "true"

अगर इसे सही पर सेट किया जाता है, तो Bazel, रिमोट कैश मेमोरी से जुड़ी गड़बड़ियों के लिए नए एक्ज़िट कोड 39 का इस्तेमाल करेगा. इनमें कैश मेमोरी से डेटा हटाना भी शामिल है. ऐसा तब होगा, जब इन गड़बड़ियों की वजह से बिल्ड पूरा नहीं हो पाता.
टैग: incompatible_change

--[no]remote_accept_cached default: "true"

रिमोटली कैश मेमोरी में सेव किए गए ऐक्शन के नतीजों को स्वीकार करना है या नहीं.

--remote_build_event_upload=<all or minimal> default: "minimal"

अगर इसे 'all' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश में अपलोड किए जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो बीईपी से रेफ़र की गई लोकल आउटपुट फ़ाइलों को रिमोट कैश में अपलोड नहीं किया जाता. हालांकि, बीईपी के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों को अपलोड किया जाता है. जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का इस्तेमाल हमेशा किया जाता है. भले ही, वे रिमोट कैश में मौजूद न हों. डिफ़ॉल्ट रूप से 'minimal' पर सेट होता है.

--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

होस्टनेम और इंस्टेंस का नाम, जिसका इस्तेमाल bytestream:// यूआरआई में किया जाना है. ये यूआरआई, बिल्ड इवेंट स्ट्रीम में लिखे जाते हैं. इस विकल्प को तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इससे --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इसे सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.

--remote_cache=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कैशिंग एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. टीएलएस को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://bazel.build/remote/caching देखें

--[no]remote_cache_async default: "true"

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

--[no]remote_cache_compression डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो कैश मेमोरी के बड़े ऑब्जेक्ट को zstd की मदद से कंप्रेस/डिकंप्रेस करें. ऐसा तब करें, जब उनका साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.

--remote_cache_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

कैश मेमोरी के अनुरोधों में शामिल किए जाने वाले हेडर के बारे में बताएं: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.

--remote_default_exec_properties=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

डिफ़ॉल्ट exec प्रॉपर्टी सेट करें, ताकि अगर कोई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो उन्हें रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल किया जा सके.
टैग: affects_outputs

--remote_default_platform_properties=<a string> default: ""

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

--remote_download_regex=<a valid Java regular expression> कई बार इस्तेमाल किया गया हो

इस पैटर्न से मेल खाने वाले पाथ के रिमोट बिल्ड आउटपुट को डाउनलोड करने के लिए मजबूर करें. भले ही, --remote_download_outputs का इस्तेमाल किया गया हो या नहीं. इस फ़्लैग को दोहराकर, कई पैटर्न तय किए जा सकते हैं.
टैग: affects_outputs

--remote_downloader_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--remote_exec_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

ऐसा हेडर तय करें जिसे एक्ज़ीक्यूशन के अनुरोधों में शामिल किया जाएगा: --remote_exec_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.

--remote_execution_priority=<an integer> default: "0"

रिमोट तरीके से की जाने वाली कार्रवाइयों की प्राथमिकता. प्राथमिकता की खास वैल्यू का सिमैंटिक, सर्वर पर निर्भर करता है.

--remote_executor=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--remote_grpc_log=<a path> डिफ़ॉल्ट: ब्यौरा देखें

अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में, क्रम से लगाए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry प्रोटोबफ़ होते हैं. हर मैसेज के पहले एक वैरिएंट होता है, जो क्रम से लगाए गए अगले प्रोटोबफ़ मैसेज के साइज़ को दिखाता है. ऐसा LogEntry.writeDelimitedTo(OutputStream) तरीके से किया जाता है.

--remote_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

ऐसा हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू को कॉमा लगाकर अलग की गई सूची में बदल दिया जाएगा.

--remote_instance_name=<a string> default: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "false"

अगर रिमोट एक्सीक्यूशन काम नहीं करता है, तो क्या स्टैंडअलोन लोकल एक्सीक्यूशन की रणनीति पर वापस जाना है.

--remote_local_fallback_strategy=<a string> default: "local"

अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

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

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

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

रिमोट कैश/एक्ज़ीक्यूटर से एक साथ कनेक्ट किए जा सकने वाले कनेक्शन की ज़्यादा से ज़्यादा संख्या को सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एक्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर 100 से ज़्यादा एक साथ किए गए अनुरोधों को हैंडल कर सकता है. इसे --remote_max_concurrency_per_connection कंट्रोल करता है. इसलिए, Bazel एक साथ `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations

--remote_proxy=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--remote_result_cache_priority=<an integer> default: "0"

रिमोट ऐक्शन की प्राथमिकता, जिसे रिमोट कैश मेमोरी में सेव किया जाना है. प्राथमिकता की खास वैल्यू का सिमैंटिक, सर्वर पर निर्भर करता है.

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

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

--remote_retry_max_delay=<An immutable length of time.> default: "5s"

रीमोट तरीके से फिर से कोशिश करने के बीच ज़्यादा से ज़्यादा बैकऑफ़ डिले. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--remote_timeout=<An immutable length of time.> default: "60s"

रिमोट एक्ज़ीक्यूशन और कैश मेमोरी के कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश के लिए, यह कनेक्ट और रीड, दोनों के लिए टाइम आउट होता है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट को शामिल नहीं किया जाता है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--[no]remote_upload_local_results default: "true"

अगर रिमोट कैश मेमोरी इस सुविधा के साथ काम करती है और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या स्थानीय तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.

--[no]remote_verify_downloads default: "true"

इस विकल्प को सही पर सेट करने पर, Bazel सभी रिमोट डाउनलोड के हैश का योग कंप्यूट करेगा. साथ ही, अगर रिमोट से कैश की गई वैल्यू, अनुमानित वैल्यू से मेल नहीं खाती हैं, तो उन्हें खारिज कर देगा.

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

--[no]allow_analysis_cache_discard default: "true"

अगर बिल्ड सिस्टम में बदलाव की वजह से, विश्लेषण की कैश मेमोरी को खारिज किया जा रहा है, तो इस विकल्प को 'गलत है' पर सेट करने से Bazel बंद हो जाएगा. हालांकि, बिल्ड जारी रहेगा. अगर 'discard_analysis_cache' भी सेट है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit

--auto_output_filter=<none, all, packages or subpackages> डिफ़ॉल्ट: "none"

अगर --output_filter के बारे में नहीं बताया गया है, तो इस विकल्प की वैल्यू का इस्तेमाल करके फ़िल्टर अपने-आप बन जाता है. अनुमति वाली वैल्यू ये हैं: 'none' (किसी भी चीज़ को फ़िल्टर न करें / सब कुछ दिखाएं), 'all' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'packages' (Blaze कमांड लाइन पर बताए गए पैकेज में मौजूद नियमों से आउटपुट शामिल करें), और 'subpackages' ('packages' की तरह, लेकिन इसमें सब-पैकेज भी शामिल हैं). 'packages' और 'subpackages' वैल्यू के लिए, //java/foo और //javatests/foo को एक पैकेज माना जाता है'.

--[no]build_manual_tests डिफ़ॉल्ट: "false"

'मैन्युअल' के तौर पर टैग किए गए टेस्ट टारगेट को बनाने के लिए मजबूर करता है. 'मैन्युअल' टेस्ट को प्रोसेस से बाहर रखा जाता है. इस विकल्प से, उन्हें बनाया जा सकता है, लेकिन लागू नहीं किया जा सकता.

--build_tag_filters=<comma-separated list of options> default: ""

कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. जिन टैग को शामिल नहीं करना है उन्हें तय करने के लिए, हर टैग से पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें कम से कम एक शामिल किया गया टैग हो और कोई भी बाहर रखा गया टैग न हो. इस विकल्प से, 'test' कमांड के साथ लागू किए गए टेस्ट के सेट पर कोई असर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों के हिसाब से लागू किए जाते हैं. उदाहरण के लिए, '--test_tag_filters'

--[no]build_tests_only डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.

--combined_report=<none or lcov> डिफ़ॉल्ट: "none"

इससे, कवरेज की कुल रिपोर्ट का टाइप तय किया जाता है. फ़िलहाल, सिर्फ़ LCOV फ़ॉर्मैट इस्तेमाल किया जा सकता है.

--[no]compile_one_dependency डिफ़ॉल्ट: "false"

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

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD को मिटा दिया है, तो बिल्ड सिस्टम को '//x:y/z' लेबल मिलने पर शिकायत हो सकती है. ऐसा तब होता है, जब यह लेबल अब भी किसी अन्य package_path एंट्री से मिला हो. --deleted_packages x/y विकल्प का इस्तेमाल करने पर, यह समस्या नहीं होती.

--[no]discard_analysis_cache डिफ़ॉल्ट: "false"

विश्लेषण पूरा होने के तुरंत बाद, विश्लेषण की कैश मेमोरी को खारिज कर दें. इससे मेमोरी का इस्तेमाल ~10% तक कम हो जाता है. हालांकि, इसके बाद इंक्रीमेंटल बिल्ड बनाने में ज़्यादा समय लगता है.

--disk_cache=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

--embed_label=<a one-line string> default: ""

सोर्स कंट्रोल के वर्शन या रिलीज़ लेबल को बाइनरी में एम्बेड करें

--execution_log_binary_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इस फ़ाइल में, src/main/protobuf/spawn.proto के मुताबिक, एक्ज़ीक्यूट किए गए स्पॉन को लंबाई के हिसाब से सीमांकित किए गए SpawnExec प्रोटो के तौर पर लॉग करें. --execution_log_compact_file को प्राथमिकता दें. यह काफ़ी छोटा होता है और इसे जनरेट करने में कम खर्च आता है. इससे जुड़े फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--execution_log_compact_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में एक्ज़ीक्यूट किए गए स्पॉन को, लंबाई के हिसाब से सीमा तय किए गए ExecLogEntry प्रोटो के तौर पर लॉग करें. पूरी फ़ाइल को zstd फ़ॉर्मैट में कंप्रेस किया गया है. इससे जुड़े फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; एक-दूसरे से अलग), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--execution_log_json_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में SpawnExec protos के न्यूलाइन-डीलिमिटेड JSON फ़ॉर्मैट के तौर पर, एक्ज़ीक्यूट किए गए स्पॉन को लॉग करें. --execution_log_compact_file को प्राथमिकता दें. यह काफ़ी छोटा होता है और इसे जनरेट करने में कम खर्च आता है. इससे जुड़े फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; एक-दूसरे से अलग), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--[no]execution_log_sort default: "true"

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

--[no]expand_test_suites default: "true"

विश्लेषण करने से पहले, test_suite के टारगेट को उनके कॉम्पोनेंट टेस्ट में बदलें. इस फ़्लैग को चालू करने पर (डिफ़ॉल्ट रूप से), नेगेटिव टारगेट पैटर्न, टेस्ट सुइट से जुड़े टेस्ट पर लागू होंगे. ऐसा न करने पर, वे लागू नहीं होंगे. इस फ़्लैग को बंद करने से, कमांड लाइन पर टॉप-लेवल के पहलुओं को लागू करने में मदद मिलती है. इसके बाद, वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis

--experimental_disk_cache_gc_idle_delay=<An immutable length of time.> default: "5m"

डिस्क कैश मेमोरी की गार्बेज कलेक्शन की प्रोसेस शुरू होने से पहले, सर्वर को कितने समय तक बंद रहना चाहिए. कचरा इकट्ठा करने की नीति तय करने के लिए, --experimental_disk_cache_gc_max_size और/या --experimental_disk_cache_gc_max_age सेट करें.

--experimental_disk_cache_gc_max_age=<An immutable length of time.> default: "0"

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

--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier> default: "0"

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

--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: ""

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

--[no]experimental_extra_action_top_level_only डिफ़ॉल्ट: "false"

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

--experimental_spawn_scheduler

कार्रवाइयों को स्थानीय और रिमोट तरीके से एक साथ चलाकर, डाइनैमिक तरीके से एक्ज़ीक्यूट करने की सुविधा चालू करें. Bazel, हर कार्रवाई को स्थानीय और रिमोट, दोनों जगहों पर शुरू करता है. इसके बाद, वह उस कार्रवाई को चुनता है जो सबसे पहले पूरी होती है. अगर किसी कार्रवाई के लिए वर्कर की ज़रूरत होती है, तो स्थानीय कार्रवाई को पर्सिस्टेंट वर्कर मोड में चलाया जाएगा. किसी कार्रवाई के लिए डाइनैमिक तरीके से एक्ज़ीक्यूशन की सुविधा चालू करने के लिए, `--internal_spawn_scheduler` और `--strategy=<mnemonic>=dynamic` फ़्लैग का इस्तेमाल करें.
बढ़कर यह हो जाता है:
  --internal_spawn_scheduler
  --spawn_strategy=dynamic

--[no]fetch default: "true"

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

--local_termination_grace_seconds=<an integer> default: "15"

टाइम आउट की वजह से किसी लोकल प्रोसेस को बंद करने और उसे ज़बरदस्ती बंद करने के बीच इंतज़ार करने का समय.

--package_path=<colon-separated list of options> default: "%workspace%"

पैकेज कहां ढूंढने हैं, इसकी कोलन से अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस के हिसाब से होते हैं. अगर इसे शामिल नहीं किया जाता है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट इस्तेमाल किया जाता है.

--[no]show_loading_progress default: "true"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--test_lang_filters=<comma-separated list of options> default: ""

इसमें, कॉमा लगाकर अलग की गई टेस्ट भाषाओं की सूची दी जाती है. हर भाषा से पहले '-' का इस्तेमाल करके, उन भाषाओं को शामिल न करने के बारे में बताया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जो बताई गई भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test नियम में मौजूद भाषा के प्रीफ़िक्स के जैसा होना चाहिए. उदाहरण के लिए, 'cc', 'java', 'py' वगैरह. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.

--test_size_filters=<comma-separated list of values: small, medium, large, or enormous> default: ""

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

--test_tag_filters=<comma-separated list of options> default: ""

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

--test_timeout_filters=<comma-separated list of values: short, moderate, long, or eternal> default: ""

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

--workspace_status_command=<path> default: ""

यह कमांड, बिल्ड की शुरुआत में लागू की जाती है. इससे की/वैल्यू पेयर के तौर पर, वर्कस्पेस की स्थिति के बारे में जानकारी मिलती है. पूरी जानकारी के लिए, उपयोगकर्ता का मैन्युअल देखें. उदाहरण के लिए, tools/buildstamp/get_workspace_status भी देखें.

बिल्ड के एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]experimental_inprocess_symlink_creation default: "true"

सिंबॉलिक लिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे तौर पर कॉल करना है या हेल्पर प्रोसेस को सौंपना है.
टैग: loading_and_analysis, execution, experimental

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false"

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.
टैग: execution, experimental

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट की कार्रवाइयों को रिमोट किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false"

अगर यह सही है, तो Bazel, नए स्पॉन में टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग चलाएगा.
टैग: execution, experimental

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false"

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

--[no]incompatible_modify_execution_info_additive डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, --modify_execution_info फ़्लैग के कई विकल्प जोड़ने पर, सभी विकल्प लागू हो जाते हैं. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो

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

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू रखें.
इनके तौर पर दिखता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

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

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है, तो Bazel, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा. टेस्ट एक्ज़ेक ग्रुप का नहीं.
टैग: execution

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

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android"

android_binary नियमों के लिए, मेनिफ़ेस्ट मर्जर को चुनने का विकल्प. यह फ़्लैग, लेगसी मर्जर से Android मेनिफ़ेस्ट मर्जर पर ट्रांज़िशन करने में मदद करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_platforms=<a build target label> default: ""

यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--apple_crosstool_top=<a build target label> default: "@bazel_tools//tools/cpp:toolchain"

Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs

--cc_output_directory_tag=<a string> default: ""

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

--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger"

यह उस बाइनरी का पाथ है जिसका इस्तेमाल रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी मौजूद हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:lcov_merger' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए जाने वाले बाइनरी का पाथ. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें सिर्फ़ एक फ़ाइल, यानी कि बाइनरी मौजूद हो. डिफ़ॉल्ट रूप से, इसकी वैल्यू '//tools/test:coverage_report_generator' होती है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support"

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

--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> कई बार इस्तेमाल किया गया हो

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

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "false"

अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution, experimental

--[no]experimental_prefer_mutual_xcode default: "true"

अगर यह सही है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए Xcode के लोकल वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state, experimental

--extra_execution_platforms=<comma-separated list of options> default: ""

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

--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

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

--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

यह फ़्लैग कोई कार्रवाई नहीं करता. आने वाले समय में इसे हटा दिया जाएगा.
टैग: loading_and_analysis, execution

--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

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

--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform"

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

--[no]incompatible_bazel_test_exec_run_under डिफ़ॉल्ट: "false"

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

--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true"

अगर यह वैल्यू सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाएं चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false"

ऐपल के नियमों (Starlark और नेटिव) के लिए, Apple SDK टूल चुनने के लिए टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive default: "true"

अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से, लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "false"

अगर यह सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change

--[no]interface_shared_objects default: "true"

अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी 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 main workspace-relative path> default: ""

यह मैपिंग फ़ाइल की जगह है. इससे पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है. साथ ही, अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसे फ़्लैग सेट करने हैं. यह मुख्य Workspace रूट के हिसाब से होना चाहिए. डिफ़ॉल्ट रूप से, यह 'platform_mappings' पर सेट होता है. यह फ़ाइल, सीधे तौर पर वर्कस्पेस रूट में होती है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable

--platforms=<a build target label> default: ""

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

--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

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

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

--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes"

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

ऐसे विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:

--[no]apple_generate_dsym डिफ़ॉल्ट: "false"

डीबग सिंबल (.dSYM) वाली फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines

--[no]build_runfile_links default: "true"

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

--[no]build_runfile_manifests default: "true"

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

--[no]build_test_dwp डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h"

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

--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc"

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

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "false"

proto_library में, Java API के अन्य वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "false"

कंपाइलेशन के आउटपुट के तौर पर, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति सेव करें.
टैग: affects_outputs, experimental

--fission=<a set of compilation modes> डिफ़ॉल्ट: "no"

इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल कौनसे कंपाइलेशन मोड करते हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.
टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम, डेटा डिपेंडेंसी के <code>DefaultInfo.files</code> को अपने रनफ़ाइल में जोड़ते हैं. यह Starlark नियमों के लिए सुझाए गए व्यवहार से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest डिफ़ॉल्ट: "false"

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

--[no]incompatible_filegroup_runfiles_for_data डिफ़ॉल्ट: "false"

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

--[no]legacy_external_runfiles डिफ़ॉल्ट: "false"

अगर यह सही है, तो .runfiles/repo के अलावा, .runfiles/wsname/external/repo में बाहरी रिपॉज़िटरी के लिए, रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं.
टैग: affects_outputs

--[no]objc_generate_linkmap डिफ़ॉल्ट: "false"

यह तय करता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs

--[no]save_temps डिफ़ॉल्ट: "false"

अगर यह विकल्प सेट किया जाता है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C) और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.
टैग: affects_outputs

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

--action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो

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

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs

--[no]android_databinding_use_androidx default: "true"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args default: "true"

3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> default: "off"

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

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical"

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

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

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

--[no]build_python_zip default: "auto"

Build python executable zip; on on Windows, off on other platforms
Tags: affects_outputs

--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

--[no]collect_code_coverage डिफ़ॉल्ट: "false"

अगर ऐसा बताया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

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

--conlyopt=<a string> कई बार इस्तेमाल किया गया हो

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

--copt=<a string> कई बार इस्तेमाल किया गया हो

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

--cpu=<a string> default: ""

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

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--cxxopt=<a string> कई बार इस्तेमाल किया गया हो

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

--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--dynamic_mode=<off, default or fully> default: "default"

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

--[no]enable_propeller_optimize_absolute_paths default: "true"

अगर यह सेट है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.
टैग: affects_outputs

--[no]enable_remaining_fdo_absolute_paths default: "true"

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

--[no]enable_runfiles default: "auto"

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

--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो

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

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

एपीके में Java संसाधनों को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 default: "true"

android databinding v2 का इस्तेमाल करें. यह फ़्लैग कोई कार्रवाई नहीं करता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "false"

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

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "false"

dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental

--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.
टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "false"

अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off, content or strip> default: "off"

आउटपुट ट्री में किस मॉडल का इस्तेमाल किया जाए, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, पाथ मैपिंग में ऑप्ट-इन कर सकते हैं. इसके लिए, उन्हें 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़नी होगी.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री, label=value के फ़ॉर्म में होनी चाहिए. इसमें label का मतलब प्लैटफ़ॉर्म से है और values का मतलब आउटपुट पाथ में इस्तेमाल किए जाने वाले पसंदीदा छोटे नाम से है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental

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

अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो platforms विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_override_name_platform_in_output_dir ने मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर शॉर्टनेम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental

--[no]experimental_py_binaries_include_label डिफ़ॉल्ट: "false"

py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.
टैग: affects_outputs, experimental

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

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

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस ह्यूरिस्टिक में कुछ कमियां हैं. हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करें.
टैग: affects_outputs, experimental

--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है. जैसे, `//foo/bar:file.afdo`. आपको संबंधित पैकेज में `exports_files` डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है. साथ ही, यह `fdo_profile` टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, `fdo_profile` नियम की जगह लागू होगा.
टैग: affects_outputs

--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कैश मेमोरी प्रीफ़ेच करने के लिए, हिंट का इस्तेमाल करें.
टैग: affects_outputs

--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--features=<a string> कई बार इस्तेमाल किया गया हो

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

--[no]force_pic डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय पीआईसी प्री-बिल्ट लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.
टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो

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

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

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

--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में C सोर्स फ़ाइलों (C++ नहीं) को कंपाइल करते समय, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_copt=<a string> कई बार इस्तेमाल किया गया हो

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

--host_cpu=<a string> default: ""

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

--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

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

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

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

--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो

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

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है. हालांकि, bar.cc में यह विकल्प नहीं जोड़ा जाता.
टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false"

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, exec ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

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

--[no]instrument_test_targets डिफ़ॉल्ट: "false"

कवरेज चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल किए गए टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, दिए गए रेगुलर एक्सप्रेशन (रेगेक्स) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि सिर्फ़ गैर-टेस्ट नियमों को लागू किया जाता है, जब तक कि --instrument_test_targets चालू न हो.
टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

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

--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

--[no]legacy_whole_archive default: "true"

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

--linkopt=<a string> कई बार इस्तेमाल किया गया हो

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

--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ बैकएंड के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto).
टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple macOS के बाइनरी फ़ाइलें बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.
टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, macOS का कम से कम यह वर्शन होना चाहिए. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.
टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "false"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

--objccopt=<a string> कई बार इस्तेमाल किया गया हो

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

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto). इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों के LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.
टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

'test' और 'run' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण ये हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

--[no]share_native_deps default: "true"

अगर यह वैल्यू सही है, तो एक जैसी फ़ंक्शनैलिटी वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "false"

बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.
टैग: affects_outputs

--stripopt=<a string> कई बार इस्तेमाल किया गया हो

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

--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, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करेगा:

--[no]check_licenses डिफ़ॉल्ट: "false"

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

--[no]check_visibility default: "true"

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

--[no]desugar_for_android default: "true"

Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "false"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 के साथ काम करने वाली लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints default: "true"

यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की डिपेंडेंसी ऐसे एनवायरमेंट के साथ काम नहीं करती हैं जिनके साथ टारगेट काम करता है, तो गड़बड़ियों की जानकारी देता है
टैग: build_file_semantics

--[no]experimental_check_desugar_deps default: "true"

Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental

--experimental_import_deps_checking=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कोई कार्रवाई नहीं की गई. इसे सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए रखा गया है
टैग: loading_and_analysis

--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है"

इसे चालू करने पर, यह लागू किया जाता है कि java_binary नियम में, क्लासपाथ पर एक ही क्लास फ़ाइल का एक से ज़्यादा वर्शन नहीं हो सकता. इस नीति के उल्लंघन की वजह से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.
टैग: loading_and_analysis

--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default"

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

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

अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "false"

इस सेटिंग के चालू होने पर, टूलचेन के लागू करने के तरीके पर भी यह जांच लागू होती है कि वह दिखता है या नहीं.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false"

यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_python_disable_py2 default: "true"

अगर यह वैल्यू 'सही है' पर सेट है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]one_version_enforcement_on_java_tests default: "true"

इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.
टैग: loading_and_analysis

--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

--incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis

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

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

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

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

--strict_public_imports=<off, warn, error, strict or default> default: "off"

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

--[no]strict_system_includes डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही है' पर सेट है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.
टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "environment" नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

ऐसे विकल्प जिनसे बिल्ड के हस्ताक्षर करने के आउटपुट पर असर पड़ता है:

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2"

APK पर साइन करने के लिए इस्तेमाल किया जाने वाला तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements default: "true"

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

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

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

--[no]incompatible_disallow_legacy_py_provider default: "true"

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

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "false"

अगर यह सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "false"

जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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

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

If true, an analysis failure of a rule target results in the target's propagation of an instance of AnalysisFailureInfo containing the error description, instead of resulting in a build failure.
टैग: loading_and_analysis, experimental

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

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

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

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

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की रकम को बदल देंगे. वैल्यू, HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]<float> (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4) भी जोड़ा जा सकता है. हालांकि, यह ज़रूरी नहीं है. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में बताए गए संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false"

android_test को तेज़ी से पूरा करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "false"

ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. उदाहरण के लिए, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची पाई जा सकती है.
टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर पर चलाने या टेस्ट करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो

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

--test_env=<a 'name=value' assignment with an optional value part> कई बार इस्तेमाल किया गया हो

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

--test_timeout=<a single integer or comma-separated list of 4 integers> default: "-1"

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

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "false"

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

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

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false"

ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद क्लास को हटाया जा सके.
टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files default: "true"

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलें सीधे रिमोट बिल्ड नोड से मेमोरी में पास की जाएंगी. इन्हें डिस्क में नहीं लिखा जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files default: "true"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly default: "true"

इस विकल्प को चालू करने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए, टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़ी समस्याओं को कम करना है. ऐसा तब होता है, जब टेस्ट नहीं किए गए नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू 'गलत है' पर सेट है, तो इसका कोई असर नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "false"

यह विकल्प चालू होने पर, cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing default: "true"

यह हर जार फ़ाइल के लिए, अलग से डेक्सिंग का ज़्यादातर काम करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning default: "true"

अगर इस फ़्लैग को सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल किया जाएगा. इससे objc कंपाइलर को पास किए गए इनपुट के सेट को कम किया जा सकेगा.
टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "false"

जब टारगेट //a:a बनाया जा रहा हो, तब उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग चालू हो.
टैग: execution

--[no]trim_test_configuration default: "true"

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

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

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*"

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

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

--flag_alias=<a 'name=value' flag alias> कई बार इस्तेमाल किया गया हो

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

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

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

--[no]incompatible_py2_outputs_are_suffixed default: "true"

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

--[no]incompatible_py3_is_default default: "true"

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

--[no]incompatible_use_python_toolchains default: "true"

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

--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

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

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

--[no]cache_test_results [-t] default: "auto"

अगर इसे 'auto' पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Bazel, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है. 'नहीं' पर सेट होने पर, Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.

--[no]experimental_cancel_concurrent_tests default: "never"

अगर 'on_failed' या 'on_passed' विकल्प चुना जाता है, तो Blaze उस नतीजे के साथ पहली बार चलने वाले टेस्ट को रद्द कर देगा. यह विकल्प सिर्फ़ --runs_per_test_detects_flakes के साथ काम करता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false"

अगर सही है, तो clang के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_j2objc_header_map default: "true"

J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental

--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "false"

क्या हेडर पाथ को छोटा करके जनरेट करना है. इसमें "_j2objc" के बजाय "_ios" का इस्तेमाल किया जाता है.
टैग: affects_outputs, experimental

--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "javabuilder"

इससे Java कंपाइलेशन के लिए क्लासपाथ कम हो जाते हैं.

--[no]experimental_java_header_compilation_direct_deps डिफ़ॉल्ट: "false"

हेडर और सामान्य कंपाइलेशन के लिए अलग-अलग आउटपुट इस्तेमाल करें.
टैग: experimental

--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं की गई, इसे सिर्फ़ पुराने वर्शन के साथ काम करने के लिए रखा गया है
टैग: affects_outputs, experimental

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

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

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

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

--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो

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

--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो

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

--[no]incompatible_check_sharding_support default: "true"

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

--[no]incompatible_exclusive_test_sandboxed default: "true"

अगर यह वैल्यू सही है, तो सैंडबॉक्स की गई रणनीति के साथ खास टेस्ट चलाए जाएंगे. 'local' टैग जोड़कर, स्थानीय तौर पर सिर्फ़ एक टेस्ट रन करें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है, तो Bazel ऐसे एनवायरमेंट का इस्तेमाल करता है जिसमें PATH के लिए स्टैटिक वैल्यू होती है. साथ ही, यह LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने से, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा. ऐसा तब होगा, जब शेयर की गई कैश मेमोरी का इस्तेमाल किया जा रहा हो.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

--java_debug

इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इनमें बदल जाता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps default: "true"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करें. फ़िलहाल, यह जानकारी कंपाइल-टाइम क्लासपाथ के लिए जनरेट की जाती है.

--[no]java_header_compilation default: "true"

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

--java_language_version=<a string> default: ""

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

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

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

--java_runtime_version=<a string> default: "local_jdk"

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

--javacopt=<a string> कई बार इस्तेमाल किया गया हो

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

--jvmopt=<a string> कई बार इस्तेमाल किया गया हो

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

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह एक बाइनरी तय करता है. इसका इस्तेमाल, उन क्लास की सूची जनरेट करने के लिए किया जाता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह बिना शार्डिंग के डेक्सिंग करने के लिए, बाइनरी तय करता है.

--plugin=<a build target label> कई बार इस्तेमाल किया गया हो

बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

इस विकल्प से यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.

--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis

--[no]proto_profile default: "true"

प्रोफ़ाइल_पाथ को प्रोटो कंपाइलर को पास करना है या नहीं.
टैग: affects_outputs, loading_and_analysis

--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain"

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

--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

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

--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जो बताता है कि Java protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जो बताता है कि JavaLite protos को कैसे कंपाइल किया जाए
टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> कई बार इस्तेमाल किया गया हो

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

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

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

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

--test_arg=<a string> कई बार इस्तेमाल किया गया हो

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

--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें

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

--test_result_expiration=<an integer> default: "-1"

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

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

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

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit"

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

--tool_java_language_version=<a string> default: ""

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

--tool_java_runtime_version=<a string> default: "remotejdk_11"

The Java runtime version used to execute tools during the build

--[no]use_ijars default: "true"

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