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

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

या

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

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

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

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

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

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

-<short_form> <value>

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

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

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

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

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

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

या इस तरह से ज़बरदस्ती बंद किया जा सकता है:

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

निर्देश

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ब्लेज़ चलाया जा रहा 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 स्टार्टअप फ़्लैग जोड़ने के लिए सुविधाजनक विकल्प. Basel के पास ऐसी जानी-पहचानी वैल्यू हैं जो हार्ड कोड किए गए 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"

http डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से बढ़ाएं
टैग: 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 डिफ़ॉल्ट: "सही"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Baze हमेशा सिमलिंक अपलोड करेगा. जैसे, रिमोट या डिस्क कैश मेमोरी में. अगर ऐसा नहीं किया जाता है, तो सिर्फ़ ऐसे रिलेटिव सिंबललिंक अपलोड किए जाएंगे जो किसी फ़ाइल या डायरेक्ट्री पर ले जाते हैं.
टैग: 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://bazel.build/external/overview देखें.
टैग: loading_and_analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर नीति को 'सही है' पर सेट किया जाता है, तो Starlark बिल्ड एपीआई के ऐसे कई प्रयोग दिखाए जाते हैं जो Google के लेगसी कोड से जुड़े हैं.
टैग: 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 डिफ़ॉल्ट: "गलत"

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

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

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

सही होने पर, Bazel अब 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/bazelbuild/bazel/issues/9014 देखें.
टैग: build_file_semantics, incompatible_change

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

अगर 'सही है' पर सेट किया जाता है, तो glb() के `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` एट्रिब्यूट में, वैल्यू "//..." का मतलब बदलता है. इससे, किसी भी रिपॉज़िटरी में मौजूद सभी पैकेज के बजाय, मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज का रेफ़रंस दिया जाता है. पुराना व्यवहार पाने के लिए, "//..." के बजाय खास वैल्यू "public" का इस्तेमाल किया जा सकता है. इस फ़्लैग के लिए, --incompatible_package_group_has_public_syntax भी चालू होना चाहिए.
टैग: build_file_semantics, incompatible_change

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--[no]incompatible_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 नियम के लिए, libraries_to_link के बजाय linker_inputs की ज़रूरत होगी. linking_context के पुराने गटर भी बंद कर दिए जाएंगे और सिर्फ़ linker_inputs उपलब्ध होंगे.
टैग: build_file_semantics, loading_and_analysis, incompatible_change

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

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

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

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

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

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

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

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

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

सही होने पर, 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/bazelbuild/bazel/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"

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

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

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

सही होने पर, Baज़ल, लिंक करने के लिए इस्तेमाल किए जाने वाले कमांड लाइन फ़्लैग में बदलाव नहीं करता. साथ ही, यह भी तय नहीं करता कि कौनसे फ़्लैग पैरामीटर फ़ाइल में जाएंगे और कौनसे नहीं. ज़्यादा जानकारी के लिए, 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> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह तय करता है कि --build_event_json_file के लिए, बिल्ड इवेंट सेवा अपलोड को बिल्ड पूरा होने से रोकना चाहिए या तुरंत अनुरोध खत्म करके, बैकग्राउंड में अपलोड पूरा करना चाहिए. 'wait_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या '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' या 'fully_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"

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

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

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

अगर ओओएम का इस्तेमाल किया जाता है, तो हीप डंप को मैन्युअल तरीके से आउटपुट करना है या नहीं (इसमें --gc_t इससेspring_limits तक पहुंचने की वजह से मैन्युअल OOM भी शामिल हैं). डंप, <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 डिफ़ॉल्ट: "गलत"

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

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

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

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

हाल ही में रेफ़र किए गए डाइजेस्ट के बाद, रिमोट कैश मेमोरी में कम से कम ब्लॉब की गारंटी मिलती है. जैसे, Actionनतीजे या 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/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No-op
टैग: 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.remote सर्टिफ़ाइडExtutionLog.LogEntry Protobufs का क्रम होता है. हर मैसेज से पहले एक वैरिंट लगाया जाता है. यह आगे दिए गए सीरियल वाले प्रोटोबफ़ मैसेज का साइज़ दिखाता है, जिसे 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 से ज़्यादा एक साथ किए जाने वाले अनुरोधों को हैंडल कर सकता है. इसलिए, Basel को `--remote_max_ connections * 100` एक साथ अनुरोध करने की सुविधा मिल सकती है.
टैग: host_machine_resource_optimizations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<a href="https://github.com/EngFlow/credential-helper-spec">क्रेडेंशियल हेल्पर स्पेसिफ़िकेशन</a> के मुताबिक क्रेडेंशियल हेल्पर कॉन्फ़िगर करता है. इसका इस्तेमाल, रिपॉज़िटरी फ़ेच करने, रिमोट कैश मेमोरी बनाने, और बिल्ड इवेंट सेवा के लिए अनुमति क्रेडेंशियल हासिल करने के लिए किया जाता है. `--google_default_Credentials`, `--google_Credentials`, `.netrc` फ़ाइल या `repository_ctx.download()` और `repository_ctx.download_and_extrack()` के लिए ऑथराइज़ेशन पैरामीटर के दिए गए क्रेडेंशियल के बजाय, किसी हेल्पर के क्रेडेंशियल को प्राथमिकता दी जाती है. एक से ज़्यादा हेल्पर सेट अप करने के लिए, इस क्रेडेंशियल को कई बार तय किया जा सकता है. निर्देशों के लिए, 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.> डिफ़ॉल्ट: "10 सेकंड"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ज़्यादा जानकारी वाले प्रोग्रेस बार में, एक साथ की जा रही कार्रवाइयों की संख्या; हर कार्रवाई को एक अलग लाइन में दिखाया जाता है. प्रोग्रेस बार में हमेशा कम से कम एक नंबर दिखता है. 1 से कम की सभी संख्याएं 1 पर मैप की जाती हैं.
टैग: 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.execute अब भी इंटरनेट को ऐक्सेस करने वाला कोई भी एक्सीक्यूटेबल चला सकता है.
टैग: 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>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, अनुमति पाए हुए वर्शन को भी तय किया जा सकता है. कीवर्ड 'सभी' का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, हम इसका सुझाव नहीं देते.
टैग: loading_and_analysis

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

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

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

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

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

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

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

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

Aquery के विकल्प

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है और उसे अपने-आप भरना है या नहीं.
टैग: terminal_output

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

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

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

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

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

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

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

Terms_input औरRule_ ठहरने के फ़ील्ड को भरना है या नहीं.
टैग: terminal_output

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

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

--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 की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

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

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

अगर सही है, तो Baze, नए स्पॉन्स में टेस्ट के लिए, कवरेज पोस्टप्रोसेसिंग चलाएगा.
टैग: 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,...> बार इस्तेमाल किए गए

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

--persistent_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

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

टैग: host_machine_resource_optimizations, execution

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

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

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

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

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

--android_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> डिफ़ॉल्ट: "@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 वर्शन में हाइफ़न वाला लेबल है, तो "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> डिफ़ॉल्ट: जानकारी देखें

डिफ़ॉल्ट रूप से, 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 के नियमों (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 डिफ़ॉल्ट: "सही"

अगर सही है, तो Basil, lto को इंडेक्स करने वाली कमांड लाइन के लिए, C++ लिंक ऐक्शन कमांड लाइन का दोबारा इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba इमारतों/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 डिफ़ॉल्ट: "सही"

अगर टूलचेन काम करता है, तो इंटरफ़ेस के शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, ईएलएफ़ टूलचेन में यह सेटिंग काम करती है.
टैग: 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 इंटरप्रेटर को दिखाता है. बहिष्कृत; --insupported_use_python_toolchains की मदद से बंद किया गया है.
टैग: loading_and_analysis, affects_outputs

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

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

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

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

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

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

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

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

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

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

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

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

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

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

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

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

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

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

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

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

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

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

proto_library में अन्य Java एपीआई वर्शन के लिए ज़्यादा कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_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://baज़ेन.build/extending/rules#runfiles_features_to_avoid) के लिए सुझाए गए तरीके से मेल खाता है.
टैग: affects_outputs, incompatible_change

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

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

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

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

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

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

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

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

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

--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> डिफ़ॉल्ट: "वर्णमाला"

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

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

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

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

python की एक्ज़ीक्यूटेबल ZIP फ़ाइल बनाएं; Windows पर, अन्य प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर यह जानकारी दी जाती है, तो 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_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> डिफ़ॉल्ट: "opt"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--macos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

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

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

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

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

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

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

अगर इसे सेट किया जाता है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS के बारे में बताएं.
टैग: action_command_lines

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

लिंक की गई बाइनरी पर, सिंबल और डेड-कोड हटाने की प्रोसेस की जानी चाहिए या नहीं. अगर इस फ़्लैग और --compilation_mode=opt, दोनों को तय किया जाता है, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

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

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

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

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

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

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

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

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

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

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, प्रोपेलर प्रोफ़ाइल की जानकारी का इस्तेमाल करें.प्रोपेलर प्रोफ़ाइल में कम से कम दो में से एक फ़ाइल होनी चाहिए, एक कॉपी प्रोफ़ाइल और एक 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> डिफ़ॉल्ट: जानकारी देखें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--tvos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

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

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

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

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

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

--watchos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--[no]experimental_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> डिफ़ॉल्ट: "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/baडेलbuild/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 डिफ़ॉल्ट: "सही"

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

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

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

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

लागू करने के दौरान, अनुमति वाली सूची (पैकेज_ग्रुप टारगेट) का इस्तेमाल करें --inबेमेल_python_disallow_native_rules.
टैग: loading_and_analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर सही है, तो objc_library andobjc_Import में sdk_frameworks और कम ऊर्जा_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/batzbuild/ba बहुत/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को या तो नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू को बेज़ल क्लाइंट एनवायरमेंट से या name=value पेयर के ज़रिए पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel 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} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने की ज़रूरत होती है. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. इस बात पर भी ध्यान दें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. हालांकि, 'बेज़ल क्वेरी' के दौरान यह फ़ैसला नहीं लिया जाता.
टैग: build_file_semantics

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है और उसे अपने-आप भरना है या नहीं.
टैग: terminal_output

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

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

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

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

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

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

--[no]proto:rule_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 कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics

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

टारगेट पैटर्न (जोड़ने और घटाने वाले) का कॉमा लगाकर बनाया गया सेट. क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. 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 टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/batzbuild/ba सुझावों/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

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

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

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो Bazel किसी टेस्ट को फिर से सिर्फ़ तब चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट चलाने का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. 'हां' पर सेट होने पर, Bazel बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजों को कैश मेमोरी में सेव नहीं करता.

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

अगर यह सही है, तो Blaze पहले सफल रन पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ काम आता है.
टैग: affects_outputs, loading_and_analysis

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

अगर यह सही है, तो कवरेज की जांच के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा की पूरी डायरेक्ट्री फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis

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

अगर यह सही है, तो clang के लिए कवरेज से LCOV रिपोर्ट जनरेट होगी.
टैग: affects_outputs, loading_and_analysis

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

J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.

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

छोटे हेडर पाथ से जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करना).
टैग: affects_outputs

--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javaबिल्डर"

Java कंपाइलेशन के लिए, कम क्लासपाथ की सुविधा चालू करता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर सही है, तो खास टेस्ट सैंडबॉक्स की गई रणनीति के साथ किए जाएंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

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

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने पर, शेयर किए गए कैश मेमोरी का इस्तेमाल होने पर, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी सेव नहीं की जा सकती.
टैग: loading_and_analysis, incompatible_change

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

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

--java_debug

इसकी वजह से, किसी Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे, jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इसे बड़ा किया जाएगा:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

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

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (फ़िलहाल, कंपाइल के समय क्लासपाथ) जनरेट करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

यह उन क्लास की सूची जनरेट करने के लिए एक बाइनरी के बारे में बताता है जिन्हें लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होना चाहिए.

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

शर्ड किए बिना डेक्स करने के लिए इस्तेमाल की जाने वाली बाइनरी के बारे में बताता है.

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

बिल्ड में इस्तेमाल करने के लिए प्लग इन. फ़िलहाल, यह java_plugin के साथ काम करता है.

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

Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना है, यह बताता है.

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

प्रोटो-कंपाइलर का लेबल.
टैग: affects_outputs, loading_and_analysis

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

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

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

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

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

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

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

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

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

--experimental_total_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "0"

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

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

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

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

अगर इसे 'सही है' पर सेट किया जाता है, तो एक साथ चलने वाले जॉब की संख्या को सीमित करने के लिए, सिग्नल का इस्तेमाल करें.
टैग: host_machine_resource_optimizations, execution

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

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

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

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

--experimental_worker_allowlist=<comma-separated set of options> डिफ़ॉल्ट: जानकारी देखें

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

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

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

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

अगर इसे 'सही' पर सेट किया जाता है, तो हर Linux सैंडबॉक्स में /tmp के तौर पर माउंट की गई एक खाली डायरेक्ट्री होगी. ऐसा करने से, /tmp को होस्ट फ़ाइल सिस्टम के साथ शेयर करने की ज़रूरत नहीं पड़ेगी. सभी सैंडबॉक्स में होस्ट का/tmp देखने के लिए, --sandbox_add_mount_pair=/tmp का इस्तेमाल करें.
टैग: execution

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

प्लेसहोल्डर का विकल्प, ताकि हम Blaze में बता सकें कि स्पैन शेड्यूलर चालू था या नहीं.
टैग: execution, host_machine_resource_optimizations

--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> [-j] डिफ़ॉल्ट: "auto"

एक साथ चलाए जाने वाले जॉब की संख्या. यह एक पूर्णांक या कीवर्ड ("ऑटो", "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

--[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.bagel.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy=<a '[name=]value1[,..,valueN]' assignment> बार इस्तेमाल किए गए

जानकारी दें कि अन्य स्पॉन्स ऐक्शन के कंपाइलेशन को कैसे डिस्ट्रिब्यूट किया जाए. सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के बीच, कॉमा लगाकर अलग की गई रणनीतियों की सूची स्वीकार की जाती है. हर कार्रवाई के लिए, Bagel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है और कार्रवाई को पूरा कर सकता है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग --spawn_strategy (और अगर याद रखने के लिए जेनरिक नियम के साथ इस्तेमाल किया गया है, तो --gen सकारात्मक_strategy) से सेट की गई वैल्यू बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazel.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

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

अतिरिक्त कमांड-फ़्लैग, जिन्हें --persistent_worker के अलावा वर्कर्स प्रोसेस को पास किया जाएगा.इनका नाम, याद रखने में आसान शब्दों से मिलता-जुलता होता है. जैसे, --worker_extra_flag=Javac=--debug.
टैग: execution, host_machine_resource_optimizations

--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> एक से ज़्यादा बार इस्तेमाल किए जाने पर

'वर्कर' रणनीति का इस्तेमाल करने पर, हर तरह के पर्सिस्टेंट वर्कर्स के कितने इंस्टेंस लॉन्च किए जा सकते हैं. हर स्नेमोनिक के लिए अलग-अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर बताया जा सकता है. यह सीमा वर्कर कुंजियों पर आधारित होती है, जिन्हें स्नेमनी के आधार पर अलग-अलग किया जाता है. साथ ही, यह स्टार्टअप फ़्लैग और पर्यावरण के आधार पर भी तय होता है. इसलिए, कुछ मामलों में हर याद में, इस फ़्लैग की तुलना में ज़्यादा वर्कर हो सकते हैं. यह एक पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल करता है. इसके बाद, वैकल्पिक रूप से कोई कार्रवाई ([-|*]<float>) ली जाती है, जैसे कि. "auto", "HOST_CPUS*.5". 'auto', मशीन की क्षमता के आधार पर डिफ़ॉल्ट रूप से सही साइज़ का हिसाब लगाता है. "=value" की मदद से, याददाश्त बढ़ाने वाली उन चीज़ों के लिए डिफ़ॉल्ट वैल्यू सेट की जाती है जिनके बारे में जानकारी नहीं दी गई है.
टैग: execution, host_machine_resource_optimizations

--worker_max_multiplex_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> बार इस्तेमाल किए गए

अगर --worker_multiplex के साथ 'कर्मचारी' रणनीति का इस्तेमाल किया जाता है, तो मल्टीप्लेक्स वर्कर प्रोसेस के साथ-साथ कितने WorkRequests मिल सकते हैं. हर मेनिमोनिक के लिए अलग वैल्यू देने के लिए, [name=value] के तौर पर तय किया जा सकता है. यह सीमा, वर्कर्स की कुंजियों पर आधारित होती है. इन कुंजियों को मेमोनिक के आधार पर अलग-अलग किया जाता है. साथ ही, स्टार्टअप फ़्लैग और एनवायरमेंट के आधार पर भी अलग-अलग किया जाता है. इसलिए, कुछ मामलों में हर मेमोनिक के लिए, इस फ़्लैग में बताई गई संख्या से ज़्यादा वर्कर्स हो सकते हैं. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "Host_CPUS*.5". 'ऑटो', मशीन की क्षमता के आधार पर उचित डिफ़ॉल्ट का हिसाब लगाता है. "=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 आवश्यक पहलू प्रदाताओं के लिए आवश्यक_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: लॉग मैसेज जनरेट करें जैसे कि 'सामान्य' पास किया गया हो, लेकिन असल में कोई फ़ाइलसिस्टम ऑपरेशन न करें (टूल के लिए काम का है). ध्यान दें कि सिर्फ़ उन सिमलिंक पर असर पड़ सकता है जिनके नाम -simlink_prefix की मौजूदा वैल्यू से जनरेट हुए हैं. अगर प्रीफ़िक्स में बदलाव होता है, तो पहले से मौजूद कोई भी सिमलिंक छोड़ दिए जाएंगे.
टैग: affects_outputs

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

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

--remote_download_all

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

टैग: affects_outputs

--remote_download_minimal

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

टैग: affects_outputs

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

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

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

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

--remote_download_toplevel

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

टैग: affects_outputs

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

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

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

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

अगर यह विकल्प चालू है, तो कार्रवाइयां चलाते समय Bazel, 'docker run' को --privileged फ़्लैग पास करेगा. इसकी ज़रूरत आपके बिल्ड के लिए पड़ सकती है, लेकिन इससे हरमैटिटी कम हो सकती है.
टैग: execution

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

कोई कार्रवाई नहीं करना
टैग: host_machine_resource_optimizations, execution

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

अगर इसे 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स की गई रणनीति से लोकल रणनीति पर, लेगसी इंप्लिसिट फ़ॉलबैक चालू हो जाता है. यह फ़्लैग आखिर में डिफ़ॉल्ट रूप से 'गलत' पर सेट हो जाएगा और फिर काम नहीं करेगा. फ़ॉलबैक कॉन्फ़िगर करने के लिए, --strategy, --spawn_strategy या --dynamic_local_strategy का इस्तेमाल करें.
टैग: execution, incompatible_change

--sandbox_add_mount_pair=<a single path or a 'source:target' pair> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सैंडबॉक्स में माउंट करने के लिए, अतिरिक्त पाथ पेयर जोड़ें.
टैग: execution

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

सैंडबॉक्स की गई कार्रवाइयों के लिए, इस पाथ को ऐक्सेस करने की अनुमति न दें.
टैग: execution

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

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

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

सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग: execution

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

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

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

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

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

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

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट नहीं है, तो उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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

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

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

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

अगर कोई टेस्ट पूरा नहीं हो पाता है, तो तय की गई संख्या तक हर टेस्ट को फिर से आज़माया जाएगा. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश की गई है उन्हें टेस्ट की खास जानकारी में 'अमान्य' के तौर पर मार्क किया जाता है. आम तौर पर, दी गई वैल्यू सिर्फ़ एक पूर्णांक या स्ट्रिंग 'default' होती है. अगर यह एक पूर्णांक है, तो सभी टेस्ट N बार तक चलाए जाएंगे. अगर 'डिफ़ॉल्ट' है, तो सामान्य टेस्ट के लिए सिर्फ़ एक बार टेस्ट किया जाएगा. वहीं, नियम (flaky=1 एट्रिब्यूट) के हिसाब से, 'अमान्य' के तौर पर मार्क किए गए टेस्ट के लिए तीन बार टेस्ट किया जाएगा. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. यहां flaky_test_attempts ऊपर बताए गए तरीके से है और regex_filter, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. साथ ही, --runs_per_test भी देखें. उदाहरण: --flaky_test_attempts=//foo/.*,-//foo/bar/.*@3, //foo/ में सभी टेस्ट को डिफ़ेक करता है. हालांकि, foo/bar में मौजूद टेस्ट को तीन बार डिफ़ेक करता है. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. हाल ही में पास किए गए आर्ग्युमेंट को प्राथमिकता दी जाती है. अगर कुछ भी मैच नहीं करता है, तो व्यवहार ऊपर 'डिफ़ॉल्ट' के तौर पर दिखेगा.
टैग: execution

--local_test_jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

एक साथ चलने वाली लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, एक साथ चलाए जाने के लिए लोकल टेस्ट जॉब की संख्या को सीमित कर देगा. --jobs की वैल्यू से ज़्यादा वैल्यू सेट करने का कोई फ़ायदा नहीं है.
टैग: execution

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

बंद होने पर, अगर कोई टेस्ट पास नहीं होता है, तो पूरा बिल्ड बंद हो जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट चलाए जाते हैं. भले ही, कुछ टेस्ट पास न हों.
टैग: execution

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

यह बताता है कि टेस्ट चलाने के लिए किस रणनीति का इस्तेमाल करना है.
टैग: execution

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

यह 'baज़ल टेस्ट' के लिए, बेस अस्थायी डायरेक्ट्री का इस्तेमाल करता है.

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

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

No-op.

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

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

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

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

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

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

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

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

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.bagel में `dev_dependency` के तौर पर एलान किए गए `bagel_dep` और `use_extension` को अनदेखा करता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को हमेशा MODULE.bazu में अनदेखा किया जाता है.
टैग: 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

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

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

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <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"

Bazel के लिए उपलब्ध स्थानीय सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह एक पूर्णांक या "Host_CPUS" लेता है. इसके बाद, विकल्प के तौर पर [-|*]<float> का इस्तेमाल किया जाता है (उदाहरण के लिए, HOST_CPUS*.5, उपलब्ध सीपीयू कोर के आधे हिस्से का इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, ("HOST_CPUS") Bazel, उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
टैग: host_machine_resource_optimizations

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

Bazel के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. स्ट्रिंग-फ़्लोट पेयर को इस्तेमाल करता है. एक से ज़्यादा तरह के अतिरिक्त संसाधनों की जानकारी देने के लिए, कई बार इस्तेमाल किया जा सकता है. Bazel, उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों की संख्या को सीमित कर देगा. टेस्ट, "resources:<resoucename>:<amount>" फ़ॉर्मैट के टैग का इस्तेमाल करके, यह बता सकते हैं कि उन्हें कितने अतिरिक्त संसाधनों की ज़रूरत है. इस फ़्लैग की मदद से, उपलब्ध सीपीयू, रैम, और संसाधनों को सेट नहीं किया जा सकता.
टैग: host_machine_resource_optimizations

--local_ram_resources=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_RAM*.67"

Bazel के लिए, स्थानीय होस्ट की कुल रैम (एमबी में) को साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_RAM" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_RAM*.5, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, ("HOST_RAM*.67") के लिए, Bazel उपलब्ध रैम की मात्रा का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और उसका 67% इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations

--local_resources=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> बार इस्तेमाल किए गए

Bazel के लिए उपलब्ध संसाधनों की संख्या सेट करें. यह फ़्लोट या HOST_RAM/HOST_CPUS में असाइनमेंट लेता है. इसके बाद, [-|*]<float> का इस्तेमाल किया जा सकता है. उदाहरण के लिए, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए, memory=HOST_RAM*.5. अलग-अलग तरह के संसाधनों के बारे में बताने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. उपलब्ध संसाधनों और ज़रूरी संसाधनों के हिसाब से, Baze एक साथ चलने वाली कार्रवाइयों को सीमित कर देगा. टेस्ट में "संसाधन:<संसाधन का नाम>:<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 इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि रिटेंन की गई हेप का प्रतिशत, --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 के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि रिटेंन की गई हेप का प्रतिशत, --skyframe_high_water_mark_threshold सेट की गई सीमा से ज़्यादा है, तो मामूली GC इवेंट होने पर, वह हर बार इस सीमा तक अनावश्य Skyframe स्टेटस को छोड़ देगा. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

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

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

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

--[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 को दिया है, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, --incompatible_remote_use_new_exit_code_for_lost_inputs फ़्लैग सेट करें और एग्ज़िट कोड 39 देखें.
टैग: execution

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

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

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

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

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

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

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

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

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

रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाना है. काम करने वाले स्कीमा grpc, grpcs (TLS चालू होने वाला grpc) और Unix (स्थानीय UNIX सॉकेट) हैं. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. यहां देखें: https://github.com/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 डिफ़ॉल्ट: "गलत"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो 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_dir (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --incompatible_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 के रेफ़रंस वाले सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड हो जाते हैं. अगर 'कम से कम' पर सेट किया जाता है, तो बीईपी से मिले लोकल आउटपुट, रिमोट कैश में अपलोड नहीं किए जाते. हालांकि, बीईपी के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों (जैसे, टेस्ट लॉग और टाइम प्रोफ़ाइल) को छोड़कर, 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_property को सेट नहीं करता हो, तो रिमोट एक्ज़िक्यूशन एपीआई के लिए, डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी को सेट करें. अगर होस्ट प्लैटफ़ॉर्म को रिमोट तौर पर चलाने के लिए, एक्सीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना जाता है, तो इस वैल्यू का इस्तेमाल भी किया जाएगा.

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

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

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

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

अगर बिल्ड सिस्टम में बदलाव की वजह से विश्लेषण की कैश मेमोरी को खारिज किया जाता है, तो इस विकल्प को 'गलत है' पर सेट करने से, बिल्ड जारी रखने के बजाय बैकल बंद हो जाएगा. 'discard_analysis_cache' सेट होने पर, इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit

--auto_output_filter=<none, all, packages or subpackages> डिफ़ॉल्ट: "none"

अगर --output_filter की वैल्यू नहीं दी गई है, तो इस विकल्प की वैल्यू का इस्तेमाल करके, अपने-आप फ़िल्टर बन जाता है. इस विकल्प के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: 'none' (कुछ भी फ़िल्टर न करें / सब कुछ दिखाएं), 'all' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'packages' (Blaze कमांड लाइन पर बताए गए पैकेज में नियमों का आउटपुट शामिल करें), और 'subpackages' ('packages' की तरह, लेकिन इसमें सब-पैकेज भी शामिल हैं). 'पैकेज' और 'सबपैकेज' वैल्यू के लिए //java/foo और //javatests/foo को एक पैकेज माना जाता है)'.

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

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

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

कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प का असर, 'test' कमांड के साथ चलाए गए टेस्ट के सेट पर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों से कंट्रोल किए जाते हैं. उदाहरण के लिए, '--test_tag_filters'

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

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

--combined_report=<none or lcov> डिफ़ॉल्ट: "कोई नहीं"

यह बताता है कि कवरेज की कुल रिपोर्ट किस तरह की होनी चाहिए. फ़िलहाल, सिर्फ़ एलसीओवी ही काम करता है.

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

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

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

पैकेज के नाम की ऐसी सूची जिसमें बिल्ड सिस्टम मौजूद नहीं होता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह शिकायत कर सकता है. ऐसा तब होता है, जब वह लेबल अब भी किसी अन्य package_path एंट्री से दिया जाता है. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

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

विश्लेषण का चरण पूरा होने के तुरंत बाद, विश्लेषण की कैश मेमोरी मिटाएं. इससे, मेमोरी के इस्तेमाल को ~10% तक कम किया जा सकता है. हालांकि, इससे ऐप्लिकेशन की रफ़्तार धीमी हो जाती है.

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

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

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

सोर्स कंट्रोल में बदलाव करने की सुविधा या रिलीज़ लेबल को बाइनरी में एम्बेड करें

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

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में, चलाए गए स्पैन को लंबाई के हिसाब से बांटा गया SpawnExec प्रोटो के तौर पर लॉग करें. --execution_log_compact_file को प्राथमिकता दें, क्योंकि यह काफ़ी छोटी होती है और इसे बनाने में कम खर्च आता है. मिलते-जुलते फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

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

इस फ़ाइल में, जो स्पॉन्स किए गए हैं उन्हें src/main/protobuf/spawn.proto के मुताबिक, लंबे समय तक सीमांकित exeLogEntry प्रोटो के तौर पर लॉग करें. पूरी फ़ाइल को zstd से कंप्रेस किया गया है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --subcommands (टर्मिनल आउटपुट में सबकमैंड दिखाने के लिए).

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

src/main/protobuf/spawn.proto के मुताबिक, SpawnExec प्रोटो के न्यूलाइन डीलिमिटेड JSON रिप्रज़ेंटेशन के तौर पर, इस फ़ाइल में लॉन्च किए गए स्पैन को लॉग करें. --execution_log_compact_file को प्राथमिकता दें, क्योंकि यह काफ़ी छोटी होती है और इसे बनाने में कम खर्च आता है. इससे जुड़े फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_binary_file (बाइनरी प्रोटोबस फ़ॉर्मैट; दोनों एक साथ इस्तेमाल नहीं किए जा सकते), --execution_log_sort (एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सब-कमांड दिखाने के लिए).

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

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

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

विश्लेषण से पहले, test_suite टारगेट को उनके कॉम्पोनेंट टेस्ट में बड़ा करें. जब इस फ़्लैग को चालू (डिफ़ॉल्ट) किया जाता है, तो टेस्ट सुइट से जुड़े टेस्ट पर नेगेटिव टारगेट पैटर्न लागू होंगे, नहीं तो वे नहीं होंगे. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड लाइन पर टॉप-लेवल के पहलुओं को लागू किया जाता है: इसके बाद वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग: loading_and_analysis

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

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

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

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

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

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

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

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

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

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

--experimental_spawn_scheduler

कार्रवाइयों को स्थानीय तौर पर या रिमोट तरीके से साथ-साथ चलाकर, डाइनैमिक एक्ज़ीक्यूशन की सुविधा चालू करें. Bazel, हर कार्रवाई को स्थानीय और रिमोट तौर पर शुरू करता है. साथ ही, वह उस कार्रवाई को चुनता है जो सबसे पहले पूरी होती है. अगर कोई कार्रवाई कर्मियों के साथ काम करती है, तो लोकल कार्रवाई परसिस्टेंट वर्कर मोड में होगी. किसी एक ऐक्शन के लिए डाइनैमिक तरीके से प्रोसेस करने की सुविधा चालू करने के लिए, `--internal_spawn_scheduler` और `--strategy=<mnemonic>=dynamic` फ़्लैग का इस्तेमाल करें.
इसे बड़ा किया जाता है:
  --internal_spawn_scheduler
  --spawn_strategy=dynamic

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

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

--[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% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

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

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

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

यह टेस्ट की जाने वाली भाषाओं की सूची होती है. इसमें भाषाओं को कॉमा लगाकर अलग किया जाता है. जिन भाषाओं के लिए अनुवाद नहीं करना है उनके लिए, हर भाषा के पहले '-' लगाया जा सकता है. केवल वही परीक्षण लक्ष्य मिलेंगे जो निर्दिष्ट भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test नियम में भाषा के प्रीफ़िक्स जैसा ही होना चाहिए. जैसे, 'cc', 'java', 'py' वगैरह में से कोई एक. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.

--test_size_filters=<comma-separated list of values: small, medium, large or enormous> डिफ़ॉल्ट: ""

यह टेस्ट साइज़ की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए साइज़ तय करने के लिए, हर साइज़ से पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. केवल वही परीक्षण लक्ष्य मिलेंगे, जिनमें कम से कम एक शामिल किया गया आकार होता है और उनमें कोई भी बहिष्कृत आकार शामिल नहीं होता. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

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

टेस्ट टैग की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. केवल वही परीक्षण लक्ष्य मिलेंगे, जिनमें कम से कम एक शामिल किया गया टैग शामिल होगा और उनमें कोई भी बहिष्कृत टैग शामिल नहीं होगा. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: ""

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

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

यह एक ऐसा निर्देश है जिसे बिल्ड की शुरुआत में ट्रिगर किया जाता है. इससे, की/वैल्यू पेयर के तौर पर, वर्कस्पेस की स्थिति की जानकारी मिलती है. पूरी जानकारी के लिए उपयोगकर्ता गाइड देखें. उदाहरण के लिए, tools/buildstamp/get_workspace_status भी देखें.

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

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

बिल्ड न करें, सिर्फ़ यह देखें कि यह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड पूरा हो जाता है. अगर किसी चरण को पूरा करने की ज़रूरत है, तो गड़बड़ी की सूचना दी जाती है और बिल्ड फ़ेल हो जाता है.
टैग: execution

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

अगर यह फ़्लैग सेट है और टेस्ट ऐक्शन से test.xml फ़ाइल जनरेट नहीं होती है, तो Baze, टेस्ट लॉग वाली एक डमी test.xml फ़ाइल जनरेट करने के लिए अलग ऐक्शन का इस्तेमाल करता है. ऐसा न होने पर, Basel की टेस्ट ऐक्शन फ़ाइल के तौर पर 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> डिफ़ॉल्ट: ""

genrules को लागू करने का तरीका बताएं. इस फ़्लैग को बंद कर दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> या सिर्फ़ जनरेटिव नियमों को कंट्रोल करने के लिए --strategy=Genrule=<value> का इस्तेमाल करें.
टैग: 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

--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". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

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

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

--persistent_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

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

टैग: host_machine_resource_optimizations, execution

--[no]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 (और अगर याद रखने के लिए जेनरिक नियम के साथ इस्तेमाल किया गया है, तो --gen सकारात्मक_strategy) से सेट की गई वैल्यू बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazel.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 टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए जाते हैं, तो बाइनरी एक फ़ैट APK होती है. इसमें, टारगेट किए गए हर प्लैटफ़ॉर्म के लिए नेटिव बाइनरी होती हैं.
टैग: 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> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

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

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

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

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

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

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

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

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

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

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

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

--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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

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

अगर टूलचेन काम करता है, तो इंटरफ़ेस के शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, ईएलएफ़ टूलचेन में यह सेटिंग काम करती है.
टैग: 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> डिफ़ॉल्ट: "@bagel_tools//tools/cpp:host_xcodes"

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

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

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

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

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

बिल्ड का इस्तेमाल करें; यह आम तौर पर होने वाला तरीका है. --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 API वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: 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://bazel.build/extending/rules#runfiles_features_to_avoid).
टैग: affects_outputs, incompatible_change

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर साफ़ तौर पर बताया गया है, तो Basel, जनरेट की गई फ़ाइलों के कवरेज की जानकारी भी जनरेट करेगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks डिफ़ॉल्ट: "normal"

यह फ़्लैग कंट्रोल करता है कि सुविधा सिमलिंक (बिल्ड के बाद, फ़ाइल फ़ोल्डर में दिखने वाले सिमलिंक) कैसे मैनेज किए जाएंगे. संभावित वैल्यू: सामान्य (डिफ़ॉल्ट): हर तरह का सुविधाजनक सिंबललिंक बनाया या मिटाया जाएगा. यह, बिल्ड के हिसाब से तय किया जाएगा. साफ़ करें: सभी सिमलिंक बिना किसी शर्त के मिटा दिए जाएंगे. ignore: इससे सिमलिनक नहीं हटेंगे. log_only: लॉग मैसेज जनरेट करें, जैसे कि 'normal' पास किया गया हो. हालांकि, फ़ाइल सिस्टम पर कोई कार्रवाई न करें. यह टूल के लिए काम का है. ध्यान दें कि सिर्फ़ उन सिमलिंक पर असर पड़ सकता है जिनके नाम -simlink_prefix की मौजूदा वैल्यू से जनरेट हुए हैं. अगर प्रीफ़िक्स में बदलाव होता है, तो पहले से मौजूद कोई भी सिमलिंक छोड़ दिए जाएंगे.
टैग: affects_outputs

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

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

एक्ज़ीक्यूटिव कॉन्फ़िगरेशन में बनाए गए टूल के लिए, 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/bazibuild/batz/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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह प्रीफ़िक्स, बिल्ड के बाद बनाए जाने वाले किसी भी सुविधा सिमलिंक के पहले जोड़ा जाता है. अगर इसे छोड़ दिया जाता है, तो डिफ़ॉल्ट वैल्यू के तौर पर बिल्ड टूल का नाम होता है, जिसके बाद हाइफ़न होता है. अगर '/' पास किया जाता है, तो कोई सिमलिंक नहीं बनाया जाता और कोई चेतावनी नहीं भेजी जाती. चेतावनी: '/' के लिए खास फ़ंक्शन जल्द ही रोक दिया जाएगा; इसके बजाय --experimental_Convenience_simlinks=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_ऑप्टिमाइज़/--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> डिफ़ॉल्ट: "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> डिफ़ॉल्ट: जानकारी देखें

लागू करने के दौरान, अनुमति वाली सूची (पैकेज_ग्रुप टारगेट) का इस्तेमाल करें --inबेमेल_python_disallow_native_rules.
टैग: loading_and_analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट नहीं है, तो उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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

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

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

अगर इसकी वैल्यू 'सही' है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट इस्तेमाल करने की अनुमति नहीं दें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की सेटिंग दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को 'सही' पर सेट करें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो पहले से मौजूद py_* नियमों का इस्तेमाल करते समय गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर सही है, तो टारगेट टारगेट के लिए विश्लेषण में गड़बड़ी होने पर, टारगेट में विश्लेषणFailureInfo के उस इंस्टेंस को लागू किया जाता है जिसमें गड़बड़ी की जानकारी होती है. इससे ऐप्लिकेशन बनाने में गड़बड़ी होती है.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. अगर उपयोगकर्ता ने यह सीमा पार नहीं की, तो नियम में गड़बड़ी होगी.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental

--[no]check_tests_up_to_date डिफ़ॉल्ट: "गलत"

जांच न करें. सिर्फ़ यह देख लें कि वे अप-टू-डेट हैं या नहीं. अगर सभी जांच के नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर किसी टेस्ट को बनाने या चलाने की ज़रूरत है, तो गड़बड़ी की रिपोर्ट की जाती है और टेस्ट पूरा नहीं होता. इस विकल्प का मतलब है कि --check_up_to_date का इस्तेमाल किया जा रहा है.
टैग: execution

--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

--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

--[no]ios_memleaks डिफ़ॉल्ट: "गलत"

ios_test टारगेट में, मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है, जैसे कि 'iPhone 6'. डिवाइसों की सूची पाने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला iOS वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--local_test_jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "ऑटो"

एक साथ चलाने के लिए लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. इसमें कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") डाला जा सकता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) डाला जा सकता है. उदाहरण के लिए: "auto", "HOST_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, एक साथ चलाए जाने के लिए लोकल टेस्ट जॉब की संख्या को सीमित कर देगा. --jobs की वैल्यू से ज़्यादा वैल्यू सेट करने का कोई फ़ायदा नहीं है.
टैग: execution

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इससे पता चलता है कि हर टेस्ट को कितनी बार चलाया जाना चाहिए. अगर इनमें से किसी भी कोशिश में किसी वजह से सफलता नहीं मिलती है, तो पूरे टेस्ट को असफल माना जाता है. आम तौर पर, डाली गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 सभी जांच तीन बार चलेगा. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test, पूर्णांक वैल्यू के लिए है और regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name=value' assignment with an optional value part> बार इस्तेमाल किए गए

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैरिएबल की वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.
टैग: test_runner

--[no]test_keep_going डिफ़ॉल्ट: "सही"

अगर यह विकल्प बंद है, तो कोई भी टेस्ट पास न होने पर पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट चलाए जाते हैं. भले ही, कुछ टेस्ट पास न हों.
टैग: execution

--test_strategy=<a string> डिफ़ॉल्ट: ""

यह बताता है कि टेस्ट करते समय किस रणनीति का इस्तेमाल करना है.
टैग: execution

--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1"

टेस्ट टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए गए हैं, तो वे टाइम आउट को छोटे, सामान्य, लंबे, और अनंत (इसी क्रम में) के लिए बदल देंगे. दोनों ही फ़ॉर्म में, -1 की वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहा जाता है.

--test_tmpdir=<a path> डिफ़ॉल्ट: जानकारी देखें

'bazel test' के इस्तेमाल के लिए, बेस टेम्पररी डायरेक्ट्री तय करता है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही"

अगर यह सही है, तो बिना एलान किए किए गए टेस्ट आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--cache_computed_file_digests=<a long integer> डिफ़ॉल्ट: "50000"

अगर यह वैल्यू 0 से ज़्यादा है, तो Bazel को मेमोरी में फ़ाइल डाइजेस्ट को कैश मेमोरी में सेव करने के लिए कॉन्फ़िगर किया जाता है. ऐसा करने पर, हर बार डिस्क से डाइजेस्ट को फिर से कैलकुलेट करने की ज़रूरत नहीं पड़ती. इसे 0 पर सेट करने से, यह पक्का किया जाता है कि नतीजे सही हों. ऐसा इसलिए, क्योंकि फ़ाइल के मेटाडेटा में किए गए सभी बदलावों को नहीं देखा जा सकता. अगर 0 नहीं है, तो संख्या कैश मेमोरी के साइज़ को दिखाती है, क्योंकि यह संख्या कैश मेमोरी में सेव की जाने वाली फ़ाइलों की संख्या होती है.

--[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

--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "HOST_CPUS"

Bazel के लिए उपलब्ध स्थानीय सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें, ताकि स्थानीय तौर पर की जाने वाली बिल्ड ऐक्शन पर खर्च किया जा सके. यह फ़ंक्शन कोई पूर्णांक या "HOST_CPUS" लेता है. इसके बाद, [-|*]<float> (उदाहरण के लिए, HOST_CPUS*.5, उपलब्ध सीपीयू कोर के आधे हिस्से का इस्तेमाल करने के लिए). डिफ़ॉल्ट रूप से, ("HOST_CPUS") Bazel, उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
टैग: host_machine_resource_optimizations

--local_extra_resources=<a named float, 'name=value'> बार इस्तेमाल किए गए

Bज़ल के लिए उपलब्ध अतिरिक्त संसाधनों की संख्या सेट करें. स्ट्रिंग-फ़्लोट पेयर को इस्तेमाल करता है. एक से ज़्यादा तरह के अतिरिक्त संसाधनों की जानकारी देने के लिए, कई बार इस्तेमाल किया जा सकता है. उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर, Basel की प्रोसेस एक साथ चलने वाली कार्रवाइयों को सीमित करती है. टेस्ट, "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"), Babel उपलब्ध रैम का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और उसके 67% हिस्से का इस्तेमाल करेगा.
टैग: host_machine_resource_optimizations

--local_resources=<a named double, 'name=value', where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Bazel के लिए उपलब्ध संसाधनों की संख्या सेट करें. किसी असाइनमेंट को फ़्लोट या Host_RAM/Host_CPUS पर ले जाता है. इसके बाद, [-|*]<float> का इस्तेमाल किया जाता है (उदाहरण के लिए, उपलब्ध रैम का आधा इस्तेमाल करने के लिए, मेमोरी=Host_RAM*.5). अलग-अलग तरह के संसाधनों की जानकारी देने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. Bazel, उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों की संख्या को सीमित कर देगा. टेस्ट में "संसाधन:<संसाधन का नाम>:<amount>" फ़ॉर्मैट का टैग इस्तेमाल करके, यह बताया जा सकता है कि उन्हें कितने संसाधनों की ज़रूरत है. --local_{cpu|ram|extra}_resources से तय किए गए संसाधनों को बदल देता है.
टैग: host_machine_resource_optimizations

--[no]objc_use_dotd_pruning डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो clang से जनरेट की गई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग की सुविधा चालू हो.
टैग: execution

--[no]trim_test_configuration डिफ़ॉल्ट: "सही"

चालू होने पर, बिल्ड के टॉप लेवल के नीचे जांच से जुड़े विकल्प मिटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को बिना टेस्ट वाले नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने पर, बिना टेस्ट वाले नियमों का फिर से विश्लेषण नहीं किया जाएगा.
टैग: loading_and_analysis, loses_incremental_state

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत"

TargetSummary इवेंट पब्लिश करने हैं या नहीं.

--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs

--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट फ़ाइलें दिखाते समय, BEP में रिलेटिव फ़ाइलसेट के लिंक को पूरी तरह से हल करें. --experimental_build_event_expand_filesets की ज़रूरत है.
टैग: affects_outputs

--experimental_build_event_upload_max_retries=<an integer> डिफ़ॉल्ट: "4"

Bazel को बिल्ड इवेंट को अपलोड करने की कोशिश कितनी बार करनी चाहिए.
टैग: bazel_internal_configuration

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> डिफ़ॉल्ट: "1s"

बीईपी अपलोड न हो पाने पर, एक्सपोनेंशियल बैकऑफ़ की वजह से होने वाली शुरुआती देरी. (एक्सपोनेंट: 1.6)
टैग: bazel_internal_configuration

--experimental_build_event_upload_strategy=<a string> डिफ़ॉल्ट: जानकारी देखें

इस विकल्प से, बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुना जाता है.
टैग: affects_outputs

--[no]experimental_materialize_param_files_directly डिफ़ॉल्ट: "गलत"

अगर पैरामीटर फ़ाइलों को मेटालाइज़ किया जा रहा है, तो डिस्क में सीधे लिखकर ऐसा करें.
टैग: execution

--[no]experimental_run_bep_event_include_residue डिफ़ॉल्ट: "गलत"

रन बिल्ड इवेंट में कमांड-लाइन के अवशेष शामिल करने हैं या नहीं. डिफ़ॉल्ट रूप से, रन कमांड वाले उन बिल्ड इवेंट में अवशेष शामिल नहीं किए जाते जिनमें अवशेष हो सकते हैं.
टैग: affects_outputs

--[no]experimental_stream_log_file_uploads डिफ़ॉल्ट: "गलत"

लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग: affects_outputs

--explain=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इस वजह से, बिल्ड सिस्टम बिल्ड के चलाए गए हर चरण के बारे में जानकारी देता है. जानकारी, बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग: affects_outputs

--[no]legacy_important_outputs डिफ़ॉल्ट: "सही"

TargetComplete इवेंट में लेगसी key_आउटपुट फ़ील्ड जनरेट करने की प्रोसेस को बंद करने के लिए, इसका इस्तेमाल करें. Basel से नतीजेStore इंटिग्रेशन के लिए, legal_Outputs ज़रूरी है.
टैग: affects_outputs

--[no]materialize_param_files डिफ़ॉल्ट: "गलत"

रिमोट ऐक्शन एक्सीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें लिखता है. कार्रवाइयों को डीबग करने में मदद मिलती है. --subcommands और --verbose_failures से यह पता चलता है.
टैग: execution

--max_config_changes_to_show=<an integer> डिफ़ॉल्ट: "3"

बिल्ड के विकल्पों में बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नामों की तय संख्या तक दिखाता है. अगर दी गई संख्या -1 है, तो बदले गए सभी विकल्प दिखाए जाएंगे.
टैग: terminal_output

--max_test_output_bytes=<an integer> डिफ़ॉल्ट: "-1"

यह हर टेस्ट लॉग का ज़्यादा से ज़्यादा साइज़ तय करता है. यह साइज़ तब जनरेट किया जा सकता है, जब --test_output 'errors' या 'all' हो. यह विकल्प, बहुत ज़्यादा गड़बड़ी वाले टेस्ट आउटपुट से आउटपुट को भरने से रोकने के लिए मददगार होता है. लॉग के साइज़ में टेस्ट हेडर शामिल होता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट या तो पूरा होता है या नहीं होता.
टैग: test_runner, terminal_output, execution

--output_filter=<a valid Java regular expression> डिफ़ॉल्ट: जानकारी देखें

सिर्फ़ उन नियमों के लिए चेतावनियां और कार्रवाई के आउटपुट दिखाता है जिनका नाम, दिए गए रेगुलर एक्सप्रेशन से मेल खाता है.
टैग: affects_outputs

--progress_report_interval=<an integer in 0-3600 range> डिफ़ॉल्ट: "0"

अभी चल रहे जॉब की रिपोर्ट के बीच इंतज़ार करने के लिए सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद, फिर 30 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, प्रोग्रेस हर मिनट में एक बार रिपोर्ट की जाएगी. --curses चालू होने पर, प्रोग्रेस हर सेकंड रिपोर्ट की जाती है.
टैग: affects_outputs

--show_result=<an integer> डिफ़ॉल्ट: "1"

बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए बताएं कि उसे अप-टू-डेट किया गया था या नहीं. अगर हां, तो बनाई गई आउटपुट फ़ाइलों की सूची भी बताएं. प्रिंट की गई फ़ाइलें, शेल में कॉपी करके चिपकाने के लिए आसान स्ट्रिंग होती हैं, ताकि उन्हें चलाया जा सके. इस विकल्प के लिए, पूर्णांक आर्ग्युमेंट की ज़रूरत होती है. यह टारगेट की थ्रेशोल्ड संख्या होती है. इस थ्रेशोल्ड से ज़्यादा होने पर, नतीजों की जानकारी नहीं छपी जाती. इसलिए, शून्य की वैल्यू देने पर मैसेज नहीं दिखता और MAX_INT की वैल्यू देने पर नतीजा हमेशा दिखता है. डिफ़ॉल्ट रूप से, एक होता है. अगर किसी टारगेट के लिए कुछ भी नहीं बनाया गया है, तो आउटपुट को थ्रेशोल्ड के तहत रखने के लिए, उसके नतीजों को हटाया जा सकता है.
टैग: affects_outputs

--[no]subcommands [-s] डिफ़ॉल्ट: "false"

बिल्ड के दौरान चलाए गए सब-कमांड दिखाएं. मिलते-जुलते फ़्लैग: --execution_log_json_file, --execution_log_binary_file (टूल के हिसाब से फ़ॉर्मैट में, सब-कमांड को फ़ाइल में लॉग करने के लिए).
टैग: terminal_output

--test_output=<summary, errors, all or streamed> डिफ़ॉल्ट: "खास जानकारी"

पसंदीदा आउटपुट मोड के बारे में बताता है. सिर्फ़ टेस्ट की स्थिति की खास जानकारी दिखाने के लिए 'खास जानकारी', टेस्ट पास न होने पर टेस्ट लॉग भी प्रिंट करने के लिए 'गड़बड़ियां', सभी टेस्ट के लॉग प्रिंट करने के लिए 'सभी', और सभी टेस्ट के लॉग रीयल टाइम में दिखाने के लिए 'स्ट्रीम की गई'. इससे, --test_strategy की वैल्यू के बावजूद, टेस्ट को एक बार में एक करके स्थानीय तौर पर चलाया जाएगा.
टैग: test_runner, terminal_output, execution

--test_summary=<short, terse, detailed, none or testcase> डिफ़ॉल्ट: "short"

यह टेस्ट की खास जानकारी के लिए, मनचाहा फ़ॉर्मैट तय करता है. मान्य वैल्यू: 'short', सिर्फ़ चलाए गए टेस्ट की जानकारी प्रिंट करने के लिए, 'terse', सिर्फ़ उन टेस्ट की जानकारी प्रिंट करने के लिए जो पूरे नहीं हुए, 'detailed', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'testcase', टेस्ट केस के नतीजों की खास जानकारी प्रिंट करने के लिए, 'none', खास जानकारी को हटाने के लिए.
टैग: terminal_output

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान, डीबग की जानकारी प्रिंट करें. इस फ़्लैग में रेगुलर एक्सप्रेशन का इस्तेमाल किया जाता है. इस एक्सप्रेशन की जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता लगाया जा सके कि किस टूल को डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. ऐसा हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए ही काम का हो.
टैग: terminal_output

--[no]verbose_explanations डिफ़ॉल्ट: "गलत"

--explain चालू होने पर, दी गई जानकारी को ज़्यादा शब्दों में दिखाता है. अगर --explain चालू नहीं है, तो इसका कोई असर नहीं पड़ता.
टैग: affects_outputs

--[no]verbose_failures डिफ़ॉल्ट: "गलत"

अगर कोई निर्देश काम नहीं करता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--aspects_parameters=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कमांड-लाइन के आसपेक्ट पैरामीटर की वैल्यू तय करता है. हर पैरामीटर की वैल्यू, <param_name>=<param_value> के ज़रिए तय की जाती है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param', --aspects सूची में किसी पहलू का पैरामीटर है या सूची में किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. हालांकि, एक ही पैरामीटर को एक से ज़्यादा बार वैल्यू असाइन करने की अनुमति नहीं है.
टैग: loading_and_analysis

--flag_alias=<a 'name=value' flag alias> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्टारलार्क फ़्लैग के लिए शॉर्टहैंड नाम सेट करता है. यह तर्क के रूप में "<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 टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, `--incompatible_py3_is_default` को भी चालू करने का सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर सही है, तो `py_binary` और `py_test` टारगेट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे PY2 के बजाय डिफ़ॉल्ट रूप से PY3 पर सेट हो जाएंगे. अगर आपने इस फ़्लैग को सेट किया है, तो हमारा सुझाव है कि `--insupported_py2_inputs_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

--target_pattern_file=<a string> डिफ़ॉल्ट: ""

अगर सेट किया जाता है, तो बिल्ड कमांड लाइन के बजाय, यहां दी गई फ़ाइल के पैटर्न को पढ़ेगा. यहां फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न भी बताना गलत है.
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_remote_cache_eviction_retries=<an integer> डिफ़ॉल्ट: "0"

अगर बिल्ड में, रिमोट कैश मेमोरी से जुड़ी कोई ऐसी गड़बड़ी आती है जिसकी वजह से बिल्ड पूरा नहीं हो पाता, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. उदाहरण के लिए, जब आर्टफ़ैक्ट को रिमोट कैश मेमोरी से हटाया जाता है या कैश मेमोरी में कुछ गड़बड़ी होती है, तब यह लागू होता है. शून्य से ज़्यादा की वैल्यू से, --incompatible_remote_use_new_exit_code_for_lost_inputs को अपने-आप 'सही' पर सेट कर दिया जाएगा. हर कोशिश के लिए, एक नया आह्वान आईडी जनरेट होगा. अगर आप न्योते का आईडी जनरेट करते हैं और उसे --invocation_id के साथ Basel को उपलब्ध कराते हैं, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, फ़्लैग --inaffiliate_remote_use_new_exit_code_for_lost_inputs सेट करें और एग्ज़िट कोड 39 देखें.
टैग: execution

--[no]incompatible_remote_use_new_exit_code_for_lost_inputs डिफ़ॉल्ट: "सही"

अगर इसे 'सही' पर सेट किया जाता है, तो कैश मेमोरी खाली करने जैसी रिमोट कैश मेमोरी से जुड़ी गड़बड़ियों की वजह से, बिल्ड पूरा न होने पर Bazel, 34 के बजाय नए एक्सिट कोड 39 का इस्तेमाल करेगा.
टैग: incompatible_change

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा गया है.:

--[no]allow_analysis_cache_discard डिफ़ॉल्ट: "सही"

अगर बिल्ड सिस्टम में हुए बदलाव की वजह से, विश्लेषण कैश मेमोरी को खारिज किया जाता है, तो इस विकल्प को 'गलत है' पर सेट करने पर, bazel बिल्ड जारी रखने के बजाय बंद हो जाएगा. अगर 'discard_analysis_cache' भी सेट है, तो इस विकल्प का कोई असर नहीं पड़ता.
टैग: eagerness_to_exit

--[no]build_manual_tests डिफ़ॉल्ट: "गलत"

'मैन्युअल' के तौर पर टैग किए गए टेस्ट टारगेट को बनाने के लिए मजबूर करता है. 'मैन्युअल' टेस्ट को प्रोसेसिंग से बाहर रखा जाता है. इस विकल्प की मदद से, उन्हें बनाने के लिए मजबूर किया जाता है, लेकिन उन्हें लागू नहीं किया जाता.

--build_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

कॉमा लगाकर अलग किए गए टैग की सूची तय करता है. बाहर रखे गए टैग तय करने के लिए, हर टैग से पहले वैकल्पिक रूप से '-' लगाया जा सकता है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प का असर, 'test' कमांड के साथ चलाए गए टेस्ट के सेट पर नहीं पड़ता. ये टेस्ट, टेस्ट फ़िल्टर करने के विकल्पों से कंट्रोल किए जाते हैं. उदाहरण के लिए, '--test_tag_filters'

--[no]build_tests_only डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चुना जाता है, तो सिर्फ़ *_test और test_suite नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर बताए गए अन्य टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.

--[no]cache_test_results [-t] डिफ़ॉल्ट: "ऑटो"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो Bazel किसी टेस्ट को फिर से सिर्फ़ तब चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट चलाने का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. 'हां' पर सेट होने पर, Bazel बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजों को कैश मेमोरी में सेव नहीं करता.

--[no]compile_one_dependency डिफ़ॉल्ट: "गलत"

आर्ग्युमेंट फ़ाइलों की एक डिपेंडेंसी को कॉम्पाइल करें. यह आईडीई में सिंटैक्स की सोर्स फ़ाइलों की जांच करने के लिए मददगार है. उदाहरण के लिए, सोर्स फ़ाइल पर निर्भर एक टारगेट को फिर से बनाकर, ताकि एडिट/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाया जा सके. इस आर्ग्युमेंट से, उन सभी आर्ग्युमेंट के इस्तेमाल के तरीके पर असर पड़ता है जो फ़्लैग नहीं हैं. ये आर्ग्युमेंट, बिल्ड करने के टारगेट के बजाय सोर्स फ़ाइल के नाम होते हैं. हर सोर्स फ़ाइल नाम के लिए, उस पर निर्भर कोई भी टारगेट बनाया जाएगा.

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, आपके क्लाइंट में x/y/BUILD को मिटाने के बाद, बिल्ड सिस्टम इसकी शिकायत कर सकता है. ऐसा तब होता है, जब उसे '//x:y/z' लेबल मिलता है. ऐसा तब होता है, जब उसे अब भी किसी दूसरी Package_path एंट्री से मिला हो. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[no]discard_analysis_cache डिफ़ॉल्ट: "गलत"

विश्लेषण का फ़ेज़ पूरा होने के तुरंत बाद, विश्लेषण कैश मेमोरी को खारिज कर दें. इससे मेमोरी के इस्तेमाल में ~10% की कमी आती है. हालांकि, इससे इंक्रीमेंटल बिल्ड धीमे होते हैं.

--execution_log_binary_file=<a path> डिफ़ॉल्ट: जानकारी देखें

इस फ़ाइल में, जो स्पॉन्स किए गए हैं उन्हें src/main/protobuf/spawn.proto के मुताबिक, लंबे समय से सीमांकित Spwn फ़ंक्शन प्रोटो के तौर पर लॉग करें. --execution_log_compact_file को प्राथमिकता दें, क्योंकि यह काफ़ी छोटी होती है और इसे बनाने में कम खर्च आता है. मिलते-जुलते फ़्लैग: --execution_log_compact_file (कॉम्पैक्ट फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_sort (एक्ज़िक्यूशन लॉग क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सबकमैंड दिखाने के लिए).

--execution_log_compact_file=<a path> डिफ़ॉल्ट: जानकारी देखें

src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में, 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

--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Blaze पहले सफल रन पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ मिलकर काम करता है.
टैग: affects_outputs, loading_and_analysis

--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: ""

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. extra_actions को शेड्यूल करने के लिए, टारगेट के सेट को फ़िल्टर करता है.

--[no]experimental_extra_action_top_level_only डिफ़ॉल्ट: "गलत"

पक्षों के पहलुओं को प्राथमिकता दी जाती है. सिर्फ़ टॉप लेवल टारगेट के लिए extra_actions शेड्यूल करता है.

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, कवरेज चलाने के दौरान हर टेस्ट के लिए, कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_generate_llvm_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> डिफ़ॉल्ट: "javaबिल्डर"

यह विकल्प Java को कंपाइल करने के लिए, कम क्लासपाथ को चालू करता है.

--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत"

--experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java लॉन्चर, उन टूल का इस्तेमाल करता है जो बिल्ड के दौरान चलाए जाते हैं.

--host_javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, javac को पास करने के लिए अतिरिक्त विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java वीएम को पास करने के कुछ और विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. गलत होने पर, शार्ड का समर्थन नहीं करने वाले टेस्ट रनर से हर शार्ड में सभी टेस्ट चल जाएंगे.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर यह 'सही' है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने पर, शेयर किए गए कैश मेमोरी का इस्तेमाल होने पर, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी सेव नहीं की जा सकती.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

J2ObjC टूल को पास करने के लिए अन्य विकल्प.

--java_debug

इसकी वजह से, किसी Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे, jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इस तरह बड़ा होता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps डिफ़ॉल्ट: "सही"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (फ़िलहाल, कंपाइल के समय क्लासपाथ) जनरेट करें.

--[no]java_header_compilation डिफ़ॉल्ट: "सही"

सीधे सोर्स से इजर कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: जानकारी देखें

यह उन क्लास की सूची जनरेट करने के लिए एक बाइनरी के बारे में बताता है जिन्हें लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होना चाहिए.

--local_termination_grace_seconds=<an integer> डिफ़ॉल्ट: "15"

टाइम आउट की वजह से किसी स्थानीय प्रोसेस को बंद करने और उसे जबरदस्ती बंद करने के बीच इंतज़ार करने का समय.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: जानकारी देखें

शर्ड किए बिना डेक्स करने के लिए इस्तेमाल की जाने वाली बाइनरी के बारे में बताता है.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--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> डिफ़ॉल्ट: "@baZ_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_SH एनवायरमेंट वैरिएबल सेट है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel काम करता है. जैसे, Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने पर, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में गड़बड़ियां हो सकती हैं.
टैग: loading_and_analysis

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--test_arg=<a string> बार इस्तेमाल किए गए

इससे उन अतिरिक्त विकल्पों और आर्ग्युमेंट की जानकारी मिलती है जिन्हें टेस्ट के लिए इस्तेमाल किए जाने वाले प्रोग्राम को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, कई बार इस्तेमाल किया जा सकता है. अगर एक से ज़्यादा टेस्ट चलाए जाते हैं, तो उनमें से हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.

--test_filter=<a string> डिफ़ॉल्ट: जानकारी देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, चलाए जाने वाले टेस्ट की संख्या को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे यह तय नहीं होता कि कौनसे टारगेट बनाए जाएं.

--test_lang_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

यह टेस्ट की जाने वाली भाषाओं की सूची होती है. इसमें भाषाओं को कॉमा लगाकर अलग किया जाता है. जिन भाषाओं के लिए अनुवाद नहीं करना है उनके लिए, हर भाषा के पहले '-' लगाया जा सकता है. सिर्फ़ वे टेस्ट टारगेट दिखेंगे जो चुनी गई भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया गया नाम, *_test नियम में भाषा के प्रीफ़िक्स जैसा ही होना चाहिए. जैसे, 'cc', 'java', 'py' वगैरह में से कोई एक. इस विकल्प से, --build_tests_only के व्यवहार और टेस्ट कमांड पर असर पड़ता है.

--test_result_expiration=<an integer> डिफ़ॉल्ट: "-1"

इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "गलत"

टेस्ट रनर के लिए, फ़ॉरवर्ड तेज़ होने का विकल्प नहीं मिलता. टेस्ट रनर को पहली बार फ़ेल होने पर, टेस्ट को रोक देना चाहिए.

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> डिफ़ॉल्ट: "अश्लील"

टेस्ट के लिए, शार्डिंग की रणनीति तय करें: 'explicit', ताकि सिर्फ़ तब शार्डिंग का इस्तेमाल किया जा सके, जब 'shard_count' BUILD एट्रिब्यूट मौजूद हो. 'बंद है', ताकि टेस्ट के लिए डेटा को अलग-अलग हिस्सों में बांटने की सुविधा का कभी भी इस्तेमाल न किया जाए. 'shard_count' BUILD एट्रिब्यूट पर ध्यान दिए बिना, जांच के लिए 'k' शार्ड लागू करने के लिए 'forced=k' का इस्तेमाल किया जाता है.

--test_size_filters=<comma-separated list of values: small, medium, large or enormous> डिफ़ॉल्ट: ""

यह टेस्ट साइज़ की कॉमा से अलग की गई सूची तय करता है. शामिल नहीं किए गए साइज़ की जानकारी देने के लिए, हर साइज़ के आगे '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. आपको सिर्फ़ ऐसे टेस्ट टारगेट दिखेंगे जिनमें शामिल किए गए कम से कम एक साइज़ शामिल हो और बाहर रखे गए कोई साइज़ शामिल न हो. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.

--test_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

टेस्ट टैग की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' लगाया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. आपको सिर्फ़ ऐसे टेस्ट टारगेट मिलेंगे जिनमें शामिल किए गए कम से कम एक टैग हो और बाहर रखे गए कोई टैग न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: ""

टेस्ट टाइम आउट की कॉमा से अलग की गई सूची तय करता है. बाहर रखे गए टाइम आउट की जानकारी देने के लिए, हर टाइम आउट के पहले '-' लगाया जा सकता है. सिर्फ़ ऐसे टेस्ट टारगेट दिखेंगे जिनमें कम से कम एक शामिल किया गया टाइम आउट हो और कोई बाहर रखा गया टाइम आउट न हो. इस विकल्प से, --build_tests_only के व्यवहार और test कमांड पर असर पड़ता है.

--tool_java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वह वर्शन जिसका इस्तेमाल, बिल्ड के दौरान ज़रूरी टूल चलाने के लिए किया जाता है

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन इंटरफ़ेस के लिए jar का इस्तेमाल करता है. इससे इन्क्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

कैननिकल फ़्लैग वाले विकल्प

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) का वह प्रतिशत है जिससे ज़्यादा GcThrtingDetector, मेमोरी दबाव के इवेंट को इसकी सीमाओं के हिसाब से नहीं मानता (--gc_t इससेrapshin_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]canonicalize_policy डिफ़ॉल्ट: "गलत"

बड़ा करने और फ़िल्टर करने के बाद, कैननिकल नीति को आउटपुट करें. आउटपुट को साफ़ रखने के लिए, इस विकल्प को 'सही है' पर सेट करने पर, कैननिकल किए गए कमांड आर्ग्युमेंट नहीं दिखाए जाएंगे. ध्यान दें कि --for_command से तय किए गए निर्देश का असर, फ़िल्टर की गई नीति पर पड़ता है. अगर कोई निर्देश तय नहीं किया गया है, तो डिफ़ॉल्ट निर्देश 'build' होता है.
टैग: affects_outputs, terminal_output

--[no]experimental_include_default_values डिफ़ॉल्ट: "गलत"

क्या Starlark के विकल्पों को उनकी डिफ़ॉल्ट वैल्यू पर सेट करके, उन्हें आउटपुट में शामिल किया गया है.
टैग: affects_outputs, terminal_output

यह विकल्प, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग सही है, तो config_setting अन्य सभी नियमों की तरह ही, 'किसको दिखे' लॉजिक का ही पालन करता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की सेटिंग दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. मान्य वैल्यू में ये शामिल हैं: गड़बड़ी को ठीक करने के लिए उसे 'गड़बड़ी'', जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: 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.bazu में अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "update"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. साथ ही, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (हटाया गया वर्शन और पहले मौजूद नहीं थे मॉड्यूल) को रीफ़्रेश करने के लिए, `refresh` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर यह अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. इसके अलावा, लॉकफ़ाइल से न तो पढ़ने के लिए और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, Skyframe स्टेटस नहीं छोड़ा जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Basel को लगता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड पर है, तो यह बिना किसी वजह के सेट किए गए स्काईफ़्रेम स्टेटस को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जो लॉग इन करने के तरीके, फ़ॉर्मैट या जगह की जानकारी पर असर डालते हैं:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

यह कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. इस्तेमाल किए जा सकने वाले प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलॉक या लॉक) में से किसी एक को आर्ग्युमेंट के तौर पर दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम पर बनाई गई फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, याददाश्त बढ़ाने वाली 20 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

Bazel कमांड में किसी सामान्य इनपुट को बदलने या उसके बारे में बताने के विकल्प, जो किसी दूसरी कैटगरी में नहीं आते.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह फ़ील्ड खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय, बताई गई ठीक की गई फ़ाइल को पढ़ें
टैग: changes_inputs

--for_command=<a string> डिफ़ॉल्ट: "build"

वह कमांड जिसके लिए विकल्पों को कैननिकल किया जाना चाहिए.
टैग: affects_outputs, terminal_output

--invocation_policy=<a string> डिफ़ॉल्ट: ""

कैनोनिकल किए जाने वाले विकल्पों पर, अनुरोध करने की नीति लागू करता है.
टैग: affects_outputs, terminal_output

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

वह फ़ाइल तय करें जिससे रिमोट डाउनलोडर को कॉन्फ़िगर करना है. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--experimental_worker_for_repo_fetching=<off, platform, virtual or auto> डिफ़ॉल्ट: "auto"

रिपॉज़िटरी फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. अगर इसे 'बंद' पर सेट किया जाता है, तो किसी भी वर्क थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रिपॉज़िटरी को फ़ेच करने के लिए, रीस्टार्ट की ज़रूरत पड़ सकती है. ऐसा न होने पर, वर्चुअल वर्कर्स थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. मौजूदा पैकेज 'x' का सबपैकेज 'x/y' मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह शिकायत कर सकता है. ऐसा तब होता है, जब वह लेबल अब भी किसी अन्य package_path एंट्री से दिया जाता है. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--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 "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

साफ़ करने के विकल्प

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) का वह प्रतिशत है जिससे ज़्यादा GcThrtingDetector, मेमोरी दबाव के इवेंट को इसकी सीमाओं के हिसाब से नहीं मानता (--gc_t इससेrapshin_limits). अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:

--[no]async डिफ़ॉल्ट: "गलत"

अगर सही है, तो आउटपुट को हटाने की प्रोसेस एसिंक्रोनस होती है. यह निर्देश पूरा होने के बाद, उसी क्लाइंट में नए निर्देशों को सुरक्षित तरीके से लागू किया जा सकता है. भले ही, डेटा मिटाने की प्रोसेस बैकग्राउंड में जारी रह सकती है.
टैग: host_machine_resource_optimizations

--[no]expunge डिफ़ॉल्ट: "गलत"

अगर सही है, तो 'साफ़ करें' सुविधा, इस बेज़ल इंस्टेंस के लिए पूरी तरह से काम कर रही ट्री को हटा देती है. इसमें, बैज से बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर बेज़ल सर्वर चल रहा है, तो यह उसे भी रोक देता है.
टैग: host_machine_resource_optimizations

--expunge_async

अगर यह विकल्प चुना जाता है, तो clean इस bazel इंस्टेंस के लिए, पूरे वर्किंग ट्री को असिंक्रोनस तरीके से हटा देता है. इसमें, bazel की बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर bazel सर्वर चल रहा है, तो उसे बंद कर देता है. यह निर्देश पूरा होने के बाद, उसी क्लाइंट में नए निर्देशों को सुरक्षित तरीके से लागू किया जा सकता है. भले ही, डेटा मिटाने की प्रोसेस बैकग्राउंड में जारी रह सकती है.
इस तरह बड़ा होता है:
  --expunge
  --async

टैग: host_machine_resource_optimizations

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन को भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. साथ ही, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (हटाया गया वर्शन और पहले मौजूद नहीं थे मॉड्यूल) को रीफ़्रेश करने के लिए, `refresh` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर यह अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. इसके अलावा, लॉकफ़ाइल से न तो पढ़ने के लिए और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> बार इस्तेमाल किए गए

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. यह क्रम अहम है: मॉड्यूल को सबसे पहले पिछली रजिस्ट्री में देखा जाएगा. बाद की रजिस्ट्री में सिर्फ़ तब जुड़ें, जब वे पिछली रजिस्ट्री में न हों.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_full_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_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 की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

कमांड के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल रिकॉर्ड करता है. आर्ग्युमेंट के तौर पर, प्रोफ़ाइलिंग इवेंट का कोई एक टाइप (सीपीयू, वॉल, ऐलोक या लॉक) दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम पर बनाई गई फ़ाइल में लिखा जाता है. आने वाले समय में, इस फ़्लैग के सिंटैक्स और सिमेंटिक्स में बदलाव किया जा सकता है. ऐसा, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए किया जा सकता है. इसे अपने जोखिम पर इस्तेमाल करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, याददाश्त बढ़ाने वाली 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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

कॉन्फ़िगरेशन विकल्प

कवरेज के विकल्प

test से सभी विकल्प इनहेरिट करता है.

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--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 पर सेट किया जाता है, तो 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> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बेज़ल मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री के बारे में बताता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, Skyframe स्टेटस नहीं छोड़ा जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, मामूली जीसी इवेंट होने पर Skyframe की स्थिति को ड्रॉप नहीं किया जाएगा. साथ ही, रीटेन किए गए हेप के प्रतिशत के थ्रेशोल्ड को पार करने पर भी ऐसा नहीं किया जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Basel को लगता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड पर है, तो यह बिना किसी वजह के सेट किए गए स्काईफ़्रेम स्टेटस को हटा देगा. इसे ट्वीट करने से आप GC थ्रैशिंग के वॉल टाइम प्रभाव को कम कर सकते हैं, जब GC थ्रैशिंग (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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

Cquery के विकल्प

test से सभी विकल्प इनहेरिट करता है.

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--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} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने की ज़रूरत होती है. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. इस बात पर भी ध्यान दें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. हालांकि, 'बेज़ल क्वेरी' के दौरान यह फ़ैसला नहीं लिया जाता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को ऐसे दिखाता है जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन लागू किया गया हो. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट को ज़्यादा आसानी से पढ़ने लायक बनाने के लिए, आउटपुट फ़ॉर्मैटर, मुख्य रिपॉज़िटरी के हिसाब से, रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: कोई कार्रवाई नहीं (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. बड़े लेबल छोटे किए जाएंगे; -1 का मतलब है कि काट-छांट नहीं की जाएगी. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: कोई कार्रवाई नहीं (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: 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" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड भाषा के सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info Build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics

--output=<a string> डिफ़ॉल्ट: "लेबल"

वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: Label, Label_ kind, textproto, ट्रांज़िशन, प्रोटोकॉल, स् ट्रीम किया गया प्रोटो, jsonproto. 'ट्रांज़िशन' चुनने पर, आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --आउटपुट=प्रोटो
टैग पर लागू होता है: 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_configurations डिफ़ॉल्ट: "सही"

चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. बंद होने पर, cqueryproto आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत"

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत"

हर नियम के इंस्टैंशिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output

--[no]proto:locations डिफ़ॉल्ट: "सही"

क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है या नहीं.
टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "all"

आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा से अलग की गई सूची. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output

--query_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां किसी फ़ाइल के साथ-साथ, कमांड लाइन क्वेरी बताने में भी गड़बड़ी होती है.
टैग: changes_inputs

--[no]relative_locations डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output

--show_config_fragments=<off, direct or transitive> डिफ़ॉल्ट: "बंद"

यह नियम के हिसाब से ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट और इसकी ट्रांज़िटिव डिपेंडेंसी दिखाता है. इससे यह पता लगाने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ को कितना छोटा किया जा सकता है.
टैग: affects_outputs

--starlark:expr=<a string> डिफ़ॉल्ट: ""

cquery के --output=starlark मोड में, कॉन्फ़िगर किए गए हर टारगेट को फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट, 'टारगेट' तक सीमित है. अगर --starlark:expr और --starlark:file, दोनों में से किसी का भी इस्तेमाल नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट हो जाएगा. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल करने पर गड़बड़ी होती है.
टैग: terminal_output

--starlark:file=<a string> डिफ़ॉल्ट: ""

इस फ़ाइल में 'format' नाम का एक Starlark फ़ंक्शन होता है. इसमें एक आर्ग्युमेंट होता है, जिसे कॉन्फ़िगर किए गए हर टारगेट पर लागू करके उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल करने पर गड़बड़ी होती है. ज़्यादा जानकारी के लिए, --output=starlark के लिए सहायता देखें.
टैग: terminal_output

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: अगर इसे बंद किया जाता है, तो 'एग्ज़ीक्यूट कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, एक से ज़्यादा बार ट्रांज़िशन करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. ये वे टारगेट भी होंगे जो टारगेट कॉन्फ़िगरेशन में शामिल हैं. अगर टॉप लेवल टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ लागू किए गए कॉन्फ़िगर किए गए टारगेट ही लौटाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics

--transitions=<full, lite or none> डिफ़ॉल्ट: "none"

वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी को प्रिंट करेगी.
टैग: affects_outputs

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ और घटाव). क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प में इनपुट के तौर पर वे टारगेट डाले जाते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, इस विकल्प का असर कॉन्फ़िगरेशन और ट्रांज़िशन पर पड़ सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माना जाता है. ध्यान दें: cquery के लिए, इस विकल्प को न बताने पर, हो सकता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल विकल्पों के साथ बिल्ड न हो पाएं.
टैग: loading_and_analysis

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन नहीं हो पाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन को भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि 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> डिफ़ॉल्ट: "update"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `update` है और बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल को अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या उसमें लिखने के लिए `बंद` करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बेज़ल मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री के बारे में बताता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: जानकारी देखें

इस नीति के तहत, उस डायरेक्ट्री के बारे में बताया जाता है जिसे बाहरी डेटा स्टोर करने की जगहों को वेंडर मोड में रखना चाहिए. भले ही, डेटा स्टोर करने की जगह को इसमें फ़ेच करना हो या बिल्डिंग के दौरान इस्तेमाल करना हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

ऐसे विकल्प जो बिल्ड के समय को ऑप्टिमाइज़ करने के लिए ट्रिगर करते हैं:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाओं को कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. ज़ीरो का मतलब है कि पूरे जीसी इवेंट का डेटा कभी भी ड्रॉप नहीं होगा. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, Skyframe स्टेटस नहीं छोड़ा जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

यह कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. आर्ग्युमेंट के तौर पर, प्रोफ़ाइलिंग इवेंट का कोई एक टाइप (सीपीयू, वॉल, ऐलोक या लॉक) दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम पर बनाई गई फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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/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

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> एक से ज़्यादा बार इस्तेमाल किए जाने पर

किसी कार्रवाई की याद दिलाने वाली जानकारी के आधार पर, किसी कार्रवाई को लागू करने की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो प्रोग्राम के चलने की जानकारी दिखाती हैं. कई सामान्य कार्रवाइयां, प्रोग्राम के चलने की जानकारी दिखाती हैं. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. इसकी वजह यह है कि एक ही याद दिलाने वाले तरीके पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' को जोड़ता है और 'y' को हटा देता है. 'Genrule=+requires-x', सभी Genrule कार्रवाइयों के लिए, लागू करने की जानकारी में 'requires-x' जोड़ता है. '(?!Genrule).*=-requires-x', Genrule से जुड़ी सभी कार्रवाइयों के लिए, कार्रवाइयों के लागू होने की जानकारी से 'requires-x' को हटा देता है.
टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar ऐक्शन को लगातार चालू करें.
इस तरह बड़ा होता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

कर्मचारियों का इस्तेमाल करके, Android के स्थायी संसाधन प्रोसेसर को चालू करें.
इनकी ओर:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker

{14//} टैग करें



--strategy=Aapt2Optimize=worker--strategy=AARGenerator=worker--strategy=ProcessDatabinding=worker--strategy=GenerateDataBindingBaseClasses=workerhost_machine_resource_optimizationsexecution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की लगातार होने वाली कई कार्रवाइयों को चालू करें.
इस तरह बड़ा होता है:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

वर्कर्स का इस्तेमाल करके, लगातार मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.
इस तरह बड़ा होता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के ऐसे टूल चालू करना जो लगातार काम करते हैं और एक से ज़्यादा काम करते हैं. जैसे, डीकंपाइल करना, डीसुगर करना, और संसाधन प्रोसेस करना.
इस तरह बड़ा होता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel टेस्ट चलाने के लिए, टेस्ट एक्सीक्यूट ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा.
टैग: execution

ऐसे विकल्प जो कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करते हैं:

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_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> डिफ़ॉल्ट: "@ba"_tools//tools/android:sdk"

Android SDK/प्लैटफ़ॉर्म के बारे में जानकारी देता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

Apple और Objc नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bagel_tools//tools/test:lcov_merger"

रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, '//tools/test:lcov_merger' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> डिफ़ॉल्ट: "@ba"_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_report_generator' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> का डिफ़ॉल्ट मैसेज: "@bagel_tools//tools/test:coverage_support"

कोड कवरेज इकट्ठा करने वाली हर टेस्ट ऐक्शन के इनपुट पर ज़रूरी सहायता फ़ाइलों की जगह. डिफ़ॉल्ट रूप से, '//tools/test:coverage_support' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--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> डिफ़ॉल्ट: ""

ऐसे प्लैटफ़ॉर्म जो ऐक्शन चलाने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म, टारगेट के हिसाब से या टारगेट पैटर्न के तौर पर तय किए जा सकते हैं. इन प्लैटफ़ॉर्म को, 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> डिफ़ॉल्ट: जानकारी देखें

चेक-इन की गई लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़े.
टैग: 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> डिफ़ॉल्ट: "@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 के नियमों (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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो 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' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: जानकारी देखें

अगर ऐसा है, तो बिल्ड से जुड़ी सही कार्रवाइयों के लिए दिए गए वर्शन के Xcode का इस्तेमाल किया जाता है. अगर जानकारी नहीं है, तो Xcode के एक्ज़ेक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग: loses_incremental_state

--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"

xcode_config नियम का लेबल, जिसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत"

डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines

--[no]build_runfile_links डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइलों के सिमलिंक फ़ॉरेस्ट बनाएं. अगर यह फ़ील्ड 'गलत' पर सेट है, तो इसे सिर्फ़ तब लिखें, जब किसी स्थानीय कार्रवाई, जांच या चलाने के कमांड की ज़रूरत हो.
टैग: affects_outputs

--[no]build_runfile_manifests डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह 'गलत है' पर सेट है, तो उन्हें शामिल न करें. अगर यह वैल्यू 'गलत' है, तो स्थानीय टेस्ट नहीं चलेंगे.
टैग: affects_outputs

--[no]build_test_dwp डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िज़न की मदद से बिल्ड करते समय, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बिल्ड हो जाएगी.
टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h"

cc_proto_library से बनने वाली हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc"

cc_proto_library से बनने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत"

proto_library में, अन्य Java API वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_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 पेयर से लिया जाएगा जो वैल्यू को शुरू करने वाले एनवायरमेंट से अलग सेट करता है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है; एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत और अलग-अलग वैरिएबल के लिए विकल्प इकट्ठा होते हैं.
टैग: 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++ डिपेंडेंसी डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बेज़ल यह चुनेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्थिर मोड में लिंक की जाएंगी.
टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "alphabetical"

Android बाइनरी के लिए, मेनिफ़ेस्ट मर्ज करने वाले टूल को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अंग्रेज़ी वर्णमाला के क्रम में का मतलब है कि मेनिफ़ेस्ट, execroot के हिसाब से पाथ के हिसाब से क्रम में लगाए जाते हैं. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. डिपेंडेंसी का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसी क्रम में रखा जाता है जो उसके डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]build_python_zip डिफ़ॉल्ट: "ऑटो"

python की एक्ज़ीक्यूटेबल ZIP फ़ाइल बनाएं; Windows पर, अन्य प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs

--catalyst_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है. इन आर्किटेक्चर के लिए, Apple Catalyst बाइनरी बनाई जानी हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "गलत"

अगर ऐसा किया जाता है, तो Baज़र, इंस्ट्रुमेंट कोड का इस्तेमाल करेगा (जहां हो सके ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ --instrumentation_filter से मेल खाने वाले टारगेट ही प्रभावित होंगे. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "fastbuild"

वह मोड बताएं जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

gcc को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ नाम बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाले FDO इंस्ट्रूमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से बनी प्रोफ़ाइल को दिखाने वाली cs_fdo_profile, जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs

--cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

--define का हर विकल्प, किसी बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default"

यह तय करता है कि C++ बाइनरी को डाइनैमिक रूप से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "auto"

रनफ़ाइल्स के सिमलिंक ट्री को चालू करें; डिफ़ॉल्ट रूप से, यह Windows और अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में Java के रिसॉर्स को कंप्रेस करें
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही"

Android डेटाबाइंडिंग v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं पड़ता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत"

dex फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करना
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत"

अगर यह जानकारी दी जाती है, तो Bazel जनरेट की गई फ़ाइलों के लिए कवरेज की जानकारी भी इकट्ठा करेगा.
टैग: affects_outputs

--experimental_objc_fastbuild_options=<comma-separated list of options> डिफ़ॉल्ट: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc फ़ास्टबिल्ड कंपाइलर के विकल्पों के तौर पर किया जाता है.
टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो स्टैक को अनवाइंड करने के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कॉम्पाइल करें.
टैग: action_command_lines, affects_outputs, experimental

--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 डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. सटीक स्कीम प्रयोग के तौर पर शुरू की गई है और इसमें बदलाव हो सकते हैं: पहला, बहुत ही कम मामलों में --प्लैटफ़ॉर्म विकल्प में सिर्फ़ एक वैल्यू नहीं होती, इसलिए प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir से रजिस्टर किया गया था, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_Output_किन_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> डिफ़ॉल्ट: "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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एक्ज़ीक्यूटिव कॉन्फ़िगरेशन में बनाए गए टूल के लिए, 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, //foo/ में बार.cc के अलावा सभी cc फ़ाइलों की cc कमांड लाइन में -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_ऐप्लिकेशन का इस्तेमाल करके, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. इसका नतीजा एक यूनिवर्सल बाइनरी होता है, जिसमें सभी तय किए गए आर्किटेक्चर शामिल होते हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive डिफ़ॉल्ट: "सही"

अब काम नहीं करता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में, linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर, alwayslink=1 का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> बार इस्तेमाल किए गए

लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ बैकएंड चरण (--features=thin_lto में) पर जाने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ को इंडेक्स करने के चरण पर जाने के लिए अन्य विकल्प (--features=thin_lto में).
टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple macOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट के लिए, macOS का कम से कम काम करने वाला वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "गलत"

अगर यह सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS तय करें.
टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर इस फ़्लैग और --compilation_mode=opt, दोनों के बारे में बताया गया है, तो बाइनरी स्ट्रिपिंग की जाएंगी.
टैग: action_command_lines

--objccopt=<a string> बार इस्तेमाल किए गए

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर रखने की सूची दिखाता है (यह भी देखें --instrumentation_filter). option_1 से option_n का मतलब, आर्बिट्रेरी कमांड लाइन विकल्पों के लिए है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड (--features=thin_lto में) को चुनिंदा तौर पर पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. option_1 से option_n, कमांड लाइन के मनमुताबिक विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, bar.o को छोड़कर //foo/ में मौजूद सभी o फ़ाइलों की LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: जानकारी देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. इस फ़्लैग में बिल्ड लेबल डाला जा सकता है, जिसमें प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा लेबल होना चाहिए. उदाहरण के लिए, a/b/BUILD:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",) में मौजूद, लेबल की जानकारी देने वाली BUILD फ़ाइल. इन फ़ाइलों को Bazel को दिखाने के लिए, उससे जुड़े पैकेज में exports_files डायरेक्टिव जोड़ना पड़ सकता है. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile
टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, cc_profile फ़ाइल का ऐब्सलूट पाथ नाम.
टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: जानकारी देखें

Propeller के ऑप्टिमाइज़ किए गए बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ नाम.
टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

'टेस्ट' और 'रन' निर्देशों के लिए, एक्सीक्यूटेबल के पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और प्रोग्राम चलाने के लिए इस्तेमाल की जाने वाली कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी ऐसे टारगेट का लेबल भी हो सकता है जिसे चलाया जा सकता है. कुछ उदाहरण: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

--[no]share_native_deps डिफ़ॉल्ट: "सही"

अगर यह सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के बीच शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "गलत"

तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल स्टोर करने की जगह की जानकारी वगैरह के साथ बाइनरी को स्टैंप करें.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब स्ट्रिप iff --compilation_mode=fastbuild है.
टैग: affects_outputs

--stripopt=<a string> बार इस्तेमाल किए गए

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Swift कंपाइलेशन के लिए पास करने के अन्य विकल्प.
टैग: action_command_lines

--tvos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

ऐसे आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं. इसमें आर्किटेक्चर को कॉमा लगाकर अलग किया गया है.
टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, काम करने वाला कम से कम tvOS वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

ऐप्लिकेशन के लिए, Apple visionOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट सिम्युलेटर और डिवाइसों के साथ काम करने वाले WatchOS वर्शन. अगर जानकारी नहीं है, तो 'watchos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू रहेंगे, जैसे कि xbinary_fdo कभी तय नहीं किया गया हो.
टैग: affects_outputs

ऐसे विकल्प जिनसे इस बात पर असर पड़ता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: ""

cpu वैल्यू को target_environment वैल्यू पर अपने-आप मैप करने के लिए, environment_group का इस्तेमाल करें.
टैग: changes_inputs, loading_and_analysis, experimental

--[no]check_licenses डिफ़ॉल्ट: "गलत"

देखें कि डिपेंडेंट पैकेज से लगाई गई लाइसेंस की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics

--[no]check_visibility डिफ़ॉल्ट: "सही"

अगर यह सेटिंग बंद है, तो टारगेट डिपेंडेंसी में दिखने से जुड़ी गड़बड़ियों की जगह, चेतावनियों की जगह सिर्फ़ चेतावनी दिखाई जाएगी.
टैग: build_file_semantics

--[no]desugar_for_android डिफ़ॉल्ट: "सही"

डेक्स करने से पहले, Java 8 के बाइटकोड को डीसुगर करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "गलत"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints डिफ़ॉल्ट: "सही"

यह जांच करता है कि हर टारगेट किन एनवायरमेंट के साथ काम करता है और अगर किसी टारगेट पर ऐसी डिपेंडेंसी है जो एक जैसे एनवायरमेंट के साथ काम नहीं करती, तो गड़बड़ियों की रिपोर्ट करता है
टैग: build_file_semantics

--[no]experimental_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/bazibuild/ba बहुत/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"

APK साइन करने के लिए इस्तेमाल करने का तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements डिफ़ॉल्ट: "सही"

अगर यह सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें

iOS साइनिंग के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह, कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक, सर्टिफ़िकेट की कीचेन आइडेंटिटी प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम की (सबस्ट्रिंग) हो सकती है.
टैग: action_command_lines

इस विकल्प का असर, 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 में हमेशा लिंक एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही बनाएं.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो पहले से मौजूद py_* नियमों का इस्तेमाल करते समय गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के AnalysisFailureInfo के इंस्टेंस का प्रॉपेगेशन होता है. इसमें गड़बड़ी की जानकारी होती है. इससे बिल्ड पूरा न होने की स्थिति नहीं होती.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा डेटा डालने पर, नियम से जुड़ी गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g. memory=10,30,60,100> बार इस्तेमाल किए गए

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई एक पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगी. अगर कॉमा लगाकर चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की संख्या को बदल देंगी. वैल्यू के तौर पर HOST_RAM/HOST_CPU भी इस्तेमाल किया जा सकता है. इसके बाद, [-|*]<float> भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4. इस फ़्लैग के ज़रिए बताए गए डिफ़ॉल्ट जांच संसाधनों को टैग में बताए गए अश्लील संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "गलत"

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "गलत"

ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है, जैसे कि 'iPhone 6'. डिवाइसों की सूची पाने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

यह iOS का वह वर्शन है जो दौड़ने या टेस्ट करने के दौरान सिम्युलेटर पर चलता है. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह हर टेस्ट को कितनी बार चलाने के लिए तय करता है. अगर इनमें से कोई भी कोशिश किसी वजह से फ़ेल हो जाती है, तो पूरी जांच को फ़ेल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. जहां Run_per_test का मतलब पूर्णांक वैल्यू है और regex_filter, रेगुलर एक्सप्रेशन पैटर्न की सूची को दिखाता है और इसमें शामिल नहीं है (इसे भी देखें --instrumentation_filter). उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कुछ भी मैच नहीं करता है, तो जांच सिर्फ़ एक बार की जाती है.

--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैरिएबल की वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.
टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1"

टेस्ट टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक धनात्मक पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर चार पूर्णांकों को कॉमा लगाकर अलग-अलग किया गया है, तो वे कम, सामान्य, ज़्यादा, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों ही रूपों में, -1 की वैल्यू से ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने का निर्देश मिलता है.

--[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>लेबल</code> के इंस्टेंस पर लागू किए गए Starlark <code>str</code> फ़ंक्शन से मिला हो. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर इस नीति को चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैट करने वाले लोग, डेटा स्टोर करने की मुख्य जगह के नाम (डेटा स्टोर करने की मुख्य जगह के बजाय) का इस्तेमाल कर सकते हैं. इससे आउटपुट को पढ़ने में आसानी होती है.
टैग: terminal_output

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: कोई कार्रवाई नहीं (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल काट दिए जाएंगे; -1 का मतलब है कि लेबल काटा नहीं जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो डिपेंडेंसी ग्राफ़ में उन डिपेंडेंसी को शामिल किया जाएगा जिन पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. cquery के लिए, यह विकल्प हल किए गए टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.
टैग: build_file_semantics

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: क्या आउटपुट में आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से जनरेट की गई कार्रवाइयों को शामिल करना है. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, शुरुआत में मौजूद `//` को नहीं हटाया जाएगा.
टैग: terminal_output, incompatible_change

--[no]infer_universe_scope डिफ़ॉल्ट: "गलत"

अगर --universe_scope सेट है और --universe_scope की वैल्यू सेट नहीं है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर अनुमानित किया जाएगा. ध्यान दें कि यूनिवर्स के दायरे वाले फ़ंक्शन (उदाहरण के लिए, `allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए, --universe_scope वैल्यू आपके हिसाब से नहीं हो सकती. इसलिए, आपको इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query पर जाएं. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है (यानी `cquery` पर नहीं).
टैग: loading_and_analysis

--[no]line_terminator_null डिफ़ॉल्ट: "गलत"

क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाता है.
टैग: terminal_output

--[no]nodep_deps डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो "nodep" एट्रिब्यूट से जुड़ी डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड भाषा के सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info Build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics

--output=<a string> डिफ़ॉल्ट: "लेबल"

इस फ़ॉर्मैट में, cquery के नतीजों को प्रिंट किया जाना चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_kind, textproto, transitions, proto, streamed_proto, jsonproto. 'ट्रांज़िशन' चुनने पर, आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू, बिल्ड फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

डेफ़िनिशन_stack प्रोटो फ़ील्ड को पॉप्युलेट करें, जो हर नियम इंस्टेंस के लिए स्टारलार्क कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की जाती थी.
टैग: terminal_output

--[no]proto:flatten_selects डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची के टाइप के लिए, फ़्लैट किया गया रिप्रज़ेंटेशन एक सूची होती है, जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप को फ़्लैट करके शून्य कर दिया जाता है.
टैग: build_file_semantics

--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत"

हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स एस्पेक्ट से पॉप्युलेट करें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स एस्पेक्ट से नहीं मिला है, तो उसे खाली स्ट्रिंग से पॉप्युलेट करें.
टैग: terminal_output

--[no]proto:include_configurations डिफ़ॉल्ट: "सही"

चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. बंद होने पर, cqueryproto आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग: affects_outputs

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत"

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत"

हर नियम के इंस्टैंशिएट करने वाले कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output

--[no]proto:locations डिफ़ॉल्ट: "सही"

जगह की जानकारी को प्रोटो आउटपुट में आउटपुट देना है या नहीं.
टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "all"

आउटपुट में शामिल करने के लिए एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

Terms_input औरRule_ ठहरने के फ़ील्ड को भरना है या नहीं.
टैग: terminal_output

--query_file=<a string> डिफ़ॉल्ट: ""

अगर यह सेट है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां किसी फ़ाइल के साथ-साथ, कमांड लाइन क्वेरी बताने में भी गड़बड़ी होती है.
टैग: changes_inputs

--[no]relative_locations डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसे नतीजे पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output

--show_config_fragments=<off, direct or transitive> डिफ़ॉल्ट: "बंद"

यह किसी नियम और उसकी ट्रांज़िशन डिपेंडेंसी के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट दिखाता है. इससे यह पता लगाने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ को कितना छोटा किया जा सकता है.
टैग: affects_outputs

--starlark:expr=<a string> डिफ़ॉल्ट: ""

cquery के --output=starlark मोड में, कॉन्फ़िगर किए गए हर टारगेट को फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट, 'target' से बंधा होता है. अगर --starlark:expr और --starlark:file, दोनों में से किसी का भी इस्तेमाल नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट हो जाएगा. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल करने पर गड़बड़ी होती है.
टैग: terminal_output

--starlark:file=<a string> डिफ़ॉल्ट: ""

इस फ़ाइल में 'format' नाम का एक Starlark फ़ंक्शन होता है. इसमें एक आर्ग्युमेंट होता है, जिसे कॉन्फ़िगर किए गए हर टारगेट पर लागू करके उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है. --starlark:expr और --starlark:file, दोनों को तय करने में गड़बड़ी होती है. ज़्यादा जानकारी के लिए, --output=starlark के लिए सहायता देखें.
टैग: terminal_output

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: अगर इसे बंद किया जाता है, तो 'एग्ज़ीक्यूट कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'exec कॉन्फ़िगरेशन' डिपेंडेंसी एज, आम तौर पर उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान इस्तेमाल किए गए टूल पर ले जाता है. जैसे, किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर ले जाने वाला एज. Cquery: यह सुविधा बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर दिया जाता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप-लेवल टारगेट की तुलना में, एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics

--transitions=<full, lite or none> डिफ़ॉल्ट: "none"

वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगी.
टैग: affects_outputs

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ और घटाव). यह क्वेरी, बताए गए टारगेट के ट्रांज़िटिव क्लोज़िंग से तय किए गए ब्रह्मांड में की जा सकती है. इस विकल्प का इस्तेमाल क्वेरी और क्वेरी कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट सभी जवाबों को टारगेट करता है. इसलिए, इस विकल्प से कॉन्फ़िगरेशन और ट्रांज़िशन पर असर पड़ सकता है. अगर इस विकल्प की जानकारी नहीं दी गई है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माना जाता है. ध्यान दें: 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 टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर सही है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, '-py2' सफ़िक्स वाले आउटपुट रूट में दिखेंगे. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा सफ़िक्स न हो. इसका मतलब है कि `baZ-bin` सुविधा सिमलिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, `--incompatible_py3_is_default` को भी चालू करने का सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से PY3 का इस्तेमाल किया जाएगा, न कि PY2 का. अगर आपने इस फ़्लैग को सेट किया है, तो हमारा सुझाव है कि `--insupported_py2_Outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के नेटिव नियमों को लागू करने के लिए, --python_top जैसे लेगसी फ़्लैग के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल किया जाएगा.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

Python के मुख्य वर्शन का मोड, या तो `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट बदल देते हैं. भले ही, वे साफ़ तौर पर किसी वर्शन की जानकारी न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "auto"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो Bazel किसी टेस्ट को फिर से सिर्फ़ तब चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट चलाने का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. 'हां' पर सेट होने पर, 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 डिफ़ॉल्ट: "गलत"

यह सुविधा सिर्फ़ Android-साथ काम करने वाली लाइब्रेरी तक उपलब्ध है.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java लॉन्चर, उन टूल का इस्तेमाल करता है जो बिल्ड के दौरान चलाए जाते हैं.

--host_javacopt=<a string> बार इस्तेमाल किए गए

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, javac को पास करने के लिए अतिरिक्त विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर सही है, तो खास टेस्ट सैंडबॉक्स की गई रणनीति के साथ किए जाएंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने पर, शेयर किए गए कैश मेमोरी का इस्तेमाल होने पर, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी सेव नहीं की जा सकती.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

J2ObjC टूल को पास करने के लिए अन्य विकल्प.

--java_debug

इसकी वजह से, किसी Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे, jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इस तरह बड़ा होता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps डिफ़ॉल्ट: "सही"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (फ़िलहाल, कंपाइल के समय क्लासपाथ) जनरेट करें.

--[no]java_header_compilation डिफ़ॉल्ट: "सही"

सीधे सोर्स से इजर कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> बार इस्तेमाल किए गए

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> बार इस्तेमाल किए गए

Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--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> डिफ़ॉल्ट: "@bagel_tools//tools/proto:cc_toolchain"

proto_lang_toolchain() का लेबल जो C++ Protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@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_SH एनवायरमेंट वैरिएबल पहले Basel को शुरू करने की प्रोसेस पर सेट है, (जिससे Baze सर्वर चालू होता है) उसका इस्तेमाल किया जाता है. यदि दोनों में से कोई भी सेट नहीं है, तो 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"

टेस्ट शार्डिंग के लिए रणनीति तय करें: 'शर्डिंग' एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब शार्डिंग का इस्तेमाल किया जा रहा हो. 'अक्षम' है. '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_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

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]action_cache डिफ़ॉल्ट: "गलत"

कार्रवाई की कैश मेमोरी में सेव कॉन्टेंट को डंप करें.
टैग: bazel_monitoring

--[no]packages डिफ़ॉल्ट: "गलत"

पैकेज की कैश मेमोरी में सेव कॉन्टेंट को डंप करें.
टैग: bazel_monitoring

--[no]rule_classes डिफ़ॉल्ट: "गलत"

नियम की क्लास को डंप करें.
टैग: bazel_monitoring

--[no]rules डिफ़ॉल्ट: "गलत"

डंप के नियम, जिनमें गिनती और मेमोरी के इस्तेमाल की जानकारी शामिल है (अगर मेमोरी को ट्रैक किया जाता है).
टैग: bazel_monitoring

--skyframe=<off, summary, count, deps or rdeps> डिफ़ॉल्ट: "बंद"

SkyFrame का ग्राफ़: 'off', 'summary', 'count', 'deps' या 'rdeps'.
टैग: bazel_monitoring

--skykey_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: ".*"

आउटपुट के लिए, SkyKey के नामों का रेगुलर एक्सप्रेशन फ़िल्टर. इसका इस्तेमाल सिर्फ़ --skyframe=deps, rdeps के साथ किया जाता है.
टैग: bazel_monitoring

--skylark_memory=<a string> डिफ़ॉल्ट: जानकारी देखें

यह, दिए गए पाथ में pprof के साथ काम करने वाली मेमोरी प्रोफ़ाइल को डंप करता है. ज़्यादा जानने के लिए, कृपया https://github.com/google/pprof पर जाएं.
टैग: bazel_monitoring

Bzlmod आउटपुट और सिमेंटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> बार इस्तेमाल किए गए

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन को भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को हमेशा MODULE.bazu में अनदेखा किया जाता है.
टैग: 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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--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 इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, मामूली जीसी इवेंट होने पर Skyframe की स्थिति को ड्रॉप नहीं किया जाएगा. साथ ही, रीटेन किए गए हेप के प्रतिशत के थ्रेशोल्ड को पार करने पर भी ऐसा नहीं किया जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जो लॉग इन करने के तरीके, फ़ॉर्मैट या जगह की जानकारी पर असर डालते हैं:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: ब्यौरा देखें

यह कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. आर्ग्युमेंट के तौर पर, प्रोफ़ाइलिंग इवेंट का कोई एक टाइप (सीपीयू, वॉल, ऐलोक या लॉक) दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम पर बनाई गई फ़ाइल में लिखा जाता है. आने वाले समय में, इस फ़्लैग के सिंटैक्स और सिमेंटिक्स में बदलाव किया जा सकता है. ऐसा, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए किया जा सकता है. इसे अपने जोखिम पर इस्तेमाल करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

फ़ेच करने के विकल्प

test से सभी विकल्प इनहेरिट करता है.

ऐसे विकल्प जो निर्देश से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--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_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है; ctx.execute अब भी इंटरनेट को ऐक्सेस करने वाला कोई भी एक्सीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]all डिफ़ॉल्ट: "गलत"

यह किसी भी टारगेट या रिपॉज़िटरी को बनाने के लिए ज़रूरी सभी बाहरी रिपॉज़िटरी फ़ेच करता है. अगर कोई दूसरा फ़्लैग और आर्ग्युमेंट नहीं दिया गया है, तो यह डिफ़ॉल्ट रूप से लागू होता है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

टेंन्चर स्पेस के इस्तेमाल का प्रतिशत (0-100). इस प्रतिशत से ज़्यादा होने पर, GcThrashingDetector मेमोरी प्रेशर इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से तय करता है. अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

इस विकल्प से Starlark भाषा या बिल्ड एपीआई के सिमैंटिक पर असर पड़ता है. बिल्ड एपीआई को BUILD फ़ाइलों, .bzl फ़ाइलों या Workspace फ़ाइलों से ऐक्सेस किया जा सकता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट नहीं है, तो उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की सेटिंग दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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]configure डिफ़ॉल्ट: "गलत"

सिर्फ़ सिस्टम कॉन्फ़िगरेशन के मकसद से, 'कॉन्फ़िगर करें' के तौर पर मार्क किए गए रिपॉज़िटरी फ़ेच करता है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs

--[no]force डिफ़ॉल्ट: "गलत"

अगर कोई मौजूदा रिपॉज़िटरी है, तो उसे अनदेखा करें और रिपॉज़िटरी को फिर से फ़ेच करें. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को हमेशा MODULE.bazu में अनदेखा किया जाता है.
टैग: 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

--repo=<a string> बार इस्तेमाल किए गए

सिर्फ़ तय की गई रिपॉज़िटरी को फ़ेच करता है. यह {@apparent_repo_name} या {@@canonical_repo_name} हो सकती है. --enable_bzlmod चालू होने पर ही काम करता है.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--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 इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Basel को लगता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड पर है, तो यह बिना किसी वजह के सेट किए गए स्काईफ़्रेम स्टेटस को हटा देगा. इसे ट्वीट करने से आप GC थ्रैशिंग के वॉल टाइम प्रभाव को कम कर सकते हैं, जब GC थ्रैशिंग (i) इस अस्थायी स्थिति की मेमोरी के उपयोग के कारण होती है और (ii) स्थिति की आवश्यकता होने पर राज्य को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जो लॉग इन करने के तरीके, फ़ॉर्मैट या जगह की जानकारी पर असर डालते हैं:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

कमांड के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल रिकॉर्ड करता है. इस्तेमाल किए जा सकने वाले प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलॉक या लॉक) में से किसी एक को आर्ग्युमेंट के तौर पर दिया जाना चाहिए. प्रोफ़ाइल को, आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम वाली फ़ाइल में लिखा जाता है. आने वाले समय में, इस फ़्लैग के सिंटैक्स और सिमेंटिक्स में बदलाव किया जा सकता है. ऐसा, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए किया जा सकता है. इसे अपने जोखिम पर इस्तेमाल करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

अगर यह वैल्यू खाली नहीं है, तो Starlark की वैल्यू लिखें. इसमें, Starlark के उन सभी रिपॉज़िटरी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

बेज़ल कमांड के लिए, जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में पंक्तियां होती हैं, जिनमें से हर एक निर्देश (`allow`, `block` या `rewrite` से शुरू होता है) के बाद एक होस्ट नाम (`allow` और `block` के लिए) या दो पैटर्न होते हैं, एक का मिलान करना है और दूसरे का इस्तेमाल वैकल्पिक यूआरएल के तौर पर किया जाता है. इसमें `$1` से शुरू होने वाले बैक-रेफ़रंस होते हैं. एक ही यूआरएल के लिए एक से ज़्यादा `रीराइट` डायरेक्टिव दिए जा सकते हैं. इस मामले में, एक से ज़्यादा यूआरएल दिए जा सकते हैं.

--experimental_worker_for_repo_fetching=<off, platform, virtual or auto> डिफ़ॉल्ट: "auto"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर इसे 'बंद' पर सेट किया जाता है, तो किसी भी वर्क थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रिपॉज़िटरी को फ़ेच करने के लिए, रीस्टार्ट की ज़रूरत पड़ सकती है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, आपके क्लाइंट में x/y/BUILD को मिटाने के बाद, बिल्ड सिस्टम इसकी शिकायत कर सकता है. ऐसा तब होता है, जब उसे '//x:y/z' लेबल मिलता है. ऐसा तब होता है, जब उसे अब भी किसी दूसरी Package_path एंट्री से मिला हो. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[no]fetch डिफ़ॉल्ट: "सही"

यह कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति देती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--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 "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]all डिफ़ॉल्ट: "गलत"

किसी भी टारगेट या डेटा स्टोर करने की जगह को बनाने के लिए ज़रूरी, सभी बाहरी डेटा स्टोर करने की जगह फ़ेच करता है. अगर कोई दूसरा फ़्लैग और आर्ग्युमेंट नहीं दिया गया है, तो यह डिफ़ॉल्ट रूप से लागू होता है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs

--[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_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

--[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"> डिफ़ॉल्ट: "ऑटो"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "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
  --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> डिफ़ॉल्ट: "@ba"_tools//tools/android:sdk"

Android SDK/प्लैटफ़ॉर्म के बारे में जानकारी देता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

Apple औरobjc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट को कंपाइल करने के लिए, C++ कंपाइलर का इस्तेमाल करें.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger"

रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, '//tools/test:lcov_merger' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट तौर पर, '//tools/test:coverage_report_generator' करता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_support"

उन समर्थन फ़ाइलों की जगह जो कोड कवरेज इकट्ठा करने वाली हर टेस्ट कार्रवाई के इनपुट के लिए ज़रूरी हैं. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_support' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--crosstool_top=<a build target label> डिफ़ॉल्ट: "@bagel_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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची, जिसमें हर एक से पहले वैकल्पिक रूप से - (नेगेटिव एक्सप्रेशन) लगाया जाता है. (=) को कॉमा लगाकर अलग किए गए कंस्ट्रेंट वैल्यू टारगेट की सूची में असाइन किया जाता है. अगर कोई टारगेट किसी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन से मेल खाता है, तो उसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा जैसे उसने शर्त की वैल्यू को, लागू करने से जुड़ी शर्तों के तौर पर बताया हो. उदाहरण: जिन टारगेट के नाम में 'test' मौजूद है उन्हें छोड़कर //demo,-test=@platforms//cpus:x86_64 को किसी भी टारगेट में 'x86_64' जोड़ा जाएगा.
टैग: 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> डिफ़ॉल्ट: जानकारी देखें

डिफ़ॉल्ट रूप से, exec कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler विकल्पों का भी इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया जाता है, तो Ba बैंक, दिए गए 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/baZ/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 डिफ़ॉल्ट: "सही"

अगर टूलचेन काम करता है, तो इंटरफ़ेस के शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, ईएलएफ़ टूलचेन में यह सेटिंग काम करती है.
टैग: 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> डिफ़ॉल्ट: ब्यौरा देखें

अब काम नहीं करता, no-op. `--insupported_use_python_toolchains` ने बंद किया है.
टैग: no_op, deprecated

--python3_path=<a string> डिफ़ॉल्ट: जानकारी देखें

अब काम नहीं करता, no-op. `--insupported_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_config नियम का लेबल, जिसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत"

डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग: affects_outputs, action_command_lines

--[no]build_runfile_links डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइलों के सिमलिंक फ़ॉरेस्ट बनाएं. अगर यह फ़ील्ड 'गलत' पर सेट है, तो इसे सिर्फ़ तब लिखें, जब किसी स्थानीय कार्रवाई, जांच या चलाने के कमांड की ज़रूरत हो.
टैग: affects_outputs

--[no]build_runfile_manifests डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह 'गलत है' पर सेट है, तो उन्हें शामिल न करें. अगर यह वैल्यू 'गलत' है, तो स्थानीय टेस्ट नहीं चलेंगे.
टैग: affects_outputs

--[no]build_test_dwp डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िज़न की मदद से बिल्ड करते समय, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बिल्ड हो जाएगी.
टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h"

cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc"

cc_proto_library से बनने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत"

proto_library में, अन्य Java API वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_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 डिफ़ॉल्ट: "सही"

अगर सही है, तो .runfile/wsname/external/repo (.runfiles/repo के अलावा) के अलावा, बाहरी डेटा स्टोर करने की जगहों के लिए रनफ़ाइल सिमलिंक करें.
टैग: affects_outputs

--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत"

यह बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs

--[no]save_temps डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो gcc से मिलने वाले अस्थायी आउटपुट सेव हो जाएंगे. इनमें .s फ़ाइलें (असेम्बलर कोड), .i फ़ाइलें (प्रीप्रोसेस की गई C) और .ii फ़ाइलें (प्रीप्रोसेस की गई C++) शामिल हैं.
टैग: affects_outputs

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--action_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टारगेट कॉन्फ़िगरेशन की कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. यह पेयर, कॉल करने के एनवायरमेंट से अलग वैल्यू सेट करता है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है; एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत और अलग-अलग वैरिएबल के लिए विकल्प इकट्ठा होते हैं.
टैग: action_command_lines

--android_cpu=<a string> डिफ़ॉल्ट: "armeabi-v7a"

Android टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]android_databinding_use_androidx डिफ़ॉल्ट: "सही"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटाबाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग का इस्तेमाल नहीं किया जा सकता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "सही"

3.4.0 आर्ग्युमेंट के साथ Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं पड़ता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद"

यह तय करता है कि जब cc_binary साफ़ तौर पर कोई शेयर की गई लाइब्रेरी न बनाए, तो Android नियमों के C++ डिपेंडेंसी डाइनैमिक तौर पर लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "alphabetical"

यह नीति, Android बाइनरी के लिए मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करती है. अंग्रेज़ी वर्णमाला के क्रम में का मतलब है कि मेनिफ़ेस्ट, execroot के हिसाब से पाथ के हिसाब से क्रम में लगाए जाते हैं. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से, पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]build_python_zip डिफ़ॉल्ट: "auto"

Python के लिए, ज़िप फ़ाइल में प्रोग्राम को चलाने की सुविधा जोड़ना; Windows पर चालू, अन्य प्लैटफ़ॉर्म पर बंद करना
टैग: affects_outputs

--catalyst_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है. इन आर्किटेक्चर के लिए, Apple Catalyst बाइनरी बनाई जानी हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "गलत"

अगर तय किया गया है, तो Bazel कोड को इंस्ट्रूमेंट करेगा. इसके लिए, जहां भी हो सके वहां ऑफ़लाइन इंस्ट्रूमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा की जाएगी. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "fastbuild"

बाइनरी को जिस मोड में बनाया जाएगा उसके बारे में बताएं. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

जीसीसी को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ नाम बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से काम करने वाले FDO इंस्ट्रूमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कॉन्टेक्स्ट के हिसाब से बनी प्रोफ़ाइल को दिखाने वाली cs_fdo_profile, जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.
टैग: affects_outputs

--cxxopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

--define का हर विकल्प, किसी बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default"

यह तय करता है कि C++ बाइनरी को डाइनैमिक रूप से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक होंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी का मैसेज दिखेगा.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "auto"

रनफ़ाइल्स के सिमलिंक ट्री को चालू करें; डिफ़ॉल्ट रूप से, यह Windows और अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अस्पेक्ट के पक्ष में, अब इसका इस्तेमाल नहीं किया जा सकता. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में जावा संसाधनों को कंप्रेस करना
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं पड़ता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत"

dex फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करना
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत"

अगर साफ़ तौर पर बताया गया है, तो Basel, जनरेट की गई फ़ाइलों के कवरेज की जानकारी भी जनरेट करेगा.
टैग: 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/batzbuild/ba बहुत/issues/6526 पर जाएं. Starlark कार्रवाइयां, 'execution_requirements' शब्द में 'supports-path-mapping' बटन को जोड़कर, पाथ मैपिंग में ऑप्ट इन की जा सकती हैं.
टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_name_platform_in_output_dir=<a 'label=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

हर एंट्री, label=value फ़ॉर्मैट में होनी चाहिए. इसमें label, किसी प्लैटफ़ॉर्म का रेफ़रंस देता है और values, आउटपुट पाथ में इस्तेमाल करने के लिए पसंदीदा शॉर्टनेम होता है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_Output_dr सही है. नाम रखने की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय, टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. सटीक स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है: सबसे पहले, अगर --platforms विकल्प में एक ही वैल्यू नहीं है, तो प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir से रजिस्टर किया गया था, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म लेबल के आधार पर किसी छोटे नाम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल आखिरी विकल्प के तौर पर किया जाता है.
टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत"

अगर यह तय किया गया है, तो collect_code_coverage चालू होने पर, Bazel gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic डिफ़ॉल्ट: "सही"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ सुझाई गई माइग्रेशन या टेस्टिंग की रणनीति के हिस्से के तौर पर करें. ध्यान दें कि अनुमान में पहले से मालूम कमियां हैं और यह सुझाव दिया जाता है कि सिर्फ़ --experimental_override_name_platform_in_Output_dr पर निर्भर रहने पर माइग्रेट करें.
टैग: affects_outputs, experimental

--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> बार इस्तेमाल किए गए

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 डिफ़ॉल्ट: "गलत"

इस विकल्प के चालू होने पर, नियम के तहत इस्तेमाल किए गए हर टूलचेन के लिए, एक एक्सेक्यूट ग्रुप अपने-आप बन जाता है. इसके काम करने के लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazubuild/batz/issues/17134 देखें.
टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही"

अगर सही है, तो जेनफ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: 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 डिफ़ॉल्ट: "सही"

अब काम नहीं करता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. इसे चालू होने पर, cc_binary नियमों के लिए -पूरा-संग्रह का इस्तेमाल करें, जिसमें linkshared=True होता है और linkopts में linkstatic=True या '-static' होता है. यह सुविधा सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर, alwayslink=1 का इस्तेमाल करना बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

लिंक करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ बैकएंड चरण को पास करने के लिए एक और विकल्प (-features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

एलटीओ को इंडेक्स करने के चरण पर जाने के लिए अन्य विकल्प (--features=thin_lto में).
टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

ऐसे आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है. इन आर्किटेक्चर के लिए, Apple macOS बाइनरी बनाई जानी हैं.
टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट के लिए, macOS का कम से कम काम करने वाला वर्शन. अगर जानकारी नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

मेमप्रोफ़ प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "गलत"

अगर यह सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS तय करें.
टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत"

लिंक की गई बाइनरी पर, सिंबल और डेड-कोड हटाने की प्रोसेस की जानी चाहिए या नहीं. अगर इस फ़्लैग और --compilation_mode=opt, दोनों को तय किया जाता है, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

--objccopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल किए जाने वाले और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. option_1 से option_n तक, मनमुताबिक कमांड लाइन के विकल्प हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, bar.cc को छोड़कर //foo/ में मौजूद सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड ( --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> डिफ़ॉल्ट: जानकारी देखें

प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए, ld_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: जानकारी देखें

'टेस्ट' और 'रन' निर्देशों के लिए, एक्सीक्यूटेबल के पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू 'foo -bar' है और प्रोग्राम चलाने के लिए इस्तेमाल की जाने वाली कमांड लाइन 'test_binary -baz' है, तो फ़ाइनल कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी ऐसे टारगेट का लेबल भी हो सकता है जिसे चलाया जा सकता है. कुछ उदाहरण: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

--[no]share_native_deps डिफ़ॉल्ट: "सही"

अगर यह सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के बीच शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "गलत"

तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल स्टोर करने की जगह की जानकारी वगैरह के साथ बाइनरी को स्टैंप करें.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि --compilation_mode=fastbuild के लिए, स्ट्रिप करें.
टैग: affects_outputs

--stripopt=<a string> बार इस्तेमाल किए गए

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--swiftcopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Swift कंपाइलेशन के लिए पास करने के अन्य विकल्प.
टैग: action_command_lines

--tvos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं. इसमें आर्किटेक्चर को कॉमा लगाकर अलग किया गया है.
टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट किए गए सिम्युलेटर और डिवाइसों के लिए, काम करने वाला कम से कम tvOS वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

ऐप्लिकेशन के लिए, Apple visionOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम डालें. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू रहेंगे, जैसे कि xbinary_fdo कभी तय नहीं किया गया हो.
टैग: affects_outputs

ऐसे विकल्प जिनसे इस बात पर असर पड़ता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: ""

cpu वैल्यू को target_environment वैल्यू पर अपने-आप मैप करने के लिए, environment_group का इस्तेमाल करें.
टैग: changes_inputs, loading_and_analysis, experimental

--[no]check_licenses डिफ़ॉल्ट: "गलत"

देखें कि डिपेंडेंट पैकेज से लगाई गई लाइसेंस की पाबंदियां, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड से मेल न खाती हों. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: build_file_semantics

--[no]check_visibility डिफ़ॉल्ट: "सही"

अगर इसे बंद किया जाता है, तो टारगेट डिपेंडेंसी में दिखने से जुड़ी गड़बड़ियों को चेतावनियों में बदल दिया जाता है.
टैग: build_file_semantics

--[no]desugar_for_android डिफ़ॉल्ट: "सही"

डेक्स करने से पहले, Java 8 बाइट कोड को इस्तेमाल करना बंद करना है या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "गलत"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 की लाइब्रेरी शामिल करनी हैं या नहीं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints डिफ़ॉल्ट: "सही"

यह जांच करता है कि हर टारगेट किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट में ऐसी डिपेंडेंसी हैं जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की रिपोर्ट करता है
टैग: build_file_semantics

--[no]experimental_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> डिफ़ॉल्ट: "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 डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel, टॉप लेवल डायरेक्ट्री हेडर को शामिल किए जाने की पुष्टि भी करेगा. ज़्यादा जानकारी के लिए, https://github.com/baडेलbuild/baZ/issues/10047 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]one_version_enforcement_on_java_tests डिफ़ॉल्ट: "सही"

यह सुविधा चालू होने पर और formula_one_version_enforcement को गैर-NONE वैल्यू पर सेट करके, java_test टारगेट पर एक वर्शन लागू करें. इंक्रीमेंटल टेस्ट परफ़ॉर्मेंस को बेहतर बनाने के लिए इस फ़्लैग को बंद किया जा सकता है, भले ही एक वर्शन उल्लंघन के संभावित मामले मौजूद न हों.
टैग: loading_and_analysis

--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: जानकारी देखें

लागू करने के दौरान, अनुमति वाली सूची (पैकेज_ग्रुप टारगेट) का इस्तेमाल करें --inबेमेल_python_disallow_native_rules.
टैग: loading_and_analysis

--[no]strict_filesets डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइल सेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "गड़बड़ी"

जब तक इसे बंद न किया जाए, तब तक यह जांच करता है कि proto_library टारगेट साफ़ तौर पर सभी सीधे इस्तेमाल किए गए टारगेट को डिपेंडेंसी के तौर पर बताता है.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद"

जब तक यह विकल्प बंद नहीं होता, तब तक यह जांच की जाती है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर एक्सपोर्ट के तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--[no]strict_system_includes डिफ़ॉल्ट: "गलत"

अगर सही है, तो सिस्टम से मिले हेडर में पाथ शामिल हैं (-isystem) का एलान करना भी ज़रूरी होता है.
टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> बार इस्तेमाल किए गए

इस बिल्ड के टारगेट एनवायरमेंट का एलान करता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर एनवायरमेंट तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

ऐसे विकल्प जिनसे बिल्ड के साइनिंग आउटपुट पर असर पड़ता है:

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2"

APKs पर साइन करने के लिए इस्तेमाल करने का तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements डिफ़ॉल्ट: "सही"

अगर यह सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: जानकारी देखें

iOS साइनिंग के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक, यह सर्टिफ़िकेट की पासकोड की पहचान की प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम का (सबस्ट्रिंग) हो सकता है.
टैग: action_command_lines

इस विकल्प का असर, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/batzbuild/ba इमारतों/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[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_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की सेटिंग दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "गलत"

अगर सही है, तो objc_library और objc_Import में हमेशा लिंक एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही बनाएं.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "गलत"

सही होने पर, पहले से मौजूद py_* नियमों का इस्तेमाल करते समय गड़बड़ी होती है; इसके बजाय,Rule_python नियमों का इस्तेमाल करना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

ऐसे विकल्प जो टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करते हैं:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के AnalysisFailureInfo के इंस्टेंस का प्रॉपेगेशन होता है. इसमें गड़बड़ी की जानकारी होती है. इससे बिल्ड पूरा न होने की स्थिति नहीं होती.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन की ज़्यादा से ज़्यादा संख्या सेट करता है. अगर उपयोगकर्ता ने यह सीमा पार नहीं की, तो नियम में गड़बड़ी होगी.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g. memory=10,30,60,100> बार इस्तेमाल किए गए

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई एक पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगी. अगर कॉमा लगाकर चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की संख्या को बदल देंगी. वैल्यू के तौर पर HOST_RAM/HOST_CPU भी इस्तेमाल किया जा सकता है. इसके बाद, [-|*]<float> भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में बताए गए साफ़ तौर पर दिए गए संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "गलत"

android_test को तेज़ी से बढ़ाने के लिए, साथ में dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "गलत"

ios_test टारगेट में, मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: जानकारी देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है, जैसे कि 'iPhone 6'. डिवाइसों की सूची पाने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला iOS वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> बार इस्तेमाल किए गए

यह हर टेस्ट को कितनी बार चलाने के लिए तय करता है. अगर इनमें से किसी भी कोशिश में किसी वजह से सफलता नहीं मिलती है, तो पूरे टेस्ट को असफल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test, पूर्णांक वैल्यू के लिए है और regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. --instrumentation_filter भी देखें. उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को कई बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को नाम से या name=value पेयर से तय किया जा सकता है. नाम से तय करने पर, वैरिएबल की वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.
टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> डिफ़ॉल्ट: "-1"

टेस्ट टाइम आउट (सेकंड में) के लिए, टेस्ट टाइम आउट की डिफ़ॉल्ट वैल्यू बदलें. अगर एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो वह सभी कैटगरी को बदल देगी. अगर चार पूर्णांकों को कॉमा लगाकर अलग-अलग किया गया है, तो वे कम, सामान्य, ज़्यादा, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. दोनों ही फ़ॉर्म में, -1 की वैल्यू से Blaze को उस कैटगरी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने के लिए कहा जाता है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही"

अगर सही है, तो जिन टेस्ट आउटपुट का एलान नहीं किया गया है उन्हें ZIP फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--[no]configure डिफ़ॉल्ट: "गलत"

सिर्फ़ सिस्टम कॉन्फ़िगरेशन के मकसद से, 'कॉन्फ़िगर करें' के तौर पर मार्क किए गए रिपॉज़िटरी फ़ेच करता है. --enable_bzlmod चालू होने पर ही काम करता है.
टैग: changes_inputs

--[no]force डिफ़ॉल्ट: "गलत"

अगर कोई मौजूदा रिपॉज़िटरी (डेटा स्टोर करने की जगह) है, तो उसे अनदेखा करें. साथ ही, डेटा स्टोर करने की जगह को फिर से फ़ेच करें. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs

--repo=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सिर्फ़ तय की गई रिपॉज़िटरी को फ़ेच करता है. यह {@apparent_repo_name} या {@@canonical_repo_name} हो सकती है. यह सिर्फ़ तब काम करता है, जब --enable_bzlmod चालू हो.
टैग: changes_inputs

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--[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 डिफ़ॉल्ट: "सही"

अगर यह नीति सेट की जाती है, तो क्लैंग की मदद से बनाई गई .d फ़ाइलों का इस्तेमाल, objc कंपाइलों में पास किए गए इनपुट के सेट को छोटा करने के लिए किया जाएगा.
टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "गलत"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग की सुविधा चालू हो.
टैग: execution

--[no]trim_test_configuration डिफ़ॉल्ट: "सही"

इस विकल्प को चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के सबसे ऊपरी लेवल के नीचे से हटा दिए जाएंगे. अगर यह फ़्लैग चालू है, तो टेस्ट को नॉन-टेस्ट नियमों के आधार पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं होगा.
टैग: loading_and_analysis, loses_incremental_state

लॉग इन करने के तरीके, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान, डीबग की जानकारी प्रिंट करें. इस फ़्लैग में रेगुलर एक्सप्रेशन का इस्तेमाल किया जाता है. इस एक्सप्रेशन की जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता लगाया जा सके कि किस टूल को डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. ऐसा हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए ही काम का हो.
टैग: terminal_output

बेज़ल कमांड के लिए, जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--flag_alias=<a 'name=value' flag alias> बार इस्तेमाल किए गए

स्टारलार्क फ़्लैग के लिए शॉर्टहैंड नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत"

इस फ़्लैग से डिफ़ॉल्ट सेटिंग बदल जाती है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बने रहें. खास तौर पर, जब py_binary या py_test टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `baZ-bin` सुविधा सिमलिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. इस विकल्प को चालू करने पर, `--incompatible_py3_is_default` को भी चालू करने का सुझाव दिया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से PY3 का इस्तेमाल किया जाएगा, न कि PY2 का. अगर यह फ़्लैग सेट किया जाता है, तो हमारा सुझाव है कि आप `--incompatible_py2_outputs_are_suffixed` को भी सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के नेटिव नियमों को लागू करने के लिए, --python_top जैसे लेगसी फ़्लैग के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल किया जाएगा.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

Python के मुख्य वर्शन का मोड, या तो `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट बदल देते हैं. भले ही, वे साफ़ तौर पर किसी वर्शन की जानकारी न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "auto"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो Bazel किसी टेस्ट को फिर से सिर्फ़ तब चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट चलाने का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. 'हां' पर सेट होने पर, Bazel बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव कर लेता है. अगर बैज 'नहीं' पर सेट है, तो Basel किसी भी टेस्ट के नतीजे को कैश मेमोरी में नहीं सेव करता.

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

पैकेज के नाम की ऐसी सूची जिसमें बिल्ड सिस्टम मौजूद नहीं होता है. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह शिकायत कर सकता है. ऐसा तब होता है, जब वह लेबल अब भी किसी अन्य package_path एंट्री से दिया जाता है. --deleted_packages x/y तय करना, इस समस्या से बचाता है.

--[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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो क्लैंग के लिए कवरेज एक एलसीओवी रिपोर्ट जनरेट करेगी.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_j2objc_header_map डिफ़ॉल्ट: "सही"

J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.

--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "गलत"

क्या छोटे हेडर पाथ के साथ जनरेट करना है ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग: affects_outputs

--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javabuilder"

Java कंपाइलेशन के लिए, कम क्लासपाथ की सुविधा चालू करता है.

--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत"

--experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--[no]fetch डिफ़ॉल्ट: "सही"

यह कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति देती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल के लिए इस्तेमाल किया जाने वाला Java लॉन्चर.

--host_javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, javac को पास करने के लिए अन्य विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर यह 'सही' है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर सही है, तो 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 VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: जानकारी देखें

लेगसी मल्टीडेक्स को कंपाइल करते समय, मुख्य डेक्स में शामिल होने वाली क्लास की सूची जनरेट करने के लिए, इस्तेमाल की जाने वाली बाइनरी के बारे में बताता है.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

शर्ड किए बिना डेक्स करने के लिए इस्तेमाल की जाने वाली बाइनरी के बारे में बताता है.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज खोजने की जगह की कोलन लगाकर अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--plugin=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड में इस्तेमाल करने के लिए प्लग इन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह नीति तय करती है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना चाहिए.

--proto_compiler=<a build target label> डिफ़ॉल्ट: "@ba"_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 protos को कंपाइल करने का तरीका बताता है
टैग: 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> डिफ़ॉल्ट: "@baZ_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_SH एनवायरमेंट वैरिएबल पहले Basel को शुरू करने की प्रोसेस पर सेट है, (जिससे Baze सर्वर चालू होता है) उसका इस्तेमाल किया जाता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel काम करता है. जैसे, Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने पर, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में गड़बड़ियां हो सकती हैं.
टैग: loading_and_analysis

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

--test_arg=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इससे उन अतिरिक्त विकल्पों और आर्ग्युमेंट की जानकारी मिलती है जिन्हें टेस्ट के लिए इस्तेमाल किए जाने वाले प्रोग्राम को पास किया जाना चाहिए. कई आर्ग्युमेंट तय करने के लिए, कई बार इस्तेमाल किया जा सकता है. अगर एक से ज़्यादा टेस्ट चलाए जाते हैं, तो उनमें से हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करता है.

--test_filter=<a string> डिफ़ॉल्ट: जानकारी देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, चलाए जाने वाले टेस्ट की संख्या को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे बनाए गए टारगेट पर कोई असर नहीं पड़ता.

--test_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 डिफ़ॉल्ट: "गलत"

अगर यह 'गलत है' पर सेट है, तो 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 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन को भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. मान्य वैल्यू में ये शामिल हैं: गड़बड़ी को ठीक करने के लिए उसे 'गड़बड़ी'', जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: 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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बेज़ल मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री के बारे में बताता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के पाथ के तौर पर बताया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <पीरियड> में <count> लगातार जीसीएस होने के बाद भी लंबे समय तक काम करने वाले स्पेस (old gen हीप) के --gc_t इससेhhreshold प्रतिशत से ज़्यादा खाली रहता है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_full_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_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 की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जो लॉग इन करने के तरीके, फ़ॉर्मैट या जगह की जानकारी पर असर डालते हैं:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

यह कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. आर्ग्युमेंट के तौर पर, प्रोफ़ाइलिंग इवेंट का कोई एक टाइप (सीपीयू, वॉल, ऐलोक या लॉक) दिया जाना चाहिए. प्रोफ़ाइल को, आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम वाली फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--help_verbosity=<long, medium or short> डिफ़ॉल्ट: "medium"

सहायता कमांड के लिए, ज़्यादा जानकारी देने का विकल्प चुनें.
टैग: affects_outputs, terminal_output

--long [-l]

हर विकल्प के नाम के बजाय, उसका पूरा ब्यौरा दिखाएं.
इस तरह बड़ा होता है:
  --help_verbosity=long

टैग: affects_outputs, terminal_output

--short

सिर्फ़ विकल्पों के नाम दिखाएं, उनके टाइप या मतलब नहीं.
इसमें बड़ा किया गया है:
  --help_verbosity=short

टैग: affects_outputs, terminal_output

Basel के किसी निर्देश में जेनरिक इनपुट तय करने या बदलने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में पंक्तियां होती हैं, जिनमें से हर एक निर्देश (`allow`, `block` या `rewrite` से शुरू होता है) के बाद एक होस्ट नाम (`allow` और `block` के लिए) या दो पैटर्न होते हैं, एक का मिलान करना है और दूसरे का इस्तेमाल वैकल्पिक यूआरएल के तौर पर किया जाता है. इसमें `$1` से शुरू होने वाले बैक-रेफ़रंस होते हैं. एक ही यूआरएल के लिए एक से ज़्यादा `रीराइट` डायरेक्टिव दिए जा सकते हैं. इस मामले में, एक से ज़्यादा यूआरएल दिए जा सकते हैं.

--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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

जानकारी के विकल्प

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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrtingDetector, मेमोरी दबाव के इवेंट को इसकी सीमाओं के हिसाब से नहीं मानता (--gc_t इससेrapshin_limits). अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन नहीं हो पाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, अनुमति पाए हुए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. साथ ही, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (हटाया गया वर्शन और पहले मौजूद नहीं थे मॉड्यूल) को रीफ़्रेश करने के लिए, `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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, 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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इसे ट्वीट करने से आप GC थ्रैशिंग के वॉल टाइम प्रभाव को कम कर सकते हैं, जब GC थ्रैशिंग (i) इस अस्थायी स्थिति की मेमोरी के उपयोग के कारण होती है और (ii) स्थिति की आवश्यकता होने पर राज्य को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

कमांड के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल रिकॉर्ड करता है. आर्ग्युमेंट के तौर पर, प्रोफ़ाइलिंग इवेंट का कोई एक टाइप (सीपीयू, वॉल, ऐलोक या लॉक) दिया जाना चाहिए. प्रोफ़ाइल को, आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम वाली फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--[no]show_make_env डिफ़ॉल्ट: "गलत"

आउटपुट में "Make" एनवायरमेंट शामिल करें.
टैग: affects_outputs, terminal_output

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड किसी दूसरी कैटगरी में नहीं आता.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें

वह फ़ाइल तय करें जिससे रिमोट डाउनलोडर को कॉन्फ़िगर करना है. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

लाइसेंस के विकल्प

ऐसे विकल्प जो निर्देश से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--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) का वह प्रतिशत है जिससे ज़्यादा GcThrtingDetector, मेमोरी दबाव के इवेंट को इसकी सीमाओं के हिसाब से नहीं मानता (--gc_t इससेrapshin_limits). अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: 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"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. मान्य वैल्यू में ये शामिल हैं: गड़बड़ी को ठीक करने के लिए उसे 'गड़बड़ी'', जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "update"

बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. साथ ही, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (हटाया गया वर्शन और पहले मौजूद नहीं थे मॉड्यूल) को रीफ़्रेश करने के लिए, `refresh` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर यह अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. इसके अलावा, लॉकफ़ाइल से न तो पढ़ने के लिए और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के रूप में लोकल पाथ वाले मॉड्यूल को बदलें. अगर दिया गया पाथ एक ऐब्सलूट पाथ है, तो उसका इस्तेमाल उसी तरह किया जाएगा. अगर दिया गया पाथ, एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--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 होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, Skyframe स्टेटस नहीं छोड़ा जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट रूप से, 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

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

यह कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. इस्तेमाल किए जा सकने वाले प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलॉक या लॉक) में से किसी एक को आर्ग्युमेंट के तौर पर दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम पर बनाई गई फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में पंक्तियां होती हैं, जिनमें से हर एक निर्देश (`allow`, `block` या `rewrite` से शुरू होता है) के बाद एक होस्ट नाम (`allow` और `block` के लिए) या दो पैटर्न होते हैं, एक का मिलान करना है और दूसरे का इस्तेमाल वैकल्पिक यूआरएल के तौर पर किया जाता है. इसमें `$1` से शुरू होने वाले बैक-रेफ़रंस होते हैं. एक ही यूआरएल के लिए एक से ज़्यादा `रीराइट` डायरेक्टिव दिए जा सकते हैं. इस मामले में, एक से ज़्यादा यूआरएल दिए जा सकते हैं.

--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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

मोबाइल पर इंस्टॉल करने के विकल्प

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

--mode=<classic, classic_internal_test_do_not_use or skylark> डिफ़ॉल्ट: "क्लासिक"

mobile-install को चलाने का तरीका चुनें. "classic", mobile-install का मौजूदा वर्शन चलाता है. "skylark" नए Starlark वर्शन का इस्तेमाल करता है, जो android_test में काम करता है.
टैग: loading_and_analysis, execution, incompatible_change

ऐक्शन लागू करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--adb=<a string> डिफ़ॉल्ट: ""

'mobile-install' कमांड के लिए इस्तेमाल किया जाने वाला adb बाइनरी. अगर कोई SDK टूल नहीं चुना जाता है, तो --android_sdk कमांड लाइन विकल्प से तय किए गए Android SDK टूल का इस्तेमाल किया जाता है. अगर --android_sdk का इस्तेमाल नहीं किया जाता है, तो डिफ़ॉल्ट SDK टूल का इस्तेमाल किया जाता है.
टैग: changes_inputs

ऐसे विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:

--[no]incremental डिफ़ॉल्ट: "गलत"

इंक्रीमेंटल इंस्टॉल करना है या नहीं. अगर यह सही है, तो उस डिवाइस की स्थिति को पढ़कर, ग़ैर-ज़रूरी काम से बचने की कोशिश करें जिस पर कोड इंस्टॉल करना है. साथ ही, उस जानकारी का इस्तेमाल करके ग़ैर-ज़रूरी काम से बचें. अगर गलत है (डिफ़ॉल्ट तौर पर), तो हमेशा पूरी तरह से इंस्टॉल करें.
टैग: loading_and_analysis

--[no]split_apks डिफ़ॉल्ट: "गलत"

डिवाइस पर ऐप्लिकेशन को इंस्टॉल और अपडेट करने के लिए, स्प्लिट APK का इस्तेमाल करना है या नहीं. यह सुविधा सिर्फ़ Marshmallow या इसके बाद के वर्शन वाले डिवाइसों पर काम करती है
टैग: loading_and_analysis, affects_outputs

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, तय किए गए आउटपुट को कॉन्फ़िगर कर सकता है. साथ ही, इसकी मदद से आउटपुट की वैल्यू पर असर पड़ता है, न कि इसके मौजूद होने पर:

--adb_arg=<a string> बार इस्तेमाल किए गए

adb को पास करने के लिए अतिरिक्त आर्ग्युमेंट. आम तौर पर, इस डेटा का इस्तेमाल किसी डिवाइस पर इंस्टॉल करने के लिए किया जाता है.
टैग: action_command_lines

--debug_app

क्या ऐप्लिकेशन शुरू करने से पहले, डीबगर के इंतज़ार करना है.
इससे यह जानकारी मिलती है:
  --start=DEBUG

टैग: execution

--device=<a string> डिफ़ॉल्ट: ""

adb डिवाइस का सीरियल नंबर. अगर यह जानकारी नहीं दी गई है, तो पहले डिवाइस का इस्तेमाल किया जाएगा.
टैग: action_command_lines

--start=<no, cold, warm or debug> डिफ़ॉल्ट: "NO"

इंस्टॉल करने के बाद, ऐप्लिकेशन को कैसे शुरू किया जाना चाहिए. इंस्टॉल करने की संख्या में बढ़ोतरी होने पर भी ऐप्लिकेशन की स्थिति को बनाए रखने और उसे पहले जैसा करने के लिए, WARM पर सेट करें.
टैग: execution

--start_app

इंस्टॉल करने के बाद, ऐप्लिकेशन को शुरू करना है या नहीं.
इस तरह बड़ा होता है:
  --start=COLD

टैग: execution

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> बार इस्तेमाल किए गए

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन को भी अनुमति दी जा सकती है. कीवर्ड 'सभी' का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, हम इसका सुझाव नहीं देते.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर MODULE.bazel रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू के बावजूद, डेवलपर डिपेंडेंसी को हमेशा अनदेखा कर दिया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "update"

यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे और कब करना है. लॉकफ़ाइल का इस्तेमाल करने और बदलाव होने पर उसे अपडेट करने के लिए, `update` वैल्यू का इस्तेमाल करें. साथ ही, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (हटाया गया वर्शन और पहले मौजूद नहीं थे मॉड्यूल) को रीफ़्रेश करने के लिए, `refresh` वैल्यू का इस्तेमाल करें. लॉकफ़ाइल का इस्तेमाल करने के लिए, `error` वैल्यू का इस्तेमाल करें. हालांकि, अगर यह अप-टू-डेट नहीं है, तो गड़बड़ी का मैसेज दिखाएं. इसके अलावा, लॉकफ़ाइल से न तो पढ़ने के लिए और न ही उसमें लिखने के लिए, `off` वैल्यू का इस्तेमाल करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के पाथ के तौर पर बताया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा <period>:<count> के तौर पर बताई जाती है. इसमें पीरियड की जानकारी कुल समय और संख्या, पॉज़िटिव पूर्णांक होती है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. ज़ीरो का मतलब है कि पूरे जीसी इवेंट का डेटा कभी भी ड्रॉप नहीं होगा. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, 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 सेट की गई सीमा से ज़्यादा है, तो मामूली GC इवेंट होने पर, वह हर बार इस सीमा तक अनावश्य Skyframe स्टेटस को छोड़ देगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: ब्यौरा देखें

कमांड के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल रिकॉर्ड करता है. आर्ग्युमेंट के तौर पर, प्रोफ़ाइलिंग इवेंट का कोई एक टाइप (सीपीयू, वॉल, ऐलोक या लॉक) दिया जाना चाहिए. प्रोफ़ाइल को, आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम वाली फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--incremental_install_verbosity=<a string> डिफ़ॉल्ट: ""

इंक्रीमेंटल इंस्टॉल के लिए ज़्यादा जानकारी. डीबग लॉगिंग के लिए, वैल्यू को 1 पर सेट करें.
टैग: bazel_monitoring

ऐसे विकल्प जो किसी सामान्य इनपुट को Bazel कमांड में बदलते हैं या उसमें बदलाव करते हैं. यह कमांड, अन्य कैटगरी में नहीं आता.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर यह टैग मौजूद है, तो WORKSPACE फ़ाइल के बजाय, तय की गई फ़ाइल को पढ़ें
टैग: changes_inputs

रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: जानकारी देखें

रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए, कोई फ़ाइल चुनें. इस फ़ाइल में लाइनें होती हैं. हर लाइन किसी डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होती है. इसके बाद, `allow` और `block` के लिए होस्ट नेम या दो पैटर्न होते हैं. एक पैटर्न, मैच करने के लिए होता है और दूसरा, यूआरएल के विकल्प के तौर पर इस्तेमाल किया जाता है. इसमें बैक-रेफ़रंस, `$1` से शुरू होते हैं. एक ही यूआरएल के लिए कई `rewrite` डायरेक्टिव दिए जा सकते हैं. इस मामले में, कई यूआरएल दिखाए जाएंगे.

--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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

मोड के विकल्प

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--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_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है; ctx.execute अब भी इंटरनेट को ऐक्सेस करने वाला कोई भी एक्सीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrtingDetector, मेमोरी दबाव के इवेंट को इसकी सीमाओं के हिसाब से नहीं मानता (--gc_t इससेrapshin_limits). अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

इस विकल्प से, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने की जानकारी देने वाले एट्रिब्यूट के बिना किसी भी config_setting के लिए, //visibility:public लागू होता है. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/batzbuild/ba इमारतों/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की सेटिंग दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

`mod` सब-कमांड के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--base_module=<"<root>" for the root module; <module>@<version> for a specific version of a module; <module> for all versions of a module; @<name> for a repo with the given apparent name; or @@<name> for a repo with the given canonical name> डिफ़ॉल्ट: "<root>"

कोई ऐसा मॉड्यूल तय करें जिसके हिसाब से, तय किए गए टारगेट रिपॉज़िटरी का विश्लेषण किया जाएगा.
टैग: terminal_output

--charset=<utf8 or ascii> डिफ़ॉल्ट: "utf8"

इस विकल्प से, ट्री के लिए इस्तेमाल किया जाने वाला वर्ण सेट चुना जाता है. इसका असर सिर्फ़ टेक्स्ट आउटपुट पर पड़ता है. मान्य वैल्यू "utf8" या "ascii" हैं. डिफ़ॉल्ट तौर पर "utf8" होता है
टैग: terminal_output

--[no]cycles डिफ़ॉल्ट: "गलत"

दिखाए गए ट्री में, डिपेंडेंसी साइकल की जानकारी देता है. आम तौर पर, डिफ़ॉल्ट रूप से इन साइकल को अनदेखा किया जाता है.
टैग: terminal_output

--depth=<an integer> डिफ़ॉल्ट: "-1"

डिपेंडेंसी ट्री की ज़्यादा से ज़्यादा डिसप्ले गहराई. उदाहरण के लिए, डेप्थ 1, सीधे डिपेंडेंसी दिखाता है. tree, path, और all_paths के लिए, यह डिफ़ॉल्ट रूप से Integer.MAX_VALUE पर सेट होता है. वहीं, deps और explain के लिए, यह डिफ़ॉल्ट रूप से 1 पर सेट होता है. यह सिर्फ़ टारगेट लीफ़ और उनके पैरंट के अलावा, रूट के डायरेक्ट डिपेंडेंसी दिखाता है.
टैग: terminal_output

--extension_filter=<a comma-separated list of <extension>s> डिफ़ॉल्ट: ब्यौरा देखें

सिर्फ़ तब इन मॉड्यूल एक्सटेंशन और उनके जनरेट किए गए रिपॉज़िटरी के इस्तेमाल को दिखाएं, जब उनके फ़्लैग सेट हों. अगर यह सेट है, तो नतीजों के ग्राफ़ में सिर्फ़ वे पाथ शामिल होंगे जिनमें बताए गए एक्सटेंशन का इस्तेमाल करने वाले मॉड्यूल शामिल हैं. खाली सूची, फ़िल्टर को बंद कर देती है. साथ ही, सभी संभावित एक्सटेंशन को असरदार तरीके से दिखाती है.
टैग: terminal_output

--extension_info=<hidden, usages, repos or all> डिफ़ॉल्ट: "hidden"

तय करें कि क्वेरी के नतीजे में, एक्सटेंशन के इस्तेमाल के बारे में कितनी जानकारी शामिल करनी है. "इस्तेमाल" में सिर्फ़ एक्सटेंशन के नाम दिखेंगे. "रिपॉज़िटरी" में, use_repo की मदद से इंपोर्ट की गई रिपॉज़िटरी भी शामिल होंगी. साथ ही, "सभी" में एक्सटेंशन से जनरेट की गई अन्य रिपॉज़िटरी भी दिखेंगी.
टैग: terminal_output

--extension_usages=<a comma-separated list of <module>s> डिफ़ॉल्ट: ""

उन मॉड्यूल की जानकारी दें जिनके एक्सटेंशन के इस्तेमाल की जानकारी, show_extension क्वेरी में दिखेगी.
टैग: terminal_output

--from=<a comma-separated list of <module>s> डिफ़ॉल्ट: "<root>"

वह मॉड्यूल जिससे डिपेंडेंसी ग्राफ़ की क्वेरी दिखेगी. सटीक सेमेटिक्स के लिए, हर क्वेरी के ब्यौरे की जांच करें. डिफ़ॉल्ट रूप से <root> पर सेट होता है.
टैग: terminal_output

--[no]include_builtin डिफ़ॉल्ट: "गलत"

डिपेंडेंसी ग्राफ़ में, पहले से मौजूद मॉड्यूल शामिल करें. यह डिफ़ॉल्ट रूप से बंद होता है, क्योंकि इसमें बहुत शोर होता है.
टैग: terminal_output

--[no]include_unused डिफ़ॉल्ट: "गलत"

क्वेरी में, ऐसे मॉड्यूल भी शामिल किए जाएंगे और दिखाए जाएंगे जिन्हें इस्तेमाल नहीं किया गया है. ये मॉड्यूल, चुने जाने के बाद मॉड्यूल रिज़ॉल्यूशन ग्राफ़ में नहीं दिखते. ऐसा, कम से कम वर्शन चुनने या बदलाव करने के नियमों की वजह से होता है. इससे हर तरह की क्वेरी पर अलग-अलग असर पड़ सकता है. जैसे, all_paths कमांड में नए पाथ शामिल करना या explain कमांड में अतिरिक्त डिपेंडेंट शामिल करना.
टैग: terminal_output

--output=<text, json or graph> डिफ़ॉल्ट: "text"

क्वेरी के नतीजों को जिस फ़ॉर्मैट में प्रिंट करना है. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: टेक्स्ट, जेएसओएन, ग्राफ़
टैग: terminal_output

--[no]verbose डिफ़ॉल्ट: "गलत"

क्वेरी में यह भी दिखेगा कि मॉड्यूल को उनके मौजूदा वर्शन में क्यों बदला गया (अगर बदला गया है). सिर्फ़ पूरी जानकारी देने वाली क्वेरी के लिए, डिफ़ॉल्ट तौर पर 'सही' पर सेट होती है.
टैग: terminal_output

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन को भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को हमेशा MODULE.bazu में अनदेखा किया जाता है.
टैग: 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> बार इस्तेमाल किए गए

बेज़ल मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री के बारे में बताता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: 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 इससेhhreshold प्रतिशत से ज़्यादा खाली रहता है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: 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 इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, मामूली जीसी इवेंट होने पर Skyframe की स्थिति को ड्रॉप नहीं किया जाएगा. साथ ही, रीटेन किए गए हेप के प्रतिशत के थ्रेशोल्ड को पार करने पर भी ऐसा नहीं किया जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (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"

रिपॉज़िटरी फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. ऐसा न होने पर, वर्चुअल वर्कर्स थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, आपके क्लाइंट में x/y/BUILD को मिटाने के बाद, बिल्ड सिस्टम इसकी शिकायत कर सकता है. ऐसा तब होता है, जब उसे '//x:y/z' लेबल मिलता है. ऐसा तब होता है, जब उसे अब भी किसी दूसरी Package_path एंट्री से मिला हो. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<repository name>=<path> के फ़ॉर्मैट में, किसी लोकल पाथ की मदद से किसी रिपॉज़िटरी को बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका इस्तेमाल मौजूदा वर्किंग डायरेक्ट्री के हिसाब से किया जाएगा. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

Print_action के विकल्प

build से सभी विकल्प इनहेरिट करता है.

ऐसे विकल्प जो निर्देश से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो कैश मेमोरी में फ़ाइल मौजूद होने पर, रिपॉज़िटरी कैश मेमोरी, फ़ाइल को कॉपी करने के बजाय उसे हार्डलिंक कर देगी. इसका मकसद डिस्क में बचा स्टोरेज बचाना है.
टैग: bazel_internal_configuration

--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_exact} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं होगी. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है; ctx.execute अब भी इंटरनेट को ऐक्सेस करने वाला कोई भी एक्सीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrtingDetector, मेमोरी दबाव के इवेंट को इसकी सीमाओं के हिसाब से नहीं मानता (--gc_t इससेrapshin_limits). अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

Bzlmod आउटपुट और सिमेंटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, अनुमति पाए हुए वर्शन को भी तय किया जा सकता है. कीवर्ड 'सभी' का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, हम इसका सुझाव नहीं देते.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को हमेशा MODULE.bazu में अनदेखा किया जाता है.
टैग: 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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

--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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें 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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, Skyframe स्टेटस नहीं छोड़ा जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, मामूली जीसी इवेंट होने पर Skyframe की स्थिति को ड्रॉप नहीं किया जाएगा. साथ ही, रीटेन किए गए हेप के प्रतिशत के थ्रेशोल्ड को पार करने पर भी ऐसा नहीं किया जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (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` से शुरू होने वाले बैक-रेफ़रंस होते हैं. एक ही यूआरएल के लिए एक से ज़्यादा `रीराइट` डायरेक्टिव दिए जा सकते हैं. इस मामले में, एक से ज़्यादा यूआरएल दिए जा सकते हैं.

--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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--print_action_mnemonics=<a string> बार इस्तेमाल किए गए

इसमें उन मेमोनिम की सूची होती है जिनके हिसाब से print_action डेटा को फ़िल्टर किया जाता है. खाली छोड़ने पर, कोई फ़िल्टर नहीं किया जाता.

क्वेरी के विकल्प

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--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 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--[no]keep_going [-k] डिफ़ॉल्ट: "गलत"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जो टारगेट पूरा नहीं हो पाया और जो उस पर निर्भर हैं उनका विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें हो सकती हैं.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

इस विकल्प से, 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/baडेलbuild/bagel/issues/12932 देखें.
टैग: loading_and_analysis, incompatible_change

क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव"

अगर आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक है, तो आसपेक्ट की डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी ऐस्पेक्ट की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि एस्पेक्ट की सभी डिपेंडेंसी जोड़ दी गई हैं, भले ही उन्हें डायरेक्ट डिपेंडेंसी की नियम क्लास दी गई हो. 'सटीक' का मतलब है कि सिर्फ़ वे ऐस्पेक्ट जोड़े जाते हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से चालू हो सकते हैं. ध्यान दें कि सटीक मोड को एक ही टारगेट का आकलन करने के लिए, अन्य पैकेज लोड करने की ज़रूरत होती है. इस तरह, यह अन्य मोड के मुकाबले धीमा हो जाता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी एस्पेक्ट का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह 'bazel क्वेरी' के दौरान नहीं चलता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर यह सुविधा चालू है, तो हर क्वेरी कमांड, लेबल को ऐसे दिखाता है जैसे कि <code>Label</code> इंस्टेंस पर Starlark <code>str</code> फ़ंक्शन लागू किया गया हो. यह उन टूल के लिए मददगार है जिन्हें नियमों से जनरेट किए गए अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट को ज़्यादा आसानी से पढ़ने लायक बनाने के लिए, आउटपुट फ़ॉर्मैटर, मुख्य रिपॉज़िटरी के हिसाब से, रिपॉज़िटरी के नाम दिखा सकते हैं.
टैग: terminal_output

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: कोई कार्रवाई नहीं (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]experimental_graphless_query डिफ़ॉल्ट: "auto"

अगर यह सही है, तो क्वेरी लागू करने के लिए उस तरीके का इस्तेमाल किया जाता है जो ग्राफ़ की कॉपी नहीं बनाता. नए तरीके में, सिर्फ़ --order_output=no और आउटपुट फ़ॉर्मैटर के सबसेट का इस्तेमाल किया जा सकता है.
टैग: build_file_semantics, eagerness_to_exit

--graph:conditional_edges_limit=<an integer> डिफ़ॉल्ट: "4"

शर्त वाले लेबल की ज़्यादा से ज़्यादा संख्या. -1 का मतलब है कि कोई काट-छांट नहीं की गई और 0 का मतलब है कि कोई एनोटेशन नहीं है. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि टॉपोलॉजिकल तौर पर एक जैसे नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल को जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल काट दिए जाएंगे; -1 का मतलब है कि लेबल काटा नहीं जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी काम करती है. ऐसी डिपेंडेंसी जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन जिसे bazel ने जोड़ा है उसे इंप्लिसिट डिपेंडेंसी कहा जाता है. क्वेरी के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग: build_file_semantics

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: आउटपुट में, आसपेक्ट से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: कोई कार्रवाई नहीं (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]incompatible_lexicographical_output डिफ़ॉल्ट: "सही"

अगर यह विकल्प सेट है, तो --order_output=auto आउटपुट को वर्णमाला के क्रम में क्रम से लगाया जाता है.
टैग: terminal_output, incompatible_change

--[no]incompatible_package_group_includes_double_slash डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, शुरुआत में मौजूद `//` को नहीं हटाया जाएगा.
टैग: terminal_output, incompatible_change

--[no]infer_universe_scope डिफ़ॉल्ट: "गलत"

अगर --universe_scope सेट है और --universe_scope की वैल्यू सेट नहीं है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर अनुमानित किया जाएगा. ध्यान दें कि यूनिवर्स के दायरे वाले फ़ंक्शन (उदाहरण के लिए, `allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए, --universe_scope वैल्यू आपके हिसाब से नहीं हो सकती. इसलिए, आपको इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query पर जाएं. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` पर लागू होता है (यानी `cquery` पर नहीं).
टैग: loading_and_analysis

--[no]line_terminator_null डिफ़ॉल्ट: "गलत"

क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 के साथ खत्म किया जाता है.
टैग: terminal_output

--[no]nodep_deps डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो "nodep" एट्रिब्यूट से जुड़ी डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, `info build-language` के आउटपुट को चलाएं और पार्स करें.
टैग: build_file_semantics

--noorder_results

नतीजों को डिफ़ॉल्ट रूप से, डिपेंडेंसी के क्रम में या बिना किसी क्रम के दिखाएं. बिना क्रम के आउटपुट तेज़ी से मिलता है. हालांकि, यह सिर्फ़ तब काम करता है, जब --output में minrank, maxrank या graph न हो.
इसमें बड़ा किया जाता है:
  --order_output=no

टैग: terminal_output

--null

क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाता है.
इस तरह बड़ा होता है:
  --line_terminator_null=true

टैग: terminal_output

--order_output=<no, deps, auto or full> डिफ़ॉल्ट: "auto"

बिना किसी क्रम के (नहीं), डिपेंडेंसी-ऑर्डर (deps) या पूरी तरह से ऑर्डर किए गए (फ़ुल) के नतीजे आउटपुट करते हैं. डिफ़ॉल्ट रूप से, यह 'अपने-आप' पर सेट होता है. इसका मतलब है कि नतीजे, आउटपुट फ़ॉर्मैटर के आधार पर, डिपेंडेंसी के क्रम में या पूरी तरह से क्रम में आउटपुट किए जाते हैं. प्रोटो, minrank, maxrank, और ग्राफ़ के लिए डिपेंडेंसी के क्रम में और बाकी सभी के लिए पूरी तरह से क्रम में. जब आउटपुट पूरी तरह से क्रम में होता है, तो नोड पूरी तरह से तय (कुल) क्रम में प्रिंट किए जाते हैं. सबसे पहले, सभी नोड वर्णमाला के क्रम में लगाए जाते हैं. इसके बाद, सूची के हर नोड का इस्तेमाल पोस्ट-ऑर्डर डेप्थ-फ़र्स्ट सर्च के शुरुआती हिस्से के रूप में किया जाता है. इसमें जिन नोड पर विज़िट नहीं किए गए हैं उन्हें आगे वाले नोड के वर्णमाला के क्रम में ट्रैवर्स किया जाता है. आखिर में, नोड उसी क्रम में प्रिंट किए जाते हैं जिस क्रम में उन्हें विज़िट किया गया था.
टैग: terminal_output

--order_results

नतीजों को डिफ़ॉल्ट रूप से, डिपेंडेंसी के क्रम में या बिना किसी क्रम के दिखाएं. बिना क्रम के आउटपुट तेज़ी से मिलता है. हालांकि, यह सिर्फ़ तब काम करता है, जब --output में minrank, maxrank या graph न हो.
इसमें बड़ा किया जाता है:
  --order_output=auto

टैग: terminal_output

--output=<a string> डिफ़ॉल्ट: "लेबल"

क्वेरी के नतीजों को जिस फ़ॉर्मैट में प्रिंट करना है. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: build, graph, streamed_jsonproto, label, label_kind, location, maxrank, minrank, package, proto, streamed_proto, textproto, xml.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर यह सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. अगर यह गलत है, तो उन्हें शामिल नहीं किया जाता. यह विकल्प --output=proto पर लागू होता है
टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह फ़ील्ड, नियम के इंस्टेंस के लिए Starlark कॉल स्टैक को उस समय रिकॉर्ड करता है, जब नियम की क्लास तय की गई थी.
टैग: terminal_output

--[no]proto:flatten_selects डिफ़ॉल्ट: "सही"

अगर यह चालू है, तो select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची के टाइप के लिए, फ़्लैट किया गया रिप्रज़ेंटेशन एक सूची होती है, जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप को फ़्लैट करके शून्य कर दिया जाता है.
टैग: build_file_semantics

--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "गलत"

हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड को उस सोर्स एस्पेक्ट से पॉप्युलेट करें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स एस्पेक्ट से नहीं मिला है, तो उसे खाली स्ट्रिंग से पॉप्युलेट करें.
टैग: terminal_output

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "गलत"

$internal_attr_hash एट्रिब्यूट का हिसाब लगाना है या नहीं. साथ ही, इसमें वैल्यू डालनी है या नहीं.
टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "गलत"

हर नियम के इंस्टैंशिएट करने वाले कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक मौजूद होना ज़रूरी है
टैग: terminal_output

--[no]proto:locations डिफ़ॉल्ट: "सही"

क्या प्रोटो आउटपुट में जगह की जानकारी को आउटपुट करना है या नहीं.
टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> डिफ़ॉल्ट: "all"

आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा से अलग की गई सूची. डिफ़ॉल्ट रूप से सभी एट्रिब्यूट के लिए लागू होता है. कोई एट्रिब्यूट न दिखाने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --output=proto पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

rule_input और rule_output फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग: terminal_output

--query_file=<a string> डिफ़ॉल्ट: ""

अगर इसे सेट किया जाता है, तो क्वेरी कमांड लाइन के बजाय, यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां फ़ाइल के साथ-साथ कमांड-लाइन क्वेरी भी डालने पर गड़बड़ी होती है.
टैग: changes_inputs

--[no]relative_locations डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग: terminal_output

--[no]strict_test_suite डिफ़ॉल्ट: "गलत"

अगर सही है, तो test() एक्सप्रेशन को तब गड़बड़ी का मैसेज मिलता है, जब उसे बिना जांच वाले टारगेट वाला test_suite मिलता है.
टैग: build_file_semantics, eagerness_to_exit

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: अगर इसे बंद किया जाता है, तो 'एग्ज़ीक्यूट कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'एक्ज़िक कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर भेजा जाता है. आम तौर पर, यह उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल की ओर इशारा करता है. Cquery: अगर यह बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो इस कॉन्फ़िगर किए गए टारगेट को खोजने वाले टॉप-लेवल टारगेट से, एक से ज़्यादा बार ट्रांज़िशन करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. ये वे टारगेट भी होंगे जो टारगेट कॉन्फ़िगरेशन में शामिल हैं. अगर टॉप-लेवल टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प में, हल किए गए टूलचेन शामिल नहीं होंगे.
टैग: build_file_semantics

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ और घटाव). क्वेरी, तय किए गए टारगेट के ट्रांज़िशन क्लोज़र से तय किए गए यूनिवर्स में की जा सकती है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प में इनपुट के तौर पर वे टारगेट डाले जाते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, इस विकल्प का असर कॉन्फ़िगरेशन और ट्रांज़िशन पर पड़ सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माना जाता है. ध्यान दें: cquery के लिए, इस विकल्प को न बताने पर, हो सकता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल विकल्पों के साथ बिल्ड न हो पाएं.
टैग: loading_and_analysis

--[no]xml:default_values डिफ़ॉल्ट: "गलत"

अगर सही है, तो नियम के वे एट्रिब्यूट प्रिंट कर दिए जाते हैं जिनकी वैल्यू, बिल्ड फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें शामिल नहीं किया जाता है.
टैग: terminal_output

--[no]xml:line_numbers डिफ़ॉल्ट: "सही"

अगर यह सही है, तो एक्सएमएल आउटपुट में लाइन नंबर शामिल होते हैं. इस विकल्प को बंद करने से, बदलावों को पढ़ना आसान हो सकता है. यह विकल्प सिर्फ़ --output=xml पर लागू होता है.
टैग: terminal_output

Bzlmod आउटपुट और सिमेंटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन को भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि 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.bazu में अनदेखा किया जाता है.
टैग: 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 इससेhhreshold प्रतिशत से ज़्यादा खाली रहता है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: 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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, 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 सेट की गई सीमा से ज़्यादा है, तो मामूली GC इवेंट होने पर, वह हर बार इस सीमा तक अनावश्य Skyframe स्टेटस को छोड़ देगा. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल Skyframe इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: जानकारी देखें

कमांड के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल रिकॉर्ड करता है. इस्तेमाल किए जा सकने वाले प्रोफ़ाइलिंग इवेंट टाइप (सीपीयू, वॉल, ऐलॉक या लॉक) में से किसी एक को आर्ग्युमेंट के तौर पर दिया जाना चाहिए. प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में, इवेंट टाइप के नाम पर बनाई गई फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 तक सीमित होती है. इसमें, सबसे ज़्यादा कार्रवाइयां करने वाले 20 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

अगर यह वैल्यू खाली नहीं है, तो Starlark की वैल्यू लिखें. इसमें, Starlark के उन सभी रिपॉज़िटरी नियमों की जानकारी शामिल होनी चाहिए जिन्हें लागू किया गया था.
टैग: affects_outputs

ऐसे विकल्प जो किसी सामान्य इनपुट को 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"

रिपॉज़िटरी फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. ऐसा न होने पर, वर्चुअल वर्कर्स थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह शिकायत कर सकता है. ऐसा तब होता है, जब वह लेबल अब भी किसी अन्य package_path एंट्री से दिया जाता है. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह वह किया गया है. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, पास के फ़ाइल फ़ोल्डर के मिलते-जुलते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

रन करने के विकल्प

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 डिफ़ॉल्ट: "गलत"

अगर गलत है, तो वर्कस्पेस में नेटिव रेपो नियमों का इस्तेमाल किया जा सकता है. अगर ऐसा नहीं है, तो इसकी जगह 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]run डिफ़ॉल्ट: "सही"

अगर यह फ़ॉल्स है, तो बनाए गए टारगेट के लिए बनाई गई कमांड लाइन को चलाने से बचें.
टैग: affects_outputs

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

टेंन्चर स्पेस के इस्तेमाल का प्रतिशत (0-100). इस प्रतिशत से ज़्यादा होने पर, GcThrashingDetector मेमोरी प्रेशर इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से तय करता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--script_path=<a path> डिफ़ॉल्ट: जानकारी देखें

अगर यह नीति सेट की जाती है, तो टारगेट को शुरू करने वाली फ़ाइल के लिए एक शेल स्क्रिप्ट लिखें. अगर यह विकल्प सेट है, तो टारगेट को bazel से नहीं चलाया जाता. '//foo' टारगेट को शुरू करने के लिए, 'bazel run --script_path=foo //foo && ./foo' का इस्तेमाल करें. यह 'bazel run //foo' से अलग है, क्योंकि इसमें bazel लॉक रिलीज़ हो जाता है और एक्सीक्यूटेबल, टर्मिनल के स्टडिन से कनेक्ट हो जाता है.
टैग: affects_outputs, execution

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--allow_yanked_versions=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

मॉड्यूल के वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय किया गया है. इन वर्शन को रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में तब भी अनुमति दी जाएगी, जब उन्हें उस रजिस्ट्री में हटा दिया गया हो जहां से वे आते हैं (अगर वे किसी NonRegistryOverride से नहीं आ रहे हैं). ऐसा न करने पर, हटाए गए वर्शन की वजह से समस्या हल नहीं हो पाएगी. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, हटाए गए वर्शन को भी अनुमति दी जा सकती है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, इसका सुझाव नहीं दिया जाता.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "error"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel रूट मॉड्यूल के MODULE.bazel में, `dev_dependency` के तौर पर बताए गए `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को हमेशा MODULE.bazu में अनदेखा किया जाता है.
टैग: 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

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--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 इससेhhreshold प्रतिशत से ज़्यादा खाली रहता है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाओं को कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_full_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_minor_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (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` से शुरू होने वाले बैक-रेफ़रंस होते हैं. एक ही यूआरएल के लिए एक से ज़्यादा `रीराइट` डायरेक्टिव दिए जा सकते हैं. इस मामले में, एक से ज़्यादा यूआरएल दिए जा सकते हैं.

--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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

बंद करने के विकल्प

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--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

ऐसे विकल्प जो निर्देश के आउटपुट को कंट्रोल करते हैं:

--iff_heap_size_greater_than=<an integer> डिफ़ॉल्ट: "0"

अगर यह वैल्यू शून्य से ज़्यादा है, तो सर्वर सिर्फ़ तब बंद होगा, जब JVM का इस्तेमाल की गई कुल मेमोरी (एमबी में) इस वैल्यू से ज़्यादा हो.
टैग: loses_incremental_state, eagerness_to_exit

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"

देखें कि 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` है और बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल को अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या उसमें लिखने के लिए `बंद` करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<module name>=<path> के फ़ॉर्मैट में, किसी मॉड्यूल को स्थानीय पाथ से बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका मतलब मौजूदा वर्किंग डायरेक्ट्री से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बेज़ल मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री के बारे में बताता है. यह क्रम अहम है: मॉड्यूल को सबसे पहले पिछली रजिस्ट्री में देखा जाएगा. बाद की रजिस्ट्री में सिर्फ़ तब जुड़ें, जब वे पिछली रजिस्ट्री में न हों.
टैग: 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> के तौर पर बताई जाती है. इसमें पीरियड की जानकारी कुल समय और संख्या, पॉज़िटिव पूर्णांक होती है. अगर <पीरियड> में <count> लगातार जीसीएस होने के बाद भी लंबे समय तक काम करने वाले स्पेस (old gen हीप) के --gc_t इससेhhreshold प्रतिशत से ज़्यादा खाली रहता है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से सेट किए गए स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए, इसकी वजह से यह तय सीमा तक कई बार रुक जाएगी. डिफ़ॉल्ट रूप से, Integer.MAX_VALUE पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, मामूली जीसी इवेंट होने पर Skyframe की स्थिति को ड्रॉप नहीं किया जाएगा. साथ ही, रीटेन किए गए हेप के प्रतिशत के थ्रेशोल्ड को पार करने पर भी ऐसा नहीं किया जाएगा.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

सिंक करने के विकल्प

ऐसे विकल्प जो निर्देश से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--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_exact} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं होगी. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है; ctx.execute अब भी इंटरनेट को ऐक्सेस करने वाला कोई भी एक्सीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--[no]configure डिफ़ॉल्ट: "गलत"

सिर्फ़ ऐसे डेटा स्टोर करने की जगह को सिंक करें जिन्हें सिस्टम कॉन्फ़िगरेशन के लिए, 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है.
टैग: changes_inputs

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrtingDetector, मेमोरी दबाव के इवेंट को इसकी सीमाओं के हिसाब से नहीं मानता (--gc_t इससेrapshin_limits). अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

--[no]keep_going [-k] डिफ़ॉल्ट: "गलत"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जो टारगेट पूरा नहीं हो पाया और जो उस पर निर्भर हैं उनका विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें हो सकती हैं.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--only=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

अगर यह विकल्प दिया जाता है, तो सिर्फ़ इस विकल्प में बताई गई रिपॉज़िटरी सिंक करें. अब भी सभी (या कॉन्फ़िगरेशन-जैसे सभी कॉन्फ़िगरेशन को दिया गया है) को पुराना मानें.
टैग: changes_inputs

इस विकल्प से, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट नहीं है, तो उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/baडेलbuild/bagel/issues/12932 देखें.
टैग: loading_and_analysis, incompatible_change

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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.bagel में `dev_dependency` के तौर पर एलान किए गए `bagel_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> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: 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 इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर 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 मेनिमोनिक शामिल होते हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

--experimental_repository_resolved_file=<a string> डिफ़ॉल्ट: ""

अगर वैल्यू खाली नहीं है, तो Starlark के डेटा स्टोर करने की जगह के उन सभी नियमों की रिज़ॉल्व की गई जानकारी के साथ Starlark वैल्यू लिखें जिन्हें लागू किया गया था.
टैग: affects_outputs

ऐसे विकल्प जो किसी सामान्य इनपुट को 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"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर इसे 'बंद' पर सेट किया जाता है, तो किसी भी वर्क थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रिपॉज़िटरी को फ़ेच करने के लिए, रीस्टार्ट की ज़रूरत पड़ सकती है. ऐसा न होने पर, वर्चुअल वर्कर्स थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--deleted_packages=<comma-separated list of package names> बार इस्तेमाल किए गए

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह शिकायत कर सकता है. ऐसा तब होता है, जब वह लेबल अब भी किसी अन्य package_path एंट्री से दिया जाता है. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इस नीति को 'बंद है' पर सेट किया जाता है, तो निर्देश डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो निर्देश काम नहीं करेगा.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<repository name>=<path> के फ़ॉर्मैट में, किसी लोकल पाथ की मदद से किसी रिपॉज़िटरी को बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका इस्तेमाल मौजूदा वर्किंग डायरेक्ट्री के हिसाब से किया जाएगा. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर यह विकल्प चालू है, तो Bazel "पैकेज लोड हो रहा है:" मैसेज प्रिंट करता है.

टेस्ट के विकल्प

build से सभी विकल्प इनहेरिट करता है.

ऐसे विकल्प जो निर्देश से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--distdir=<a path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

नेटवर्क को ऐक्सेस करके उन्हें डाउनलोड करने से पहले, संग्रह खोजने के लिए अन्य जगहें.
टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "गलत"

अगर यह नीति सेट है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कैश मेमोरी के हिट होने पर फ़ाइल को कॉपी करने के बजाय, हार्डलिंक करेगी. इसका मकसद डिस्क स्पेस बचाना है.
टैग: bazel_internal_configuration

--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

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"

देखें कि Bazel मॉड्यूल, Bazel के किस वर्शन के साथ काम करते हैं. मान्य वैल्यू में ये शामिल हैं: गड़बड़ी को ठीक करने के लिए उसे 'गड़बड़ी'', जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: 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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. यह क्रम अहम है: मॉड्यूल को सबसे पहले पिछली रजिस्ट्री में देखा जाएगा. बाद की रजिस्ट्री में सिर्फ़ तब जुड़ें, जब वे पिछली रजिस्ट्री में न हों.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इस नीति के तहत, उस डायरेक्ट्री के बारे में बताया जाता है जिसे बाहरी डेटा स्टोर करने की जगहों को वेंडर मोड में रखना चाहिए. भले ही, डेटा स्टोर करने की जगह को इसमें फ़ेच करना हो या बिल्डिंग के दौरान इस्तेमाल करना हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाओं को कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, 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 की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से हो और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा हो.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनसे लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर पड़ता है:

--experimental_command_profile=<cpu, wall, alloc or lock> डिफ़ॉल्ट: ब्यौरा देखें

यह कमांड की अवधि के दौरान, Java फ़्लाइट रिकॉर्डर प्रोफ़ाइल को रिकॉर्ड करता है. आर्ग्युमेंट के तौर पर, प्रोफ़ाइलिंग इवेंट का कोई एक टाइप (सीपीयू, वॉल, ऐलोक या लॉक) दिया जाना चाहिए. प्रोफ़ाइल को, आउटपुट बेस डायरेक्ट्री में मौजूद इवेंट टाइप के नाम वाली फ़ाइल में लिखा जाता है. आने वाले समय में, अन्य प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, इस फ़्लैग के सिंटैक्स और सेमेटिक्स में बदलाव हो सकता है. इसका इस्तेमाल अपने जोखिम पर करें.

--[no]experimental_record_metrics_for_all_mnemonics डिफ़ॉल्ट: "गलत"

डिफ़ॉल्ट रूप से, याददाश्त बढ़ाने वाली 20 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, सभी मेनेमोनिक के लिए आंकड़े लिखे जाएंगे.

--[no]print_relative_test_log_paths डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट लॉग के पाथ को प्रिंट करते समय, रिलेटिव पाथ का इस्तेमाल करें. यह पाथ, 'testlogs' सुविधा वाले सिंबललिंक का इस्तेमाल करता है. ध्यान दें - किसी दूसरे कॉन्फ़िगरेशन के साथ 'बिल्ड'/'टेस्ट'/वगैरह को फिर से शुरू करने पर, इस सिंबललिंक का टारगेट बदल सकता है. इससे, पहले प्रिंट किया गया पाथ अब काम का नहीं रह जाता.
टैग: affects_outputs

--[no]test_verbose_timeout_warnings डिफ़ॉल्ट: "गलत"

अगर सही है, तो अतिरिक्त चेतावनियां प्रिंट करें. ऐसा तब करें, जब जांच के लागू होने का असल समय, टेस्ट के लिए तय किए गए टाइम आउट से मेल न खाता हो. भले ही, यह साफ़ तौर पर बताया गया हो या साफ़ तौर पर बताया गया हो.
टैग: affects_outputs

--[no]verbose_test_summary डिफ़ॉल्ट: "सही"

अगर यह सही है, तो टेस्ट की खास जानकारी में ज़्यादा जानकारी (समय, बिना किसी नतीजे के पूरे हुए रन की संख्या वगैरह) प्रिंट करें.
टैग: affects_outputs

बेज़ल कमांड के लिए, जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

वेंडर के विकल्प

test से सभी विकल्प इनहेरिट करता है.

ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट के ज़रिए पार्स किए जाते हैं:

--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

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

इस विकल्प से, 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/batzbuild/ba इमारतों/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

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

--repo=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सिर्फ़ वेंडर के लिए तय की गई रिपॉज़िटरी, जो `@apparent_repo_name` या `@@canonical_repo_name` हो सकती है. इस विकल्प को कई बार सेट किया जा सकता है
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के पाथ के तौर पर बताया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--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

--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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, 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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि मामूली जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर यह सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Bazel को पता चलता है कि उसके पास मौजूद हेप का इस्तेमाल कम से कम इस थ्रेशोल्ड तक किया गया है, तो वह Skyframe की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (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> डिफ़ॉल्ट: "ऑटो"

रिपॉज़िटरी फ़ेच करने के लिए, थ्रेडिंग मोड का इस्तेमाल किया जाता है. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. ऐसा न होने पर, वर्चुअल वर्कर्स थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी कैटगरी में नहीं रखा गया है:

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह शिकायत कर सकता है. ऐसा तब होता है, जब वह लेबल अब भी किसी अन्य package_path एंट्री से दिया जाता है. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगा.

--override_repository=<an equals-separated mapping of repository name to path> एक से ज़्यादा बार इस्तेमाल किए जाने पर

<repository name>=<path> के फ़ॉर्मैट में, किसी लोकल पाथ की मदद से किसी रिपॉज़िटरी को बदलें. अगर दिया गया पाथ ऐब्सोल्यूट पाथ है, तो उसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो इसका इस्तेमाल मौजूदा वर्किंग डायरेक्ट्री के हिसाब से किया जाएगा. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह वर्कस्पेस रूट के हिसाब से होता है. यह `bazel info workspace` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

बिल्ड को कंट्रोल करने वाले विकल्प:

--[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

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. जिस टारगेट को पूरा नहीं किया जा सका और उस पर निर्भर अन्य टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.
टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> डिफ़ॉल्ट: "auto"

लोड करने/विश्लेषण करने के चरण के लिए, इस्तेमाल की जाने वाली पैरलल थ्रेड की संख्या. यह कोई पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") लेता है. इसके बाद, वैकल्पिक रूप से कोई ऑपरेशन ([-|*]<float>) हो सकता है. उदाहरण के लिए, "auto", "HOST_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर एक सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए
टैग: bazel_internal_configuration

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐक्शन के मेनिमोनिक के आधार पर, ऐक्शन के लागू होने की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो प्रोग्राम के चलने की जानकारी दिखाती हैं. कई सामान्य कार्रवाइयां, प्रोग्राम के चलने की जानकारी दिखाती हैं. जैसे, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम का ध्यान रखना ज़रूरी है, क्योंकि एक ही मेनिमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "regex=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के लिए, 'x' और 'z' को जोड़ता है और 'y' को हटा देता है. 'Genroll=+requires-x', सभी जेनरल कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में 'ज़रूरी-x' जोड़ता है. '(?!Genनया).*=-requires-x', सभी गैर-सामान्य कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से 'ज़रूरी-x' को हटा देता है.
टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

कर्मचारियों का इस्तेमाल करके, Android dex और डीशुगर कार्रवाइयों को लगातार चालू करें.
इसे बड़ा किया जाता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

वर्कर का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को लगातार चालू रखने की सुविधा चालू करें.
इस तरह बड़ा होता है:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --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 टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी एक फ़ैट 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> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"

Apple औरobjc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: जानकारी देखें

टारगेट को कंपाइल करने के लिए, C++ कंपाइलर का इस्तेमाल करें.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_merger"

बाइनरी की जगह, जिसका इस्तेमाल कवरेज की रॉ रिपोर्ट को पोस्ट-प्रोसेस करने के लिए किया जाता है. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, '//tools/test:lcov_merger' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक फ़ाइल ग्रुप होना चाहिए, जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से, यह '//tools/test:coverage_report_generator' पर सेट होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_support"

कोड कवरेज इकट्ठा करने वाली हर टेस्ट ऐक्शन के इनपुट पर ज़रूरी सहायता फ़ाइलों की जगह. डिफ़ॉल्ट रूप से, '//tools/test:coverage_support' होता है.
टैग: changes_inputs, affects_outputs, loading_and_analysis

--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 के हर ऐक्शन के लिए "ज़रूरी-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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टूलचेन रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों को ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन पर विचार किया जाएगा, ताकि उन टूलचेन को आपके लिए
affects_outputschanges_inputsloading_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> डिफ़ॉल्ट: जानकारी देखें

डिफ़ॉल्ट रूप से, 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 के नियमों (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 डिफ़ॉल्ट: "सही"

अगर यह सही है, तो 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 इंटरप्रेटर को दिखाता है. बहिष्कृत; --insupported_use_python_toolchains की मदद से बंद किया गया है.
टैग: loading_and_analysis, affects_outputs

--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

यह tvOS SDK के वर्शन के बारे में बताता है, ताकि tvOS ऐप्लिकेशन बनाने के लिए इसका इस्तेमाल किया जा सके. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से डिफ़ॉल्ट tvOS SDK टूल के वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

यह WatchOS SDK के वर्शन के बारे में बताता है, ताकि WatchOS ऐप्लिकेशन बनाने में इस्तेमाल किया जा सके. अगर कोई वैल्यू नहीं दी गई है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: जानकारी देखें

अगर यह एट्रिब्यूट तय किया गया है, तो काम की बिल्ड ऐक्शन के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी गई है, तो Xcode के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"

xcode_config नियम का लेबल, जिसका इस्तेमाल बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए किया जाता है.
टैग: loses_incremental_state, loading_and_analysis

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत"

डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करनी हैं या नहीं.
टैग: affects_outputs, action_command_lines

--[no]build_runfile_links डिफ़ॉल्ट: "सही"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल को फ़ॉरेस्ट को सिमलिंक करें. अगर यह फ़ील्ड 'गलत' पर सेट है, तो इसे सिर्फ़ तब लिखें, जब किसी स्थानीय कार्रवाई, जांच या चलाने के कमांड की ज़रूरत हो.
टैग: affects_outputs

--[no]build_runfile_manifests डिफ़ॉल्ट: "सही"

अगर यह सही है, तो सभी टारगेट के लिए, रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह 'गलत है' पर सेट है, तो उन्हें शामिल न करें. गलत होने पर, लोकल टेस्ट नहीं चल पाएंगे.
टैग: affects_outputs

--[no]build_test_dwp डिफ़ॉल्ट: "गलत"

यह सुविधा चालू होने पर, C++ टेस्ट बनाते समय, टेस्ट बाइनरी के लिए .dwp फ़ाइल अपने-आप बन जाएगी. ऐसा, स्टैटिक तरीके से और फ़िज़न के साथ किया जाता है.
टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.h"

cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> डिफ़ॉल्ट: ".pb.cc"

cc_proto_library से बनने वाली सोर्स फ़ाइलों के सफ़िक्स सेट करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "गलत"

proto_library में, अन्य Java API वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_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 डिफ़ॉल्ट: "सही"

अगर सही है, तो .runfile/wsname/external/repo (.runfiles/repo के अलावा) के अलावा, बाहरी डेटा स्टोर करने की जगहों के लिए रनफ़ाइल सिमलिंक करें.
टैग: affects_outputs

--[no]objc_generate_linkmap डिफ़ॉल्ट: "गलत"

बताता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग: affects_outputs

--[no]save_temps डिफ़ॉल्ट: "गलत"

अगर यह सेट है, तो gcc से मिलने वाले अस्थायी आउटपुट सेव हो जाएंगे. इनमें .s फ़ाइलें (असेम्बलर कोड), .i फ़ाइलें (प्रीप्रोसेस की गई C) और .ii फ़ाइलें (प्रीप्रोसेस की गई C++) शामिल हैं.
टैग: affects_outputs

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--action_env=<a 'name=value' assignment with an optional value part> बार इस्तेमाल किए गए

टारगेट कॉन्फ़िगरेशन वाले ऐक्शन के लिए उपलब्ध, एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को नाम से तय किया जा सकता है. इस मामले में, वैल्यू को कॉल करने के एनवायरमेंट से लिया जाएगा. इसके अलावा, वैरिएबल को name=value पेयर से भी तय किया जा सकता है. यह पेयर, कॉल करने के एनवायरमेंट से अलग वैल्यू सेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्प इकट्ठा किए जाते हैं.
टैग: action_command_lines

--android_cpu=<a string> डिफ़ॉल्ट: "armeabi-v7a"

Android टारगेट सीपीयू.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]android_databinding_use_androidx डिफ़ॉल्ट: "सही"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटाबाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग का कोई असर नहीं पड़ता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args डिफ़ॉल्ट: "सही"

3.4.0 आर्ग्युमेंट के साथ Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं पड़ता.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "बंद"

इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी साफ़ तौर पर शेयर नहीं करता है, तो Android के नियमों के C++ डिप को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी' का मतलब है कि सभी लाइब्रेरी डायनैमिक रूप से लिंक कर दी जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> डिफ़ॉल्ट: "alphabetical"

Android बाइनरी के लिए, मेनिफ़ेस्ट मर्ज करने वाले टूल को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अंग्रेज़ी वर्णमाला के क्रम में का मतलब है कि मेनिफ़ेस्ट, execroot के हिसाब से पाथ के हिसाब से क्रम में लगाए जाते हैं. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में मौजूद कॉन्फ़िगरेशन डायरेक्ट्री के पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]build_python_zip डिफ़ॉल्ट: "auto"

python की एक्ज़ीक्यूटेबल ZIP फ़ाइल बनाएं; Windows पर, अन्य प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs

--catalyst_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐसे आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है. इन आर्किटेक्चर के लिए, Apple Catalyst बाइनरी बनाई जानी हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "गलत"

अगर तय किया गया है, तो Bazel कोड को इंस्ट्रूमेंट करेगा. इसके लिए, जहां भी हो सके वहां ऑफ़लाइन इंस्ट्रूमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा की जाएगी. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मैच करते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'bazel coverage' कमांड का इस्तेमाल किया जाना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "fastbuild"

वह मोड बताएं जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--conlyopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

gcc को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ नाम बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंट की बाइनरी जनरेट करना. Clang/LLVM कंपाइलर के साथ, वह डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: जानकारी देखें

ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली कॉन्टेक्स्ट सेंसिटिव प्रोफ़ाइल को दिखाने वाली cs_fdo_profile.
टैग: affects_outputs

--cxxopt=<a string> बार इस्तेमाल किए गए

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> एक से ज़्यादा बार इस्तेमाल किए जाने पर

--इसके लिए तय किया गया हर विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "default"

यह तय करता है कि C++ बाइनरी को डाइनैमिक तौर पर लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी' का मतलब है कि सभी लाइब्रेरी डायनैमिक रूप से लिंक कर दी जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक होंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह नीति सेट की जाती है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी दिखेगी.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "auto"

रनफ़ाइल्स के सिमलिंक ट्री को चालू करें; डिफ़ॉल्ट रूप से, यह Windows और अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

पक्षों के पहलुओं को प्राथमिकता दी जाती है. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में जावा संसाधनों को कंप्रेस करना
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 डिफ़ॉल्ट: "सही"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का इस्तेमाल नहीं किया जा सकता है.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत"

dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत"

अगर साफ़ तौर पर बताया गया है, तो Basel, जनरेट की गई फ़ाइलों के कवरेज की जानकारी भी जनरेट करेगा.
टैग: 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_output_dir से रजिस्टर किया गया था, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म लेबल के आधार पर किसी छोटे नाम का इस्तेमाल करें. आखिर में, प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल आखिरी विकल्प के तौर पर किया जाता है.
टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "गलत"

अगर सूचना दी जाए, तो Collect_code_coverage चालू होने पर Basel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic डिफ़ॉल्ट: "सही"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ सुझाई गई माइग्रेशन या टेस्टिंग की रणनीति के हिस्से के तौर पर करें. ध्यान दें कि हेयुरिस्टिक्स में कुछ कमियां हैं. हमारा सुझाव है कि सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करके माइग्रेट करें.
टैग: affects_outputs, experimental

--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> बार इस्तेमाल किए गए

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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

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_ऐप्लिकेशन का इस्तेमाल करके, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें सभी खास आर्किटेक्चर शामिल हैं.
टैग: 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, //foo/ में बार.cc को छोड़कर, सभी cc कमांड लाइन में -O0 कमांड लाइन का विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> बार इस्तेमाल किए गए

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड (--features=thin_lto में) को चुनिंदा तौर पर पास करने के लिए अन्य विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter, शामिल और बाहर रखे जाने वाले रेगुलर एक्सप्रेशन पैटर्न की सूची के लिए है. option_1 से option_n, कमांड लाइन के मनमुताबिक विकल्पों के लिए हैं. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, bar.o को छोड़कर //foo/ में मौजूद सभी o फ़ाइलों की LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: जानकारी देखें

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. इस फ़्लैग में बिल्ड लेबल डाला जा सकता है, जिसमें प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा लेबल होना चाहिए. उदाहरण के लिए, a/b/BUILD:prop इंतज़ार_Optimize( name = "prop Tager_profile", cc_profile = "prof") = "prop कौशल_ld_profile.txt", ld_profile = "prop इसे_ld_profile.txt" में लेबल को लेबल करने के बारे में बताना चाहिए. इसके लिए, इन फ़ाइलों को संबंधित पैकेज में एक्सपोर्ट करना ज़रूरी होगा, ताकि ये फ़ाइलें बेज़ेल में दिखें. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

स्विफ़्ट के कंपाइलेशन का इस्तेमाल करने के दूसरे विकल्प.
टैग: action_command_lines

--tvos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple tvOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के साथ काम करने वाला tvOS वर्शन. अगर कोई वैल्यू नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐप्लिकेशन के लिए, Apple visionOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> एक से ज़्यादा बार इस्तेमाल किए जाने पर

ऐप्लिकेशन के लिए, Apple watchOS बाइनरी बनाने के लिए आर्किटेक्चर की कॉमा लगाकर बनाई गई सूची.
टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम वर्शन. अगर जानकारी नहीं है, तो 'watchos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: जानकारी देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ किया जाता है, तो वे विकल्प हमेशा लागू रहेंगे, जैसे कि xbinary_fdo कभी तय नहीं किया गया हो.
टैग: affects_outputs

ऐसे विकल्प जो इस बात पर असर डालते हैं कि Basel ने मान्य बिल्ड इनपुट को कितना सख्ती से लागू किया है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):

--auto_cpu_environment_group=<a build target label> डिफ़ॉल्ट: ""

Environment_group का एलान करें, ताकि सीपीयू वैल्यू को target_environment वैल्यू पर अपने-आप मैप करने के लिए इस्तेमाल किया जा सके.
टैग: 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 डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel, टॉप लेवल डायरेक्ट्री हेडर को शामिल किए जाने की पुष्टि भी करेगा. ज़्यादा जानकारी के लिए, https://github.com/baडेलbuild/baZ/issues/10047 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]one_version_enforcement_on_java_tests डिफ़ॉल्ट: "सही"

यह सुविधा चालू होने पर और formula_one_version_enforcement को गैर-NONE वैल्यू पर सेट करके, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद करके, इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. हालांकि, ऐसा करने पर किसी एक वर्शन के उल्लंघन का पता नहीं चलेगा.
टैग: loading_and_analysis

--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: जानकारी देखें

--incompatible_python_disallow_native_rules लागू करते समय इस्तेमाल करने के लिए, एक अनुमति वाली सूची (package_group टारगेट).
टैग: loading_and_analysis

--[no]strict_filesets डिफ़ॉल्ट: "गलत"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइल सेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.
टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच की जाती है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर डिपेंडेंसी के तौर पर बताता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> डिफ़ॉल्ट: "बंद"

जब तक यह विकल्प बंद नहीं होता, तब तक यह जांच की जाती है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को साफ़ तौर पर एक्सपोर्ट के तौर पर दिखाता है या नहीं.
टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--[no]strict_system_includes डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो सिस्टम में शामिल पाथ (-isystem) से मिले हेडर की जानकारी भी देनी होगी.
टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताता है. यह "एनवायरमेंट" नियम का लेबल रेफ़रंस होना चाहिए. अगर एनवायरमेंट तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.
टैग: changes_inputs

ऐसे विकल्प जिनसे किसी बिल्ड के हस्ताक्षर करने के आउटपुट पर असर पड़ता है:

--apk_signing_method=<v1, v2, v1_v2 or v4> डिफ़ॉल्ट: "v1_v2"

APKs पर साइन करने के लिए इस्तेमाल करने का तरीका
टैग: action_command_lines, affects_outputs, loading_and_analysis

--[no]device_debug_entitlements डिफ़ॉल्ट: "सही"

अगर यह सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.
टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: जानकारी देखें

iOS साइनिंग के लिए सर्टिफ़िकेट का नाम. अगर यह सेट नहीं है, तो डिवाइस पर प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक, यह सर्टिफ़िकेट की पासकोड की पहचान की प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम का (सबस्ट्रिंग) हो सकता है.
टैग: action_command_lines

इस विकल्प का असर, Starlark भाषा के सेमेटिक्स या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए ऐक्सेस किए जा सकने वाले बिल्ड एपीआई पर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह कोई काम नहीं करता. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट नहीं है, तो उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग 'सही' पर सेट है, तो config_setting, दिखने के उसी लॉजिक का पालन करती है जो अन्य सभी नियमों के लिए लागू होता है. https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disallow_legacy_py_provider डिफ़ॉल्ट: "सही"

काम नहीं करता. इसे जल्द ही हटा दिया जाएगा.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "गलत"

अगर इसकी वैल्यू 'सही' है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट इस्तेमाल करने की अनुमति नहीं दें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर 'सही है' पर सेट है, तो config_setting की सेटिंग दिखने से जुड़ी पाबंदियां लागू करें. अगर यह 'गलत' है, तो हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_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/batzbuild/ba बहुत/issues/17773 देखें.
टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "गलत"

अगर सही है, तो टारगेट टारगेट के लिए विश्लेषण में गड़बड़ी होने पर, टारगेट में विश्लेषणFailureInfo का वह इंस्टेंस दिखता है जिसमें गड़बड़ी की जानकारी होती है. इससे ऐप्लिकेशन बनाने में गड़बड़ी होती है.
टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट के ज़रिए, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा डेटा डालने पर, नियम से जुड़ी गड़बड़ी का मैसेज दिखेगा.
टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो टेस्ट के रनटाइम के दौरान dex2oat को लागू करने के बजाय, dex2oat ऐक्शन के पूरा न होने की वजह से बिल्ड रुक जाएगा.
टैग: loading_and_analysis, experimental

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g. memory=10,30,60,100> एक से ज़्यादा बार इस्तेमाल किए जाने पर

जांच के लिए, संसाधनों की डिफ़ॉल्ट संख्या को बदलें. सही फ़ॉर्मैट <resource>=<value> है. अगर <value> के तौर पर कोई एक पॉज़िटिव संख्या दी जाती है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट रिसॉर्स को बदल देगी. अगर कॉमा लगाकर चार संख्याएं दी गई हैं, तो वे छोटे, मीडियम, बड़े, और बहुत बड़े टेस्ट साइज़ के लिए, संसाधन की संख्या को बदल देंगी. वैल्यू Host_RAM/Host_CPU भी हो सकती हैं. इसके बाद, [-|*]<float> (उदाहरण के लिए, space=Host_RAM*.1,Host_RAM*.2,Host_RAM*.3,Host_RAM*.4) भी हो सकता है. इस फ़्लैग से तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को, टैग में बताए गए साफ़ तौर पर दिए गए संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "गलत"

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.
टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "गलत"

ios_test टारगेट में, मेमोरी लीक की जांच करने की सुविधा चालू करें.
टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, जिस डिवाइस को सिम्युलेट करना है, जैसे कि 'iPhone 6'. डिवाइसों की सूची पाने के लिए, उस मशीन पर 'xcrun simctl list devicetypes' चलाएं जिस पर सिम्युलेटर चलाया जाएगा.
टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: जानकारी देखें

ऐप्लिकेशन को चलाने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला iOS वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> बार इस्तेमाल किए गए

यह हर टेस्ट को कितनी बार चलाने के लिए तय करता है. अगर इनमें से किसी भी कोशिश में किसी वजह से सफलता नहीं मिलती है, तो पूरे टेस्ट को असफल माना जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. जहां Run_per_test का मतलब पूर्णांक वैल्यू है और regex_filter, रेगुलर एक्सप्रेशन पैटर्न की सूची को दिखाता है और इसमें शामिल नहीं है (इसे भी देखें --instrumentation_filter). उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट को तीन बार चलाता है. हालांकि, foo/bar में मौजूद टेस्ट को नहीं चलाता. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name=value' assignment with an optional value part> एक से ज़्यादा बार इस्तेमाल किए जाने पर

टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल तय करता है. वैरिएबल को या तो नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू को बेज़ल क्लाइंट एनवायरमेंट से या name=value पेयर के ज़रिए पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'bazel 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

Bzlmod के आउटपुट और सेमेटिक्स से जुड़े विकल्प:

--repo=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

सिर्फ़ वेंडर के लिए तय की गई रिपॉज़िटरी, जो `@apparent_repo_name` या `@@canonical_repo_name` हो सकती है. इस विकल्प को कई बार सेट किया जा सकता है
टैग: changes_inputs

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--[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> बार इस्तेमाल किए गए

स्टारलार्क फ़्लैग के लिए शॉर्टहैंड नाम सेट करता है. यह एक आर्ग्युमेंट के तौर पर, "<key>=<value>" फ़ॉर्मैट में एक की-वैल्यू पेयर लेता है.
टैग: changes_inputs

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "गलत"

यह फ़्लैग, डिफ़ॉल्ट तरीके को बदल देता है, ताकि Python टारगेट के रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बनें. खास तौर पर, जब py_binary या py_test टारगेट में legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तो इसे सिर्फ़ तब गलत माना जाता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर यह विकल्प 'सही है' पर सेट है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे. इस रूट में '-py2' सफ़िक्स शामिल होगा. वहीं, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं होगा. इसका मतलब है कि `bazel-bin` सुविधा वाला सिंबललिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. अगर इस विकल्प को चालू किया जाता है, तो हमारा सुझाव है कि आप `--insupported_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर यह सही है, तो `py_binary` और `py_test` टारगेट के लिए, `python_version` (या `default_python_version`) एट्रिब्यूट की वैल्यू सेट नहीं की जाएगी. ऐसे में, इन टारगेट के लिए डिफ़ॉल्ट रूप से PY3 का इस्तेमाल किया जाएगा, न कि PY2 का. अगर यह फ़्लैग सेट किया जाता है, तो हमारा सुझाव है कि आप `--incompatible_py2_outputs_are_suffixed` को भी सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो Python के नेटिव नियमों को लागू करने के लिए, --python_top जैसे लेगसी फ़्लैग के बजाय, Python टूलचेन में बताए गए Python रनटाइम का इस्तेमाल किया जाएगा.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: जानकारी देखें

Python के मुख्य वर्शन का मोड, या तो `PY2` या `PY3`. ध्यान दें कि इसे `py_binary` और `py_test` टारगेट बदल देते हैं. भले ही, वे साफ़ तौर पर किसी वर्शन की जानकारी न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

अलग-अलग तरह के विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "auto"

अगर इसे 'अपने-आप' पर सेट किया जाता है, तो Bazel किसी टेस्ट को फिर से सिर्फ़ तब चलाता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया हो, (3) --runs_per_test के साथ कई टेस्ट चलाने का अनुरोध किया गया हो या(4) टेस्ट पहले फ़ेल हो गया हो. 'हां' पर सेट होने पर, Bazel बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर, सभी टेस्ट के नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजों को कैश मेमोरी में सेव नहीं करता.

--deleted_packages=<comma-separated list of package names> एक से ज़्यादा बार इस्तेमाल किए जाने पर

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं मानेगा. भले ही, वे पैकेज के पाथ पर कहीं दिखते हों. किसी मौजूदा पैकेज 'x' के सब-पैकेज 'x/y' को मिटाते समय, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह शिकायत कर सकता है. ऐसा तब होता है, जब वह लेबल अब भी किसी अन्य package_path एंट्री से दिया जाता है. --deleted_packages x/y का इस्तेमाल करने से, यह समस्या नहीं होती.

--[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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो क्लैंग के लिए कवरेज एक एलसीओवी रिपोर्ट जनरेट करेगी.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_j2objc_header_map डिफ़ॉल्ट: "सही"

J2ObjC ट्रांसपाइलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है या नहीं.

--[no]experimental_j2objc_shorter_header_path डिफ़ॉल्ट: "गलत"

छोटे हेडर पाथ से जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करना).
टैग: affects_outputs

--experimental_java_classpath=<off, javabuilder or bazel> डिफ़ॉल्ट: "javabuilder"

Java कंपाइलेशन के लिए, कम क्लासपाथ की सुविधा चालू करता है.

--[no]experimental_limit_android_lint_to_android_constrained_java डिफ़ॉल्ट: "गलत"

--experimental_run_android_lint_on_java_rules को Android के साथ काम करने वाली लाइब्रेरी तक सीमित करें.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

TestRunner के डिपेंडेंसी से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी को साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ bazel के लिए काम करता है.

--[no]fetch डिफ़ॉल्ट: "सही"

इससे, कमांड को बाहरी डिपेंडेंसी फ़ेच करने की अनुमति मिलती है. अगर इस नीति को 'बंद है' पर सेट किया जाता है, तो निर्देश डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगा. अगर कोई वर्शन मौजूद नहीं है, तो निर्देश काम नहीं करेगा.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल के लिए इस्तेमाल किया जाने वाला Java लॉन्चर.

--host_javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान इस्तेमाल होने वाले टूल बनाते समय, javac को पास करने के लिए अन्य विकल्प.

--host_jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java वीएम को पास करने के कुछ और विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--[no]incompatible_check_sharding_support डिफ़ॉल्ट: "सही"

अगर यह सही है, तो अगर टेस्ट रनर यह नहीं दिखाता है कि वह TEST_SHARD_STATUS_FILE में पाथ पर मौजूद फ़ाइल को छूकर, शर्डिंग के साथ काम करता है, तो Bazel, शर्ड किए गए टेस्ट को फ़ेल कर देगा. अगर यह वैल्यू 'गलत' है, तो ऐसे टेस्ट रनर के लिए हर शर्ड में सभी टेस्ट चलेंगे जो शर्डिंग की सुविधा के साथ काम नहीं करते.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर यह 'सही' है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि ऐसा करने पर, शेयर किए गए कैश मेमोरी का इस्तेमाल होने पर, अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी सेव नहीं की जा सकती.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> बार इस्तेमाल किए गए

J2ObjC टूल को पास करने के लिए अन्य विकल्प.

--java_debug

इसकी वजह से, किसी Java टेस्ट की Java वर्चुअल मशीन, टेस्ट शुरू करने से पहले JDWP के साथ काम करने वाले डीबगर (जैसे, jdb) से कनेक्शन का इंतज़ार करती है. इसका मतलब है कि -test_output=streamed.
इस तरह बड़ा होता है:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps डिफ़ॉल्ट: "सही"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (फ़िलहाल, कंपाइल के समय क्लासपाथ) जनरेट करें.

--[no]java_header_compilation डिफ़ॉल्ट: "सही"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: जानकारी देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

Java VM को पास करने के लिए अन्य विकल्प. ये विकल्प, हर java_binary टारगेट के VM स्टार्टअप विकल्पों में जुड़ जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: जानकारी देखें

यह उन क्लास की सूची जनरेट करने के लिए एक बाइनरी के बारे में बताता है जिन्हें लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होना चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: जानकारी देखें

शर्ड किए बिना डेक्स करने के लिए इस्तेमाल की जाने वाली बाइनरी के बारे में बताता है.

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज कहां खोजने हैं, इसकी सूची. इसमें कोलन लगाकर अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, उस वर्कस्पेस से जुड़े होते हैं जिसमें वे मौजूद होते हैं. अगर यह पैरामीटर नहीं दिया गया है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट दिखेगा.

--plugin=<a build target label> एक से ज़्यादा बार इस्तेमाल किए जाने पर

बिल्ड में इस्तेमाल करने के लिए प्लग इन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना है, यह बताता है.

--proto_compiler=<a build target label> डिफ़ॉल्ट: "@ba"_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> डिफ़ॉल्ट: "@bagel_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> एक से ज़्यादा बार इस्तेमाल किए जाने पर

प्रोटोबफ़ कंपाइलर को पास करने के लिए अन्य विकल्प.
टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "गलत"

अगर यह सही है, तो जिस शर्ड में कम से कम एक रन/अटैंप पास होता है और कम से कम एक रन/अटैंप फ़ेल होता है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: जानकारी देखें

Bazel के इस्तेमाल के लिए, शेल की एक्ज़ीक्यूटेबल फ़ाइल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन Bazel को पहली बार इस्तेमाल करने पर BAZEL_SH एनवायरमेंट वैरिएबल सेट है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ, उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर Bazel काम करता है. जैसे, Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash. ध्यान दें कि किसी ऐसे शेल का इस्तेमाल करने पर जो बैश के साथ काम नहीं करता है, हो सकता है कि जनरेट की गई बाइनरी बिल्ड न हो या रनटाइम फ़ेल हो जाए.
टैग: loading_and_analysis

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

--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 डिफ़ॉल्ट: "गलत"

अगर यह 'गलत है' पर सेट है, तो 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_exact} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं होगी. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है; ctx.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

बिल्ड को कंट्रोल करने वाले विकल्प:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrtingDetector, मेमोरी दबाव के इवेंट को इसकी सीमाओं के हिसाब से नहीं मानता (--gc_t इससेrapshin_limits). अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, अपने हिसाब से आउटपुट कॉन्फ़िगर कर सकता है. इन विकल्पों से आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--[no]gnu_format डिफ़ॉल्ट: "गलत"

अगर सेट है, तो GNU स्टैंडर्ड में बताए गए नियमों का इस्तेमाल करके, वर्शन को स्टैंडआउट में लिखें.
टैग: affects_outputs, execution

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 मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. सही वैल्यू के तौर पर, `error` का इस्तेमाल करके गड़बड़ी को 'समस्या हल नहीं हो सकी' के तौर पर दिखाया जा सकता है. इसके अलावा, जांच बंद करने के लिए `off` और मैच न होने का पता चलने पर चेतावनी दिखाने के लिए `warning` का इस्तेमाल किया जा सकता है.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो आपको डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच बंद करने के लिए, `बंद करें`. मैच न होने का पता चलने पर चेतावनी देने के लिए, `चेतावनी`. गड़बड़ी को हल न कर पाने की स्थिति में सूचना देने के लिए, `गड़बड़ी`.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.bagel में `dev_dependency` के तौर पर एलान किए गए `bagel_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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ाइल फ़ोल्डर` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले किए गए सभी बदलावों को हटा दें.

--registry=<a string> एक से ज़्यादा बार इस्तेमाल किए जाने पर

यह उन रजिस्ट्री के बारे में बताता है जिनका इस्तेमाल, Bazel मॉड्यूल की डिपेंडेंसी ढूंढने के लिए किया जाता है. क्रम का ध्यान रखना ज़रूरी है: मॉड्यूल पहले पुरानी रजिस्ट्री में खोजे जाएंगे. अगर वे वहां मौजूद नहीं हैं, तो ही नई रजिस्ट्री में खोजे जाएंगे.
टैग: changes_inputs

--vendor_dir=<a path> डिफ़ॉल्ट: जानकारी देखें

इससे उस डायरेक्ट्री के बारे में पता चलता है जिसमें बाहरी रिपॉज़िटरी को वेंडर मोड में रखना चाहिए. भले ही, उन्हें इसमें फ़ेच करने या बिल्ड करते समय इस्तेमाल करने के लिए ऐसा किया जा रहा हो. पाथ को ऐब्सलूट पाथ या वर्कस्पेस डायरेक्ट्री के हिसाब से रिलेटिव पाथ के तौर पर सेट किया जा सकता है.
टैग: loading_and_analysis

बिल्ड के समय को ऑप्टिमाइज़ करने वाले विकल्प:

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> डिफ़ॉल्ट: "1s:2,20s:3,1m:5"

सीमाएं, जिन तक पहुंचने पर GcThrashingDetector, OOM की वजह से Bazel को क्रैश कर देता है. हर सीमा को <period>:<count> के तौर पर दिखाया जाता है. इसमें period, समयावधि होती है और count, पॉज़िटिव इंटिजर होता है. अगर <period> में लगातार <count> बार जीसी होने के बाद भी, टेंचर (ओल्ड जनरेशन हीप) में --gc_thrashing_threshold प्रतिशत से ज़्यादा जगह खाली नहीं रहती है, तो ओओएम ट्रिगर हो जाता है. एक से ज़्यादा सीमाएं तय की जा सकती हैं. इन्हें कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--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 पर सेट होता है. इसका मतलब है कि यह अनलिमिटेड है. शून्य का मतलब है कि पूरे जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. सीमा पूरी होने पर, पूरी जीसी इवेंट होने और रीटेन की गई हेप के प्रतिशत के थ्रेशोल्ड से ज़्यादा होने पर, 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 की अस्थायी स्थिति को हटा देगा. इस सेटिंग में बदलाव करके, जीसी थ्रैशिंग के असर को कम किया जा सकता है. ऐसा तब किया जा सकता है, जब जीसी थ्रैशिंग (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` का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से लागू किए गए सभी बदलाव हटाएं.

विकल्प के असर वाले टैग

unknown	इस विकल्प का असर अज्ञात है या इसके बारे में कोई जानकारी नहीं दी गई है.
no_op	इस विकल्प से कोई असर नहीं पड़ता.
loses_incremental_state	इस विकल्प की वैल्यू बदलने से, इंक्रीमेंटल (बढ़ने वाली) स्थिति में काफ़ी कमी आ सकती है, जिससे बिल्ड धीमे हो सकता है. सर्वर के रीस्टार्ट होने या डिपेंडेंसी ग्राफ़ के बड़े हिस्से के अमान्य होने की वजह से, स्टेटस दिख सकता है.
changes_inputs	यह विकल्प, उन इनपुट में बदलाव करता है जिन्हें bazel, बिल्ड के लिए इस्तेमाल करता है. जैसे, फ़ाइल सिस्टम की पाबंदियां, रिपॉज़िटरी के वर्शन या अन्य विकल्प.
affects_outputs	इस विकल्प से, बैजल के आउटपुट पर असर पड़ता है. इस टैग को जान-बूझकर बड़ा किया गया है, इसमें ट्रांज़िटिव असर शामिल हो सकते हैं. साथ ही, इससे किस तरह के आउटपुट पर असर पड़ता है, इसकी जानकारी नहीं दी गई है.
build_file_semantics	इस विकल्प से BUILD या .bzl फ़ाइलों के सिमेंटिक्स पर असर पड़ता है.
bazel_internal_configuration	इस विकल्प से, bazel की इंटरनल मशीनरी की सेटिंग पर असर पड़ता है. इस टैग का मतलब यह नहीं है कि बिल्ड आर्टफ़ैक्ट पर असर पड़ा है.
loading_and_analysis	इस विकल्प से डिपेंडेंसी लोड करने और उसका विश्लेषण करने में मदद मिलती है. साथ ही, डिपेंडेंसी ग्राफ़ बनाने पर भी असर पड़ता है.
execution	यह विकल्प, एक्ज़ीक्यूशन के चरण पर असर डालता है. जैसे, सैंडबॉक्सिंग या रिमोट तौर पर एक्ज़ीक्यूशन से जुड़े विकल्प.
host_machine_resource_optimizations	यह विकल्प ऐसा ऑप्टिमाइज़ेशन ट्रिगर करता है जो मशीन से जुड़ा हो सकता है. साथ ही, इस बात की कोई गारंटी नहीं है कि यह सभी मशीनों पर काम करेगा. ऑप्टिमाइज़ेशन में, परफ़ॉर्मेंस के दूसरे पहलुओं के साथ समझौता किया जा सकता है. जैसे, मेमोरी या सीपीयू की लागत.
eagerness_to_exit	इस विकल्प से, यह तय होता है कि किसी गड़बड़ी के दौरान bazel, प्रोसेस को कितनी जल्दी बंद करेगा. इसमें, गड़बड़ी के बावजूद प्रोसेस जारी रखने और उसे बंद करने का विकल्प होता है.
bazel_monitoring	इस विकल्प का इस्तेमाल, bazel के व्यवहार और परफ़ॉर्मेंस को मॉनिटर करने के लिए किया जाता है.
terminal_output	इस विकल्प से, bazel के टर्मिनल आउटपुट पर असर पड़ता है.
action_command_lines	यह विकल्प, एक या उससे ज़्यादा बिल्ड ऐक्शन के कमांड लाइन आर्ग्युमेंट बदलता है.
test_runner	यह विकल्प, बिल्ड के टेस्टरनर एनवायरमेंट को बदलता है.

विकल्प के मेटाडेटा टैग

experimental	यह विकल्प, एक्सपेरिमेंट के तौर पर उपलब्ध किसी सुविधा को ट्रिगर करता है. हालांकि, इस बात की कोई गारंटी नहीं है कि यह सुविधा काम करेगी.
incompatible_change	यह विकल्प, ब्रेकिंग बदलाव को ट्रिगर करता है. माइग्रेशन के लिए तैयार हैं या नहीं, यह जांचने या नई सुविधा का रिलीज़ होने से पहले ऐक्सेस पाने के लिए, इस विकल्प का इस्तेमाल करें
deprecated	यह विकल्प अब काम नहीं करता. ऐसा हो सकता है कि जिस सुविधा पर इसका असर पड़ता है उसे बंद कर दिया गया हो या जानकारी देने का कोई दूसरा तरीका इस्तेमाल किया जा रहा हो.