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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--host_jvm_debug

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एचटीटीपी डाउनलोड की कोशिशों के लिए ज़्यादा से ज़्यादा टाइम आउट. 0 वैल्यू का मतलब है कि टाइम आउट की कोई तय सीमा नहीं है.
टैग: bazel_internal_configuration

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

एचटीटीपी के ज़रिए, एक साथ डाउनलोड किए जा सकने वाले आइटम की ज़्यादा से ज़्यादा संख्या.
टैग: bazel_internal_configuration

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

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

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

अगर यह 'गलत है' पर सेट है, तो WORKSPACE में नेटिव रिपॉज़िटरी के नियमों का इस्तेमाल किया जा सकता है. अगर यह 'सही है' पर सेट है, तो Starlark रिपॉज़िटरी के नियमों का इस्तेमाल करना होगा. नेटिव रिपॉज़िटरी के नियमों में local_repository, new_local_repository, local_config_platform, और android_sdk_repository शामिल हैं.
टैग: bazel_internal_configuration

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

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

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

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

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

--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "गलत"

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

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

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

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

--remote_download_all

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

टैग: affects_outputs

--remote_download_minimal

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

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> डिफ़ॉल्ट: "toplevel"

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

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

रिमोट बिल्ड आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबल लिंक बनाएं. सिंबल लिंक का टारगेट, टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये क्रमशः ऑब्जेक्ट के हैश और बाइट में साइज़ में बदल जाते हैं. उदाहरण के लिए, ये सिंबल लिंक किसी ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर सीएएस से ऑब्जेक्ट लोड करता है.
टैग: 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 डिफ़ॉल्ट: "सही"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--incompatible_autoload_externally=<comma-separated set of options> डिफ़ॉल्ट: "+@rules_python,+JavaInfo,+JavaPluginInfo,ProguardSpecProvider,java_binary,java_import,java_library,java_plugin,java_test,+java_runtime,+java_toolchain,+java_package_configuration,@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" का कोई सूची आइटम, किसी भी ऑटोलोडिंग को ट्रिगर नहीं करता है. हालांकि, इससे पूरे वर्कस्पेस में foo के Bazel से तय किए गए वर्शन को ऐक्सेस नहीं किया जा सकता. इसका इस्तेमाल यह पुष्टि करने के लिए किया जाता है कि वर्कस्पेस, 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 डिफ़ॉल्ट: "सही"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<module name>=<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>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

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

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

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

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

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

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

अगर यह वैल्यू 'गलत' है, तो बिल्ड पूरा होने पर 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 होती है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, 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 सेट की गई सीमा से ज़्यादा है, तो मामूली GC इवेंट होने पर, वह हर बार इस सीमा तक अनावश्य Skyframe स्टेटस को छोड़ देगा. डिफ़ॉल्ट रूप से, यह वैल्यू 10 होती है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, मामूली जीसी इवेंट होने पर Skyframe की स्थिति को ड्रॉप नहीं किया जाएगा. साथ ही, रीटेन किए गए हेप के प्रतिशत के थ्रेशोल्ड को पार करने पर भी ऐसा नहीं किया जाएगा.
टैग: host_machine_resource_optimizations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह एक मैसेज में BEP को भेजे जाने वाले stdout या stderr का ज़्यादा से ज़्यादा साइज़ तय करता है.
टैग: affects_outputs

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

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

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

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

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

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

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

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

--bes_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete"

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

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

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

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

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

--build_event_binary_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete"

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

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

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

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

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

--build_event_json_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete"

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

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

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

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

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

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

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

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

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

--build_event_text_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> डिफ़ॉल्ट: "wait_for_upload_complete"

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

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

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

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

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

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

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

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

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

--experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JDK21+ जेवीएम हेप मेमोरी कलेक्शन के लिए, मैच करने वाले लॉजिक को बदलने के लिए रेगुलर एक्सप्रेशन. हम साफ़ मेमोरी मेट्रिक पाने के लिए, G1 GC के इंप्लीमेंटेशन की जानकारी पर भरोसा कर रहे हैं. इस विकल्प की मदद से, हम बाइनरी रिलीज़ का इंतज़ार किए बिना, उस इंप्लीमेंटेशन में हुए बदलावों को अपना सकते हैं. JDK Matcher.find() को पास किया गया

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "failure"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

किसी ऐक्शन की इनपुट फ़ाइलों को रिमोट कैश मेमोरी में अपलोड करने से पहले, उनकी ctime की जांच करने की सुविधा बंद करने के लिए, इसे बंद करें. कुछ मामलों में, Linux kernel फ़ाइलों को लिखने में देरी कर सकता है. इस वजह से, गलत नतीजे मिल सकते हैं.

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

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

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

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

--experimental_remote_cache_ttl=<An immutable length of time.> डिफ़ॉल्ट: "3h"

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

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

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

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

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

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

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

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

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

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

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

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

रिमोट तरीके से प्रोसेस करने के लिए, keepalive का इस्तेमाल करना है या नहीं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "minimal"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर यह सही है, तो 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.> डिफ़ॉल्ट: "5m"

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

--experimental_disk_cache_gc_max_age=<An immutable length of time.> डिफ़ॉल्ट: "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> डिफ़ॉल्ट: "0"

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

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

प्रयोग के लिए बने नियम एक्सटेंशन एपीआई और सबनियम एपीआई चालू करना
टैग: loading_and_analysis, experimental

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

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

--google_auth_scopes=<comma-separated list of options> डिफ़ॉल्ट: "https://www.googleapis.com/auth/cloud-platform"

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

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

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

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

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

--grpc_keepalive_time=<An immutable length of time.> डिफ़ॉल्ट: जानकारी देखें

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

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

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

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

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

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

टर्मिनल के टाइटल में, निर्देश की प्रोग्रेस दिखाएं. एक से ज़्यादा टर्मिनल टैब होने पर, यह देखने के लिए कि bazel क्या कर रहा है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Analyze-profile के विकल्प

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

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

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

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

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

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

Aquery के विकल्प

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर यह सुविधा चालू है, तो एक से ज़्यादा --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 के ऐसे टूल चालू करना जो लगातार काम करते हैं और एक से ज़्यादा काम करते हैं. जैसे, डीकंपाइल करना, डीसुगर करना, और संसाधन प्रोसेस करना.
इस तरह बड़ा होता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ऑपरेटिंग सिस्टम का वह कम से कम वर्शन जिसे आपका कंपाइलेशन टारगेट करता है.
टैग: loading_and_analysis, affects_outputs

--platform_mappings=<a main workspace-relative path> डिफ़ॉल्ट: ""

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

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

मौजूदा निर्देश के लिए टारगेट किए गए प्लैटफ़ॉर्म के बारे में बताने वाले, प्लैटफ़ॉर्म के नियमों के लेबल.
टैग: 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> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"

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

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

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

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

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

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

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

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

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

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

--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h"

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

--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Python के लिए, ज़िप फ़ाइल में प्रोग्राम को चलाने की सुविधा जोड़ना; Windows पर चालू, अन्य प्लैटफ़ॉर्म पर बंद करना
टैग: affects_outputs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

APK में जावा संसाधनों को कंप्रेस करना
टैग: affects_outputs, loading_and_analysis, experimental

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

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

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

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

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

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

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

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

--experimental_objc_fastbuild_options=<comma-separated list of options> डिफ़ॉल्ट: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc फ़ास्टबिल्ड कंपाइलर के विकल्पों के तौर पर किया जाता है.
टैग: action_command_lines

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

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

--experimental_output_paths=<off, content or strip> डिफ़ॉल्ट: "बंद"

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

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

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

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

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

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

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

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

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

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

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

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

कैश मेमोरी में प्रीफ़ेच करने के सुझावों का इस्तेमाल करें.
टैग: affects_outputs

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

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

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

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

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

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

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

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

--host_compilation_mode=<fastbuild, dbg or opt> डिफ़ॉल्ट: "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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

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

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

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

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

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

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

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

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

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

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

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. option_1 से option_n तक, मनमुताबिक कमांड लाइन के विकल्प हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

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

इस विकल्प के चालू होने पर, नियम के तहत इस्तेमाल किए गए हर टूलचेन के लिए, एक एक्सेक्यूट ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों में `टूलचेन` पैरामीटर की जानकारी देनी होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change

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

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

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

कवरेज चालू होने पर, यह तय करता है कि टेस्ट नियमों को इंस्ट्रूमेंट करना है या नहीं. सेट होने पर, --instrumentation_filter से शामिल किए गए टेस्ट नियमों को इंस्ट्रूमेंट किया जाता है. ऐसा न करने पर, टेस्ट के नियमों को कवरेज इंस्ट्रूमेंटेशन से हमेशा बाहर रखा जाता है.
टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/javatests[/:],-/test/java[/:]"

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

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

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

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

ios_application बनाने के लिए, कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची. इसका नतीजा एक यूनिवर्सल बाइनरी होता है, जिसमें सभी तय किए गए आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis

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

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

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

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

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

एलटीओ बैकएंड चरण (--features=thin_lto में) पर जाने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

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

एलटीओ को इंडेक्स करने के चरण पर जाने के लिए अन्य विकल्प (--features=thin_lto में).
टैग: action_command_lines, affects_outputs

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

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

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

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

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

memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

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

अगर यह सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS तय करें.
टैग: action_command_lines

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

लिंक की गई बाइनरी पर, सिंबल और डेड-कोड हटाने की प्रोसेस की जानी चाहिए या नहीं. अगर इस फ़्लैग और --compilation_mode=opt, दोनों को तय किया जाता है, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

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

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

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. option_1 से option_n तक, मनमुताबिक कमांड लाइन के विकल्प हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड (--features=thin_lto में) को चुनिंदा तौर पर पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. option_1 से option_n, कमांड लाइन के मनमुताबिक विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, bar.o को छोड़कर //foo/ में मौजूद सभी o फ़ाइलों की LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

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

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

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

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

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

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

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

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

--run_under=<a prefix in front of command> डिफ़ॉल्ट: जानकारी देखें

'टेस्ट' और 'रन' निर्देशों के लिए, एक्सीक्यूटेबल के पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और प्रोग्राम चलाने के लिए इस्तेमाल की जाने वाली कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी ऐसे टारगेट का लेबल भी हो सकता है जिसे चलाया जा सकता है. कुछ उदाहरण: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

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

अगर यह सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के बीच शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

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

तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल स्टोर करने की जगह की जानकारी वगैरह के साथ बाइनरी को स्टैंप करें.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि --compilation_mode=fastbuild के लिए, स्ट्रिप करें.
टैग: affects_outputs

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

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

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

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

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

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

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

डेक्स करने से पहले, Java 8 के बाइटकोड को डीसुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

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

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

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

यह जांच करता है कि हर टारगेट किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट में ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की रिपोर्ट करता है
टैग: build_file_semantics

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

Android बाइनरी लेवल पर, सही तरीके से डी-शुगर करने की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental

--experimental_import_deps_checking=<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"

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

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

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

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

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

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

अगर यह विकल्प चालू है, तो नेटिव Android नियमों का सीधे तौर पर इस्तेमाल बंद हो जाता है. कृपया https://github.com/bazelbuild/rules_android पर मौजूद, Starlark Android नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change

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

काम नहीं करता. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change

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

अगर यह 'सही' पर सेट है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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

अगर यह सुविधा चालू है और 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 डिफ़ॉल्ट: "गलत"

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

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

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

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

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

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

अगर यह सही है, तो सिस्टम में शामिल पाथ (-isystem) से मिले हेडर की जानकारी भी देनी होगी.
टैग: loading_and_analysis, eagerness_to_exit

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

इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर एनवायरमेंट तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

ऐसे विकल्प जिनसे किसी बिल्ड के हस्ताक्षर करने के आउटपुट पर असर पड़ता है:

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2"

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

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

अगर यह सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: जानकारी देखें

iOS साइनिंग के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक, यह सर्टिफ़िकेट की पासकोड की पहचान की प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम का (सबस्ट्रिंग) हो सकता है.
टैग: action_command_lines

इस विकल्प का असर, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर पड़ता है.:

--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही"

काम नहीं करता. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "गलत"

अगर इसकी वैल्यू 'सही' है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट इस्तेमाल करने की अनुमति नहीं दें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को 'सही' पर सेट करें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो पहले से मौजूद py_* नियमों का इस्तेमाल करते समय गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के AnalysisFailureInfo के इंस्टेंस का प्रॉपेगेशन होता है. इसमें गड़बड़ी की जानकारी होती है. इससे बिल्ड पूरा न होने की स्थिति नहीं होती.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा डेटा डालने पर, नियम से जुड़ी गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental

--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 डिफ़ॉल्ट: "गलत"

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "गलत"

ios_test टारगेट में, मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है, जैसे कि 'iPhone 6'. डिवाइसों की सूची पाने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला iOS वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह हर टेस्ट को कितनी बार चलाने के लिए तय करता है. अगर इनमें से किसी भी कोशिश में किसी वजह से सफलता नहीं मिलती है, तो पूरे टेस्ट को असफल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test, पूर्णांक वैल्यू के लिए है और regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैरिएबल की वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.
टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1"

टेस्ट टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर चार पूर्णांकों को कॉमा लगाकर अलग-अलग किया गया है, तो वे कम, सामान्य, ज़्यादा, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों ही फ़ॉर्म में, -1 की वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहा जाता है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो बिना एलान किए किए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "गलत"

LibraryJar में मौजूद सभी क्लास हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलें, डिस्क में लिखे जाने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में भेजी जाएंगी.
टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलें, डिस्क पर लिखे जाने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में भेजी जाएंगी.
टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत"

चालू होने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, cc_test नियमों पर निर्भर न करने वाले नियमों के लिए, कार्रवाई से जुड़ी समस्याओं को कम करना है. अगर --trim_test_configuration को 'गलत है' पर सेट किया जाता है, तो इसका कोई असर नहीं पड़ता.
टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "गलत"

इनपुट फ़ाइलों से #include लाइनों को पार्स करके, इनपुट को C/C++ कंपाइलेशन तक सीमित करना है या नहीं. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम हो जाता है. इससे परफ़ॉर्मेंस और इंक्रीमेंटलिटी बेहतर हो सकती है. हालांकि, इससे बिल्ड भी खराब हो सकते हैं, क्योंकि शामिल करने वाला स्कैनर, C प्रीप्रोसेसिंग सेमेंटेक्स को पूरी तरह से लागू नहीं करता. खास तौर पर, यह डाइनैमिक #include निर्देशों को समझ नहीं पाता और प्रीप्रोसेसर के कंडीशनल लॉजिक को अनदेखा कर देता है. अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी सभी समस्याओं को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing डिफ़ॉल्ट: "सही"

यह हर Jar फ़ाइल के लिए, इंडेक्स करने का ज़्यादातर काम अलग से करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो clang से जनरेट की गई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग की सुविधा चालू हो.
टैग: execution

--[no]trim_test_configuration डिफ़ॉल्ट: "सही"

इस विकल्प को चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के सबसे ऊपरी लेवल के नीचे से हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को बिना टेस्ट वाले नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने पर, बिना टेस्ट वाले नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान, डीबग की जानकारी प्रिंट करें. इस फ़्लैग में रेगुलर एक्सप्रेशन का इस्तेमाल किया जाता है. इस एक्सप्रेशन की जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता लगाया जा सके कि किस टूल को डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. ऐसा हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए ही काम का हो.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत"

यह फ़्लैग, डिफ़ॉल्ट तरीके को बदल देता है, ताकि Python टारगेट के रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बनें. खास तौर पर, जब py_binary या py_test टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिंबललिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, `--incompatible_py3_is_default` को भी चालू करने का सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से PY3 का इस्तेमाल किया जाएगा, न कि PY2 का. अगर यह फ़्लैग सेट किया जाता है, तो हमारा सुझाव है कि आप `--incompatible_py2_outputs_are_suffixed` को भी सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के नेटिव नियमों को लागू करने के लिए, --python_top जैसे लेगसी फ़्लैग के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल किया जाएगा.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

Python के मुख्य वर्शन का मोड, या तो `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट बदल देते हैं. भले ही, वे साफ़ तौर पर किसी वर्शन की जानकारी न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "auto"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो Bazel किसी टेस्ट को फिर से सिर्फ़ तब चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट चलाने का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. 'हां' पर सेट होने पर, Bazel बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजों को कैश मेमोरी में सेव नहीं करता.

--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Blaze पहले सफल रन पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ काम आता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो कवरेज की जांच के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा की पूरी डायरेक्ट्री फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो clang के लिए कवरेज से LCOV रिपोर्ट जनरेट होगी.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_j2objc_header_map डिफ़ॉल्ट: "सही"

J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental

--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "गलत"

क्या छोटे हेडर पाथ के साथ जनरेट करना है ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग: affects_outputs, experimental

--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javabuilder"

Java कंपाइलेशन के लिए, कम क्लासपाथ की सुविधा चालू करता है.

--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत"

काम नहीं करता, इसे सिर्फ़ पुराने वर्शन के साथ काम करने के लिए रखा गया है
टैग: affects_outputs, experimental

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs, experimental

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java लॉन्चर, उन टूल का इस्तेमाल करता है जो बिल्ड के दौरान चलाए जाते हैं.

--host_javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, javac को पास करने के लिए अन्य विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर यह 'सही' है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने पर, शेयर किए गए कैश मेमोरी का इस्तेमाल होने पर, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी सेव नहीं की जा सकती.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

J2ObjC टूल को पास करने के लिए अन्य विकल्प.

--java_debug

इसकी वजह से, किसी Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे, jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इस तरह बड़ा होता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps डिफ़ॉल्ट: "सही"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (फ़िलहाल, कंपाइल के समय क्लासपाथ) जनरेट करें.

--[no]java_header_compilation डिफ़ॉल्ट: "सही"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis

--[no]proto_profile डिफ़ॉल्ट: "सही"

क्या प्रोटो कंपाइलर को profile_path पास करना है.
टैग: affects_outputs, loading_and_analysis

--proto_profile_path=<a build target label> डिफ़ॉल्ट: जानकारी देखें

प्रोटो कंपाइलर को profile_path के तौर पर पास की जाने वाली प्रोफ़ाइल. अगर यह सेट नहीं है, लेकिन --proto_profile सही (डिफ़ॉल्ट) है, तो --fdo_optimize से पाथ का अनुमान लगाया जाता है.
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain"

proto_lang_toolchain() का लेबल, जो C++ प्रोटो कोड को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जो Java प्रोटो कोड को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जो JavaLite प्रोटो को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

protobuf कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो जिस शर्ड में कम से कम एक रन/अटैंप पास होता है और कम से कम एक रन/अटैंप फ़ेल होता है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: जानकारी देखें

Bazel के इस्तेमाल के लिए, शेल की एक्ज़ीक्यूटेबल फ़ाइल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन Bazel को पहली बार इस्तेमाल करने पर BAZEL_SH एनवायरमेंट वैरिएबल सेट है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel काम करता है. जैसे, Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने पर, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में गड़बड़ियां हो सकती हैं.
टैग: loading_and_analysis

--test_arg=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इससे उन अतिरिक्त विकल्पों और आर्ग्युमेंट की जानकारी मिलती है जिन्हें टेस्ट के लिए इस्तेमाल किए जाने वाले प्रोग्राम को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, कई बार इस्तेमाल किया जा सकता है. अगर एक से ज़्यादा टेस्ट चलाए जाते हैं, तो उनमें से हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.

--test_filter=<a string> डिफ़ॉल्ट: जानकारी देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, चलाए जाने वाले टेस्ट की संख्या को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे यह तय नहीं होता कि कौनसे टारगेट बनाए जाएं.

--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1"

इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत"

टेस्ट रनर को फ़ेल फ़ास्ट विकल्प फ़ॉरवर्ड करता है. टेस्ट रनर को पहली बार फ़ेल होने पर, टेस्ट को रोक देना चाहिए.

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "explicit"

टेस्ट के लिए, शार्डिंग की रणनीति तय करें: 'explicit', ताकि सिर्फ़ तब शार्डिंग का इस्तेमाल किया जा सके, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'बंद है', ताकि टेस्ट के लिए डेटा को अलग-अलग हिस्सों में बांटने की सुविधा का कभी भी इस्तेमाल न किया जाए. 'forced=k': इस विकल्प का इस्तेमाल करके, टेस्टिंग के लिए 'k' शर्ड लागू किए जा सकते हैं. भले ही, 'shard_count' बिल्ड एट्रिब्यूट की वैल्यू कुछ भी हो.

--tool_java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वह वर्शन जिसका इस्तेमाल, बिल्ड के दौरान ज़रूरी टूल चलाने के लिए किया जाता है

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन इंटरफ़ेस के लिए jar का इस्तेमाल करता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

बिल्ड करने के विकल्प

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]check_up_to_date डिफ़ॉल्ट: "गलत"

बिल्ड न करें, सिर्फ़ यह देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड पूरा हो जाता है. अगर किसी चरण को पूरा करना ज़रूरी है, तो गड़बड़ी की शिकायत की जाती है और बिल्ड पूरा नहीं होता.
टैग: execution

--dynamic_local_execution_delay=<an integer> डिफ़ॉल्ट: "1000"

अगर किसी बिल्ड के दौरान, रिमोट तरीके से एक्सीक्यूशन की प्रोसेस कम से कम एक बार तेज़ी से पूरी हुई है, तो लोकल तरीके से एक्सीक्यूशन में कितने मिलीसेकंड की देरी होनी चाहिए?
टैग: execution, host_machine_resource_optimizations

--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यहां दी गई स्थानीय रणनीतियों का इस्तेमाल, दिए गए मेमोनेमिक के लिए किया जाता है. लागू होने वाली पहली रणनीति का इस्तेमाल किया जाता है. उदाहरण के लिए, `worker,sandboxed` ऐसी कार्रवाइयां चलाता है जो वर्कर्स की रणनीति का इस्तेमाल करके, लगातार काम करने वाले वर्कर्स के साथ-साथ सैंडबॉक्स की रणनीति का इस्तेमाल करने वाले सभी वर्कर्स के साथ काम करती हैं. अगर कोई मेमोनेमिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी मेमोनेमिक के लिए फ़ॉलबैक के तौर पर किया जाता है. अगर `experimental_local_lockfree_output` सेट है,तो फ़ॉलबैक के तौर पर इस्तेमाल होने वाली डिफ़ॉल्ट सूची`worker, sandboxed` या `worker,sandboxed,standalone` है. [mnemonic=]local_strategy[,local_strategy,...] लेता है
टैग: execution, host_machine_resource_optimizations

--dynamic_remote_strategy=<a '[name=]value1[,..,valueN]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

रिमोट रणनीतियां, दिए गए मेमोनेमिक के लिए इस्तेमाल करने के क्रम में - लागू होने वाली पहली रणनीति का इस्तेमाल किया जाता है. अगर कोई मेमोनेमिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी मेमोनेमिक के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `remote` होती है. इसलिए, आम तौर पर इस फ़्लैग को साफ़ तौर पर सेट करने की ज़रूरत नहीं होती. [mnemonic=]remote_strategy[,remote_strategy,...] लेता है
टैग: execution, host_machine_resource_optimizations

--experimental_docker_image=<a string> डिफ़ॉल्ट: ""

Docker की रणनीति का इस्तेमाल करते समय, सैंडबॉक्स की गई कार्रवाई को लागू करने के लिए, Docker इमेज का नाम (उदाहरण के लिए, "ubuntu:latest") डालें. साथ ही, यह भी पक्का करें कि प्लैटफ़ॉर्म के ब्यौरे में, कार्रवाई की remote_execution_properties में पहले से ही कंटेनर-इमेज एट्रिब्यूट मौजूद न हो. इस फ़्लैग की वैल्यू को 'docker run' में बिना किसी बदलाव के पास किया जाता है. इसलिए, यह Docker के सिंटैक्स और तरीकों के साथ काम करता है.
टैग: execution

--[no]experimental_docker_use_customized_images डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो Docker इमेज का इस्तेमाल करने से पहले, मौजूदा उपयोगकर्ता के uid और gid को उसमें इंजेक्ट करता है. अगर आपका बिल्ड / टेस्ट, कंटेनर में उपयोगकर्ता के नाम और होम डायरेक्ट्री पर निर्भर करता है, तो यह ज़रूरी है. यह सुविधा डिफ़ॉल्ट रूप से चालू रहती है. हालांकि, अगर आपके लिए इमेज को अपने-आप पसंद के मुताबिक बनाने की सुविधा काम नहीं करती है या आपको इसकी ज़रूरत नहीं है, तो इसे बंद किया जा सकता है.
टैग: execution

--[no]experimental_dynamic_exclude_tools डिफ़ॉल्ट: "सही"

सेट होने पर, "टूल के लिए" बनाए गए टारगेट, डाइनैमिक तरीके से लागू नहीं होते. ऐसे टारगेट को धीरे-धीरे बनाने की संभावना बहुत कम होती है. इसलिए, इन पर लोकल साइकल खर्च करने का कोई फ़ायदा नहीं है.
टैग: execution, host_machine_resource_optimizations

--experimental_dynamic_local_load_factor=<a double> डिफ़ॉल्ट: "0"

यह कंट्रोल करता है कि डाइनैमिक तरीके से लागू होने वाले फ़ंक्शन से, लोकल मशीन पर कितना लोड डाला जाए. इस फ़्लैग से यह तय होता है कि डाइनैमिक तरीके से लागू होने वाली कितनी कार्रवाइयों को एक साथ शेड्यूल किया जाएगा. यह Blaze के हिसाब से उपलब्ध सीपीयू की संख्या पर आधारित होता है. इसे --local_cpu_resources फ़्लैग की मदद से कंट्रोल किया जा सकता है. अगर यह फ़्लैग 0 है, तो सभी कार्रवाइयां स्थानीय तौर पर तुरंत शेड्यूल की जाती हैं. अगर यह वैल्यू 0 से ज़्यादा है, तो स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या, उपलब्ध सीपीयू की संख्या से सीमित होती है. अगर यह वैल्यू 1 से कम है, तो लोड फैक्टर का इस्तेमाल, स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या को कम करने के लिए किया जाता है. ऐसा तब किया जाता है, जब शेड्यूल होने की प्रतीक्षा में कार्रवाइयों की संख्या ज़्यादा हो. इससे क्लीन बिल्ड के मामले में, लोकल मशीन पर लोड कम हो जाता है. इस मामले में, लोकल मशीन का ज़्यादा योगदान नहीं होता.
टैग: execution, host_machine_resource_optimizations

--experimental_dynamic_slow_remote_time=<An immutable length of time.> डिफ़ॉल्ट: "0"

अगर यह वैल्यू >0 है, तो इसका मतलब है कि रीमोट टाइम आउट से बचने के लिए, डाइनैमिक तौर पर चलने वाली कार्रवाई को स्थानीय तौर पर लागू करने से पहले, उसे सिर्फ़ रीमोट तौर पर चलाया जाना चाहिए. इससे, रिमोट से चलाए जाने वाले सिस्टम में कुछ समस्याएं छिप सकती हैं. रिमोट से चलाए जाने से जुड़ी समस्याओं को मॉनिटर किए बिना, इसे चालू न करें.
टैग: execution, host_machine_resource_optimizations

--[no]experimental_enable_docker_sandbox डिफ़ॉल्ट: "गलत"

Docker पर आधारित सैंडबॉक्सिंग की सुविधा चालू करें. अगर Docker इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं पड़ेगा.
टैग: execution

--[no]experimental_inmemory_sandbox_stashes डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो 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"> डिफ़ॉल्ट: "4"

अगर 0 है, तो कोई कार्रवाई पूरी होने के तुरंत बाद सैंडबॉक्स ट्री मिटाएं. इससे कार्रवाई पूरी होने में देरी होती है. अगर यह शून्य से ज़्यादा है, तो ऐसे थ्री को एक असाइनोक्रोनस थ्रेड पूल में मिटाएं. बिल्ड चलने के दौरान, इस पूल का साइज़ 1 होता है. सर्वर के खाली होने पर, यह साइज़ इस फ़्लैग में बताए गए साइज़ तक बढ़ जाता है.
टैग: host_machine_resource_optimizations, execution

--experimental_sandbox_enforce_resources_regexp=<a valid Java regular expression> डिफ़ॉल्ट: ""

अगर यह सही है, तो जिन कार्रवाइयों का मेनिमोनिक इनपुट रेगुलर एक्सप्रेशन से मेल खाता है उनके लिए संसाधनों के अनुरोध को सीमाओं के तौर पर लागू किया जाएगा. अगर संसाधन टाइप इसकी अनुमति देता है, तो --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>.> डिफ़ॉल्ट: "0"

अगर यह वैल्यू 0 से ज़्यादा है, तो हर Linux सैंडबॉक्स में तय मेमोरी (एमबी में) ही इस्तेमाल की जा सकेगी. इसके लिए, cgroups v1 या v2 की ज़रूरत होती है. साथ ही, उपयोगकर्ताओं के पास cgroups डायरेक्ट्री के लिए अनुमतियां होनी चाहिए.
टैग: execution

--[no]experimental_shrink_worker_pool डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो वर्कर मेमोरी का दबाव ज़्यादा होने पर, वर्कर पूल छोटा हो सकता है. यह फ़्लैग सिर्फ़ तब काम करता है, जब experimental_total_worker_memory_limit_mb फ़्लैग चालू हो.
टैग: execution, host_machine_resource_optimizations

--[no]experimental_split_xml_generation डिफ़ॉल्ट: "सही"

अगर यह फ़्लैग सेट है और कोई टेस्ट ऐक्शन, test.xml फ़ाइल जनरेट नहीं करता है, तो Bazel एक अलग ऐक्शन का इस्तेमाल करके, टेस्ट लॉग वाली डमी test.xml फ़ाइल जनरेट करता है. ऐसा न करने पर, Bazel टेस्ट ऐक्शन के हिस्से के तौर पर test.xml जनरेट करता है.
टैग: execution

--experimental_total_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0"

अगर यह सीमा शून्य से ज़्यादा है, तो सभी वर्कर्स का कुल मेमोरी इस्तेमाल इस सीमा से ज़्यादा होने पर, शायद कोई भी वर्कर्स काम न करे.
टैग: execution, host_machine_resource_optimizations

--[no]experimental_use_hermetic_linux_sandbox डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो रूट को माउंट न करें. सिर्फ़ sandbox_add_mount_pair के साथ जोड़े गए फ़ोल्डर को माउंट करें. इनपुट फ़ाइलों को सैंडबॉक्स से लिंक करने के बजाय, सैंडबॉक्स में हार्डलिंक किया जाएगा. अगर ऐक्शन इनपुट फ़ाइलें सैंडबॉक्स से अलग फ़ाइल सिस्टम में मौजूद हैं, तो इनपुट फ़ाइलों को कॉपी किया जाएगा.
टैग: execution

--[no]experimental_use_semaphore_for_jobs डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो एक साथ चलने वाले जॉब की संख्या को सीमित करने के लिए, सिग्नल का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution

--[no]experimental_use_windows_sandbox डिफ़ॉल्ट: "गलत"

कार्रवाइयां चलाने के लिए, Windows सैंडबॉक्स का इस्तेमाल करें. अगर "हां" है, तो --experimental_windows_sandbox_path से दी गई बाइनरी मान्य होनी चाहिए और sandboxfs के साथ काम करने वाले वर्शन से मेल खानी चाहिए. अगर "अपने-आप" है, तो हो सकता है कि बाइनरी मौजूद न हो या काम न कर रही हो.
टैग: execution

--experimental_windows_sandbox_path=<a string> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो Bazel उन वर्कर्स को रद्द करने के अनुरोध भेज सकता है जो उन्हें सहायता देते हैं.
टैग: execution

--experimental_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0"

अगर यह सीमा शून्य से ज़्यादा है, तो वर्कर्स की मेमोरी इस्तेमाल करने की सीमा से ज़्यादा इस्तेमाल होने पर, वर्कर्स को बंद किया जा सकता है. अगर 'डाइनैमिक तरीके से लागू करना' और `--experimental_dynamic_ignore_local_signals=9` के साथ इस्तेमाल नहीं किया जाता है, तो हो सकता है कि आपका बिल्ड क्रैश हो जाए.
टैग: execution, host_machine_resource_optimizations

--experimental_worker_metrics_poll_interval=<An immutable length of time.> डिफ़ॉल्ट: "5s"

वर्कर की मेट्रिक इकट्ठा करने और उसे हटाने की कोशिश करने के बीच का अंतराल. परफ़ॉर्मेंस की वजह से, यह समय एक सेकंड से कम नहीं होना चाहिए.
टैग: execution, host_machine_resource_optimizations

--[no]experimental_worker_multiplex_sandboxing डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो 'supports-multiplex-sandboxing' एक्सीक्यूशन की ज़रूरी शर्त वाले मल्टीप्लेक्स वर्कर्स, सैंडबॉक्स किए गए एनवायरमेंट में चलेंगे. इसके लिए, हर वर्क रिक्वेस्ट के लिए एक अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल किया जाएगा. 'डाइनैमिक तरीके से प्रोसेस करने की रणनीति' के तहत चलने वाले मल्टीप्लेक्स वर्कर्स को हमेशा सैंडबॉक्स में रखा जाता है. भले ही, उनके लिए 'एक्सीक्यूशन की ज़रूरी शर्तें' फ़्लैग सेट किया गया हो या नहीं.
टैग: execution

--[no]experimental_worker_sandbox_hardening डिफ़ॉल्ट: "गलत"

अगर यह सेटिंग चालू है, तो वर्कर को बेहतर सुरक्षा वाले सैंडबॉक्स में चलाया जाता है. हालांकि, ऐसा तब ही किया जाता है, जब लागू करने की अनुमति हो. अगर सुरक्षा को बेहतर बनाने की सुविधा चालू है, तो अलग-अलग वर्कर्स के लिए अलग-अलग टेंप्लेट डायरेक्ट्री बनाई जाती हैं.
टैग: execution

--experimental_worker_sandbox_inmemory_tracking=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

वर्कर की याद रखने लायक ऐसी कुंजी जिसके लिए सैंडबॉक्स डायरेक्ट्री के कॉन्टेंट को मेमोरी में ट्रैक किया जाता है. इससे, ज़्यादा मेमोरी का इस्तेमाल करके, बिल्ड की परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. इसका असर सिर्फ़ सैंडबॉक्स किए गए वर्कर्स पर पड़ता है. अलग-अलग मेमोनेमिक के लिए, एक से ज़्यादा बार तय किया जा सकता है.
टैग: execution

--[no]experimental_worker_strict_flagfiles डिफ़ॉल्ट: "गलत"

अगर इसे चालू किया जाता है, तो वर्कर्स के लिए कार्रवाइयों के ऐसे आर्ग्युमेंट से गड़बड़ी होगी जो वर्कर्स की खास बातों का पालन नहीं करते. वर्कर्स के आर्ग्युमेंट में, आखिरी आर्ग्युमेंट के तौर पर एक @flagfile आर्ग्युमेंट होना चाहिए.
टैग: execution

--genrule_strategy=<comma-separated list of options> डिफ़ॉल्ट: ""

genrules को लागू करने का तरीका बताएं. इस फ़्लैग को बंद कर दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरेटिव नियमों को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution

--[no]incompatible_sandbox_hermetic_tmp डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो हर Linux सैंडबॉक्स में /tmp के तौर पर माउंट की गई एक खाली डायरेक्ट्री होगी. ऐसा करने से, /tmp को होस्ट फ़ाइल सिस्टम के साथ शेयर करने की ज़रूरत नहीं पड़ेगी. सभी सैंडबॉक्स में होस्ट का/tmp देखने के लिए, --sandbox_add_mount_pair=/tmp का इस्तेमाल करें.
टैग: execution

--[no]incompatible_use_new_cgroup_implementation डिफ़ॉल्ट: "गलत"

अगर यह 'सही है' पर सेट है, तो cgroups के लिए नए तरीके का इस्तेमाल करें. पुराने तरीके से लागू करने पर, सिर्फ़ मेमोरी कंट्रोलर काम करता है. साथ ही, --experimental_sandbox_limits की वैल्यू को अनदेखा कर दिया जाता है.
टैग: execution

--[no]internal_spawn_scheduler डिफ़ॉल्ट: "सही"

प्लेसहोल्डर का विकल्प, ताकि हम Blaze में बता सकें कि स्पैन शेड्यूलर चालू था या नहीं.
टैग: execution, host_machine_resource_optimizations

--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> [-j] डिफ़ॉल्ट: "auto"

एक साथ चलने वाली जॉब की संख्या. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. 2500 से ज़्यादा वैल्यू से, मेमोरी से जुड़ी समस्याएं हो सकती हैं. "auto", होस्ट के संसाधनों के आधार पर, डिफ़ॉल्ट तौर पर सही अनुमान लगाता है.
टैग: host_machine_resource_optimizations, execution

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--[no]reuse_sandbox_directories डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो सेटअप की ग़ैर-ज़रूरी लागत से बचने के लिए, सैंडबॉक्स किए गए नॉन-वर्कर एक्सीक्यूशन में इस्तेमाल की गई डायरेक्ट्री का फिर से इस्तेमाल किया जा सकता है.
टैग: host_machine_resource_optimizations, execution

--sandbox_base=<a string> डिफ़ॉल्ट: ""

इससे सैंडबॉक्स, इस पाथ के नीचे अपनी सैंडबॉक्स डायरेक्ट्री बना सकता है. अगर आपके बिल्ड /टेस्ट में कई इनपुट फ़ाइलें हैं, तो परफ़ॉर्मेंस को बेहतर बनाने के लिए, tmpfs (जैसे कि/run / shm) पर कोई पाथ तय करें. ध्यान दें: टास्क चलाने से जनरेट होने वाले आउटपुट और इंटरमीडियरी फ़ाइलों को सेव करने के लिए, आपके पास ज़रूरत के मुताबिक रैम और tmpfs में खाली जगह होनी चाहिए.
टैग: host_machine_resource_optimizations, execution

--[no]sandbox_explicit_pseudoterminal डिफ़ॉल्ट: "गलत"

सैंडबॉक्स की गई कार्रवाइयों के लिए, साफ़ तौर पर सूडो-टर्मिनल बनाने की सुविधा चालू करें. कुछ Linux डिस्ट्रिब्यूशन में, स्यूडो-टर्मिनल के काम करने के लिए, सैंडबॉक्स में प्रोसेस के ग्रुप आईडी को 'tty' पर सेट करना ज़रूरी होता है. अगर इससे समस्याएं आ रही हैं, तो अन्य ग्रुप का इस्तेमाल करने के लिए, इस फ़्लैग को बंद किया जा सकता है.
टैग: execution

--sandbox_tmpfs_path=<an absolute path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सैंडबॉक्स की गई कार्रवाइयों के लिए, इस सटीक पाथ पर एक खाली और लिखने लायक डायरेक्ट्री माउंट करें. हालांकि, अगर सैंडबॉक्सिंग लागू करने की सुविधा काम करती है, तो ऐसा करें. अगर ऐसा नहीं है, तो इस बात को अनदेखा करें.
टैग: host_machine_resource_optimizations, execution

--[no]skip_incompatible_explicit_targets डिफ़ॉल्ट: "गलत"

कमांड लाइन पर साफ़ तौर पर बताए गए, काम न करने वाले टारगेट को स्किप करें. डिफ़ॉल्ट रूप से, ऐसे टारगेट बनाने पर गड़बड़ी का मैसेज दिखता है. हालांकि, यह विकल्प चालू होने पर, उन्हें चुपचाप स्किप कर दिया जाता है. देखें: https://bazel.build/extending/platforms#skipping-incompatible-targets
टैग: loading_and_analysis

--spawn_strategy=<comma-separated list of options> डिफ़ॉल्ट: ""

बताएं कि स्पॉन ऐक्शन डिफ़ॉल्ट रूप से कैसे लागू होते हैं. इसमें रणनीतियों की सूची को कॉमा लगाकर, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के क्रम में लिखा जाता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली उस रणनीति को चुनता है जो कार्रवाई को पूरा कर सकती है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy=<a '[name=]value1[,..,valueN]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्पैन करने से जुड़ी अन्य कार्रवाइयों के कलेक्शन को डिस्ट्रिब्यूट करने का तरीका बताएं. इसमें रणनीतियों की सूची को कॉमा लगाकर, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के क्रम में लिखा जाता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली उस रणनीति को चुनता है जो कार्रवाई को पूरा कर सकती है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग, --spawn_strategy से सेट की गई वैल्यू को बदल देता है. साथ ही, अगर mnemonic Genrule के साथ इस्तेमाल किया जाता है, तो --genrule_strategy को भी बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्पैन ऐक्शन को लागू करने के लिए, किस स्पैन रणनीति का इस्तेमाल किया जाना चाहिए. यह रणनीति, किसी खास regex_filter से मैच करने वाली जानकारी के लिए तय की जाती है. regex_filter मैचिंग के बारे में जानकारी के लिए, --per_file_copt देखें. ब्यौरे से मैच करने वाले आखिरी रेगुलर एक्सप्रेशन फ़िल्टर का इस्तेमाल किया जाता है. यह विकल्प, रणनीति तय करने के लिए अन्य फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि अगर ऐक्शन के ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो लोकल रणनीति का इस्तेमाल करके ऐक्शन चलाएं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed, 'Compiling //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा. हालांकि, क्रम को बदलने पर, इसे 'sandboxed' के साथ चलाया जाएगा.
टैग: execution

--worker_extra_flag=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अतिरिक्त कमांड-फ़्लैग, जिन्हें --persistent_worker के अलावा वर्कर्स प्रोसेस को पास किया जाएगा.इनका नाम, याद रखने में आसान शब्दों से मिलता-जुलता होता है. जैसे, --worker_extra_flag=Javac=--debug.
टैग: execution, host_machine_resource_optimizations

--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> एक से ज़्यादा बार इस्तेमाल किए जाने पर

'वर्कर' रणनीति का इस्तेमाल करने पर, हर तरह के पर्सिस्टेंट वर्कर्स के कितने इंस्टेंस लॉन्च किए जा सकते हैं. हर मेनिमोनिक के लिए अलग वैल्यू देने के लिए, [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' रणनीति का इस्तेमाल करने पर, मल्टीप्लेक्स वर्कर्स प्रोसेस को एक साथ कितने वर्क रिक्वेस्ट मिल सकते हैं. हर मेनिमोनिक के लिए अलग वैल्यू देने के लिए, [name=value] के तौर पर तय किया जा सकता है. यह सीमा, वर्कर्स की कुंजियों पर आधारित होती है. इन कुंजियों को मेमोनिक के आधार पर अलग-अलग किया जाता है. साथ ही, स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में हर मेमोनिक के लिए, इस फ़्लैग में बताई गई संख्या से ज़्यादा वर्कर्स हो सकते हैं. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 'auto', मशीन की क्षमता के आधार पर डिफ़ॉल्ट रूप से सही साइज़ का हिसाब लगाता है. "=value", बिना बताए गए मेमोनिक के लिए डिफ़ॉल्ट सेट करता है.
टैग: execution, host_machine_resource_optimizations

--[no]worker_multiplex डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो वर्कर्स मल्टीप्लेक्सिंग का इस्तेमाल करेंगे. हालांकि, इसके लिए ज़रूरी है कि वर्कर्स में मल्टीप्लेक्सिंग की सुविधा काम करती हो.
टैग: execution, host_machine_resource_optimizations

--[no]worker_quit_after_build डिफ़ॉल्ट: "गलत"

इस विकल्प के चालू होने पर, बिल्ड पूरा होने के बाद सभी वर्कर्स बंद हो जाते हैं.
टैग: execution, host_machine_resource_optimizations

--[no]worker_sandboxing डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो सिंगलप्लेक्स वर्कर्स सैंडबॉक्स वाले एनवायरमेंट में चलेंगे. डाइनैमिक तरीके से प्रोसेस करने की रणनीति के तहत काम करते समय, सिंगलप्लेक्स वर्कर्स हमेशा सैंडबॉक्स में होते हैं. भले ही, इस फ़्लैग का इस्तेमाल किया गया हो या नहीं.
टैग: execution

--[no]worker_verbose डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो वर्कर्स के शुरू होने, बंद होने वगैरह पर ज़्यादा जानकारी वाले मैसेज प्रिंट होते हैं

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]build डिफ़ॉल्ट: "सही"

बिल्ड को लागू करें; यह सामान्य तरीका है. --nobuild का इस्तेमाल करने पर, बिल्ड ऐक्शन लागू करने से पहले ही बिल्ड रुक जाता है. अगर पैकेज लोड करने और विश्लेषण के चरण सही तरीके से पूरे हो जाते हैं, तो यह शून्य दिखाता है. यह मोड, उन चरणों की जांच करने के लिए काम का है.
टैग: execution, affects_outputs

--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "गलत"

क्या टेस्ट के साथ पैरलल तरीके से काम करने के लिए, आसपेक्ट का इस्तेमाल करके पुष्टि करने की कार्रवाइयां चलानी हैं.
टैग: execution, affects_outputs

--output_groups=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इनमें से हर नाम के आगे + या - लगाने का विकल्प होता है. + लगाने पर, ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ दिया जाता है. वहीं, - लगाने पर, ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप के नाम में प्रीफ़िक्स नहीं जोड़ा गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हटा दिया जाता है. उदाहरण के लिए, --output_groups=+foo,+bar, डिफ़ॉल्ट सेट, foo, और bar का यूनियन बनाता है. वहीं, --output_groups=foo,bar, डिफ़ॉल्ट सेट को बदल देता है, ताकि सिर्फ़ foo और bar बनाए जाएं.
टैग: execution, affects_outputs

--[no]run_validations डिफ़ॉल्ट: "सही"

बिल्ड के हिस्से के तौर पर, पुष्टि करने वाली कार्रवाइयां चलानी हैं या नहीं. https://bazel.build/extending/rules#validation_actions पर जाएं
टैग: execution, affects_outputs

--serialized_frontier_profile=<a string> डिफ़ॉल्ट: ""

सीरियलाइज़ किए गए फ़्रंटियर बाइट की प्रोफ़ाइल को डंप करें. आउटपुट पाथ की जानकारी देता है.
टैग: bazel_monitoring

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपनी पसंद के मुताबिक आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--aspects=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टॉप-लेवल टारगेट पर लागू किए जाने वाले आसपेक्ट की सूची, जिसमें कॉमा लगाकर आसपेक्ट को अलग किया गया है. अगर सूची में, किसी एस्पेक्ट some_aspect के लिए, ज़रूरी एस्पेक्ट की सेवा देने वाली कंपनियों की जानकारी, required_aspect_providers के ज़रिए दी गई है, तो some_aspect उन सभी एस्पेक्ट के बाद चलेगा जिनके लिए विज्ञापन में बताई गई कंपनियां, some_aspect के लिए ज़रूरी एस्पेक्ट की सेवा देने वाली कंपनियों की ज़रूरी शर्तें पूरी करती हैं. इसके अलावा, some_aspect, ज़रूरी एट्रिब्यूट की वैल्यू देने के बाद ही चलेगा. इसके बाद, some_aspect के पास उन एस्पेक्ट के प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, उदाहरण के लिए, '//tools:my_def.bzl%my_aspect', जहां 'my_aspect', tools/my_def.bzl फ़ाइल की टॉप-लेवल वैल्यू है

--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1"

बीईपी आर्टफ़ैक्ट अपलोड करने के दौरान, ज़्यादा से ज़्यादा कितनी फ़ाइलें खोली जा सकती हैं.
टैग: affects_outputs

--[no]experimental_convenience_symlinks डिफ़ॉल्ट: "normal"

इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिंक (बिल्ड के बाद वर्कस्पेस में दिखने वाले लिंक) को कैसे मैनेज किया जाएगा. संभावित वैल्यू: सामान्य (डिफ़ॉल्ट): हर तरह का सुविधाजनक सिंबललिंक बनाया या मिटाया जाएगा. यह, बिल्ड के हिसाब से तय किया जाएगा. clean: सभी सिंबललिंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: इससे सिमलिनक न तो बनाए जाएंगे और न ही उन्हें हटाया जाएगा. log_only: लॉग मैसेज जनरेट करें, जैसे कि 'normal' पास किया गया हो. हालांकि, फ़ाइल सिस्टम पर कोई कार्रवाई न करें. यह टूल के लिए काम का है. ध्यान दें कि सिर्फ़ उन सिमलिंक पर असर पड़ सकता है जिनके नाम --symlink_prefix की मौजूदा वैल्यू से जनरेट किए गए हैं. प्रीफ़िक्स बदलने पर, पहले से मौजूद सिमलिंक में कोई बदलाव नहीं होगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks_bep_event डिफ़ॉल्ट: "सही"

इस फ़्लैग से यह कंट्रोल होता है कि हम BuildEventProtocol में, बिल्ड eventConvenienceSymlinksIdentified को पोस्ट करेंगे या नहीं. अगर वैल्यू 'सही है' पर सेट है, तो BuildEventProtocol में convenienceSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधाजनक लिंक की सूची होगी. अगर यह 'गलत' है, तो BuildEventProtocol में convenienceSymlinksIdentified एंट्री खाली होगी.
टैग: affects_outputs

--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> डिफ़ॉल्ट: "toplevel"

अगर इसे 'कम से कम' पर सेट किया जाता है, तो स्थानीय मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होता. हालांकि, स्थानीय कार्रवाइयों के लिए ज़रूरी आउटपुट डाउनलोड किए जाते हैं. 'toplevel' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह लोकल मशीन पर टॉप लेवल टारगेट के आउटपुट भी डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की समस्या है, तो दोनों विकल्पों से बिल्ड करने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs

--remote_download_symlink_template=<a string> डिफ़ॉल्ट: ""

रिमोट बिल्ड आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबल लिंक बनाएं. सिंबल लिंक का टारगेट, टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये क्रमशः ऑब्जेक्ट के हैश और बाइट में साइज़ में बदल जाते हैं. उदाहरण के लिए, ये सिंबल लिंक किसी ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर सीएएस से ऑब्जेक्ट लोड करता है.
टैग: 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 डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो कार्रवाइयां चलाते समय Bazel, 'docker run' को --privileged फ़्लैग पास करेगा. हो सकता है कि आपके बिल्ड के लिए यह ज़रूरी हो, लेकिन इससे डिवाइस के अंदर हवा या गैस के घुसने की संभावना भी बढ़ सकती है.
टैग: execution

--[no]experimental_sandboxfs_map_symlink_targets डिफ़ॉल्ट: "गलत"

कोई कार्रवाई नहीं करना
टैग: host_machine_resource_optimizations, execution

--[no]incompatible_legacy_local_fallback डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स की गई रणनीति से लोकल रणनीति पर, लेगसी इंप्लिसिट फ़ॉलबैक चालू हो जाता है. यह फ़्लैग आखिर में डिफ़ॉल्ट रूप से 'गलत' पर सेट हो जाएगा और फिर काम नहीं करेगा. फ़ॉलबैक कॉन्फ़िगर करने के लिए, --strategy, --spawn_strategy या --dynamic_local_strategy का इस्तेमाल करें.
टैग: execution, incompatible_change

--sandbox_add_mount_pair=<a single path or a 'source:target' pair> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सैंडबॉक्स में माउंट करने के लिए, अतिरिक्त पाथ पेयर जोड़ें.
टैग: execution

--sandbox_block_path=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सैंडबॉक्स की गई कार्रवाइयों के लिए, इस पाथ को ऐक्सेस करने की अनुमति न दें.
टैग: execution

--[no]sandbox_default_allow_network डिफ़ॉल्ट: "सही"

कार्रवाइयों के लिए, डिफ़ॉल्ट रूप से नेटवर्क ऐक्सेस की अनुमति दें; ऐसा हो सकता है कि यह सभी सैंडबॉक्सिंग लागू करने के साथ काम न करे.
टैग: execution

--[no]sandbox_fake_hostname डिफ़ॉल्ट: "गलत"

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग: execution

--[no]sandbox_fake_username डिफ़ॉल्ट: "गलत"

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'कोई नहीं' में बदलें.
टैग: execution

--sandbox_writable_path=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सैंडबॉक्स की गई कार्रवाइयों के लिए, सैंडबॉक्स में मौजूद किसी डायरेक्ट्री को लिखने लायक बनाएं. ऐसा तब ही करें, जब सैंडबॉक्सिंग लागू करने की सुविधा काम करती हो. ऐसा न करने पर, डायरेक्ट्री को अनदेखा कर दिया जाएगा.
टैग: execution

इस विकल्प का असर, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की सेटिंग दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती.
टैग: loading_and_analysis

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]check_tests_up_to_date डिफ़ॉल्ट: "गलत"

टेस्ट न चलाएं, सिर्फ़ यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी टेस्ट के नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर किसी टेस्ट को बनाने या चलाने की ज़रूरत है, तो गड़बड़ी की रिपोर्ट की जाती है और टेस्ट पूरा नहीं होता. इस विकल्प का मतलब है कि --check_up_to_date का इस्तेमाल किया जा रहा है.
टैग: execution

--flaky_test_attempts=<a positive integer, the string "default", or test_regex@attempts. This flag may be passed more than once> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर कोई टेस्ट पूरा नहीं हो पाता है, तो तय की गई संख्या तक हर टेस्ट को फिर से आज़माया जाएगा. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश की गई है उन्हें टेस्ट की खास जानकारी में 'अमान्य' के तौर पर मार्क किया जाता है. आम तौर पर, दी गई वैल्यू सिर्फ़ एक पूर्णांक या स्ट्रिंग 'default' होती है. अगर यह एक पूर्णांक है, तो सभी टेस्ट N बार तक चलाए जाएंगे. अगर 'डिफ़ॉल्ट' है, तो सामान्य टेस्ट के लिए सिर्फ़ एक बार टेस्ट किया जाएगा. वहीं, नियम (flaky=1 एट्रिब्यूट) के हिसाब से, 'अमान्य' के तौर पर मार्क किए गए टेस्ट के लिए तीन बार टेस्ट किया जाएगा. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. यहां flaky_test_attempts ऊपर बताए गए तरीके से है और regex_filter, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. साथ ही, --runs_per_test भी देखें. उदाहरण: --flaky_test_attempts=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाने के बाद, उनमें से उन टेस्ट को हटा देता है जो foo/bar में मौजूद हैं. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई भी वैल्यू मैच नहीं होती है, तो ऊपर दिए गए 'डिफ़ॉल्ट' विकल्प की तरह ही व्यवहार होता है.
टैग: execution

--local_test_jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

एक साथ चलने वाली लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, एक साथ चलने वाली लोकल टेस्ट जॉब की संख्या को सीमित कर देंगे. --jobs की वैल्यू से ज़्यादा वैल्यू सेट करने का कोई फ़ायदा नहीं है.
टैग: execution

--[no]test_keep_going डिफ़ॉल्ट: "सही"

अगर यह विकल्प बंद है, तो कोई भी टेस्ट पास न होने पर पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट चलाए जाते हैं. भले ही, कुछ टेस्ट पास न हों.
टैग: execution

--test_strategy=<a string> डिफ़ॉल्ट: ""

यह बताता है कि टेस्ट करते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution

--test_tmpdir=<a path> डिफ़ॉल्ट: जानकारी देखें

'bazel test' के इस्तेमाल के लिए, बेस टेम्पररी डायरेक्ट्री तय करता है.

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--cache_computed_file_digests=<a long integer> डिफ़ॉल्ट: "50000"

अगर यह वैल्यू 0 से ज़्यादा है, तो Bazel को मेमोरी में फ़ाइल डाइजेस्ट को कैश मेमोरी में सेव करने के लिए कॉन्फ़िगर किया जाता है. ऐसा करने पर, हर बार डिस्क से डाइजेस्ट को फिर से कैलकुलेट करने की ज़रूरत नहीं पड़ती. इसकी वैल्यू को 0 पर सेट करने से यह पक्का होता है कि फ़ाइल में किए गए सभी बदलावों को मेटाडेटा में शामिल किया गया है. अगर यह संख्या 0 नहीं है, तो यह कैश मेमोरी के साइज़ को दिखाती है. यह साइज़, कैश मेमोरी में सेव की जाने वाली फ़ाइल डाइजेस्ट की संख्या के बराबर होता है.

--[no]experimental_cpu_load_scheduling डिफ़ॉल्ट: "गलत"

सीपीयू लोड के आधार पर, एक्सपेरिमेंट के तौर पर स्थानीय तौर पर एक्सेक्यूशन शेड्यूलिंग की सुविधा चालू करता है. यह सुविधा, एक-एक करके कार्रवाइयों के अनुमान के आधार पर नहीं चालू होती. एक्सपेरिमेंट के तौर पर शेड्यूल करने की सुविधा से, बड़ी संख्या में कोर वाली बेहतरीन मशीनों पर बड़े लोकल बिल्ड में काफ़ी फ़ायदा हुआ है. हमारा सुझाव है कि --local_resources=cpu=HOST_CPUS के साथ इस्तेमाल करें
टैग: execution

--experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers> डिफ़ॉल्ट: जानकारी देखें

OS सिग्नल नंबर की सूची लेता है. अगर डाइनैमिक तरीके से लागू होने वाली प्रोसेस की किसी लोकल शाखा को इनमें से किसी भी सिग्नल से बंद कर दिया जाता है, तो रिमोट शाखा को पूरा होने की अनुमति दी जाएगी. लगातार काम करने वाले वर्कर के लिए, इसका असर सिर्फ़ उन सिग्नल पर पड़ता है जो वर्कर प्रोसेस को बंद कर देते हैं.
टैग: execution

--[no]experimental_enable_skyfocus डिफ़ॉल्ट: "गलत"

अगर यह 'सही है' पर सेट है, तो --experimental_working_set का इस्तेमाल चालू करें. इससे, इंक्रीमेंटल बिल्ड के लिए Bazel की मेमोरी का फ़ुटप्रिंट कम हो जाएगा. इस सुविधा को स्काईफ़ोकस कहा जाता है.
टैग: host_machine_resource_optimizations

--experimental_working_set=<comma-separated list of options> डिफ़ॉल्ट: ""

Skyfocus के लिए काम करने वाला सेट. कॉमा लगाकर अलग किए गए वर्कस्पेस के रूट-रिलेटिव पाथ के तौर पर बताएं. यह एक स्टेटलेस फ़्लैग है. वर्किंग सेट तय करने पर, उसे बाद में फिर से इस्तेमाल किया जा सकता है. ऐसा तब तक किया जा सकता है, जब तक उसे नए सेट से फिर से तय नहीं किया जाता.
टैग: host_machine_resource_optimizations

--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_CPUS"

Bazel के लिए उपलब्ध स्थानीय सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_CPUS" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_CPUS*.5, उपलब्ध सीपीयू कोर के आधे हिस्से का इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, ("HOST_CPUS") Bazel, उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
टैग: 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> डिफ़ॉल्ट: "4"

Bazel को बिल्ड इवेंट को अपलोड करने की कोशिश कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration

--[no]debug_spawn_scheduler डिफ़ॉल्ट: "गलत"

--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत"

TargetSummary इवेंट पब्लिश करने हैं या नहीं.

--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs

--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में रिलेटिव फ़ाइलसेट के लिंक को पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs

--experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both> एक से ज़्यादा बार इस्तेमाल किए जाने पर

तय करें कि TargetComplete/AspectComplete बीईपी इवेंट में, आउटपुट ग्रुप की फ़ाइलों को कैसे दिखाया जाएगा. वैल्यू, आउटपुट ग्रुप के नाम को 'NAMED_SET_OF_FILES_ONLY', 'INLINE_ONLY' या 'BOTH' में से किसी एक के लिए असाइन करते हैं. डिफ़ॉल्ट वैल्यू 'NAMED_SET_OF_FILES_ONLY' है. अगर किसी आउटपुट ग्रुप को दोहराया जाता है, तो दिखने वाली आखिरी वैल्यू का इस्तेमाल किया जाता है. डिफ़ॉल्ट वैल्यू, कवरेज आर्टफ़ैक्ट के लिए मोड को दोनों पर सेट करती है: --experimental_build_event_output_group_mode=baseline.lcov=both
टैग: affects_outputs

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s"

बीईपी अपलोड न हो पाने पर, एक्सपोनेंशियल बैकऑफ़ की वजह से होने वाली शुरुआती देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration

--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुनता है. Bazel में, 'लोकल' और 'रिमोट' मान्य विकल्प हैं. डिफ़ॉल्ट वैल्यू 'local' होती है.
टैग: affects_outputs

--[no]experimental_docker_verbose डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो Bazel, Docker सैंडबॉक्स की रणनीति के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करेगा.
टैग: execution

--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "गलत"

अगर पैरामीटर फ़ाइलों को मेटालाइज़ किया जा रहा है, तो डिस्क में सीधे लिखकर ऐसा करें.
टैग: execution

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

अगर यह वैल्यू खाली नहीं है, तो Starlark की वैल्यू लिखें. इसमें, Starlark के उन सभी रिपॉज़िटरी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "गलत"

रन बिल्ड इवेंट में कमांड-लाइन के अवशेष शामिल करने हैं या नहीं. डिफ़ॉल्ट रूप से, रन कमांड वाले उन बिल्ड इवेंट में अवशेष शामिल नहीं किए जाते जिनमें अवशेष हो सकते हैं.
टैग: affects_outputs

--experimental_skyfocus_dump_keys=<none, count or verbose> डिफ़ॉल्ट: "none"

Skyfocus को डीबग करने के लिए. फ़ोकस किए गए SkyKey (रूट, लीफ़, फ़ोकस किए गए डिपेंडेंसी, फ़ोकस किए गए rdeps) को डंप करें.
टैग: terminal_output

--[no]experimental_skyfocus_dump_post_gc_stats डिफ़ॉल्ट: "गलत"

Skyfocus को डीबग करने के लिए. अगर यह चालू है, तो ढेर के साइज़ में हुई कमी की रिपोर्ट करने के लिए, फ़ोकस करने से पहले/बाद में मैन्युअल GC ट्रिगर करें. इससे Skyfocus के इंतज़ार का समय बढ़ जाएगा.
टैग: terminal_output

--experimental_skyfocus_handling_strategy=<strict or warn> डिफ़ॉल्ट: "strict"

Skyfocus के लिए, काम करने वाले सेट के बाहर के बदलावों को मैनेज करने की रणनीतियां.
टैग: eagerness_to_exit

--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत"

लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs

--explain=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे बिल्ड सिस्टम, बिल्ड के हर चरण के बारे में जानकारी देता है. जानकारी, बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग: affects_outputs

--[no]ignore_unsupported_sandboxing डिफ़ॉल्ट: "गलत"

अगर इस सिस्टम पर सैंडबॉक्स में चलाने की सुविधा काम नहीं करती, तो चेतावनी न दिखाएं.
टैग: terminal_output

--[no]legacy_important_outputs डिफ़ॉल्ट: "गलत"

TargetComplete इवेंट में, लेगसी important_outputs फ़ील्ड जनरेट होने से रोकने के लिए, इसका इस्तेमाल करें. Bazel से ResultStore/BTX इंटिग्रेशन के लिए, important_outputs ज़रूरी है.
टैग: affects_outputs

--[no]materialize_param_files डिफ़ॉल्ट: "गलत"

रिमोट ऐक्शन एक्सीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें लिखता है. यह कार्रवाई को डीबग करने के दौरान काम का होता है. --subcommands और --verbose_failures से यह पता चलता है.
टैग: execution

--max_config_changes_to_show=<an integer> डिफ़ॉल्ट: "3"

बिल्ड के विकल्पों में बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नामों की तय संख्या तक दिखाता है. अगर दी गई संख्या -1 है, तो बदले गए सभी विकल्प दिखेंगे.
टैग: terminal_output

--max_test_output_bytes=<an integer> डिफ़ॉल्ट: "-1"

यह हर टेस्ट लॉग का ज़्यादा से ज़्यादा साइज़ तय करता है. यह साइज़ तब जनरेट किया जा सकता है, जब --test_output 'errors' या 'all' हो. यह विकल्प, बहुत ज़्यादा गड़बड़ी वाले टेस्ट आउटपुट से आउटपुट को भरने से रोकने के लिए मददगार होता है. लॉग के साइज़ में टेस्ट हेडर शामिल होता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट या तो पूरा होता है या नहीं होता.
टैग: test_runner, terminal_output, execution

--output_filter=<a valid Java regular expression> डिफ़ॉल्ट: जानकारी देखें

सिर्फ़ उन नियमों के लिए चेतावनियां और कार्रवाई के आउटपुट दिखाता है जिनका नाम, दिए गए रेगुलर एक्सप्रेशन से मेल खाता है.
टैग: affects_outputs

--progress_report_interval=<an integer in 0-3600 range> डिफ़ॉल्ट: "0"

अभी चल रहे जॉब की रिपोर्ट के बीच इंतज़ार करने के लिए सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद, फिर 30 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, प्रोग्रेस हर मिनट में एक बार रिपोर्ट की जाएगी. --curses चालू होने पर, प्रोग्रेस हर सेकंड रिपोर्ट की जाती है.
टैग: affects_outputs

--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "failure"

चुनें कि रिमोट से चलाए गए निर्देशों के मैसेज कब प्रिंट किए जाएं. मान्य वैल्यू: सिर्फ़ गड़बड़ियों पर प्रिंट करने के लिए `failure`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए `success`, और हमेशा प्रिंट करने के लिए `all`.
टैग: terminal_output

--[no]sandbox_debug डिफ़ॉल्ट: "गलत"

सैंडबॉक्सिंग की सुविधा के लिए, डीबग करने की सुविधाएं चालू करता है. इसमें दो चीज़ें शामिल हैं: पहला, बिल्ड के बाद सैंडबॉक्स के रूट कॉन्टेंट में कोई बदलाव नहीं किया जाता; और दूसरा, इसे चलाने पर डीबग करने से जुड़ी अतिरिक्त जानकारी प्रिंट होती है. इससे, Bazel या Starlark नियमों के डेवलपर को इनपुट फ़ाइलों के मौजूद न होने वगैरह की वजह से, डीबग करने में होने वाली गड़बड़ियों को ठीक करने में मदद मिल सकती है.
टैग: terminal_output

--show_result=<an integer> डिफ़ॉल्ट: "1"

बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए बताएं कि उसे अप-टू-डेट किया गया था या नहीं. अगर किया गया था, तो उन आउटपुट फ़ाइलों की सूची दें जिन्हें बनाया गया था. प्रिंट की गई फ़ाइलें, शेल में कॉपी करके चिपकाने के लिए आसान स्ट्रिंग होती हैं, ताकि उन्हें चलाया जा सके. इस विकल्प के लिए, पूर्णांक आर्ग्युमेंट की ज़रूरत होती है. यह टारगेट की थ्रेशोल्ड संख्या होती है. इस थ्रेशोल्ड से ज़्यादा होने पर, नतीजों की जानकारी नहीं छपी जाती. इसलिए, शून्य की वैल्यू देने पर मैसेज नहीं दिखता और MAX_INT की वैल्यू देने पर नतीजा हमेशा दिखता है. डिफ़ॉल्ट रूप से, एक होता है. अगर किसी टारगेट के लिए कुछ भी नहीं बनाया गया है, तो आउटपुट को थ्रेशोल्ड के तहत रखने के लिए, उसके नतीजों को हटाया जा सकता है.
टैग: affects_outputs

--[no]subcommands [-s] डिफ़ॉल्ट: "false"

बिल्ड के दौरान चलाए गए सब-कमांड दिखाएं. मिलते-जुलते फ़्लैग: --execution_log_json_file, --execution_log_binary_file (टूल के हिसाब से फ़ॉर्मैट में, सब-कमांड को फ़ाइल में लॉग करने के लिए).
टैग: terminal_output

--test_output=<summary, errors, all or streamed> डिफ़ॉल्ट: "खास जानकारी"

पसंदीदा आउटपुट मोड के बारे में बताता है. सिर्फ़ टेस्ट की स्थिति की खास जानकारी दिखाने के लिए 'खास जानकारी', टेस्ट पास न होने पर टेस्ट लॉग भी प्रिंट करने के लिए 'गड़बड़ियां', सभी टेस्ट के लॉग प्रिंट करने के लिए 'सभी', और सभी टेस्ट के लॉग रीयल टाइम में दिखाने के लिए 'स्ट्रीम की गई'. इससे, --test_strategy की वैल्यू के बावजूद, टेस्ट को एक बार में एक करके स्थानीय तौर पर चलाया जाएगा.
टैग: test_runner, terminal_output, execution

--test_summary=<short, terse, detailed, none or testcase> डिफ़ॉल्ट: "short"

यह टेस्ट की खास जानकारी के लिए, मनचाहा फ़ॉर्मैट तय करता है. मान्य वैल्यू: 'short', सिर्फ़ चलाए गए टेस्ट की जानकारी प्रिंट करने के लिए, 'terse', सिर्फ़ उन टेस्ट की जानकारी प्रिंट करने के लिए जो पूरे नहीं हुए, 'detailed', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'testcase', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'none', खास जानकारी को हटाने के लिए.
टैग: terminal_output

--[no]verbose_explanations डिफ़ॉल्ट: "गलत"

--explain चालू होने पर, दी गई जानकारी को ज़्यादा शब्दों में दिखाता है. अगर --explain चालू नहीं है, तो इसका कोई असर नहीं पड़ता.
टैग: affects_outputs

--[no]verbose_failures डिफ़ॉल्ट: "गलत"

अगर कोई निर्देश काम नहीं करता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--aspects_parameters=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कमांड-लाइन के आसपेक्ट पैरामीटर की वैल्यू तय करता है. हर पैरामीटर की वैल्यू, <param_name>=<param_value> के ज़रिए तय की जाती है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param', --aspects सूची में किसी पहलू का पैरामीटर है या सूची में किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. हालांकि, एक ही पैरामीटर को एक से ज़्यादा बार वैल्यू असाइन करने की अनुमति नहीं है.
टैग: loading_and_analysis

--target_pattern_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो बिल्ड, कमांड लाइन के बजाय यहां बताई गई फ़ाइल से पैटर्न पढ़ेगा. यहां फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न भी बताना गलत है.
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें

यह सर्किट ब्रेकर के इस्तेमाल की रणनीति के बारे में बताता है. उपलब्ध रणनीतियां "फ़ेल" हैं. विकल्प के लिए अमान्य वैल्यू देने पर, विकल्प के लिए सेट किया गया व्यवहार नहीं दिखता.
टैग: execution

--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत"

किसी ऐक्शन की इनपुट फ़ाइलों को रिमोट कैश मेमोरी में अपलोड करने से पहले, उनकी ctime की जांच करने की सुविधा बंद करने के लिए, इसे बंद करें. कुछ मामलों में, Linux kernel फ़ाइलों को लिखने में देरी कर सकता है. इस वजह से, गलत नतीजे मिल सकते हैं.

--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 आईडी जनरेट किया है और उसे --invocation_id के साथ Bazel को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, --incompatible_remote_use_new_exit_code_for_lost_inputs फ़्लैग सेट करें और एग्ज़िट कोड 39 देखें.
टैग: execution

--[no]experimental_remote_cache_lease_extension डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैश मेमोरी में समय-समय पर `FindMissingBlobs` कॉल भेजकर, बिल्ड के दौरान रिमोट ऐक्शन के आउटपुट के लिए लीज़ को बढ़ा देगा. फ़्रीक्वेंसी, `--experimental_remote_cache_ttl` की वैल्यू पर आधारित होती है.

--experimental_remote_cache_ttl=<An immutable length of time.> डिफ़ॉल्ट: "3h"

रिमोट कैश मेमोरी में ब्लॉब का कम से कम टीटीएल, जब उनके डाइजेस्ट का हाल ही में रेफ़रंस दिया गया हो. जैसे, ActionResult या FindMissingBlobs. Bazel, ब्लॉब के टीटीएल के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, इंक्रीमेंटल बिल्ड में GetActionResult को बार-बार कॉल नहीं करता. वैल्यू को असल टीटीएल से थोड़ा कम सेट किया जाना चाहिए, क्योंकि सर्वर से डाइजेस्ट मिलने और Bazel को उनके मिलने में अंतर होता है.
टैग: execution

--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.

--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो GetActionResult() और Execute() को कॉल करने के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़ी इनपुट मैपिंग की मेमोरी में मौजूद कॉपी को हटा दें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में डेटा न मिलने और फिर से कोशिश करने पर, Bazel को उन्हें फिर से कैलकुलेट करना पड़ता है.

--experimental_remote_downloader=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट एसेट एपीआई एंडपॉइंट का यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाएगा. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

--[no]experimental_remote_downloader_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर का इस्तेमाल करना है या नहीं.

--[no]experimental_remote_downloader_propagate_credentials डिफ़ॉल्ट: "गलत"

netrc और क्रेडेंशियल हेल्पर से, रिमोट डाउनलोडर सर्वर पर क्रेडेंशियल भेजने का विकल्प. सर्वर को लागू करने के लिए, नए `http_header_url:<url-index>:<header-key>` क्वालिफ़ायर का इस्तेमाल करना ज़रूरी है. यहां `<url-index>`, FetchBlobRequest के `uris` फ़ील्ड में यूआरएल की 0-आधारित पोज़िशन है. यूआरएल के हिसाब से हेडर, ग्लोबल हेडर से ज़्यादा प्राथमिकता वाले होने चाहिए.

--[no]experimental_remote_execution_keepalive डिफ़ॉल्ट: "गलत"

रिमोट तरीके से प्रोसेस करने के लिए, keepalive का इस्तेमाल करना है या नहीं.

--experimental_remote_failure_rate_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "10"

यह किसी खास समयावधि के लिए, फ़ेल होने की दर को प्रतिशत में सेट करता है. इसके बाद, यह रिमोट कैश मेमोरी/एग्ज़ीक्यूटर को कॉल करना बंद कर देता है. डिफ़ॉल्ट रूप से, इसकी वैल्यू 10 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
टैग: execution

--experimental_remote_failure_window_interval=<An immutable length of time.> डिफ़ॉल्ट: "60s"

वह इंटरवल जिसमें रिमोट अनुरोधों के पूरा न होने की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव वैल्यू होने पर, गड़बड़ी की अवधि को पूरे एक्सीक्यूशन की अवधि के तौर पर कैलकुलेट किया जाता है.इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.
टैग: execution

--[no]experimental_remote_mark_tool_inputs डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, इनपुट को रिमोट एक्सीक्यूटर के लिए टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट पर लगातार काम करने वाले वर्कर लागू करने के लिए किया जा सकता है.

--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेर्कल ट्री कैलकुलेशन को मेमोइज़ किया जाएगा. कैश मेमोरी का फ़ुटप्रिंट, --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.

--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000"

रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेमोज़ करने वाले मेर्कल ट्री की संख्या. भले ही, सॉफ़्ट रेफ़रंस को मैनेज करने के लिए Java, कैश मेमोरी को अपने-आप कम करता है, लेकिन बहुत ज़्यादा सेट करने पर, मेमोरी खत्म होने की गड़बड़ियां हो सकती हैं. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड होता है. प्रोजेक्ट के साइज़ के हिसाब से, ऑप्टिमम वैल्यू अलग-अलग होती है. डिफ़ॉल्ट रूप से 1,000 पर सेट होती है.

--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> डिफ़ॉल्ट: ""

यह वह पाथ है जिसमें --experimental_remote_output_service की मदद से मैनेज की जाने वाली आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. किसी बिल्ड में इस्तेमाल की जाने वाली असल आउटपुट डायरेक्ट्री, इस पाथ की एक सब-डायरेक्ट्री होगी. यह आउटपुट सेवा के हिसाब से तय की जाएगी.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो यह पक्का करें कि दूर से चलने वाली सभी कार्रवाइयों को कैश मेमोरी में सेव किया गया हो. ऐसा न करने पर, बिल्ड पूरा नहीं होगा. यह गैर-तय समस्याओं को हल करने में मददगार है. इससे यह जांच की जा सकती है कि कैश मेमोरी में सेव की जानी वाली कार्रवाइयां, असल में कैश मेमोरी में सेव की गई हैं या नहीं. ऐसा करने के लिए, कैश मेमोरी में नए नतीजे इंजेक्ट नहीं किए जाते.

--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]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो कैश मेमोरी खाली करने जैसी रिमोट कैश मेमोरी से जुड़ी गड़बड़ियों की वजह से, बिल्ड पूरा न होने पर Bazel, 34 के बजाय नए एक्सिट कोड 39 का इस्तेमाल करेगा.
टैग: incompatible_change

--[no]remote_accept_cached डिफ़ॉल्ट: "सही"

क्या रिमोट से कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को स्वीकार करना है.

--remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "minimal"

अगर इसे 'सभी' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड हो जाते हैं. अगर इसे 'कम से कम' पर सेट किया जाता है, तो BEP के रेफ़रंस वाले लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते.हालांकि, BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों (जैसे, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल) को अपलोड किया जाता है. फ़ाइलों के यूआरआई के लिए, bytestream:// स्कीम का हमेशा इस्तेमाल किया जाता है. भले ही, वे रिमोट कैश मेमोरी में मौजूद न हों. डिफ़ॉल्ट रूप से 'कम से कम' पर सेट होता है.

--remote_bytestream_uri_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट स्ट्रीम में लिखे गए bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम. यह विकल्प तब सेट किया जा सकता है, जब किसी प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इसकी वजह से, --remote_executor और --remote_instance_name की वैल्यू, रिमोट इकसेक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. सेट न होने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.

--remote_cache=<a string> डिफ़ॉल्ट: जानकारी देखें

कैश मेमोरी में डेटा सेव करने वाले एंडपॉइंट का यूआरआई. इन स्कीम का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा की जानकारी दें. https://bazel.build/remote/caching पर जाएं

--[no]remote_cache_async डिफ़ॉल्ट: "सही"

अगर यह सही है, तो किसी कार्रवाई के पूरा होने को ब्लॉक करने के बजाय, डिस्क या रिमोट कैश मेमोरी में कार्रवाई के नतीजों को बैकग्राउंड में अपलोड किया जाएगा. कुछ कार्रवाइयां, बैकग्राउंड में अपलोड करने की सुविधा के साथ काम नहीं करती हैं. साथ ही, यह फ़्लैग सेट होने के बाद भी, उन्हें ब्लॉक किया जा सकता है.

--[no]remote_cache_compression डिफ़ॉल्ट: "गलत"

अगर यह चालू है, तो कैश मेमोरी में मौजूद ब्लॉब का साइज़ कम से कम --experimental_remote_cache_compression_threshold होने पर, zstd की मदद से उन्हें कंप्रेस/डिकंप्रेस करें.

--remote_cache_header=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कैश मेमोरी के अनुरोधों में शामिल किया जाने वाला हेडर तय करें: --remote_cache_header=Name=Value. एक से ज़्यादा हेडर पास करने के लिए, फ़्लैग को कई बार डालें. एक ही नाम के लिए एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.

--remote_default_exec_properties=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर कोई एक्सीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो डिफ़ॉल्ट exec प्रॉपर्टी सेट करें, ताकि उनका इस्तेमाल रिमोट एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर किया जा सके.
टैग: affects_outputs

--remote_default_platform_properties=<a string> डिफ़ॉल्ट: ""

अगर एक्सीक्यूशन प्लैटफ़ॉर्म पर पहले से ही remote_execution_properties सेट नहीं है, तो रिमोट एक्सीक्यूशन एपीआई के लिए सेट की जाने वाली डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी सेट करें. अगर होस्ट प्लैटफ़ॉर्म को रिमोट तौर पर चलाने के लिए, एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल भी किया जाएगा.

--remote_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> डिफ़ॉल्ट: "0"

रिमोट तौर पर की जाने वाली कार्रवाइयों की प्राथमिकता. प्राथमिकता की खास वैल्यू का सेमेटिक्स, सर्वर पर निर्भर करता है.

--remote_executor=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट तौर पर प्रोग्राम चलाने वाले एंडपॉइंट का HOST या HOST:PORT. इन स्कीमा का इस्तेमाल किया जा सकता है: grpc, grpcs (TLS चालू होने पर grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा की वैल्यू दें.

--remote_grpc_log=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर यह पैरामीटर दिया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए, फ़ाइल का पाथ. इस लॉग में, सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry protobufs का क्रम होता है. हर मैसेज के आगे एक वैरिएंट होता है, जो सीरियलाइज़ किए गए अगले protobuf मैसेज का साइज़ दिखाता है. ऐसा, LogEntry.writeDelimitedTo(OutputStream) तरीके से किया जाता है.

--remote_header=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसा हेडर डालें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. एक से ज़्यादा हेडर पास करने के लिए, फ़्लैग को कई बार डालें. एक ही नाम के लिए एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.

--remote_instance_name=<a string> डिफ़ॉल्ट: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट तरीके से लागू करने की प्रोसेस पूरी न होने पर, स्टैंडअलोन लोकल तरीके से लागू करने की रणनीति का इस्तेमाल करना है या नहीं.

--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "local"

अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

--remote_max_connections=<an integer> डिफ़ॉल्ट: "100"

रिमोट कैश मेमोरी/एग्ज़ीक्यूटर पर एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, यह तय करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एग्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को मैनेज कर सकता है. इसलिए, Bazel एक साथ `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग: host_machine_resource_optimizations

--remote_proxy=<a string> डिफ़ॉल्ट: जानकारी देखें

प्रॉक्सी के ज़रिए रिमोट कैश मेमोरी से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.

--remote_result_cache_priority=<an integer> डिफ़ॉल्ट: "0"

रिमोट कैश मेमोरी में सेव किए जाने वाले रिमोट ऐक्शन की प्राथमिकता. प्राथमिकता की खास वैल्यू का सेमेटिक्स, सर्वर पर निर्भर करता है.

--remote_retries=<an integer> डिफ़ॉल्ट: "5"

कुछ समय के लिए होने वाली गड़बड़ी को ठीक करने के लिए, ज़्यादा से ज़्यादा कितनी बार कोशिश की जा सकती है. अगर इसे 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.

--remote_retry_max_delay=<An immutable length of time.> डिफ़ॉल्ट: "5s"

रिमोट तौर पर फिर से कोशिश करने के बीच, ज़्यादा से ज़्यादा बैकऑफ़ देरी. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--remote_timeout=<An immutable length of time.> डिफ़ॉल्ट: "60s"

रिमोट तरीके से एक्सीक्यूशन और कैश मेमोरी कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट और पढ़ने के लिए टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर यूनिट नहीं दी जाती है, तो वैल्यू को सेकंड के तौर पर माना जाता है.

--[no]remote_upload_local_results डिफ़ॉल्ट: "सही"

अगर रिमोट कैश मेमोरी में कार्रवाई के नतीजे अपलोड किए जा सकते हैं और उपयोगकर्ता के पास ऐसा करने की अनुमति है, तो क्या लोकल तौर पर की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है.

--[no]remote_verify_downloads डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो Bazel सभी रिमोट डाउनलोड के हैश का कुल हिसाब लगाएगा. साथ ही, अगर रिमोट से कैश मेमोरी में सेव की गई वैल्यू, उम्मीद के मुताबिक नहीं होती हैं, तो उन्हें खारिज कर देगा.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--[no]allow_analysis_cache_discard डिफ़ॉल्ट: "सही"

अगर बिल्ड सिस्टम में हुए बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज किया जाता है, तो इस विकल्प को 'गलत है' पर सेट करने पर, bazel बिल्ड जारी रखने के बजाय बंद हो जाएगा. अगर 'discard_analysis_cache' भी सेट है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit

--auto_output_filter=<none, all, packages or subpackages> डिफ़ॉल्ट: "none"

अगर --output_filter की वैल्यू नहीं दी गई है, तो इस विकल्प की वैल्यू का इस्तेमाल करके, अपने-आप फ़िल्टर बन जाता है. इस विकल्प के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: 'none' (कुछ भी फ़िल्टर न करें / सब कुछ दिखाएं), 'all' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'packages' (Blaze कमांड लाइन पर बताए गए पैकेज में नियमों का आउटपुट शामिल करें), और 'subpackages' ('packages' की तरह, लेकिन इसमें सब-पैकेज भी शामिल हैं). 'पैकेज' और 'सब-पैकेज' वैल्यू के लिए, //java/foo और //javatests/foo को एक पैकेज माना जाता है).

--[no]build_manual_tests डिफ़ॉल्ट: "गलत"

'मैन्युअल' के तौर पर टैग किए गए टेस्ट टारगेट को बनाने के लिए मजबूर करता है. 'मैन्युअल' टेस्ट को प्रोसेस से बाहर रखा जाता है. इस विकल्प की मदद से, उन्हें बनाने के लिए मजबूर किया जाता है, लेकिन उन्हें लागू नहीं किया जाता.

--build_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प का असर, 'test' कमांड के साथ चलाए गए टेस्ट के सेट पर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों से कंट्रोल किए जाते हैं. उदाहरण के लिए, '--test_tag_filters'

--[no]build_tests_only डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चुना जाता है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.

--combined_report=<none or lcov> डिफ़ॉल्ट: "none"

यह बताता है कि कवरेज की कुल रिपोर्ट किस तरह की होनी चाहिए. फ़िलहाल, सिर्फ़ LCOV का इस्तेमाल किया जा सकता है.

--[no]compile_one_dependency डिफ़ॉल्ट: "गलत"

आर्ग्युमेंट फ़ाइलों की एक डिपेंडेंसी को कॉम्पाइल करें. यह आईडीई में सोर्स फ़ाइलों के सिंटैक्स की जांच करने के लिए मददगार है. उदाहरण के लिए, बदलाव करने/बिल्ड करने/जांच करने के दौरान, गड़बड़ियों का पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर किसी एक टारगेट को फिर से बनाकर. इस आर्ग्युमेंट से, उन सभी आर्ग्युमेंट के इस्तेमाल के तरीके पर असर पड़ता है जो फ़्लैग नहीं हैं. ये आर्ग्युमेंट, बिल्ड करने के टारगेट के बजाय सोर्स फ़ाइल के नाम होते हैं. हर सोर्स फ़ाइल नाम के लिए, उस पर निर्भर कोई भी टारगेट बनाया जाएगा.

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह शिकायत कर सकता है. ऐसा तब होता है, जब वह लेबल अब भी किसी अन्य package_path एंट्री से दिया जाता है. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[no]discard_analysis_cache डिफ़ॉल्ट: "गलत"

विश्लेषण का फ़ेज़ पूरा होने के तुरंत बाद, विश्लेषण कैश मेमोरी को खारिज कर दें. इससे मेमोरी के इस्तेमाल में ~10% की कमी आती है. हालांकि, इससे इंक्रीमेंटल बिल्ड धीमे होते हैं.

--disk_cache=<a path> डिफ़ॉल्ट: जानकारी देखें

ऐसी डायरेक्ट्री का पाथ जहां Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.

--embed_label=<a one-line string> डिफ़ॉल्ट: ""

सोर्स कंट्रोल रिविज़न या रिलीज़ लेबल को बाइनरी में एम्बेड करना

--execution_log_binary_file=<a path> डिफ़ॉल्ट: जानकारी देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में, चलाए गए स्पैन को लंबाई के हिसाब से बांटा गया 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 प्रोटो के न्यूलाइन डीलिमिटेड JSON रिप्रज़ेंटेशन के तौर पर, इस फ़ाइल में लॉन्च किए गए स्पैन को लॉग करें. --execution_log_compact_file को प्राथमिकता दें, क्योंकि यह काफ़ी छोटी होती है और इसे बनाने में कम खर्च आता है. इससे जुड़े फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_binary_file (बाइनरी प्रोटोबस फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--[no]execution_log_sort डिफ़ॉल्ट: "सही"

कार्रवाई के लॉग को क्रम से लगाना है या नहीं. इससे, सभी अनुरोधों के लॉग की तुलना करना आसान हो जाता है. कॉल के आखिर में सीपीयू और मेमोरी के ज़्यादा इस्तेमाल से बचने के लिए, इसे 'गलत' पर सेट करें. हालांकि, ऐसा करने पर लॉग को लागू करने का क्रम तय नहीं किया जा सकेगा. यह सिर्फ़ बाइनरी और JSON फ़ॉर्मैट पर लागू होता है. कॉम्पैक्ट फ़ॉर्मैट को कभी क्रम से नहीं लगाया जाता.

--[no]expand_test_suites डिफ़ॉल्ट: "सही"

विश्लेषण से पहले, test_suite टारगेट को उनके कॉम्पोनेंट टेस्ट में बड़ा करें. यह फ़्लैग चालू होने पर (डिफ़ॉल्ट रूप से), नेगेटिव टारगेट पैटर्न, टेस्ट सुइट से जुड़े टेस्ट पर लागू होंगे. ऐसा न होने पर, ये पैटर्न लागू नहीं होंगे. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड-लाइन पर टॉप-लेवल के पहलू लागू किए जाते हैं: तब वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis

--experimental_disk_cache_gc_idle_delay=<An immutable length of time.> डिफ़ॉल्ट: "5m"

डिस्क कैश की ग़ैर-ज़रूरी फ़ाइलें हटाने से पहले, सर्वर को कितने समय तक बंद रखना चाहिए. ग़ैर-ज़रूरी डेटा हटाने की नीति तय करने के लिए, --experimental_disk_cache_gc_max_size और/या --experimental_disk_cache_gc_max_age सेट करें.

--experimental_disk_cache_gc_max_age=<An immutable length of time.> डिफ़ॉल्ट: "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> डिफ़ॉल्ट: "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> डिफ़ॉल्ट: ""

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. extra_actions को शेड्यूल करने के लिए, टारगेट के सेट को फ़िल्टर करता है.

--[no]experimental_extra_action_top_level_only डिफ़ॉल्ट: "गलत"

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. सिर्फ़ टॉप लेवल टारगेट के लिए extra_actions शेड्यूल करता है.

--experimental_spawn_scheduler

कार्रवाइयों को एक साथ स्थानीय और रिमोट तौर पर चलाकर, डाइनैमिक तरीके से लागू करने की सुविधा चालू करें. Bazel, हर कार्रवाई को स्थानीय और रिमोट तौर पर शुरू करता है. साथ ही, वह उस कार्रवाई को चुनता है जो सबसे पहले पूरी होती है. अगर कोई कार्रवाई, वर्कर के साथ काम करती है, तो लोकल कार्रवाई, पर्सिस्टेंट वर्कर मोड में चलेगी. किसी एक ऐक्शन के लिए डाइनैमिक तरीके से प्रोसेस करने की सुविधा चालू करने के लिए, `--internal_spawn_scheduler` और `--strategy=<mnemonic>=dynamic` फ़्लैग का इस्तेमाल करें.
इस तरह बड़ा होता है:
  --internal_spawn_scheduler
  --spawn_strategy=dynamic

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--local_termination_grace_seconds=<an integer> डिफ़ॉल्ट: "15"

टाइम आउट की वजह से किसी स्थानीय प्रोसेस को बंद करने और उसे जबरदस्ती बंद करने के बीच इंतज़ार करने का समय.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--test_lang_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

यह टेस्ट की जाने वाली भाषाओं की सूची होती है. इसमें भाषाओं को कॉमा लगाकर अलग किया जाता है. जिन भाषाओं के लिए अनुवाद नहीं करना है उनके लिए, हर भाषा के पहले '-' लगाया जा सकता है. सिर्फ़ वे टेस्ट टारगेट दिखेंगे जो चुनी गई भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test नियम में भाषा के प्रीफ़िक्स जैसा ही होना चाहिए. जैसे, 'cc', 'java', 'py' वगैरह में से कोई एक. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.

--test_size_filters=<comma-separated list of values: small, medium, large, or enormous> डिफ़ॉल्ट: ""

यह टेस्ट साइज़ की कॉमा से अलग की गई सूची तय करता है. शामिल नहीं किए गए साइज़ की जानकारी देने के लिए, हर साइज़ के आगे '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. आपको सिर्फ़ ऐसे टेस्ट टारगेट दिखेंगे जिनमें शामिल किए गए कम से कम एक साइज़ शामिल हो और बाहर रखे गए कोई साइज़ शामिल न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

टेस्ट टैग की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. आपको सिर्फ़ ऐसे टेस्ट टारगेट मिलेंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_timeout_filters=<comma-separated list of values: short, moderate, long, or eternal> डिफ़ॉल्ट: ""

टेस्ट टाइम आउट की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टाइम आउट की जानकारी देने के लिए, हर टाइम आउट के पहले '-' लगाया जा सकता है. सिर्फ़ ऐसे टेस्ट टारगेट दिखेंगे जिनमें कम से कम एक शामिल किया गया टाइम आउट हो और कोई बाहर रखा गया टाइम आउट न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--workspace_status_command=<path> डिफ़ॉल्ट: ""

यह एक ऐसा निर्देश है जिसे बिल्ड की शुरुआत में ट्रिगर किया जाता है. इससे, की/वैल्यू पेयर के तौर पर, वर्कस्पेस की स्थिति की जानकारी मिलती है. पूरी जानकारी के लिए, उपयोगकर्ता मैन्युअल देखें. उदाहरण के लिए, tools/buildstamp/get_workspace_status भी देखें.

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "सही"

किसी हेल्पर प्रोसेस को काम सौंपने के बजाय, सिमलिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे कॉल करना है या नहीं.
टैग: loading_and_analysis, execution, experimental

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "गलत"

वर्कर्स का इस्तेमाल करके, लगातार काम करने वाला aar एक्सट्रैक्टर चालू करें.
टैग: execution, experimental

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "गलत"

सोर्स मेनिफ़ेस्ट ऐक्शन को रिमोट से कंट्रोल किया जा सकता है या नहीं
टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel एक नए स्पैन में टेस्ट के लिए कवरेज पोस्ट-प्रोसेसिंग चलाएगा.
टैग: execution, experimental

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो फ़ाइल सेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर इस्तेमाल करेंगे. ये डायरेक्ट्री में नहीं जाएंगे या सिमलिन्क के लिए संवेदनशील नहीं होंगे.
टैग: execution, experimental

--[no]incompatible_modify_execution_info_additive डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो एक से ज़्यादा --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 के ऐसे टूल चालू करना जो लगातार काम करते हैं और एक से ज़्यादा काम करते हैं. जैसे, डीकंपाइल करना, डीसुगर करना, और संसाधन प्रोसेस करना.
इस तरह बड़ा होता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel टेस्ट चलाने के लिए, टेस्ट एक्सीक्यूट ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा.
टैग: execution

ऐक्शन को लागू करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--android_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android"

android_binary नियमों के लिए इस्तेमाल करने के लिए, मेनिफ़ेस्ट मर्ज करने वाला टूल चुनता है. लेगसी मर्ज से Android मेनिफ़ेस्ट मर्ज पर ट्रांज़िशन करने में मदद करने के लिए फ़्लैग.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_platforms=<a build target label> डिफ़ॉल्ट: ""

उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए जाते हैं, तो बाइनरी एक फ़ैट APK होती है. इसमें, टारगेट किए गए हर प्लैटफ़ॉर्म के लिए नेटिव बाइनरी होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

Apple और Objc नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger"

बाइनरी की जगह, जिसका इस्तेमाल कवरेज की रॉ रिपोर्ट को पोस्ट-प्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, '//tools/test:lcov_merger' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_report_generator' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_support"

कोड कवरेज इकट्ठा करने वाली हर टेस्ट ऐक्शन के इनपुट पर ज़रूरी सहायता फ़ाइलों की जगह. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_support' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--custom_malloc=<a build target label> डिफ़ॉल्ट: जानकारी देखें

malloc फ़ंक्शन को पसंद के मुताबिक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs

--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के आगे - (नेगेटिव एक्सप्रेशन) लगाने का विकल्प होता है. यह सूची, कॉमा लगाकर अलग की गई पाबंदी की वैल्यू के टारगेट की सूची को (=) असाइन करती है. अगर कोई टारगेट किसी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा जैसे उसने शर्त की वैल्यू को, लागू करने से जुड़ी शर्तों के तौर पर बताया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64, //demo के तहत मौजूद किसी भी टारगेट में 'x86_64' जोड़ देगा. हालांकि, जिन टारगेट के नाम में 'test' शामिल है उनमें यह पैरामीटर नहीं जोड़ा जाएगा.
टैग: loading_and_analysis

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "गलत"

अगर सेट है, तो हर Xcode ऐक्शन के लिए, "requires-xcode:{version}" को लागू करने की ज़रूरी शर्त जोड़ें. अगर Xcode वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" को भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution, experimental

--[no]experimental_prefer_mutual_xcode डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सबसे नए Xcode का इस्तेमाल करें. यह Xcode, लोकल और रिमोट, दोनों जगहों पर उपलब्ध होता है. अगर यह फ़ॉल्स है या दोनों डिवाइसों पर एक ही वर्शन उपलब्ध नहीं है, तो xcode-select की मदद से चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state, experimental

--extra_execution_platforms=<comma-separated list of options> डिफ़ॉल्ट: ""

ऐसे प्लैटफ़ॉर्म जो ऐक्शन चलाने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को एग्ज़ैक्ट टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म को, register_execution_platforms() की मदद से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले इस्तेमाल किया जाएगा. यह विकल्प सिर्फ़ एक बार सेट किया जा सकता है. बाद के इंस्टेंस, फ़्लैग की पिछली सेटिंग को बदल देंगे.
टैग: execution

--extra_toolchains=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों को ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन की मदद से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले इस्तेमाल किया जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--grte_top=<a label> डिफ़ॉल्ट: जानकारी देखें

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़े.
टैग: action_command_lines, affects_outputs

--host_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

कोई कार्रवाई न करने वाला फ़्लैग. इसे आने वाले वर्शन में हटा दिया जाएगा.
टैग: loading_and_analysis, execution

--host_grte_top=<a label> डिफ़ॉल्ट: जानकारी देखें

अगर यह सेटिंग तय की जाती है, तो यह exec कॉन्फ़िगरेशन के लिए, libc टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools:host_platform"

होस्ट सिस्टम के बारे में बताने वाले प्लैटफ़ॉर्म नियम का लेबल.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_bazel_test_exec_run_under डिफ़ॉल्ट: "गलत"

अगर यह चालू है, तो "bazel test --run_under=//:runner", exec कॉन्फ़िगरेशन में "//:runner" को बनाता है. बंद होने पर, यह टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, टेस्ट को exec मशीनों पर चलाता है. इसलिए, पहला तरीका ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता, जो हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'नॉन-होस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "गलत"

Apple के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करना
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो 'रन करने लायक फ़ाइलों' के लिए स्ट्रिप ऐक्शन, फ़्लैग -x का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change

--[no]interface_shared_objects डिफ़ॉल्ट: "सही"

अगर टूलचेन काम करता है, तो इंटरफ़ेस के शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, सभी ELF टूलचेन इस सेटिंग के साथ काम करते हैं.
टैग: loading_and_analysis, affects_outputs, affects_outputs

--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

iOS ऐप्लिकेशन बनाने के लिए, iOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

macOS ऐप्लिकेशन बनाने के लिए, macOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से macOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--minimum_os_version=<a string> डिफ़ॉल्ट: जानकारी देखें

ऑपरेटिंग सिस्टम का वह कम से कम वर्शन जिसे आपका कंपाइलेशन टारगेट करता है.
टैग: loading_and_analysis, affects_outputs

--platform_mappings=<a main workspace-relative path> डिफ़ॉल्ट: ""

मैपिंग फ़ाइल की जगह, जो बताती है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है या कोई प्लैटफ़ॉर्म पहले से मौजूद होने पर, कौनसे फ़्लैग सेट करने हैं. यह मुख्य फ़ाइल फ़ोल्डर से जुड़ा होना चाहिए. डिफ़ॉल्ट रूप से, 'platform_mappings' (वर्कस्पेस रूट में मौजूद फ़ाइल) पर सेट होता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis, immutable

--platforms=<a build target label> डिफ़ॉल्ट: ""

मौजूदा निर्देश के लिए टारगेट किए गए प्लैटफ़ॉर्म के बारे में बताने वाले, प्लैटफ़ॉर्म के नियमों के लेबल.
टैग: 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> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"

xcode_config नियम का लेबल, जिसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत"

डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines

--[no]build_runfile_links डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइलों के सिमलिंक फ़ॉरेस्ट बनाएं. अगर यह फ़ील्ड 'गलत' पर सेट है, तो इसे सिर्फ़ तब लिखें, जब किसी स्थानीय कार्रवाई, जांच या चलाने के कमांड की ज़रूरत हो.
टैग: affects_outputs

--[no]build_runfile_manifests डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह 'गलत है' पर सेट है, तो उन्हें शामिल न करें. अगर यह वैल्यू 'गलत' है, तो स्थानीय टेस्ट नहीं चलेंगे.
टैग: affects_outputs

--[no]build_test_dwp डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िज़न की मदद से बिल्ड करते समय, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बिल्ड हो जाएगी.
टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h"

cc_proto_library से बनने वाली हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc"

cc_proto_library से बनने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत"

proto_library में, अन्य Java API वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत"

कंपाइलेशन के आउटपुट के तौर पर, चालू और अनुरोध किए गए फ़ीचर की स्थिति सेव करें.
टैग: affects_outputs, experimental

--fission=<a set of compilation modes> डिफ़ॉल्ट: "no"

यह बताता है कि C++ कंपाइलेशन और लिंक के लिए, कौनसे कंपाइलेशन मोड फ़िज़न का इस्तेमाल करते हैं. यह {'fastbuild', 'dbg', 'opt'} या सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू का कोई भी कॉम्बिनेशन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही"

अगर यह सही है, तो नेटिव नियम अपने रनफ़ाइल में डेटा डिपेंडेंसी की <code>DefaultInfo.files</code> जोड़ते हैं. यह Starlark नियमों के लिए सुझाए गए व्यवहार से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change

--[no]legacy_external_runfiles डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो .runfiles/wsname/external/repo के तहत, बाहरी रिपॉज़िटरी के लिए runfiles सिमलिंक फ़ॉरेस्ट बनाएं. साथ ही, .runfiles/repo में भी बनाएं.
टैग: affects_outputs

--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत"

यह बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs

--[no]save_temps डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो gcc से मिलने वाले अस्थायी आउटपुट सेव हो जाएंगे. इनमें .s फ़ाइलें (असेम्बलर कोड), .i फ़ाइलें (प्रीप्रोसेस की गई C) और .ii फ़ाइलें (प्रीप्रोसेस की गई C++) शामिल हैं.
टैग: affects_outputs

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टारगेट कॉन्फ़िगरेशन वाले ऐक्शन के लिए उपलब्ध, एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. यह पेयर, कॉल करने के एनवायरमेंट से अलग वैल्यू सेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines

--allowed_cpu_values=<comma-separated set of options> डिफ़ॉल्ट: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.
टैग: changes_inputs, affects_outputs

--[no]android_databinding_use_androidx डिफ़ॉल्ट: "सही"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है. इस फ़्लैग का कोई असर नहीं पड़ता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "सही"

3.4.0 आर्ग्युमेंट के साथ Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं पड़ता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद"

यह तय करता है कि जब cc_binary साफ़ तौर पर कोई शेयर की गई लाइब्रेरी न बनाए, तो Android नियमों के C++ डिपेंडेंसी डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "alphabetical"

Android बाइनरी के लिए, मेनिफ़ेस्ट मर्ज करने वाले टूल को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अंग्रेज़ी वर्णमाला के क्रम में का मतलब है कि मेनिफ़ेस्ट, execroot के हिसाब से पाथ के हिसाब से क्रम में लगाए जाते हैं. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]build_python_zip डिफ़ॉल्ट: "auto"

Python के लिए, ज़िप फ़ाइल में प्रोग्राम को चलाने की सुविधा जोड़ना; Windows पर चालू, अन्य प्लैटफ़ॉर्म पर बंद करना
टैग: affects_outputs

--catalyst_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है. इन आर्किटेक्चर के लिए, Apple Catalyst बाइनरी बनाई जानी हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "गलत"

अगर तय किया गया है, तो Bazel कोड को इंस्ट्रूमेंट करेगा. इसके लिए, जहां भी हो सके वहां ऑफ़लाइन इंस्ट्रूमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा की जाएगी. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "fastbuild"

बाइनरी को जिस मोड में बनाया जाएगा उसके बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

gcc को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ नाम बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाले FDO इंस्ट्रूमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से बनी प्रोफ़ाइल को दिखाने वाली cs_fdo_profile, जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs

--cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

--define का हर विकल्प, किसी बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू दी गई हैं, तो आखिरी वैल्यू का इस्तेमाल किया जाएगा.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default"

यह तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_propeller_optimize_absolute_paths डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो propeller optimize के लिए एब्सोलूट पाथ का इस्तेमाल करने पर गड़बड़ी दिखेगी.
टैग: affects_outputs

--[no]enable_remaining_fdo_absolute_paths डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो एफ़डीओ के लिए एब्सोलूट पाथ का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "auto"

रनफ़ाइल्स के सिमलिंक ट्री को चालू करें; डिफ़ॉल्ट रूप से, यह Windows और अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में जावा संसाधनों को कंप्रेस करना
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं पड़ता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत"

dex फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करना
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत"

अगर यह जानकारी दी जाती है, तो Bazel जनरेट की गई फ़ाइलों के लिए कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs, experimental

--experimental_objc_fastbuild_options=<comma-separated list of options> डिफ़ॉल्ट: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc फ़ास्टबिल्ड कंपाइलर के विकल्पों के तौर पर किया जाता है.
टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो स्टैक को अनवाइंड करने के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कॉम्पाइल करें.
टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off, content or strip> डिफ़ॉल्ट: "बंद"

आउटपुट ट्री के नियमों में, आउटपुट कहां लिखे जाएं, इसके लिए किस मॉडल का इस्तेमाल करना है. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन वाले बिल्ड के लिए. यह सुविधा एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. 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 डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. सटीक स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है: सबसे पहले, अगर --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 डिफ़ॉल्ट: "गलत"

py_binary टारगेट में, स्टैंपिंग बंद होने पर भी उनका लेबल शामिल होता है.
टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत"

अगर यह तय किया गया है, तो collect_code_coverage चालू होने पर, Bazel gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic डिफ़ॉल्ट: "सही"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ सुझाई गई माइग्रेशन या टेस्टिंग की रणनीति के हिस्से के तौर पर करें. ध्यान दें कि हेयुरिस्टिक्स में कुछ कमियां हैं. हमारा सुझाव है कि सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करके माइग्रेट करें.
टैग: affects_outputs, experimental

--fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें

एफ़डीओ इंस्ट्रूमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs

--fdo_optimize=<a string> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. उस ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल शामिल हो. यह फ़्लैग, लेबल के तौर पर बताई गई फ़ाइलों को भी स्वीकार करता है.जैसे, `//foo/bar:file. afdo` - आपको उससे जुड़े पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है.साथ ही, यह फ़्लैग, `fdo_profile` टारगेट पर ले जाने वाले लेबल को भी स्वीकार करता है. इस फ़्लैग की जगह, `fdo_profile` नियम लागू होगा.
टैग: affects_outputs

--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कैश मेमोरी में प्रीफ़ेच करने के सुझावों का इस्तेमाल करें.
टैग: affects_outputs

--fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

fdo_profile, ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल को दिखाता है.
टैग: affects_outputs

--features=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> की वैल्यू सबमिट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक सुविधाएं, हमेशा सकारात्मक सुविधाओं की जगह ले लेती हैं. --host_features देखें
टैग: changes_inputs, affects_outputs

--[no]force_pic डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. साथ ही, लिंक करने के लिए, PIC वाली पहले से बनी लाइब्रेरी का इस्तेमाल किया जाता है, न कि PIC वाली लाइब्रेरी का. इसके अलावा, लिंक करने पर पोज़िशन-इंडिपेंडेंट एक्सीक्यूटेबल ("-pie") जनरेट होते हैं.
टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह, ऐक्शन के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. यह सेट, ऐक्शन के लिए इस्तेमाल किए जाने वाले एक्सीक्यूशन कॉन्फ़िगरेशन के साथ उपलब्ध होता है. वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. यह पेयर, कॉल करने के एनवायरमेंट से अलग वैल्यू सेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> डिफ़ॉल्ट: "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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_cpu=<a string> डिफ़ॉल्ट: ""

होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_features=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> की वैल्यू सबमिट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक सुविधाएं, हमेशा सकारात्मक सुविधाओं की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

exec कॉन्फ़िगरेशन के लिए, Python वर्शन को बदल देता है. यह "PY2" या "PY3" हो सकता है.
टैग: loading_and_analysis, affects_outputs

--host_linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एक्सीक्यूट कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

होस्ट टारगेट के लिए, macOS का कम से कम काम करने वाला वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. option_1 से option_n तक, मनमुताबिक कमांड लाइन के विकल्प हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "गलत"

इस विकल्प के चालू होने पर, नियम के तहत इस्तेमाल किए गए हर टूलचेन के लिए, एक एक्सेक्यूट ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों में `टूलचेन` पैरामीटर की जानकारी देनी होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही"

अगर यह सही है, तो genfiles डायरेक्ट्री को bin डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "गलत"

कवरेज चालू होने पर, यह तय करता है कि टेस्ट नियमों को इंस्ट्रूमेंट करना है या नहीं. सेट होने पर, --instrumentation_filter से शामिल किए गए टेस्ट नियमों को इंस्ट्रूमेंट किया जाता है. ऐसा न करने पर, टेस्ट के नियमों को कवरेज इंस्ट्रूमेंटेशन से हमेशा बाहर रखा जाता है.
टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/javatests[/:],-/test/java[/:]"

कवरेज चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रूमेंट किया जाएगा जिनके नाम, रेगुलर एक्सप्रेशन पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि --instrument_test_targets चालू होने तक, सिर्फ़ नॉन-टेस्ट नियम इंस्ट्रुमेंट किए जाते हैं.
टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'ios_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--ios_multi_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ios_application बनाने के लिए, कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची. इसका नतीजा एक यूनिवर्सल बाइनरी होता है, जिसमें सभी तय किए गए आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive डिफ़ॉल्ट: "सही"

अब काम नहीं करता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में, linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर, alwayslink=1 का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ बैकएंड चरण (--features=thin_lto में) पर जाने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ को इंडेक्स करने के चरण पर जाने के लिए अन्य विकल्प (--features=thin_lto में).
टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है. इन आर्किटेक्चर के लिए, Apple macOS बाइनरी बनाई जानी हैं.
टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट के लिए, macOS का कम से कम काम करने वाला वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "गलत"

अगर यह सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS तय करें.
टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत"

लिंक की गई बाइनरी पर, सिंबल और डेड-कोड हटाने की प्रोसेस की जानी चाहिए या नहीं. अगर इस फ़्लैग और --compilation_mode=opt, दोनों को तय किया जाता है, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

--objccopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. option_1 से option_n तक, मनमुताबिक कमांड लाइन के विकल्प हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड (--features=thin_lto में) को चुनिंदा तौर पर पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. option_1 से option_n, कमांड लाइन के मनमुताबिक विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, bar.o को छोड़कर //foo/ में मौजूद सभी o फ़ाइलों की LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: जानकारी देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. इस फ़्लैग में एक बिल्ड लेबल डाला जा सकता है. यह लेबल, प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों का रेफ़रंस होना चाहिए. उदाहरण के लिए, a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",) में मौजूद, लेबल की जानकारी देने वाली BUILD फ़ाइल. इन फ़ाइलों को Bazel को दिखाने के लिए, उससे जुड़े पैकेज में exports_files डायरेक्टिव जोड़ना पड़ सकता है. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ नाम.
टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: जानकारी देखें

'टेस्ट' और 'रन' निर्देशों के लिए, एक्सीक्यूटेबल के पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और प्रोग्राम चलाने के लिए इस्तेमाल की जाने वाली कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी ऐसे टारगेट का लेबल भी हो सकता है जिसे चलाया जा सकता है. कुछ उदाहरण: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

--[no]share_native_deps डिफ़ॉल्ट: "सही"

अगर यह सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के बीच शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "गलत"

तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल स्टोर करने की जगह की जानकारी वगैरह के साथ बाइनरी को स्टैंप करें.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि --compilation_mode=fastbuild के लिए, स्ट्रिप करें.
टैग: affects_outputs

--stripopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप करने के लिए पास किए जाने वाले अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--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 डिफ़ॉल्ट: "गलत"

देखें कि डिपेंडेंट पैकेज से लगाई गई लाइसेंस की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics

--[no]check_visibility डिफ़ॉल्ट: "सही"

अगर इसे बंद किया जाता है, तो टारगेट डिपेंडेंसी में दिखने से जुड़ी गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics

--[no]desugar_for_android डिफ़ॉल्ट: "सही"

डेक्स करने से पहले, Java 8 के बाइटकोड को डीसुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "गलत"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints डिफ़ॉल्ट: "सही"

यह जांच करता है कि हर टारगेट किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट में ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की रिपोर्ट करता है
टैग: build_file_semantics

--[no]experimental_check_desugar_deps डिफ़ॉल्ट: "सही"

Android बाइनरी लेवल पर, सही तरीके से डी-शुगर करने की दोबारा जांच करनी है या नहीं.
टैग: eagerness_to_exit, loading_and_analysis, experimental

--experimental_import_deps_checking=<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"

अगर यह सही है, तो यह जांच की जाती है कि कोई Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो आउटपुट फ़ाइलों के तौर पर काम करने वाले टारगेट के लिए, सिर्फ़ टेस्ट करने की सुविधा देखें. इसके लिए, जनरेट करने वाले नियम के लिए सिर्फ़ टेस्ट करने की सुविधा देखें. यह, 'डिवाइस किसे दिखे' सेटिंग की जांच से मेल खाता है.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_check_visibility_for_toolchains डिफ़ॉल्ट: "गलत"

अगर यह सेटिंग चालू है, तो टूलचेन लागू करने पर भी, डिवाइस के दिखने की जांच की जाएगी.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो नेटिव Android नियमों का सीधे तौर पर इस्तेमाल बंद हो जाता है. कृपया https://github.com/bazelbuild/rules_android पर मौजूद, Starlark Android नियमों का इस्तेमाल करें
टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "गलत"

काम नहीं करता. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.
टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_python_disable_py2 डिफ़ॉल्ट: "सही"

अगर यह 'सही' पर सेट है, तो Python 2 की सेटिंग का इस्तेमाल करने पर गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2ONLY शामिल हैं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]one_version_enforcement_on_java_tests डिफ़ॉल्ट: "सही"

अगर यह सुविधा चालू है और 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 डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइल सेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच की जाती है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद"

जब तक यह विकल्प बंद नहीं होता, तब तक यह जांच की जाती है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर एक्सपोर्ट के तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--[no]strict_system_includes डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो सिस्टम में शामिल पाथ (-isystem) से मिले हेडर की जानकारी भी देनी होगी.
टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर एनवायरमेंट तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

ऐसे विकल्प जिनसे किसी बिल्ड के हस्ताक्षर करने के आउटपुट पर असर पड़ता है:

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2"

APKs पर साइन करने के लिए इस्तेमाल करने का तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements डिफ़ॉल्ट: "सही"

अगर यह सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: जानकारी देखें

iOS साइनिंग के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक, यह सर्टिफ़िकेट की पासकोड की पहचान की प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम का (सबस्ट्रिंग) हो सकता है.
टैग: action_command_lines

इस विकल्प का असर, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर पड़ता है.:

--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही"

काम नहीं करता. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "गलत"

अगर इसकी वैल्यू 'सही' है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट इस्तेमाल करने की अनुमति नहीं दें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को 'सही' पर सेट करें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो पहले से मौजूद py_* नियमों का इस्तेमाल करते समय गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के AnalysisFailureInfo के इंस्टेंस का प्रॉपेगेशन होता है. इसमें गड़बड़ी की जानकारी होती है. इससे बिल्ड पूरा न होने की स्थिति नहीं होती.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा डेटा डालने पर, नियम से जुड़ी गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental

--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 डिफ़ॉल्ट: "गलत"

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "गलत"

ios_test टारगेट में, मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है, जैसे कि 'iPhone 6'. डिवाइसों की सूची पाने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला iOS वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह हर टेस्ट को कितनी बार चलाने के लिए तय करता है. अगर इनमें से किसी भी कोशिश में किसी वजह से सफलता नहीं मिलती है, तो पूरे टेस्ट को असफल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test, पूर्णांक वैल्यू के लिए है और regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैरिएबल की वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.
टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1"

टेस्ट टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर चार पूर्णांकों को कॉमा लगाकर अलग-अलग किया गया है, तो वे कम, सामान्य, ज़्यादा, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों ही फ़ॉर्म में, -1 की वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहा जाता है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो बिना एलान किए किए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "गलत"

LibraryJar में मौजूद सभी क्लास हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलें, डिस्क में लिखे जाने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में भेजी जाएंगी.
टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलें, डिस्क पर लिखे जाने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में भेजी जाएंगी.
टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly डिफ़ॉल्ट: "गलत"

चालू होने पर, --trim_test_configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, cc_test नियमों पर निर्भर न करने वाले नियमों के लिए, कार्रवाई से जुड़ी समस्याओं को कम करना है. अगर --trim_test_configuration को 'गलत है' पर सेट किया जाता है, तो इसका कोई असर नहीं पड़ता.
टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_starlark_cc_import डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "गलत"

इनपुट फ़ाइलों से #include लाइनों को पार्स करके, इनपुट को C/C++ कंपाइलेशन तक सीमित करना है या नहीं. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम हो जाता है. इससे परफ़ॉर्मेंस और इंक्रीमेंटलिटी बेहतर हो सकती है. हालांकि, इससे बिल्ड भी खराब हो सकते हैं, क्योंकि शामिल करने वाला स्कैनर, C प्रीप्रोसेसिंग सेमेंटेक्स को पूरी तरह से लागू नहीं करता. खास तौर पर, यह डाइनैमिक #include निर्देशों को समझ नहीं पाता और प्रीप्रोसेसर के कंडीशनल लॉजिक को अनदेखा कर देता है. अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी सभी समस्याओं को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing डिफ़ॉल्ट: "सही"

यह हर Jar फ़ाइल के लिए, इंडेक्स करने का ज़्यादातर काम अलग से करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो clang से जनरेट की गई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग की सुविधा चालू हो.
टैग: execution

--[no]trim_test_configuration डिफ़ॉल्ट: "सही"

इस विकल्प को चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के सबसे ऊपरी लेवल के नीचे से हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को बिना टेस्ट वाले नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने पर, बिना टेस्ट वाले नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान, डीबग की जानकारी प्रिंट करें. इस फ़्लैग में रेगुलर एक्सप्रेशन का इस्तेमाल किया जाता है. इस एक्सप्रेशन की जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता लगाया जा सके कि किस टूल को डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. ऐसा हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए ही काम का हो.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत"

यह फ़्लैग, डिफ़ॉल्ट तरीके को बदल देता है, ताकि Python टारगेट के रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बनें. खास तौर पर, जब py_binary या py_test टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिंबललिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, `--incompatible_py3_is_default` को भी चालू करने का सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से PY3 का इस्तेमाल किया जाएगा, न कि PY2 का. अगर यह फ़्लैग सेट किया जाता है, तो हमारा सुझाव है कि आप `--incompatible_py2_outputs_are_suffixed` को भी सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के नेटिव नियमों को लागू करने के लिए, --python_top जैसे लेगसी फ़्लैग के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल किया जाएगा.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

Python के मुख्य वर्शन का मोड, या तो `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट बदल देते हैं. भले ही, वे साफ़ तौर पर किसी वर्शन की जानकारी न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "auto"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो Bazel किसी टेस्ट को फिर से सिर्फ़ तब चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट चलाने का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. 'हां' पर सेट होने पर, Bazel बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजों को कैश मेमोरी में सेव नहीं करता.

--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Blaze पहले सफल रन पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ काम आता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो कवरेज की जांच के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा की पूरी डायरेक्ट्री फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो clang के लिए कवरेज से LCOV रिपोर्ट जनरेट होगी.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_j2objc_header_map डिफ़ॉल्ट: "सही"

J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.
टैग: experimental

--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "गलत"

क्या छोटे हेडर पाथ के साथ जनरेट करना है ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग: affects_outputs, experimental

--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javabuilder"

Java कंपाइलेशन के लिए, कम क्लासपाथ की सुविधा चालू करता है.

--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत"

काम नहीं करता, इसे सिर्फ़ पुराने वर्शन के साथ काम करने के लिए रखा गया है
टैग: affects_outputs, experimental

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs, experimental

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java लॉन्चर, उन टूल का इस्तेमाल करता है जो बिल्ड के दौरान चलाए जाते हैं.

--host_javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, javac को पास करने के लिए अन्य विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर यह 'सही' है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने पर, शेयर किए गए कैश मेमोरी का इस्तेमाल होने पर, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी सेव नहीं की जा सकती.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

J2ObjC टूल को पास करने के लिए अन्य विकल्प.

--java_debug

इसकी वजह से, किसी Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे, jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इस तरह बड़ा होता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps डिफ़ॉल्ट: "सही"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (फ़िलहाल, कंपाइल के समय क्लासपाथ) जनरेट करें.

--[no]java_header_compilation डिफ़ॉल्ट: "सही"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis

--[no]proto_profile डिफ़ॉल्ट: "सही"

क्या प्रोटो कंपाइलर को profile_path पास करना है.
टैग: affects_outputs, loading_and_analysis

--proto_profile_path=<a build target label> डिफ़ॉल्ट: जानकारी देखें

प्रोटो कंपाइलर को profile_path के तौर पर पास की जाने वाली प्रोफ़ाइल. अगर यह सेट नहीं है, लेकिन --proto_profile सही (डिफ़ॉल्ट) है, तो --fdo_optimize से पाथ का अनुमान लगाया जाता है.
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain"

proto_lang_toolchain() का लेबल, जो C++ प्रोटो कोड को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जो Java प्रोटो कोड को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जो JavaLite प्रोटो को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

protobuf कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो जिस शर्ड में कम से कम एक रन/अटैंप पास होता है और कम से कम एक रन/अटैंप फ़ेल होता है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: जानकारी देखें

Bazel के इस्तेमाल के लिए, शेल की एक्ज़ीक्यूटेबल फ़ाइल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन Bazel को पहली बार इस्तेमाल करने पर BAZEL_SH एनवायरमेंट वैरिएबल सेट है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel काम करता है. जैसे, Windows: c:/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने पर, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में गड़बड़ियां हो सकती हैं.
टैग: loading_and_analysis

--test_arg=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इससे उन अतिरिक्त विकल्पों और आर्ग्युमेंट की जानकारी मिलती है जिन्हें टेस्ट के लिए इस्तेमाल किए जाने वाले प्रोग्राम को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, कई बार इस्तेमाल किया जा सकता है. अगर एक से ज़्यादा टेस्ट चलाए जाते हैं, तो उनमें से हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.

--test_filter=<a string> डिफ़ॉल्ट: जानकारी देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, चलाए जाने वाले टेस्ट की संख्या को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे यह तय नहीं होता कि कौनसे टारगेट बनाए जाएं.

--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1"

इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत"

टेस्ट रनर को फ़ेल फ़ास्ट विकल्प फ़ॉरवर्ड करता है. टेस्ट रनर को पहली बार फ़ेल होने पर, टेस्ट को रोक देना चाहिए.

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "explicit"

टेस्ट के लिए, शार्डिंग की रणनीति तय करें: 'explicit', ताकि सिर्फ़ तब शार्डिंग का इस्तेमाल किया जा सके, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'बंद है', ताकि टेस्ट के लिए डेटा को अलग-अलग हिस्सों में बांटने की सुविधा का कभी भी इस्तेमाल न किया जाए. 'forced=k': इस विकल्प का इस्तेमाल करके, टेस्टिंग के लिए 'k' शर्ड लागू किए जा सकते हैं. भले ही, 'shard_count' बिल्ड एट्रिब्यूट की वैल्यू कुछ भी हो.

--tool_java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वह वर्शन जिसका इस्तेमाल, बिल्ड के दौरान ज़रूरी टूल चलाने के लिए किया जाता है

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन इंटरफ़ेस के लिए jar का इस्तेमाल करता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.