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

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

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

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

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

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

-<short_form> <value>

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

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

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

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

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

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

निर्देश

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--host_jvm_args=<jvm_arg> बार इस्तेमाल किए गए

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

--host_jvm_debug

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

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

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

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

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

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

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

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

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

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

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

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

अगर इसे 'सही है' पर सेट किया जाता है, तो रिमोट या डिस्क कैश मेमोरी में अपलोड किए गए सिमलिंक, डेगल हो सकते हैं.
टैग: execution, incompatible_change

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

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel हमेशा रिमोट या डिस्क कैश मेमोरी में सिमलंक को इस तरह अपलोड करेगा. अगर ऐसा नहीं होता है, तो न झूलने वाले मिलते-जुलते सिमलिंक (और सिर्फ़ उन ही) को उस फ़ाइल या डायरेक्ट्री के तौर पर अपलोड किया जाएगा जिस पर वे ले जाते हैं.
टैग: execution, incompatible_change

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

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

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

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

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

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

--remote_download_all

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

टैग: affects_outputs

--remote_download_minimal

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

टैग: affects_outputs

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

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

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

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

--remote_download_toplevel

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

टैग: affects_outputs

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

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

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

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

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

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

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

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

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

अगर यह 'सही है' पर सेट है, तो बाहरी डिपेंडेंसी के लिए, लेगसी WORKSPACE सिस्टम चालू हो जाता है. ज़्यादा जानकारी के लिए, https://bagel.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 एपीआई के तरीके उपलब्ध होंगे
टैग: 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_enable_android_migration_apis डिफ़ॉल्ट: "गलत"

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

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

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

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

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

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

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

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

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

कॉमा लगाकर अलग किए गए नियमों (या अन्य सिंबल) की सूची, जो पहले Bazel का हिस्सा थे और जिन्हें अब उनके बाहरी रिपॉज़िटरी से वापस पाना है. इस फ़्लैग का इस्तेमाल, Bazel से नियमों को माइग्रेट करने के लिए किया जाता है. https://github.com/bagelbuild/ba सुझावों/issues/23043 पर जाएं. किसी फ़ाइल में अपने-आप लोड होने वाला सिंबल, इस तरह काम करता है जैसे कि पहले से मौजूद बैजल डेफ़िनिशन को एक्सटर्नल रिपॉज़िटरी में उसकी कैननिकल नई डेफ़िनिशन से बदल दिया गया हो. BUILD फ़ाइल के लिए, इसका मतलब है कि load() स्टेटमेंट को चुपचाप जोड़ना. किसी .bzl फ़ाइल के लिए, यह या तो एक लोड() स्टेटमेंट है या `नेटिव` ऑब्जेक्ट के किसी फ़ील्ड में बदलाव होता है. यह इस बात पर निर्भर करता है कि अपने-आप लोड हुआ सिंबल कोई नियम है या नहीं. बेज़ल उन सभी सिंबल की एक हार्डकोड सूची बनाकर रखता है जो अपने-आप लोड हो सकते हैं; इस फ़्लैग में सिर्फ़ वे चिह्न दिख सकते हैं. हर सिंबल के लिए, Basel को एक्सटर्नल रिपॉज़िटरी (डेटा स्टोर करने की जगह) में नई जगह के बारे में पता है. साथ ही, खास-केस वाले डेटा स्टोर करने की जगहों के एक सेट के बारे में भी पता है, जिसे साइकल बनाने से बचने के लिए, अपने-आप लोड नहीं होना चाहिए. इस फ़्लैग में "+foo" की सूची के आइटम की वजह से, सिंबल foo अपने-आप लोड हो जाता है. हालांकि, foo की उन रिपॉज़िटरी में ऐसा नहीं होता जिनमें Bazel से तय किया गया foo का वर्शन अब भी उपलब्ध है. "foo" का कोई सूची आइटम, ऊपर बताए गए तरीके से अपने-आप लोड होने की सुविधा को ट्रिगर करता है. हालांकि, Bazel के तय किए गए foo के वर्शन को, बाहर रखे गए रिपॉज़िटरी के लिए उपलब्ध नहीं कराया जाता. इससे यह पक्का होता है कि foo का बाहरी रिपॉज़िटरी, foo के पुराने Bazel लागू करने पर निर्भर नहीं करता है "-foo" का कोई सूची आइटम, किसी भी ऑटोलोडिंग को ट्रिगर नहीं करता है. हालांकि, इससे पूरे वर्कस्पेस में foo के Bazel से तय किए गए वर्शन को ऐक्सेस नहीं किया जा सकता. इसका इस्तेमाल यह पुष्टि करने के लिए किया जाता है कि वर्कस्पेस, 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_java_output_source_jars डिफ़ॉल्ट: "सही"

सही होने पर, Basil अब java_info.java_Output[0].source_jars से कोई सूची नहीं दिखाता, लेकिन इसके बजाय depset दिखाता है.
टैग: loading_and_analysis, incompatible_change

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

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

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

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

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

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

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

अगर इसे 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स की मदद से, 'टारगेट' ऑब्जेक्ट पर उपलब्ध कराने वाली सेवाओं को ऐक्सेस करने की सुविधा बंद कर दें. इसके बजाय, provider-key सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, नियम लागू करने वाले फ़ंक्शन में, `my_info` को ऐक्सेस करने के लिए `ctx.attr.dep.my_info` का इस्तेमाल करने के बजाय, `ctx.attr.dep[MyInfo]` का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bagelbuild/baZ/issues/9014 पर जाएं.
टैग: build_file_semantics, 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_existing_rules_immutable_view डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो native.existing_rule और native.existing_rules, बदले जा सकने वाले डिक्शनरी के बजाय, लाइटवाइट और बदले न जा सकने वाले व्यू ऑब्जेक्ट दिखाते हैं.
टैग: build_file_semantics, loading_and_analysis, incompatible_change

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--[no]incompatible_no_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 फ़ंक्शन के `आउटपुट` पैरामीटर को बंद कर देता है.
टैग: build_file_semantics, incompatible_change

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

अगर इसे 'सही है' पर सेट किया जाता है, तो जानकारी लिंक करने के लिए ObjcProvider के एपीआई हटा दिए जाएंगे.
टैग: 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 को बनाया जाएगा. linking_context के पुराने गटर भी बंद कर दिए जाएंगे और सिर्फ़ linker_inputs उपलब्ध होंगे.
टैग: build_file_semantics, loading_and_analysis, incompatible_change

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

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

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

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

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

स्ट्रक्चर के to_json और to_proto तरीकों को बंद कर देता है. ये तरीके, स्ट्रक्चर फ़ील्ड नेमस्पेस को गंदा करते हैं. इसके बजाय, JSON के लिए json.encode या json.encode_indent या टेक्स्टप्रोटो के लिए proto.encode_text का इस्तेमाल करें.
टैग: build_file_semantics, incompatible_change

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

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

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

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

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

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

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

अगर सही है, तो कैननिकल रिपो नामों में टिल्ड (~) के बजाय, प्लस के निशान (+) का इस्तेमाल किया जाता है. यह Windows पर परफ़ॉर्मेंस से जुड़ी गंभीर समस्याओं को हल करने के लिए इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://github.com/baazbuild/ba बहुत/issues/22865 पर जाएं.
टैग: loading_and_analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बिल्ड इवेंट सेवा (BES) का बैकएंड एंडपॉइंट [SCHEME://]Host[:PORT] फ़ॉर्म में बताता है. यह डिफ़ॉल्ट तौर पर, बीईएस डेटा अपलोड करने की सुविधा को बंद करता है. इन स्कीम का इस्तेमाल किया जा सकता है: 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> डिफ़ॉल्ट: जानकारी देखें

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

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

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

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

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

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

यह तय करता है कि 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> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--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' या 'full_async' में से किसी एक को चुनें.
टैग: eagerness_to_exit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--experimental_profile_additional_tasks=<phase, action, action_check, action_lock, action_release, action_update, action_complete, bzlmod, info, create_package, remote_execution, local_execution, scanner, local_parse, upload_time, remote_process_time, remote_queue, remote_setup, fetch, local_process_time, vfs_stat, vfs_dir, vfs_readlink, vfs_md5, vfs_xattr, vfs_delete, vfs_open, vfs_read, vfs_write, vfs_glob, vfs_vmfs_stat, vfs_vmfs_dir, vfs_vmfs_read, wait, thread_name, thread_sort_index, skyframe_eval, skyfunction, critical_path, critical_path_component, handle_gc_notification, action_counts, action_cache_counts, local_cpu_usage, system_cpu_usage, cpu_usage_estimation, local_memory_usage, system_memory_usage, memory_usage_estimation, system_network_up_usage, system_network_down_usage, workers_memory_usage, system_load_average, starlark_parser, starlark_user_fn, starlark_builtin_fn, starlark_user_compiled_fn, starlark_repository_fn, action_fs_staging, remote_cache_check, remote_download, remote_network, filesystem_traversal, worker_execution, worker_setup, worker_borrow, worker_working, worker_copying_outputs, credential_helper, pressure_stall_io, pressure_stall_memory, 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_label डिफ़ॉल्ट: "गलत"

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

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

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

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

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

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

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

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

यह सेटिंग चालू होने पर, Baze, बिल्ड की प्रोफ़ाइल बना देता है और आउटपुट बेस में, 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

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

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

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

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

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

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

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

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

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

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

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

डिफ़ॉल्ट रूप से, Bazel प्रोफ़ाइलर तेज़ी से होने वाले कई इवेंट (जैसे, फ़ाइल को स्टैट करना) के लिए सिर्फ़ एग्रीगेट किया गया डेटा रिकॉर्ड करेगा. अगर यह विकल्प चालू है, तो प्रोफ़ाइलर हर इवेंट को रिकॉर्ड करेगा. इससे, प्रोफ़ाइलिंग का ज़्यादा सटीक डेटा मिलेगा, लेकिन परफ़ॉर्मेंस पर काफ़ी असर पड़ेगा. इस विकल्प का असर सिर्फ़ तब होता है, जब --profile का इस्तेमाल भी किया गया हो.
टैग: 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_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें

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

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

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

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

अगर यह सही है, तो स्पॉन के हिस्से के तौर पर होने के बजाय, रिमोट कैश मेमोरी का I/O बैकग्राउंड में होगा.

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

zstd --remote_cache_compression सेट होने तक, यह विकल्प काम नहीं करता.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अब काम नहीं करता. नहीं-ऑप. इसके बजाय --remote_build_event_upload=minimal का उपयोग करें.

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

एक से ज़्यादा वैल्यू वाले हेडर की सभी वैल्यू को, रिमोट डाउनलोडर को भेजना है या सिर्फ़ पहली वैल्यू को.
टैग: incompatible_change

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

अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट के हिसाब से होते हैं.
टैग: incompatible_change

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

कोई कार्रवाई नहीं करने वाले
टैग: incompatible_change

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--remote_download_regex=<a valid Java regular expression> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नहीं, इसकी सुविधा नहीं है. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba बहुत/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.> डिफ़ॉल्ट: "60 सेकंड"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier> डिफ़ॉल्ट: "0"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--invocation_id=<a UUID> डिफ़ॉल्ट: ""

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर यह 'गलत है' पर सेट है, तो WORKSPACE में नेटिव रिपॉज़िटरी के नियमों का इस्तेमाल किया जा सकता है. अगर यह 'सही है' पर सेट है, तो Starlark रिपॉज़िटरी के नियमों का इस्तेमाल करना होगा. नेटिव रेपो नियमों में local_repository, new_local_repository, local_config_platform, android_sdk_repository, और android_ndk_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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

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

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

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

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

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

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

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

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

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `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> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--experimental_worker_for_repo_fetching=<off, platform, virtual or auto> डिफ़ॉल्ट: "ऑटो"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर यह 'गलत है' पर सेट है, तो WORKSPACE में नेटिव रिपॉज़िटरी के नियमों का इस्तेमाल किया जा सकता है. अगर यह 'सही है' पर सेट है, तो Starlark रिपॉज़िटरी के नियमों का इस्तेमाल करना होगा. नेटिव रिपॉज़िटरी के नियमों में local_repository, new_local_repository, local_config_platform, android_sdk_repository, और android_ndk_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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

देखें कि 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, पॉज़िटिव इंटिजर होता है. अगर <पीरियड> में <count> लगातार जीसीएस होने के बाद भी लंबे समय तक काम करने वाले स्पेस (old gen हीप) के --gc_t इससेShring_threshold से ज़्यादा प्रतिशत खाली रहता है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--experimental_worker_for_repo_fetching=<off, platform, virtual or auto> डिफ़ॉल्ट: "auto"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर यह सेट है, तो किसी कार्रवाई के लिए आउटपुट फ़ाइल को डायरेक्ट्री के तौर पर मैटीरियलाइज़ करना गड़बड़ी है. इससे सोर्स डायरेक्ट्री पर कोई असर नहीं पड़ता. https://github.com/bazelbuild/bazel/issues/18646 पर जाएं.
टैग: bazel_internal_configuration, incompatible_change

--[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 और 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_crosstool_top=<a build target label> डिफ़ॉल्ट: "//external:android/crosstool"

Android बिल्ड के लिए इस्तेमाल किए जाने वाले C++ कंपाइलर की जगह.
टैग: affects_outputs, changes_inputs, loading_and_analysis, loses_incremental_state

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

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

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

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

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

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

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

इससे उस Android SDK टूल/प्लैटफ़ॉर्म के बारे में पता चलता है जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazu_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> का डिफ़ॉल्ट मैसेज: "@bagel_tools//tools/test:coverage_support"

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

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

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

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

malloc फ़ंक्शन को पसंद के मुताबिक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में मैलक एट्रिब्यूट को बदल देती है.
टैग: 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर सही है, तो Basel को cc_common.Configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/baडेलbuild/baZ/issues/7793 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--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 API वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental

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

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

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

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

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

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

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

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

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

अगर यह सही है, तो .runfiles/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 पेयर से तय किया जा सकता है. नाम से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. वहीं, name=value पेयर से तय करने पर, वैल्यू को कॉल करने के एनवायरमेंट से अलग सेट किया जाएगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines

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

Android टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

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

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

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

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

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

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

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

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

अगर तय किया गया है, तो 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> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

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

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

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

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

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. मौजूदा बिल्ड ऐक्शन में 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

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

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

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

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

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

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

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

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

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

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

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

इस विकल्प को सेट करने से, फ़ैट APK चालू हो जाते हैं.इनमें, टारगेट किए गए सभी आर्किटेक्चर के लिए नेटिव बाइनरी होती हैं. जैसे, --fat_apk_cpu=x86,armeabi-v7a. अगर यह फ़्लैग दिया गया है, तो android_binary नियमों की डिपेंडेंसी के लिए --android_cpu को अनदेखा कर दिया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर इसे चालू किया जाता है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") बनाते हैं. लिंक, नॉन-पीआईसी लाइब्रेरी के बजाय, पहले से बनी PIC लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन के हिसाब से एक्ज़ीक्यूटेबल एक्ज़ीक्यूटेबल ("-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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

एक्ज़ीक्यूटिव टूल के लिए swiftc को पास करने के अन्य विकल्प.
टैग: 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]incompatible_use_host_features डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए --features और exec कॉन्फ़िगरेशन के लिए --host_features का इस्तेमाल करें.
टैग: changes_inputs, 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 डिफ़ॉल्ट: "सही"

अब काम नहीं करता, --inबेमेल_remove_legacy_whole_archive (ज़्यादा जानकारी के लिए, https://github.com/ba आवाज़ोंbuild/baZ/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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड ( --features=thin_lto के नीचे) को चुनिंदा तरीके से पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. option_1 से option_n, कमांड लाइन के मनमुताबिक विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, bar.o को छोड़कर //foo/ में मौजूद सभी o फ़ाइलों की LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

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

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

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

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

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

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

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

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

--run_under=<a prefix in front of command> डिफ़ॉल्ट: जानकारी देखें

'टेस्ट' और 'रन' निर्देशों के लिए, एक्सीक्यूटेबल के पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और प्रोग्राम चलाने के लिए इस्तेमाल की जाने वाली कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी ऐसे टारगेट का लेबल भी हो सकता है जिसे चलाया जा सकता है. कुछ उदाहरण: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

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

अगर सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट में शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

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

तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल स्टोर करने की जगह की जानकारी वगैरह के साथ बाइनरी को स्टैंप करें.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि --compilation_mode=fastbuild के लिए, स्ट्रिप करें.
टैग: affects_outputs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cpu वैल्यू को target_environment वैल्यू पर अपने-आप मैप करने के लिए, environment_group का इस्तेमाल करें.
टैग: changes_inputs, loading_and_analysis, experimental

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

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

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

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

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

डेक्स करने से पहले, Java 8 के बाइटकोड को डी-सुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

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

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

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

यह जांच करता है कि हर टारगेट किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट में ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की रिपोर्ट करता है
टैग: build_file_semantics

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

क्या Android बाइनरी लेवल पर, सही डीयूगरिंग की दोबारा जांच करनी है.
टैग: eagerness_to_exit, loading_and_analysis, experimental

--experimental_import_deps_checking=<off, warning or error> डिफ़ॉल्ट: "बंद है"

चालू होने पर, देखें कि aar_Import की डिपेंडेंसी पूरी हुई हैं या नहीं. ऐसा करने से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.
टैग: loading_and_analysis

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

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

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

अगर यह सुविधा चालू है और experimental_one_version_enforcement को NONE के अलावा किसी दूसरी वैल्यू पर सेट किया गया है, तो java_test टारगेट पर एक वर्शन लागू करें. इंक्रीमेंटल टेस्ट परफ़ॉर्मेंस को बेहतर बनाने के लिए इस फ़्लैग को बंद किया जा सकता है, भले ही एक वर्शन उल्लंघन के संभावित मामले मौजूद न हों.
टैग: loading_and_analysis

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

--incompatible_python_disallow_native_rules लागू करते समय इस्तेमाल करने के लिए, एक अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis

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

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

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

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

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

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

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

अगर यह सही है, तो सिस्टम में शामिल पाथ (-isystem) से मिले हेडर की जानकारी भी देनी होगी.
टैग: loading_and_analysis, eagerness_to_exit

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

इस बिल्ड के टारगेट एनवायरमेंट का एलान करता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर एनवायरमेंट तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

ऐसे विकल्प जिनसे किसी बिल्ड के हस्ताक्षर करने के आउटपुट पर असर पड़ता है:

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2"

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

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

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

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

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

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

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

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

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

अगर इसकी वैल्यू 'सही' है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट इस्तेमाल करने की अनुमति नहीं दें.
टैग: build_file_semantics, incompatible_change

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

अगर यह सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को 'सही' पर सेट करें.
टैग: build_file_semantics, incompatible_change

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

अगर यह सही है, तो पहले से मौजूद py_* नियमों का इस्तेमाल करते समय गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

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

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

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

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

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

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

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

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g. memory=10,30,60,100> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट के लिए, डिफ़ॉल्ट तौर पर उपलब्ध संसाधनों की संख्या बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई एक पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगी. अगर कॉमा लगाकर चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की संख्या को बदल देंगी. वैल्यू के तौर पर HOST_RAM/HOST_CPU का इस्तेमाल भी किया जा सकता है. इसके बाद, [-|*]<float> का इस्तेमाल किया जा सकता है. उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में बताए गए साफ़ तौर पर दिए गए संसाधनों से बदल दिया जाता है.

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

android_test को तेज़ी से बढ़ाने के लिए, साथ में dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

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

ios_test टारगेट में, मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

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

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किया जाने वाला डिवाइस, जैसे कि 'iPhone 6'. डिवाइसों की सूची पाने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

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

यह iOS का वह वर्शन है जो दौड़ने या टेस्ट करने के दौरान सिम्युलेटर पर चलता है. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को या तो नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू को बेज़ल क्लाइंट एनवायरमेंट से या name=value पेयर के ज़रिए पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel 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

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

--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_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]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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LibraryJar में मौजूद सभी क्लास हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग: action_command_lines

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

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलें डिस्क में लिखे जाने के बजाय, सीधे तौर पर रिमोट बिल्ड नोड से मेमोरी में भेजी जाएंगी.
टैग: loading_and_analysis, execution, affects_outputs, experimental

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

अगर यह विकल्प चालू है, तो Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलें, डिस्क पर लिखे जाने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में भेजी जाएंगी.
टैग: loading_and_analysis, execution, affects_outputs, experimental

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

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

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

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

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

अगर यह विकल्प चालू है, तो cc_import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis, experimental

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

इनपुट फ़ाइलों से #include लाइनों को पार्स करके, इनपुट को C/C++ कंपाइलेशन तक सीमित करना है या नहीं. यह कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस को बेहतर बनाने और बढ़ोतरी को बढ़ावा देने में मदद कर सकता है. हालांकि, इससे बिल्ड भी खराब हो सकते हैं, क्योंकि शामिल करने वाला स्कैनर, C प्रीप्रोसेसिंग सेमेंटेक्स को पूरी तरह से लागू नहीं करता. खास तौर पर, यह डाइनैमिक #include निर्देशों को समझ नहीं पाता और प्रीप्रोसेसर के कंडीशनल लॉजिक को अनदेखा कर देता है. अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी सभी समस्याओं को बंद कर दिया जाएगा.
टैग: loading_and_analysis, execution, changes_inputs

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

यह हर Jar फ़ाइल के लिए, इंडेक्स करने का ज़्यादातर काम अलग से करता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

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

अगर यह सेट है, तो clang से जनरेट की गई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis

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

टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग: execution

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

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

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

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

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

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

--flag_alias=<a 'name=value' flag alias> बार इस्तेमाल किए गए

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

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

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

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

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

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

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से 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"

अगर Baze को 'ऑटो' पर सेट किया जाता है, तो वह दोबारा टेस्ट तब करता है, जब: (1) Basel को टेस्ट या उसकी डिपेंडेंसी में बदलाव का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया है, (3) --runs_per_test की मदद से एक से ज़्यादा टेस्ट रन का अनुरोध किया गया था या(4) टेस्ट पहले फ़ेल हो गया था. 'हां' पर सेट होने पर, Bazel, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजों को कैश मेमोरी में सेव नहीं करता.

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

अगर यह सही है, तो Blaze पहले सफल रन पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ काम आता है.
टैग: affects_outputs, loading_and_analysis

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

अगर यह सही है, तो कवरेज की जांच के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा की पूरी डायरेक्ट्री फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis

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

अगर यह सही है, तो clang के लिए कवरेज से LCOV रिपोर्ट जनरेट होगी.
टैग: affects_outputs, loading_and_analysis

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

J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.

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

क्या छोटे हेडर पाथ के साथ जनरेट करना है ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग: affects_outputs

--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javabuilder"

Java कंपाइलेशन के लिए, कम क्लासपाथ की सुविधा चालू करता है.

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

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

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

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

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

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

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

अगर सही है, तो Basel, 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> डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--test_arg=<a string> बार इस्तेमाल किए गए

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

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

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

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

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

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

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

--test_sharding_strategy=<explicit, 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 का इस्तेमाल करता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

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

बिल्ड न करें, सिर्फ़ यह देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड सफलतापूर्वक पूरा हो जाता है. अगर किसी चरण को पूरा करने की ज़रूरत है, तो गड़बड़ी की सूचना दी जाती है और बिल्ड फ़ेल हो जाता है.
टैग: execution

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

अगर किसी बिल्ड के दौरान, रिमोट तरीके से एक्सीक्यूशन की प्रोसेस कम से कम एक बार तेज़ी से पूरी हुई है, तो लोकल तरीके से एक्सीक्यूशन में कितने मिलीसेकंड की देरी होनी चाहिए?
टैग: execution, host_machine_resource_optimizations

--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment> बार इस्तेमाल किए गए

यहां दी गई स्थानीय रणनीतियों का इस्तेमाल, दिए गए मेमोनेमिक के लिए किया जाता है. लागू होने वाली पहली रणनीति का इस्तेमाल किया जाता है. उदाहरण के लिए, `worker,sandboxed` ऐसी कार्रवाइयां चलाता है जो वर्कर्स की रणनीति का इस्तेमाल करके, लगातार काम करने वाले वर्कर्स के साथ-साथ सैंडबॉक्स की रणनीति का इस्तेमाल करने वाले सभी वर्कर्स के साथ काम करती हैं. अगर कोई मेमोनेमिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी मेमोनेमिक के लिए फ़ॉलबैक के तौर पर किया जाता है. अगर `experimental_local_lockfree_output` सेट है,तो फ़ॉलबैक के तौर पर इस्तेमाल होने वाली डिफ़ॉल्ट सूची`worker, sandboxed` या `worker,sandboxed,standalone` है. [mnemonic=]local_strategy[,local_strategy,...] लेता है
टैग: execution, host_machine_resource_optimizations

--dynamic_remote_strategy=<a '[name=]value1[,..,valueN]' assignment> बार इस्तेमाल किए गए

यादगार घटना के लिए, रिमोट रणनीतियों का इस्तेमाल किया जाता है. इनमें, लागू होने वाली पहली रणनीति का इस्तेमाल किया जाता है. अगर याद रखने से जुड़ी कोई जानकारी नहीं दी गई है, तो याददाश्त बढ़ाने वाली सभी चीज़ों के लिए फ़ॉलबैक के तौर पर रणनीतियों की सूची का इस्तेमाल किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `remote` होती है. इसलिए, आम तौर पर इस फ़्लैग को साफ़ तौर पर सेट करने की ज़रूरत नहीं होती. [mnemonic=]remote_strategy[,remote_strategy,...] लेता है
टैग: execution, host_machine_resource_optimizations

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

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

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

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

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

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

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

यह कंट्रोल करता है कि डाइनैमिक तरीके से लागू होने वाले फ़ंक्शन से, लोकल मशीन पर कितना लोड डाला जाए. इस फ़्लैग से यह तय होता है कि डाइनैमिक एक्ज़ीक्यूशन में हम एक साथ कितनी कार्रवाइयां शेड्यूल करेंगे. यह Blaze के हिसाब से उपलब्ध सीपीयू की संख्या पर आधारित होता है. इसे --local_cpu_resources फ़्लैग की मदद से कंट्रोल किया जा सकता है. अगर यह फ़्लैग 0 है, तो सभी कार्रवाइयां स्थानीय तौर पर तुरंत शेड्यूल की जाती हैं. अगर यह 0 से ज़्यादा है, तो स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या, उपलब्ध सीपीयू की संख्या से सीमित होती है. अगर यह वैल्यू 1 से कम है, तो लोड फैक्टर का इस्तेमाल, स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या को कम करने के लिए किया जाता है. ऐसा तब किया जाता है, जब शेड्यूल होने की प्रतीक्षा में कार्रवाइयों की संख्या ज़्यादा हो. इससे साफ़ बिल्ड केस में लोकल मशीन पर लोड कम हो जाता है, जहां लोकल मशीन ज़्यादा योगदान नहीं देती.
टैग: execution, host_machine_resource_optimizations

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

अगर यह वैल्यू >0 है, तो इसका मतलब है कि रीमोट टाइम आउट से बचने के लिए, डाइनैमिक तौर पर चलने वाली कार्रवाई को स्थानीय तौर पर लागू करने से पहले, उसे सिर्फ़ रीमोट तौर पर चलाया जाना चाहिए. इससे, रिमोट से चलाए जाने वाले सिस्टम में कुछ समस्याएं छिप सकती हैं. रिमोट से चलाए जाने से जुड़ी समस्याओं को मॉनिटर किए बिना, इसे चालू न करें.
टैग: execution, host_machine_resource_optimizations

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

Docker पर आधारित सैंडबॉक्सिंग की सुविधा चालू करें. अगर Docker इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं पड़ेगा.
टैग: execution

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

अगर इसे 'सही है' पर सेट किया जाता है, तो reuse_sandbox_directories के लिए स्टैश किए गए सैंडबॉक्स के कॉन्टेंट को मेमोरी में ट्रैक किया जाएगा. इससे, दोबारा इस्तेमाल के दौरान ज़रूरी I/O की मात्रा कम हो जाती है. बिल्ड के हिसाब से, इस फ़्लैग से वॉल टाइम बेहतर हो सकता है. बिल्ड के आधार पर, यह फ़्लैग काफ़ी ज़्यादा मेमोरी का इस्तेमाल कर सकता है.
टैग: host_machine_resource_optimizations, execution

--experimental_sandbox_async_tree_delete_idle_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "4"

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

--experimental_sandbox_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0"

अगर यह वैल्यू 0 से ज़्यादा है, तो हर Linux सैंडबॉक्स में तय मेमोरी (एमबी में) ही इस्तेमाल की जा सकेगी. इसके लिए, cgroups v1 या v2 की ज़रूरत होती है. साथ ही, उपयोगकर्ताओं के पास cgroups डायरेक्ट्री के लिए अनुमतियां होनी चाहिए.
टैग: execution

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

अगर यह विकल्प चालू है, तो वर्कर मेमोरी का दबाव ज़्यादा होने पर, वर्कर पूल छोटा हो सकता है. यह फ़्लैग सिर्फ़ तब काम करता है, जब experimental_total_worker_memory_limit_mb फ़्लैग चालू हो.
टैग: execution, host_machine_resource_optimizations

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

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

--experimental_total_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0"

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

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

अगर नीति को 'सही है' पर सेट किया जाता है, तो रूट को माउंट न करें. सिर्फ़ sandbox_add_माउंट_पेयर की मदद से दी गई चीज़ों को ही माउंट करें. इनपुट फ़ाइलों को सैंडबॉक्स से लिंक करने के बजाय, सैंडबॉक्स में हार्डलिंक किया जाएगा. अगर ऐक्शन इनपुट फ़ाइलें सैंडबॉक्स से अलग फ़ाइल सिस्टम में मौजूद हैं, तो इनपुट फ़ाइलों को कॉपी किया जाएगा.
टैग: 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> डिफ़ॉल्ट: "BagelSandbox.exe"

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

--experimental_worker_allowlist=<comma-separated set of options> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

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

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

--experimental_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0"

अगर यह सीमा शून्य से ज़्यादा है, तो वर्कर्स की मेमोरी इस्तेमाल करने की सीमा से ज़्यादा इस्तेमाल होने पर, वर्कर्स को बंद किया जा सकता है. अगर इसे डाइनैमिक एक्ज़ीक्यूशन और `--experimental_ Dynamic_ignore_local_signals=9` के साथ इस्तेमाल नहीं किया जाता है, तो इससे आपके बिल्ड को क्रैश हो सकता है.
टैग: execution, host_machine_resource_optimizations

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

वर्कर की मेट्रिक इकट्ठा करने और उसे हटाने की कोशिश करने के बीच का अंतराल. परफ़ॉर्मेंस की वजह से, यह समय एक सेकंड से कम नहीं होना चाहिए.
टैग: execution, host_machine_resource_optimizations

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

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

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

अगर यह सेटिंग चालू है, तो वर्कर को बेहतर सुरक्षा वाले सैंडबॉक्स में चलाया जाता है. हालांकि, ऐसा तब ही किया जाता है, जब लागू करने की अनुमति हो.
टैग: execution

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

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

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

टेंन्चर स्पेस के इस्तेमाल का प्रतिशत (0-100). इस प्रतिशत से ज़्यादा होने पर, GcThrashingDetector मेमोरी प्रेशर इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से तय करता है. अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

--genrule_strategy=<comma-separated list of options> डिफ़ॉल्ट: ""

genrules को लागू करने का तरीका बताएं. इस फ़्लैग को बंद कर दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरेटिव नियमों को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution

--high_priority_workers=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कोई कार्रवाई नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग: execution

--[no]incompatible_remote_dangling_symlinks डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो रिमोट या डिस्क कैश मेमोरी में अपलोड किए गए सिमलिंक, डेगल हो सकते हैं.
टैग: execution, incompatible_change

--[no]incompatible_remote_symlinks डिफ़ॉल्ट: "सही"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Baze हमेशा सिमलिंक अपलोड करेगा. जैसे, रिमोट या डिस्क कैश मेमोरी में. अगर ऐसा नहीं किया जाता है, तो सिर्फ़ ऐसे रिलेटिव सिंबललिंक अपलोड किए जाएंगे जो किसी फ़ाइल या डायरेक्ट्री पर ले जाते हैं.
टैग: execution, incompatible_change

--[no]incompatible_sandbox_hermetic_tmp डिफ़ॉल्ट: "सही"

अगर नीति को 'सही है' पर सेट किया जाता है, तो हर Linux सैंडबॉक्स में एक खाली डायरेक्ट्री होगी, जो होस्ट फ़ाइल सिस्टम के साथ /tmp शेयर करने के बजाय, /tmp के तौर पर माउंट की जाएगी. सभी सैंडबॉक्स में होस्ट का/tmp देखने के लिए, --sandbox_add_mount_pair=/tmp का इस्तेमाल करें.
टैग: execution

--[no]internal_spawn_scheduler डिफ़ॉल्ट: "गलत"

प्लेसहोल्डर का विकल्प सेट करना, ताकि हम Blaze में यह बता सकें कि स्पॉन्स शेड्यूलर चालू था या नहीं.
टैग: execution, host_machine_resource_optimizations

--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> [-j] डिफ़ॉल्ट: "ऑटो"

एक साथ चलने वाली जॉब की संख्या. यह एक पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल करता है. इसके बाद, वैकल्पिक रूप से कोई कार्रवाई ([-|*]<float>) ली जाती है, जैसे कि. "auto", "HOST_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. 2500 से ज़्यादा वैल्यू से, मेमोरी से जुड़ी समस्याएं हो सकती हैं. "auto", होस्ट के संसाधनों के आधार पर, डिफ़ॉल्ट तौर पर सही अनुमान लगाता है.
टैग: host_machine_resource_optimizations, execution

--[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"> डिफ़ॉल्ट: "ऑटो"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "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 से सेट की गई वैल्यू को बदल देता है. साथ ही, अगर Genrule के साथ mnemonic का इस्तेमाल किया जाता है, तो --genrule_strategy से सेट की गई वैल्यू को भी बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazu.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्पैन ऐक्शन को लागू करने के लिए, किस स्पैन रणनीति का इस्तेमाल किया जाना चाहिए. यह रणनीति, किसी खास regex_filter से मैच करने वाली जानकारी के लिए तय की जाती है. regex_filter मैचिंग के बारे में जानकारी के लिए, --per_file_copt देखें. ब्यौरे से मैच करने वाले आखिरी रेगुलर एक्सप्रेशन फ़िल्टर का इस्तेमाल किया जाता है. यह विकल्प, रणनीति तय करने के लिए अन्य फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि अगर ऐक्शन के ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो लोकल रणनीति का इस्तेमाल करके ऐक्शन चलाएं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed 'कंपाइलिंग //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा, लेकिन ऑर्डर को उलटा करने पर वह 'सैंडबॉक्स' के साथ चल जाएगा.
टैग: execution

--worker_extra_flag=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एक और कमांड-फ़्लैग, जो कर्मचारी की प्रोसेस को दिया जाएगा. इसके अलावा, उसे --persistent_worker के साथ-साथ, याद रखने के लिए इस्तेमाल होने वाले बटन (जैसे कि --worker_extra_flag=JaYC=--debug) को भेजा जाएगा.
टैग: execution, host_machine_resource_optimizations

--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> एक से ज़्यादा बार इस्तेमाल किए जाने पर

'वर्कर' रणनीति का इस्तेमाल करने पर, हर तरह के पर्सिस्टेंट वर्कर्स के कितने इंस्टेंस लॉन्च किए जा सकते हैं. हर मेनिमोनिक के लिए अलग वैल्यू देने के लिए, [name=value] के तौर पर तय किया जा सकता है. यह सीमा, वर्कर्स की कुंजियों पर आधारित होती है. इन कुंजियों को मेमोनिक के आधार पर अलग-अलग किया जाता है. साथ ही, स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में हर मेमोनिक के लिए, इस फ़्लैग में बताई गई संख्या से ज़्यादा वर्कर्स हो सकते हैं. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 'auto', मशीन की क्षमता के आधार पर डिफ़ॉल्ट रूप से सही साइज़ का हिसाब लगाता है. "=value", बिना बताए गए मेमोनिक के लिए डिफ़ॉल्ट सेट करता है.
टैग: execution, host_machine_resource_optimizations

--worker_max_multiplex_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> एक से ज़्यादा बार इस्तेमाल किए जाने पर

--worker_multiplex के साथ 'worker' रणनीति का इस्तेमाल करने पर, मल्टीप्लेक्स वर्कर्स प्रोसेस को एक साथ कितने वर्क रिक्वेस्ट मिल सकते हैं. हर स्नेमोनिक के लिए अलग-अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर बताया जा सकता है. यह सीमा वर्कर कुंजियों पर आधारित होती है, जिन्हें स्नेमनी के आधार पर अलग-अलग किया जाता है. साथ ही, यह स्टार्टअप फ़्लैग और पर्यावरण के आधार पर भी तय होता है. इसलिए, कुछ मामलों में हर याद में, इस फ़्लैग की तुलना में ज़्यादा वर्कर हो सकते हैं. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 'auto', मशीन की क्षमता के आधार पर डिफ़ॉल्ट रूप से सही साइज़ का हिसाब लगाता है. "=value", बिना बताए गए मेमोनिक के लिए डिफ़ॉल्ट सेट करता है.
टैग: execution, host_machine_resource_optimizations

--[no]worker_multiplex डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो वर्कर्स मल्टीप्लेक्सिंग का इस्तेमाल करेंगे. हालांकि, इसके लिए ज़रूरी है कि वर्कर्स में मल्टीप्लेक्सिंग की सुविधा काम करती हो.
टैग: execution, host_machine_resource_optimizations

--[no]worker_quit_after_build डिफ़ॉल्ट: "गलत"

इस विकल्प के चालू होने पर, बिल्ड पूरा होने के बाद सभी वर्कर्स बंद हो जाते हैं.
टैग: execution, host_machine_resource_optimizations

--[no]worker_sandboxing डिफ़ॉल्ट: "गलत"

अगर इसे चालू किया जाता है, तो सैंडबॉक्स की मदद से वर्कर एक्ज़ीक्यूट किए जाएंगे.
टैग: execution

--[no]worker_verbose डिफ़ॉल्ट: "गलत"

अगर यह चालू है, तो वर्कर्स के शुरू होने, बंद होने वगैरह पर ज़्यादा जानकारी वाले मैसेज प्रिंट करता है

ऐक्शन को लागू करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--target_platform_fallback=<a string> डिफ़ॉल्ट: ""

इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं पड़ता.
टैग: affects_outputs, changes_inputs, loading_and_analysis

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]build डिफ़ॉल्ट: "सही"

बिल्ड को लागू करें; यह सामान्य तरीका है. --nobuild की वैल्यू तय करने से, बिल्ड ऐक्शन को पूरा करने से पहले बिल्ड रुक जाता है. अगर पैकेज लोड होने और उसके विश्लेषण के चरण पूरे होने पर कोई वैल्यू नहीं मिलती है, तो इस मोड की मदद से इन फ़ेज़ की टेस्टिंग की जा सकती है.
टैग: execution, affects_outputs

--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "गलत"

क्या टेस्ट के साथ पैरलल तरीके से काम करने के लिए, आसपेक्ट का इस्तेमाल करके पुष्टि करने की कार्रवाइयां चलानी हैं.
टैग: execution, affects_outputs

--output_groups=<comma-separated list of options> बार इस्तेमाल किए गए

कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इनमें से हर नाम के आगे + या - लगाने का विकल्प होता है. + लगाने पर, ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ दिया जाता है. वहीं, - लगाने पर, ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप के नाम में प्रीफ़िक्स नहीं जोड़ा गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हटा दिया जाता है. उदाहरण के लिए, --output_groups=+foo,+bar, डिफ़ॉल्ट सेट, foo, और bar का यूनियन बनाता है. वहीं, --output_groups=foo,bar, डिफ़ॉल्ट सेट को बदल देता है, ताकि सिर्फ़ foo और bar बनाए जाएं.
टैग: execution, affects_outputs

--[no]run_validations डिफ़ॉल्ट: "सही"

बिल्ड के हिस्से के तौर पर, पुष्टि करने वाली कार्रवाइयां चलानी हैं या नहीं. https://baZ.build/extending/rules#validation_action
टैग: execution, affects_outputs

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, तय किए गए आउटपुट को कॉन्फ़िगर कर सकता है. इससे, आउटपुट मौजूद होने पर, उसकी वैल्यू पर असर पड़ता है:

--aspects=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टॉप-लेवल टारगेट पर लागू किए जाने वाले आसपेक्ट की सूची, जिसमें कॉमा लगाकर आसपेक्ट को अलग किया गया है. अगर सूची में, किसी एस्पेक्ट some_aspect के लिए, ज़रूरी एस्पेक्ट की सेवा देने वाली कंपनियों की जानकारी, required_aspect_providers के ज़रिए दी गई है, तो some_aspect उन सभी एस्पेक्ट के बाद चलेगा जिनके लिए विज्ञापन में बताई गई कंपनियां, some_aspect के लिए ज़रूरी एस्पेक्ट की सेवा देने वाली कंपनियों की ज़रूरी शर्तें पूरी करती हैं. इसके अलावा, some_aspect, ज़रूरी एट्रिब्यूट की वैल्यू देने के बाद ही चलेगा. इसके बाद, some_aspect के पास उन एस्पेक्ट के प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, जैसे कि '//tools:my_def.bzl%my_aspect'. इसमें 'my_aspect' किसी फ़ाइल टूल/my_def.bzl से लिया गया टॉप-लेवल मान है

--bep_maximum_open_remote_upload_files=<an integer> डिफ़ॉल्ट: "-1"

बीईपी आर्टफ़ैक्ट अपलोड करने के दौरान, ज़्यादा से ज़्यादा कितनी फ़ाइलें खोली जा सकती हैं.
टैग: affects_outputs

--[no]experimental_convenience_symlinks डिफ़ॉल्ट: "normal"

इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिंक (बिल्ड के बाद वर्कस्पेस में दिखने वाले लिंक) को कैसे मैनेज किया जाएगा. संभावित वैल्यू: सामान्य (डिफ़ॉल्ट): हर तरह का सुविधाजनक सिंबललिंक बनाया या मिटाया जाएगा. यह, बिल्ड के हिसाब से तय किया जाएगा. clean: सभी सिंबललिंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: इससे सिमलिनक नहीं हटेंगे. log_only: लॉग मैसेज जनरेट करें, जैसे कि 'normal' पास किया गया हो. हालांकि, फ़ाइल सिस्टम पर कोई कार्रवाई न करें. यह टूल के लिए काम का है. ध्यान दें कि सिर्फ़ उन सिमलिंक पर असर पड़ सकता है जिनके नाम --symlink_prefix की मौजूदा वैल्यू से जनरेट किए गए हैं. प्रीफ़िक्स बदलने पर, पहले से मौजूद सिमलिंक में कोई बदलाव नहीं होगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks_bep_event डिफ़ॉल्ट: "गलत"

इस फ़्लैग से यह कंट्रोल होता है कि हम BuildEventProtocol में, बिल्ड eventConvenienceSymlinksIdentified को पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में 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' पर सेट होने पर, यह'minimal' की तरह काम करता है. हालांकि, यह लोकल मशीन पर टॉप लेवल टारगेट के आउटपुट भी डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ की समस्या है, तो दोनों विकल्पों से बिल्ड करने में लगने वाला समय काफ़ी कम हो सकता है.
टैग: affects_outputs

--remote_download_symlink_template=<a string> डिफ़ॉल्ट: ""

रिमोट बिल्ड आउटपुट को लोकल मशीन पर डाउनलोड करने के बजाय, सिंबल लिंक बनाएं. सिंबल लिंक का टारगेट, टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं. ये क्रमशः ऑब्जेक्ट के हैश और बाइट में साइज़ में बदल जाते हैं. उदाहरण के लिए, ये सिंबल लिंक किसी ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर सीएएस से ऑब्जेक्ट लोड करता है.
टैग: affects_outputs

--remote_download_toplevel

सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट को लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, --remote_download_outputs=toplevel का दूसरा नाम है.
इस तरह बड़ा होता है:
  --remote_download_outputs=toplevel

टैग: affects_outputs

--symlink_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

प्रीफ़िक्स, जो किसी भी सुविधाजनक सिमलिंक के आगे जोड़ा जाता है. ये सिमलिंक, बिल्ड के बाद बनाए जाते हैं. अगर इस एट्रिब्यूट को शामिल नहीं किया जाता है, तो डिफ़ॉल्ट वैल्यू के तौर पर, बिल्ड टूल का नाम और उसके बाद हाइफ़न दिखेगा. अगर '/' को पास कर दिया जाता है, तो कोई सिमलिंक नहीं बनाया जाता और कोई चेतावनी नहीं भेजी जाती. चेतावनी: '/' के लिए खास सुविधा जल्द ही बंद कर दी जाएगी. इसके बजाय, --experimental_convenience_symlinks=ignore का इस्तेमाल करें.
टैग: affects_outputs

ऐसे विकल्प जिनसे इस बात पर असर पड़ता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]experimental_docker_privileged डिफ़ॉल्ट: "गलत"

अगर इसे चालू किया जाता है, तो कार्रवाइयां करते समय Basel, खास अधिकार वाले फ़्लैग को 'docker Run' के लिए पास करेगा. इसकी ज़रूरत आपके बिल्ड के लिए पड़ सकती है, लेकिन इससे हरमैटिटी कम हो सकती है.
टैग: execution

--[no]experimental_sandboxfs_map_symlink_targets डिफ़ॉल्ट: "गलत"

कोई कार्रवाई नहीं करना
टैग: host_machine_resource_optimizations, execution

--[no]incompatible_legacy_local_fallback डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स की गई रणनीति से लोकल रणनीति पर, लेगसी इंप्लिसिट फ़ॉलबैक चालू हो जाता है. यह फ़्लैग डिफ़ॉल्ट रूप से 'गलत' पर सेट हो जाएगा और फिर 'नो-ऑप' बन जाएगा. इसके बजाय, फ़ॉलबैक कॉन्फ़िगर करने के लिए --strategy, --spawn_strategy, या -- Dynamic_local_strategy का इस्तेमाल करें.
टैग: execution, incompatible_change

--sandbox_add_mount_pair=<a single path or a 'source:target' pair> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सैंडबॉक्स में माउंट करने के लिए, अतिरिक्त पाथ पेयर जोड़ें.
टैग: execution

--sandbox_block_path=<a string> बार इस्तेमाल किए गए

सैंडबॉक्स की गई कार्रवाइयों के लिए, इस पाथ को ऐक्सेस करने की अनुमति न दें.
टैग: execution

--[no]sandbox_default_allow_network डिफ़ॉल्ट: "सही"

कार्रवाइयों के लिए डिफ़ॉल्ट रूप से नेटवर्क का ऐक्सेस दें. ऐसा हो सकता है कि यह सैंडबॉक्स लागू करने के सभी तरीकों के साथ काम न करे.
टैग: execution

--[no]sandbox_fake_hostname डिफ़ॉल्ट: "गलत"

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग: execution

--[no]sandbox_fake_username डिफ़ॉल्ट: "गलत"

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'कोई नहीं' में बदलें.
टैग: execution

--sandbox_writable_path=<a string> बार इस्तेमाल किए गए

सैंडबॉक्स की गई कार्रवाइयों के लिए, किसी मौजूदा डायरेक्ट्री को सैंडबॉक्स में लिखें (अगर सैंडबॉक्सिंग की सुविधा काम करती है, तो उसे अनदेखा कर दिया जाता है).
टैग: execution

इस विकल्प का असर, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग सही है, तो config_setting अन्य सभी नियमों की तरह ही, 'किसको दिखे' लॉजिक का ही पालन करता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]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> बार इस्तेमाल किए गए

जांच में कोई गड़बड़ी होने पर, हर जांच को तय की गई संख्या तक फिर से इस्तेमाल करने की कोशिश की जाएगी. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश करनी पड़ती है उन्हें टेस्ट की खास जानकारी में 'फ़्लैकी' के तौर पर मार्क किया जाता है. आम तौर पर बताया गया मान सिर्फ़ एक पूर्णांक या 'डिफ़ॉल्ट' स्ट्रिंग होती है. अगर यह एक पूर्णांक है, तो सभी टेस्ट 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"

एक साथ चलाने के लिए लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. यह एक पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल करता है. इसके बाद, वैकल्पिक रूप से कोई कार्रवाई ([-|*]<float>) ली जाती है, जैसे कि. "auto", "Host_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, एक साथ चलाए जाने के लिए लोकल टेस्ट जॉब की संख्या को सीमित कर देगा. --jobs की वैल्यू से ज़्यादा वैल्यू सेट करने का कोई फ़ायदा नहीं है.
टैग: execution

--[no]test_keep_going डिफ़ॉल्ट: "सही"

अगर यह विकल्प बंद है, तो कोई भी टेस्ट पास न होने पर पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट चलाए जाते हैं, भले ही कुछ टेस्ट पास न हों.
टैग: execution

--test_strategy=<a string> डिफ़ॉल्ट: ""

यह बताता है कि टेस्ट करते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution

--test_tmpdir=<a path> डिफ़ॉल्ट: जानकारी देखें

'bazel test' के इस्तेमाल के लिए, बेस टेम्पररी डायरेक्ट्री तय करता है.

क्वेरी के आउटपुट और सिमेंटिक्स से जुड़े विकल्प:

--[no]experimental_parallel_aquery_output डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं की जाती.

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> बार इस्तेमाल किए गए

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं. हालांकि, ऐसा तब ही होगा, जब वे NonRegistryOverride से न आते हों. ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन के लिए भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, हमारा सुझाव है कि ऐसा न करें.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: गड़बड़ी को ठीक करने के लिए उसे 'गड़बड़ी'', जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: 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` है और बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल को अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या उसमें लिखने के लिए `बंद` करें.
टैग: 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

ऐसे विकल्प जो बिल्ड के समय को ऑप्टिमाइज़ करने के लिए ट्रिगर करते हैं:

--cache_computed_file_digests=<a long integer> डिफ़ॉल्ट: "50000"

अगर यह वैल्यू 0 से ज़्यादा है, तो Bazel को मेमोरी में फ़ाइल डाइजेस्ट को कैश मेमोरी में सेव करने के लिए कॉन्फ़िगर किया जाता है. ऐसा करने पर, हर बार डिस्क से डाइजेस्ट को फिर से कैलकुलेट करने की ज़रूरत नहीं पड़ती. इसकी वैल्यू को 0 पर सेट करने से यह पक्का होता है कि फ़ाइल में किए गए सभी बदलावों को मेटाडेटा में शामिल किया गया है. अगर यह संख्या 0 नहीं है, तो यह कैश मेमोरी के साइज़ को दिखाती है. यह साइज़, कैश मेमोरी में सेव की जाने वाली फ़ाइल डाइजेस्ट की संख्या के बराबर होता है.

--experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers> डिफ़ॉल्ट: जानकारी देखें

OS सिग्नल नंबर की सूची लेता है. अगर डाइनैमिक तरीके से लागू होने वाली प्रोसेस की किसी लोकल शाखा को इनमें से किसी भी सिग्नल से बंद कर दिया जाता है, तो रिमोट शाखा को पूरा होने की अनुमति दी जाएगी. लगातार काम करने वाले लोगों के लिए, यह सिर्फ़ उन सिग्नल पर असर डालता है जो काम करने की प्रोसेस को खत्म करते हैं.
टैग: execution

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_CPUS"

Baज़ल के लिए उपलब्ध लोकल सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें, ताकि बिल्ड ऐक्शन पर स्थानीय तौर पर काम करने पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "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"

Bazel के लिए, स्थानीय होस्ट की कुल रैम (एमबी में) को साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_RAM" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_RAM*.5, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, ("HOST_RAM*.67") के लिए, Bazel उपलब्ध रैम की मात्रा का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और उसका 67% इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations

--local_resources=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Bazel के लिए उपलब्ध संसाधनों की संख्या सेट करें. किसी असाइनमेंट को फ़्लोट या Host_RAM/Host_CPUS पर ले जाता है. इसके बाद, [-|*]<float> का इस्तेमाल किया जाता है (उदाहरण के लिए, उपलब्ध रैम का आधा इस्तेमाल करने के लिए, मेमोरी=Host_RAM*.5). अलग-अलग तरह के संसाधनों की जानकारी देने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. Bazel, उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों की संख्या को सीमित कर देगा. टेस्ट में "संसाधन:<संसाधन का नाम>:<amount>" फ़ॉर्मैट का टैग इस्तेमाल करके, यह बताया जा सकता है कि उन्हें कितने संसाधनों की ज़रूरत है. --local_{cpu|ram|extra}_resources के ज़रिए बताए गए संसाधनों को बदलता है.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Basel को पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो पूरा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. यह सब शुरू करने पर कई बार ऐसा होगा. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन किए गए हेप के प्रतिशत थ्रेशोल्ड से ज़्यादा होने पर, Skyframe स्टेटस नहीं छोड़ा जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि रिटेंन की गई हेप का प्रतिशत, --skyframe_high_water_mark_threshold सेट की गई सीमा से ज़्यादा है, तो मामूली GC इवेंट होने पर, वह हर बार इस सीमा तक अनावश्य Skyframe स्टेटस को छोड़ देगा. डिफ़ॉल्ट रूप से, यह Integer.MAX_VALUE पर सेट होती है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, मामूली जीसी इवेंट होने पर Skyframe की स्थिति को ड्रॉप नहीं किया जाएगा. साथ ही, रीटेन किए गए हेप के प्रतिशत के थ्रेशोल्ड को पार करने पर भी ऐसा नहीं किया जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इसे ट्वीट करने से आप GC थ्रैशिंग के वॉल टाइम प्रभाव को कम कर सकते हैं, जब GC थ्रैशिंग (i) इस अस्थायी स्थिति की मेमोरी के उपयोग के कारण होती है और (ii) स्थिति की आवश्यकता होने पर राज्य को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]debug_spawn_scheduler डिफ़ॉल्ट: "गलत"

--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत"

TargetSummary इवेंट पब्लिश करने हैं या नहीं.

--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs

--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में रिलेटिव फ़ाइलसेट के लिंक को पूरी तरह से हल करें. इसके लिए, --experimental_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs

--experimental_build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4"

Bazel को बिल्ड इवेंट को अपलोड करने की कोशिश कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s"

बीईपी फ़ाइल अपलोड न होने पर, एक्सपोनेन्शियल बैकऑफ़ बार-बार कोशिश करने के बाद, शुरुआती समय में कम से कम देरी हो सकती है. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration

--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: जानकारी देखें

बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुनता है.
टैग: affects_outputs

--[no]experimental_collect_local_sandbox_action_metrics डिफ़ॉल्ट: "सही"

अब काम नहीं करता है.
टैग: execution

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

कमांड के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल रिकॉर्ड करता है. आर्ग्युमेंट के तौर पर, प्रोफ़ाइलिंग इवेंट का कोई एक टाइप (सीपीयू, वॉल, ऐलोक या लॉक) दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम पर बनाई गई फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_docker_verbose डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो Bazel, Docker सैंडबॉक्स की रणनीति के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करेगा.
टैग: execution

--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "गलत"

अगर पैरामीटर फ़ाइलों को मेटालाइज़ किया जा रहा है, तो डिस्क में सीधे लिखकर ऐसा करें.
टैग: execution

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

अगर यह वैल्यू खाली नहीं है, तो Starlark की वैल्यू लिखें. इसमें, Starlark के उन सभी रिपॉज़िटरी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "गलत"

क्या रन बिल्ड इवेंट में कमांड-लाइन के बचे हुए हिस्से को शामिल करना है, जिसमें बचा हुआ हिस्सा हो सकता है. डिफ़ॉल्ट रूप से, बचे हुए को रन कमांड बिल्ड इवेंट में शामिल नहीं किया जाता, जिसमें बचा हुआ हिस्सा हो सकता है.
टैग: affects_outputs

--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत"

लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs

--explain=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इससे बिल्ड सिस्टम, बिल्ड के हर चरण के बारे में जानकारी देता है. जानकारी, बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग: affects_outputs

--[no]ignore_unsupported_sandboxing डिफ़ॉल्ट: "गलत"

अगर इस सिस्टम पर सैंडबॉक्स में चलाने की सुविधा काम नहीं करती, तो चेतावनी न दिखाएं.
टैग: terminal_output

--[no]legacy_important_outputs डिफ़ॉल्ट: "सही"

TargetComplete इवेंट में, लेगसी important_outputs फ़ील्ड जनरेट होने से रोकने के लिए, इसका इस्तेमाल करें. Bazel से ResultStore इंटिग्रेशन के लिए, important_outputs ज़रूरी है.
टैग: affects_outputs

--[no]materialize_param_files डिफ़ॉल्ट: "गलत"

रिमोट ऐक्शन एक्सीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें लिखता है. यह कार्रवाई को डीबग करने के दौरान काम का होता है. --subcommands और --verbose_failures से यह पता चलता है.
टैग: execution

--max_config_changes_to_show=<an integer> डिफ़ॉल्ट: "3"

बिल्ड के विकल्पों में बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नामों की तय संख्या तक दिखाता है. अगर दी गई संख्या -1 है, तो बदले गए सभी विकल्प दिखेंगे.
टैग: terminal_output

--max_test_output_bytes=<an integer> डिफ़ॉल्ट: "-1"

यह हर टेस्ट लॉग का ज़्यादा से ज़्यादा साइज़ तय करता है. यह साइज़ तब जनरेट किया जा सकता है, जब --test_output 'errors' या 'all' हो. इससे टेस्ट आउटपुट में बहुत ज़्यादा शोर होने से बचने में मदद मिलती है. टेस्ट हेडर, लॉग साइज़ में शामिल होता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट या तो पूरा होता है या नहीं होता.
टैग: test_runner, terminal_output, execution

--output_filter=<a valid Java regular expression> डिफ़ॉल्ट: जानकारी देखें

यह सिर्फ़ ऐसे नियमों के लिए चेतावनियां और कार्रवाई का आउटपुट दिखाता है जिनका नाम, दिए गए रेगुलर एक्सप्रेशन से मेल खाता है.
टैग: affects_outputs

--progress_report_interval=<an integer in 0-3600 range> डिफ़ॉल्ट: "0"

अभी चल रहे जॉब की रिपोर्ट के बीच इंतज़ार करने के लिए सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद, फिर 30 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, प्रोग्रेस हर मिनट में एक बार रिपोर्ट की जाएगी. --curses चालू होने पर, प्रोग्रेस हर सेकंड रिपोर्ट की जाती है.
टैग: affects_outputs

--remote_print_execution_messages=<failure, success or all> डिफ़ॉल्ट: "failure"

चुनें कि रिमोट तौर पर एक्ज़ीक्यूशन वाले मैसेज कब प्रिंट करने हैं. मान्य वैल्यू: सिर्फ़ गड़बड़ियों पर प्रिंट करने के लिए `failure`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए `success`, और हमेशा प्रिंट करने के लिए `all`.
टैग: terminal_output

--[no]sandbox_debug डिफ़ॉल्ट: "गलत"

इससे सैंडबॉक्स की सुविधा के लिए, डीबग करने की सुविधाएं चालू हो जाती हैं. इसमें दो चीज़ें शामिल हैं: पहली, बिल्ड के बाद सैंडबॉक्स रूट की सामग्री में कोई बदलाव नहीं किया जाता; और दूसरा, एक्ज़ीक्यूशन के बाद, डीबग करने की ज़्यादा जानकारी प्रिंट करता है. इससे Baज़र या Starlark के नियमों के डेवलपर को, इनपुट फ़ाइलें मौजूद न होने वगैरह की वजह से डीबग करने में मदद मिल सकती है.
टैग: terminal_output

--show_result=<an integer> डिफ़ॉल्ट: "1"

बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए बताएं कि उसे अप-टू-डेट किया गया था या नहीं. अगर हां, तो बनाई गई आउटपुट फ़ाइलों की सूची भी बताएं. प्रिंट की गई फ़ाइलें, शेल में कॉपी करके चिपकाने के लिए आसान स्ट्रिंग होती हैं, ताकि उन्हें चलाया जा सके. इस विकल्प के लिए, पूर्णांक आर्ग्युमेंट की ज़रूरत होती है. यह टारगेट की थ्रेशोल्ड संख्या होती है. इस थ्रेशोल्ड से ज़्यादा होने पर, नतीजों की जानकारी नहीं छपी जाती. इस प्रकार, शून्य संदेश को छिपा देता है और MAX_INT के कारण परिणाम को हमेशा प्रिंट किया जाता है. डिफ़ॉल्ट रूप से, एक होता है. अगर किसी टारगेट के लिए कुछ भी नहीं बनाया गया है, तो आउटपुट को थ्रेशोल्ड के तहत रखने के लिए, उसके नतीजों को हटाया जा सकता है.
टैग: affects_outputs

--[no]subcommands [-s] डिफ़ॉल्ट: "false"

बिल्ड के दौरान चलाए गए सब-कमांड दिखाएं. मिलते-जुलते फ़्लैग: --execution_log_json_file, --execution_log_binary_file (टूल के हिसाब से फ़ॉर्मैट में, सब-कमांड को फ़ाइल में लॉग करने के लिए).
टैग: terminal_output

--test_output=<summary, errors, all or streamed> डिफ़ॉल्ट: "खास जानकारी"

पसंदीदा आउटपुट मोड के बारे में बताता है. सिर्फ़ टेस्ट की स्थिति की खास जानकारी दिखाने के लिए 'खास जानकारी', टेस्ट पास न होने पर टेस्ट लॉग भी प्रिंट करने के लिए 'गड़बड़ियां', सभी टेस्ट के लॉग प्रिंट करने के लिए 'सभी', और सभी टेस्ट के लॉग रीयल टाइम में दिखाने के लिए 'स्ट्रीम की गई'. इससे, --test_strategy की वैल्यू के बावजूद, टेस्ट को एक बार में एक करके स्थानीय तौर पर चलाया जाएगा.
टैग: test_runner, terminal_output, execution

--test_summary=<short, terse, detailed, none or testcase> डिफ़ॉल्ट: "short"

यह टेस्ट की खास जानकारी के लिए, मनचाहा फ़ॉर्मैट तय करता है. मान्य वैल्यू: 'short', सिर्फ़ चलाए गए टेस्ट की जानकारी प्रिंट करने के लिए, 'terse', सिर्फ़ उन टेस्ट की जानकारी प्रिंट करने के लिए जो पूरे नहीं हुए, 'detailed', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'testcase', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'none', खास जानकारी को हटाने के लिए.
टैग: terminal_output

--[no]verbose_explanations डिफ़ॉल्ट: "गलत"

--explain चालू होने पर, दी गई जानकारी को ज़्यादा शब्दों में दिखाता है. अगर --explain चालू नहीं है, तो इसका कोई असर नहीं पड़ता.
टैग: affects_outputs

--[no]verbose_failures डिफ़ॉल्ट: "गलत"

अगर कोई निर्देश काम नहीं करता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

बेज़ल कमांड के लिए, जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--aspects_parameters=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कमांड-लाइन के आसपेक्ट पैरामीटर की वैल्यू तय करता है. हर पैरामीटर की वैल्यू, <param_name>=<param_value> के ज़रिए तय की जाती है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param', --aspects सूची में किसी पहलू का पैरामीटर है या सूची में किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. हालांकि, एक ही पैरामीटर के लिए एक से ज़्यादा बार वैल्यू असाइन नहीं की जा सकती.
टैग: loading_and_analysis

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय, बताई गई ठीक की गई फ़ाइल को पढ़ें
टैग: changes_inputs

--target_pattern_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो बिल्ड, कमांड लाइन के बजाय यहां बताई गई फ़ाइल से पैटर्न पढ़ेगा. यहां फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न भी बताना गलत है.
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_circuit_breaker_strategy=<failure> डिफ़ॉल्ट: जानकारी देखें

यह सर्किट ब्रेकर के इस्तेमाल की रणनीति के बारे में बताता है. उपलब्ध रणनीतियां "फ़ेल" हैं. विकल्प के लिए अमान्य वैल्यू देने पर, विकल्प के लिए सेट किया गया व्यवहार नहीं दिखता.
टैग: execution

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--[no]experimental_guard_against_concurrent_changes डिफ़ॉल्ट: "गलत"

किसी कार्रवाई की इनपुट फ़ाइलों को रिमोट कैश में अपलोड करने से पहले, उसके ctime की जांच बंद करने के लिए इसे बंद करें. कुछ मामलों में, Linux kernel फ़ाइलों को लिखने में देरी कर सकता है. इस वजह से, गलत नतीजे मिल सकते हैं.

--[no]experimental_remote_cache_async डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो स्पैन के हिस्से के तौर पर होने के बजाय, रिमोट कैश मेमोरी का I/O बैकग्राउंड में होगा.

--experimental_remote_cache_compression_threshold=<an integer> डिफ़ॉल्ट: "0"

zstd की मदद से, ब्लॉब को कंप्रेस/डीकंप्रेस करने के लिए ज़रूरी कम से कम साइज़. --remote_cache_compression सेट होने तक, यह विकल्प काम नहीं करता.

--experimental_remote_cache_eviction_retries=<an integer> डिफ़ॉल्ट: "0"

अगर बिल्ड में, रिमोट कैश मेमोरी से जुड़ी कोई ऐसी गड़बड़ी आती है जिसकी वजह से बिल्ड पूरा नहीं हो पाता, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. उदाहरण के लिए, जब आर्टफ़ैक्ट को रिमोट कैश मेमोरी से हटाया जाता है या कैश मेमोरी में कुछ गड़बड़ी होती है, तब यह लागू होता है. शून्य से ज़्यादा की वैल्यू से, --incompatible_remote_use_new_exit_code_for_lost_inputs को अपने-आप 'सही' पर सेट कर दिया जाएगा. हर कोशिश के लिए एक नया शुरू करने का आईडी जनरेट किया जाएगा. अगर आपने invocation आईडी जनरेट किया है और उसे --invocation_id के साथ Bazel को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, फ़्लैग --inaffiliate_remote_use_new_exit_code_for_lost_inputs सेट करें और एग्ज़िट कोड 39 देखें.
टैग: execution

--[no]experimental_remote_cache_lease_extension डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैश मेमोरी में समय-समय पर `FindMissingBlobs` कॉल भेजकर, बिल्ड के दौरान रिमोट ऐक्शन के आउटपुट के लिए लीज़ को बढ़ा देगा. फ़्रीक्वेंसी, `--experimental_remote_cache_ttl` की वैल्यू पर आधारित होती है.

--experimental_remote_cache_ttl=<An immutable length of time.> डिफ़ॉल्ट: "3h"

हाल ही में रेफ़र किए गए डाइजेस्ट के बाद, रिमोट कैश मेमोरी में कम से कम ब्लॉब की गारंटी मिलती है. जैसे, Actionनतीजे या FindmissingBlobs से. Basel, BLOB के TTL (टीटीएल) के आधार पर कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, इंक्रीमेंटल बिल्ड में GetActionresults को बार-बार कॉल नहीं किया जाता. वैल्यू, रीयल 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_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"

रिमोट कैश हिट की जांच की स्पीड को बेहतर बनाने के लिए, मेमोज़ करने वाले मेर्कल ट्री की संख्या. भले ही, सॉफ़्ट रेफ़रंस को मैनेज करने के लिए 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_input_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_dr (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --inaffiliate_strict_action_env (एनवायरमेंट वैरिएबल को नॉर्मलाइज़ करने के लिए) के साथ एक साथ सेट किया जा सकता है.

--experimental_worker_for_repo_fetching=<off, platform, virtual or auto> डिफ़ॉल्ट: "ऑटो"

रिपॉज़िटरी फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. अगर इसे 'बंद' पर सेट किया जाता है, तो किसी भी वर्क थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रिपॉज़िटरी को फ़ेच करने के लिए, रीस्टार्ट की ज़रूरत पड़ सकती है. ऐसा न होने पर, वर्चुअल वर्कर्स थ्रेड का इस्तेमाल किया जाता है.

--[no]incompatible_remote_build_event_upload_respect_no_cache डिफ़ॉल्ट: "गलत"

अब काम नहीं करता. कोई कार्रवाई नहीं की जाएगी. इसके बजाय, --remote_build_event_upload=minimal का इस्तेमाल करें.

--[no]incompatible_remote_downloader_send_all_headers डिफ़ॉल्ट: "सही"

एक से ज़्यादा वैल्यू वाले हेडर की सभी वैल्यू को, रिमोट डाउनलोडर को भेजना है या सिर्फ़ पहली वैल्यू को.
टैग: incompatible_change

--[no]incompatible_remote_output_paths_relative_to_input_root डिफ़ॉल्ट: "गलत"

अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट के हिसाब से होते हैं.
टैग: incompatible_change

--[no]incompatible_remote_results_ignore_disk डिफ़ॉल्ट: "सही"

कोई कार्रवाई नहीं करने वाले
टैग: incompatible_change

--[no]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो कैश मेमोरी खाली करने जैसी रिमोट कैश मेमोरी से जुड़ी गड़बड़ियों की वजह से, बिल्ड पूरा न होने पर Bazel, 34 के बजाय नए एक्सिट कोड 39 का इस्तेमाल करेगा.
टैग: incompatible_change

--[no]remote_accept_cached डिफ़ॉल्ट: "सही"

क्या रिमोट से कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को स्वीकार करना है.

--remote_build_event_upload=<all or minimal> डिफ़ॉल्ट: "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://bagel.build/remote/cating

पर जाएं

--[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_property को सेट नहीं किया हो, तो रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए, डिफ़ॉल्ट 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> डिफ़ॉल्ट: ""

रिमोट एक्ज़ीक्यूशन एपीआई में example_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "गलत"

रिमोट तरीके से लागू करने की प्रोसेस पूरी न होने पर, स्टैंडअलोन लोकल तरीके से लागू करने की रणनीति का इस्तेमाल करना है या नहीं.

--remote_local_fallback_strategy=<a string> डिफ़ॉल्ट: "local"

काम नहीं करता, अब इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba बहुत/issues/7480 पर जाएं.

--remote_max_connections=<an integer> डिफ़ॉल्ट: "100"

एक साथ कई कनेक्शन की संख्या को रिमोट कैश/एक्ज़ीक्यूटर तक सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा तय नहीं है. एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --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 डिफ़ॉल्ट: "सही"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Basel सभी रिमोट डाउनलोड के हैश योग को कैलकुलेट करेगा. साथ ही, अगर रिमोट तौर पर कैश मेमोरी में सेव की गई वैल्यू और वैल्यू, उम्मीद के मुताबिक वैल्यू से मेल नहीं खाती हैं, तो उन वैल्यू को खारिज कर दिया जाएगा.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--[no]allow_analysis_cache_discard डिफ़ॉल्ट: "सही"

अगर बिल्ड सिस्टम में हुए बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज किया जाता है, तो इस विकल्प को 'गलत है' पर सेट करने पर, bazel बिल्ड जारी रखने के बजाय बंद हो जाएगा. अगर 'discard_analysis_cache' भी सेट है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit

--auto_output_filter=<none, all, packages or subpackages> डिफ़ॉल्ट: "कोई नहीं"

अगर --output_filter की वैल्यू नहीं दी गई है, तो इस विकल्प की वैल्यू का इस्तेमाल करके, अपने-आप फ़िल्टर बन जाता है. इस विकल्प के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: 'none' (कुछ भी फ़िल्टर न करें / सब कुछ दिखाएं), 'all' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'packages' (Blaze कमांड लाइन पर बताए गए पैकेज में नियमों का आउटपुट शामिल करें), और 'subpackages' ('packages' की तरह, लेकिन इसमें सब-पैकेज भी शामिल हैं). 'पैकेज' और 'सबपैकेज' वैल्यू के लिए //java/foo और //javatests/foo को एक पैकेज माना जाता है)'.

--[no]build_manual_tests डिफ़ॉल्ट: "गलत"

'मैन्युअल' टैग किए गए टेस्ट टारगेट बनाए जाते हैं. 'मैन्युअल' टेस्ट को प्रोसेस से बाहर रखा जाता है. इस विकल्प की मदद से, उन्हें बनाने के लिए मजबूर किया जाता है, लेकिन उन्हें लागू नहीं किया जाता.

--build_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

टैग की कॉमा-सेपरेटेड लिस्ट दिखाता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प का असर, 'test' कमांड के साथ चलाए गए टेस्ट के सेट पर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों से कंट्रोल किए जाते हैं. उदाहरण के लिए, '--test_tag_filters'

--[no]build_tests_only डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चुना जाता है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.

--combined_report=<none or lcov> डिफ़ॉल्ट: "कोई नहीं"

यह बताता है कि कवरेज की कुल रिपोर्ट किस तरह की होनी चाहिए. फ़िलहाल, सिर्फ़ 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 के मुताबिक, इस फ़ाइल में, चलाए गए स्पैन को लंबाई के हिसाब से बांटा गया SpawnExec प्रोटो के तौर पर लॉग करें. --execution_log_compact_file को प्राथमिकता दें, क्योंकि यह काफ़ी छोटी होती है और इसे बनाने में कम खर्च आता है. मिलते-जुलते फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--execution_log_compact_file=<a path> डिफ़ॉल्ट: जानकारी देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में, ExecLogEntry प्रोटो के तौर पर, स्पान की गई प्रोसेस को लॉग करें. पूरी फ़ाइल को zstd से कंप्रेस किया गया है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबस फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--execution_log_json_file=<a path> डिफ़ॉल्ट: जानकारी देखें

src/main/protobuf/spawn.proto के मुताबिक, SpawnExec प्रोटो के न्यूलाइन डीलिमिटेड JSON रिप्रज़ेंटेशन के तौर पर, इस फ़ाइल में लॉन्च किए गए स्पैन को लॉग करें. --execution_log_compact_file को प्राथमिकता दें. यह काफ़ी छोटी होती है और इसे बनाने में कम खर्च आता है. इससे जुड़े फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_binary_file (बाइनरी प्रोटोबस फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

--[no]execution_log_sort डिफ़ॉल्ट: "सही"

कार्रवाई के लॉग को क्रम से लगाना है या नहीं. इससे, सभी अनुरोधों के लॉग की तुलना करना आसान हो जाता है. कॉल के आखिर में सीपीयू और मेमोरी के ज़्यादा इस्तेमाल से बचने के लिए, इसे 'गलत' पर सेट करें. हालांकि, ऐसा करने पर लॉग को लागू करने का क्रम तय नहीं किया जा सकेगा. यह सिर्फ़ बाइनरी और JSON फ़ॉर्मैट पर लागू होता है. कॉम्पैक्ट फ़ॉर्मैट को कभी क्रम से नहीं लगाया जाता.

--[no]expand_test_suites डिफ़ॉल्ट: "सही"

विश्लेषण से पहले, test_suite के टारगेट को उसके मूल टेस्ट में बड़ा करें. यह फ़्लैग चालू होने पर (डिफ़ॉल्ट रूप से), नेगेटिव टारगेट पैटर्न, टेस्ट सुइट से जुड़े टेस्ट पर लागू होंगे. ऐसा न होने पर, ये पैटर्न लागू नहीं होंगे. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड लाइन पर टॉप-लेवल के पहलुओं को लागू किया जाता है: इसके बाद वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis

--experimental_disk_cache_gc_idle_delay=<An immutable length of time.> डिफ़ॉल्ट: "5m"

डिस्क कैश की ग़ैर-ज़रूरी फ़ाइलें हटाने से पहले, सर्वर को कितने समय तक बंद रखना चाहिए. ग़ैर-ज़रूरी डेटा हटाने की नीति तय करने के लिए, --experimental_disk_cache_gc_max_size और/या --experimental_disk_cache_gc_max_age सेट करें.

--experimental_disk_cache_gc_max_age=<An immutable length of time.> डिफ़ॉल्ट: "0"

अगर इसे किसी पॉज़िटिव वैल्यू पर सेट किया जाता है, तो डिस्क कैश में समय-समय पर गै़रबैज कलेक्शन किया जाएगा, ताकि इस समयसीमा से ज़्यादा पुरानी एंट्री हटाई जा सकें. अगर --experimental_disk_cache_gc_max_size के साथ सेट किया जाता है, तो दोनों शर्तें लागू होती हैं. सर्वर के खाली होने पर, बैकग्राउंड में ग़ैर-ज़रूरी डेटा हटाया जाता है. यह --experimental_disk_cache_gc_idle_delay फ़्लैग से तय होता है.

--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier> डिफ़ॉल्ट: "0"

अगर वैल्यू को पॉज़िटिव पर सेट किया जाता है, तो डिस्क की कैश मेमोरी में समय-समय पर इकट्ठा किया गया कचरा होगा, ताकि इस साइज़ को इससे कम रखा जा सके. अगर --experimental_disk_cache_gc_max_age के साथ सेट किया गया है, तो दोनों शर्तें लागू होती हैं. सर्वर के खाली होने पर, बैकग्राउंड में ग़ैर-ज़रूरी डेटा हटाया जाता है. यह --experimental_disk_cache_gc_idle_delay फ़्लैग से तय होता है.

--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: ""

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. टारगेट के सेट के फ़िल्टर जिनके लिए extra_action शेड्यूल करने हैं.

--[no]experimental_extra_action_top_level_only डिफ़ॉल्ट: "गलत"

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. सिर्फ़ टॉप लेवल टारगेट के लिए extra_actions शेड्यूल करता है.

--experimental_spawn_scheduler

कार्रवाइयों को स्थानीय तौर पर या रिमोट तरीके से साथ-साथ चलाकर, डाइनैमिक एक्ज़ीक्यूशन की सुविधा चालू करें. बेज़ल, हर कार्रवाई को स्थानीय तौर पर और कहीं से भी शुरू करते हैं. साथ ही, जो पहले पूरा करता है उसे चुनता है. अगर कोई कार्रवाई कर्मियों के साथ काम करती है, तो लोकल कार्रवाई परसिस्टेंट वर्कर मोड में होगी. किसी एक ऐक्शन के लिए डाइनैमिक तरीके से प्रोसेस करने की सुविधा चालू करने के लिए, `--internal_spawn_scheduler` और `--strategy=<mnemonic>=dynamic` फ़्लैग का इस्तेमाल करें.
इस तरह बड़ा होता है:
  --internal_spawn_scheduler
  --spawn_strategy=dynamic

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--[no]incompatible_dont_use_javasourceinfoprovider डिफ़ॉल्ट: "गलत"

कोई कार्रवाई नहीं करने वाले
टैग: incompatible_change

--local_termination_grace_seconds=<an integer> डिफ़ॉल्ट: "15"

टाइम आउट की वजह से, किसी लोकल प्रोसेस को खत्म करने और उसे ज़बरदस्ती बंद करने के बीच इंतज़ार का समय.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह वह किया गया है. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--test_lang_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

यह टेस्ट की जाने वाली भाषाओं की सूची होती है. इसमें भाषाओं को कॉमा लगाकर अलग किया जाता है. बाहर रखी गई भाषाएं तय करने के लिए हर भाषा के पहले वैकल्पिक रूप से '-' लगाया जा सकता है. सिर्फ़ वे टेस्ट टारगेट दिखेंगे जो चुनी गई भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test नियम में भाषा के प्रीफ़िक्स जैसा ही होना चाहिए. जैसे, 'cc', 'java', 'py' वगैरह में से कोई एक. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.

--test_size_filters=<comma-separated list of values: small, medium, large or enormous> डिफ़ॉल्ट: ""

टेस्ट साइज़ की ऐसी सूची बताता है जिसे कॉमा लगाकर अलग किया गया हो. शामिल नहीं किए गए साइज़ की जानकारी देने के लिए, हर साइज़ के आगे '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. आपको सिर्फ़ ऐसे टेस्ट टारगेट दिखेंगे जिनमें शामिल किए गए कम से कम एक साइज़ शामिल हो और बाहर रखे गए कोई साइज़ शामिल न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

टेस्ट टैग की ऐसी सूची दिखाता है जिसे कॉमा लगाकर अलग किया गया हो. बाहर रखे गए टैग तय करने के लिए, हर टैग से पहले वैकल्पिक रूप से '-' लगाया जा सकता है. आपको सिर्फ़ ऐसे टेस्ट टारगेट मिलेंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: ""

टेस्ट टाइम आउट की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टाइम आउट की जानकारी देने के लिए, हर टाइम आउट के पहले '-' लगाया जा सकता है. केवल वही परीक्षण लक्ष्य मिलेंगे, जिनमें कम से कम एक टाइमआउट शामिल किया गया हो और उसमें कोई भी बहिष्कृत टाइमआउट शामिल न हो. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.

--workspace_status_command=<path> डिफ़ॉल्ट: ""

किसी फ़ाइल फ़ोल्डर की स्थिति की जानकारी देने के लिए, बिल्ड की शुरुआत में एक कमांड का इस्तेमाल किया जाता है. यह जानकारी, की/वैल्यू पेयर के तौर पर होती है. पूरी जानकारी के लिए, उपयोगकर्ता मैन्युअल देखें. उदाहरण के लिए, Tools/buildstamp/get_workspace_status देखें.

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]check_up_to_date डिफ़ॉल्ट: "गलत"

बिल्ड न करें, सिर्फ़ यह देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड सफलतापूर्वक पूरा हो जाता है. अगर किसी चरण को पूरा करना ज़रूरी है, तो गड़बड़ी की शिकायत की जाती है और बिल्ड पूरा नहीं होता.
टैग: execution

--[no]experimental_inprocess_symlink_creation डिफ़ॉल्ट: "गलत"

सिंबललिंक ट्री बनाने के लिए, फ़ाइल सिस्टम को सीधे कॉल करना है या नहीं
टैग: loading_and_analysis, execution, experimental

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "गलत"

कर्मचारियों का इस्तेमाल करके, लगातार आर एक्सट्रैक्टर चालू करें.
टैग: execution

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "गलत"

सोर्स मेनिफ़ेस्ट कार्रवाइयों को रिमोट तौर पर बनाया जाए या नहीं
टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel एक नए स्पैन में टेस्ट के लिए कवरेज पोस्ट-प्रोसेसिंग चलाएगा.
टैग: execution

--[no]experimental_split_xml_generation डिफ़ॉल्ट: "सही"

अगर यह फ़्लैग सेट है और कोई टेस्ट ऐक्शन, test.xml फ़ाइल जनरेट नहीं करता है, तो Bazel एक अलग ऐक्शन का इस्तेमाल करके, टेस्ट लॉग वाली डमी test.xml फ़ाइल जनरेट करता है. ऐसा न करने पर, Bazel टेस्ट ऐक्शन के हिस्से के तौर पर test.xml जनरेट करता है.
टैग: execution

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो फ़ाइल सेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर इस्तेमाल करेंगे. ये डायरेक्ट्री में नहीं जाएंगे या सिमलिन्क के लिए संवेदनशील नहीं होंगे.
टैग: execution

--[no]experimental_use_semaphore_for_jobs डिफ़ॉल्ट: "सही"

अगर इसे 'सही है' पर सेट किया जाता है, तो एक साथ चलने वाले जॉब की संख्या को सीमित करने के लिए, सिग्नल का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution

--genrule_strategy=<comma-separated list of options> डिफ़ॉल्ट: ""

यह बताएं कि जेनरूल को कैसे लागू करना है. इस फ़्लैग को बंद कर दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरेटिव नियमों को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: execution

--[no]incompatible_disallow_unsound_directory_outputs डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो किसी कार्रवाई के लिए आउटपुट फ़ाइल को डायरेक्ट्री के तौर पर मैटीरियलाइज़ करना गड़बड़ी है. इससे सोर्स डायरेक्ट्री पर कोई असर नहीं पड़ता. https://github.com/baडेलbuild/basel/issues/18646 पर जाएं.
टैग: bazel_internal_configuration, incompatible_change

--[no]incompatible_modify_execution_info_additive डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो एक से ज़्यादा --modify_execution_info फ़्लैग पास करने पर, उनका योग जोड़ दिया जाता है. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग पर ध्यान दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> [-j] डिफ़ॉल्ट: "auto"

एक साथ चलने वाली जॉब की संख्या. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "Host_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. 2500 से ज़्यादा वैल्यू की वजह से, मेमोरी से जुड़ी समस्याएं हो सकती हैं. "auto", होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट तौर पर सही साइज़ का हिसाब लगाता है.
टैग: host_machine_resource_optimizations, execution

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> एक से ज़्यादा बार इस्तेमाल किए जाने पर

किसी कार्रवाई की याद दिलाने वाली जानकारी के आधार पर, किसी कार्रवाई को लागू करने की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो प्रोग्राम के चलने की जानकारी दिखाती हैं. कई सामान्य कार्रवाइयां, प्रोग्राम के चलने की जानकारी दिखाती हैं. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. इसकी वजह यह है कि एक ही याद दिलाने वाले तरीके पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "रेगुलर एक्सप्रेशन=[+-]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

{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]skip_incompatible_explicit_targets डिफ़ॉल्ट: "गलत"

कमांड लाइन पर साफ़ तौर पर बताए गए, काम न करने वाले टारगेट को स्किप करें. डिफ़ॉल्ट रूप से, ऐसे टारगेट बनाने पर गड़बड़ी होती है. हालांकि, इस विकल्प के चालू होने पर इन्हें बिना किसी सूचना के स्किप कर दिया जाता है. देखें: https://bazu.build/extending/platforms#skipping-inaffiliate-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 से मैच करने वाली जानकारी के लिए तय की जाती है. रेगुलर एक्सप्रेशन फ़िल्टर मैचिंग के बारे में जानने के लिए --per_file_copt देखें. ब्यौरे से मैच करने वाले आखिरी रेगुलर एक्सप्रेशन फ़िल्टर का इस्तेमाल किया जाता है. रणनीति तय करने के लिए यह विकल्प दूसरे फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि अगर ऐक्शन के ब्यौरे //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar से नहीं, तो लोकल रणनीति का इस्तेमाल करके ऐक्शन चलाएं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed, 'Compiling //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा. हालांकि, क्रम को बदलने पर, इसे 'sandboxed' के साथ चलाया जाएगा.
टैग: execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel टेस्ट चलाने के लिए, टेस्ट एक्सीक्यूट ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा.
टैग: execution

ऐसे विकल्प जो कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करते हैं:

--android_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_crosstool_top=<a build target label> डिफ़ॉल्ट: "//external:android/crosstool"

Android बिल्ड के लिए इस्तेमाल किए जाने वाले C++ कंपाइलर की जगह की जानकारी.
टैग: affects_outputs, changes_inputs, loading_and_analysis, loses_incremental_state

--android_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

Android का टारगेट grte_top.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--android_manifest_merger=<legacy, android or force_android> डिफ़ॉल्ट: "android"

android_binary नियमों के लिए इस्तेमाल करने के लिए, मेनिफ़ेस्ट मर्ज करने वाला टूल चुनता है. लेगसी मर्ज से Android मेनिफ़ेस्ट मर्ज पर ट्रांज़िशन करने में मदद करने के लिए फ़्लैग.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_platforms=<a build target label> डिफ़ॉल्ट: ""

उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी एक फ़ैट APKs होता है. इसमें, बताए गए हर टारगेट प्लैटफ़ॉर्म के लिए, नेटिव बाइनरी होती हैं.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--android_sdk=<a build target label> डिफ़ॉल्ट: "@ba"_tools//tools/android:sdk"

इससे उस Android SDK टूल/प्लैटफ़ॉर्म के बारे में पता चलता है जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: 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> डिफ़ॉल्ट: "@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

--crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

C++ कोड को कंपाइल करने के लिए, क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--custom_malloc=<a build target label> डिफ़ॉल्ट: जानकारी देखें

malloc फ़ंक्शन को पसंद के मुताबिक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड नियमों में malloc एट्रिब्यूट को बदल देती है.
टैग: changes_inputs, affects_outputs

--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के आगे - (नेगेटिव एक्सप्रेशन) लगाने का विकल्प होता है. यह सूची, कॉमा लगाकर अलग की गई पाबंदी की वैल्यू के टारगेट की सूची को (=) असाइन करती है. अगर कोई टारगेट किसी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा जैसे उसने शर्त की वैल्यू को, लागू करने से जुड़ी शर्तों के तौर पर बताया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64, //demo के तहत मौजूद किसी भी टारगेट में 'x86_64' जोड़ देगा. हालांकि, जिन टारगेट के नाम में 'test' शामिल है उनमें यह पैरामीटर नहीं जोड़ा जाएगा.
टैग: loading_and_analysis

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "गलत"

अगर सेट है, तो हर Xcode ऐक्शन के लिए, "requires-xcode:{version}" को लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "ज़रूरी-xcode-label:{version_label}" लागू करने की शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution

--[no]experimental_prefer_mutual_xcode डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सबसे नए Xcode का इस्तेमाल करें. यह Xcode, लोकल और रिमोट, दोनों जगहों पर उपलब्ध होता है. अगर यह फ़ॉल्स है या दोनों डिवाइसों पर एक ही वर्शन उपलब्ध नहीं है, तो xcode-select की मदद से चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state

--extra_execution_platforms=<comma-separated list of options> डिफ़ॉल्ट: ""

ऐसे प्लैटफ़ॉर्म जो ऐक्शन चलाने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म को एग्ज़ैक्ट टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन प्लैटफ़ॉर्म पर उन प्लैटफ़ॉर्म का इस्तेमाल करने से पहले विचार किया जाएगा जिनका एलान Workspace फ़ाइल में रजिस्टर_execution_platforms() के ज़रिए किया गया है. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है; बाद के इंस्टेंस, पहले के फ़्लैग सेटिंग को बदल देंगे.
टैग: execution

--extra_toolchains=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों को ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() फ़ंक्शन की मदद से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले इस्तेमाल किया जाएगा.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

चेक-इन की गई लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़े.
टैग: action_command_lines, affects_outputs

--host_compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

होस्ट कोड को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. --host_crosstool_top सेट न होने पर, इसे अनदेखा कर दिया जाता है.
टैग: loading_and_analysis, execution

--host_crosstool_top=<a build target label> डिफ़ॉल्ट: जानकारी देखें

डिफ़ॉल्ट रूप से, exec कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler विकल्पों का भी इस्तेमाल किया जाता है. यह फ़्लैग देने पर, Bazel दिए गए crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--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_dont_enable_host_nonhost_crosstool_features डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'नॉन-होस्ट' सुविधाओं को चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_android_toolchain_resolution डिफ़ॉल्ट: "सही"

Android के नियमों के लिए, Android SDK टूल (Starlark और नेटिव) चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "गलत"

Apple के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करना
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_make_thinlto_command_lines_standalone डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel, lto इंडेक्सिंग कमांड लाइन के लिए C++ लिंक ऐक्शन कमांड लाइन का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_require_ctx_in_configure_features डिफ़ॉल्ट: "सही"

अगर यह सही है, तो Bazel को cc_common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]interface_shared_objects डिफ़ॉल्ट: "सही"

अगर टूलचेन के साथ काम करता है, तो इंटरफ़ेस के साथ शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, सभी ELF टूलचेन इस सेटिंग के साथ काम करते हैं.
टैग: loading_and_analysis, affects_outputs, affects_outputs

--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

iOS ऐप्लिकेशन बनाने के लिए, iOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

macOS ऐप्लिकेशन बनाने के लिए, macOS SDK टूल के वर्शन की जानकारी देता है. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से macOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--minimum_os_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें

ऑपरेटिंग सिस्टम का कम से कम वर्शन जिसे आपके कंपाइलेशन ने टारगेट किया है.
टैग: loading_and_analysis, affects_outputs

--platform_mappings=<a relative path> डिफ़ॉल्ट: ""

मैपिंग फ़ाइल की जगह, जो बताती है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो किस प्लैटफ़ॉर्म का इस्तेमाल करना है या कोई प्लैटफ़ॉर्म पहले से मौजूद होने पर, कौनसे फ़्लैग सेट करने हैं. यह मुख्य फ़ाइल फ़ोल्डर से जुड़ा होना चाहिए. डिफ़ॉल्ट रूप से 'platform_mappings' (फ़ाइल फ़ोल्डर रूट के नीचे मौजूद फ़ाइल) पर सेट होता है.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--platforms=<a build target label> डिफ़ॉल्ट: ""

मौजूदा निर्देश के लिए टारगेट किए गए प्लैटफ़ॉर्म के बारे में बताने वाले, प्लैटफ़ॉर्म के नियमों के लेबल.
टैग: affects_outputs, changes_inputs, loading_and_analysis

--python2_path=<a string> डिफ़ॉल्ट: जानकारी देखें

अब काम नहीं करता. `--incompatible_use_python_toolchains` से बंद कर दिया गया है.
टैग: no_op, deprecated

--python3_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

अब काम नहीं करता. `--incompatible_use_python_toolchains` से बंद कर दिया गया है.
टैग: no_op, deprecated

--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. बहिष्कृत; --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 ऐप्लिकेशन बनाने के लिए, 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> डिफ़ॉल्ट: "@bagel_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 डिफ़ॉल्ट: "सही"

बिल्ड को लागू करें; यह सामान्य तरीका है. --nobuild का इस्तेमाल करने पर, बिल्ड ऐक्शन लागू करने से पहले ही बिल्ड रुक जाता है. अगर पैकेज लोड करने और विश्लेषण के चरण सही तरीके से पूरे हो जाते हैं, तो यह शून्य दिखाता है. यह मोड, उन चरणों की जांच करने के लिए काम का है.
टैग: execution, affects_outputs

--[no]build_runfile_links डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइलों के सिमलिंक फ़ॉरेस्ट बनाएं. अगर यह फ़ील्ड 'गलत' पर सेट है, तो इसे सिर्फ़ तब लिखें, जब किसी स्थानीय कार्रवाई, जांच या चलाने के कमांड की ज़रूरत हो.
टैग: affects_outputs

--[no]build_runfile_manifests डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह 'गलत है' पर सेट है, तो उन्हें शामिल न करें. गलत होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs

--[no]build_test_dwp डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िज़न की मदद से बिल्ड करते समय, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बिल्ड हो जाएगी.
टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h"

cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc"

cc_proto_library से बनने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत"

proto_library में, अन्य Java API वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_proto_extra_actions डिफ़ॉल्ट: "गलत"

proto_library में अन्य Java एपीआई वर्शन के लिए ज़्यादा कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत"

कंपाइलेशन के आउटपुट के तौर पर, चालू और अनुरोध किए गए फ़ीचर की स्थिति सेव करें.
टैग: affects_outputs, experimental

--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "गलत"

क्या टेस्ट के साथ पैरलल तरीके से काम करने के लिए, आसपेक्ट का इस्तेमाल करके पुष्टि करने की कार्रवाइयां चलानी हैं.
टैग: execution, affects_outputs

--fission=<a set of compilation modes> डिफ़ॉल्ट: "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://baज़ेन.build/extending/rules#runfiles_features_to_avoid) के लिए सुझाए गए तरीके से मेल खाता है.
टैग: affects_outputs, incompatible_change

--[no]legacy_external_runfiles डिफ़ॉल्ट: "सही"

अगर यह सही है, तो .runfiles/repo के अलावा, .runfiles/wsname/external/repo में बाहरी रिपॉज़िटरी के लिए, runfiles के सिर्फ़ लिंक वाले फ़ॉरेस्ट बनाएं.
टैग: affects_outputs

--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत"

बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs

--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

--[no]save_temps डिफ़ॉल्ट: "गलत"

अगर यह नीति सेट की जाती है, तो gcc से कुछ समय के लिए मिले आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (पहले से प्रोसेस की गई C) और .ii फ़ाइलें (पहले से प्रोसेस की गई C++) शामिल हैं.
टैग: affects_outputs

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, तय किए गए आउटपुट को कॉन्फ़िगर कर सकता है. साथ ही, उसके मौजूद होने पर, उसकी वैल्यू पर असर डालता है:

--action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टारगेट कॉन्फ़िगरेशन वाले ऐक्शन के लिए उपलब्ध, एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. यह पेयर, कॉल करने के एनवायरमेंट से अलग वैल्यू सेट करता है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है; एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत और अलग-अलग वैरिएबल के लिए विकल्प इकट्ठा होते हैं.
टैग: action_command_lines

--android_cpu=<a string> डिफ़ॉल्ट: "armeabi-v7a"

Android टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]android_databinding_use_androidx डिफ़ॉल्ट: "सही"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ 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> डिफ़ॉल्ट: "alphabetical"

Android बाइनरी के लिए, मेनिफ़ेस्ट मर्ज करने वाले टूल को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अंग्रेज़ी वर्णमाला के क्रम में का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. डिपेंडेंसी का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसी क्रम में रखा जाता है जो उसके डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--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' किसी फ़ाइल टूल/my_def.bzl से लिया गया टॉप-लेवल मान है

--[no]build_python_zip डिफ़ॉल्ट: "auto"

Python के लिए, ज़िप फ़ाइल में प्रोग्राम को चलाने की सुविधा जोड़ना; Windows पर चालू, अन्य प्लैटफ़ॉर्म पर बंद करना
टैग: affects_outputs

--catalyst_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है. इन आर्किटेक्चर के लिए, Apple Catalyst बाइनरी बनाई जानी हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "गलत"

अगर तय किया गया है, तो Bazel कोड को इंस्ट्रूमेंट करेगा. इसके लिए, जहां भी हो सके वहां ऑफ़लाइन इंस्ट्रूमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा की जाएगी. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताना चाहिए - इसके बजाय, 'bazu दूरी' निर्देश का इस्तेमाल करना चाहिए.
टैग: 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_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह नीति सेट की जाती है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी दिखेगी.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "auto"

रनफ़ाइल्स के सिमलिंक ट्री को चालू करें; डिफ़ॉल्ट रूप से, यह Windows और अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> बार इस्तेमाल किए गए

पक्षों के पहलुओं को प्राथमिकता दी जाती है. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में Java के रिसॉर्स को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का इस्तेमाल नहीं किया जा सकता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत"

dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत"

अगर साफ़ तौर पर बताया गया है, तो Basel, जनरेट की गई फ़ाइलों के कवरेज की जानकारी भी जनरेट करेगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks डिफ़ॉल्ट: "सामान्य"

इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिंक (बिल्ड के बाद वर्कस्पेस में दिखने वाले लिंक) को कैसे मैनेज किया जाएगा. संभावित वैल्यू: सामान्य (डिफ़ॉल्ट): हर तरह का सुविधाजनक सिंबललिंक बनाया या मिटाया जाएगा. यह, बिल्ड के हिसाब से तय किया जाएगा. साफ़ करें: सभी सिमलिंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: इससे सिमलिनक नहीं हटेंगे. log_only: लॉग मैसेज जनरेट करें, जैसे कि 'normal' पास किया गया हो. हालांकि, फ़ाइल सिस्टम पर कोई कार्रवाई न करें. यह टूल के लिए काम का है. ध्यान दें कि सिर्फ़ उन सिमलिंक पर असर पड़ सकता है जिनके नाम --symlink_prefix की मौजूदा वैल्यू से जनरेट किए गए हैं. प्रीफ़िक्स बदलने पर, पहले से मौजूद सिमलिंक में कोई बदलाव नहीं होगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks_bep_event डिफ़ॉल्ट: "गलत"

इस फ़्लैग से यह कंट्रोल किया जाता है कि हम बिल्ड event संबद्धSymlinksIdentified को BuildEventProtocol पर पोस्ट करेंगे या नहीं. अगर वैल्यू 'सही है' पर सेट है, तो BuildEventProtocol में convenienceSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधाजनक लिंक की सूची होगी. अगर यह 'गलत' है, तो BuildEventProtocol में convenienceSymlinksIdentified एंट्री खाली होगी.
टैग: affects_outputs

--experimental_objc_fastbuild_options=<comma-separated list of options> डिफ़ॉल्ट: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc फ़ास्टबिल्ड कंपाइलर विकल्पों के तौर पर किया जाता है.
टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "गलत"

अगर सही हो, तो स्टैक को आराम देने के लिए libunwind का इस्तेमाल करें और -fomit-frame-pointer और -fasynchronous-unwind-tables की मदद से कंपाइल करें.
टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off, content or strip> डिफ़ॉल्ट: "बंद"

आउटपुट ट्री के नियमों में आउटपुट कहां पर लिखा जाएगा, यह तय करने के लिए किस मॉडल का इस्तेमाल करना चाहिए. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6526 पर जाएं. Starlark ऐक्शन, 'execution_requirements' डिक्शनरी में 'supports-path-mapping' कुंजी जोड़कर, पाथ मैपिंग में ऑप्ट इन कर सकते हैं.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

हर एंट्री, label=value फ़ॉर्मैट में होनी चाहिए. इसमें label, किसी प्लैटफ़ॉर्म का रेफ़रंस देता है और values, आउटपुट पाथ में इस्तेमाल करने के लिए पसंदीदा शॉर्टनेम होता है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir सही हो. नाम रखने की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत"

अगर सही है, तो टारगेट प्लैटफ़ॉर्म के छोटे नाम का इस्तेमाल, सीपीयू के बजाय आउटपुट डायरेक्ट्री के नाम में किया जाता है. सटीक स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव किया जा सकता है: सबसे पहले, अगर --platforms विकल्प में एक ही वैल्यू नहीं है, तो प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir से रजिस्टर किया गया था, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म लेबल के आधार पर किसी छोटे नाम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल आखिरी विकल्प के तौर पर किया जाता है.
टैग: affects_outputs, experimental

--[no]experimental_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

--fat_apk_cpu=<comma-separated set of options> डिफ़ॉल्ट: "armeabi-v7a"

इस विकल्प को सेट करने से, फ़ैट APK चालू हो जाते हैं.इनमें, टारगेट किए गए सभी आर्किटेक्चर के लिए नेटिव बाइनरी होती हैं. जैसे, --fat_apk_cpu=x86,armeabi-v7a. अगर यह फ़्लैग बताया गया है, तो android_binary नियमों की निर्भरता के लिए --android_cpu को अनदेखा कर दिया जाता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]fat_apk_hwasan डिफ़ॉल्ट: "गलत"

HWASAN स्प्लिट बनाने हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें

एफ़डीओ इंस्ट्रूमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर की मदद से, यह डायरेक्ट्री का नाम भी स्वीकार करता है. इसके तहत, रनटाइम के दौरान, रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को डंप किया जाएगा.
टैग: affects_outputs

--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. उस ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल शामिल हो. यह फ़्लैग, लेबल के तौर पर बताई गई फ़ाइलों को भी स्वीकार करता है.जैसे, `//foo/bar:file. afdo` - आपको उससे जुड़े पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है.साथ ही, यह फ़्लैग, `fdo_profile` टारगेट पर ले जाने वाले लेबल को भी स्वीकार करता है. `fdo_profile` नियम के तहत इस फ़्लैग की जगह ले ली जाएगी.
टैग: affects_outputs

--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कैश मेमोरी में प्रीफ़ेच करने के सुझावों का इस्तेमाल करें.
टैग: affects_outputs

--fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

fdo_profile, ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल को दिखाता है.
टैग: affects_outputs

--features=<a string> बार इस्तेमाल किए गए

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> के बारे में बताने से सुविधा बंद हो जाएगी. नकारात्मक सुविधाएं, हमेशा सकारात्मक सुविधाओं की जगह ले लेती हैं. --host_features देखें
टैग: changes_inputs, affects_outputs

--[no]force_pic डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. साथ ही, लिंक करने के लिए, PIC वाली पहले से बनी लाइब्रेरी का इस्तेमाल किया जाता है, न कि PIC वाली लाइब्रेरी का. इसके अलावा, लिंक करने पर पोज़िशन-इंडिपेंडेंट एक्सीक्यूटेबल ("-pie") जनरेट होते हैं.
टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह, ऐक्शन के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. यह सेट, ऐक्शन के लिए इस्तेमाल किए जाने वाले एक्सीक्यूशन कॉन्फ़िगरेशन के साथ उपलब्ध होता है. वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. यह पेयर, कॉल करने के एनवायरमेंट से अलग वैल्यू सेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> डिफ़ॉल्ट: "ऑप्ट करें"

वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल पहले से मौजूद होंगे. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--host_conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एक्ज़िक कॉन्फ़िगरेशन में C (C++ नहीं) सोर्स फ़ाइलों को कंपाइल करते समय, C कंपाइलर को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--host_copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_cpu=<a string> डिफ़ॉल्ट: ""

होस्ट सीपीयू.
टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_features=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> की वैल्यू देने पर, यह सुविधा बंद हो जाएगी. नकारात्मक सुविधाएं, हमेशा सकारात्मक सुविधाओं की जगह ले लेती हैं.
टैग: changes_inputs, affects_outputs

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

exec कॉन्फ़िगरेशन के लिए, Python वर्शन को बदल देता है. यह "PY2" या "PY3" हो सकता है.
टैग: loading_and_analysis, affects_outputs

--host_linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एग्ज़ीक्यूट कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

होस्ट टारगेट के लिए, कम से कम काम करने वाला macOS वर्शन. अगर कोई वैल्यू नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. option_1 से option_n, मनमुताबिक कमांड लाइन के विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--host_swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

exec टूल के लिए, swiftc को पास करने के अन्य विकल्प.
टैग: 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]incompatible_use_host_features डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए --features और exec कॉन्फ़िगरेशन के लिए --host_features का इस्तेमाल करें.
टैग: changes_inputs, 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड ( --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

--swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्विफ़्ट के कंपाइलेशन का इस्तेमाल करने के दूसरे विकल्प.
टैग: action_command_lines

--symlink_prefix=<a string> डिफ़ॉल्ट: जानकारी देखें

प्रीफ़िक्स, जो किसी भी सुविधाजनक सिमलिंक के आगे जोड़ा जाता है. ये सिमलिंक, बिल्ड के बाद बनाए जाते हैं. अगर इस एट्रिब्यूट को शामिल नहीं किया जाता है, तो डिफ़ॉल्ट वैल्यू के तौर पर, बिल्ड टूल का नाम और उसके बाद हाइफ़न दिखेगा. अगर '/' पास किया जाता है, तो कोई सिमलिंक नहीं बनाया जाता और कोई चेतावनी नहीं भेजी जाती. चेतावनी: '/' के लिए खास सुविधा जल्द ही बंद कर दी जाएगी. इसके बजाय, --experimental_convenience_symlinks=ignore का इस्तेमाल करें.
टैग: affects_outputs

--tvos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं. इसमें आर्किटेक्चर को कॉमा लगाकर अलग किया गया है.
टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, काम करने वाला कम से कम tvOS वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा से अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple visionOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू रहेंगे, जैसे कि xbinary_fdo कभी तय नहीं किया गया हो.
टैग: affects_outputs