BaselCon 2024 का रजिस्ट्रेशन अब शुरू हो गया है!

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

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

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

या

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

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

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

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

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

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

-<short_form> <value>

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

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

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

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

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

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

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

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

निर्देश

`analyze-profile`	बिल्ड प्रोफ़ाइल के डेटा का विश्लेषण करता है.
`aquery`	दिए गए टारगेट का विश्लेषण करता है और ऐक्शन ग्राफ़ की क्वेरी करता है.
`build`	तय किए गए टारगेट बनाता है.
`canonicalize-flags`	bazel के विकल्पों की सूची को कैननिकल बनाता है.
`clean`	आउटपुट फ़ाइलों को हटाता है और सर्वर को बंद कर देता है.
`coverage`	तय किए गए टेस्ट टारगेट के लिए, कोड कवरेज रिपोर्ट जनरेट करता है.
`cquery`	कॉन्फ़िगरेशन का इस्तेमाल करके, तय किए गए टारगेट को लोड करता है, उनका विश्लेषण करता है, और उनके बारे में क्वेरी करता है.
`dump`	bazel सर्वर प्रोसेस की इंटरनल स्टेटस को डंप करता है.
`fetch`	ऐसे बाहरी डेटा स्टोर करने की जगह फ़ेच करता है जो टारगेट के लिए ज़रूरी हैं.
`help`	निर्देशों या इंडेक्स के लिए मदद प्रिंट करता है.
`info`	bazel सर्वर के बारे में रनटाइम की जानकारी दिखाता है.
`license`	इस सॉफ़्टवेयर का लाइसेंस प्रिंट करता है.
`mobile-install`	मोबाइल डिवाइसों पर टारगेट इंस्टॉल करता है.
`mod`	Bzlmod बाहरी डिपेंडेंसी ग्राफ़ की क्वेरी करता है
`print_action`	किसी फ़ाइल को कंपाइल करने के लिए, कमांड लाइन आर्ग्युमेंट को प्रिंट करता है.
`query`	डिपेंडेंसी ग्राफ़ की क्वेरी को लागू करता है.
`run`	तय किए गए टारगेट को चलाता है.
`shutdown`	bazel सर्वर को बंद कर देता है.
`sync`	वर्कस्पेस फ़ाइल में दिए गए सभी डेटा स्टोर करने की जगह को सिंक करता है
`test`	तय किए गए टेस्ट टारगेट बनाता है और उन्हें चलाता है.
`vendor`	बाहरी डेटा स्टोर करने की जगहों को फ़्लैग --vendor_ कौशल के ज़रिए बताए गए फ़ोल्डर में ले जाता है.
`version`	bazel के वर्शन की जानकारी प्रिंट करता है.

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

--[no]autodetect_server_javabase डिफ़ॉल्ट: "सही": जब --noautodetect_server_javabase पास होता है, तो Basel सर्वर को चलाने के लिए लोकल JDK पर वापस नहीं आता है और इसके बजाय बाहर निकल जाता है.
टैग: affects_outputs, loses_incremental_state
--[no]batch डिफ़ॉल्ट: "गलत": अगर यह सेट किया जाता है, तो Bazel को स्टैंडर्ड क्लाइंट/सर्वर मोड के बजाय, सिर्फ़ क्लाइंट प्रोसेस के तौर पर चलाया जाएगा. यह सुविधा अब काम नहीं करती और इसे हटा दिया जाएगा. अगर आपको सर्वर को बंद करना है, तो कृपया साफ़ तौर पर सर्वर को बंद करें.
टैग: loses_incremental_state, bazel_internal_configuration, deprecated
--[no]batch_cpu_scheduling डिफ़ॉल्ट: "गलत": सिर्फ़ Linux पर; Blaze के लिए, सीपीयू शेड्यूलिंग के 'बैच' मोड का इस्तेमाल करें. यह नीति उन वर्कलोड के लिए काम की है जो इंटरैक्टिव नहीं हैं, लेकिन जिनकी नीस वैल्यू कम नहीं करनी है. देखें 'पुरुष 2 sched_setScheduler'. अगर यह 'गलत है' पर सेट है, तो Bazel कोई सिस्टम कॉल नहीं करता.
टैग: host_machine_resource_optimizations
--bazelrc=<path> डिफ़ॉल्ट: ब्यौरा देखें: उपयोगकर्ता की .bazelrc फ़ाइल की जगह, जिसमें Bazel के विकल्पों की डिफ़ॉल्ट वैल्यू होती हैं. /dev/null से यह पता चलता है कि आगे आने वाले सभी `--bagelrc`s को अनदेखा किया जाएगा.इससे उपयोगकर्ता की आरसी फ़ाइल को खोजने की सुविधा बंद हो जाती है. जैसे, रिलीज़ बिल्ड में. इस विकल्प को कई बार भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, `--bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc` के साथ, 1) x.rc और y.rc पढ़े जाते हैं. 2) पहले से मौजूद /dev/null की वजह से, z.rc को अनदेखा कर दिया जाता है. अगर इसके बारे में जानकारी नहीं दी जाती है, तो Basel की ओर से मिलने वाली पहली .baकोई फ़ाइल को इन दो जगहों पर इस्तेमाल किया जाता है: फ़ाइल फ़ोल्डर की डायरेक्ट्री और फिर उपयोगकर्ता की होम डायरेक्ट्री. ध्यान दें: कमांड लाइन विकल्प हमेशा baज़ेनrc में किसी भी विकल्प की जगह ले लेंगे.
टैग: 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/ba टैग है और cpu और मेमोरी कंट्रोलर, /sys/fs/cgroup/cpu और /sys/fs/cgroup/memory पर माउंट किए जाते हैं, तो सर्वर को cgroups /sys/fs/cgroup/cpu/build/baकोई और /sys/fs/build/ba सुझावों में एक के लिए मान लें, इस विकल्प का उन प्लैटफ़ॉर्म पर कोई असर नहीं पड़ता जो 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 सबसे कम. हो सकता है कि शेड्यूल करने वाला वह प्रोग्राम, सिर्फ़ चौथी प्राथमिकता तक का हो. अगर नेगेटिव वैल्यू पर सेट किया जाता है, तो Basel सिस्टम कॉल नहीं करता है.
टैग: 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 डिफ़ॉल्ट: "सही": पूरे सिस्टम पर अलग-अलग सेटिंग देखें.
टैग: 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 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: 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

--[no]check_bzl_visibility डिफ़ॉल्ट: "सही": अगर इसे बंद किया जाता है, तो .bzl लोड होने से जुड़ी गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics

--[no]enable_bzlmod डिफ़ॉल्ट: "सही": अगर यह 'सही' पर सेट है, तो Bzlmod डिपेंडेंसी मैनेजमेंट सिस्टम चालू हो जाता है. यह WORKSPACE के मुकाबले प्राथमिकता पाता है. ज़्यादा जानकारी के लिए, https://bazel.build/docs/bzlmod देखें.
टैग: loading_and_analysis
--[no]enable_workspace डिफ़ॉल्ट: "गलत": अगर सही है, तो बाहरी डिपेंडेंसी के लिए लेगसी Workspace सिस्टम को चालू करता है. ज़्यादा जानकारी के लिए, https://bazel.build/external/overview देखें.
टैग: loading_and_analysis
--[no]experimental_action_resource_set डिफ़ॉल्ट: "सही": अगर इसे 'सही है' पर सेट किया जाता है, तो ctx.action.run() और ctx.action.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_scl_dialect डिफ़ॉल्ट: "सही": अगर इसे 'सही है' पर सेट किया जाता है, तो load() स्टेटमेंट में .scl फ़ाइलों का इस्तेमाल किया जा सकता है.
टैग: build_file_semantics
--[no]experimental_google_legacy_api डिफ़ॉल्ट: "गलत": अगर इसे 'सही' पर सेट किया जाता है, तो Google के लेगसी कोड से जुड़े Starlark बिल्ड एपीआई के कई एक्सपेरिमेंटल हिस्से दिखते हैं.
टैग: loading_and_analysis, experimental
--[no]experimental_isolated_extension_usages डिफ़ॉल्ट: "गलत": अगर यह सही है, तो <a href="https://bazel.build/rules/lib/globals/module#use_extension"><code>use_extension</code></a> फ़ंक्शन में<code>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 डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तो रिपॉज़िटरी_नियम को रिमोट तौर पर लागू करने की कुछ सुविधाएं मिल जाती हैं.
टैग: 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,+@rules_java,+@protobuf,@rules_shell,+@rules_android": कॉमा लगाकर अलग किए गए नियमों (या अन्य सिंबल) की सूची, जो पहले Bazel का हिस्सा थे और जिन्हें अब उनके बाहरी रिपॉज़िटरी से वापस पाना है. इस फ़्लैग का इस्तेमाल, Bazel से नियमों को माइग्रेट करने के लिए किया जाता है. https://github.com/bagelbuild/ba सुझावों/issues/23043 पर जाएं. किसी फ़ाइल में अपने-आप लोड होने वाला सिंबल, ऐसा व्यवहार करता है जैसे कि Bazel में पहले से मौजूद उसकी परिभाषा को, बाहरी रिपॉज़िटरी में मौजूद उसकी कैननिकल नई परिभाषा से बदल दिया गया हो. BUILD फ़ाइल के लिए इसका मतलब है कि सीधे तौर पर एक load() स्टेटमेंट जोड़ा जा रहा है. .bzl फ़ाइल के लिए, यह load() स्टेटमेंट या `native` ऑब्जेक्ट के फ़ील्ड में बदलाव होता है. यह इस बात पर निर्भर करता है कि अपने-आप लोड होने वाला सिंबल कोई नियम है या नहीं. Bazel, उन सभी सिंबल की हार्डकोड की गई सूची रखता है जिन्हें अपने-आप लोड किया जा सकता है. इस फ़्लैग में सिर्फ़ वे सिंबल दिख सकते हैं. हर सिंबल के लिए, Basel को एक्सटर्नल रिपॉज़िटरी (डेटा स्टोर करने की जगह) में नई जगह के बारे में पता है. साथ ही, खास-केस वाले डेटा स्टोर करने की जगहों के एक सेट के बारे में भी पता है, जिसे साइकल बनाने से बचने के लिए, अपने-आप लोड नहीं होना चाहिए. इस फ़्लैग में "+foo" की सूची के आइटम की वजह से, सिंबल foo अपने-आप लोड हो जाता है. हालांकि, foo की उन रिपॉज़िटरी में ऐसा नहीं होता जिनमें Bazel से तय किया गया foo का वर्शन अब भी उपलब्ध है. "foo" का कोई सूची आइटम, ऊपर बताए गए तरीके से अपने-आप लोड होने की सुविधा को ट्रिगर करता है. हालांकि, Bazel के तय किए गए foo के वर्शन को, बाहर रखे गए रिपॉज़िटरी के लिए उपलब्ध नहीं कराया जाता. इससे यह पक्का हो जाता है कि foo का बाहरी डेटा स्टोर करने की जगह, foo के पुराने Baze को लागू करने के तरीके पर निर्भर नहीं है "-foo" का एक सूची आइटम अपने-आप लोड होने की सुविधा को ट्रिगर नहीं करता है. हालांकि, इसकी वजह से foo के तय किए गए वर्शन को पूरे फ़ाइल फ़ोल्डर में ऐक्सेस नहीं किया जा सकता. इसका इस्तेमाल यह पुष्टि करने के लिए किया जाता है कि वर्कस्पेस, Bazel से foo की परिभाषा को मिटाने के लिए तैयार है या नहीं. अगर इस फ़्लैग में किसी चिह्न का नाम नहीं दिया गया है, तो यह सामान्य तरीके से काम करता रहता है -- न तो अपने-आप लोड होने की प्रोसेस पूरी होती है और न ही बेज़ल से तय किए गए वर्शन को दबाया जाता है. कॉन्फ़िगरेशन के लिए, 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 डिफ़ॉल्ट: "सही": सही होने पर, Basel, 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.action.run या ctx.action.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" का इस्तेमाल किया जा सकता है. इस फ़्लैग के लिए यह ज़रूरी है कि --inaffiliate_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 डिफ़ॉल्ट: "सही": यह सुविधा चालू होने पर, तय की गई 'env' और 'use_default_shell_env = True', दोनों के साथ ctx.action.run और ctx.action.run_shell की कार्रवाइयों. इसके लिए, डिफ़ॉल्ट शेल एनवायरमेंट से मिले एनवायरमेंट का इस्तेमाल किया जाएगा. इसके लिए, 'env' में पास की गई वैल्यू को बदलना होगा. अगर यह बंद है, तो इस मामले में 'env' की वैल्यू को पूरी तरह से अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_no_attr_license डिफ़ॉल्ट: "सही": अगर इसे 'सही है' पर सेट किया जाता है, तो `attr.लाइसेंस` फ़ंक्शन बंद होता है.
टैग: 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 के लिए Library_to_link के बजाय linker_inputs को बनाया जाएगा. लिंकिंग_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/batzbuild/ba बहुत/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

--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/batzbuild/ba बहुत/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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Bazel को पता चलता है कि रिटेंन की गई हेप का प्रतिशत, --skyframe_high_water_mark_threshold सेट की गई सीमा से ज़्यादा है, तो मामूली GC इवेंट होने पर, वह हर बार इस सीमा तक अनावश्य Skyframe स्टेटस को छोड़ देगा. डिफ़ॉल्ट रूप से, यह वैल्यू 10 होती है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, मामूली जीसी इवेंट होने पर Skyframe की स्थिति को ड्रॉप नहीं किया जाएगा. साथ ही, रीटेन किए गए हेप के प्रतिशत के थ्रेशोल्ड को पार करने पर भी ऐसा नहीं किया जाएगा.
टैग: host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85": Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Basel को लगता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड पर है, तो यह बिना किसी वजह के सेट किए गए स्काईफ़्रेम स्टेटस को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (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] फ़ॉर्मैट में, बिल्ड इवेंट सेवा (बीईएस) के बैकएंड एंडपॉइंट की जानकारी देता है. यह डिफ़ॉल्ट तौर पर, बीईएस डेटा अपलोड करने की सुविधा को बंद करता है. इन स्कीम का इस्तेमाल किया जा सकता है: 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> डिफ़ॉल्ट: "": इससे उस बेस यूआरएल के बारे में पता चलता है जहां उपयोगकर्ता, बीईएस बैकएंड पर स्ट्रीम की गई जानकारी देख सकता है. 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": यह नीति तय करती है कि बिल्ड और टेस्ट पूरे होने के बाद, 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' या 'full_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_फ़ाइलें_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 पर जाकर प्रोफ़ाइल देखें. डिफ़ॉल्ट रूप से, Bagel सभी बिल्ड-जैसे निर्देशों और क्वेरी के लिए प्रोफ़ाइल लिखता है.
टैग: 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 सेकंड के पॉज़ के साथ 2 जीसी. इसके बाद, शून्य सेकंड के पॉज़ के साथ चार जीसी
टैग: 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

--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 को बार-बार कॉल नहीं करता. वैल्यू, रीयल TTL से कुछ कम सेट होनी चाहिए, क्योंकि सर्वर की तरफ़ से डाइजेस्ट वापस मिलने और बेज़ल को मिलने के समय के बीच एक अंतर है.
टैग: 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 डिफ़ॉल्ट: "गलत": अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Baze, इनपुट को रिमोट एक्ज़िक्यूटर के लिए, टूल इनपुट के तौर पर मार्क कर देगा. इसका इस्तेमाल, रिमोट पर लगातार काम करने वाले वर्कर लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache डिफ़ॉल्ट: "गलत": अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेर्कल ट्री कैलकुलेशन को मेमोइज़ किया जाएगा. कैश मेमोरी का फ़ुटप्रिंट, --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer> डिफ़ॉल्ट: "1000": रिमोट कैश हिट चेकिंग स्पीड को बेहतर बनाने के लिए, Merकल ट्री की संख्या को याद रखना चाहिए. हालांकि, 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> डिफ़ॉल्ट: "ऑटो": रिपॉज़िटरी फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. अगर इसे 'बंद' पर सेट किया जाता है, तो किसी भी वर्क थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रिपॉज़िटरी को फ़ेच करने के लिए, रीस्टार्ट की ज़रूरत पड़ सकती है. ऐसा न होने पर, वर्चुअल वर्कर्स थ्रेड का इस्तेमाल किया जाता है.
--[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> डिफ़ॉल्ट: "स्थानीय": अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.
--remote_max_connections=<an integer> डिफ़ॉल्ट: "100": रिमोट कैश मेमोरी/एग्ज़ीक्यूटर पर एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, यह तय करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Baze एक साथ कई अनुरोध कर सकता है. यह एक साथ कई अनुरोध करने के लिए, --remote_max_ connections तक की प्रोसेस को पूरा कर सकता है. gRPC रिमोट कैश/एक्ज़िकेटर के लिए, एक gRPC चैनल आम तौर पर 100 से ज़्यादा एक साथ किए जाने वाले अनुरोधों को हैंडल कर सकता है. इसलिए, Basel को `--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/config कार्रवाई-baazs- वाई-फ़ाई-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 डिफ़ॉल्ट: "गलत": अगर सही का विकल्प चुना जाता है, तो Baze, होस्ट-ओएस के लिए खास तौर पर कॉन्फ़िगर की गई कॉन्फ़िगरेशन लाइनों को baezrc फ़ाइलों से चुनता है. उदाहरण के लिए, अगर होस्ट ओएस, Linux है और आपके पास बैजल बिल्ड है, तो Baज़र, 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
--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 डिफ़ॉल्ट: "गलत": टर्मिनल के टाइटल में, निर्देश की प्रोग्रेस दिखाएं. यह देखने के लिए उपयोगी है कि एकाधिक टर्मिनल टैब होने पर बेज़ल क्या कर रहा है.
--[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 पर: अगर सही है, तो बैज हर फ़ाइल को स्कैन करने के बजाय ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करके, सिस्टम में होने वाले बदलावों को समझने की कोशिश करता है. Windows पर: फ़िलहाल, यह फ़्लैग काम नहीं करता. हालांकि, इसे --experimental_windows_watchfs के साथ चालू किया जा सकता है. किसी भी ओएस पर: अगर आपका फ़ाइल फ़ोल्डर, नेटवर्क फ़ाइल सिस्टम पर है और फ़ाइलों में किसी रिमोट मशीन से बदलाव किया जाता है, तो फ़ाइलों के सिंक होने का तरीका तय नहीं होता.

Analyze-profile के विकल्प

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं की जाती.
टैग: loading_and_analysis

--dump=<text or raw> [-d] डिफ़ॉल्ट: ब्यौरा देखें: पूरी प्रोफ़ाइल का डेटा डंप, इंसान के पढ़ने लायक 'टेक्स्ट' फ़ॉर्मैट या स्क्रिप्ट के हिसाब से 'रॉ' फ़ॉर्मैट में आउटपुट करता है.
टैग: bazel_monitoring

Aquery के विकल्प

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंजर्वेटिव": अगर आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने की ज़रूरत होती है. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. इस बात पर भी ध्यान दें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. हालांकि, 'बेज़ल क्वेरी' के दौरान यह फ़ैसला नहीं लिया जाता.
टैग: build_file_semantics
--[no]consistent_labels डिफ़ॉल्ट: "गलत": अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को ऐसे दिखाता है जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन लागू किया गया हो. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट को ज़्यादा आसानी से पढ़ने लायक बनाने के लिए, आउटपुट फ़ॉर्मैटर, मुख्य रिपॉज़िटरी के हिसाब से, रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output
--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत": aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: कोई कार्रवाई नहीं (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output
--[no]graph:factored डिफ़ॉल्ट: "सही": अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output
--graph:node_limit=<an integer> डिफ़ॉल्ट: "512": आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की अधिकतम लंबाई. लंबे लेबल काट दिए जाएंगे; -1 का मतलब है कि लेबल काटा नहीं जाएगा. यह विकल्प केवल --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output
--[no]implicit_deps डिफ़ॉल्ट: "सही": अगर यह विकल्प चालू है, तो डिपेंडेंसी ग्राफ़ में उन डिपेंडेंसी को शामिल किया जाएगा जिन पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_artifacts डिफ़ॉल्ट: "सही": आउटपुट में कार्रवाई के इनपुट और आउटपुट के नाम शामिल होते हैं. ये नाम बड़े हो सकते हैं.
टैग: terminal_output
--[no]include_aspects डिफ़ॉल्ट: "सही": 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://bagel.build/reference/query#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है, न कि `cquery` पर.
टैग: loading_and_analysis
--[no]line_terminator_null डिफ़ॉल्ट: "गलत": क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाता है.
टैग: terminal_output
--[no]nodep_deps डिफ़ॉल्ट: "सही": चालू होने पर, "nodep" एट्रिब्यूट के deps को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा, जिस पर क्वेरी काम करती है. "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 डिफ़ॉल्ट: "सही": अगर सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू, बिल्ड फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --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 डिफ़ॉल्ट: "सही": Terms_input औरRule_ ठहरने के फ़ील्ड को भरना है या नहीं.
टैग: 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' को हटा देता है. 'Genroll=+requires-x', सभी जेनरल कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में 'ज़रूरी-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 के हर ऐक्शन के लिए "ज़रूरी-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 डिफ़ॉल्ट: "गलत": अगर इसे चालू किया जाता है, तो exec कॉन्फ़िगरेशन में "bagel test --run_under=//:Chromebook" को बिल्ड करके "//:Run" बनाया जा सकता है. बंद होने पर, यह टारगेट कॉन्फ़िगरेशन में "//:runner" बनाता है. Bazel, टेस्ट को exec मशीनों पर चलाता है. इसलिए, पहला तरीका ज़्यादा सही है. इससे "bazel run" पर कोई असर नहीं पड़ता, जो हमेशा टारगेट कॉन्फ़िगरेशन में "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही": अगर सही है, तो Basel, c++ टूलचेन में 'host' और 'nonhost' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/ba इमारतोंbuild/ba इमारतों/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 डिफ़ॉल्ट: "सही": अगर टूलचेन के साथ काम करता है, तो इंटरफ़ेस के साथ शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, ईएलएफ़ टूलचेन में यह सेटिंग काम करती है.
टैग: 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> डिफ़ॉल्ट: जानकारी देखें: टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python अनुवादक को दिखाने वाले py_runtime का लेबल. अब काम नहीं करता; --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 वर्शन चुनने के लिए, इस्तेमाल किया जाने वाला xcode_config नियम का लेबल.
टैग: 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 एपीआई वर्शन के लिए ज़्यादा कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत": कंपाइलेशन के आउटपुट के तौर पर, चालू और अनुरोध की गई सुविधाओं की स्थिति को सेव करें.
टैग: affects_outputs, experimental
--fission=<a set of compilation modes> डिफ़ॉल्ट: "नहीं": यह बताता है कि C++ कंपाइलेशन और लिंक के लिए, कौनसे कंपाइलेशन मोड फ़िज़न का इस्तेमाल करते हैं. सभी मोड को चालू करने के लिए {'Fastbuild', 'dbg', 'opt'} या विशेष वैल्यू 'yes' का कोई भी कॉम्बिनेशन हो सकता है और सभी मोड को बंद करने के लिए 'no' का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs
--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही": अगर यह सही है, तो नेटिव नियम अपने रनफ़ाइल में डेटा डिपेंडेंसी की <code>DefaultInfo.files</code> जोड़ते हैं. यह Starlark नियमों के लिए सुझाए गए व्यवहार से मेल खाता है (https://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change
--[no]legacy_external_runfiles डिफ़ॉल्ट: "गलत": अगर सही है, तो .runfile/wsname/external/repo (.runfiles/repo के अलावा) के अलावा, बाहरी डेटा स्टोर करने की जगहों के लिए रनफ़ाइल सिमलिंक करें.
टैग: affects_outputs
--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत": यह बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs
--[no]save_temps डिफ़ॉल्ट: "गलत": अगर यह सेट है, तो gcc से मिलने वाले अस्थायी आउटपुट सेव हो जाएंगे. इनमें .s फ़ाइलें (असेम्बलर कोड), .i फ़ाइलें (प्रीप्रोसेस की गई C) और .ii फ़ाइलें (प्रीप्रोसेस की गई C++) शामिल हैं.
टैग: affects_outputs

--action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर: टारगेट कॉन्फ़िगरेशन वाले ऐक्शन के लिए उपलब्ध, एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. यह पेयर, कॉल करने के एनवायरमेंट से अलग वैल्यू सेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines
--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> डिफ़ॉल्ट: जानकारी देखें: कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंट की बाइनरी जनरेट करना. 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 APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: 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 डिफ़ॉल्ट: "गलत": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. सटीक स्कीम प्रयोग के तौर पर शुरू की गई है और इसमें बदलाव हो सकते हैं: पहला, बहुत ही कम मामलों में --प्लैटफ़ॉर्म विकल्प में सिर्फ़ एक वैल्यू नहीं होती, इसलिए प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --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 लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन के हिसाब से एक्ज़ीक्यूटेबल एक्ज़ीक्यूटेबल ("-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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: एक्ज़िक कॉन्फ़िगरेशन में 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: एक्ज़िक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, 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 डिफ़ॉल्ट: "सही": अब काम नहीं करता, --inबेमेल_remove_legacy_whole_archive (ज़्यादा जानकारी के लिए, https://github.com/ba इमारतोंbuild/baze/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_ऑप्टिमाइज़/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा इस तरह लागू होंगे जैसे कि xbinary_fdo की जानकारी कभी न दी गई हो.
टैग: affects_outputs

--[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/bazibuild/ba बहुत/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> डिफ़ॉल्ट: जानकारी देखें: लागू करने के दौरान, अनुमति वाली सूची (पैकेज_ग्रुप टारगेट) का इस्तेमाल करें --inबेमेल_python_disallow_native_rules.
टैग: 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 डिफ़ॉल्ट: "सही": अगर नीति को सेट किया जाता है और कंपाइलेशन मोड 'ऑप्ट-आउट' नहीं किया जाता, तो साइन इन करते समय ऑब्जेसी ऐप्लिकेशन, डीबग एनटाइटलमेंट को शामिल करेंगे.
टैग: changes_inputs
--ios_signing_cert_name=<a string> डिफ़ॉल्ट: जानकारी देखें: iOS साइनिंग के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक, यह सर्टिफ़िकेट की पासकोड की पहचान की प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम का (सबस्ट्रिंग) हो सकता है.
टैग: action_command_lines

--[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 में हमेशा लिंक एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही बनाएं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत": अगर यह सही है, तो पहले से मौजूद py_* नियमों का इस्तेमाल करते समय गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और डेटा को दूसरी जगह भेजने से जुड़े निर्देशों के लिए, https://github.com/batzbuild/ba बहुत/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> (उदाहरण के लिए, space=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 की वैल्यू से ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने का निर्देश मिलता है.
--[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 डिफ़ॉल्ट: "सही": अगर यह नीति सेट की जाती है, तो क्लैंग की मदद से बनाई गई .d फ़ाइलों का इस्तेमाल, objc कंपाइलों में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत": टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग: execution
--[no]trim_test_configuration डिफ़ॉल्ट: "सही": चालू होने पर, बिल्ड के टॉप लेवल के नीचे जांच से जुड़े विकल्प मिटा दिए जाएंगे. अगर यह फ़्लैग चालू है, तो टेस्ट को नॉन-टेस्ट नियमों के आधार पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state

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

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर: 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] डिफ़ॉल्ट: "ऑटो": अगर इसे 'अपने-आप' पर सेट किया जाता है, तो 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 डिफ़ॉल्ट: "गलत": अगर सही है, तो Basel, कवरेज चलाने के दौरान हर टेस्ट के लिए, कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: 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 टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[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> डिफ़ॉल्ट: "@@protobuf+//:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--[no]proto_profile डिफ़ॉल्ट: "सही": क्या प्रोटो कंपाइलर को profile_path पास करना है.
टैग: affects_outputs, loading_and_analysis
--proto_profile_path=<a build target label> डिफ़ॉल्ट: जानकारी देखें: प्रोफ़ाइल_पाथ के तौर पर प्रोटो कंपाइलर को भेजी जाने वाली प्रोफ़ाइल. अगर यह सेट नहीं है, लेकिन --proto_profile सही (डिफ़ॉल्ट) है, तो --fdo_optimize से पाथ का अनुमान लगाया जाता है.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> डिफ़ॉल्ट: "@@protobuf+//:cc_toolchain": proto_lang_toolchain() का लेबल जो C++ Protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain": proto_lang_toolchain() का लेबल जो j2objc protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@@protobuf+//:java_toolchain": proto_lang_toolchain() का लेबल, जो Java प्रोटो कोड को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@@protobuf+//: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 को कंपाइल करने में इंटरफ़ेस जार का इस्तेमाल होता है. इससे तेज़ी से कंपाइलेशन होगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

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

--[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 डिफ़ॉल्ट: "गलत": अगर इसे 'सही है' पर सेट किया जाता है, तोकर के इस्तेमाल के लिए सेव किए गए सैंडबॉक्स के कॉन्टेंट को मेमोरी में ट्रैक किया जाएगा. इससे, फिर से इस्तेमाल करने के दौरान ज़रूरी 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 dit पर जाने के लिए, अनुमतियों की ज़रूरत होती है.
टैग: execution
--experimental_sandbox_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0": अगर यह वैल्यू 0 से ज़्यादा है, तो हर Linux सैंडबॉक्स में तय मेमोरी (एमबी में) ही इस्तेमाल की जा सकेगी. इसके लिए, cgroups v1 या v2 की ज़रूरत होती है. साथ ही, उपयोगकर्ताओं के पास cgroups डायरेक्ट्री के लिए अनुमतियां होनी चाहिए.
टैग: execution
--[no]experimental_shrink_worker_pool डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू है, तो वर्कर मेमोरी का दबाव ज़्यादा होने पर, वर्कर पूल छोटा हो सकता है. यह फ़्लैग सिर्फ़ तब काम करता है, जब प्रयोग के तौर पर इस्तेमाल होने वाले_total_worker_memory_limit_mb को फ़्लैग किया गया हो, तो यह फ़्लैग काम करता है.
टैग: execution, host_machine_resource_optimizations
--[no]experimental_split_xml_generation डिफ़ॉल्ट: "सही": अगर यह फ़्लैग सेट है और टेस्ट ऐक्शन से test.xml फ़ाइल जनरेट नहीं होती है, तो Baze, टेस्ट लॉग वाली एक डमी 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] डिफ़ॉल्ट: "ऑटो": एक साथ चलने वाली जॉब की संख्या. यह एक पूर्णांक या कीवर्ड ("ऑटो", "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.bagel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution
--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर: स्पैन ऐक्शन को लागू करने के लिए, किस स्पैन रणनीति का इस्तेमाल किया जाना चाहिए. यह रणनीति, किसी खास regex_filter से मैच करने वाली जानकारी के लिए तय की जाती है. regex_filter मैचिंग के बारे में जानकारी के लिए, --per_file_copt देखें. जानकारी से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. रणनीति तय करने के लिए यह विकल्प दूसरे फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि अगर ऐक्शन के ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो लोकल रणनीति का इस्तेमाल करके ऐक्शन चलाएं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed 'कंपाइलिंग //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा, लेकिन ऑर्डर को उलटा करने पर वह 'सैंडबॉक्स' के साथ चल जाएगा.
टैग: 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 के साथ 'कर्मचारी' रणनीति का इस्तेमाल किया जाता है, तो मल्टीप्लेक्स वर्कर प्रोसेस के साथ-साथ कितने WorkRequests मिल सकते हैं. हर मेनिमोनिक के लिए अलग वैल्यू देने के लिए, [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 डिफ़ॉल्ट: "सही": इस फ़्लैग से यह कंट्रोल किया जाता है कि हम बिल्ड event संबद्धSymlinksIdentified को BuildEventProtocol पर पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में shoppingSymlinksIdentified, के लिए एक एंट्री होगी, जिसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक की सूची होगी. अगर यह 'गलत' है, तो 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' पर सेट किया जाता है, तो यह 'मिनिमल' की तरह काम करता है, लेकिन यह स्थानीय मशीन पर टॉप लेवल टारगेट के आउटपुट डाउनलोड भी करता है. अगर नेटवर्क बैंडविड्थ की समस्या है, तो दोनों विकल्पों से बिल्ड करने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: 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

--[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

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत": अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी 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> डिफ़ॉल्ट: जानकारी देखें: यह 'baज़ल टेस्ट' के लिए, बेस अस्थायी डायरेक्ट्री का इस्तेमाल करता है.

--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> डिफ़ॉल्ट: "": स्काईफ़ोकस के लिए काम करने वाला सेट. कॉमा लगाकर अलग किए गए वर्कस्पेस के रूट-रिलेटिव पाथ के तौर पर बताएं. यह एक स्टेटलेस फ़्लैग है. वर्किंग सेट तय करने पर, उसे बाद में फिर से इस्तेमाल किया जा सकता है. ऐसा तब तक किया जा सकता है, जब तक उसे नए सेट से फिर से तय नहीं किया जाता.
टैग: 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'> बार इस्तेमाल किए गए: Bज़ल के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. स्ट्रिंग-फ़्लोट पेयर को इस्तेमाल करता है. एक से ज़्यादा तरह के अतिरिक्त संसाधनों की जानकारी देने के लिए, कई बार इस्तेमाल किया जा सकता है. 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": Bज़ल के लिए उपलब्ध लोकल होस्ट रैम (एमबी में) की कुल मात्रा साफ़ तौर पर सेट करें, ताकि उसे स्थानीय तौर पर लागू की जाने वाली बिल्ड कार्रवाइयों पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_RAM" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_RAM*.5, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, ("Host_RAM*.67"), Babel उपलब्ध रैम का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और उसके 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, उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों की संख्या को सीमित कर देगा. टेस्ट में "संसाधन:<संसाधन का नाम>:<amount>" फ़ॉर्मैट का टैग इस्तेमाल करके, यह बताया जा सकता है कि उन्हें कितने संसाधनों की ज़रूरत है. --local_{cpu|ram|extra}_resources से तय किए गए संसाधनों को बदल देता है.
टैग: host_machine_resource_optimizations

--build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4": Baज़ल को बिल्ड इवेंट को ज़्यादा से ज़्यादा कितनी बार अपलोड करना चाहिए.
टैग: 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 इवेंट में लेगसी before_Outputs फ़ील्ड को जनरेट करने की प्रोसेस बंद करने के लिए, इसका इस्तेमाल करें. Basel को नतीजेStore/BTX इंटिग्रेशन के लिए ज़रूरी_आउटपुट सेट करना ज़रूरी है.
टैग: 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 डिफ़ॉल्ट: "गलत": इससे सैंडबॉक्स की सुविधा के लिए, डीबग करने की सुविधाएं चालू हो जाती हैं. इसमें दो चीज़ें शामिल हैं: पहला, बिल्ड के बाद सैंडबॉक्स के रूट कॉन्टेंट में कोई बदलाव नहीं किया जाता; और दूसरा, इसे चलाने पर डीबग करने से जुड़ी अतिरिक्त जानकारी प्रिंट होती है. इससे Baज़र या Starlark के नियमों के डेवलपर को, इनपुट फ़ाइलें मौजूद न होने वगैरह की वजह से डीबग करने में मदद मिल सकती है.
टैग: terminal_output
--show_result=<an integer> डिफ़ॉल्ट: "1": बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए बताएं कि उसे अप-टू-डेट किया गया था या नहीं. अगर हां, तो बनाई गई आउटपुट फ़ाइलों की सूची भी बताएं. प्रिंट की गई फ़ाइलें शेल में कॉपी करने+पेस्ट करने और उन्हें चलाने के लिए सुविधाजनक स्ट्रिंग होती हैं. इस विकल्प के लिए, पूर्णांक आर्ग्युमेंट की ज़रूरत होती है. यह टारगेट की थ्रेशोल्ड संख्या होती है. इस थ्रेशोल्ड से ज़्यादा होने पर, नतीजों की जानकारी नहीं छपी जाती. इसलिए, शून्य की वैल्यू देने पर मैसेज नहीं दिखता और MAX_INT की वैल्यू देने पर नतीजा हमेशा दिखता है. डिफ़ॉल्ट रूप से, एक होता है. अगर किसी टारगेट के लिए कुछ भी नहीं बनाया गया है, तो आउटपुट को थ्रेशोल्ड के तहत रखने के लिए, उसके नतीजों को हटाया जा सकता है.
टैग: affects_outputs
--[no]subcommands [-s] डिफ़ॉल्ट: "गलत": बिल्ड के दौरान चलाए गए सब-कमांड दिखाएं. मिलते-जुलते फ़्लैग: --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 चालू नहीं है, तो इसका कोई असर नहीं होता.
टैग: affects_outputs
--[no]verbose_failures डिफ़ॉल्ट: "गलत": अगर कोई निर्देश काम नहीं करता, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

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

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें: यह सर्किट ब्रेकर के इस्तेमाल की रणनीति के बारे में बताता है. उपलब्ध रणनीतियां "फ़ेल" हैं. विकल्प के लिए अमान्य वैल्यू देने पर, विकल्प के लिए सेट किया गया व्यवहार नहीं दिखता.
टैग: execution
--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत": किसी ऐक्शन की इनपुट फ़ाइलों को रिमोट कैश मेमोरी में अपलोड करने से पहले, उनकी ctime की जांच करने की सुविधा बंद करने के लिए, इसे बंद करें. ऐसे मामले हो सकते हैं जहां Linux कर्नेल फ़ाइलों को लिखने में देरी करता है और इसकी वजह से फ़ॉल्स पॉज़िटिव नतीजे आ सकते हैं.
--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 डिफ़ॉल्ट: "गलत": अगर बैज को 'सही है' पर सेट किया जाता है, तो बिल्ड के दौरान Basel को रिमोट ऐक्शन के आउटपुट के लिए लीज़ को बढ़ाने का मौका मिलेगा. इसके लिए, समय-समय पर रिमोट कैश मेमोरी में `FindomissingBlobs` कॉल भेजना होगा. फ़्रीक्वेंसी, `--experimental_remote_cache_ttl` की वैल्यू पर आधारित होती है.
--experimental_remote_cache_ttl=<An immutable length of time.> डिफ़ॉल्ट: "3h": रिमोट कैश मेमोरी में ब्लॉब का कम से कम टीटीएल, जब उनके डाइजेस्ट का हाल ही में रेफ़रंस दिया गया हो. जैसे, ActionResult या FindMissingBlobs. Bazel, ब्लॉब के टीटीएल के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, इंक्रीमेंटल बिल्ड में GetActionResult को बार-बार कॉल नहीं करता. वैल्यू, रीयल TTL से कुछ कम सेट होनी चाहिए, क्योंकि सर्वर की तरफ़ से डाइजेस्ट वापस मिलने और बेज़ल को मिलने के समय के बीच एक अंतर है.
टैग: execution
--experimental_remote_capture_corrupted_outputs=<a path> डिफ़ॉल्ट: जानकारी देखें: उस डायरेक्ट्री का पाथ जहां गड़बड़ी वाले आउटपुट कैप्चर किए जाएंगे.
--[no]experimental_remote_discard_merkle_trees डिफ़ॉल्ट: "सही": अगर नीति को 'सही है' पर सेट किया जाता है, तो GetActionresults() और सार्वजनिक फ़ंक्शन को एक्ज़ीक्यूट करने के दौरान दी गई कॉल के दौरान, इनपुट रूट के मर्कल ट्री की इन-मेमोरी कॉपी और उससे जुड़ी इनपुट मैपिंग को खारिज करें. इससे मेमोरी का इस्तेमाल काफ़ी कम हो जाता है. हालांकि, रिमोट कैश मेमोरी में जगह न होने और दोबारा कोशिश करने पर, Baज़ल को फिर से उनका आकलन करना पड़ता है.
--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 डिफ़ॉल्ट: "गलत": किसी दूसरी जगह से किए जाने वाले कॉल के लिए, कीपअलाइव का इस्तेमाल करना है या नहीं.
--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 सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bagel डिफ़ॉल्ट रूप से 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> डिफ़ॉल्ट: "कम से कम": अगर 'सभी' पर सेट है, तो 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 सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bagel डिफ़ॉल्ट रूप से 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 सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bagel डिफ़ॉल्ट रूप से 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 नहीं दिया गया है, तो इस विकल्प की वैल्यू का इस्तेमाल किया जाता है. इससे अपने-आप फ़िल्टर बन जाता है. अनुमति वाली वैल्यू 'कोई नहीं' (फ़िल्टर कुछ भी नहीं / सब कुछ दिखाएं), 'सभी' (सब कुछ फ़िल्टर करें / कुछ नहीं दिखाएं), 'पैकेज' (ब्लेज़ कमांड लाइन पर बताए गए पैकेज के नियमों से आउटपुट शामिल करें), और 'सबपैकेज' (जैसे 'पैकेज', लेकिन सबपैकेज भी शामिल हैं) हैं. 'पैकेज' और 'सब-पैकेज' वैल्यू के लिए, //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> डिफ़ॉल्ट: ब्यौरा देखें: ऐसी डायरेक्ट्री का पाथ जहां Ba जानना, कार्रवाइयां और ऐक्शन आउटपुट पढ़ने और लिखने की सुविधा देता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.
--embed_label=<a one-line string> डिफ़ॉल्ट: "": सोर्स कंट्रोल रिविज़न या रिलीज़ लेबल को बाइनरी में एम्बेड करना
--execution_log_binary_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें: इस फ़ाइल में, जो स्पॉन्स किए गए हैं उन्हें src/main/protobuf/spawn.proto के मुताबिक, लंबे समय से सीमांकित Spwn फ़ंक्शन प्रोटो के तौर पर लॉग करें. --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 के मुताबिक, लंबे समय तक सीमांकित exeLogEntry प्रोटो के तौर पर लॉग करें. पूरी फ़ाइल को 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 डिफ़ॉल्ट: "गलत": अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. टॉप लेवल टारगेट के लिए सिर्फ़ Ex_action शेड्यूल करता है.
--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_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> डिफ़ॉल्ट: "@ba"_tools//tools/test:coverage_report_generator": कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_report_generator' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis
--coverage_support=<a build target label> का डिफ़ॉल्ट मैसेज: "@bagel_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 वर्शन में हाइफ़न वाला लेबल है, तो "ज़रूरी-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 मशीनों पर चलाता है. इसलिए, पहला तरीका ज़्यादा सही है. इससे "बेज़ल रन" पर कोई असर नहीं पड़ता, जो टारगेट कॉन्फ़िगरेशन में हमेशा "`--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 डिफ़ॉल्ट: "सही": अगर टूलचेन काम करता है, तो इंटरफ़ेस के शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, ईएलएफ़ टूलचेन में यह सेटिंग काम करती है.
टैग: 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 टूल के वर्शन की जानकारी देता है. अगर जानकारी नहीं दी गई है, तो macOS SDK के डिफ़ॉल्ट वर्शन के लिए, 'xcode_version' का इस्तेमाल किया जाता है.
टैग: 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 टारगेट चलाने के लिए इस्तेमाल किया जाता है. बहिष्कृत; --insupported_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 SDK के वर्शन के बारे में बताता है, ताकि tvOS ऐप्लिकेशन बनाने के लिए इसका इस्तेमाल किया जा सके. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट tvOS SDK टूल के वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें: यह WatchOS SDK के वर्शन के बारे में बताता है, ताकि WatchOS ऐप्लिकेशन बनाने में इस्तेमाल किया जा सके. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version=<a string> डिफ़ॉल्ट: जानकारी देखें: अगर यह एट्रिब्यूट तय किया गया है, तो काम की बिल्ड ऐक्शन के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी गई है, तो Xcode के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state
--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes": बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए, इस्तेमाल किया जाने वाला xcode_config नियम का लेबल.
टैग: 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> डिफ़ॉल्ट: "वर्णमाला": यह नीति, 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 डिफ़ॉल्ट: "गलत": अगर ऐसा किया जाता है, तो Baज़र, इंस्ट्रुमेंट कोड का इस्तेमाल करेगा (जहां हो सके ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --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> बार इस्तेमाल किए गए: जीसीसी को पास करने के लिए दूसरे विकल्प.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: --इसके लिए तय किया गया हर विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू दी गई हैं, तो आखिरी वैल्यू का इस्तेमाल किया जाएगा.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default": यह तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Basel को यह चुनना होगा कि उसे डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी' का मतलब है कि सभी लाइब्रेरी डायनैमिक रूप से लिंक कर दी जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: 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_ रखरखाव_की मदद से, रजिस्टर किया गया है, तो उस छोटे नाम का इस्तेमाल किया जाएगा. इसके बाद, अगर --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 फ़ाइल या एलएलवीएम प्रोफ़ाइल फ़ाइल हो. यह फ़्लैग, लेबल के तौर पर बताई गई फ़ाइलों को भी स्वीकार करता है.जैसे, `//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 लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन के हिसाब से एक्ज़ीक्यूटेबल एक्ज़ीक्यूटेबल ("-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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: एक्ज़िक कॉन्फ़िगरेशन में 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: लिंक करते समय, जीसीसी में भेजने का एक और विकल्प.
टैग: 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 डायरेक्टिव जोड़ना पड़ सकता है. इस विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --प्रॉपेनर_ऑप्टिमाइज़=//a/b:prop वायरलेस_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें: प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए 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" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब स्ट्रिप iff --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

--[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> डिफ़ॉल्ट: "डिफ़ॉल्ट": अगर यह सही है, तो यह जांच की जाती है कि कोई 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> डिफ़ॉल्ट: जानकारी देखें: लागू करने के दौरान, अनुमति वाली सूची (पैकेज_ग्रुप टारगेट) का इस्तेमाल करें --inबेमेल_python_disallow_native_rules.
टैग: 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 टारगेट साफ़ तौर पर 'सार्वजनिक इंपोर्ट' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--[no]strict_system_includes डिफ़ॉल्ट: "गलत": अगर यह सही है, तो सिस्टम में शामिल पाथ (-isystem) से मिले हेडर की जानकारी भी देनी होगी.
टैग: loading_and_analysis, eagerness_to_exit
--target_environment=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर: इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर एनवायरमेंट तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

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

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

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत": अगर सही है, तो टारगेट टारगेट के लिए विश्लेषण में गड़बड़ी होने पर, टारगेट में विश्लेषणFailureInfo का वह इंस्टेंस दिखता है जिसमें गड़बड़ी की जानकारी होती है. इससे ऐप्लिकेशन बनाने में गड़बड़ी होती है.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन की ज़्यादा से ज़्यादा संख्या सेट करता है. अगर उपयोगकर्ता ने यह सीमा पार नहीं की, तो नियम में गड़बड़ी होगी.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत": अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> एक से ज़्यादा बार इस्तेमाल किए जाने पर: जांच के लिए, संसाधनों की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई एक पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगी. अगर कॉमा लगाकर अलग की गई चार संख्याएं दी जाती हैं, तो वे छोटे, मध्यम, बड़े, बहुत बड़े टेस्ट साइज़ के लिए संसाधन की रकम को बदल देंगी. वैल्यू के तौर पर HOST_RAM/HOST_CPU भी इस्तेमाल किया जा सकता है. इसके बाद, [-|*]<float> भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, 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 डिफ़ॉल्ट: "सही": जेर फ़ाइल की हर फ़ाइल की डेक्सिंग के लिए ज़्यादातर काम अलग-अलग किए जाते हैं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही": अगर यह नीति सेट की जाती है, तो क्लैंग की मदद से बनाई गई .d फ़ाइलों का इस्तेमाल, objc कंपाइलों में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत": //a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग की सुविधा चालू हो.
टैग: execution
--[no]trim_test_configuration डिफ़ॉल्ट: "सही": इस विकल्प को चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के सबसे ऊपरी लेवल के नीचे से हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को बिना टेस्ट वाले नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने पर, बिना टेस्ट वाले नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

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

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर: 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 टारगेट पर ले जाएगा. अगर इस विकल्प को चालू किया जाता है, तो हमारा सुझाव है कि आप `--insupported_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) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Baze, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर सभी जांच नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजों को कैश मेमोरी में सेव नहीं करता.
--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत": अगर यह सही है, तो Blaze पहले सफल रन पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ काम आता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत": अगर सही है, तो Basel, कवरेज चलाने के दौरान हर टेस्ट के लिए, कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: 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 की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सुविधा सिर्फ़ बेज़ल के लिए काम करती है.
--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 में मौजूद पाथ पर फ़ाइल को टच करके शार्डिंग की सुविधा देता है, तो Baज़ल, शार्ड टेस्ट में फ़ेल हो जाएगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: 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 डिफ़ॉल्ट: "सही": सीधे सोर्स से इजर कंपाइल करें.
--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 वीएम को पास करने के लिए दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें: यह उन क्लास की सूची जनरेट करने के लिए एक बाइनरी के बारे में बताता है जिन्हें लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होना चाहिए.
--optimizing_dexer=<a build target label> डिफ़ॉल्ट: जानकारी देखें: शर्ड किए बिना डेक्स करने के लिए इस्तेमाल की जाने वाली बाइनरी के बारे में बताता है.
--plugin=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर: बिल्ड में इस्तेमाल करने के लिए प्लग इन. फ़िलहाल, यह java_plugin के साथ काम करता है.
--proguard_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें: Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना है, यह बताता है.
--proto_compiler=<a build target label> डिफ़ॉल्ट: "@@protobuf+//: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> डिफ़ॉल्ट: "@@protobuf+//:cc_toolchain": proto_lang_toolchain() का लेबल जो C++ Protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bagel_tools//tools/j2objc:j2objc_proto_toolchain": proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@@protobuf+//:java_toolchain": proto_lang_toolchain() का लेबल, जो Java प्रोटो कोड को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@@protobuf+//:javalite_toolchain": proto_lang_toolchain() का लेबल, जो JavaLite प्रोटो को कॉम्पाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--protocopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर: प्रोटोबफ़ कंपाइलर को पास करने के लिए अन्य विकल्प.
टैग: affects_outputs
--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "गलत": अगर सही है, तो जिस शार्ड में कम से कम एक दौड़ या कोशिश की जाती है उसे 'फ़्लैकी' स्टेटस मिलता है.
--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 एट्रिब्यूट मौजूद हो. 'अक्षम' है. 'shard_count' BUILD एट्रिब्यूट पर ध्यान दिए बिना, जांच के लिए 'k' शार्ड लागू करने के लिए 'forced=k' का इस्तेमाल किया जाता है.
--tool_java_language_version=<a string> डिफ़ॉल्ट: "": Java भाषा का वह वर्शन जिसका इस्तेमाल, बिल्ड के दौरान ज़रूरी टूल चलाने के लिए किया जाता है
--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11": बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन
--[no]use_ijars डिफ़ॉल्ट: "सही": अगर यह विकल्प चालू है, तो Java कंपाइलेशन इंटरफ़ेस के लिए jar का इस्तेमाल करता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

कैननिकल फ़्लैग वाले विकल्प

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

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

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत": अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी 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/baडेलbuild/bagel/issues/12932 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं की जाती.
टैग: loading_and_analysis

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

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

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

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

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

टैग: host_machine_resource_optimizations

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

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

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

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

Cquery के विकल्प

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

--[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 फ़ाइल में साफ़ तौर पर तय नहीं किया गया है, लेकिन उसे बैजल से जोड़ा गया है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics
--[no]include_aspects डिफ़ॉल्ट: "सही": aquery, cquery: क्या आउटपुट में आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से जनरेट की गई कार्रवाइयों को शामिल करना है. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output
--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही": अगर इस नीति को चालू किया जाता है, तो Package_group के `packages` एट्रिब्यूट को आउटपुट करने के दौरान, सबसे पहले मौजूद `//` को नहीं हटाया जाएगा.
टैग: terminal_output, incompatible_change
--[no]infer_universe_scope डिफ़ॉल्ट: "गलत": अगर --universe_scope सेट है और --universe_scope की वैल्यू सेट नहीं है, तो --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" एट्रिब्यूट के बारे में जानने के लिए, `info Build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics
--output=<a string> डिफ़ॉल्ट: "लेबल": वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: Label, Label_ kind, textproto, ट्रांज़िशन, प्रोटोकॉल, स् ट्रीम किया गया प्रोटो, jsonproto. 'ट्रांज़िशन' चुनने पर, आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": डेफ़िनिशन_stack प्रोटो फ़ील्ड को पॉप्युलेट करें, जो हर नियम इंस्टेंस के लिए स्टारलार्क कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की जाती थी.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": अगर यह चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए फ़्लैटन प्रज़ेंटेशन एक ऐसी सूची है जिसमें चुने गए मैप की हर वैल्यू को सिर्फ़ एक बार शामिल किया जाता है. स्केलर टाइप को शून्य पर फ़्लैट कर दिया जाता है.
टैग: build_file_semantics
--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत": हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को, उस सोर्स आसपेक्ट के साथ भरें जिससे यह एट्रिब्यूट मिला है (अगर ऐसा नहीं है, तो स्ट्रिंग खाली है).
टैग: terminal_output
--[no]proto:include_configurations डिफ़ॉल्ट: "सही": अगर यह चालू है, तो प्रोटो आउटपुट में कॉन्फ़िगरेशन की जानकारी शामिल होगी. बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs
--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत": $internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output
--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत": हर नियम के इंस्टैंशिएट करने वाले कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output
--[no]proto:locations डिफ़ॉल्ट: "सही": जगह की जानकारी को प्रोटो आउटपुट में आउटपुट देना है या नहीं.
टैग: terminal_output
--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "सभी": आउटपुट में शामिल करने के लिए एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_classes डिफ़ॉल्ट: "गलत": हर नियम के rule_class_key फ़ील्ड को पॉप्युलेट करें. साथ ही, किसी दिए गए rule_class_key वाले पहले नियम के लिए, उसके rule_class_info प्रोटो फ़ील्ड को भी पॉप्युलेट करें. नियम_क्लास_की फ़ील्ड, नियम की कैटगरी की खास तौर पर पहचान करता है. साथ ही, नियम_क्लास_इन्फ़ो फ़ील्ड Stardoc-format नियम क्लास एपीआई डेफ़िनिशन है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर यह सेट है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां फ़ाइल के साथ-साथ कमांड-लाइन क्वेरी भी डालने पर गड़बड़ी होती है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर यह सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--show_config_fragments=<off, direct or transitive> डिफ़ॉल्ट: "बंद": यह किसी नियम और उसकी ट्रांज़िशन डिपेंडेंसी के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट दिखाता है. इससे यह पता लगाने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ को कितना छोटा किया जा सकता है.
टैग: affects_outputs
--starlark:expr=<a string> डिफ़ॉल्ट: "": एक Starlark एक्सप्रेशन. इसकी मदद से, कॉन्फ़िगर किए गए हर टारगेट को cquery के --आउटपुट=starlark मोड में फ़ॉर्मैट किया जा सकता है. कॉन्फ़िगर किया गया टारगेट, 'target' से बंधा होता है. अगर --starlark:expr और --starlark:file, दोनों में से किसी का भी इस्तेमाल नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट हो जाएगा. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल करने पर गड़बड़ी होती है.
टैग: terminal_output
--starlark:file=<a string> डिफ़ॉल्ट: "": इस फ़ाइल में 'format' नाम का एक Starlark फ़ंक्शन होता है. इसमें एक आर्ग्युमेंट होता है, जिसे कॉन्फ़िगर किए गए हर टारगेट पर लागू करके उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल करने पर गड़बड़ी होती है. ज़्यादा जानकारी के लिए, --output=starlark के लिए सहायता देखें.
टैग: terminal_output
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: अगर इसे बंद किया जाता है, तो 'एग्ज़ीक्यूट कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, एक से ज़्यादा बार ट्रांज़िशन करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics
--transitions=<full, lite or none> डिफ़ॉल्ट: "कोई नहीं": वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी को प्रिंट करेगी.
टैग: affects_outputs
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न (जोड़ने और घटाने वाले) का कॉमा लगाकर बनाया गया सेट. क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प में इनपुट के तौर पर वे टारगेट डाले जाते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, इस विकल्प का असर कॉन्फ़िगरेशन और ट्रांज़िशन पर पड़ सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माना जाता है. ध्यान दें: cquery के लिए, इस विकल्प को न बताने पर, हो सकता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल विकल्पों के साथ बिल्ड न हो पाएं.
टैग: loading_and_analysis

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

{14//} टैग करें

--strategy=Aapt2Optimize=worker--strategy=AARGenerator=worker--strategy=ProcessDatabinding=worker--strategy=GenerateDataBindingBaseClasses=workerhost_machine_resource_optimizationsexecution
--persistent_multiplex_android_dex_desugar: वर्कर्स का इस्तेमाल करके, Android dex और desugar की लगातार होने वाली कई कार्रवाइयों को चालू करें.
इस तरह बड़ा होता है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_resource_processor: वर्कर्स का इस्तेमाल करके, लगातार मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.
इस तरह बड़ा होता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --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 डिफ़ॉल्ट: "गलत": अगर सही है, तो Baze, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा, न कि टेस्ट एक्ज़ेक्यूटिव ग्रुप का.
टैग: 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> डिफ़ॉल्ट: "@ba"_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> डिफ़ॉल्ट: जानकारी देखें: अगर तय किया गया है, तो यह सेटिंग एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन के लिए 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" को बनाता है. अगर बंद हो, तो यह टारगेट कॉन्फ़िगरेशन में "//:दौड़ना करने वाले टूल" बनाता है. Bazel, टेस्ट को exec मशीनों पर चलाता है. इसलिए, पहला तरीका ज़्यादा सही है. इससे "बेज़ल रन" पर कोई असर नहीं पड़ता, जो टारगेट कॉन्फ़िगरेशन में हमेशा "`--run_under=//foo" बनाता है.
टैग: affects_outputs, incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही": अगर सही है, तो Basel, c++ टूलचेन में 'host' और 'nonhost' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/ba इमारतोंbuild/ba इमारतों/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 डिफ़ॉल्ट: "सही": अगर सही है, तो Baज़र, लाइब्रेरी डिपेंडेंसी को डिफ़ॉल्ट रूप से पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazibuild/baZ/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> डिफ़ॉल्ट: ब्यौरा देखें: टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python अनुवादक को दिखाने वाले py_runtime का लेबल. अब काम नहीं करता; --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 डेटाबाइंडिंग 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> डिफ़ॉल्ट: "वर्णमाला": यह नीति, 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 डिफ़ॉल्ट: "ऑटो": Python के लिए, ज़िप फ़ाइल में प्रोग्राम को चलाने की सुविधा जोड़ना; Windows पर चालू, अन्य प्लैटफ़ॉर्म पर बंद करना
टैग: affects_outputs
--catalyst_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर: ऐसे आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है. इन आर्किटेक्चर के लिए, Apple Catalyst बाइनरी बनाई जानी हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]collect_code_coverage डिफ़ॉल्ट: "गलत": अगर ऐसा किया जाता है, तो Baज़र, इंस्ट्रुमेंट कोड का इस्तेमाल करेगा (जहां हो सके ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --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> डिफ़ॉल्ट: ब्यौरा देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई एलएलवीएम प्रोफ़ाइल फ़ाइल वाली 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++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Basel को यह चुनना होगा कि उसे डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: 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_dr सही है. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.
टैग: affects_outputs, experimental
--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत": अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. सटीक स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है: सबसे पहले, अगर --platforms विकल्प में एक ही वैल्यू नहीं है, तो प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir से रजिस्टर किया गया था, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_Output_किन_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 डिफ़ॉल्ट: "गलत": इस विकल्प के चालू होने पर, नियम के तहत इस्तेमाल किए गए हर टूलचेन के लिए, एक एक्सेक्यूट ग्रुप अपने-आप बन जाता है. इसके काम करने के लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, 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 डिफ़ॉल्ट: "सही": अब काम नहीं करता, --inबेमेल_remove_legacy_whole_archive (ज़्यादा जानकारी के लिए, https://github.com/ba इमारतोंbuild/baze/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> डिफ़ॉल्ट: ब्यौरा देखें: मेमप्रोफ़ प्रोफ़ाइल का इस्तेमाल करें.
टैग: 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:prop इंतज़ार_optimize( name = "prop Tager_profile", cc_profile = "prop एक्सप्लोर_cc_profile.txt", ld_profile = "prop मुझे_ld_profile.txt" में लेबल को लेबल करने के बारे में बताना चाहिए. इन फ़ाइलों को बेज़ल में दिखाने के लिए, export_files डायरेक्टिव को संबंधित पैकेज में जोड़ना ज़रूरी है. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs
--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: जानकारी देखें: प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए 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_ऑप्टिमाइज़/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा इस तरह लागू होंगे जैसे कि xbinary_fdo की जानकारी कभी न दी गई हो.
टैग: affects_outputs

--[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> डिफ़ॉल्ट: "डिफ़ॉल्ट": अगर यह सही है, तो यह जांच की जाती है कि कोई 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> डिफ़ॉल्ट: ब्यौरा देखें: लागू करने के दौरान, अनुमति वाली सूची (पैकेज_ग्रुप टारगेट) का इस्तेमाल करें --inबेमेल_python_disallow_native_rules.
टैग: loading_and_analysis
--[no]strict_filesets डिफ़ॉल्ट: "गलत": अगर यह विकल्प चालू है, तो पैकेज की सीमाएं पार करने वाली फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "गड़बड़ी": अगर यह विकल्प बंद नहीं है, तो यह जांच की जाती है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change
--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद": जब तक यह विकल्प बंद नहीं होता, तब तक यह जांच की जाती है कि proto_library टारगेट, '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": APK साइन करने के लिए इस्तेमाल करने का तरीका
टैग: 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

--[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 पेयर के ज़रिए पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'basel 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 डिफ़ॉल्ट: "सही": जेर फ़ाइल की हर फ़ाइल की डेक्सिंग के लिए ज़्यादातर काम अलग-अलग किए जाते हैं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही": अगर यह नीति सेट की जाती है, तो क्लैंग की मदद से बनाई गई .d फ़ाइलों का इस्तेमाल, objc कंपाइलों में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत": //a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग की सुविधा चालू हो.
टैग: execution
--[no]trim_test_configuration डिफ़ॉल्ट: "सही": चालू होने पर, बिल्ड के टॉप लेवल के नीचे जांच से जुड़े विकल्प मिटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को बिना टेस्ट वाले नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने पर, बिना टेस्ट वाले नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

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

--flag_alias=<a 'name=value' flag alias> बार इस्तेमाल किए गए: Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत": यह फ़्लैग, डिफ़ॉल्ट तरीके को बदल देता है, ताकि Python टारगेट के रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बनें. इसका मतलब यह है कि जब किसी py_binary या py_test टारगेट में लेगसी_create_init टारगेट "अपने-आप" (डिफ़ॉल्ट) पर सेट होता है, तो इस फ़्लैग के सेट होने पर ही इसे गलत माना जाता है. https://github.com/batzbuild/ba सुझावों/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही": अगर सही है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, '-py2' सफ़िक्स वाले आउटपुट रूट में दिखेंगे. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा सफ़िक्स न हो. इसका मतलब है कि `bazel-bin` सुविधा वाला सिंबललिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. अगर इस विकल्प को चालू किया जाता है, तो हमारा सुझाव है कि आप `--insupported_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही": अगर सही है, तो `py_binary` और `py_test` टारगेट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे PY2 के बजाय डिफ़ॉल्ट रूप से PY3 पर सेट हो जाएंगे. अगर आपने इस फ़्लैग को सेट किया है, तो हमारा सुझाव है कि `--insupported_py2_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) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Baze, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर सभी जांच नतीजों को कैश मेमोरी में सेव कर लेता है. अगर बैज 'नहीं' पर सेट है, तो Basel किसी भी टेस्ट के नतीजे को कैश मेमोरी में नहीं सेव करता.
--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत": अगर यह सही है, तो Blaze पहले सफल रन पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ मिलकर काम करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत": अगर सही है, तो Basel, कवरेज चलाने के दौरान हर टेस्ट के लिए, कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis, experimental
--[no]experimental_generate_llvm_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> डिफ़ॉल्ट: "javaबिल्डर": 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> डिफ़ॉल्ट: "@@protobuf+//: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> डिफ़ॉल्ट: "@@protobuf+//: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> डिफ़ॉल्ट: "@@protobuf+//:java_toolchain": proto_lang_toolchain() का लेबल, जो Java प्रोटो कोड को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@@protobuf+//: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 इसका इस्तेमाल करता है. अगर दोनों में से कोई भी सेट नहीं है, तो Basel, चलने वाले ऑपरेटिंग सिस्टम के आधार पर हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है (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": टेस्ट शार्डिंग के लिए रणनीति तय करें: 'शर्डिंग' एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब शार्डिंग का इस्तेमाल किया जा रहा हो. 'अक्षम' है. 'shard_count' BUILD एट्रिब्यूट पर ध्यान दिए बिना, जांच के लिए 'k' शार्ड लागू करने के लिए 'forced=k' का इस्तेमाल किया जाता है.
--tool_java_language_version=<a string> डिफ़ॉल्ट: "": Java लैंग्वेज वर्शन, जिसका इस्तेमाल ऐसे टूल को एक्ज़ीक्यूट करने के लिए किया जाता है जो बिल्ड के दौरान ज़रूरी होते हैं
--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11": बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन
--[no]use_ijars डिफ़ॉल्ट: "सही": अगर यह विकल्प चालू है, तो Java कंपाइलेशन इंटरफ़ेस के लिए jar का इस्तेमाल करता है. इससे तेज़ी से कंपाइलेशन होगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

डंप के विकल्प

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

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

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

--[no]all डिफ़ॉल्ट: "गलत": यह किसी भी टारगेट या रिपॉज़िटरी को बनाने के लिए ज़रूरी सभी बाहरी रिपॉज़िटरी फ़ेच करता है. अगर कोई दूसरा फ़्लैग और आर्ग्युमेंट नहीं दिया गया है, तो यह डिफ़ॉल्ट रूप से लागू होता है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs
--[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", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत": अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/batzbuild/ba इमारतों/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 डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis

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

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: "": अगर यह वैल्यू खाली नहीं है, तो Starlark की वैल्यू लिखें. इसमें, Starlark के उन सभी रिपॉज़िटरी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

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

--[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' जोड़ता है. '(?!Genनया).*=-requires-x', सभी गैर-सामान्य कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से 'ज़रूरी-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 डिफ़ॉल्ट: "गलत": अगर सही है, तो Baze, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा, न कि टेस्ट एक्ज़ेक्यूटिव ग्रुप का.
टैग: 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> डिफ़ॉल्ट: "@bagel_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> डिफ़ॉल्ट: ब्यौरा देखें: अगर तय किया गया है, तो यह सेटिंग एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन के लिए libc टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देगी.
टैग: action_command_lines, affects_outputs
--host_platform=<a build target label> डिफ़ॉल्ट: "@ba"_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 डिफ़ॉल्ट: "सही": अगर सही है, तो Baज़र, लाइब्रेरी डिपेंडेंसी को डिफ़ॉल्ट रूप से पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazibuild/baZ/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 टूल के वर्शन की जानकारी देता है. अगर जानकारी नहीं दी गई है, तो macOS SDK के डिफ़ॉल्ट वर्शन के लिए, 'xcode_version' का इस्तेमाल किया जाता है.
टैग: 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 SDK के वर्शन के बारे में बताता है, ताकि tvOS ऐप्लिकेशन बनाने के लिए इसका इस्तेमाल किया जा सके. अगर कोई वैल्यू नहीं दी गई है, तो '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 वर्शन चुनने के लिए, इस्तेमाल किया जाने वाला xcode_config नियम का लेबल.
टैग: 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 के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटाबाइंडिंग 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 का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. डिपेंडेंसी का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसी क्रम में रखा जाता है जो उसके डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution
--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत": ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis
--[no]build_python_zip डिफ़ॉल्ट: "ऑटो": python की एक्ज़ीक्यूटेबल ZIP फ़ाइल बनाएं; 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 से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताना चाहिए - इसके बजाय, 'basel app' निर्देश का इस्तेमाल किया जाना चाहिए.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: --इसके लिए तय किया गया हर विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू होने पर, आखिरी वैल्यू की जीत होती है.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "डिफ़ॉल्ट": यह तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs
--[no]enable_propeller_optimize_absolute_paths डिफ़ॉल्ट: "सही": अगर यह नीति सेट की जाती है, तो प्रोपेलर ऑप्टिमाइज़ के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी दिखेगी.
टैग: 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 APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: 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/batzbuild/ba बहुत/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_किन_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_dr पर निर्भर रहने पर माइग्रेट करें.
टैग: affects_outputs, experimental
--fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें: एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करना. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs
--fdo_optimize=<a string> डिफ़ॉल्ट: जानकारी देखें: कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री हो, अपने-आप बनी प्रोफ़ाइल वाली afdo फ़ाइल या एलएलवीएम प्रोफ़ाइल फ़ाइल हो. यह फ़्लैग, लेबल के तौर पर बताई गई फ़ाइलों को भी स्वीकार करता है.जैसे, `//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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: एक्ज़िक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, 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_ऐप्लिकेशन का इस्तेमाल करके, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. इसका नतीजा एक यूनिवर्सल बाइनरी होता है, जिसमें सभी तय किए गए आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis
--[no]legacy_whole_archive डिफ़ॉल्ट: "सही": अब काम नहीं करता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. इसे चालू होने पर, cc_binary नियमों के लिए -पूरा-संग्रह का इस्तेमाल करें, जिसमें 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> डिफ़ॉल्ट: जानकारी देखें: मेमप्रोफ़ प्रोफ़ाइल का इस्तेमाल करें.
टैग: 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> डिफ़ॉल्ट: जानकारी देखें: प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs
--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: जानकारी देखें: प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए, ld_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs
--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें: 'टेस्ट' और 'रन' निर्देशों के लिए, एक्सीक्यूटेबल के पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो आखिरी कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इनके कुछ उदाहरण हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines
--[no]share_native_deps डिफ़ॉल्ट: "सही": अगर यह सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के बीच शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs
--[no]stamp डिफ़ॉल्ट: "गलत": तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल स्टोर करने की जगह की जानकारी वगैरह के साथ बाइनरी को स्टैंप करें.
टैग: affects_outputs
--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी": यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि --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

--[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/bazibuild/ba बहुत/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 टारगेट साफ़ तौर पर 'सार्वजनिक इंपोर्ट' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर बताता है.
टैग: 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

--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही": काम नहीं करता. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "गलत": अगर सही है, तो objc_library andobjc_Import में sdk_frameworks और कम ऊर्जा_SDK_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत": अगर सही है, तो objc_library और objc_Import में हमेशा लिंक एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही बनाएं.
टैग: build_file_semantics, incompatible_change
--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत": अगर यह सही है, तो पहले से मौजूद py_* नियमों का इस्तेमाल करते समय गड़बड़ी होती है. इसके बजाय, 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. जहां Run_per_test का मतलब पूर्णांक वैल्यू है और regex_filter, रेगुलर एक्सप्रेशन पैटर्न की सूची को दिखाता है और इसमें शामिल नहीं है (इसे भी देखें --instrumentation_filter). उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.
--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर: टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या 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

--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/batzbuild/ba सुझावों/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही": अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `baZ-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) टेस्ट पहले फ़ेल हो गया हो. अगर इसे 'हां' पर सेट किया जाता है, तो Baze, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर सभी जांच नतीजों को कैश मेमोरी में सेव कर लेता है. अगर बैज 'नहीं' पर सेट है, तो Basel किसी भी टेस्ट के नतीजे को कैश मेमोरी में नहीं सेव करता.
--[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 वीएम को पास करने के लिए दूसरे विकल्प. ये विकल्प, हर 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> डिफ़ॉल्ट: "@@protobuf+//:protoc": प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis
--[no]proto_profile डिफ़ॉल्ट: "सही": क्या प्रोटो कंपाइलर को profile_path पास करना है.
टैग: affects_outputs, loading_and_analysis
--proto_profile_path=<a build target label> डिफ़ॉल्ट: जानकारी देखें: प्रोफ़ाइल_पाथ के तौर पर प्रोटो कंपाइलर को भेजी जाने वाली प्रोफ़ाइल. अगर यह सेट नहीं है, लेकिन --proto_profile सही (डिफ़ॉल्ट) है, तो --fdo_optimize से पाथ का अनुमान लगाया जाता है.
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_cc=<a build target label> डिफ़ॉल्ट: "@@protobuf+//: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 protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@@protobuf+//:java_toolchain": proto_lang_toolchain() का लेबल जो Java प्रोटोकॉल को इकट्ठा करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@@protobuf+//: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]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं की जाती.
टैग: loading_and_analysis

--help_verbosity=<long, medium or short> डिफ़ॉल्ट: "medium": सहायता कमांड के लिए, ज़्यादा जानकारी देने का विकल्प चुनें.
टैग: terminal_output
--long [-l]: हर विकल्प के नाम के बजाय, उसका पूरा ब्यौरा दिखाएं.
इसमें बड़ा किया जाता है:
--help_verbosity=long

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

टैग: terminal_output

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

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": No-op.
टैग: loading_and_analysis

--[no]show_make_env डिफ़ॉल्ट: "गलत": आउटपुट में "Make" एनवायरमेंट शामिल करें.
टैग: affects_outputs, terminal_output

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

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

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

--mode=<classic, classic_internal_test_do_not_use or skylark> डिफ़ॉल्ट: "skylark": 'कोई इफ़ेक्ट नहीं' फ़्लैग का इस्तेमाल बंद कर दिया गया है. फ़िलहाल, सिर्फ़ Skylark मोड काम कर रहा है.
टैग: loading_and_analysis, execution, incompatible_change

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

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

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

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

टैग: execution

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं की जाती.
टैग: loading_and_analysis

--incremental_install_verbosity=<a string> डिफ़ॉल्ट: "": इंक्रीमेंटल इंस्टॉल के लिए ज़्यादा जानकारी. डीबग लॉगिंग के लिए, वैल्यू को 1 पर सेट करें.
टैग: bazel_monitoring

मोड के विकल्प

--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": लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत": अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/batzbuild/ba इमारतों/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

--base_module=<"<root>" for the root module; <module>@<version> for a specific version of a module; <module> for all versions of a module; @<name> for a repo with the given apparent name; or @@<name> for a repo with the given canonical name> डिफ़ॉल्ट: "<root>": ऐसा मॉड्यूल तय करें जिसके हिसाब से, दिए गए टारगेट रिपोज़ का मतलब समझा जाए.
टैग: terminal_output
--charset=<utf8 or ascii> डिफ़ॉल्ट: "utf8": ट्री के लिए इस्तेमाल करने के लिए, वर्ण सेट चुनता है. इसका असर सिर्फ़ टेक्स्ट आउटपुट पर पड़ता है. मान्य वैल्यू "utf8" या "ascii" हैं. डिफ़ॉल्ट तौर पर "utf8" होता है
टैग: terminal_output
--[no]cycles डिफ़ॉल्ट: "गलत": दिखाए गए ट्री में, डिपेंडेंसी साइकल की जानकारी देता है. आम तौर पर, डिफ़ॉल्ट रूप से इन साइकल को अनदेखा किया जाता है.
टैग: terminal_output
--depth=<an integer> डिफ़ॉल्ट: "-1": डिपेंडेंसी ट्री की ज़्यादा से ज़्यादा डिसप्ले गहराई. उदाहरण के लिए, डेप्थ 1, सीधे डिपेंडेंसी दिखाता है. tree, path, और all_paths के लिए, यह डिफ़ॉल्ट रूप से Integer.MAX_VALUE पर सेट होता है. वहीं, deps और explain के लिए, यह डिफ़ॉल्ट रूप से 1 पर सेट होता है. यह सिर्फ़ टारगेट लीफ़ और उनके पैरंट के अलावा, रूट के डायरेक्ट डिपेंडेंसी दिखाता है.
टैग: terminal_output
--extension_filter=<a comma-separated list of <extension>s> डिफ़ॉल्ट: जानकारी देखें: सिर्फ़ तब इन मॉड्यूल एक्सटेंशन और उनके जनरेट किए गए रिपॉज़िटरी के इस्तेमाल को दिखाएं, जब उनके फ़्लैग सेट हों. अगर यह सेट है, तो नतीजों के ग्राफ़ में सिर्फ़ वे पाथ शामिल होंगे जिनमें बताए गए एक्सटेंशन का इस्तेमाल करने वाले मॉड्यूल शामिल हैं. खाली सूची, फ़िल्टर को बंद कर देती है. साथ ही, सभी संभावित एक्सटेंशन को असरदार तरीके से दिखाती है.
टैग: terminal_output
--extension_info=<hidden, usages, repos or all> डिफ़ॉल्ट: "hidden": तय करें कि क्वेरी के नतीजे में, एक्सटेंशन के इस्तेमाल के बारे में कितनी जानकारी शामिल करनी है. "इस्तेमाल" में सिर्फ़ एक्सटेंशन के नाम दिखेंगे. "रिपॉज़िटरी" में, use_repo की मदद से इंपोर्ट की गई रिपॉज़िटरी भी शामिल होंगी. साथ ही, "सभी" में एक्सटेंशन से जनरेट की गई अन्य रिपॉज़िटरी भी दिखेंगी.
टैग: terminal_output
--extension_usages=<a comma-separated list of <module>s> डिफ़ॉल्ट: "": ऐसे मॉड्यूल के बारे में बताएं जिनके एक्सटेंशन के इस्तेमाल, show_extension क्वेरी में दिखेंगे.
टैग: terminal_output
--from=<a comma-separated list of <module>s> डिफ़ॉल्ट: "<root>": वह मॉड्यूल जिससे डिपेंडेंसी ग्राफ़ की क्वेरी दिखेगी. सटीक सेमेटिक्स के लिए, हर क्वेरी के ब्यौरे की जांच करें. डिफ़ॉल्ट रूप से <root> पर सेट होता है.
टैग: terminal_output
--[no]include_builtin डिफ़ॉल्ट: "गलत": डिपेंडेंसी ग्राफ़ में, पहले से मौजूद मॉड्यूल शामिल करें. यह डिफ़ॉल्ट रूप से बंद रहता है, क्योंकि इसमें बहुत ज़्यादा शोर होता है.
टैग: terminal_output
--[no]include_unused डिफ़ॉल्ट: "गलत": क्वेरी में, ऐसे मॉड्यूल भी शामिल किए जाएंगे और दिखाए जाएंगे जिन्हें इस्तेमाल नहीं किया गया है. ये मॉड्यूल, चुने जाने के बाद मॉड्यूल रिज़ॉल्यूशन ग्राफ़ में नहीं दिखते. ऐसा, कम से कम वर्शन चुनने या बदलाव करने के नियमों की वजह से होता है. इससे हर तरह की क्वेरी पर अलग-अलग असर पड़ सकता है. जैसे, all_paths कमांड में नए पाथ शामिल करना या explain कमांड में अतिरिक्त डिपेंडेंट शामिल करना.
टैग: terminal_output
--output=<text, json or graph> डिफ़ॉल्ट: "text": क्वेरी के नतीजों को जिस फ़ॉर्मैट में प्रिंट करना है. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: text, json, graph
टैग: terminal_output
--[no]verbose डिफ़ॉल्ट: "गलत": क्वेरी में, मॉड्यूल के मौजूदा वर्शन के हिसाब से समाधान किए जाने की वजह भी दिखेगी (अगर बदलाव हुआ है). यह सिर्फ़ 'एक्सप्लेन' क्वेरी के लिए डिफ़ॉल्ट रूप से 'सही' पर सेट होता है.
टैग: terminal_output

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

Print_action के विकल्प

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

--print_action_mnemonics=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर: इसमें उन मेमोनिम की सूची होती है जिनके हिसाब से print_action डेटा को फ़िल्टर किया जाता है. खाली छोड़ने पर, कोई फ़िल्टर नहीं किया जाता.

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

--[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": लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. उदाहरण के लिए, "auto", "Host_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--[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

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

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

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

टैग: terminal_output
--output=<a string> डिफ़ॉल्ट: "लेबल": क्वेरी के नतीजों को जिस फ़ॉर्मैट में प्रिंट करना है. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: build, graph, streamed_jsonproto, label, label_kind, location, maxrank, minrank, package, proto, streamed_proto, xml.
टैग: terminal_output
--[no]proto:default_values डिफ़ॉल्ट: "सही": अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output
--[no]proto:definition_stack डिफ़ॉल्ट: "गलत": definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह फ़ील्ड, नियम के इंस्टेंस के लिए Starlark कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की गई थी.
टैग: terminal_output
--[no]proto:flatten_selects डिफ़ॉल्ट: "सही": चालू होने पर, Select() से बनाए जा सकने वाले, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट फ़्लैट कर दिए जाते हैं. सूची के टाइप के लिए, फ़्लैट किया गया रिप्रज़ेंटेशन एक सूची होती है, जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप को फ़्लैट करके शून्य कर दिया जाता है.
टैग: build_file_semantics
--[no]proto:include_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": आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा से अलग की गई सूची. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. किसी भी एट्रिब्यूट का आउटपुट देने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output
--[no]proto:rule_classes डिफ़ॉल्ट: "गलत": हर नियम के नियम_class_key फ़ील्ड में जानकारी डालें; और दिए गए नियम_class_key वाले पहले नियम के लिए, इसके नियम_class_info प्रोटो फ़ील्ड में भी जानकारी डालें. नियम_क्लास_की फ़ील्ड, नियम की कैटगरी की खास तौर पर पहचान करता है. साथ ही, नियम_क्लास_इन्फ़ो फ़ील्ड Stardoc-format नियम क्लास एपीआई डेफ़िनिशन है.
टैग: terminal_output
--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही": rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output
--query_file=<a string> डिफ़ॉल्ट: "": अगर यह सेट है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां फ़ाइल के साथ-साथ कमांड-लाइन क्वेरी भी डालने पर गड़बड़ी होती है.
टैग: changes_inputs
--[no]relative_locations डिफ़ॉल्ट: "गलत": अगर यह सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output
--[no]strict_test_suite डिफ़ॉल्ट: "गलत": अगर सही है, तो test() एक्सप्रेशन को तब गड़बड़ी का मैसेज मिलता है, जब उसे बिना जांच वाले टारगेट वाला test_suite मिलता है.
टैग: build_file_semantics, eagerness_to_exit
--[no]tool_deps डिफ़ॉल्ट: "सही": क्वेरी: यह विकल्प बंद होने पर, 'एक्ज़िक कॉन्फ़िगरेशन' की डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाएगा जिस पर क्वेरी काम करती है. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, एक से ज़्यादा बार ट्रांज़िशन करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप लेवल टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ लागू किए गए कॉन्फ़िगर किए गए टारगेट ही लौटाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics
--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: "": टारगेट पैटर्न (जोड़ने और घटाने वाले) का कॉमा लगाकर बनाया गया सेट. क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प में इनपुट के तौर पर वे टारगेट डाले जाते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, इस विकल्प का असर कॉन्फ़िगरेशन और ट्रांज़िशन पर पड़ सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माना जाता है. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ बनाए नहीं जा सकते हैं, तो इस विकल्प को न बताने पर, बिल्ड टूट सकता है.
टैग: loading_and_analysis
--[no]xml:default_values डिफ़ॉल्ट: "गलत": अगर यह सही है, तो नियम के ऐसे एट्रिब्यूट प्रिंट किए जाते हैं जिनकी वैल्यू, BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें हटा दिया जाता है.
टैग: terminal_output
--[no]xml:line_numbers डिफ़ॉल्ट: "सही": अगर यह सही है, तो एक्सएमएल आउटपुट में लाइन नंबर शामिल होते हैं. इस विकल्प को बंद करने से, बदलावों को पढ़ना आसान हो सकता है. यह विकल्प सिर्फ़ --output=xml पर लागू होता है.
टैग: terminal_output

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: "": अगर यह वैल्यू खाली नहीं है, तो Starlark की वैल्यू लिखें. इसमें, Starlark के उन सभी रिपॉज़िटरी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

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

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

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

--[no]portable_paths डिफ़ॉल्ट: "गलत": अगर यह 'सही' है, तो ExecRequest में बदले जाने वाले पाथ शामिल होते हैं, ताकि नतीजे के तौर पर मिलने वाले पाथ पोर्टेबल हो सकें.
टैग: affects_outputs
--[no]run डिफ़ॉल्ट: "सही": अगर गलत है, तो बनाए गए टारगेट के लिए बनाई गई कमांड लाइन चलाएं. ध्यान दें कि --script_path वाले सभी बिल्ड के लिए, इस फ़्लैग को अनदेखा कर दिया जाता है.
टैग: affects_outputs
--run_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर: टारगेट कॉन्फ़िगरेशन वाले ऐक्शन के लिए उपलब्ध, एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. यह पेयर, कॉल करने के एनवायरमेंट से अलग वैल्यू सेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: affects_outputs

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

बंद करने के विकल्प

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

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

--[no]configure डिफ़ॉल्ट: "गलत": सिर्फ़ उन रिपॉज़िटरी को सिंक करें जिन्हें सिस्टम कॉन्फ़िगरेशन के लिए, 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है.
टैग: changes_inputs
--[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", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration
--only=<a string> बार इस्तेमाल किए गए: अगर यह विकल्प दिया जाता है, तो सिर्फ़ इस विकल्प में बताई गई रिपॉज़िटरी सिंक करें. हालांकि, अब भी सभी (या --configure के दिए जाने पर, configure जैसे सभी) को पुराना माना जाता है.
टैग: changes_inputs

--[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/baडेलbuild/bagel/issues/12932 देखें.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं की जाती.
टैग: loading_and_analysis

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: "": अगर वैल्यू खाली नहीं है, तो Starlark के डेटा स्टोर करने की जगह के उन सभी नियमों की रिज़ॉल्व की गई जानकारी के साथ Starlark वैल्यू लिखें जिन्हें लागू किया गया था.
टैग: affects_outputs

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

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

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

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं की जाती.
टैग: loading_and_analysis

--[no]print_relative_test_log_paths डिफ़ॉल्ट: "गलत": अगर यह सही है, तो टेस्ट लॉग के पाथ को प्रिंट करते समय, रिलेटिव पाथ का इस्तेमाल करें. यह पाथ, 'testlogs' सुविधा वाले सिंबललिंक का इस्तेमाल करता है. ध्यान दें - किसी दूसरे कॉन्फ़िगरेशन के साथ आने वाले 'बिल्ड'/'टेस्ट'/वगैरह को शुरू करने से, इस सिमलिंक का टारगेट बदल सकता है. ऐसा करने से, पहले प्रिंट किया गया पाथ अब काम का नहीं रहता.
टैग: affects_outputs
--[no]test_verbose_timeout_warnings डिफ़ॉल्ट: "गलत": अगर यह सही है, तो टेस्ट के असल समय और टेस्ट के लिए तय किए गए टाइम आउट (चाहे वह तय किया गया हो या नहीं) के मेल न खाने पर, अतिरिक्त चेतावनियां प्रिंट करें.
टैग: affects_outputs
--[no]verbose_test_summary डिफ़ॉल्ट: "सही": अगर यह सही है, तो टेस्ट की खास जानकारी में ज़्यादा जानकारी (समय, बिना किसी नतीजे के पूरे हुए रन की संख्या वगैरह) प्रिंट करें.
टैग: affects_outputs

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

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

--[no]keep_going [-k] डिफ़ॉल्ट: "गलत": गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जो टारगेट पूरा नहीं हो पाया और जो उस पर निर्भर हैं उनका विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें हो सकती हैं.
टैग: 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", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--[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

--repo=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर: सिर्फ़ वेंडर, तय की गई रिपॉज़िटरी का इस्तेमाल कर सकते हैं. यह रिपॉज़िटरी, `@apparent_repo_name` या `@@canonical_repo_name` हो सकती है. इस विकल्प को कई बार सेट किया जा सकता है
टैग: changes_inputs

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

--[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. एक से ज़्यादा वैल्यू तय करते समय, क्रम का ध्यान रखना ज़रूरी है, क्योंकि एक ही मेनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "रेगुलर एक्सप्रेशन=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों को लागू करने की जानकारी में 'x' और 'z' को जोड़ता है और उससे 'y' को हटाता है. 'Genroll=+requires-x', सभी जेनरल कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में 'ज़रूरी-x' जोड़ता है. '(?!Genनया).*=-requires-x', सभी गैर-सामान्य कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से 'ज़रूरी-x' को हटा देता है.
टैग: execution, affects_outputs, loading_and_analysis
--persistent_android_dex_desugar: कर्मचारियों का इस्तेमाल करके, Android dex और डीशुगर कार्रवाइयों को लगातार चालू करें.
इस तरह बड़ा होता है:
  --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

{14//} टैग करें

--strategy=Aapt2Optimize=worker--strategy=AARGenerator=worker--strategy=ProcessDatabinding=worker--strategy=GenerateDataBindingBaseClasses=workerhost_machine_resource_optimizationsexecution
--persistent_multiplex_android_dex_desugar: वर्कर्स का इस्तेमाल करके, Android dex और desugar की लगातार होने वाली कई कार्रवाइयों को चालू करें.
इस तरह बड़ा होता है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution
--persistent_multiplex_android_resource_processor: कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android संसाधन प्रोसेसर को चालू करें.
इस तरह बड़ा होता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --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> डिफ़ॉल्ट: "@bagel_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> डिफ़ॉल्ट: "@ba"_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 फ़ंक्शन को पसंद के मुताबिक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में मैलक एट्रिब्यूट को बदल देती है.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों को ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन पर विचार किया जाएगा, ताकि उन टूलचेन को आपके लिए
affects_outputschanges_inputsloading_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 डिफ़ॉल्ट: "सही": अगर सही है, तो Baज़र, लाइब्रेरी डिपेंडेंसी को डिफ़ॉल्ट रूप से पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazibuild/baZ/issues/7362 पर जाएं.
टैग: loading_and_analysis, incompatible_change
--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "गलत": अगर यह सही है, तो 'रन करने लायक फ़ाइलों' के लिए स्ट्रिप ऐक्शन, फ़्लैग -x का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.
टैग: action_command_lines, incompatible_change
--[no]interface_shared_objects डिफ़ॉल्ट: "सही": अगर टूलचेन के साथ काम करता है, तो इंटरफ़ेस के साथ शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, ईएलएफ़ टूलचेन में यह सेटिंग काम करती है.
टैग: 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' से वॉचओएस 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 का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. डिपेंडेंसी का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसी क्रम में रखा जाता है जो उसके डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: 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> बार इस्तेमाल किए गए: जीसीसी को पास करने के लिए दूसरे विकल्प.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: --इसके लिए तय किया गया हर विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू दी गई हैं, तो आखिरी वैल्यू का इस्तेमाल किया जाएगा.
टैग: changes_inputs, affects_outputs
--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default": यह तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Basel को यह चुनना होगा कि उसे डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: 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_dr सही है. नाम रखने की प्राथमिकता सबसे ज़्यादा है.
टैग: 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 चालू होने पर Basel, 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: एक्ज़ीक्यूटिव कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs
--host_cpu=<a string> डिफ़ॉल्ट: "": होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs
--host_cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर: एक्ज़ीक्यूटिव कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs
--host_features=<a string> बार इस्तेमाल किए गए: एक्ज़ीक्यूटिव कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<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_ऐप्लिकेशन का इस्तेमाल करके, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. इसका नतीजा एक यूनिवर्सल बाइनरी होता है, जिसमें सभी तय किए गए आर्किटेक्चर शामिल होते हैं.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: लिंक करते समय, जीसीसी में भेजने का एक और विकल्प.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर: कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड ( --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

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

--[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 डिफ़ॉल्ट: "गलत": अगर सही है, तो टारगेट टारगेट के लिए विश्लेषण में गड़बड़ी होने पर, टारगेट में विश्लेषणFailureInfo का वह इंस्टेंस दिखता है जिसमें गड़बड़ी की जानकारी होती है. इससे ऐप्लिकेशन बनाने में गड़बड़ी होती है.
टैग: loading_and_analysis, experimental
--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000": for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा डेटा डालने पर, नियम से जुड़ी गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत": अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental
--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> बार इस्तेमाल किए गए: टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर किसी सिंगल पॉज़िटिव संख्या को <value> के तौर पर दिखाया जाता है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगा. अगर कॉमा लगाकर चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की संख्या को बदल देंगी. वैल्यू के तौर पर HOST_RAM/HOST_CPU भी इस्तेमाल किया जा सकता है. इसके बाद, [-|*]<float> भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, 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 डिफ़ॉल्ट: "सही": जेर फ़ाइल की हर फ़ाइल की डेक्सिंग के लिए ज़्यादातर काम अलग-अलग किए जाते हैं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state
--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही": अगर यह सेट है, तो clang से जनरेट की गई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis
--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत": टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग: execution
--[no]trim_test_configuration डिफ़ॉल्ट: "सही": इस विकल्प को चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के सबसे ऊपरी लेवल के नीचे से हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को बिना टेस्ट वाले नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने पर, बिना टेस्ट वाले नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

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

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर: Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs
--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत": इस फ़्लैग से डिफ़ॉल्ट सेटिंग बदल जाती है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बने रहें. इसका मतलब यह है कि जब किसी py_binary या py_test टारगेट में लेगसी_create_init टारगेट "अपने-आप" (डिफ़ॉल्ट) पर सेट होता है, तो इस फ़्लैग के सेट होने पर ही इसे गलत माना जाता है. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change
--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही": अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `baZ-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] डिफ़ॉल्ट: "ऑटो": अगर बैज को 'ऑटो' पर सेट किया जाता है, तो वह दोबारा टेस्ट तब करता है, जब: (1) Baज़र को टेस्ट या उसकी डिपेंडेंसी में बदलाव का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया है, (3) --runs_per_test की मदद से कई टेस्ट रन करने का अनुरोध किया गया था या(4) टेस्ट पहले फ़ेल हो गया था. अगर इसे 'हां' पर सेट किया जाता है, तो Baze, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर सभी जांच नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो 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 डिफ़ॉल्ट: "गलत": अगर सही है, तो क्लैंग के लिए कवरेज एक एलसीओवी रिपोर्ट जनरेट करेगी.
टैग: 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 में मौजूद पाथ पर फ़ाइल को टच करके शार्डिंग की सुविधा देता है, तो Baज़ल, शार्ड टेस्ट में फ़ेल हो जाएगा. गलत होने पर, शार्ड का समर्थन नहीं करने वाले टेस्ट रनर से हर शार्ड में सभी टेस्ट चल जाएंगे.
टैग: 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> डिफ़ॉल्ट: "@@protobuf+//: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> डिफ़ॉल्ट: "@@protobuf+//:cc_toolchain": proto_lang_toolchain() का लेबल जो C++ Protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain": proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@@protobuf+//:java_toolchain": proto_lang_toolchain() का लेबल, जो Java प्रोटो कोड को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis
--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@@protobuf+//: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]gnu_format डिफ़ॉल्ट: "गलत": अगर सेट है, तो GNU स्टैंडर्ड में बताए गए नियमों का इस्तेमाल करके, वर्शन को स्टैंडआउट में लिखें.
टैग: affects_outputs, execution

--[no]incompatible_use_plus_in_repo_names डिफ़ॉल्ट: "सही": कोई कार्रवाई नहीं.
टैग: loading_and_analysis

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

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

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

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