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

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	बेज़ल विकल्पों की सूची को कैननिकल बना देता है.
clean	आउटपुट फ़ाइलों को हटाता है और वैकल्पिक रूप से सर्वर को बंद करता है.
coverage	तय किए गए टेस्ट टारगेट के लिए, कोड कवरेज रिपोर्ट जनरेट करता है.
cquery	कॉन्फ़िगरेशन का इस्तेमाल करके, तय किए गए टारगेट को लोड करता है, उनका विश्लेषण करता है, और उनके बारे में क्वेरी करता है.
dump	बेज़ल सर्वर प्रोसेस की अंदरूनी स्थिति को डंप करता है.
fetch	ऐसे बाहरी डेटा स्टोर करने की जगह फ़ेच करता है जो टारगेट के लिए ज़रूरी हैं.
help	कमांड या इंडेक्स के लिए प्रिंट सहायता.
info	बेज़ल सर्वर के बारे में रनटाइम की जानकारी दिखाता है.
license	इस सॉफ़्टवेयर का लाइसेंस प्रिंट करता है.
mobile-install	मोबाइल डिवाइस पर टारगेट इंस्टॉल करता है.
mod	Bzlmod बाहरी डिपेंडेंसी ग्राफ़ की क्वेरी करता है
print_action	किसी फ़ाइल को कंपाइल करने के लिए, कमांड लाइन आर्ग प्रिंट करता है.
query	डिपेंडेंसी ग्राफ़ क्वेरी चलाता है.
run	तय टारगेट को रन करता है.
shutdown	बेज़ल सर्वर को रोकता है.
sync	वर्कस्पेस फ़ाइल में दिए गए सभी डेटा स्टोर करने की जगह को सिंक करता है
test	तय किए गए टेस्ट टारगेट बनाता और चलाता है.
vendor	बाहरी डेटा स्टोर करने की जगहों को फ़्लैग --vendor_ कौशल के ज़रिए बताए गए किसी खास फ़ोल्डर में फ़ेच करता है.
version	बेज़ल के लिए प्रिंट वर्शन की जानकारी.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$HOME/.ba सुझावों का इस्तेमाल करके, होम baazrc फ़ाइल देखी जाए या नहीं
टैग: changes_inputs

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

सर्वर के कुछ समय से इस्तेमाल में न होने पर, System.gc() चलाएं
टैग: loses_incremental_state, host_machine_resource_optimizations

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

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

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

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

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

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

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

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

पूरे सिस्टम पर अलग-अलग तरह के बैज देखें या नहीं.
टैग: changes_inputs

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

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

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

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

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

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

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

$workspace/.baezrc में वर्कस्पेस की फ़ाइल खोजें या नहीं
टैग: 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> डिफ़ॉल्ट: ""

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

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

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

सभी कमांड के लिए आम तौर पर उपलब्ध विकल्प

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

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

अगर सही है, तो proto lang के नियम,Terms_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' को सेट किया जाता है, तो यह'मिनिमल' की तरह काम करता है. हालांकि, यह लोकल मशीन पर टॉप लेवल टारगेट के आउटपुट डाउनलोड भी करता है. अगर नेटवर्क बैंडविड्थ के लिए कोई समस्या है, तो दोनों विकल्प बिल्ड समय को काफ़ी कम कर सकते हैं.
टैग: affects_outputs

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

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

--remote_download_toplevel

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

टैग: affects_outputs

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

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

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

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

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

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

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

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

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

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

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

अगर इसे 'सही है' पर सेट किया जाता है, तो ctx.action.run() और ctx.action.run_shell() पर सेट करके लोकल एक्ज़ीक्यूशन के लिएResource_set पैरामीटर रहेगा. ऐसा न करने पर, मेमोरी और 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 एपीआई के तरीके उपलब्ध होंगे
टैग: build_file_semantics, loading_and_analysis, experimental

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

अगर इसे 'सही है' पर सेट किया जाता है, तो अपने-आप जनरेट हुआ //बाहरी पैकेज उपलब्ध नहीं रहेगा. Basel अब भी 'external/BUILD' फ़ाइल को पार्स नहीं कर पाएगा. हालांकि, बिना नाम वाले पैकेज के बाहरी या बिना नाम वाले ग्लोब का इस्तेमाल किया जा सकेगा.
टैग: 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://ba इमारतों.build/rules/lib/globals/module#use_extension"><code>use_extension</code></a> फ़ंक्शन में, <code>आइसोलेट</code> पैरामीटर को चालू करता है.
टैग: loading_and_analysis

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

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

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

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

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

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

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

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

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

अगर टैग को 'सही है' पर सेट किया जाता है, तो टारगेट से ऐक्शन को लागू करने की ज़रूरी शर्तों पर टैग को लागू किया जाएगा. ऐसा न होने पर, टैग को अपने-आप लागू नहीं किया जाएगा. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba बहुत/issues/8830 पर जाएं.
टैग: build_file_semantics, experimental

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

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

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

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

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

सही होने पर, Baज़ल, 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/baडेलbuild/bazu/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 डिफ़ॉल्ट: "सही"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो local.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` एट्रिब्यूट में, वैल्यू "//..." का मतलब बदलता है. इससे, किसी भी रिपॉज़िटरी में मौजूद सभी पैकेज के बजाय, मौजूदा रिपॉज़िटरी में मौजूद सभी पैकेज का रेफ़रंस दिया जाता है. आप पुराने व्यवहार का पता लगाने के लिए "//..." के स्थान पर विशेष मान "सार्वजनिक" का उपयोग कर सकते हैं. इस फ़्लैग के लिए यह ज़रूरी है कि --insupported_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.action` पर उपलब्ध होगा, `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/bagelbuild/proposals/blob/Master/designs/2019-10-24-file- visibility.md पर जाएं
टैग: build_file_semantics, incompatible_change

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

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

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

अगर इसे 'सही है' पर सेट किया जाता है, तो लिंक करने की जानकारी के लिए, ObjcProvider के एपीआई हटा दिए जाएंगे.
टैग: build_file_semantics, incompatible_change

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सही होने पर, Baze अब @bagel_tools में cc_Configure का इस्तेमाल करने की अनुमति नहीं देगा. डेटा को दूसरी जगह भेजने से जुड़े निर्देशों और ज़्यादा जानकारी के लिए, कृपया https://github.com/bagelbuild/baaz/issues/10134 देखें.
टैग: loading_and_analysis, incompatible_change

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

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

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

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

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

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

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

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

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

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

सही होने पर, Baze, लिंक करने के लिए इस्तेमाल किए जाने वाले कमांड लाइन फ़्लैग में बदलाव नहीं करता. साथ ही, यह भी तय नहीं करता कि कौनसे फ़्लैग पैरामीटर फ़ाइल में जाएंगे और कौनसे नहीं. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba इमारतों/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) हैं. अगर कोई स्कीम नहीं दी जाती है, तो Baज़र, जीआरपीसी को मान लेता है.
टैग: affects_outputs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जब भी मुमकिन हो, बिल्ड इवेंट प्रोटोकॉल की बाइनरी फ़ाइल रिप्रज़ेंटेशन में पाथ को दुनिया भर में मान्य यूआरआई में बदलें; बंद होने पर, file:// uri स्कीम का हमेशा इस्तेमाल किया जाएगा
टैग: 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' या 'full_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:// uri स्कीम का हमेशा इस्तेमाल किया जाएगा
टैग: affects_outputs

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

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

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

किसी एक name_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:// uri स्कीम का इस्तेमाल हमेशा किया जाएगा
टैग: affects_outputs

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

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

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

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

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

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

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

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

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

अगर सही है, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी में रिलेटिव फ़ाइलसेट सिमलिंक को पूरी तरह से ठीक करें. --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 or unknown> बार इस्तेमाल किए गए

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TargetComplete इवेंट में लेगसी key_Outputs फ़ील्ड को जनरेट करने की प्रोसेस बंद करने के लिए, इसका इस्तेमाल करें. Basel से स्ट्रटीजस्टोर इंटिग्रेशन के लिए,अहम जानकारी ज़रूरी है.
टैग: 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"

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

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

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

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

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

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

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

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

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

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

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

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

इस Basel को शुरू करने की आवाज़ को एट्रिब्यूट करने के लिए टूल का नाम.
टैग: affects_outputs, bazel_monitoring

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

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

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

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

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

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

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

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

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

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

zstd तब तक काम नहीं करता, जब तक कि --remote_cache_compression सेट न किया गया हो.

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

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

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

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

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

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

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

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

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

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

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

--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.> डिफ़ॉल्ट: "60 सेकंड"

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

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

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

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

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

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

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

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

रिमोट आउटपुट सेवा एंडपॉइंट का Host या Host:PORT. काम करने वाले स्कीमा grpc, grpcs (TLS चालू होने वाला grpc) और Unix (स्थानीय UNIX सॉकेट) हैं. अगर कोई स्कीमा नहीं दिया जाता है, तो Basel को डिफ़ॉल्ट रूप से 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 के साथ --expal_platform_in_आउटपुट_डायरेक्टर (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --inaffiliate_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> डिफ़ॉल्ट: "कम से कम"

अगर 'सभी' पर सेट है, तो 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, grp, grpcs (TLS के साथ grpc) और Unix (स्थानीय UNIX सॉकेट) हैं. अगर कोई स्कीमा नहीं दिया जाता है, तो Basel को डिफ़ॉल्ट रूप से grpcs पर सेट कर दिया जाएगा. TLS को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://batz.build/remote/cating

पर जाएं

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

यह सुविधा चालू होने पर, कैश मेमोरी के ब्लॉब को zstd फ़ॉर्मैट में कंप्रेस या डीकंप्रेस करें. ऐसा तब करें, जब साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.

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

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

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

अगर किसी एक्ज़ीक्यूशन प्लैटफ़ॉर्म ने पहले से exec_property को सेट नहीं किया हो, तो रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल की जाने वाली डिफ़ॉल्ट 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 सॉकेट) हैं. अगर कोई स्कीमा नहीं दिया जाता है, तो Basel को डिफ़ॉल्ट रूप से grpcs पर सेट कर दिया जाएगा. TLS को बंद करने के लिए, grpc:// या Unix: स्कीमा तय करें.

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

अगर बताया गया हो, तो gRPC कॉल से जुड़ी जानकारी लॉग करने वाली फ़ाइल का पाथ. इस लॉग में, क्रम से लगाए गए com.google.devtools.build.lib.remote.logging.remote प्रोसेसutionLog.LogEntry Protobufs का क्रम होता है. हर मैसेज से पहले एक वैरिंट लगाया जाता है. यह आगे दिए गए सीरियल वाले प्रोटोबफ़ मैसेज का साइज़ दिखाता है, जिसे 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> डिफ़ॉल्ट: "स्थानीय"

नहीं, यह सुविधा बंद कर दी गई है. ज़्यादा जानकारी के लिए, https://github.com/bazibuild/ba इमारतों/issues/7480 पर जाएं.

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

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

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

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

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

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

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

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

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

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

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

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

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

आरसी फ़ाइलों से अतिरिक्त कॉन्फ़िगरेशन सेक्शन चुनता है; हर <command> के लिए, अगर ऐसा कोई सेक्शन मौजूद है, तो यह <command>:<config> से भी विकल्प लेता है; अगर यह सेक्शन किसी भी .rc फ़ाइल में मौजूद नहीं है, तो Blaze किसी गड़बड़ी की वजह से फ़ेल हो जाता है. कॉन्फ़िगरेशन सेक्शन और फ़्लैग के जिन कॉम्बिनेशन के बराबर हैं वे टूल/*.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/configलुing-bagels-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> डिफ़ॉल्ट: "ऑटो"

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

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

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

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

अगर सही का विकल्प चुना जाता है, तो Baze, होस्ट-ओएस के लिए खास तौर पर कॉन्फ़िगर की गई कॉन्फ़िगरेशन लाइनों का इस्तेमाल, baselrc फ़ाइलों से करता है. उदाहरण के लिए, अगर होस्ट ओएस, Linux है और आपके पास बैजल बिल्ड चलाने का विकल्प है, तो Basel, बिल्ड:linux से शुरू होने वाली लाइनों को चुन लेता है. काम करने वाले ओएस आइडेंटिफ़ायर, linux, macos, window, freebsd, और Openbsd हैं. इस फ़्लैग को चालू करना, Linux पर --config=linux, Windows पर --config=Windows वगैरह का इस्तेमाल करने के बराबर है.

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

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

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

अगर सही है, तो प्रयोग के तौर पर --watchfs के लिए Windows पर काम करने की सुविधा चालू है. अगर ऐसा नहीं है, तो Windows पर यह काम न करें. यह भी पक्का करें कि -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 कनेक्शन के लिए कीप-अलाइव पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो इतने समय बाद Baज़ल, कनेक्शन पर कोई कार्रवाई न होने पर पिंग भेजता है. ऐसा सिर्फ़ तब होता है, जब gRPC कॉल कम से कम एक पेंडिंग हो. समय को जानकारी के दूसरे लेवल के तौर पर देखा जाता है; एक सेकंड से कम समय वाली वैल्यू सेट करना गड़बड़ी होती है. डिफ़ॉल्ट रूप से, कीप-अलाइव पिंग बंद होते हैं. इस सेटिंग को चालू करने से पहले आपको सेवा के मालिक से संपर्क करना चाहिए. उदाहरण के लिए, इस फ़्लैग पर 30 सेकंड की वैल्यू सेट करने के लिए, इसे --grpc_keepalive_time=30s

की मदद से सेट करना चाहिए

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

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

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

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

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

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

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

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

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

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

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

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

किसी ऐसे TLS सर्टिफ़िकेट का पाथ बताएं जो सर्वर सर्टिफ़िकेट के लिए भरोसेमंद हो.

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

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

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

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

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

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

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

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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

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

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

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

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_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> डिफ़ॉल्ट: "गड़बड़ी"

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

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

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

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

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

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

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

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

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

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

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

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

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

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

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

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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

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

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर सेट नहीं है और --universe_scope को सेट नहीं किया गया, तो क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर --universe_scope की वैल्यू का अनुमान लगाया जाएगा. ध्यान दें, ऐसा हो सकता है कि यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे कि`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, textproto, proto, हमें_proto, jsonproto.
टैग: terminal_output

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

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

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

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

नियम_इनपुट और नियम_आउटपुट फ़ील्ड भरने या न भरने की जानकारी.
टैग: terminal_output

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

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

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--persistent_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

कर्मचारियों का इस्तेमाल करके, Android के स्थायी संसाधन प्रोसेसर को चालू करें.
इसे:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker

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



--strategy=Aapt2Optimize=worker--strategy=AARGenerator=worker--strategy=ProcessDatabinding=worker--strategy=GenerateDataBindingBaseClasses=workerhost_machine_resource_optimizationsexecution

--persistent_multiplex_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android संसाधन प्रोसेसर को चालू करें.
इनकी ओर से:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workersटैग करें

{14 --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workersटैग करें
5}{14
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers--modify_execution_info=AARGenerator=+supports-multiplex-workershost_machine_resource_optimizationsexecution

--persistent_multiplex_android_tools

Android के स्थायी और मल्टीप्लेक्स टूल (डेक्सिंग, डियूगरिंग, और रिसॉर्स प्रोसेसिंग) चालू करें.
इसे बड़ा किया जाता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

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

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

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

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

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

--android_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> डिफ़ॉल्ट: "@bagel_tools//tools/android:sdk"

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

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

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

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

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

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

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

--coverage_output_generator=<a build target label> का डिफ़ॉल्ट मैसेज: "@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> डिफ़ॉल्ट: "@bazu_tools//tools/cpp:toolchain"

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

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

कस्टम मैलक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में मैलक एट्रिब्यूट को बदल देती है.
टैग: 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 के हर ऐक्शन के लिए "ज़रूरी-xcode:{version}" लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "ज़रूरी-xcode-label:{version_label}" लागू करने की शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution

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

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

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

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

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

टूलचेन के रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों पर ध्यान दिया जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन पर विचार किया जाएगा, ताकि उन टूलचेन पर विचार किया जा सके जिनका एलान workspace_toolchains() से किया गया हो.
टैग: 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 और --कंपाइलर विकल्पों का इस्तेमाल, एक्ज़ीक्यूट कॉन्फ़िगरेशन के लिए भी किया जाता है. अगर यह फ़्लैग दिया जाता है, तो Ba बैंक, दिए गए 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> डिफ़ॉल्ट: "@ba"_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/batzbuild/ba इमारतों/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 डिफ़ॉल्ट: "सही"

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

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

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

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

अगर सही है, तो Basel को cc_common.Configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba बहुत/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 टारगेट चलाने के लिए इस्तेमाल किया जाता है. बहिष्कृत; --insupported_use_python_toolchains की मदद से बंद किया गया है.
टैग: loading_and_analysis, affects_outputs

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

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python अनुवादक को दिखाने वाले py_runtime का लेबल. बहिष्कृत; --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' से वॉचओएस SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

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

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

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

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

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

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

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

--[no]build_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 एपीआई वर्शन के लिए ज़्यादा कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental

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

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

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

इससे पता चलता है कि C++ कंपाइलेशन और लिंक के लिए, किस कंपाइलेशन मोड का इस्तेमाल किया जा रहा है. सभी मोड को सक्षम करने के लिए {'Fastbuild', 'dbg', 'opt'} या विशेष मानों का कोई भी संयोजन हो सकता है और सभी मोड को अक्षम करने के लिए 'no' का संयोजन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs

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

अगर नेटिव नियम सही हैं, तो नेटिव नियमों की मदद से, रनफ़ाइल में डेटा डिपेंडेंसी के लिए <code>DefaultInfo.files</code> जुड़ जाता है. यह तरीका Starlark के नियमों (https://bazz.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 डेटाबाइंडिंग 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> डिफ़ॉल्ट: "वर्णमाला"

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

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

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

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

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

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

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

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

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

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

वह मोड बताएं जिसमें बाइनरी बनाई जाएगी. मान: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

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

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

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

जीसीसी को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines, affects_outputs

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

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

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

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

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

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

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

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

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

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

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

--इसके लिए तय किया गया हर विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

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

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

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

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

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

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

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

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

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

APK में 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 APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

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

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

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

अगर साफ़ तौर पर बताया गया है, तो 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/bazibuild/baZZ/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> बार इस्तेमाल किए गए

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

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

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

वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल पहले से मौजूद होंगे. मान: '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> बार इस्तेमाल किए गए

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

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

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

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

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

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

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

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

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

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

एक्ज़ीक्यूटिव टूल के लिए swiftc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

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

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

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

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

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

अगर सही है, तो --सुविधा का इस्तेमाल सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए करें और --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change

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

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

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

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

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

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

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

iOS_ऐप्लिकेशन का इस्तेमाल करके, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें सभी खास आर्किटेक्चर शामिल हैं.
टैग: loses_incremental_state, loading_and_analysis

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

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

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

लिंक करते समय, जीसीसी में भेजने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड ( --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:prop इंतज़ार_Optimize( name = "prop Tager_profile", cc_profile = "prop सूचनाएं_cc_profile.txt", ld_profile = "prop मुझे_ld_profile.txt" में लेबल को लेबल करते हैं. इससे जुड़े पैकेज में export_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है, ताकि ये फ़ाइलें बेज़ेल में दिखें. इस विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --प्रॉपेलर_ऑप्टिमाइज़=//a/b:prop मॉडल_profile
टैग: action_command_lines, affects_outputs

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

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

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

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

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

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

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

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

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

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

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

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

स्विफ़्ट के कंपाइलेशन का इस्तेमाल करने के दूसरे विकल्प.
टैग: action_command_lines

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

ऐसे विकल्प जो इस बात पर असर डालते हैं कि 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_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/batzbuild/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/batzbuild/ba बहुत/issues/15684 देखें.
टैग: loading_and_analysis, incompatible_change

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

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

--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 टारगेट साफ़ तौर पर 'सार्वजनिक इंपोर्ट' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर बताता है.
टैग: 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 साइनिंग के लिए सर्टिफ़िकेट का नाम. अगर इस नीति को सेट नहीं किया जाता है, तो इसे सेट अप करने के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल पर वापस लाया जाएगा. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक, सर्टिफ़िकेट की कीचेन आइडेंटिटी प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम की (सबस्ट्रिंग) हो सकती है.
टैग: action_command_lines

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर सेट नहीं है और --universe_scope को सेट नहीं किया गया, तो क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर --universe_scope की वैल्यू का अनुमान लगाया जाएगा. ध्यान दें, ऐसा हो सकता है कि यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे कि`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, textproto, proto, हमें_proto, jsonproto.
टैग: terminal_output

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

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

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

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

नियम_इनपुट और नियम_आउटपुट फ़ील्ड भरने या न भरने की जानकारी.
टैग: terminal_output

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

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

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

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

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

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

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

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

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

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

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

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

लाइब्रेरीजार में मौजूद किसी भी क्लास को हटाने के लिए, 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 डिफ़ॉल्ट: "सही"

जेर फ़ाइल की हर फ़ाइल की डेक्सिंग के लिए ज़्यादातर काम अलग-अलग किए जाते हैं.
टैग: 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 टारगेट में लेगसी_create_init टारगेट "अपने-आप" (डिफ़ॉल्ट) पर सेट होता है, तो इस फ़्लैग के सेट होने पर ही इसे गलत माना जाता है. https://github.com/baazbuild/baZZ/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

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

अगर सही है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, '-py2' सफ़िक्स वाले आउटपुट रूट में दिखेंगे. वहीं, Python 3 के लिए बनाए गए टारगेट, Python से जुड़े सफ़िक्स के बिना रूट में दिखेंगे. इसका मतलब है कि `bazz-bin` सुविधा सिमलिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. अगर इस विकल्प को चालू किया जाता है, तो हमारा सुझाव है कि `--insupported_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change

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

अगर सही है, तो `py_binary` और `py_test` टारगेट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे PY2 के बजाय डिफ़ॉल्ट रूप से PY3 पर सेट हो जाएंगे. अगर आपने इस फ़्लैग को सेट किया है, तो हमारा सुझाव है कि `--insupported_py2_Outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

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

अगर लागू किए जा सकने वाले नेटिव Python नियम, --python_top जैसे लेगसी फ़्लैग से मिले रनटाइम के बजाय, Python टूलचेन के बताए गए Python रनटाइम का इस्तेमाल करेंगे, तो वे उसका इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change

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

Python मेजर वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि यह `py_binary` और `py_test` टारगेट से ओवरराइड होता है, भले ही वे किसी वर्शन की जानकारी साफ़ तौर पर न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

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

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

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

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

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

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

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

यह सुविधा सिर्फ़ Android-साथ काम करने वाली लाइब्रेरी तक उपलब्ध है.
टैग: affects_outputs

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

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

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

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

--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 में मौजूद पाथ पर फ़ाइल को टच करके शार्डिंग की सुविधा देता है, तो Baज़ल, शार्ड टेस्ट में फ़ेल हो जाएगा. गलत होने पर, शार्ड का समर्थन नहीं करने वाले टेस्ट रनर से हर शार्ड में सभी टेस्ट चल जाएंगे.
टैग: incompatible_change

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

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

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

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

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

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

--java_debug

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--plugin=<a build target label> बार इस्तेमाल किए गए

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

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

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

--proto_compiler=<a build target label> डिफ़ॉल्ट: "@bazu_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> का डिफ़ॉल्ट अनुवाद: "@bagel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल जो j2objc protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bagel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल जो Java प्रोटो को इकट्ठा करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@baaz_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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो कोई भी शार्ड जिसमें कम से कम एक दौड़ या कोशिश फ़ेल हो जाती है उसे 'फ़्लैकी' स्टेटस मिलता है.

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

बेज़ल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल, पहले Basel के बोले जाने पर शुरू करने वाले टूल (जिससे Baज़र सर्वर शुरू होता है) पर सेट है, Baze इसका इस्तेमाल करता है. यदि दोनों में से कोई भी सेट नहीं है, तो Ba जानना, आपके द्वारा चलाए जाने वाले ऑपरेटिंग सिस्टम के आधार पर हार्ड कोड किए गए डिफ़ॉल्ट पथ का उपयोग करता है (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash). ध्यान दें कि किसी ऐसे शेल का इस्तेमाल करने से जो बैश के साथ काम नहीं करता है, हो सकता है कि जनरेट की गई बाइनरी बिल्ड न हो या रनटाइम बंद हो जाए.
टैग: loading_and_analysis

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

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

टेस्ट शार्डिंग के लिए रणनीति तय करें: 'शर्डिंग' एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब शार्डिंग का इस्तेमाल किया जा रहा हो. 'अक्षम' है. 'shard_count' BUILD एट्रिब्यूट पर ध्यान दिए बिना, जांच के लिए 'k' शार्ड लागू करने के लिए 'forced=k' का इस्तेमाल किया जाता है.

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

Java लैंग्वेज वर्शन, जिसका इस्तेमाल ऐसे टूल को एक्ज़ीक्यूट करने के लिए किया जाता है जो बिल्ड के दौरान ज़रूरी होते हैं

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

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

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

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

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

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

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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

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

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: 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_ मांग` सेट किए गए है,तो डिफ़ॉल्ट फ़ॉलबैक सूची`worker, sandboxed` या `worker,sandboxed,Standalone` होती है. [mnemonic=]local_strategy[,local_strategy,...] का इस्तेमाल करता है
टैग: execution, host_machine_resource_optimizations

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

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

यह सुविधा चालू होने पर, मौजूदा उपयोगकर्ता के uid और gid को इस्तेमाल करने से पहले, Docker इमेज में इंजेक्ट किया जाता है. अगर आपका बिल्ड / टेस्ट इस बात पर निर्भर है कि उपयोगकर्ता के पास कंटेनर के अंदर नाम और होम डायरेक्ट्री है, तो ऐसा करना ज़रूरी है. यह डिफ़ॉल्ट रूप से चालू होता है. हालांकि, अगर इमेज को अपने-आप कस्टमाइज़ करने की सुविधा आपके मामले में काम नहीं करती है या आपको पता है कि आपको उसकी ज़रूरत नहीं है, तो आपके पास इसे बंद करने का विकल्प होता है.
टैग: execution

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

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

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

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

--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 dit पर जाने के लिए, अनुमतियों की ज़रूरत होती है.
टैग: execution

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

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

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

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

_experimental_use_window_sandbox पर सही होने पर, Windows सैंडबॉक्स बाइनरी का पाथ. अगर कोई नाम नहीं है, तो PATH में मिली उस नाम की पहली बाइनरी का इस्तेमाल करें.
टैग: execution

--experimental_worker_allowlist=<comma-separated set of options> डिफ़ॉल्ट: ब्यौरा देखें

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

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

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

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

अगर यह सुविधा चालू की जाती है, तो Basel, सहायता टीम से संपर्क करने वाले कर्मचारियों को सदस्यता रद्द करने का अनुरोध भेज सकता है.
टैग: 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"

कर्मचारियों की मेट्रिक इकट्ठा करने और शायद निकालने की कोशिश के बीच का समय. परफ़ॉर्मेंस की वजहों से, यह वैल्यू 1 सेकंड से कम नहीं हो सकती.
टैग: execution, host_machine_resource_optimizations

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

चालू होने पर, मल्टीप्लेक्स वर्कर को सैंडबॉक्स किया जाएगा. इसके लिए, हर काम के अनुरोध के लिए एक अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल किया जाएगा. सिर्फ़ उन कर्मचारियों को सैंडबॉक्स किया जाएगा जिन्हें 'supports-मल्टीप्लेक्स-सैंडबॉक्सिंग' लागू करने की ज़रूरी शर्त है.
टैग: 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) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

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

यह बताएं कि जेनरूल को कैसे लागू करना है. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> का इस्तेमाल करें या सिर्फ़ जेनरूल को कंट्रोल करने के लिए --strategy=Gen दवा=<value> का इस्तेमाल करें.
टैग: execution

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

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

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

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

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

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

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

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

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

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

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

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

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

किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. जो टारगेट पूरा नहीं हो पाया और जो उस पर निर्भर हैं उनका विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें हो सकती हैं.
टैग: eagerness_to_exit

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

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

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

तय करें कि स्पॉन्सर ऐक्शन को डिफ़ॉल्ट रूप से कैसे लागू किया जाए. सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के बीच, कॉमा लगाकर अलग की गई रणनीतियों की सूची स्वीकार की जाती है. हर कार्रवाई के लिए, Basel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है और कार्रवाई को पूरा कर सकता है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी के लिए, https://blog.bazu.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

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

जानकारी दें कि अन्य स्पॉन्स ऐक्शन के कंपाइलेशन को कैसे डिस्ट्रिब्यूट किया जाए. सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के बीच, कॉमा लगाकर अलग की गई रणनीतियों की सूची स्वीकार की जाती है. हर कार्रवाई के लिए, Basel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है और कार्रवाई को पूरा कर सकता है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग --spawn_strategy (और अगर याद रखने के लिए जेनरिक नियम के साथ इस्तेमाल किया गया है, तो --gen सकारात्मक_strategy) से सेट की गई वैल्यू बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazu.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> बार इस्तेमाल किए गए

यह बदलाव करें कि किसी खास regex_filter से मेल खाने वाली जानकारी वाली स्पॉन्स कार्रवाइयों को लागू करने के लिए, किस स्पॉन्स रणनीति का इस्तेमाल करना चाहिए. regex_filter मिलान के बारे में ज़्यादा जानकारी के लिए --per_file_copt देखें. जानकारी से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. रणनीति तय करने के लिए यह विकल्प दूसरे फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि स्थानीय रणनीति का इस्तेमाल करके कार्रवाइयां चलाना, अगर उनके विवरण //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar नहीं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed 'कंपाइलिंग //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा, लेकिन ऑर्डर को उलटा करने पर वह 'सैंडबॉक्स' के साथ चल जाएगा.
टैग: execution

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

एक और कमांड-फ़्लैग, जो कर्मचारी की प्रोसेस को दिया जाएगा. इसके अलावा, उसे --persistent_worker के साथ-साथ, याद रखने की तकनीक (जैसे कि --worker_extra_flag=Jawk=--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". 'ऑटो', मशीन की क्षमता के आधार पर उचित डिफ़ॉल्ट का हिसाब लगाता है. "=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] के तौर पर बताया जा सकता है. यह सीमा वर्कर कुंजियों पर आधारित होती है, जिन्हें स्नेमनी के आधार पर अलग-अलग किया जाता है. साथ ही, यह स्टार्टअप फ़्लैग और पर्यावरण के आधार पर भी तय होता है. इसलिए, कुछ मामलों में हर याद में, इस फ़्लैग की तुलना में ज़्यादा वर्कर हो सकते हैं. यह एक पूर्णांक या कीवर्ड ("ऑटो", "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, और बार का कॉम्बिनेशन बनाया जाता है, जबकि --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"

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

--[no]experimental_convenience_symlinks डिफ़ॉल्ट: "सामान्य"

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

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

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

--remote_download_all

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

टैग: affects_outputs

--remote_download_minimal

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

टैग: affects_outputs

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

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

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

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

--remote_download_toplevel

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

टैग: affects_outputs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एक साथ चलाने के लिए लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. यह एक पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल करता है. इसके बाद, वैकल्पिक रूप से कोई कार्रवाई ([-|*]<float>) ली जाती है, जैसे कि. "auto", "Host_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, एक साथ चलाए जाने के लिए लोकल टेस्ट जॉब की संख्या को सीमित कर देगा. इसे 'नौकरी' के लिए वैल्यू से ज़्यादा सेट करना असर नहीं पड़ता.
टैग: 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>` के तौर पर बताएं, जिसे रिज़ॉल्व की गई डिपेंडेंसी ग्राफ़ में अनुमति दी जाएगी. भले ही, उन्हें रजिस्ट्री में येनक किया गया हो, जहां से वे आए हैं (अगर वे NonRegistryOver से नहीं आए हैं). ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन नहीं हो पाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, अनुमति पाए हुए वर्शन को भी तय किया जा सकता है. कीवर्ड 'सभी' का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, हम इसका सुझाव नहीं देते.
टैग: loading_and_analysis

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

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

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

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

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

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

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

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

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

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

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

--experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers> डिफ़ॉल्ट: ब्यौरा देखें

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

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

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <period>:<count> के तौर पर बताई जाती है. इसमें पीरियड की जानकारी कुल समय और संख्या, पॉज़िटिव पूर्णांक होती है. अगर <पीरियड> में <count> लगातार जीसीएस होने के बाद भी लंबे समय तक काम करने वाले स्पेस (old gen हीप) के --gc_t इससेhhreshold से ज़्यादा प्रतिशत खाली रहता है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाओं को कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "Host_CPUS"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अब काम नहीं करता है.
टैग: execution

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

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

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

अगर इसे चालू किया जाता है, तो Baज़र, Docker सैंडबॉक्स रणनीति के बारे में ज़्यादा जानकारी देने वाले मैसेज प्रिंट करेगा.
टैग: execution

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

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

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

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

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

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

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

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

यह टेस्ट की खास जानकारी का पसंदीदा फ़ॉर्मैट तय करता है. मान्य वैल्यू को सिर्फ़ लागू किए गए टेस्ट की जानकारी को प्रिंट करने के लिए 'छोटा', 'ट्रिस', और पूरे न हो चुके टेस्ट के बारे में जानकारी प्रिंट करने के लिए 'ज़्यादा जानकारी', टेस्ट केस के समाधान के बारे में ज़्यादा जानकारी प्रिंट करने के लिए 'ज़्यादा जानकारी', टेस्ट केस के समाधान में जवाब को प्रिंट करने के लिए 'टेस्टकेस', पूरे न होने वाले टेस्ट केस की पूरी जानकारी प्रिंट न करें, और जवाब को शामिल न करने के लिए 'कोई नहीं'.
टैग: terminal_output

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

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

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

अगर कोई निर्देश काम नहीं करता, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

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

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

कमांड-लाइन आसपेक्ट रेशियो के पैरामीटर की वैल्यू बताता है. हर पैरामीटर का वैल्यू, <param_name>=<param_value> की मदद से तय किया जाता है. उदाहरण के लिए, 'my_param=my_val' जहां 'my_param', --aspects की सूची में मौजूद किसी पहलू का पैरामीटर होता है या सूची में किसी पहलू के लिए ज़रूरी होता है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. हालांकि, एक ही पैरामीटर के लिए एक से ज़्यादा बार वैल्यू असाइन नहीं की जा सकती.
टैग: loading_and_analysis

--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 कर्नेल फ़ाइलों को लिखने में देरी करता है और इसकी वजह से फ़ॉल्स पॉज़िटिव नतीजे आ सकते हैं.

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

अगर बिल्ड में मौजूद रिमोट कैश मेमोरी को हटाने में कोई गड़बड़ी हुई हो, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. एक गैर-शून्य मान को स्पष्ट रूप से --insupported_remote_use_new_exit_code_for_lost_inputs को सही पर सेट कर दिया जाएगा. हर कोशिश के लिए एक नया शुरू करने का आईडी जनरेट किया जाएगा. अगर आप न्योते का आईडी जनरेट करते हैं और उसे --invocation_id के साथ Basel को उपलब्ध कराते हैं, तो आपको इस फ़्लैग का इस्तेमाल नहीं करना चाहिए. इसके बजाय, फ़्लैग --inaffiliate_remote_use_new_exit_code_for_lost_inputs सेट करें और एग्ज़िट कोड 39 देखें.
टैग: execution

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

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

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

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

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

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

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

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

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

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

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

--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.> डिफ़ॉल्ट: "60 सेकंड"

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

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

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

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

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

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

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

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

रिमोट आउटपुट सेवा एंडपॉइंट का Host या Host:PORT. काम करने वाले स्कीमा grpc, grpcs (TLS चालू होने वाला grpc) और Unix (स्थानीय UNIX सॉकेट) हैं. अगर कोई स्कीमा नहीं दिया जाता है, तो Basel को डिफ़ॉल्ट रूप से 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 के साथ --expal_platform_in_आउटपुट_डायरेक्टर (आउटपुट प्रीफ़िक्स को सामान्य बनाने के लिए) और --inaffiliate_strict_action_env (एनवायरमेंट वैरिएबल को नॉर्मलाइज़ करने के लिए) के साथ सेट किया जा सकता है.

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

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

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

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

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

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

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

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

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

No-op
टैग: incompatible_change

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

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो अगर बिल्ड के दौरान रिमोट कैश मेमोरी को बाहर कर देती है, तो Baज़ल, 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगा.
टैग: incompatible_change

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

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

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

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

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

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

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

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

पर जाएं

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

यह सुविधा चालू होने पर, कैश मेमोरी के ब्लॉब को zstd फ़ॉर्मैट में कंप्रेस या डीकंप्रेस करें. ऐसा तब करें, जब साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.

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

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

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

अगर किसी एक्ज़ीक्यूशन प्लैटफ़ॉर्म ने पहले से exec_property को सेट नहीं किया हो, तो रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल की जाने वाली डिफ़ॉल्ट 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 सॉकेट) हैं. अगर कोई स्कीमा नहीं दिया जाता है, तो Basel को डिफ़ॉल्ट रूप से grpcs पर सेट कर दिया जाएगा. TLS को बंद करने के लिए, grpc:// या Unix: स्कीमा तय करें.

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

अगर बताया गया हो, तो gRPC कॉल से जुड़ी जानकारी लॉग करने वाली फ़ाइल का पाथ. इस लॉग में, क्रम से लगाए गए com.google.devtools.build.lib.remote.logging.remote प्रोसेसutionLog.LogEntry Protobufs का क्रम होता है. हर मैसेज से पहले एक वैरिंट लगाया जाता है. यह आगे दिए गए सीरियल वाले प्रोटोबफ़ मैसेज का साइज़ दिखाता है, जिसे 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> डिफ़ॉल्ट: "स्थानीय"

नहीं, यह सुविधा बंद कर दी गई है. ज़्यादा जानकारी के लिए, https://github.com/bazibuild/ba इमारतों/issues/7480 पर जाएं.

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

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

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

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

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

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

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

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

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

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

यह तय करता है कि कुल कवरेज की रिपोर्ट किस तरह की है. फ़िलहाल, सिर्फ़ LCOV का इस्तेमाल किया जा सकता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

src/main/protobuf/spawn.proto के मुताबिक, एक्ज़ीक्यूट किए गए स्पॉन्स को इस फ़ाइल में, SpwnSequence प्रोटो के न्यूलाइन-डीलिमिटेड JSON प्रज़ेंटेशन के तौर पर लॉग करें. संबंधित फ़्लैग: --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_execution_log_compact_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें

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

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

पक्षों के पहलुओं को प्राथमिकता दी जाती है. टारगेट के सेट के फ़िल्टर जिनके लिए extra_action शेड्यूल करने हैं.

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

पक्षों के पहलुओं को प्राथमिकता दी जाती है. टॉप लेवल टारगेट के लिए सिर्फ़ extra_action शेड्यूल करता है.

--experimental_spawn_scheduler

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

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

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

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

No-op
टैग: incompatible_change

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

टाइम आउट की वजह से, किसी लोकल प्रोसेस को खत्म करने और उसे ज़बरदस्ती बंद करने के बीच इंतज़ार का समय.

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

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

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

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

--[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_tag_filters=<comma-separated list of options> डिफ़ॉल्ट: ""

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

--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: ""

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह बताएं कि जेनरूल को कैसे लागू करना है. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> का इस्तेमाल करें या सिर्फ़ जेनरूल को कंट्रोल करने के लिए --strategy=Gen दवा=<value> का इस्तेमाल करें.
टैग: execution

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

अगर यह नीति सेट की जाती है, तो आउटपुट फ़ाइल को डायरेक्ट्री के तौर पर सेट करने से जुड़ी कार्रवाई में गड़बड़ी होती है. सोर्स डायरेक्ट्री पर असर नहीं पड़ता. https://github.com/bagelbuild/baकोई का इस्तेमाल करने के लिए 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] डिफ़ॉल्ट: "ऑटो"

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

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

किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. जो टारगेट पूरा नहीं हो पाया और जो उस पर निर्भर हैं उनका विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें हो सकती हैं.
टैग: eagerness_to_exit

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

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

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

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

--persistent_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

कर्मचारियों का इस्तेमाल करके, Android के स्थायी संसाधन प्रोसेसर को चालू करें.
इसे:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker

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



--strategy=Aapt2Optimize=worker--strategy=AARGenerator=worker--strategy=ProcessDatabinding=worker--strategy=GenerateDataBindingBaseClasses=workerhost_machine_resource_optimizationsexecution

--persistent_multiplex_android_dex_desugar

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

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android संसाधन प्रोसेसर को चालू करें.
इनकी ओर से:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workersटैग करें

{14 --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workersटैग करें
5}{14
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers--modify_execution_info=AARGenerator=+supports-multiplex-workershost_machine_resource_optimizationsexecution

--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://ba बहुत.build/extending/platforms#skipping-insupported-targets
टैग: loading_and_analysis

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

तय करें कि स्पॉन्सर ऐक्शन को डिफ़ॉल्ट रूप से कैसे लागू किया जाए. सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के बीच, कॉमा लगाकर अलग की गई रणनीतियों की सूची स्वीकार की जाती है. हर कार्रवाई के लिए, Basel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है और कार्रवाई को पूरा कर सकता है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी के लिए, https://blog.bazu.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

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

जानकारी दें कि अन्य स्पॉन्स ऐक्शन के कंपाइलेशन को कैसे डिस्ट्रिब्यूट किया जाए. सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के बीच, कॉमा लगाकर अलग की गई रणनीतियों की सूची स्वीकार की जाती है. हर कार्रवाई के लिए, Basel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है और कार्रवाई को पूरा कर सकता है. इसकी डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग --spawn_strategy (और अगर याद रखने के लिए जेनरिक नियम के साथ इस्तेमाल किया गया है, तो --gen सकारात्मक_strategy) से सेट की गई वैल्यू बदल देता है. ज़्यादा जानकारी के लिए, https://blog.bazu.build/2019/06/19/list-strategy.html पर जाएं.
टैग: execution

--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment> बार इस्तेमाल किए गए

यह बदलाव करें कि किसी खास regex_filter से मेल खाने वाली जानकारी वाली स्पॉन्स कार्रवाइयों को लागू करने के लिए, किस स्पॉन्स रणनीति का इस्तेमाल करना चाहिए. regex_filter मिलान के बारे में ज़्यादा जानकारी के लिए --per_file_copt देखें. जानकारी से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. रणनीति तय करने के लिए यह विकल्प दूसरे फ़्लैग को बदल देता है. उदाहरण: --strategy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि स्थानीय रणनीति का इस्तेमाल करके कार्रवाइयां चलाना, अगर उनके विवरण //foo.*.cc से मेल खाते हैं, लेकिन //foo/bar नहीं. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed 'कंपाइलिंग //foo/bar/baz' को 'local' रणनीति के साथ चलाएगा, लेकिन ऑर्डर को उलटा करने पर वह 'सैंडबॉक्स' के साथ चल जाएगा.
टैग: execution

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

अगर सही है, तो Baze, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा, न कि टेस्ट एक्ज़ेक्यूटिव ग्रुप का.
टैग: 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> डिफ़ॉल्ट: "@bagel_tools//tools/android:sdk"

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

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

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

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

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

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

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

--coverage_output_generator=<a build target label> का डिफ़ॉल्ट मैसेज: "@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> डिफ़ॉल्ट: "@bazu_tools//tools/cpp:toolchain"

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

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

कस्टम मैलक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में मैलक एट्रिब्यूट को बदल देती है.
टैग: 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 के हर ऐक्शन के लिए "ज़रूरी-xcode:{version}" लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "ज़रूरी-xcode-label:{version_label}" लागू करने की शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution

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

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

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

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

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

टूलचेन के रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों पर ध्यान दिया जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन पर विचार किया जाएगा, ताकि उन टूलचेन पर विचार किया जा सके जिनका एलान workspace_toolchains() से किया गया हो.
टैग: 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 और --कंपाइलर विकल्पों का इस्तेमाल, एक्ज़ीक्यूट कॉन्फ़िगरेशन के लिए भी किया जाता है. अगर यह फ़्लैग दिया जाता है, तो Ba बैंक, दिए गए 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> डिफ़ॉल्ट: "@ba"_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/batzbuild/ba इमारतों/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 डिफ़ॉल्ट: "सही"

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

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

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

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

अगर सही है, तो Basel को cc_common.Configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba बहुत/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 टारगेट चलाने के लिए इस्तेमाल किया जाता है. बहिष्कृत; --insupported_use_python_toolchains की मदद से बंद किया गया है.
टैग: loading_and_analysis, affects_outputs

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

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python अनुवादक को दिखाने वाले py_runtime का लेबल. बहिष्कृत; --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' से वॉचओएस SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

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

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

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

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

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

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

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

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

बिल्ड का इस्तेमाल करें; यह आम तौर पर होने वाला तरीका है. --nobuild की वैल्यू तय करने से, बिल्ड ऐक्शन को पूरा करने से पहले बिल्ड रुक जाता है. अगर पैकेज लोड होने और उसके विश्लेषण के चरण पूरे होने पर कोई वैल्यू नहीं मिलती है, तो इस मोड की मदद से इन फ़ेज़ की टेस्टिंग की जा सकती है.
टैग: execution, affects_outputs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इससे पता चलता है कि C++ कंपाइलेशन और लिंक के लिए, किस कंपाइलेशन मोड का इस्तेमाल किया जा रहा है. सभी मोड को सक्षम करने के लिए {'Fastbuild', 'dbg', 'opt'} या विशेष मानों का कोई भी संयोजन हो सकता है और सभी मोड को अक्षम करने के लिए 'no' का संयोजन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs

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

अगर नेटिव नियम सही हैं, तो नेटिव नियमों की मदद से, रनफ़ाइल में डेटा डिपेंडेंसी के लिए <code>DefaultInfo.files</code> जुड़ जाता है. यह तरीका Starlark के नियमों (https://bazz.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, और बार का कॉम्बिनेशन बनाया जाता है, जबकि --Output_groups=foo,bar, डिफ़ॉल्ट सेट को इस तरह से ओवरराइड करता है, ताकि सिर्फ़ foo और bar बनाया जा सके.
टैग: execution, affects_outputs

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

बिल्ड के हिस्से के तौर पर, पुष्टि करने से जुड़ी कार्रवाइयां करनी हैं या नहीं. https://baZ.build/extending/rules#validation_ टास्क देखें
टैग: 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 डेटाबाइंडिंग 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> डिफ़ॉल्ट: "वर्णमाला"

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

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

ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--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 से लिया गया टॉप-लेवल मान है

--[no]build_python_zip डिफ़ॉल्ट: "ऑटो"

python की एक्ज़ीक्यूटेबल ZIP फ़ाइल बनाएं; Windows पर, अन्य प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs

--catalyst_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

कॉमा से अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple Catपाल बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "गलत"

अगर सूचना दी जाती है, तो Baज़र, इंस्ट्रुमेंट कोड का इस्तेमाल करेगा (जहां संभव हो ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ --instrumentation_filter से मेल खाने वाले टारगेट ही प्रभावित होंगे. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताना चाहिए - इसके बजाय, 'bazu दूरी' निर्देश का इस्तेमाल करना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "फ़ास्टबिल्ड"

वह मोड बताएं जिसमें बाइनरी बनाई जाएगी. मान: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--conlyopt=<a string> बार इस्तेमाल किए गए

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> बार इस्तेमाल किए गए

जीसीसी को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई एलएलवीएम प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का ऐब्सलूट पाथ बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंट की बाइनरी जनरेट करना. Clang/LLVM कंपाइलर की मदद से, यह डायरेक्ट्री का नाम भी स्वीकार करता है. इसके तहत, रनटाइम के दौरान, रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को डंप किया जाएगा.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली कॉन्टेक्स्ट सेंसिटिव प्रोफ़ाइल को दिखाने वाली cs_fdo_profile.
टैग: affects_outputs

--cxxopt=<a string> बार इस्तेमाल किए गए

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> बार इस्तेमाल किए गए

--इसके लिए तय किया गया हर विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "डिफ़ॉल्ट"

यह तय करता है कि C++ बाइनरी को डाइनैमिक रूप से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Basel को यह चुनना होगा कि उसे डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी' का मतलब है कि सभी लाइब्रेरी डायनैमिक रूप से लिंक कर दी जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्थिर मोड में लिंक की जाएंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह नीति सेट की जाती है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी दिखेगी.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "ऑटो"

रनफ़ाइल सिमलिंक ट्री चालू करें. डिफ़ॉल्ट रूप से, यह Windows में दूसरे प्लैटफ़ॉर्म पर बंद रहती है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> बार इस्तेमाल किए गए

पक्षों के पहलुओं को प्राथमिकता दी जाती है. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में 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 APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत"

dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत"

अगर साफ़ तौर पर बताया गया है, तो Basel, जनरेट की गई फ़ाइलों के कवरेज की जानकारी भी जनरेट करेगा.
टैग: affects_outputs

--[no]experimental_convenience_symlinks डिफ़ॉल्ट: "सामान्य"

यह फ़्लैग कंट्रोल करता है कि सुविधा सिमलिंक (बिल्ड के बाद, फ़ाइल फ़ोल्डर में दिखने वाले सिमलिंक) कैसे मैनेज किए जाएंगे. संभावित वैल्यू: सामान्य (डिफ़ॉल्ट): हर तरह का सुविधा सिमलिंक बनाया या मिटाया जाएगा, जैसा कि बिल्ड के आधार पर तय किया जाता है. साफ़ करें: सभी सिमलिंक बिना किसी शर्त के मिटा दिए जाएंगे. ध्यान न दें: सिमलिंक अकेले छोड़ दिए जाएंगे. Log_only: लॉग मैसेज जनरेट करें जैसे कि 'सामान्य' पास किया गया हो, लेकिन असल में फ़ाइल सिस्टम से जुड़ी कोई कार्रवाई न करें. यह टूल के लिए काम का है. ध्यान दें कि सिर्फ़ उन सिमलिंक पर असर पड़ सकता है जिनके नाम --simlink_prefix की मौजूदा वैल्यू से जनरेट हुए हैं; अगर प्रीफ़िक्स में बदलाव होता है, तो पहले से मौजूद कोई भी सिमलिंक छोड़ दिए जाएंगे.
टैग: affects_outputs

--[no]experimental_convenience_symlinks_bep_event डिफ़ॉल्ट: "गलत"

इस फ़्लैग से यह कंट्रोल किया जाता है कि हम बिल्ड event subscriptionsSymlinksIdentified को BuildEventProtocol पर पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में shoppingSymlinksIdentified, के लिए एक एंट्री होगी, जिसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक की सूची होगी. अगर गलत है, तो BuildEventProtocol में सुविधाSymlinksIdentified एंट्री वाला फ़ील्ड खाली रहेगा.
टैग: 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/bazibuild/baZZ/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> बार इस्तेमाल किए गए

हर एंट्री फ़ॉर्म में लेबल=वैल्यू के तौर पर होनी चाहिए. यहां लेबल किसी प्लैटफ़ॉर्म के बारे में बताता है. साथ ही, आउटपुट पाथ में इस्तेमाल करने के लिए, वैल्यू एक छोटा नाम होना चाहिए. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_Output_किन सही है. नाम रखने की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत"

अगर सही है, तो टारगेट प्लैटफ़ॉर्म के छोटे नाम का इस्तेमाल, सीपीयू के बजाय आउटपुट डायरेक्ट्री के नाम में किया जाता है. सटीक स्कीम प्रयोग के तौर पर है और इसमें बदलाव हो सकते हैं: पहला, बहुत ही कम मामलों में --प्लैटफ़ॉर्म विकल्प में सिर्फ़ एक वैल्यू नहीं होती, इसलिए प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए किसी छोटे नाम को --experimental_override_name_platform_in_Output_ ख़िलाफ़ ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_Output_ इससे_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_किन फ़ंक्शन पर भरोसा करने पर माइग्रेट करें.
टैग: 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 फ़ाइल या एलएलवीएम प्रोफ़ाइल फ़ाइल हो. इस फ़्लैग में लेबल के तौर पर दी गई फ़ाइलें (जैसे कि `//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> डिफ़ॉल्ट: "ऑप्ट करें"

वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल पहले से मौजूद होंगे. मान: '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> बार इस्तेमाल किए गए

यहां दी गई सुविधाएं, एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> के बारे में बताने से सुविधा बंद हो जाएगी. नेगेटिव सुविधाएं, हमेशा पॉज़िटिव वैल्यू को ओवरराइड कर देती हैं.
टैग: changes_inputs, affects_outputs

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

exec कॉन्फ़िगरेशन के लिए, Python वर्शन को बदलता है. यह "PY2" या "PY3" हो सकता है.
टैग: loading_and_analysis, affects_outputs

--host_linkopt=<a string> बार इस्तेमाल किए गए

एक्ज़िक कॉन्फ़िगरेशन में टूल जोड़ते समय, लिंकर को भेजने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, कम से कम काम करने वाला macOS वर्शन. अगर जानकारी नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> बार इस्तेमाल किए गए

एक्ज़ीक्यूटिव कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के अन्य विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर रखने की सूची दिखाता है (यह भी देखें --instrumentation_filter). option_1 से option_n का मतलब, आर्बिट्रेरी कमांड लाइन विकल्पों के लिए है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में बार.cc को छोड़कर, सभी cc फ़ाइलों की cc कमांड लाइन में -O0 कमांड लाइन का विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--host_swiftcopt=<a string> बार इस्तेमाल किए गए

एक्ज़ीक्यूटिव टूल के लिए swiftc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "गलत"

चालू होने पर, किसी नियम में इस्तेमाल होने वाले हर टूलचेन के लिए एक्ज़ेक्यूटिव ग्रुप अपने-आप बन जाता है. इसके काम करने के लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazibuild/bagel/issues/17134 देखें.
टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही"

अगर सही है, तो जेनफ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_use_host_features डिफ़ॉल्ट: "सही"

अगर सही है, तो --सुविधा का इस्तेमाल सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए करें और --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "गलत"

कवरेज की सुविधा चालू होने पर, यह तय किया जाता है कि टेस्ट के नियमों को लागू किया जाए या नहीं. सेट होने पर, --instrumentation_filter पर शामिल किए गए टेस्ट नियम इंस्ट्रुमेंट किए जाते हैं. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रुमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/javatests[/:],-/test/java[/:]"

कवरेज चालू होने पर, सिर्फ़ खास रेगुलर एक्सप्रेशन-आधारित फ़िल्टर में शामिल नामों वाले नियम ही लागू किए जाएंगे. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि जब तक --instrument_test_targets को चालू नहीं किया जाता, तब तक सिर्फ़ नॉन-टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है.
टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के साथ काम करने वाला कम से कम iOS वर्शन. अगर तय नहीं है, तो 'ios_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--ios_multi_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

iOS_ऐप्लिकेशन का इस्तेमाल करके, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें सभी खास आर्किटेक्चर शामिल हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive डिफ़ॉल्ट: "सही"

अब काम नहीं करता, --inबेमेल_remove_legacy_whole_archive (ज़्यादा जानकारी के लिए, https://github.com/ba आवाज़ोंbuild/baZ/issues/7362 पर जाएं) पर जाएं. इसे चालू होने पर, cc_binary नियमों के लिए -पूरा-संग्रह का इस्तेमाल करें, जिसमें linkshared=True होता है और linkopts में linkstatic=True या '-static' होता है. यह सुविधा सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर,Alwayslink=1 का इस्तेमाल करना एक बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> बार इस्तेमाल किए गए

लिंक करते समय, जीसीसी में भेजने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> बार इस्तेमाल किए गए

एलटीओ बैकएंड चरण को पास करने के लिए एक और विकल्प (-features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> बार इस्तेमाल किए गए

एलटीओ इंडेक्स करने के चरण को पास करने का एक और विकल्प (-features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple macOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, कम से कम macOS का वर्शन होना चाहिए. अगर जानकारी नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "गलत"

अगर सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS के बारे में बताएं.
टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर इस फ़्लैग और --compilation_mode=opt, दोनों के बारे में बताया गया है, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

--objccopt=<a string> बार इस्तेमाल किए गए

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> बार इस्तेमाल किए गए

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तरीके से पास करने के लिए अन्य विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर रखने की सूची दिखाता है (यह भी देखें --instrumentation_filter). option_1 से option_n का मतलब, आर्बिट्रेरी कमांड लाइन विकल्पों के लिए है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //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> बार इस्तेमाल किए गए

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड ( --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:prop इंतज़ार_Optimize( name = "prop Tager_profile", cc_profile = "prop सूचनाएं_cc_profile.txt", ld_profile = "prop मुझे_ld_profile.txt" में लेबल को लेबल करते हैं. इससे जुड़े पैकेज में export_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है, ताकि ये फ़ाइलें बेज़ेल में दिखें. इस विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --प्रॉपेलर_ऑप्टिमाइज़=//a/b:prop मॉडल_profile
टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए, ld_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

'टेस्ट' और 'रन' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले प्रीफ़िक्स का इस्तेमाल करें. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो आखिरी कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

--[no]share_native_deps डिफ़ॉल्ट: "सही"

अगर सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट में शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "गलत"

तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह के साथ स्टैंप बाइनरी.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं ("-Wl,--strip-debug" का इस्तेमाल करना). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब स्ट्रिप iff --compilation_mode=fastbuild है.
टैग: affects_outputs

--stripopt=<a string> बार इस्तेमाल किए गए

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--swiftcopt=<a string> बार इस्तेमाल किए गए

स्विफ़्ट के कंपाइलेशन का इस्तेमाल करने के दूसरे विकल्प.
टैग: action_command_lines

--symlink_prefix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

यह प्रीफ़िक्स, बिल्ड के बाद बनाए जाने वाले किसी भी सुविधा सिमलिंक के पहले जोड़ा जाता है. अगर इसे छोड़ दिया जाता है, तो डिफ़ॉल्ट वैल्यू बिल्ड टूल के नाम के बाद हाइफ़न होती है. अगर '/' को पास कर दिया जाता है, तो कोई सिमलिंक नहीं बनाया जाता और कोई चेतावनी नहीं भेजी जाती. चेतावनी: '/' के लिए खास फ़ंक्शन जल्द ही बंद कर दिया जाएगा; इसके बजाय --experimental_convenience_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

ऐसे विकल्प जो इस बात पर असर डालते हैं कि 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_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/batzbuild/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/batzbuild/ba बहुत/issues/15684 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_validate_top_level_header_inclusions डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel, टॉप लेवल डायरेक्ट्री हेडर को शामिल किए जाने की पुष्टि भी करेगा. ज़्यादा जानकारी के लिए, https://github.com/ba इमारतोंbuild/ba इमारतों/issues/10047 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--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 टारगेट साफ़ तौर पर 'सार्वजनिक इंपोर्ट' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर बताता है.
टैग: 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 साइनिंग के लिए सर्टिफ़िकेट का नाम. अगर इस नीति को सेट नहीं किया जाता है, तो इसे सेट अप करने के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल पर वापस लाया जाएगा. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक, सर्टिफ़िकेट की कीचेन आइडेंटिटी प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम की (सबस्ट्रिंग) हो सकती है.
टैग: action_command_lines

इस विकल्प से Starlark भाषा के सिमैंटिक या बिल्ड एपीआई के उस वर्शन पर असर पड़ता है जिसे बिल्ड फ़ाइलों, .bzl फ़ाइलों या Workspace फ़ाइलों से ऐक्सेस किया जा सकता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट मौजूद नहीं है, उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग सही है, तो config_setting अन्य सभी नियमों की तरह ही, 'किसको दिखे' लॉजिक का ही पालन करता है. https://github.com/baazbuild/baZZ/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 andobjc_Import में sdk_frameworks और कम ऊर्जा_SDK_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/batzbuild/ba बहुत/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/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

--[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 बार तक चलाए जाएंगे. अगर यह 'डिफ़ॉल्ट' पर सेट है, तो सामान्य जांचों के लिए सिर्फ़ एक बार जांच की जाएगी. वहीं, तीन बार जांच करने की कोशिश की जाएगी, जिसे उनके नियम (फ़्लैकी=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"> डिफ़ॉल्ट: "ऑटो"

एक साथ चलाने के लिए लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. यह एक पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल करता है. इसके बाद, वैकल्पिक रूप से कोई कार्रवाई ([-|*]<float>) ली जाती है, जैसे कि. "auto", "Host_CPUS*.5". 0 का मतलब है कि लोकल रिसॉर्स, एक साथ चलाए जाने के लिए लोकल टेस्ट जॉब की संख्या को सीमित कर देगा. इसे 'नौकरी' के लिए वैल्यू से ज़्यादा सेट करना असर नहीं पड़ता.
टैग: 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. जहां 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 पेयर के ज़रिए पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'baze 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 की वैल्यू से ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने का निर्देश मिलता है.

--test_tmpdir=<a path> डिफ़ॉल्ट: ब्यौरा देखें

यह 'baज़ल टेस्ट' के लिए, बेस अस्थायी डायरेक्ट्री का इस्तेमाल करता है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "सही"

अगर सही है, तो जिन टेस्ट आउटपुट का एलान नहीं किया गया है उन्हें ZIP फ़ाइल में संग्रहित किया जाएगा.
टैग: test_runner

ऐसे विकल्प जो बिल्ड टाइम के ऑप्टिमाइज़ेशन को ट्रिगर करते हैं:

--cache_computed_file_digests=<a long integer> डिफ़ॉल्ट: "50000"

अगर यह 0 से ज़्यादा है, तो फ़ाइलें ज़रूरत के मुताबिक डिस्क से बार-बार मिलने वाले डाइजेस्ट की फिर से गिनती करने के बजाय, Drive में की गई गतिविधि का ब्यौरा आपके मेटाडेटा के आधार पर, मेमोरी में कैश मेमोरी में सेव करने के लिए Baज़ल को कॉन्फ़िगर करती हैं. इसे 0 पर सेट करने से, यह पक्का किया जाता है कि नतीजे सही हों. ऐसा इसलिए, क्योंकि फ़ाइल के मेटाडेटा में किए गए सभी बदलावों को नहीं देखा जा सकता. अगर 0 नहीं है, तो संख्या कैश मेमोरी के साइज़ को दिखाती है, क्योंकि यह संख्या कैश मेमोरी में सेव की जाने वाली फ़ाइलों की संख्या होती है.

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "गलत"

लाइब्रेरीजार में मौजूद किसी भी क्लास को हटाने के लिए, 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 डिफ़ॉल्ट: "सही"

जेर फ़ाइल की हर फ़ाइल की डेक्सिंग के लिए ज़्यादातर काम अलग-अलग किए जाते हैं.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.> डिफ़ॉल्ट: "Host_CPUS"

BZ के लिए उपलब्ध लोकल सीपीयू कोर की कुल संख्या साफ़ तौर पर सेट करें, ताकि उन बिल्ड ऐक्शन पर खर्च किया जा सके जो स्थानीय तौर पर एक्ज़ीक्यूट की जाती हैं. यह एक पूर्णांक या "Host_CPUS" लेता है. इसके बाद, विकल्प के तौर पर [-|*]<float> का इस्तेमाल किया जाता है (उदाहरण के लिए, उपलब्ध CPU कोर का आधा हिस्सा इस्तेमाल करने के लिए Host_CPUS*.5 दबाएं. डिफ़ॉल्ट रूप से, ("Host_CPUS"), Basel, उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
टैग: 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"

Bज़ल के लिए उपलब्ध लोकल होस्ट रैम (एमबी में) की कुल मात्रा साफ़ तौर पर सेट करें, ताकि उसे स्थानीय तौर पर लागू की जाने वाली बिल्ड कार्रवाइयों पर खर्च किया जा सके. यह एक पूर्णांक या "Host_RAM" लेता है. इसके बाद, वैकल्पिक रूप से [-|*]<float> लिया जाता है (उदाहरण के लिए, उपलब्ध रैम की आधी रैम का इस्तेमाल करने के लिए Host_RAM*.5). डिफ़ॉल्ट रूप से, ("Host_RAM*.67"), Baज़र, उपलब्ध रैम का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और उसके 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). अलग-अलग तरह के संसाधनों के बारे में बताने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, Basel की प्रोसेस एक साथ चलने वाली कार्रवाइयों को सीमित करेगी. टेस्ट में "संसाधन:<संसाधन का नाम>:<amount>" फ़ॉर्मैट का टैग इस्तेमाल करके, यह बताया जा सकता है कि उन्हें कितने संसाधनों की ज़रूरत है. --local_{cpu|ram|extra}_resources के ज़रिए बताए गए संसाधनों को बदलता है.
टैग: host_machine_resource_optimizations

--[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

लॉग इन करने के तरीके, फ़ॉर्मैट या जगह पर जानकारी डालने के तरीके पर असर डालने वाले विकल्प:

--[no]experimental_bep_target_summary डिफ़ॉल्ट: "गलत"

टारगेट समरी इवेंट पब्लिश करना है या नहीं.

--[no]experimental_build_event_expand_filesets डिफ़ॉल्ट: "गलत"

अगर सही है, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी में फ़ाइलसेट को बड़ा करें.
टैग: affects_outputs

--[no]experimental_build_event_fully_resolve_fileset_symlinks डिफ़ॉल्ट: "गलत"

अगर सही है, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी में रिलेटिव फ़ाइलसेट सिमलिंक को पूरी तरह से ठीक करें. --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_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_Outputs फ़ील्ड को जनरेट करने की प्रोसेस बंद करने के लिए, इसका इस्तेमाल करें. Basel से स्ट्रटीजस्टोर इंटिग्रेशन के लिए,अहम जानकारी ज़रूरी है.
टैग: 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 'गड़बड़ी' या 'सभी' है. इससे टेस्ट आउटपुट में बहुत ज़्यादा शोर होने से बचने में मदद मिलती है. टेस्ट हेडर, लॉग साइज़ में शामिल होता है. नेगेटिव वैल्यू की कोई सीमा नहीं होती. आउटपुट में सब कुछ या कुछ नहीं होता.
टैग: 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 सेकंड बाद प्रिंट की जाएगी. इसके बाद, हर मिनट में एक बार रिपोर्ट जारी की जाएगी. जब --कर्स चालू होते हैं, तो प्रोग्रेस हर सेकंड रिपोर्ट की जाती है.
टैग: affects_outputs

--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> डिफ़ॉल्ट: "छोटा"

यह टेस्ट की खास जानकारी का पसंदीदा फ़ॉर्मैट तय करता है. मान्य वैल्यू को सिर्फ़ लागू किए गए टेस्ट की जानकारी को प्रिंट करने के लिए 'छोटा', 'ट्रिस', और पूरे न हो चुके टेस्ट के बारे में जानकारी प्रिंट करने के लिए 'ज़्यादा जानकारी', टेस्ट केस के समाधान के बारे में ज़्यादा जानकारी प्रिंट करने के लिए 'ज़्यादा जानकारी', टेस्ट केस के समाधान में जवाब को प्रिंट करने के लिए 'टेस्टकेस', पूरे न होने वाले टेस्ट केस की पूरी जानकारी प्रिंट न करें, और जवाब को शामिल न करने के लिए 'कोई नहीं'.
टैग: terminal_output

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान, डीबग की जानकारी प्रिंट करें. फ़्लैग एक रेगुलर एक्सप्रेशन लेता है. इसकी जांच टूलचेन टाइप और खास टारगेट के आधार पर की जाती है, ताकि यह पता लगाया जा सके कि किसे डीबग करना है. कई रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल है. यह हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए काम का हो.
टैग: terminal_output

--[no]verbose_explanations डिफ़ॉल्ट: "गलत"

अगर 'एक्सप्लेनेशंस' सुविधा चालू है, तो एक्सप्लेनेशंस को ज़्यादा शब्दों में बताया जाता है. अगर --explain चालू नहीं है, तो इसका कोई असर नहीं होता.
टैग: affects_outputs

--[no]verbose_failures डिफ़ॉल्ट: "गलत"

अगर कोई निर्देश काम नहीं करता, तो पूरी कमांड लाइन प्रिंट करें.
टैग: terminal_output

बेज़ल कमांड के लिए, जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--aspects_parameters=<a 'name=value' assignment> बार इस्तेमाल किए गए

कमांड-लाइन आसपेक्ट रेशियो के पैरामीटर की वैल्यू बताता है. हर पैरामीटर का वैल्यू, <param_name>=<param_value> की मदद से तय किया जाता है. उदाहरण के लिए, 'my_param=my_val' जहां 'my_param', --aspects की सूची में मौजूद किसी पहलू का पैरामीटर होता है या सूची में किसी पहलू के लिए ज़रूरी होता है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. हालांकि, एक ही पैरामीटर के लिए एक से ज़्यादा बार वैल्यू असाइन नहीं की जा सकती.
टैग: loading_and_analysis

--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/baazbuild/baZZ/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर सही है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, '-py2' सफ़िक्स वाले आउटपुट रूट में दिखेंगे. वहीं, Python 3 के लिए बनाए गए टारगेट, Python से जुड़े सफ़िक्स के बिना रूट में दिखेंगे. इसका मतलब है कि `bazz-bin` सुविधा सिमलिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. अगर इस विकल्प को चालू किया जाता है, तो हमारा सुझाव है कि `--insupported_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर सही है, तो `py_binary` और `py_test` टारगेट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे PY2 के बजाय डिफ़ॉल्ट रूप से PY3 पर सेट हो जाएंगे. अगर आपने इस फ़्लैग को सेट किया है, तो हमारा सुझाव है कि `--insupported_py2_Outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर लागू किए जा सकने वाले नेटिव Python नियम, --python_top जैसे लेगसी फ़्लैग से मिले रनटाइम के बजाय, Python टूलचेन के बताए गए Python रनटाइम का इस्तेमाल करेंगे, तो वे उसका इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

Python मेजर वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि यह `py_binary` और `py_test` टारगेट से ओवरराइड होता है, भले ही वे किसी वर्शन की जानकारी साफ़ तौर पर न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

--target_pattern_file=<a string> डिफ़ॉल्ट: ""

अगर इसे सेट किया जाता है, तो बिल्ड कमांड लाइन के बजाय, यहां दी गई फ़ाइल के पैटर्न को पढ़ेगा. यहां किसी फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न बताने में भी कोई गड़बड़ी होती है.
टैग: changes_inputs

दूर से कैश मेमोरी में सेव करने और उसे एक्ज़ीक्यूट करने के विकल्प:

--experimental_remote_cache_eviction_retries=<an integer> डिफ़ॉल्ट: "0"

अगर बिल्ड में मौजूद रिमोट कैश मेमोरी को हटाने में कोई गड़बड़ी हुई हो, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. एक गैर-शून्य मान को स्पष्ट रूप से --insupported_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 डिफ़ॉल्ट: "सही"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो अगर बिल्ड के दौरान रिमोट कैश मेमोरी को बाहर कर देती है, तो Baज़ल, 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगा.
टैग: incompatible_change

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--[no]allow_analysis_cache_discard डिफ़ॉल्ट: "सही"

अगर बिल्ड सिस्टम में बदलाव की वजह से विश्लेषण की कैश मेमोरी को खारिज किया जाता है, तो इस विकल्प को 'गलत है' पर सेट करने से, बिल्ड जारी रखने के बजाय बैकल बंद हो जाएगा. '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] डिफ़ॉल्ट: "ऑटो"

अगर Baze को 'ऑटो' पर सेट किया जाता है, तो वह दोबारा टेस्ट तब करता है, जब: (1) Basel को टेस्ट या उसकी डिपेंडेंसी में बदलाव का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया है, (3) --runs_per_test की मदद से एक से ज़्यादा टेस्ट रन का अनुरोध किया गया था या(4) टेस्ट पहले फ़ेल हो गया था. अगर यह 'हां' पर सेट है, तो Basel के टेस्ट के नतीजे, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर सभी को कैश मेमोरी में सेव होते हैं. अगर यह 'नहीं' पर सेट है, तो Baze किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.

--[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_json_file (टेक्स्ट JSON फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_sort (एक्ज़िक्यूशन लॉग क्रम से लगाना है या नहीं), --subcommands (टर्मिनल आउटपुट में सबकमैंड दिखाने के लिए).

--execution_log_json_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें

src/main/protobuf/spawn.proto के मुताबिक, एक्ज़ीक्यूट किए गए स्पॉन्स को इस फ़ाइल में, SpwnSequence प्रोटो के न्यूलाइन-डीलिमिटेड JSON प्रज़ेंटेशन के तौर पर लॉग करें. संबंधित फ़्लैग: --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_execution_log_compact_file=<a path> डिफ़ॉल्ट: ब्यौरा देखें

इस फ़ाइल में, जो स्पॉन्स किए गए हैं उन्हें src/main/protobuf/spawn.proto के मुताबिक, लंबे समय से सीमांकित exeLogEntry प्रोटोकॉल के तौर पर लॉग करें. पूरी फ़ाइल को zstd कंप्रेस किया गया है. यह फ़ॉर्मैट एक्सपेरिमेंट के तौर पर उपलब्ध है. इस पर अभी काम चल रहा है. इसे किसी भी समय बदला जा सकता है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (बाइनरी प्रोटोबफ़ फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --execution_log_json_file (टेक्स्ट JSON फ़ॉर्मैट; म्यूचुअली एक्सक्लूसिव), --subcommands (टर्मिनल आउटपुट में सबकमैंड दिखाने के लिए).

--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: ""

पक्षों के पहलुओं को प्राथमिकता दी जाती है. टारगेट के सेट के फ़िल्टर जिनके लिए extra_action शेड्यूल करने हैं.

--[no]experimental_extra_action_top_level_only डिफ़ॉल्ट: "गलत"

पक्षों के पहलुओं को प्राथमिकता दी जाती है. टॉप लेवल टारगेट के लिए सिर्फ़ extra_action शेड्यूल करता है.

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत"

अगर सही है, तो Bagel, कवरेज रन के दौरान हर टेस्ट के लिए, कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: 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 डिफ़ॉल्ट: "गलत"

यह सुविधा सिर्फ़ Android-साथ काम करने वाली लाइब्रेरी तक उपलब्ध है.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

गलती से TestRunner के Deps से जानकारी पाने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी के बारे में साफ़ तौर पर बताएं. फ़िलहाल, यह सुविधा सिर्फ़ बेज़ल के लिए काम करती है.

--[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 में मौजूद पाथ पर फ़ाइल को टच करके शार्डिंग की सुविधा देता है, तो Baज़ल, शार्ड टेस्ट में फ़ेल हो जाएगा. गलत होने पर, शार्ड का समर्थन नहीं करने वाले टेस्ट रनर से हर शार्ड में सभी टेस्ट चल जाएंगे.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर सही है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ किए जाएंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता है. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान रखें कि ऐसा करने से, शेयर की गई कैश मेमोरी का इस्तेमाल करने पर क्रॉस-यूज़र कैशिंग में रुकावट आएगी.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> बार इस्तेमाल किए गए

J2ObjC टूल को पास करने के लिए अन्य विकल्प.

--java_debug

जावा टेस्ट की Java वर्चुअल मशीन को अनुमति देता है, ताकि टेस्ट शुरू करने से पहले, JDWP के नियमों का पालन करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार किया जा सके. इसमें -test_Output=streamed का इस्तेमाल हुआ है.
इसे बड़ा किया जाएगा:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps डिफ़ॉल्ट: "सही"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (अभी के लिए, कंपाइल-टाइम क्लासपाथ) जनरेट करें.

--[no]java_header_compilation डिफ़ॉल्ट: "सही"

सीधे सोर्स से इजर कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर यह फ़्लैग खाली स्ट्रिंग पर सेट है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> बार इस्तेमाल किए गए

javac को पास करने के लिए अतिरिक्त विकल्प.

--jvmopt=<a string> बार इस्तेमाल किए गए

Java वीएम को पास करने के लिए दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह उन क्लास की सूची जनरेट करने के लिए एक बाइनरी के बारे में बताता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.

--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> डिफ़ॉल्ट: "@bazu_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> का डिफ़ॉल्ट अनुवाद: "@bagel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल जो j2objc protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bagel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल जो Java प्रोटो को इकट्ठा करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@baaz_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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो कोई भी शार्ड जिसमें कम से कम एक दौड़ या कोशिश फ़ेल हो जाती है उसे 'फ़्लैकी' स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

बेज़ल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल, पहले Basel के बोले जाने पर शुरू करने वाले टूल (जिससे Baज़र सर्वर शुरू होता है) पर सेट है, Baze इसका इस्तेमाल करता है. यदि दोनों में से कोई भी सेट नहीं है, तो Ba जानना, आपके द्वारा चलाए जाने वाले ऑपरेटिंग सिस्टम के आधार पर हार्ड कोड किए गए डिफ़ॉल्ट पथ का उपयोग करता है (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> बार इस्तेमाल किए गए

ऐसे अतिरिक्त विकल्प और आर्ग्युमेंट बनाती है जिन्हें टेस्ट के लिए लागू किया जा सकने वाला टेस्ट पास किया जाना चाहिए. कई आर्ग्युमेंट के बारे में बताने के लिए, इसका इस्तेमाल एक से ज़्यादा बार किया जा सकता है. अगर कई जांच की जाती हैं, तो उनमें से हर एक को एक जैसे तर्क मिलेंगे. इसका इस्तेमाल सिर्फ़ 'baze 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> डिफ़ॉल्ट: "अश्लील"

टेस्ट शार्डिंग के लिए रणनीति तय करें: 'शर्डिंग' एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब शार्डिंग का इस्तेमाल किया जा रहा हो. 'अक्षम' है. '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_timeout_filters=<comma-separated list of values: short, moderate, long or eternal> डिफ़ॉल्ट: ""

यह, टेस्ट टाइम आउट की ऐसी सूची के बारे में बताती है जिसे कॉमा लगाकर अलग किया गया है. बाहर रखे गए टाइम आउट तय करने के लिए, हर टाइम आउट से पहले वैकल्पिक तौर पर '-' का इस्तेमाल किया जा सकता है. केवल वही परीक्षण लक्ष्य मिलेंगे, जिनमें कम से कम एक टाइमआउट शामिल किया गया हो और उसमें कोई भी बहिष्कृत टाइमआउट शामिल न हो. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.

--tool_java_language_version=<a string> डिफ़ॉल्ट: ""

Java लैंग्वेज वर्शन, जिसका इस्तेमाल ऐसे टूल को एक्ज़ीक्यूट करने के लिए किया जाता है जो बिल्ड के दौरान ज़रूरी होते हैं

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो इस विकल्प की वजह से Java को कंपाइल करने में इंटरफ़ेस जार का इस्तेमाल होता है. इससे तेज़ी से कंपाइलेशन होगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

कैननिकल फ़्लैग वाले विकल्प

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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_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/baazbuild/baZZ/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/batzbuild/ba बहुत/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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--experimental_resolved_file_instead_of_workspace=<a string> डिफ़ॉल्ट: ""

अगर खाली नहीं है, तो Workspace फ़ाइल के बजाय हल की गई फ़ाइल को पढ़ें
टैग: changes_inputs

--for_command=<a string> डिफ़ॉल्ट: "बिल्ड"

वह निर्देश जिसके लिए विकल्पों को कैननिकल किया जाना चाहिए.
टैग: affects_outputs, terminal_output

--invocation_policy=<a string> डिफ़ॉल्ट: ""

कैननिकल किए जाने वाले विकल्पों पर अनुरोध करने की नीति लागू होती है.
टैग: affects_outputs, terminal_output

कैश मेमोरी में सेव करने और उसे एक्ज़ीक्यूट करने के विकल्प:

--experimental_downloader_config=<a string> डिफ़ॉल्ट: ब्यौरा देखें

वह फ़ाइल तय करें जिससे रिमोट डाउनलोडर को कॉन्फ़िगर करना है. इस फ़ाइल में पंक्तियां होती हैं, जिनमें से हर एक निर्देश (`allow`, `block` या `rewrite` से शुरू होता है) के बाद एक होस्ट नाम (`allow` और `block` के लिए) या दो पैटर्न होते हैं, एक को मिलान करने के लिए, और दूसरे को `$1` से शुरू होने वाले बैक-रेफ़रंस यूआरएल के रूप में. एक ही यूआरएल के लिए एक से ज़्यादा `रीराइट` डायरेक्टिव दिए जा सकते हैं. इस मामले में, एक से ज़्यादा यूआरएल दिए जा सकते हैं.

--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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ोल्डर` का आउटपुट होता है

--package_path=<colon-separated list of options> डिफ़ॉल्ट: "%workspace%"

पैकेज की खोज करने की जगह की कोलन लगाकर अलग की गई सूची. '%workspace%' से शुरू होने वाले एलिमेंट, पास के फ़ाइल फ़ोल्डर के मिलते-जुलते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी के लिए डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

साफ़ करने के विकल्प

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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:

--[no]async डिफ़ॉल्ट: "गलत"

अगर सही है, तो आउटपुट को हटाने की प्रोसेस एसिंक्रोनस होती है. इस निर्देश के पूरा होने के बाद, एक ही क्लाइंट में नए निर्देशों को लागू करना सुरक्षित रहेगा. भले ही, बैकग्राउंड में इन्हें मिटाने का काम जारी रहे.
टैग: host_machine_resource_optimizations

--[no]expunge डिफ़ॉल्ट: "गलत"

अगर सही है, तो 'क्लीन करें' इस 'बेज़ल' इंस्टेंस के लिए, काम करने वाले पूरे ट्री को हटा देता है. इसमें, बाज़ से बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर बेज़ल सर्वर चल रहा है, तो वह रुक भी जाता है.
टैग: host_machine_resource_optimizations

--expunge_async

अगर साफ़ तौर पर बताया गया है, तो एसिंक्रोनस तरीके से एसिंक्रोनस तरीके से, इस बेज़ल इंस्टेंस के लिए काम करने वाले पूरे ट्री को हटा देता है. इसमें, बैज से बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर बेज़ल सर्वर चल रहा है, तो यह उसे भी बंद कर देता है. इस निर्देश के पूरा होने के बाद, एक ही क्लाइंट में नए निर्देशों को लागू करना सुरक्षित रहेगा. भले ही, बैकग्राउंड में इन्हें मिटाने का काम जारी रहे.
इसमें बड़ा किया गया है:
  --expunge
  --async

टैग: 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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव"

जब आउटपुट फ़ॉर्मैट, {xml,proto,record} में से एक हो, तो आसपेक्ट रेशियो पर निर्भरता को कैसे ठीक करें. 'बंद' का मतलब है कि किसी आसपेक्ट डिपेंडेंसी की समस्या हल नहीं हुई. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान की गई सभी आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) डिपेंडेंसी को सीधे तौर पर डिपेंडेंसी की नियम क्लास दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वे पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से ऐक्टिव हैं. ध्यान दें कि सटीक मोड को एक ही टारगेट का आकलन करने के लिए, अन्य पैकेज लोड करने की ज़रूरत होती है. इस तरह, यह अन्य मोड के मुकाबले धीमा हो जाता है. इस बात पर भी ध्यान दें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. हालांकि, 'बेज़ल क्वेरी' के दौरान यह फ़ैसला नहीं लिया जाता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से ऐसा लेबल दिखता है जैसे <code>लेबल</code> के इंस्टेंस पर लागू किया गया Starlark <code>str</code> फ़ंक्शन हो. यह उन टूल के लिए काम का है जिन्हें क्वेरी के अलग-अलग निर्देशों और/या नियमों से जनरेट होने वाले लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इस नीति को चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैट करने वाले लोग, डेटा स्टोर करने की मुख्य जगह के नाम (डेटा स्टोर करने की मुख्य जगह के बजाय) का इस्तेमाल कर सकते हैं. इससे आउटपुट को पढ़ने में आसानी होती है.
टैग: terminal_output

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत"

aquery, cquery: क्या आउटपुट में आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से जनरेट की गई कार्रवाइयों को शामिल करना है. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि जगह के हिसाब से सटीक नोड को एक साथ मर्ज कर दिया जाएगा और उनके लेबल जोड़ दिए जाएंगे. यह विकल्प केवल --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की अधिकतम लंबाई. बड़े लेबल छोटे किए जाएंगे; -1 का मतलब है कि काट-छांट नहीं की जाएगी. यह विकल्प केवल --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी काम करती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर तय नहीं किया गया है, लेकिन उसे बैजल से जोड़ा गया है. क्वेरी के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग: 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 की वैल्यू का अनुमान लगाया जाएगा. ध्यान दें, ऐसा हो सकता है कि यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे कि`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> डिफ़ॉल्ट: "लेबल"

वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: Label, label_ kind, textproto, ट्रांज़िशन, प्रोटोकॉल, स् ट्रीम किया गया प्रोटो, jsonproto. अगर 'transitions' को चुना जाता है, तो आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू, बिल्ड फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --आउटपुट=प्रोटो
टैग पर लागू होता है: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

डेफ़िनिशन_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> डिफ़ॉल्ट: "सभी"

आउटपुट में शामिल करने के लिए एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, सभी एट्रिब्यूट का इस्तेमाल किया जाता है. किसी भी एट्रिब्यूट का आउटपुट देने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

नियम_इनपुट और नियम_आउटपुट फ़ील्ड भरने या न भरने की जानकारी.
टैग: 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> डिफ़ॉल्ट: ""

स्टारलार्क फ़ंक्शन को तय करने वाली फ़ाइल का नाम, जिसे एक आर्ग्युमेंट का फ़ॉर्मैट 'फ़ॉर्मैट' कहा जाता है. यह आर्ग्युमेंट, कॉन्फ़िगर किए गए हर टारगेट पर लागू होता है, ताकि उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जा सके. --starlark:expr और --starlark:file, दोनों को तय करने में गड़बड़ी होती है. अतिरिक्त जानकारी के लिए --आउटपुट=starlark के लिए सहायता देखें.
टैग: terminal_output

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: यह विकल्प बंद होने पर, 'एक्ज़िक कॉन्फ़िगरेशन' की डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाएगा जिस पर क्वेरी काम करती है. 'एक्ज़िक कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर भेजा जाता है. आम तौर पर, यह उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल की ओर इशारा करता है. Cquery: यह सुविधा बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर दिया जाता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप-लेवल टारगेट की तुलना में, एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. ये वे टारगेट भी होंगे जो टारगेट कॉन्फ़िगरेशन में शामिल हैं. अगर टॉप लेवल टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ लागू किए गए कॉन्फ़िगर किए गए टारगेट ही लौटाए जाएंगे. इस विकल्प में उन टूलचेन को शामिल नहीं किया जाएगा जिन्हें हल किया जा चुका है.
टैग: build_file_semantics

--transitions=<full, lite or none> डिफ़ॉल्ट: "कोई नहीं"

वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगी.
टैग: affects_outputs

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ और घटाव). यह क्वेरी, बताए गए टारगेट के ट्रांज़िटिव क्लोज़िंग से तय किए गए ब्रह्मांड में की जा सकती है. इस विकल्प का इस्तेमाल क्वेरी और क्वेरी कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वह टारगेट है जिसके तहत सभी जवाबों को बनाया गया है. इसलिए, इस विकल्प से कॉन्फ़िगरेशन और ट्रांज़िशन पर असर पड़ सकता है. अगर इस विकल्प की जानकारी नहीं दी गई है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माना जाता है. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ बनाए नहीं जा सकते हैं, तो इस विकल्प को न बताने पर, बिल्ड टूट सकता है.
टैग: loading_and_analysis

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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baज़ल की जानकारी Workspace` का आउटपुट होता है

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो Bagel नए स्पॉन्स में टेस्ट के लिए, कवरेज पोस्टप्रोसेसिंग चलाएगा.
टैग: execution

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को चालू किया जाता है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलें मानेंगे. वे डायरेक्ट्री में रुकावट नहीं डालेंगी या सिमलिंक के प्रति संवेदनशील नहीं होंगी.
टैग: execution

--[no]incompatible_disallow_unsound_directory_outputs डिफ़ॉल्ट: "सही"

अगर यह नीति सेट की जाती है, तो आउटपुट फ़ाइल को डायरेक्ट्री के तौर पर सेट करने से जुड़ी कार्रवाई में गड़बड़ी होती है. सोर्स डायरेक्ट्री पर असर नहीं पड़ता. https://github.com/bagelbuild/baकोई का इस्तेमाल करने के लिए 18646 पर जाएं.
टैग: bazel_internal_configuration, incompatible_change

--[no]incompatible_modify_execution_info_additive डिफ़ॉल्ट: "गलत"

इसे चालू करने पर, एक से ज़्यादा --modify_execution_info फ़्लैग को पास करना आसान नहीं होता. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग पर ध्यान दिया जाता है.
टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> बार इस्तेमाल किए गए

किसी कार्रवाई की याद दिलाने वाली जानकारी के आधार पर, किसी कार्रवाई को लागू करने की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो एक्ज़ीक्यूशन की जानकारी के साथ काम करती हैं. कई सामान्य ऐक्शन, एक्ज़ीक्यूशन की जानकारी के साथ काम करते हैं. उदाहरण के लिए, Gen बचाने, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. इसकी वजह यह है कि एक ही याद दिलाने वाले तरीके पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "रेगुलर एक्सप्रेशन=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों को लागू करने की जानकारी में 'x' और 'z' को जोड़ता है और उससे 'y' को हटाता है. 'Genral=+requires-x', सभी जेनरल ऐक्शन के लिए, एक्ज़ीक्यूशन की जानकारी में 'ज़रूरी-x' जोड़ता है. '(?!Genregular).*=-requires-x' सभी गैर-सामान्य कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से 'ज़रूरी-x' को हटा देता है.
टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

कर्मचारियों का इस्तेमाल करके, Android dex और डीशुगर कार्रवाइयों को लगातार चालू करें.
इसे बड़ा किया जाता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

कर्मचारियों का इस्तेमाल करके, Android के स्थायी संसाधन प्रोसेसर को चालू करें.
इसे:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker

{14//} टैग करें



--strategy=Aapt2Optimize=worker--strategy=AARGenerator=worker--strategy=ProcessDatabinding=worker--strategy=GenerateDataBindingBaseClasses=workerhost_machine_resource_optimizationsexecution

--persistent_multiplex_android_dex_desugar

कर्मचारियों का इस्तेमाल करके, Android dex और desugar की स्थायी कार्रवाइयां चालू करें.
इसे बड़ा किया जाता है:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android संसाधन प्रोसेसर को चालू करें.
इनकी ओर से:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workersटैग करें

{14 --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workersटैग करें
5}{14
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers--modify_execution_info=AARGenerator=+supports-multiplex-workershost_machine_resource_optimizationsexecution

--persistent_multiplex_android_tools

Android के स्थायी और मल्टीप्लेक्स टूल (डेक्सिंग, डियूगरिंग, और रिसॉर्स प्रोसेसिंग) चालू करें.
इसे बड़ा किया जाता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "गलत"

अगर सही है, तो Baze, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा, न कि टेस्ट एक्ज़ेक्यूटिव ग्रुप का.
टैग: execution

ऐसे विकल्प जो कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करते हैं:

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_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> डिफ़ॉल्ट: "@bagel_tools//tools/android:sdk"

Android SDK/प्लैटफ़ॉर्म के बारे में जानकारी देता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazu_tools//tools/cpp:toolchain"

Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट को कंपाइल करने के लिए, C++ कंपाइलर का इस्तेमाल करें.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> का डिफ़ॉल्ट मैसेज: "@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> डिफ़ॉल्ट: "@bazu_tools//tools/cpp:toolchain"

C++ कोड को कंपाइल करने के लिए इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कस्टम मैलक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में मैलक एट्रिब्यूट को बदल देती है.
टैग: 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 के हर ऐक्शन के लिए "ज़रूरी-xcode:{version}" लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "ज़रूरी-xcode-label:{version_label}" लागू करने की शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution

--[no]experimental_prefer_mutual_xcode डिफ़ॉल्ट: "सही"

अगर सही है, तो सबसे नए Xcode का इस्तेमाल करें. यह Xcode स्थानीय तौर पर और कहीं से भी उपलब्ध है. अगर गलत है या कोई म्युचुअल उपलब्ध वर्शन नहीं है, तो xcode-select के ज़रिए चुने गए लोकल Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state

--extra_execution_platforms=<comma-separated list of options> डिफ़ॉल्ट: ""

ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म, टारगेट के हिसाब से या टारगेट पैटर्न के तौर पर तय किए जा सकते हैं. इन प्लैटफ़ॉर्म पर उन प्लैटफ़ॉर्म का इस्तेमाल करने से पहले विचार किया जाएगा जिनका एलान Workspace फ़ाइल में रजिस्टर_execution_platforms() के ज़रिए किया गया है. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है; बाद के इंस्टेंस पहले फ़्लैग की सेटिंग को बदल देंगे.
टैग: execution

--extra_toolchains=<comma-separated list of options> बार इस्तेमाल किए गए

टूलचेन के रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों पर ध्यान दिया जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन पर विचार किया जाएगा, ताकि उन टूलचेन पर विचार किया जा सके जिनका एलान workspace_toolchains() से किया गया हो.
टैग: 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 और --कंपाइलर विकल्पों का इस्तेमाल, एक्ज़ीक्यूट कॉन्फ़िगरेशन के लिए भी किया जाता है. अगर यह फ़्लैग दिया जाता है, तो Ba बैंक, दिए गए 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> डिफ़ॉल्ट: "@ba"_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/batzbuild/ba इमारतों/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 डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel, lto को इंडेक्स करने वाली कमांड लाइन के लिए C++ लिंक ऐक्शन कमांड लाइन का दोबारा इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazubuild/baZ/issues/6791 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive डिफ़ॉल्ट: "सही"

अगर सही है, तो Baज़र, लाइब्रेरी डिपेंडेंसी को डिफ़ॉल्ट रूप से पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazibuild/bagel/issues/7362 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_require_ctx_in_configure_features डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel को cc_common.Configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba बहुत/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 टारगेट चलाने के लिए इस्तेमाल किया जाता है. बहिष्कृत; --insupported_use_python_toolchains की मदद से बंद किया गया है.
टैग: loading_and_analysis, affects_outputs

--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python अनुवादक को दिखाने वाले py_runtime का लेबल. बहिष्कृत; --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' से वॉचओएस SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें

अगर ऐसा है, तो बिल्ड से जुड़ी सही कार्रवाइयों के लिए दिए गए वर्शन के Xcode का इस्तेमाल किया जाता है. अगर जानकारी नहीं है, तो Xcode के एक्ज़ेक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग: loses_incremental_state

--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bagel_tools//tools/cpp:host_xcodes"

बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए, इस्तेमाल किया जाने वाला xcode_config नियम का लेबल.
टैग: loses_incremental_state, loading_and_analysis

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत"

डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग: affects_outputs, action_command_lines

--[no]build_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 एपीआई वर्शन के लिए ज़्यादा कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत"

कंपाइलेशन के आउटपुट के तौर पर, चालू और अनुरोध की गई सुविधाओं की स्थिति को सेव करें.
टैग: affects_outputs, experimental

--fission=<a set of compilation modes> डिफ़ॉल्ट: "नहीं"

इससे पता चलता है कि C++ कंपाइलेशन और लिंक के लिए, किस कंपाइलेशन मोड का इस्तेमाल किया जा रहा है. सभी मोड को सक्षम करने के लिए {'Fastbuild', 'dbg', 'opt'} या विशेष मानों का कोई भी संयोजन हो सकता है और सभी मोड को अक्षम करने के लिए 'no' का संयोजन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही"

अगर नेटिव नियम सही हैं, तो नेटिव नियमों की मदद से, रनफ़ाइल में डेटा डिपेंडेंसी के लिए <code>DefaultInfo.files</code> जुड़ जाता है. यह तरीका Starlark के नियमों (https://bazz.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 डेटाबाइंडिंग 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> डिफ़ॉल्ट: "वर्णमाला"

यह नीति, Android बाइनरी के लिए मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करती है. ऐल्फ़ाबेट का मतलब है कि मेनिफ़ेस्ट को एक्ज़ीक्यूटेबल के मुकाबले पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में मौजूद कॉन्फ़िगरेशन डायरेक्ट्री के पाथ के हिसाब से क्रम में लगाया जाता है. डिपेंडेंसी का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसी क्रम में रखा जाता है जो उसके डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]build_python_zip डिफ़ॉल्ट: "ऑटो"

python की एक्ज़ीक्यूटेबल ZIP फ़ाइल बनाएं; Windows पर, अन्य प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs

--catalyst_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

कॉमा से अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple Catपाल बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "गलत"

अगर सूचना दी जाती है, तो Baज़र, इंस्ट्रुमेंट कोड का इस्तेमाल करेगा (जहां संभव हो ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ --instrumentation_filter से मेल खाने वाले टारगेट ही प्रभावित होंगे. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताना चाहिए - इसके बजाय, 'bazu दूरी' निर्देश का इस्तेमाल करना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "फ़ास्टबिल्ड"

वह मोड बताएं जिसमें बाइनरी बनाई जाएगी. मान: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--conlyopt=<a string> बार इस्तेमाल किए गए

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> बार इस्तेमाल किए गए

जीसीसी को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई एलएलवीएम प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का ऐब्सलूट पाथ बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंट की बाइनरी जनरेट करना. Clang/LLVM कंपाइलर की मदद से, यह डायरेक्ट्री का नाम भी स्वीकार करता है. इसके तहत, रनटाइम के दौरान, रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को डंप किया जाएगा.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली कॉन्टेक्स्ट सेंसिटिव प्रोफ़ाइल को दिखाने वाली cs_fdo_profile.
टैग: affects_outputs

--cxxopt=<a string> बार इस्तेमाल किए गए

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> बार इस्तेमाल किए गए

--इसके लिए तय किया गया हर विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "डिफ़ॉल्ट"

यह तय करता है कि C++ बाइनरी को डाइनैमिक रूप से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Basel को यह चुनना होगा कि उसे डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी' का मतलब है कि सभी लाइब्रेरी डायनैमिक रूप से लिंक कर दी जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्थिर मोड में लिंक की जाएंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह नीति सेट की जाती है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी दिखेगी.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "ऑटो"

रनफ़ाइल सिमलिंक ट्री चालू करें. डिफ़ॉल्ट रूप से, यह Windows में दूसरे प्लैटफ़ॉर्म पर बंद रहती है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> बार इस्तेमाल किए गए

पक्षों के पहलुओं को प्राथमिकता दी जाती है. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में 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 APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत"

dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत"

अगर साफ़ तौर पर बताया गया है, तो 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/bazibuild/baZZ/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> बार इस्तेमाल किए गए

हर एंट्री फ़ॉर्म में लेबल=वैल्यू के तौर पर होनी चाहिए. यहां लेबल किसी प्लैटफ़ॉर्म के बारे में बताता है. साथ ही, आउटपुट पाथ में इस्तेमाल करने के लिए, वैल्यू एक छोटा नाम होना चाहिए. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_Output_किन सही है. नाम रखने की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत"

अगर सही है, तो टारगेट प्लैटफ़ॉर्म के छोटे नाम का इस्तेमाल, सीपीयू के बजाय आउटपुट डायरेक्ट्री के नाम में किया जाता है. सटीक स्कीम प्रयोग के तौर पर है और इसमें बदलाव हो सकते हैं: पहला, बहुत ही कम मामलों में --प्लैटफ़ॉर्म विकल्प में सिर्फ़ एक वैल्यू नहीं होती, इसलिए प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए किसी छोटे नाम को --experimental_override_name_platform_in_Output_ ख़िलाफ़ ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_Output_ इससे_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_किन फ़ंक्शन पर भरोसा करने पर माइग्रेट करें.
टैग: 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 फ़ाइल या एलएलवीएम प्रोफ़ाइल फ़ाइल हो. इस फ़्लैग में लेबल के तौर पर दी गई फ़ाइलें (जैसे कि `//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> डिफ़ॉल्ट: "ऑप्ट करें"

वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल पहले से मौजूद होंगे. मान: '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> बार इस्तेमाल किए गए

यहां दी गई सुविधाएं, एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> के बारे में बताने से सुविधा बंद हो जाएगी. नेगेटिव सुविधाएं, हमेशा पॉज़िटिव वैल्यू को ओवरराइड कर देती हैं.
टैग: changes_inputs, affects_outputs

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

exec कॉन्फ़िगरेशन के लिए, Python वर्शन को बदलता है. यह "PY2" या "PY3" हो सकता है.
टैग: loading_and_analysis, affects_outputs

--host_linkopt=<a string> बार इस्तेमाल किए गए

एक्ज़िक कॉन्फ़िगरेशन में टूल जोड़ते समय, लिंकर को भेजने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, कम से कम काम करने वाला macOS वर्शन. अगर जानकारी नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> बार इस्तेमाल किए गए

एक्ज़ीक्यूटिव कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के अन्य विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर रखने की सूची दिखाता है (यह भी देखें --instrumentation_filter). option_1 से option_n का मतलब, आर्बिट्रेरी कमांड लाइन विकल्पों के लिए है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में बार.cc को छोड़कर, सभी cc फ़ाइलों की cc कमांड लाइन में -O0 कमांड लाइन का विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--host_swiftcopt=<a string> बार इस्तेमाल किए गए

एक्ज़ीक्यूटिव टूल के लिए swiftc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "गलत"

चालू होने पर, किसी नियम में इस्तेमाल होने वाले हर टूलचेन के लिए एक्ज़ेक्यूटिव ग्रुप अपने-आप बन जाता है. इसके काम करने के लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazibuild/bagel/issues/17134 देखें.
टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही"

अगर सही है, तो जेनफ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_use_host_features डिफ़ॉल्ट: "सही"

अगर सही है, तो --सुविधा का इस्तेमाल सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए करें और --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "गलत"

कवरेज की सुविधा चालू होने पर, यह तय किया जाता है कि टेस्ट के नियमों को लागू किया जाए या नहीं. सेट होने पर, --instrumentation_filter पर शामिल किए गए टेस्ट नियम इंस्ट्रुमेंट किए जाते हैं. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रुमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/javatests[/:],-/test/java[/:]"

कवरेज चालू होने पर, सिर्फ़ खास रेगुलर एक्सप्रेशन-आधारित फ़िल्टर में शामिल नामों वाले नियम ही लागू किए जाएंगे. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि जब तक --instrument_test_targets को चालू नहीं किया जाता, तब तक सिर्फ़ नॉन-टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है.
टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के साथ काम करने वाला कम से कम iOS वर्शन. अगर तय नहीं है, तो 'ios_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--ios_multi_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

iOS_ऐप्लिकेशन का इस्तेमाल करके, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें सभी खास आर्किटेक्चर शामिल हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive डिफ़ॉल्ट: "सही"

अब काम नहीं करता, --inबेमेल_remove_legacy_whole_archive (ज़्यादा जानकारी के लिए, https://github.com/ba आवाज़ोंbuild/baZ/issues/7362 पर जाएं) पर जाएं. इसे चालू होने पर, cc_binary नियमों के लिए -पूरा-संग्रह का इस्तेमाल करें, जिसमें linkshared=True होता है और linkopts में linkstatic=True या '-static' होता है. यह सुविधा सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर,Alwayslink=1 का इस्तेमाल करना एक बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> बार इस्तेमाल किए गए

लिंक करते समय, जीसीसी में भेजने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> बार इस्तेमाल किए गए

एलटीओ बैकएंड चरण को पास करने के लिए एक और विकल्प (-features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> बार इस्तेमाल किए गए

एलटीओ इंडेक्स करने के चरण को पास करने का एक और विकल्प (-features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple macOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, कम से कम macOS का वर्शन होना चाहिए. अगर जानकारी नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "गलत"

अगर सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS के बारे में बताएं.
टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर इस फ़्लैग और --compilation_mode=opt, दोनों के बारे में बताया गया है, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

--objccopt=<a string> बार इस्तेमाल किए गए

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> बार इस्तेमाल किए गए

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तरीके से पास करने के लिए अन्य विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर रखने की सूची दिखाता है (यह भी देखें --instrumentation_filter). option_1 से option_n का मतलब, आर्बिट्रेरी कमांड लाइन विकल्पों के लिए है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //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> बार इस्तेमाल किए गए

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड ( --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:prop इंतज़ार_Optimize( name = "prop Tager_profile", cc_profile = "prop सूचनाएं_cc_profile.txt", ld_profile = "prop मुझे_ld_profile.txt" में लेबल को लेबल करते हैं. इससे जुड़े पैकेज में export_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है, ताकि ये फ़ाइलें बेज़ेल में दिखें. इस विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --प्रॉपेलर_ऑप्टिमाइज़=//a/b:prop मॉडल_profile
टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए, ld_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

'टेस्ट' और 'रन' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले प्रीफ़िक्स का इस्तेमाल करें. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो आखिरी कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

--[no]share_native_deps डिफ़ॉल्ट: "सही"

अगर सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट में शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "गलत"

तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह के साथ स्टैंप बाइनरी.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं ("-Wl,--strip-debug" का इस्तेमाल करना). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब स्ट्रिप iff --compilation_mode=fastbuild है.
टैग: affects_outputs

--stripopt=<a string> बार इस्तेमाल किए गए

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--swiftcopt=<a string> बार इस्तेमाल किए गए

स्विफ़्ट के कंपाइलेशन का इस्तेमाल करने के दूसरे विकल्प.
टैग: action_command_lines

--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

ऐसे विकल्प जो इस बात पर असर डालते हैं कि 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_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/batzbuild/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/batzbuild/ba बहुत/issues/15684 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_validate_top_level_header_inclusions डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel, टॉप लेवल डायरेक्ट्री हेडर को शामिल किए जाने की पुष्टि भी करेगा. ज़्यादा जानकारी के लिए, https://github.com/ba इमारतोंbuild/ba इमारतों/issues/10047 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--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 टारगेट साफ़ तौर पर 'सार्वजनिक इंपोर्ट' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर बताता है.
टैग: 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 साइनिंग के लिए सर्टिफ़िकेट का नाम. अगर इस नीति को सेट नहीं किया जाता है, तो इसे सेट अप करने के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल पर वापस लाया जाएगा. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक, सर्टिफ़िकेट की कीचेन आइडेंटिटी प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम की (सबस्ट्रिंग) हो सकती है.
टैग: action_command_lines

इस विकल्प से Starlark भाषा के सिमैंटिक या बिल्ड एपीआई के उस वर्शन पर असर पड़ता है जिसे बिल्ड फ़ाइलों, .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 में हमेशा लिंक एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही बनाएं.
टैग: 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> (उदाहरण के लिए,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 पेयर के ज़रिए पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'baze 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} में से एक हो, तो आसपेक्ट रेशियो पर निर्भरता को कैसे ठीक करें. 'बंद' का मतलब है कि किसी आसपेक्ट डिपेंडेंसी की समस्या हल नहीं हुई. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान की गई सभी आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) डिपेंडेंसी को सीधे तौर पर डिपेंडेंसी की नियम क्लास दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वे पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से ऐक्टिव हैं. ध्यान दें कि सटीक मोड को एक ही टारगेट का आकलन करने के लिए, अन्य पैकेज लोड करने की ज़रूरत होती है. इस तरह, यह अन्य मोड के मुकाबले धीमा हो जाता है. इस बात पर भी ध्यान दें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. हालांकि, 'बेज़ल क्वेरी' के दौरान यह फ़ैसला नहीं लिया जाता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से ऐसा लेबल दिखता है जैसे <code>लेबल</code> के इंस्टेंस पर लागू किया गया Starlark <code>str</code> फ़ंक्शन हो. यह उन टूल के लिए काम का है जिन्हें क्वेरी के अलग-अलग निर्देशों और/या नियमों से जनरेट होने वाले लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इस नीति को चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैट करने वाले लोग, डेटा स्टोर करने की मुख्य जगह के नाम (डेटा स्टोर करने की मुख्य जगह के बजाय) का इस्तेमाल कर सकते हैं. इससे आउटपुट को पढ़ने में आसानी होती है.
टैग: terminal_output

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत"

aquery, cquery: क्या आउटपुट में आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से जनरेट की गई कार्रवाइयों को शामिल करना है. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि जगह के हिसाब से सटीक नोड को एक साथ मर्ज कर दिया जाएगा और उनके लेबल जोड़ दिए जाएंगे. यह विकल्प केवल --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की अधिकतम लंबाई. बड़े लेबल छोटे किए जाएंगे; -1 का मतलब है कि काट-छांट नहीं की जाएगी. यह विकल्प केवल --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी काम करती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर तय नहीं किया गया है, लेकिन उसे बैजल से जोड़ा गया है. क्वेरी के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग: 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 की वैल्यू का अनुमान लगाया जाएगा. ध्यान दें, ऐसा हो सकता है कि यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे कि`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> डिफ़ॉल्ट: "लेबल"

वह फ़ॉर्मैट जिसमें cquery के नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: Label, label_ kind, textproto, ट्रांज़िशन, प्रोटोकॉल, स् ट्रीम किया गया प्रोटो, jsonproto. अगर 'transitions' को चुना जाता है, तो आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू, बिल्ड फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --आउटपुट=प्रोटो
टैग पर लागू होता है: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

डेफ़िनिशन_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> डिफ़ॉल्ट: "सभी"

आउटपुट में शामिल करने के लिए एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, सभी एट्रिब्यूट का इस्तेमाल किया जाता है. किसी भी एट्रिब्यूट का आउटपुट देने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प --आउटपुट=प्रोटो पर लागू होता है.
टैग: terminal_output

--[no]proto:rule_inputs_and_outputs डिफ़ॉल्ट: "सही"

नियम_इनपुट और नियम_आउटपुट फ़ील्ड भरने या न भरने की जानकारी.
टैग: 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> डिफ़ॉल्ट: ""

स्टारलार्क फ़ंक्शन को तय करने वाली फ़ाइल का नाम, जिसे एक आर्ग्युमेंट का फ़ॉर्मैट 'फ़ॉर्मैट' कहा जाता है. यह आर्ग्युमेंट, कॉन्फ़िगर किए गए हर टारगेट पर लागू होता है, ताकि उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जा सके. --starlark:expr और --starlark:file, दोनों को तय करने में गड़बड़ी होती है. अतिरिक्त जानकारी के लिए --आउटपुट=starlark के लिए सहायता देखें.
टैग: terminal_output

--[no]tool_deps डिफ़ॉल्ट: "सही"

क्वेरी: यह विकल्प बंद होने पर, 'एक्ज़िक कॉन्फ़िगरेशन' की डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाएगा जिस पर क्वेरी काम करती है. 'एक्ज़िक कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर पर भेजा जाता है. आम तौर पर, यह उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल की ओर इशारा करता है. Cquery: यह सुविधा बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर दिया जाता है जो कॉन्फ़िगर किए गए इस टारगेट को खोजने वाले टॉप-लेवल टारगेट की तुलना में, एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. ये वे टारगेट भी होंगे जो टारगेट कॉन्फ़िगरेशन में शामिल हैं. अगर टॉप लेवल टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ लागू किए गए कॉन्फ़िगर किए गए टारगेट ही लौटाए जाएंगे. इस विकल्प में उन टूलचेन को शामिल नहीं किया जाएगा जिन्हें हल किया जा चुका है.
टैग: build_file_semantics

--transitions=<full, lite or none> डिफ़ॉल्ट: "कोई नहीं"

वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगी.
टैग: affects_outputs

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ और घटाव). यह क्वेरी, बताए गए टारगेट के ट्रांज़िटिव क्लोज़िंग से तय किए गए ब्रह्मांड में की जा सकती है. इस विकल्प का इस्तेमाल क्वेरी और क्वेरी कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वह टारगेट है जिसके तहत सभी जवाबों को बनाया गया है. इसलिए, इस विकल्प से कॉन्फ़िगरेशन और ट्रांज़िशन पर असर पड़ सकता है. अगर इस विकल्प की जानकारी नहीं दी गई है, तो टॉप-लेवल के टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट माना जाता है. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ बनाए नहीं जा सकते हैं, तो इस विकल्प को न बताने पर, बिल्ड टूट सकता है.
टैग: loading_and_analysis

ऐसे विकल्प जिनसे बिल्ड के समय को ऑप्टिमाइज़ करने में मदद मिलती है:

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "गलत"

लाइब्रेरीजार में मौजूद किसी भी क्लास को हटाने के लिए, 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 डिफ़ॉल्ट: "सही"

जेर फ़ाइल की हर फ़ाइल की डेक्सिंग के लिए ज़्यादातर काम अलग-अलग किए जाते हैं.
टैग: 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 टारगेट में लेगसी_create_init टारगेट "अपने-आप" (डिफ़ॉल्ट) पर सेट होता है, तो इस फ़्लैग के सेट होने पर ही इसे गलत माना जाता है. https://github.com/baazbuild/baZZ/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर सही है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, '-py2' सफ़िक्स वाले आउटपुट रूट में दिखेंगे. वहीं, Python 3 के लिए बनाए गए टारगेट, Python से जुड़े सफ़िक्स के बिना रूट में दिखेंगे. इसका मतलब है कि `bazz-bin` सुविधा सिमलिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. अगर इस विकल्प को चालू किया जाता है, तो हमारा सुझाव है कि `--insupported_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर सही है, तो `py_binary` और `py_test` टारगेट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे PY2 के बजाय डिफ़ॉल्ट रूप से PY3 पर सेट हो जाएंगे. अगर आपने इस फ़्लैग को सेट किया है, तो हमारा सुझाव है कि `--insupported_py2_Outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर लागू किए जा सकने वाले नेटिव Python नियम, --python_top जैसे लेगसी फ़्लैग से मिले रनटाइम के बजाय, Python टूलचेन के बताए गए Python रनटाइम का इस्तेमाल करेंगे, तो वे उसका इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

Python मेजर वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि यह `py_binary` और `py_test` टारगेट से ओवरराइड होता है, भले ही वे किसी वर्शन की जानकारी साफ़ तौर पर न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

अलग-अलग तरह के विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "ऑटो"

अगर Baze को 'ऑटो' पर सेट किया जाता है, तो वह दोबारा टेस्ट तब करता है, जब: (1) Basel को टेस्ट या उसकी डिपेंडेंसी में बदलाव का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया है, (3) --runs_per_test की मदद से एक से ज़्यादा टेस्ट रन का अनुरोध किया गया था या(4) टेस्ट पहले फ़ेल हो गया था. अगर यह 'हां' पर सेट है, तो Basel के टेस्ट के नतीजे, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर सभी को कैश मेमोरी में सेव होते हैं. अगर यह 'नहीं' पर सेट है, तो Baze किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.

--[no]experimental_cancel_concurrent_tests डिफ़ॉल्ट: "गलत"

अगर सही है, तो Blaze पहली बार दौड़ने पर एक साथ चल रहे टेस्ट रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ मिलकर काम करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "गलत"

अगर सही है, तो Bagel, कवरेज रन के दौरान हर टेस्ट के लिए, कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: 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 डिफ़ॉल्ट: "गलत"

यह सुविधा सिर्फ़ Android-साथ काम करने वाली लाइब्रेरी तक उपलब्ध है.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

गलती से TestRunner के Deps से जानकारी पाने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी के बारे में साफ़ तौर पर बताएं. फ़िलहाल, यह सुविधा सिर्फ़ बेज़ल के लिए काम करती है.

--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 में मौजूद पाथ पर फ़ाइल को टच करके शार्डिंग की सुविधा देता है, तो Baज़ल, शार्ड टेस्ट में फ़ेल हो जाएगा. गलत होने पर, शार्ड का समर्थन नहीं करने वाले टेस्ट रनर से हर शार्ड में सभी टेस्ट चल जाएंगे.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर सही है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ किए जाएंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता है. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान रखें कि ऐसा करने से, शेयर की गई कैश मेमोरी का इस्तेमाल करने पर क्रॉस-यूज़र कैशिंग में रुकावट आएगी.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> बार इस्तेमाल किए गए

J2ObjC टूल को पास करने के लिए अन्य विकल्प.

--java_debug

जावा टेस्ट की Java वर्चुअल मशीन को अनुमति देता है, ताकि टेस्ट शुरू करने से पहले, JDWP के नियमों का पालन करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार किया जा सके. इसमें -test_Output=streamed का इस्तेमाल हुआ है.
इसे बड़ा किया जाएगा:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps डिफ़ॉल्ट: "सही"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (अभी के लिए, कंपाइल-टाइम क्लासपाथ) जनरेट करें.

--[no]java_header_compilation डिफ़ॉल्ट: "सही"

सीधे सोर्स से इजर कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर यह फ़्लैग खाली स्ट्रिंग पर सेट है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> बार इस्तेमाल किए गए

javac को पास करने के लिए अतिरिक्त विकल्प.

--jvmopt=<a string> बार इस्तेमाल किए गए

Java वीएम को पास करने के लिए दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह उन क्लास की सूची जनरेट करने के लिए एक बाइनरी के बारे में बताता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह एक बाइनरी है जिसका इस्तेमाल बिना शार्ड किए डेक्सिंग करने के लिए किया जाता है.

--plugin=<a build target label> बार इस्तेमाल किए गए

बिल्ड में इस्तेमाल करने के लिए प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह नीति तय करती है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना चाहिए.

--proto_compiler=<a build target label> डिफ़ॉल्ट: "@bazu_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> का डिफ़ॉल्ट अनुवाद: "@bagel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल जो j2objc protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bagel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल जो Java प्रोटो को इकट्ठा करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@baaz_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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो कोई भी शार्ड जिसमें कम से कम एक दौड़ या कोशिश फ़ेल हो जाती है उसे 'फ़्लैकी' स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

बेज़ल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल, पहले Basel के बोले जाने पर शुरू करने वाले टूल (जिससे Baज़र सर्वर शुरू होता है) पर सेट है, Baze इसका इस्तेमाल करता है. यदि दोनों में से कोई भी सेट नहीं है, तो Ba जानना, आपके द्वारा चलाए जाने वाले ऑपरेटिंग सिस्टम के आधार पर हार्ड कोड किए गए डिफ़ॉल्ट पथ का उपयोग करता है (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, अन्य सभी: /bin/bash). ध्यान दें कि किसी ऐसे शेल का इस्तेमाल करने से जो बैश के साथ काम नहीं करता है, हो सकता है कि जनरेट की गई बाइनरी बिल्ड न हो या रनटाइम बंद हो जाए.
टैग: loading_and_analysis

--test_arg=<a string> बार इस्तेमाल किए गए

ऐसे अतिरिक्त विकल्प और आर्ग्युमेंट बनाती है जिन्हें टेस्ट के लिए लागू किया जा सकने वाला टेस्ट पास किया जाना चाहिए. कई आर्ग्युमेंट के बारे में बताने के लिए, इसका इस्तेमाल एक से ज़्यादा बार किया जा सकता है. अगर कई जांच की जाती हैं, तो उनमें से हर एक को एक जैसे तर्क मिलेंगे. इसका इस्तेमाल सिर्फ़ 'baze 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> डिफ़ॉल्ट: "अश्लील"

टेस्ट शार्डिंग के लिए रणनीति तय करें: 'शर्डिंग' एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब शार्डिंग का इस्तेमाल किया जा रहा हो. 'अक्षम' है. 'shard_count' BUILD एट्रिब्यूट पर ध्यान दिए बिना, जांच के लिए 'k' शार्ड लागू करने के लिए 'forced=k' का इस्तेमाल किया जाता है.

--tool_java_language_version=<a string> डिफ़ॉल्ट: ""

Java लैंग्वेज वर्शन, जिसका इस्तेमाल ऐसे टूल को एक्ज़ीक्यूट करने के लिए किया जाता है जो बिल्ड के दौरान ज़रूरी होते हैं

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो इस विकल्प की वजह से Java को कंपाइल करने में इंटरफ़ेस जार का इस्तेमाल होता है. इससे तेज़ी से कंपाइलेशन होगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

डंप के विकल्प

ऐसे विकल्प जो निर्देश से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: 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> डिफ़ॉल्ट: "बंद"

स्काईफ़्रेम ग्राफ़ को डंप करें: 'ऑफ़', 'समरी', 'काउंट', 'डेप्स' या '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>` के तौर पर बताएं, जिसे रिज़ॉल्व की गई डिपेंडेंसी ग्राफ़ में अनुमति दी जाएगी. भले ही, उन्हें रजिस्ट्री में येनक किया गया हो, जहां से वे आए हैं (अगर वे NonRegistryOver से नहीं आए हैं). ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन नहीं हो पाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, अनुमति पाए हुए वर्शन को भी तय किया जा सकता है. कीवर्ड 'सभी' का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, हम इसका सुझाव नहीं देते.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--[no]all डिफ़ॉल्ट: "गलत"

किसी भी टारगेट या डेटा स्टोर करने की जगह को बनाने के लिए ज़रूरी, सभी बाहरी डेटा स्टोर करने की जगह फ़ेच करता है. --enable_bzlmod चालू होने पर ही काम करता है.
टैग: changes_inputs

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: 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"> डिफ़ॉल्ट: "ऑटो"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. जैसे, "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

इस विकल्प से Starlark भाषा या बिल्ड एपीआई के सिमेंटिक्स पर असर पड़ता है. बिल्ड एपीआई को BUILD फ़ाइलों, .bzl फ़ाइलों या Workspace फ़ाइलों से ऐक्सेस किया जा सकता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट मौजूद नहीं है, उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग सही है, तो config_setting अन्य सभी नियमों की तरह ही, 'किसको दिखे' लॉजिक का ही पालन करता है. https://github.com/baazbuild/baZZ/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/batzbuild/ba बहुत/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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]configure डिफ़ॉल्ट: "गलत"

सिर्फ़ ऐसे डेटा स्टोर करने की जगहों को फ़ेच किया जाता है जिन्हें सिस्टम कॉन्फ़िगरेशन के लिए, 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है. --enable_bzlmod चालू होने पर ही काम करता है.
टैग: changes_inputs

--[no]force डिफ़ॉल्ट: "गलत"

अगर कोई मौजूदा रिपॉज़िटरी (डेटा स्टोर करने की जगह) है, तो उसे अनदेखा करें. साथ ही, डेटा स्टोर करने की जगह को फिर से फ़ेच करें. --enable_bzlmod चालू होने पर ही काम करता है.
टैग: changes_inputs

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> बार इस्तेमाल किए गए

<module name>=<path> के रूप में लोकल पाथ वाले मॉड्यूल को बदलें. अगर दिया गया पाथ एक ऐब्सलूट पाथ है, तो उसका इस्तेमाल उसी तरह किया जाएगा. अगर दिया गया पाथ, एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ोल्डर` का आउटपुट होता है

--registry=<a string> बार इस्तेमाल किए गए

बेज़ल मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री के बारे में बताता है. यह क्रम अहम है: मॉड्यूल को सबसे पहले पिछली रजिस्ट्री में देखा जाएगा. बाद की रजिस्ट्री में तब ही वापस आएंगे, जब वे पिछली रजिस्ट्री में मौजूद नहीं होंगे.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--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%' से शुरू होने वाले एलिमेंट, पास के फ़ाइल फ़ोल्डर के मिलते-जुलते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी के लिए डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो Bagel नए स्पॉन्स में टेस्ट के लिए, कवरेज पोस्टप्रोसेसिंग चलाएगा.
टैग: execution

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "गलत"

अगर इस विकल्प को चालू किया जाता है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलें मानेंगे. वे डायरेक्ट्री में रुकावट नहीं डालेंगी या सिमलिंक के प्रति संवेदनशील नहीं होंगी.
टैग: execution

--[no]incompatible_disallow_unsound_directory_outputs डिफ़ॉल्ट: "सही"

अगर यह नीति सेट की जाती है, तो आउटपुट फ़ाइल को डायरेक्ट्री के तौर पर सेट करने से जुड़ी कार्रवाई में गड़बड़ी होती है. सोर्स डायरेक्ट्री पर असर नहीं पड़ता. https://github.com/bagelbuild/baकोई का इस्तेमाल करने के लिए 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] डिफ़ॉल्ट: "गलत"

किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. जो टारगेट पूरा नहीं हो पाया और जो उस पर निर्भर हैं उनका विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें हो सकती हैं.
टैग: 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". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> बार इस्तेमाल किए गए

किसी कार्रवाई की याद दिलाने वाली जानकारी के आधार पर, किसी कार्रवाई को लागू करने की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो एक्ज़ीक्यूशन की जानकारी के साथ काम करती हैं. कई सामान्य ऐक्शन, एक्ज़ीक्यूशन की जानकारी के साथ काम करते हैं. उदाहरण के लिए, Gen बचाने, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. इसकी वजह यह है कि एक ही याद दिलाने वाले तरीके पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं. सिंटैक्स: "रेगुलर एक्सप्रेशन=[+-]key,regex=[+-]key,...". उदाहरण: '.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों को लागू करने की जानकारी में 'x' और 'z' को जोड़ता है और उससे 'y' को हटाता है. 'Genral=+requires-x', सभी जेनरल ऐक्शन के लिए, एक्ज़ीक्यूशन की जानकारी में 'ज़रूरी-x' जोड़ता है. '(?!Genregular).*=-requires-x' सभी गैर-सामान्य कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से 'ज़रूरी-x' को हटा देता है.
टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

कर्मचारियों का इस्तेमाल करके, Android dex और डीशुगर कार्रवाइयों को लगातार चालू करें.
इसे बड़ा किया जाता है:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

कर्मचारियों का इस्तेमाल करके, Android के स्थायी संसाधन प्रोसेसर को चालू करें.
इसे:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker

{14//} टैग करें



--strategy=Aapt2Optimize=worker--strategy=AARGenerator=worker--strategy=ProcessDatabinding=worker--strategy=GenerateDataBindingBaseClasses=workerhost_machine_resource_optimizationsexecution

--persistent_multiplex_android_dex_desugar

कर्मचारियों का इस्तेमाल करके, Android dex और desugar की स्थायी कार्रवाइयां चालू करें.
इसे बड़ा किया जाता है:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android संसाधन प्रोसेसर को चालू करें.
इनकी ओर से:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workersटैग करें

{14 --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workersटैग करें
5}{14
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers--modify_execution_info=AARGenerator=+supports-multiplex-workershost_machine_resource_optimizationsexecution

--persistent_multiplex_android_tools

Android के स्थायी और मल्टीप्लेक्स टूल (डेक्सिंग, डियूगरिंग, और रिसॉर्स प्रोसेसिंग) चालू करें.
इसे बड़ा किया जाता है:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "गलत"

अगर सही है, तो Baze, टेस्ट चलाने के लिए टारगेट प्लैटफ़ॉर्म का इस्तेमाल करेगा, न कि टेस्ट एक्ज़ेक्यूटिव ग्रुप का.
टैग: execution

ऐसे विकल्प जो कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करते हैं:

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Android टारगेट कंपाइलर.
टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--android_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> डिफ़ॉल्ट: "@bagel_tools//tools/android:sdk"

Android SDK/प्लैटफ़ॉर्म के बारे में जानकारी देता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--apple_crosstool_top=<a build target label> डिफ़ॉल्ट: "@bazu_tools//tools/cpp:toolchain"

Apple और Objc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loses_incremental_state, changes_inputs

--cc_output_directory_tag=<a string> डिफ़ॉल्ट: ""

कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स तय करता है.
टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट को कंपाइल करने के लिए, C++ कंपाइलर का इस्तेमाल करें.
टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> का डिफ़ॉल्ट मैसेज: "@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> डिफ़ॉल्ट: "@bazu_tools//tools/cpp:toolchain"

C++ कोड को कंपाइल करने के लिए इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग: loading_and_analysis, changes_inputs, affects_outputs

--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कस्टम मैलक लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड के नियमों में मैलक एट्रिब्यूट को बदल देती है.
टैग: 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 के हर ऐक्शन के लिए "ज़रूरी-xcode:{version}" लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "ज़रूरी-xcode-label:{version_label}" लागू करने की शर्त भी जोड़ें.
टैग: loses_incremental_state, loading_and_analysis, execution

--[no]experimental_prefer_mutual_xcode डिफ़ॉल्ट: "सही"

अगर सही है, तो सबसे नए Xcode का इस्तेमाल करें. यह Xcode स्थानीय तौर पर और कहीं से भी उपलब्ध है. अगर गलत है या कोई म्युचुअल उपलब्ध वर्शन नहीं है, तो xcode-select के ज़रिए चुने गए लोकल Xcode वर्शन का इस्तेमाल करें.
टैग: loses_incremental_state

--extra_execution_platforms=<comma-separated list of options> डिफ़ॉल्ट: ""

ऐसे प्लैटफ़ॉर्म जो कार्रवाइयां करने के लिए, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं. प्लैटफ़ॉर्म, टारगेट के हिसाब से या टारगेट पैटर्न के तौर पर तय किए जा सकते हैं. इन प्लैटफ़ॉर्म पर उन प्लैटफ़ॉर्म का इस्तेमाल करने से पहले विचार किया जाएगा जिनका एलान Workspace फ़ाइल में रजिस्टर_execution_platforms() के ज़रिए किया गया है. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है; बाद के इंस्टेंस पहले फ़्लैग की सेटिंग को बदल देंगे.
टैग: execution

--extra_toolchains=<comma-separated list of options> बार इस्तेमाल किए गए

टूलचेन के रिज़ॉल्यूशन के दौरान, टूलचेन के नियमों पर ध्यान दिया जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन पर विचार किया जाएगा, ताकि उन टूलचेन पर विचार किया जा सके जिनका एलान workspace_toolchains() से किया गया हो.
टैग: 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 और --कंपाइलर विकल्पों का इस्तेमाल, एक्ज़ीक्यूट कॉन्फ़िगरेशन के लिए भी किया जाता है. अगर यह फ़्लैग दिया जाता है, तो Ba बैंक, दिए गए 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> डिफ़ॉल्ट: "@ba"_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/batzbuild/ba इमारतों/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 डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel, lto को इंडेक्स करने वाली कमांड लाइन के लिए C++ लिंक ऐक्शन कमांड लाइन का दोबारा इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazubuild/baZ/issues/6791 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive डिफ़ॉल्ट: "सही"

अगर सही है, तो Baज़र, लाइब्रेरी डिपेंडेंसी को डिफ़ॉल्ट रूप से पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazibuild/bagel/issues/7362 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_require_ctx_in_configure_features डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel को cc_common.Configure_features में 'ctx' पैरामीटर की ज़रूरत होगी. ज़्यादा जानकारी के लिए, https://github.com/batzbuild/ba बहुत/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 टारगेट चलाने के लिए इस्तेमाल किया जाता है. बहिष्कृत; --insupported_use_python_toolchains की मदद से बंद किया गया है.
टैग: loading_and_analysis, affects_outputs

--python_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python अनुवादक को दिखाने वाले py_runtime का लेबल. बहिष्कृत; --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' से वॉचओएस SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें

अगर ऐसा है, तो बिल्ड से जुड़ी सही कार्रवाइयों के लिए दिए गए वर्शन के Xcode का इस्तेमाल किया जाता है. अगर जानकारी नहीं है, तो Xcode के एक्ज़ेक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग: loses_incremental_state

--xcode_version_config=<a build target label> डिफ़ॉल्ट: "@bagel_tools//tools/cpp:host_xcodes"

बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए, इस्तेमाल किया जाने वाला xcode_config नियम का लेबल.
टैग: loses_incremental_state, loading_and_analysis

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]apple_generate_dsym डिफ़ॉल्ट: "गलत"

डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग: affects_outputs, action_command_lines

--[no]build_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 एपीआई वर्शन के लिए ज़्यादा कार्रवाइयां करें.
टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "गलत"

कंपाइलेशन के आउटपुट के तौर पर, चालू और अनुरोध की गई सुविधाओं की स्थिति को सेव करें.
टैग: affects_outputs, experimental

--fission=<a set of compilation modes> डिफ़ॉल्ट: "नहीं"

इससे पता चलता है कि C++ कंपाइलेशन और लिंक के लिए, किस कंपाइलेशन मोड का इस्तेमाल किया जा रहा है. सभी मोड को सक्षम करने के लिए {'Fastbuild', 'dbg', 'opt'} या विशेष मानों का कोई भी संयोजन हो सकता है और सभी मोड को अक्षम करने के लिए 'no' का संयोजन हो सकता है.
टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data डिफ़ॉल्ट: "सही"

अगर नेटिव नियम सही हैं, तो नेटिव नियमों की मदद से, रनफ़ाइल में डेटा डिपेंडेंसी के लिए <code>DefaultInfo.files</code> जुड़ जाता है. यह तरीका Starlark के नियमों (https://bazz.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 डेटाबाइंडिंग 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> डिफ़ॉल्ट: "वर्णमाला"

यह नीति, Android बाइनरी के लिए मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करती है. ऐल्फ़ाबेट का मतलब है कि मेनिफ़ेस्ट को एक्ज़ीक्यूटेबल के मुकाबले पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में मौजूद कॉन्फ़िगरेशन डायरेक्ट्री के पाथ के हिसाब से क्रम में लगाया जाता है. डिपेंडेंसी का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट को उसी क्रम में रखा जाता है जो उसके डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "गलत"

ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]build_python_zip डिफ़ॉल्ट: "ऑटो"

python की एक्ज़ीक्यूटेबल ZIP फ़ाइल बनाएं; Windows पर, अन्य प्लैटफ़ॉर्म पर बंद करें
टैग: affects_outputs

--catalyst_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

कॉमा से अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple Catपाल बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "गलत"

अगर सूचना दी जाती है, तो Baज़र, इंस्ट्रुमेंट कोड का इस्तेमाल करेगा (जहां संभव हो ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ --instrumentation_filter से मेल खाने वाले टारगेट ही प्रभावित होंगे. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताना चाहिए - इसके बजाय, 'bazu दूरी' निर्देश का इस्तेमाल करना चाहिए.
टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] डिफ़ॉल्ट: "फ़ास्टबिल्ड"

वह मोड बताएं जिसमें बाइनरी बनाई जाएगी. मान: 'Fastbuild', 'dbg', 'opt'.
टैग: affects_outputs, action_command_lines

--conlyopt=<a string> बार इस्तेमाल किए गए

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--copt=<a string> बार इस्तेमाल किए गए

जीसीसी को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines, affects_outputs

--cpu=<a string> डिफ़ॉल्ट: ""

टारगेट सीपीयू.
टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई एलएलवीएम प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का ऐब्सलूट पाथ बताएं.
टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंट की बाइनरी जनरेट करना. Clang/LLVM कंपाइलर की मदद से, यह डायरेक्ट्री का नाम भी स्वीकार करता है. इसके तहत, रनटाइम के दौरान, रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को डंप किया जाएगा.
टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली कॉन्टेक्स्ट सेंसिटिव प्रोफ़ाइल को दिखाने वाली cs_fdo_profile.
टैग: affects_outputs

--cxxopt=<a string> बार इस्तेमाल किए गए

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc पास करने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> बार इस्तेमाल किए गए

--इसके लिए तय किया गया हर विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है.
टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> डिफ़ॉल्ट: "डिफ़ॉल्ट"

यह तय करता है कि C++ बाइनरी को डाइनैमिक रूप से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Basel को यह चुनना होगा कि उसे डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी' का मतलब है कि सभी लाइब्रेरी डायनैमिक रूप से लिंक कर दी जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्थिर मोड में लिंक की जाएंगी.
टैग: loading_and_analysis, affects_outputs

--[no]enable_fdo_profile_absolute_path डिफ़ॉल्ट: "सही"

अगर यह नीति सेट की जाती है, तो fdo_absolute_profile_path का इस्तेमाल करने पर गड़बड़ी दिखेगी.
टैग: affects_outputs

--[no]enable_runfiles डिफ़ॉल्ट: "ऑटो"

रनफ़ाइल सिमलिंक ट्री चालू करें. डिफ़ॉल्ट रूप से, यह Windows में दूसरे प्लैटफ़ॉर्म पर बंद रहती है.
टैग: affects_outputs

--experimental_action_listener=<a build target label> बार इस्तेमाल किए गए

पक्षों के पहलुओं को प्राथमिकता दी जाती है. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "गलत"

APK में 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 APK के लिए, संसाधन को छोटा करने की सुविधा चालू करता है.
टैग: affects_outputs, loading_and_analysis

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "गलत"

dex फ़ाइलों को फिर से लिखने के लिए rex टूल का इस्तेमाल करें
टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "गलत"

अगर साफ़ तौर पर बताया गया है, तो 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/bazibuild/baZZ/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> बार इस्तेमाल किए गए

हर एंट्री फ़ॉर्म में लेबल=वैल्यू के तौर पर होनी चाहिए. यहां लेबल किसी प्लैटफ़ॉर्म के बारे में बताता है. साथ ही, आउटपुट पाथ में इस्तेमाल करने के लिए, वैल्यू एक छोटा नाम होना चाहिए. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_Output_किन सही है. नाम रखने की प्राथमिकता सबसे ज़्यादा है.
टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir डिफ़ॉल्ट: "गलत"

अगर सही है, तो टारगेट प्लैटफ़ॉर्म के छोटे नाम का इस्तेमाल, सीपीयू के बजाय आउटपुट डायरेक्ट्री के नाम में किया जाता है. सटीक स्कीम प्रयोग के तौर पर है और इसमें बदलाव हो सकते हैं: पहला, बहुत ही कम मामलों में --प्लैटफ़ॉर्म विकल्प में सिर्फ़ एक वैल्यू नहीं होती, इसलिए प्लैटफ़ॉर्म विकल्प के हैश का इस्तेमाल किया जाता है. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए किसी छोटे नाम को --experimental_override_name_platform_in_Output_ ख़िलाफ़ ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है. इसके बाद, अगर --experimental_use_platforms_in_Output_ इससे_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_किन फ़ंक्शन पर भरोसा करने पर माइग्रेट करें.
टैग: 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 फ़ाइल या एलएलवीएम प्रोफ़ाइल फ़ाइल हो. इस फ़्लैग में लेबल के तौर पर दी गई फ़ाइलें (जैसे कि `//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> डिफ़ॉल्ट: "ऑप्ट करें"

वह मोड तय करें जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल पहले से मौजूद होंगे. मान: '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> बार इस्तेमाल किए गए

यहां दी गई सुविधाएं, एक्ज़ीक्यूटेबल कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> के बारे में बताने से सुविधा बंद हो जाएगी. नेगेटिव सुविधाएं, हमेशा पॉज़िटिव वैल्यू को ओवरराइड कर देती हैं.
टैग: changes_inputs, affects_outputs

--host_force_python=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

exec कॉन्फ़िगरेशन के लिए, Python वर्शन को बदलता है. यह "PY2" या "PY3" हो सकता है.
टैग: loading_and_analysis, affects_outputs

--host_linkopt=<a string> बार इस्तेमाल किए गए

एक्ज़िक कॉन्फ़िगरेशन में टूल जोड़ते समय, लिंकर को भेजने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, कम से कम काम करने वाला macOS वर्शन. अगर जानकारी नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> बार इस्तेमाल किए गए

एक्ज़ीक्यूटिव कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के अन्य विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर रखने की सूची दिखाता है (यह भी देखें --instrumentation_filter). option_1 से option_n का मतलब, आर्बिट्रेरी कमांड लाइन विकल्पों के लिए है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में बार.cc को छोड़कर, सभी cc फ़ाइलों की cc कमांड लाइन में -O0 कमांड लाइन का विकल्प जोड़ता है.
टैग: action_command_lines, affects_outputs

--host_swiftcopt=<a string> बार इस्तेमाल किए गए

एक्ज़ीक्यूटिव टूल के लिए swiftc को पास करने के अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "गलत"

चालू होने पर, किसी नियम में इस्तेमाल होने वाले हर टूलचेन के लिए एक्ज़ेक्यूटिव ग्रुप अपने-आप बन जाता है. इसके काम करने के लिए, नियम को अपनी कार्रवाइयों पर `toolchain` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazibuild/bagel/issues/17134 देखें.
टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory डिफ़ॉल्ट: "सही"

अगर सही है, तो जेनफ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग: affects_outputs, incompatible_change

--[no]incompatible_use_host_features डिफ़ॉल्ट: "सही"

अगर सही है, तो --सुविधा का इस्तेमाल सिर्फ़ टारगेट कॉन्फ़िगरेशन के लिए करें और --host_features का इस्तेमाल करें.
टैग: changes_inputs, affects_outputs, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "गलत"

कवरेज की सुविधा चालू होने पर, यह तय किया जाता है कि टेस्ट के नियमों को लागू किया जाए या नहीं. सेट होने पर, --instrumentation_filter पर शामिल किए गए टेस्ट नियम इंस्ट्रुमेंट किए जाते हैं. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रुमेंटेशन से बाहर रखा जाता है.
टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> डिफ़ॉल्ट: "-/javatests[/:],-/test/java[/:]"

कवरेज चालू होने पर, सिर्फ़ खास रेगुलर एक्सप्रेशन-आधारित फ़िल्टर में शामिल नामों वाले नियम ही लागू किए जाएंगे. इसके बजाय, '-' से शुरू होने वाले नियमों को बाहर रखा जाता है. ध्यान दें कि जब तक --instrument_test_targets को चालू नहीं किया जाता, तब तक सिर्फ़ नॉन-टेस्ट नियमों को इंस्ट्रुमेंट किया जाता है.
टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के साथ काम करने वाला कम से कम iOS वर्शन. अगर तय नहीं है, तो 'ios_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--ios_multi_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

iOS_ऐप्लिकेशन का इस्तेमाल करके, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें सभी खास आर्किटेक्चर शामिल हैं.
टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive डिफ़ॉल्ट: "सही"

अब काम नहीं करता, --inबेमेल_remove_legacy_whole_archive (ज़्यादा जानकारी के लिए, https://github.com/ba आवाज़ोंbuild/baZ/issues/7362 पर जाएं) पर जाएं. इसे चालू होने पर, cc_binary नियमों के लिए -पूरा-संग्रह का इस्तेमाल करें, जिसमें linkshared=True होता है और linkopts में linkstatic=True या '-static' होता है. यह सुविधा सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर,Alwayslink=1 का इस्तेमाल करना एक बेहतर विकल्प है.
टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> बार इस्तेमाल किए गए

लिंक करते समय, जीसीसी में भेजने का एक और विकल्प.
टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> बार इस्तेमाल किए गए

एलटीओ बैकएंड चरण को पास करने के लिए एक और विकल्प (-features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> बार इस्तेमाल किए गए

एलटीओ इंडेक्स करने के चरण को पास करने का एक और विकल्प (-features=thin_lto के तहत).
टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> बार इस्तेमाल किए गए

कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple macOS बाइनरी बनाना है.
टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, कम से कम macOS का वर्शन होना चाहिए. अगर जानकारी नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.
टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "गलत"

अगर सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS के बारे में बताएं.
टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "गलत"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर इस फ़्लैग और --compilation_mode=opt, दोनों के बारे में बताया गया है, तो बाइनरी स्ट्रिपिंग की जाएगी.
टैग: action_command_lines

--objccopt=<a string> बार इस्तेमाल किए गए

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए दूसरे विकल्प.
टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> बार इस्तेमाल किए गए

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तरीके से पास करने के लिए अन्य विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर रखने की सूची दिखाता है (यह भी देखें --instrumentation_filter). option_1 से option_n का मतलब, आर्बिट्रेरी कमांड लाइन विकल्पों के लिए है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //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> बार इस्तेमाल किए गए

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड ( --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:prop इंतज़ार_Optimize( name = "prop Tager_profile", cc_profile = "prop सूचनाएं_cc_profile.txt", ld_profile = "prop मुझे_ld_profile.txt" में लेबल को लेबल करते हैं. इससे जुड़े पैकेज में export_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है, ताकि ये फ़ाइलें बेज़ेल में दिखें. इस विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --प्रॉपेलर_ऑप्टिमाइज़=//a/b:prop मॉडल_profile
टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए cc_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

प्रोपलर ऑप्टिमाइज़ किए गए बिल्ड के लिए, ld_profile फ़ाइल का ऐब्सलूट पाथ.
टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

'टेस्ट' और 'रन' कमांड के लिए, एक्ज़ीक्यूटेबल से पहले प्रीफ़िक्स का इस्तेमाल करें. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो आखिरी कमांड लाइन 'foo -bar test_binary -baz' होगी. यह किसी एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण हैं: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग: action_command_lines

--[no]share_native_deps डिफ़ॉल्ट: "सही"

अगर सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट में शेयर किया जाएगा
टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "गलत"

तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह के साथ स्टैंप बाइनरी.
टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं ("-Wl,--strip-debug" का इस्तेमाल करना). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब स्ट्रिप iff --compilation_mode=fastbuild है.
टैग: affects_outputs

--stripopt=<a string> बार इस्तेमाल किए गए

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अन्य विकल्प.
टैग: action_command_lines, affects_outputs

--swiftcopt=<a string> बार इस्तेमाल किए गए

स्विफ़्ट के कंपाइलेशन का इस्तेमाल करने के दूसरे विकल्प.
टैग: action_command_lines

--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

ऐसे विकल्प जो इस बात पर असर डालते हैं कि 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_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/batzbuild/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/batzbuild/ba बहुत/issues/15684 देखें.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_validate_top_level_header_inclusions डिफ़ॉल्ट: "सही"

अगर सही है, तो Basel, टॉप लेवल डायरेक्ट्री हेडर को शामिल किए जाने की पुष्टि भी करेगा. ज़्यादा जानकारी के लिए, https://github.com/ba इमारतोंbuild/ba इमारतों/issues/10047 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--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 टारगेट साफ़ तौर पर 'सार्वजनिक इंपोर्ट' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर बताता है.
टैग: 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 साइनिंग के लिए सर्टिफ़िकेट का नाम. अगर इस नीति को सेट नहीं किया जाता है, तो इसे सेट अप करने के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल पर वापस लाया जाएगा. यह कोडसाइन के मैन पेज (SIGNING IDENTITIES) के मुताबिक, सर्टिफ़िकेट की कीचेन आइडेंटिटी प्राथमिकता या सर्टिफ़िकेट के सामान्य नाम की (सबस्ट्रिंग) हो सकती है.
टैग: action_command_lines

इस विकल्प से Starlark भाषा के सिमैंटिक या बिल्ड एपीआई के उस वर्शन पर असर पड़ता है जिसे बिल्ड फ़ाइलों, .bzl फ़ाइलों या Workspace फ़ाइलों से ऐक्सेस किया जा सकता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट मौजूद नहीं है, उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग सही है, तो config_setting अन्य सभी नियमों की तरह ही, 'किसको दिखे' लॉजिक का ही पालन करता है. https://github.com/baazbuild/baZZ/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 andobjc_Import में sdk_frameworks और कम ऊर्जा_SDK_frameworks एट्रिब्यूट को अनुमति न दें.
टैग: build_file_semantics, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/batzbuild/ba बहुत/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/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> (उदाहरण के लिए,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 पेयर के ज़रिए पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'baze 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

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 डिफ़ॉल्ट: "गलत"

लाइब्रेरीजार में मौजूद किसी भी क्लास को हटाने के लिए, 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 डिफ़ॉल्ट: "सही"

जेर फ़ाइल की हर फ़ाइल की डेक्सिंग के लिए ज़्यादातर काम अलग-अलग किए जाते हैं.
टैग: 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 टारगेट में लेगसी_create_init टारगेट "अपने-आप" (डिफ़ॉल्ट) पर सेट होता है, तो इस फ़्लैग के सेट होने पर ही इसे गलत माना जाता है. https://github.com/baazbuild/baZZ/issues/10076 पर जाएं.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py2_outputs_are_suffixed डिफ़ॉल्ट: "सही"

अगर सही है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट, '-py2' सफ़िक्स वाले आउटपुट रूट में दिखेंगे. वहीं, Python 3 के लिए बनाए गए टारगेट, Python से जुड़े सफ़िक्स के बिना रूट में दिखेंगे. इसका मतलब है कि `bazz-bin` सुविधा सिमलिंक, Python 2 के बजाय Python 3 टारगेट पर ले जाएगा. अगर इस विकल्प को चालू किया जाता है, तो हमारा सुझाव है कि `--insupported_py3_is_default` को चालू करें.
टैग: affects_outputs, incompatible_change

--[no]incompatible_py3_is_default डिफ़ॉल्ट: "सही"

अगर सही है, तो `py_binary` और `py_test` टारगेट जो अपने `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते, वे PY2 के बजाय डिफ़ॉल्ट रूप से PY3 पर सेट हो जाएंगे. अगर आपने इस फ़्लैग को सेट किया है, तो हमारा सुझाव है कि `--insupported_py2_Outputs_are_suffixed` को सेट करें.
टैग: loading_and_analysis, affects_outputs, incompatible_change

--[no]incompatible_use_python_toolchains डिफ़ॉल्ट: "सही"

अगर लागू किए जा सकने वाले नेटिव Python नियम, --python_top जैसे लेगसी फ़्लैग से मिले रनटाइम के बजाय, Python टूलचेन के बताए गए Python रनटाइम का इस्तेमाल करेंगे, तो वे उसका इस्तेमाल करेंगे.
टैग: loading_and_analysis, incompatible_change

--python_version=<PY2 or PY3> डिफ़ॉल्ट: ब्यौरा देखें

Python मेजर वर्शन मोड, `PY2` या `PY3`. ध्यान दें कि यह `py_binary` और `py_test` टारगेट से ओवरराइड होता है, भले ही वे किसी वर्शन की जानकारी साफ़ तौर पर न दें. इसलिए, आम तौर पर इस फ़्लैग को देने की ज़रूरत नहीं होती.
टैग: loading_and_analysis, affects_outputs

अलग-अलग तरह के विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] डिफ़ॉल्ट: "ऑटो"

अगर Baze को 'ऑटो' पर सेट किया जाता है, तो वह दोबारा टेस्ट तब करता है, जब: (1) Basel को टेस्ट या उसकी डिपेंडेंसी में बदलाव का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया है, (3) --runs_per_test की मदद से एक से ज़्यादा टेस्ट रन का अनुरोध किया गया था या(4) टेस्ट पहले फ़ेल हो गया था. अगर यह 'हां' पर सेट है, तो Basel के टेस्ट के नतीजे, बाहरी के तौर पर मार्क किए गए टेस्ट को छोड़कर सभी को कैश मेमोरी में सेव होते हैं. अगर यह 'नहीं' पर सेट है, तो Baze किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता है.

--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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो Bagel, कवरेज रन के दौरान हर टेस्ट के लिए, कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.
टैग: 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 डिफ़ॉल्ट: "गलत"

यह सुविधा सिर्फ़ Android-साथ काम करने वाली लाइब्रेरी तक उपलब्ध है.
टैग: affects_outputs

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "गलत"

java_* सोर्स की पुष्टि करनी है या नहीं.
टैग: affects_outputs

--[no]explicit_java_test_deps डिफ़ॉल्ट: "गलत"

गलती से TestRunner के Deps से जानकारी पाने के बजाय, java_test में JUnit या Hamcrest की डिपेंडेंसी के बारे में साफ़ तौर पर बताएं. फ़िलहाल, यह सुविधा सिर्फ़ बेज़ल के लिए काम करती है.

--[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 में मौजूद पाथ पर फ़ाइल को टच करके शार्डिंग की सुविधा देता है, तो Baज़ल, शार्ड टेस्ट में फ़ेल हो जाएगा. गलत होने पर, शार्ड का समर्थन नहीं करने वाले टेस्ट रनर से हर शार्ड में सभी टेस्ट चल जाएंगे.
टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed डिफ़ॉल्ट: "सही"

अगर सही है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ किए जाएंगे. किसी खास टेस्ट को स्थानीय तौर पर चलाने के लिए, 'local' टैग जोड़ें
टैग: incompatible_change

--[no]incompatible_strict_action_env डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता है. अगर आपको क्लाइंट से कुछ एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान रखें कि ऐसा करने से, शेयर की गई कैश मेमोरी का इस्तेमाल करने पर क्रॉस-यूज़र कैशिंग में रुकावट आएगी.
टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> बार इस्तेमाल किए गए

J2ObjC टूल को पास करने के लिए अन्य विकल्प.

--java_debug

जावा टेस्ट की Java वर्चुअल मशीन को अनुमति देता है, ताकि टेस्ट शुरू करने से पहले, JDWP के नियमों का पालन करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार किया जा सके. इसमें -test_Output=streamed का इस्तेमाल हुआ है.
इसे बड़ा किया जाएगा:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps डिफ़ॉल्ट: "सही"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी (अभी के लिए, कंपाइल-टाइम क्लासपाथ) जनरेट करें.

--[no]java_header_compilation डिफ़ॉल्ट: "सही"

सीधे सोर्स से इजर कंपाइल करें.

--java_language_version=<a string> डिफ़ॉल्ट: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

Java बाइनरी बनाते समय इस्तेमाल करने के लिए Java लॉन्चर. अगर यह फ़्लैग खाली स्ट्रिंग पर सेट है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> डिफ़ॉल्ट: "local_jdk"

Java रनटाइम वर्शन

--javacopt=<a string> बार इस्तेमाल किए गए

javac को पास करने के लिए अतिरिक्त विकल्प.

--jvmopt=<a string> बार इस्तेमाल किए गए

Java वीएम को पास करने के लिए दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह उन क्लास की सूची जनरेट करने के लिए एक बाइनरी के बारे में बताता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य डेक्स में होनी चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह एक बाइनरी है जिसका इस्तेमाल बिना शार्ड किए डेक्सिंग करने के लिए किया जाता है.

--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> डिफ़ॉल्ट: "@bazu_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> का डिफ़ॉल्ट अनुवाद: "@bagel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल जो j2objc protos को कंपाइल करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> डिफ़ॉल्ट: "@bagel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल जो Java प्रोटो को इकट्ठा करने का तरीका बताता है
टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> डिफ़ॉल्ट: "@baaz_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 डिफ़ॉल्ट: "गलत"

अगर सही है, तो कोई भी शार्ड जिसमें कम से कम एक दौड़ या कोशिश फ़ेल हो जाती है उसे 'फ़्लैकी' स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

बेज़ल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल, पहले Basel के बोले जाने पर शुरू करने वाले टूल (जिससे Baज़र सर्वर शुरू होता है) पर सेट है, Baze इसका इस्तेमाल करता है. यदि दोनों में से कोई भी सेट नहीं है, तो Ba जानना, आपके द्वारा चलाए जाने वाले ऑपरेटिंग सिस्टम के आधार पर हार्ड कोड किए गए डिफ़ॉल्ट पथ का उपयोग करता है (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> बार इस्तेमाल किए गए

ऐसे अतिरिक्त विकल्प और आर्ग्युमेंट बनाती है जिन्हें टेस्ट के लिए लागू किया जा सकने वाला टेस्ट पास किया जाना चाहिए. कई आर्ग्युमेंट के बारे में बताने के लिए, इसका इस्तेमाल एक से ज़्यादा बार किया जा सकता है. अगर कई जांच की जाती हैं, तो उनमें से हर एक को एक जैसे तर्क मिलेंगे. इसका इस्तेमाल सिर्फ़ 'baze 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> डिफ़ॉल्ट: "अश्लील"

टेस्ट शार्डिंग के लिए रणनीति तय करें: 'शर्डिंग' एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब शार्डिंग का इस्तेमाल किया जा रहा हो. 'अक्षम' है. 'shard_count' BUILD एट्रिब्यूट पर ध्यान दिए बिना, जांच के लिए 'k' शार्ड लागू करने के लिए 'forced=k' का इस्तेमाल किया जाता है.

--tool_java_language_version=<a string> डिफ़ॉल्ट: ""

Java लैंग्वेज वर्शन, जिसका इस्तेमाल ऐसे टूल को एक्ज़ीक्यूट करने के लिए किया जाता है जो बिल्ड के दौरान ज़रूरी होते हैं

--tool_java_runtime_version=<a string> डिफ़ॉल्ट: "remotejdk_11"

बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन

--[no]use_ijars डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो इस विकल्प की वजह से Java को कंपाइल करने में इंटरफ़ेस जार का इस्तेमाल होता है. इससे तेज़ी से कंपाइलेशन होगा, लेकिन गड़बड़ी के मैसेज अलग हो सकते हैं.

सहायता के विकल्प

ऐसे विकल्प जो निर्देश से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

--help_verbosity=<long, medium or short> डिफ़ॉल्ट: "मीडियम"

चुनें कि आपको सहायता निर्देश में कितनी जानकारी देनी है.
टैग: affects_outputs, terminal_output

--long [-l]

हर विकल्प के नाम के बजाय, उसकी पूरी जानकारी दिखाएं.
इसे बड़ा किया जाता है:
  --help_verbosity=long

टैग: affects_outputs, terminal_output

--short

सिर्फ़ विकल्पों के नाम दिखाएं, उनके टाइप या मतलब नहीं.
इसे बड़ा किया जाता है:
  --help_verbosity=short

टैग: affects_outputs, terminal_output

Baज़ल कमांड के लिए जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

--[no]show_make_env डिफ़ॉल्ट: "गलत"

आउटपुट में "Make" एनवायरमेंट शामिल करें.
टैग: affects_outputs, terminal_output

बेज़ल कमांड के लिए, सामान्य इनपुट को तय करने वाले या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

--mode=<classic, classic_internal_test_do_not_use or skylark> डिफ़ॉल्ट: "क्लासिक"

मोबाइल-इंस्टॉल चलाने का तरीका चुनें. "क्लासिक", मोबाइल-इंस्टॉल के मौजूदा वर्शन को चलाता है. "skylark" नए Starlark वर्शन का इस्तेमाल करता है, जो android_test में काम करता है.
टैग: loading_and_analysis, execution, incompatible_change

कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने के विकल्प:

--adb=<a string> डिफ़ॉल्ट: ""

'mobile-install' कमांड के लिए, adb बाइनरी का इस्तेमाल करें. अगर जानकारी नहीं दी गई है, तो --android_sdk कमांड लाइन विकल्प (या अगर --android_sdk तय नहीं है, तो डिफ़ॉल्ट SDK) की मदद से तय किए गए Android 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>` के तौर पर बताएं, जिसे रिज़ॉल्व की गई डिपेंडेंसी ग्राफ़ में अनुमति दी जाएगी. भले ही, उन्हें रजिस्ट्री में येनक किया गया हो, जहां से वे आए हैं (अगर वे NonRegistryOver से नहीं आए हैं). ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन नहीं हो पाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, अनुमति पाए हुए वर्शन को भी तय किया जा सकता है. कीवर्ड 'सभी' का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, हम इसका सुझाव नहीं देते.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

--incremental_install_verbosity=<a string> डिफ़ॉल्ट: ""

इंक्रीमेंटल इंस्टॉल के लिए कितने शब्दों में जानकारी दी जाए. डीबग लॉग करने के लिए, वैल्यू को 1 पर सेट करें.
टैग: bazel_monitoring

बेज़ल कमांड के लिए, जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते हैं.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: 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"> डिफ़ॉल्ट: "ऑटो"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. जैसे, "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

इस विकल्प से Starlark भाषा या बिल्ड एपीआई के सिमेंटिक्स पर असर पड़ता है. बिल्ड एपीआई को BUILD फ़ाइलों, .bzl फ़ाइलों या Workspace फ़ाइलों से ऐक्सेस किया जा सकता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट मौजूद नहीं है, उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग सही है, तो config_setting अन्य सभी नियमों की तरह ही, 'किसको दिखे' लॉजिक का ही पालन करता है. https://github.com/baazbuild/baZZ/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/batzbuild/ba बहुत/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 की डेप्थ, डायरेक्ट डिपेंडेंसी दिखाती है. ट्री, पाथ, और all_path के लिए, यह डिफ़ॉल्ट रूप से Integer.MAX_VALUE होता है, जबकि डिप और समझाने के लिए यह डिफ़ॉल्ट रूप से 1 होता है (टारगेट वाली पत्तियों और उनके पैरंट के अलावा रूट का सिर्फ़ डायरेक्ट डिप्रेशन दिखाता है).
टैग: terminal_output

--extension_filter=<a comma-separated list of <extension>s> डिफ़ॉल्ट: ब्यौरा देखें

इन मॉड्यूल एक्सटेंशन के इस्तेमाल और इनके जनरेट किए गए डेटा को सिर्फ़ तब दिखाएं, जब इनसे जुड़े फ़्लैग सेट किए गए हों. अगर यह नीति सेट की जाती है, तो नतीजों के ग्राफ़ में सिर्फ़ ऐसे पाथ शामिल होंगे जिनमें बताए गए एक्सटेंशन का इस्तेमाल करने वाले मॉड्यूल हों. खाली सूची में फ़िल्टर बंद हो जाता है और सभी संभावित एक्सटेंशन असरदार तरीके से तय किए जाते हैं.
टैग: terminal_output

--extension_info=<hidden, usages, repos or all> डिफ़ॉल्ट: "छिपाया गया"

यह बताएं कि क्वेरी के नतीजे में, एक्सटेंशन के इस्तेमाल के बारे में कितनी जानकारी शामिल करनी है. "इस्तेमाल" में सिर्फ़ एक्सटेंशन के नाम दिखेंगे, "डेटा स्टोर करने की जगह" मेंuse_repo के साथ इंपोर्ट किए गए डेटा स्टोर करने की जगहें भी शामिल होंगी और "all" में, एक्सटेंशन से जनरेट किए गए डेटा स्टोर करने की अन्य जगहें भी दिखेंगी.
टैग: 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 कमांड में नए पाथ शामिल करना या एक्सप्लेनेशन कमांड में अतिरिक्त डिपेंडेंसी शामिल करना.
टैग: terminal_output

--output=<text, json or graph> डिफ़ॉल्ट: "टेक्स्ट"

वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए इन वैल्यू की अनुमति है: text, json, graph
टैग: terminal_output

--[no]verbose डिफ़ॉल्ट: "गलत"

क्वेरी में, मॉड्यूल के मौजूदा वर्शन के हिसाब से समाधान किए जाने की वजह भी दिखेगी (अगर बदलाव हुआ है). सिर्फ़ पूरी जानकारी देने वाली क्वेरी के लिए, डिफ़ॉल्ट तौर पर 'सही' पर सेट होती है.
टैग: terminal_output

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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--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%' से शुरू होने वाले एलिमेंट, पास के फ़ाइल फ़ोल्डर के मिलते-जुलते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी के लिए डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ोल्डर` का आउटपुट होता है

--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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: 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"> डिफ़ॉल्ट: "ऑटो"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. जैसे, "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

इस विकल्प से Starlark भाषा या बिल्ड एपीआई के सिमेंटिक्स पर असर पड़ता है. बिल्ड एपीआई को BUILD फ़ाइलों, .bzl फ़ाइलों या Workspace फ़ाइलों से ऐक्सेस किया जा सकता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट मौजूद नहीं है, उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग सही है, तो config_setting अन्य सभी नियमों की तरह ही, 'किसको दिखे' लॉजिक का ही पालन करता है. https://github.com/baazbuild/baZZ/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/batzbuild/ba बहुत/issues/12932 देखें.
टैग: loading_and_analysis, incompatible_change

क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> डिफ़ॉल्ट: "कंज़र्वेटिव"

जब आउटपुट फ़ॉर्मैट, {xml,proto,record} में से एक हो, तो आसपेक्ट रेशियो पर निर्भरता को कैसे ठीक करें. 'बंद' का मतलब है कि किसी आसपेक्ट डिपेंडेंसी की समस्या हल नहीं हुई. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि एलान की गई सभी आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) डिपेंडेंसी को सीधे तौर पर डिपेंडेंसी की नियम क्लास दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वे पहलू जोड़े गए हैं जो डायरेक्ट डिपेंडेंसी की नियम क्लास के हिसाब से ऐक्टिव हैं. ध्यान दें कि सटीक मोड को एक ही टारगेट का आकलन करने के लिए, अन्य पैकेज लोड करने की ज़रूरत होती है. इस तरह, यह अन्य मोड के मुकाबले धीमा हो जाता है. इस बात पर भी ध्यान दें कि सटीक मोड भी पूरी तरह सटीक नहीं होता: किसी पहलू का हिसाब लगाने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. हालांकि, 'बेज़ल क्वेरी' के दौरान यह फ़ैसला नहीं लिया जाता.
टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "गलत"

अगर इसे चालू किया जाता है, तो हर क्वेरी कमांड से ऐसा लेबल दिखता है जैसे <code>लेबल</code> के इंस्टेंस पर लागू किया गया Starlark <code>str</code> फ़ंक्शन हो. यह उन टूल के लिए काम का है जिन्हें क्वेरी के अलग-अलग निर्देशों और/या नियमों से जनरेट होने वाले लेबल के आउटपुट से मैच करने की ज़रूरत होती है. अगर इस नीति को चालू नहीं किया जाता है, तो आउटपुट फ़ॉर्मैट करने वाले लोग, डेटा स्टोर करने की मुख्य जगह के नाम (डेटा स्टोर करने की मुख्य जगह के बजाय) का इस्तेमाल कर सकते हैं. इससे आउटपुट को पढ़ने में आसानी होती है.
टैग: terminal_output

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "गलत"

aquery, cquery: क्या आउटपुट में आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से जनरेट की गई कार्रवाइयों को शामिल करना है. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: terminal_output

--[no]experimental_graphless_query डिफ़ॉल्ट: "ऑटो"

अगर सही है, तो क्वेरी को लागू करने के ऐसे तरीके का इस्तेमाल किया जाता है जो ग्राफ़ की कॉपी नहीं बनाता. इसे लागू करने का नया तरीका, सिर्फ़ --order_ निर्भर=no, और आउटपुट फ़ॉर्मैटर के सबसेट के साथ काम करता है.
टैग: build_file_semantics, eagerness_to_exit

--graph:conditional_edges_limit=<an integer> डिफ़ॉल्ट: "4"

तय की गई शर्तों के लेबल की ज़्यादा से ज़्यादा संख्या. -1 का मतलब है कि कोई काट-छांट नहीं की गई और 0 का मतलब है कि कोई एनोटेशन नहीं है. यह विकल्प केवल --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output

--[no]graph:factored डिफ़ॉल्ट: "सही"

अगर सही है, तो ग्राफ़ को 'फ़ैक्टर' के तौर पर दिखाया जाएगा. इसका मतलब है कि जगह के हिसाब से सटीक नोड को एक साथ मर्ज कर दिया जाएगा और उनके लेबल जोड़ दिए जाएंगे. यह विकल्प केवल --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output

--graph:node_limit=<an integer> डिफ़ॉल्ट: "512"

आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की अधिकतम लंबाई. बड़े लेबल छोटे किए जाएंगे; -1 का मतलब है कि काट-छांट नहीं की जाएगी. यह विकल्प केवल --आउटपुट=ग्राफ़ पर लागू होता है.
टैग: terminal_output

--[no]implicit_deps डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो इंप्लिसिट डिपेंडेंसी को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा जिस पर क्वेरी काम करती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर तय नहीं किया गया है, लेकिन उसे बैजल से जोड़ा गया है. क्वेरी के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग: build_file_semantics

--[no]include_aspects डिफ़ॉल्ट: "सही"

aquery, cquery: क्या आउटपुट में आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से जनरेट की गई कार्रवाइयों को शामिल करना है. क्वेरी: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).
टैग: 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 की वैल्यू का अनुमान लगाया जाएगा. ध्यान दें, ऐसा हो सकता है कि यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे कि`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

--noorder_results

नतीजे, डिपेंडेंसी-ऑर्डर (डिफ़ॉल्ट) या बिना क्रम वाले फ़ैशन में नतीजे देते हैं. बिना क्रम वाला आउटपुट तेज़ी से काम करता है. हालांकि, यह सिर्फ़ तब काम करता है, जब --आउटपुट, minrank, maxrank या ग्राफ़, नहीं हो.
इसमें बड़ा किया जाता है:
  --order_output=no

टैग: terminal_output

--null

क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाता है.
इसमें बड़ा किया जाता है:
  --line_terminator_null=true

टैग: terminal_output

--order_output=<no, deps, auto or full> डिफ़ॉल्ट: "ऑटो"

बिना किसी क्रम के (नहीं), डिपेंडेंसी-ऑर्डर (deps) या पूरी तरह से ऑर्डर किए गए (फ़ुल) के नतीजे आउटपुट करते हैं. डिफ़ॉल्ट रूप से यह 'ऑटो' होता है. इसका मतलब है कि नतीजे, आउटपुट फ़ॉर्मैटर पर निर्भर करते हुए, आउटपुट में डिपेंडेंसी या पूरी तरह से क्रम में लगे होते हैं. दूसरे सभी के लिए पूरी तरह ऑर्डर किए गए प्रोटो, मिनरैंक, मैक्सरैंक, और ग्राफ़ के लिए डिपेंडेंसी-ऑर्डर (डिपेंडेंसी-ऑर्डर) होता है. जब आउटपुट पूरी तरह ऑर्डर हो जाता है, तो नोड पूरी तरह से सारणिक (कुल) क्रम में प्रिंट किए जाते हैं. सबसे पहले, सभी नोड वर्णमाला के क्रम में लगाए जाते हैं. इसके बाद, सूची के हर नोड का इस्तेमाल पोस्ट-ऑर्डर डेप्थ-फ़र्स्ट सर्च के शुरुआती दौर के रूप में किया जाता है. इसमें जिन नोड पर विज़िट नहीं किए गए हैं उन्हें आगे वाले नोड के वर्णमाला के क्रम में ट्रैवर्स किया जाता है. आखिर में, नोड उस क्रम के उलट प्रिंट होते हैं जिस क्रम में वे देखे गए थे.
टैग: terminal_output

--order_results

नतीजे, डिपेंडेंसी-ऑर्डर (डिफ़ॉल्ट) या बिना क्रम वाले फ़ैशन में नतीजे देते हैं. बिना क्रम वाला आउटपुट तेज़ी से काम करता है. हालांकि, यह सिर्फ़ तब काम करता है, जब --आउटपुट, minrank, maxrank या ग्राफ़, नहीं हो.
इसमें बड़ा किया जाता है:
  --order_output=auto

टैग: terminal_output

--output=<a string> डिफ़ॉल्ट: "लेबल"

वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए इन वैल्यू की अनुमति दी गई है: build, graph, stream_jsonproto, label, labels_ kind, location, maxrank, minrank, Package, proto, stream_proto, textproto, xml.
टैग: terminal_output

--[no]proto:default_values डिफ़ॉल्ट: "सही"

अगर सही है, तो ऐसे एट्रिब्यूट शामिल किए जाते हैं जिनकी वैल्यू, बिल्ड फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --आउटपुट=प्रोटो
टैग पर लागू होता है: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "गलत"

डेफ़िनिशन_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 डिफ़ॉल्ट: "सही"

नियम_इनपुट और नियम_आउटपुट फ़ील्ड भरने या न भरने की जानकारी.
टैग: 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 कॉन्फ़िगरेशन में है, तो सिर्फ़ लागू किए गए कॉन्फ़िगर किए गए टारगेट ही लौटाए जाएंगे. इस विकल्प में उन टूलचेन को शामिल नहीं किया जाएगा जिन्हें हल किया जा चुका है.
टैग: build_file_semantics

--universe_scope=<comma-separated list of options> डिफ़ॉल्ट: ""

टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ और घटाव). यह क्वेरी, बताए गए टारगेट के ट्रांज़िटिव क्लोज़िंग से तय किए गए ब्रह्मांड में की जा सकती है. इस विकल्प का इस्तेमाल क्वेरी और क्वेरी कमांड के लिए किया जाता है. 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>` के तौर पर बताएं, जिसे रिज़ॉल्व की गई डिपेंडेंसी ग्राफ़ में अनुमति दी जाएगी. भले ही, उन्हें रजिस्ट्री में येनक किया गया हो, जहां से वे आए हैं (अगर वे NonRegistryOver से नहीं आए हैं). ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन नहीं हो पाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल की मदद से, अनुमति पाए हुए वर्शन को भी तय किया जा सकता है. कीवर्ड 'सभी' का इस्तेमाल करके, इस जांच को बंद किया जा सकता है. हालांकि, हम इसका सुझाव नहीं देते.
टैग: loading_and_analysis

--check_bazel_compatibility=<error, warning or off> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--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%' से शुरू होने वाले एलिमेंट, पास के फ़ाइल फ़ोल्डर के मिलते-जुलते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी के लिए डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

रन के विकल्प

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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

--[no]run डिफ़ॉल्ट: "सही"

अगर गलत है, तो बनाए गए टारगेट के लिए बनाई गई कमांड लाइन चलाएं.
टैग: affects_outputs

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, तय किए गए आउटपुट को कॉन्फ़िगर कर सकता है. साथ ही, आउटपुट की मौजूदगी पर, उसकी वैल्यू पर असर डालता है:

--script_path=<a path> डिफ़ॉल्ट: ब्यौरा देखें

अगर यह नीति सेट की जाती है, तो दी गई फ़ाइल में टारगेट को शुरू करने वाली एक शेल स्क्रिप्ट लिखें. अगर यह विकल्प सेट है, तो टारगेट बेज़ल से नहीं चलता. target '//foo' को शुरू करने के लिए, 'baZ Run --script_path=foo //foo && ./foo' का इस्तेमाल करें. यह 'bazu Run //foo' से अलग होता है, क्योंकि बेज़ेल लॉक को रिलीज़ किया जाता है और एक्ज़ीक्यूटेबल को टर्मिनल के stDन से कनेक्ट किया जाता है.
टैग: affects_outputs, execution

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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: 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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--[no]configure डिफ़ॉल्ट: "गलत"

सिर्फ़ ऐसे डेटा स्टोर करने की जगह को सिंक करें जिन्हें सिस्टम कॉन्फ़िगरेशन के लिए, 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है.
टैग: changes_inputs

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: 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"> डिफ़ॉल्ट: "ऑटो"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. जैसे, "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 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/baazbuild/baZZ/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/batzbuild/ba बहुत/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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--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%' से शुरू होने वाले एलिमेंट, पास के फ़ाइल फ़ोल्डर के मिलते-जुलते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी के लिए डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

जांच के विकल्प

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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

--[no]print_relative_test_log_paths डिफ़ॉल्ट: "गलत"

अगर सही है, तो टेस्ट लॉग का पाथ प्रिंट करते समय, उस रिलेटिव पाथ का इस्तेमाल करें जो 'टेस्टलॉग' सुविधा सिमलिंक का इस्तेमाल करता है. ध्यान दें - किसी दूसरे कॉन्फ़िगरेशन के साथ आने वाले 'बिल्ड'/'टेस्ट'/वगैरह को शुरू करने से, इस सिमलिंक का टारगेट बदल सकता है. ऐसा करने से, पहले प्रिंट किया गया पाथ अब काम का नहीं रहेगा.
टैग: 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` से शुरू होने वाले बैक-रेफ़रंस यूआरएल के रूप में. एक ही यूआरएल के लिए एक से ज़्यादा `रीराइट` डायरेक्टिव दिए जा सकते हैं. इस मामले में, एक से ज़्यादा यूआरएल दिए जा सकते हैं.

--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% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले 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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: 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"> डिफ़ॉल्ट: "ऑटो"

लोड होने/विश्लेषण के फ़ेज़ के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल किया जाता है. इसके बाद, वैकल्पिक तौर पर कोई कार्रवाई ([-|*]<float>) ली जाती है. जैसे, "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग: bazel_internal_configuration

इस विकल्प से Starlark भाषा या बिल्ड एपीआई के सिमेंटिक्स पर असर पड़ता है. बिल्ड एपीआई को BUILD फ़ाइलों, .bzl फ़ाइलों या Workspace फ़ाइलों से ऐक्सेस किया जा सकता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "गलत"

अगर नफ़रत वाली भाषा का इस्तेमाल करने के लिए कोई वैल्यू नहीं दी गई है, तो यह नोप है. ऐसा नहीं होने पर, अगर यह फ़्लैग गलत है, तो कोई भी config_setting, जिसमें साफ़ तौर पर दिखने वाला एट्रिब्यूट मौजूद नहीं है, उसे //visibility:public के तौर पर दिखाया जाएगा. अगर यह फ़्लैग सही है, तो config_setting अन्य सभी नियमों की तरह ही, 'किसको दिखे' लॉजिक का ही पालन करता है. https://github.com/baazbuild/baZZ/issues/12933 पर जाएं.
टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility डिफ़ॉल्ट: "सही"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट पर दिखेगी. https://github.com/batzbuild/ba बहुत/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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> बार इस्तेमाल किए गए

<module name>=<path> के रूप में लोकल पाथ वाले मॉड्यूल को बदलें. अगर दिया गया पाथ एक ऐब्सलूट पाथ है, तो उसका इस्तेमाल उसी तरह किया जाएगा. अगर दिया गया पाथ, एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `baze की जानकारी वाले फ़ोल्डर` का आउटपुट होता है

--registry=<a string> बार इस्तेमाल किए गए

बेज़ल मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री के बारे में बताता है. यह क्रम अहम है: मॉड्यूल को सबसे पहले पिछली रजिस्ट्री में देखा जाएगा. बाद की रजिस्ट्री में तब ही वापस आएंगे, जब वे पिछली रजिस्ट्री में मौजूद नहीं होंगे.
टैग: 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> के तौर पर बताई जाती है. इसमें पीरियड की जानकारी कुल समय और संख्या, पॉज़िटिव पूर्णांक होती है. अगर <पीरियड> में <count> लगातार जीसीएस होने के बाद भी लंबे समय तक काम करने वाले स्पेस (old gen हीप) के --gc_t इससेhhreshold से ज़्यादा प्रतिशत खाली रहता है, तो ओओएम ट्रिगर होता है. एक से ज़्यादा सीमाओं को कॉमा लगाकर अलग किया जा सकता है.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0> डिफ़ॉल्ट: "2147483647"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--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%' से शुरू होने वाले एलिमेंट, पास के फ़ाइल फ़ोल्डर के मिलते-जुलते हैं. अगर इसे छोड़ दिया जाता है या खाली किया जाता है, तो डिफ़ॉल्ट 'baज़ल की जानकारी के लिए डिफ़ॉल्ट-पैकेज-पाथ' का आउटपुट होता है.

--[no]show_loading_progress डिफ़ॉल्ट: "सही"

अगर इसे चालू किया जाता है, तो Ba बाद में "पैकेज लोड हो रहा है:" मैसेज प्रिंट हो जाता है.

वर्शन के विकल्प

ऐसे विकल्प जो निर्देश से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--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

--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_timeout_scaling=<a double> डिफ़ॉल्ट: "1.0"

दिए गए फ़ैक्टर के हिसाब से एचटीटीपी डाउनलोड करने से जुड़े सभी टाइम आउट को स्केल करें
टैग: bazel_internal_configuration

--[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.execut अब भी इंटरनेट को ऐक्सेस करने वाला आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग: bazel_internal_configuration

ऐसे विकल्प जो बिल्ड को एक्ज़ीक्यूट करने की सुविधा को कंट्रोल करते हैं:

--gc_thrashing_threshold=<an integer in 0-100 range> डिफ़ॉल्ट: "100"

ज़्यादा समय तक ली गई जगह (0-100) का वह प्रतिशत है जिससे ज़्यादा GcThrringDetector, मेमोरी प्रेशर इवेंट के हिसाब से, इसकी सीमाओं के हिसाब से मान लेता है (--gc_t इससेrapins_limits). अगर नीति को 100 पर सेट किया जाता है, तो GcTraringdetector बंद हो जाएगा.
टैग: host_machine_resource_optimizations

ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, तय किए गए आउटपुट को कॉन्फ़िगर कर सकता है. साथ ही, आउटपुट की मौजूदगी पर, उसकी वैल्यू पर असर डालता है:

--[no]gnu_format डिफ़ॉल्ट: "गलत"

अगर यह नीति सेट की जाती है, तो GNU के मानकों में बताए गए तरीकों का इस्तेमाल करके, वर्शन को stdout में लिखें.
टैग: affects_outputs, execution

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> डिफ़ॉल्ट: "गड़बड़ी"

देखें कि Basel मॉड्यूल की सुविधा, बैजल वर्शन के साथ काम करती है या नहीं. मान्य वैल्यू में ये शामिल हैं: `गड़बड़ी`, इसे समस्या को हल करने में मदद करने के लिए, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी`.
टैग: loading_and_analysis

--check_direct_dependencies=<off, warning or error> डिफ़ॉल्ट: "चेतावनी"

देखें कि रूट मॉड्यूल में तय की गई, सीधे `bagel_dep` डिपेंडेंसी के वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच को बंद करने के लिए मान्य वैल्यू को 'बंद है' पर सेट किया जाता है. इसके अलावा, मेल न खाने पर चेतावनी प्रिंट करने के लिए `चेतावनी` दी जाती है. इसके अलावा, गड़बड़ी को ठीक करने के लिए 'गड़बड़ी' दी जाती है.
टैग: loading_and_analysis

--[no]ignore_dev_dependency डिफ़ॉल्ट: "गलत"

अगर सही है, तो Basel, रूट मॉड्यूल के MODULE.baZZ में `dev_dependency` के तौर पर एलान किए गए `baaz_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें, अगर यह रूट मॉड्यूल नहीं है, तो इस फ़्लैग की वैल्यू चाहे जो भी हो, इन डेवलपर डिपेंडेंसी को MODULE.bazu में हमेशा अनदेखा किया जाता है.
टैग: loading_and_analysis

--lockfile_mode=<off, update, refresh or error> डिफ़ॉल्ट: "अपडेट करें"

यह तय करता है कि Lockfile का इस्तेमाल कैसे करना है और क्या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य वैल्यू `अपडेट` होती हैं. साथ ही, बदलाव होने पर इसे अपडेट करें, समय-समय पर रिमोट रजिस्ट्री से बदली जा सकने वाली जानकारी (यांग किए गए वर्शन और पहले से मौजूद मॉड्यूल मौजूद नहीं है) को रीफ़्रेश करने के लिए `रीफ़्रेश करें`, लॉकफ़ाइल का इस्तेमाल करने के लिए `गड़बड़ी`, लेकिन अगर लॉकफ़ाइल अप-टू-डेट न हो, तो गड़बड़ी करें, या लॉकफ़ाइल में न पढ़ने या लिखने के लिए `बंद` करें.
टैग: 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"

तय की गई सीमा तक पहुंचने पर, GcThrracingdetector ऐप्लिकेशन, बेज़ल को ओओएम के साथ क्रैश कर देता है. हर सीमा <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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --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 के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर Ba ज़रिए को यह पता चलता है कि उसके बनाए गए हीप के प्रतिशत का इस्तेमाल, --skyframe_high_water_mark_threshold के तय किए गए थ्रेशोल्ड से ज़्यादा है, तो कोई छोटा जीसी इवेंट होने पर, यह बिना किसी वजह से स्काईफ़्रेम की अस्थायी स्थिति को कम कर देगा. उपयोगकर्ता को दिए जाने वाले हर बार के लिए यह इस सीमा तक कई बार हो जाएगा. डिफ़ॉल्ट तौर पर, Integer.MAX_VALUE होता है; असरदार तरीके से अनलिमिटेड है. शून्य का मतलब है कि छोटे जीसी इवेंट कभी भी ड्रॉप ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो कोई छोटा जीसी इवेंट होने पर, स्काईफ़्रेम की स्थिति को नहीं हटाया जाएगा. साथ ही, बनाए रखे गए हीप के प्रतिशत की सीमा भी पार हो जाएगी.
टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> डिफ़ॉल्ट: "85"

Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए, फ़्लैग करें. अगर 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 कार्रवाइयों की संख्या डिफ़ॉल्ट रूप से तय होती है. इनमें, सबसे ज़्यादा कार्रवाइयां की जाती हैं. इस विकल्प को सेट करने पर, याददाश्त बढ़ाने वाली सभी चीज़ों के आंकड़े दिखेंगे.

ऐसे विकल्प जो किसी जेनरिक इनपुट को बेज़ल कमांड में बदल सकते हैं या उसके हिसाब से बदलाव कर सकते हैं, जो अन्य कैटगरी में नहीं आते.:

--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> डिफ़ॉल्ट: "ऑटो"

रेपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह नीति 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता. साथ ही, रेपो फ़ेचिंग को रीस्टार्ट किया जा सकता है. अगर ऐसा नहीं है, तो वर्चुअल वर्कर थ्रेड का इस्तेमाल किया जाता है.

अन्य विकल्प, जिन्हें किसी अन्य कैटगरी में नहीं रखा जाता.:

--override_repository=<an equals-separated mapping of repository name to path> बार इस्तेमाल किए गए

डेटा स्टोर करने की जगह को बदलने के लिए, <repository name>=<path> के तौर पर लोकल पाथ का इस्तेमाल करें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो उसका इस्तेमाल बिलकुल उसी तरह किया जाएगा. अगर दिया गया पाथ एक रिलेटिव पाथ है, तो वह मौजूदा डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace% से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से जुड़ा होता है, जो `baze की जानकारी वाले Workspace` का आउटपुट होता है

विकल्प इफ़ेक्ट टैग

unknown	इस विकल्प का असर अनजान या दस्तावेज़ में नहीं है.
no_op	इस विकल्प से कोई असर नहीं पड़ता.
loses_incremental_state	इस विकल्प की वैल्यू बदलने से, इंक्रीमेंटल (बढ़ने वाली) स्थिति में काफ़ी कमी आ सकती है, जिससे बिल्ड धीमे हो सकता है. सर्वर के रीस्टार्ट होने या डिपेंडेंसी ग्राफ़ के बड़े हिस्से के अमान्य होने की वजह से, स्टेटस दिख सकता है.
changes_inputs	यह विकल्प उन इनपुट को सक्रिय रूप से बदलता है जिन्हें बिल्ड के लिए बैजल के इस्तेमाल का इस्तेमाल किया जाता है, जैसे कि फ़ाइल सिस्टम से जुड़ी पाबंदियां, रिपॉज़िटरी वर्शन या अन्य विकल्प.
affects_outputs	इस विकल्प से, बैज के आउटपुट पर असर पड़ता है. इस टैग में जान-बूझकर बहुत ज़्यादा असर डाला गया है. इसमें ट्रांज़िटिव असर शामिल हो सकता है. साथ ही, इससे किस तरह के आउटपुट पर असर पड़ता है, इसकी जानकारी नहीं दी गई है.
build_file_semantics	इस विकल्प से BUILD या .bzl फ़ाइलों के सिमेंटिक्स पर असर पड़ता है.
bazel_internal_configuration	यह विकल्प बेज़ल-इंटरनल मशीनरी की सेटिंग पर असर डालता है. इस टैग का मतलब यह नहीं है कि बिल्ड आर्टफ़ैक्ट पर असर पड़ा है.
loading_and_analysis	इस विकल्प से डिपेंडेंसी लोड करने और उसका विश्लेषण करने में मदद मिलती है. साथ ही, डिपेंडेंसी ग्राफ़ बनाने पर भी असर पड़ता है.
execution	यह विकल्प, एक्ज़ीक्यूशन के चरण पर असर डालता है. जैसे, सैंडबॉक्सिंग या रिमोट तौर पर एक्ज़ीक्यूशन से जुड़े विकल्प.
host_machine_resource_optimizations	यह विकल्प ऐसे ऑप्टिमाइज़ेशन को ट्रिगर करता है जो मशीन से जुड़ा हो सकता है. साथ ही, इस बात की कोई गारंटी नहीं है कि यह सभी मशीनों पर काम करेगा. ऑप्टिमाइज़ेशन में परफ़ॉर्मेंस के अन्य पहलुओं, जैसे कि मेमोरी या सीपीयू की लागत के साथ समझौता करना शामिल हो सकता है.
eagerness_to_exit	इस विकल्प से यह तय होता है कि कितनी जल्दी-जल्दी बैजल, गलती से हारने के बाद बाहर निकलेंगे. इस विकल्प में हार मिलने के बाद भी गेम जारी रखने का विकल्प मौजूद होता है.
bazel_monitoring	इस विकल्प का इस्तेमाल करके, बैजल के व्यवहार और परफ़ॉर्मेंस को मॉनिटर किया जाता है.
terminal_output	इस विकल्प से, बैजल के टर्मिनल आउटपुट पर असर पड़ता है.
action_command_lines	यह विकल्प एक या ज़्यादा बिल्ड कार्रवाइयों के कमांड लाइन आर्ग्युमेंट को बदल देता है.
test_runner	इस विकल्प से, बिल्ड का टेस्टरनर एनवायरमेंट बदल जाता है.

विकल्प मेटाडेटा टैग

experimental	यह विकल्प, एक्सपेरिमेंट के तौर पर शुरू की गई सुविधा को ट्रिगर करता है. इसके काम करने की गारंटी नहीं दी जाती.
incompatible_change	यह विकल्प, नुकसान पहुंचा सकने वाले बदलाव को ट्रिगर करता है. माइग्रेशन के लिए तैयार है या नहीं, इसकी जांच करने या नई सुविधा को रिलीज़ होने से पहले इस्तेमाल करने के लिए, इस विकल्प का इस्तेमाल करें
deprecated	यह विकल्प अब काम नहीं करता. ऐसा हो सकता है कि जिस सुविधा पर इसका असर पड़ रहा है उस पर रोक लगा दी गई हो या जानकारी देने के किसी दूसरे तरीके को प्राथमिकता दी जाए.