bazel [<startup options>] <command> [<args>]या
bazel [<startup options>] <command> [<args>] -- [<target patterns>]टारगेट पैटर्न के सिंटैक्स के बारे में जानने के लिए, उपयोगकर्ता के लिए गाइड देखें.
विकल्प सिंटैक्स
Bazel को अलग-अलग तरीके से विकल्प भेजे जा सकते हैं. जिन विकल्पों के लिए वैल्यू की ज़रूरत होती है उन्हें इसके बराबर के निशान या स्पेस से पास किया जा सकता है:
--<option>=<value> --<option> <value>कुछ विकल्पों में एक वर्ण का छोटा फ़ॉर्म होता है. ऐसे मामले में, कम अवधि वाले फ़ॉर्म को एक डैश और स्पेस से पास करना ज़रूरी है.
-<short_form> <value>
बूलियन विकल्पों को इन तरीकों से चालू किया जा सकता है:
--<option> --<option>=[true|yes|1]और बंद करने के लिए:
--no<option> --<option>=[false|no|0]
आम तौर पर, 'ट्रिस्टेट' विकल्प डिफ़ॉल्ट रूप से 'अपने-आप' पर सेट होते हैं. नीचे बताए गए तरीके से इन्हें 'हर हाल में चालू करें' पर सेट किया जा सकता है:
--<option>=[true|yes|1]या नीचे बताए गए तरीके से 'हर हाल में बंद किया गया' के तौर पर सेट किया जा सकता है:
--no<option> --<option>=[false|no|0]
निर्देश
analyze-profile |
बिल्ड प्रोफ़ाइल के डेटा का विश्लेषण करता है. |
aquery |
दिए गए टारगेट का विश्लेषण करता है और ऐक्शन ग्राफ़ पर क्वेरी करता है. |
build |
तय किए गए टारगेट बनाता है. |
canonicalize-flags |
यह बैजल के विकल्पों की सूची को कैननिकल बनाता है. |
clean |
आउटपुट फ़ाइलों को हटाता है और वैकल्पिक तौर पर सर्वर को रोक देता है. |
coverage |
खास टेस्ट टारगेट के लिए, कोड कवरेज की रिपोर्ट जनरेट करता है. |
cquery |
कॉन्फ़िगरेशन के साथ तय किए गए टारगेट को लोड करता है, उनका विश्लेषण करता है, और क्वेरी करता है. |
dump |
bazel सर्वर प्रोसेस की अंदरूनी स्थिति को डंप करता है. |
fetch |
डेटा स्टोर करने की ऐसी बाहरी जगह को फ़ेच करता है जो टारगेट करने के लिए ज़रूरी शर्तें हैं. |
help |
निर्देशों या इंडेक्स के लिए प्रिंट से जुड़ी सहायता. |
info |
यह bazel सर्वर के बारे में रनटाइम की जानकारी दिखाता है. |
license |
इस सॉफ़्टवेयर का लाइसेंस प्रिंट करता है. |
mobile-install |
मोबाइल डिवाइस पर इंस्टॉल लक्ष्य. |
modquery |
Bzlmod बाहरी डिपेंडेंसी ग्राफ़ पर क्वेरी करता है |
print_action |
फ़ाइल को कंपाइल करने के लिए, कमांड लाइन के आर्ग्युमेंट प्रिंट करता है. |
query |
डिपेंडेंसी ग्राफ़ क्वेरी चलाता है. |
run |
तय किए गए टारगेट को चलाता है. |
shutdown |
bazel सर्वर बंद करता है. |
sync |
फ़ाइल फ़ोल्डर फ़ाइल में बताए गए सभी डेटा स्टोर करने की जगहों को सिंक करता है |
test |
खास टेस्ट टारगेट बनाता और चलाता है. |
version |
bazel के लिए वर्शन की जानकारी प्रिंट करता है. |
स्टार्टअप के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
--[no]autodetect_server_javabase
डिफ़ॉल्ट: "सही"-
जब --noautodetect_server_javabase पास हो जाता है, तो Bazel, bazel सर्वर चलाने के लिए लोकल JDK का इस्तेमाल करने के बजाय, बाहर निकल जाता है.
टैग:affects_outputs
,loses_incremental_state
--[no]batch
डिफ़ॉल्ट: "false"-
अगर सेट कर दी जाती है, तो Bazel को स्टैंडर्ड क्लाइंट/सर्वर मोड के बजाय, बिना सर्वर के क्लाइंट प्रोसेस के तौर पर चलाया जाएगा. यह अब सेवा में नहीं है और इसे हटा दिया जाएगा. अगर आपको सर्वर को ज़्यादा देर तक बंद रखना है, तो कृपया इसे पूरी तरह से बंद कर दें.
टैग:loses_incremental_state
,bazel_internal_configuration
,deprecated
--[no]batch_cpu_scheduling
डिफ़ॉल्ट: "false"-
सिर्फ़ Linux पर; Blaze के लिए 'बैच' सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति ऐसे वर्कलोड के लिए फ़ायदेमंद है जो नॉन-इंटरैक्टिव हैं, लेकिन जिन्हें उनका बेहतर मान कम नहीं करना है. 'पुरुष 2 sched_setscheduler' देखें. अगर इस नीति को 'गलत है' पर सेट किया जाता है, तो Bazel सिस्टम कॉल नहीं करेगा.
टैग:host_machine_resource_optimizations
--bazelrc=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
उपयोगकर्ता .bazelrc फ़ाइल की जगह की जानकारी, जिसमें Bazel विकल्पों की डिफ़ॉल्ट वैल्यू शामिल हैं. /dev/null का मतलब है कि आगे के सभी `--bazelrc`को अनदेखा कर दिया जाएगा. इससे उपयोगकर्ता की आरसी फ़ाइल की खोज को बंद किया जा सकता है, जैसे कि रिलीज़ बिल्ड में.
यह विकल्प एक से ज़्यादा बार भी दिया जा सकता है.
उदाहरण के लिए, `--bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc`,
1) x.rc और y.rc को पढ़े जाने की संख्या होती है.
2) पिछले /dev/null की वजह से, z.rc को अनदेखा कर दिया गया है.
अगर इसकी जानकारी नहीं दी गई है, तो Bazel पहली .bazelrc फ़ाइल का इस्तेमाल करता है, जो उसे इन दो जगहों पर मिलती है: फ़ाइल फ़ोल्डर की डायरेक्ट्री और फिर उपयोगकर्ता की होम डायरेक्ट्री.
ध्यान दें: कमांड लाइन विकल्प, bazelrc में मौजूद किसी भी विकल्प की जगह हमेशा लागू होंगे.
टैग:changes_inputs
--[no]block_for_lock
डिफ़ॉल्ट: "सही"-
जब --noblock_for_lock पास हो जाता है, तो Bazel, चल रहे किसी निर्देश के पूरा होने का इंतज़ार नहीं करता. इसके बजाय, वह तुरंत बाहर निकल जाता है.
टैग:eagerness_to_exit
--[no]client_debug
डिफ़ॉल्ट: "false"-
अगर सही है, तो क्लाइंट से stderr पर डीबग की जानकारी को लॉग करें. इस विकल्प को बदलने से सर्वर रीस्टार्ट नहीं होगा.
टैग:affects_outputs
,bazel_monitoring
--connect_timeout_secs=<an integer>
डिफ़ॉल्ट: "30"-
सर्वर से कनेक्ट करने की हर कोशिश के लिए, क्लाइंट कितनी देर इंतज़ार करता है
टैग:bazel_internal_configuration
--[no]expand_configs_in_place
डिफ़ॉल्ट: "सही"-
--कॉन्फ़िगरेशन फ़्लैग के विस्तार को सामान्य rc विकल्पों और कमांड लाइन के ज़रिए तय किए गए विकल्पों के बीच एक तय पॉइंट एक्सपैंशन के बजाय, जगह से तय किया गया था.
टैग:no_op
,deprecated
--failure_detail_out=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर इस नीति को सेट किया जाता है, तो यह ऐसी जगह के बारे में बताता है जहां सर्वर के काम न करने पर यह प्रोटोबफ़ मैसेज लिखा जा सकता है. साथ ही, आम तौर पर gRPC से इसकी रिपोर्ट नहीं की जा सकती. अगर ऐसा नहीं है, तो जगह की जानकारी ${OUTPUT_BASE}/failure_detail.rawproto होगी.
टैग:affects_outputs
,loses_incremental_state
--[no]home_rc
डिफ़ॉल्ट: "सही"- $HOME/.bazelrc पर होम पेज की फ़ाइल देखनी है या नहीं, यह देखना है या नहीं
टैग:changes_inputs
--[no]idle_server_tasks
डिफ़ॉल्ट: "सही"-
सर्वर के कुछ समय से इस्तेमाल में न होने पर, System.gc() चलाएं
टैग:loses_incremental_state
,host_machine_resource_optimizations
--[no]ignore_all_rc_files
डिफ़ॉल्ट: "false"-
यह नीति सभी आरसी फ़ाइलों को बंद कर देती है. भले ही, ये फ़्लैग स्टार्टअप के विकल्पों की सूची में बाद में आएं, फिर चाहे ये अन्य आरसी-बदलाव करने वाले फ़्लैग की वैल्यू पर ध्यान दिए बिना.
टैग:changes_inputs
--io_nice_level={-1,0,1,2,3,4,5,6,7}
डिफ़ॉल्ट: "-1"-
सिर्फ़ Linux पर; sys_ioprio_set सिस्टम कॉल का इस्तेमाल करके, सबसे बढ़िया IO शेड्यूल करने के लिए, इस लेवल को 0 से 7 तक सेट करें. सबसे ऊंची प्राथमिकता 0 और सबसे कम प्राथमिकता 7 है. ऐसा हो सकता है कि शेड्यूलर सिर्फ़ चार प्राथमिकता पर ही काम करे. अगर इस नीति को नेगेटिव वैल्यू पर सेट किया जाता है, तो Bazel सिस्टम कॉल नहीं करेगा.
टैग:host_machine_resource_optimizations
--local_startup_timeout_secs=<an integer>
डिफ़ॉल्ट: "120"-
सर्वर से कनेक्ट होने के लिए क्लाइंट को ज़्यादा से ज़्यादा कितनी देर इंतज़ार करना पड़ता है
टैग:bazel_internal_configuration
--macos_qos_class=<a string>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
macOS पर चलाते समय, bazel सर्वर के लिए 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} होगी. ध्यान दें: अगर आपने इस वैल्यू के लिए Bazel को एक से दूसरे पर ले जाने के लिए, कोई दूसरा विकल्प चुना है, तो हो सकता है कि आप एक नया और अतिरिक्त Bazel सर्वर शुरू कर दें. Bazel हर तय आउटपुट आधार पर एक सर्वर शुरू करता है. आम तौर पर, हर फ़ाइल फ़ोल्डर में एक आउटपुट बेस होता है - हालांकि, इस विकल्प को चुनने पर आपके पास हर फ़ाइल फ़ोल्डर के लिए कई आउटपुट बेस हो सकते हैं. इस तरह, एक ही क्लाइंट के लिए एक ही मशीन पर एक साथ कई बिल्ड चलाए जा सकते हैं. Bazel सर्वर को बंद करने का तरीका जानने के लिए, 'bazel help शटडाउन' देखें.
टैग:affects_outputs
,loses_incremental_state
--output_user_root=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
वह उपयोगकर्ता खास डायरेक्ट्री जिसमें सभी बिल्ड आउटपुट लिखे जाते हैं. डिफ़ॉल्ट रूप से, यह $USER का फ़ंक्शन होता है. हालांकि, एक कॉन्सटैंट के बारे में बताने पर, बिल्ड आउटपुट को साथ मिलकर काम करने वाले उपयोगकर्ताओं के बीच शेयर किया जा सकता है.
टैग:affects_outputs
,loses_incremental_state
--[no]preemptible
डिफ़ॉल्ट: "false"-
सही होने पर, कोई दूसरा निर्देश शुरू होने पर, इस निर्देश को रोका जा सकता है.
टैग:eagerness_to_exit
--server_jvm_out=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
सर्वर के जेवीएम के आउटपुट में कुछ लिखने की जगह. अगर इस नीति को सेट नहीं किया जाता है, तो view_base में डिफ़ॉल्ट रूप से जगह सेट होती है.
टैग:affects_outputs
,loses_incremental_state
--[no]shutdown_on_low_sys_mem
डिफ़ॉल्ट: "false"-
अगर max_idle_secs सेट किया गया है और बिल्ड सर्वर कुछ समय के लिए बंद है, तो सिस्टम में बिना रैम कम होने पर सर्वर को बंद कर दें. सिर्फ़ Linux.
टैग:eagerness_to_exit
,loses_incremental_state
--[no]system_rc
डिफ़ॉल्ट: "सही"-
पूरे सिस्टम में मौजूद bazelrc को देखना है या नहीं, यह देखना है या नहीं.
टैग:changes_inputs
--[no]unlimit_coredumps
डिफ़ॉल्ट: "false"-
सॉफ़्ट कोरडंप की सीमा को हार्ड लिमिट तक बढ़ाता है, ताकि सामान्य स्थितियों में सर्वर और क्लाइंट के कोरडंप बनाए जा सकें. इस फ़्लैग को एक बार अपने बाज़ार में लगाएं और इसे भूल जाएं, ताकि आपको कोरडंप मिल जाएं. ऐसा तब होगा, जब असल में आपके सामने कोई ऐसी स्थिति पैदा हो जाए, जो उन्हें ट्रिगर करती है.
टैग:bazel_internal_configuration
--[no]watchfs
डिफ़ॉल्ट: "false"-
अगर सही है, तो bazel स्थानीय बदलावों के लिए, हर फ़ाइल को स्कैन करने के बजाय, ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करता है.
टैग:deprecated
--[no]windows_enable_symlinks
डिफ़ॉल्ट: "false"-
सही होने पर, Windows पर फ़ाइल कॉपी करने के बजाय, असल सिंबॉलिक लिंक बनाए जाएंगे. इसके लिए ज़रूरी है कि Windows डेवलपर मोड चालू हो और Windows 10 का 1703 या इसके बाद का वर्शन हो.
टैग:bazel_internal_configuration
--[no]workspace_rc
डिफ़ॉल्ट: "सही"- $workspace/.bazelrc पर फ़ाइल फ़ोल्डर bazelrc फ़ाइल खोजने या न देखने की सुविधा
टैग:changes_inputs
- अन्य विकल्प जो अलग-अलग कैटगरी में नहीं आते हैं.:
- ऐप्लिकेशन के
--host_jvm_args=<jvm_arg>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - Blaze को एक्ज़ीक्यूट करने के लिए, JVM को पास करने के लिए फ़्लैग.
--host_jvm_debug
-
कुछ अतिरिक्त JVM स्टार्टअप फ़्लैग जोड़ने की सुविधा का विकल्प. इसकी वजह से, JVM को शुरू होने के दौरान तब तक इंतज़ार करना पड़ता है, जब तक कि आप JDWP का पालन करने वाले डीबगर (जैसे कि Eclipse) को पोर्ट 5005 से कनेक्ट नहीं कर लेते.
इसमें बढ़ता है:
--host_jvm_args=-Xdebug
--host_jvm_args=-Xrunjdwp:transport=dt_socket,server=y,address=5005
--host_jvm_profile=<profiler_name>
डिफ़ॉल्ट: ""- प्रोफ़ाइलर/डीबगर के लिए बने JVM स्टार्टअप फ़्लैग को जोड़ने की सुविधा का विकल्प. Bazel के पास जाने-पहचाने वैल्यू की एक सूची है, जिसे वह हार्ड कोड किए गए JVM स्टार्टअप फ़्लैग के साथ मैप करता है. यह कुछ फ़ाइलों के लिए हार्डकोड किए गए कुछ पाथ खोज सकता है.
--server_javabase=<jvm path>
डिफ़ॉल्ट: ""- JVM का पाथ, जिसका इस्तेमाल Bazel को खुद चलाने के लिए किया जाता है.
सभी कमांड से जुड़े सामान्य विकल्प
- बिल का एक्ज़ीक्यूट करने की प्रोसेस को कंट्रोल करने वाले विकल्प:
--experimental_oom_more_eagerly_threshold=<an integer>
डिफ़ॉल्ट: "100"-
अगर इस फ़्लैग की वैल्यू 100 से कम पर सेट की जाती है, तो Bazel को ओओएम माना जाएगा. हालांकि, ऐसा तब होगा, जब दो पूरे जीसी (जीसी) के बाद भी, इस फ़्लैग (पुरानी पीढ़ी) के हीप के प्रतिशत से ज़्यादा हिस्सा इकट्ठा रहता हो.
टैग:host_machine_resource_optimizations
--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range>
डिफ़ॉल्ट: "1048576"-
कंसोल पर प्रिंट की जाने वाली stdout / stderr फ़ाइलों का ज़्यादा से ज़्यादा साइज़. -1 का मतलब है कोई सीमा नहीं.
टैग:execution
- ऐसे विकल्प जो उपयोगकर्ता को सही आउटपुट कॉन्फ़िगर करने की अनुमति देते हैं, उसकी वैल्यू पर असर पड़ता है, न कि उस पर असर होता है:
- ऐप्लिकेशन के
--repo_env=<a 'name=value' assignment with an optional value part>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
ऐसे अतिरिक्त एनवायरमेंट वैरिएबल तय किए जाते हैं जो सिर्फ़ रिपॉज़िटरी के नियमों के लिए उपलब्ध होते हैं. ध्यान दें कि रिपॉज़िटरी के नियमों को पूरा एनवायरमेंट दिखता है. हालांकि, इस तरह कॉन्फ़िगरेशन की जानकारी को ऐक्शन ग्राफ़ को अमान्य किए बिना, विकल्पों की मदद से डेटा स्टोर करने की जगहों में भेजा जा सकता है.
टैग:action_command_lines
- Bzel के मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--[no]check_bzl_visibility
डिफ़ॉल्ट: "सही"-
यह विकल्प बंद होने पर, .bzl लोड होने से जुड़ी गड़बड़ियां, चेतावनियों के तौर पर मार्क हो जाती हैं.
टैग:build_file_semantics
- यह विकल्प, Starlark भाषा या बिल्ड एपीआई के सिमैंटिक पर असर डालता है. ऐसा उस बिल्ड एपीआई को ऐक्सेस करने के लिए किया जा सकता है जिसे BUILD फ़ाइलें, .bzl फ़ाइलें या WORKSPACE फ़ाइलें ऐक्सेस करनी हैं.:
--[no]enable_bzlmod
डिफ़ॉल्ट: "false"-
सही होने पर, Bzlmod डिपेंडेंसी मैनेजमेंट सिस्टम चालू हो जाता है. इसे Workspace की जगह प्राथमिकता दी जाती है. ज़्यादा जानकारी के लिए, https://bazel.build/build/bzlmod देखें.
टैग:loading_and_analysis
--[no]experimental_action_resource_set
डिफ़ॉल्ट: "सही"-
अगर नीति को 'सही है' पर सेट किया जाता है, तो स्थानीय तौर पर प्रोसेस करने के लिए, ctx.actions.run() और ctx.actions.run_shel() रिसॉर्स_set पैरामीटर स्वीकार हो जाएगा. ऐसा न करने पर, मेमोरी और 1 सीपीयू के लिए यह डिफ़ॉल्ट रूप से 250 एमबी हो जाएगा.
टैग:execution
,build_file_semantics
,experimental
-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो टैग को टारगेट से, कार्रवाइयों के पूरा होने की ज़रूरी शर्तों के मुताबिक लागू किया जाएगा. ऐसा न होने पर, टैग लागू नहीं होंगे. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/8830 देखें.
टैग:build_file_semantics
,experimental
--[no]experimental_analysis_test_call
डिफ़ॉल्ट: "सही"-
सही पर सेट होने पर, analytics_test नेटिव कॉल की सुविधा उपलब्ध होगी.
टैग:loading_and_analysis
,build_file_semantics
,experimental
--[no]experimental_bzl_visibility
डिफ़ॉल्ट: "सही"-
इस सेटिंग को चालू करने पर, `visible()` फ़ंक्शन जोड़ा जाता है. इसे .bzl फ़ाइलें, लोड() स्टेटमेंट के मकसद से, टॉप-लेवल की जांच के दौरान कॉल कर सकती हैं.
टैग:loading_and_analysis
,experimental
-
अगर 'सही है' पर सेट किया जाता है, तो cc_shared_library नियम के लिए ज़रूरी नियम एट्रिब्यूट और Starlark API तरीके उपलब्ध होंगे
टैग:build_file_semantics
,loading_and_analysis
,experimental
--[no]experimental_disable_external_package
डिफ़ॉल्ट: "false"-
अगर इसे 'सही है' पर सेट किया जाता है, तो अपने-आप जनरेट हुआ //बाहरी पैकेज उपलब्ध नहीं रहेगा. Bazel अब भी 'external/BUILD' फ़ाइल को पार्स नहीं कर पाएगा, लेकिन बिना नाम वाले पैकेज से बाहरी/ में पहुंचने वाले ग्लॉब काम करेंगे.
टैग:loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_enable_android_migration_apis
डिफ़ॉल्ट: "false"-
अगर इसे 'सही है' पर सेट किया जाता है, तो Android Starlark माइग्रेशन के लिए ज़रूरी एपीआई चालू करता है.
टैग:build_file_semantics
--[no]experimental_get_fixed_configured_action_env
डिफ़ॉल्ट: "false"-
चालू होने पर, action.env फ़ीचर कॉन्फ़िगरेशन के ज़रिए तय किए गए तय एनवायरमेंट वैरिएबल भी दिखाएगा.
टैग:loading_and_analysis
,experimental
--[no]experimental_google_legacy_api
डिफ़ॉल्ट: "false"-
अगर 'सही है' पर सेट किया जाता है, तो यह Google के लेगसी कोड से जुड़े Starlark बिल्ड एपीआई के कई प्रयोग दिखाता है.
टैग:loading_and_analysis
,experimental
--[no]experimental_lazy_template_expansion
डिफ़ॉल्ट: "सही"-
अगर 'सही है' पर सेट किया जाता है, तो ctx.actions.expand_template(), प्रतिस्थापन वैल्यू के स्थगित इवैलुएशन के लिए TemplateDict पैरामीटर को स्वीकार करता है.
टैग:execution
,build_file_semantics
,experimental
--[no]experimental_platforms_api
डिफ़ॉल्ट: "false"-
अगर 'सही है' पर सेट किया जाता है, तो प्लैटफ़ॉर्म से जुड़े Starlark एपीआई चालू करता है. ये एपीआई, डीबग करने के लिए काम के होते हैं.
टैग:loading_and_analysis
,experimental
--[no]experimental_repo_remote_exec
डिफ़ॉल्ट: "false"-
अगर 'सही है' पर सेट किया जाता है, तो रिपॉज़िटरी_रूल को कहीं से भी काम करने की कुछ सुविधाएं मिलती हैं.
टैग:build_file_semantics
,loading_and_analysis
,experimental
--[no]experimental_sibling_repository_layout
डिफ़ॉल्ट: "false"-
अगर 'सही है' पर सेट किया जाता है, तो नॉन-मुख्य रिपॉज़िटरी, एक्ज़ीक्यूशन रूट में मुख्य रिपॉज़िटरी के लिए सिमलिंक के तौर पर लगाए जाते हैं. इसका मतलब है कि डेटा स्टोर करने की सभी जगहें, $OUT_base/execution_root डायरेक्ट्री से सीधे तौर पर जुड़े हैं. इसका खराब असर, वास्तविक टॉप-लेवल की 'बाहरी' डायरेक्ट्री के लिए $OUT_base/execution_root/__main__/external को खाली करने का होता है.
टैग:action_command_lines
,bazel_internal_configuration
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]incompatible_always_check_depset_elements
डिफ़ॉल्ट: "सही"-
डिप्सेट में जोड़े गए सभी कंस्ट्रक्टर में जोड़े गए एलिमेंट की वैधता देखें. एलिमेंट ऐसे होने चाहिए जिनमें बदलाव न किया जा सके, लेकिन शुरुआत में depset(direct=...) कंस्ट्रक्टर जांच करना भूल गया. डिप्सेट एलिमेंट में सूचियों के बजाय, ट्यूपल का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10313 देखें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_depset_for_libraries_to_link_getter
डिफ़ॉल्ट: "सही"-
सही होने पर, Bazel, Linking_context.libraries_to_link से मिली सूची नहीं दिखाता है. हालांकि, यह इसकी जगह डिप्सेट दिखाता है.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_disable_starlark_host_transitions
डिफ़ॉल्ट: "false"-
अगर 'सही है' पर सेट किया जाता है, तो नियम के एट्रिब्यूट 'cfg = "host"' पर सेट नहीं हो सकते. नियमों में इसके बजाय 'cfg = "exec"' सेट होना चाहिए.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_disable_target_provider_fields
डिफ़ॉल्ट: "false"-
अगर इसे 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स के ज़रिए 'टारगेट' ऑब्जेक्ट पर, सेवा देने वाली कंपनियों को ऐक्सेस करने की सुविधा बंद करें. इसके बजाय, प्रोवाइडर-की सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, नियम लागू करने वाले फ़ंक्शन में `my_info` को ऐक्सेस करने के लिए, `ctx.attr.dep.my_info` का इस्तेमाल करने के बजाय, `ctx.attr.dep[MyInfo]` का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/9014 देखें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disallow_empty_glob
डिफ़ॉल्ट: "false"-
अगर इस वैल्यू को 'सही है' पर सेट किया जाता है, तो Glob() के `allow_BLANK` आर्ग्युमेंट की डिफ़ॉल्ट वैल्यू 'गलत' होती है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disallow_legacy_javainfo
डिफ़ॉल्ट: "सही"-
अब सेवा में नहीं है. No-op.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disallow_struct_provider_syntax
डिफ़ॉल्ट: "false"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो हो सकता है कि नियम लागू करने वाले फ़ंक्शन, स्ट्रक्ट न दिखाएं. इसके बजाय, उन्हें प्रोवाइडर इंस्टेंस की सूची दिखानी होगी.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_existing_rules_immutable_view
डिफ़ॉल्ट: "सही"-
अगर इसे 'सही है' पर सेट किया जाता है, तो local.मौजूदा_ नीतियां और local.existing_rules सेट किए जा सकते हैं. इसके लिए, बदले जा सकने वाले डिक्ट के बजाय, लाइटवेट ऐसे व्यू ऑब्जेक्ट दिखाए जाते हैं जिनमें बदलाव न किया जा सकता हो.
टैग:build_file_semantics
,loading_and_analysis
,incompatible_change
--[no]incompatible_fix_package_group_reporoot_syntax
डिफ़ॉल्ट: "सही"-
पैकेज_ग्रुप के `packages` एट्रिब्यूट में, किसी भी रिपॉज़िटरी (डेटा स्टोर करने की जगह) में मौजूद सभी पैकेज के बजाय, मौजूदा रिपॉज़िटरी में सभी पैकेज को रेफ़र करने के लिए, वैल्यू "//..." का मतलब बदलता है. पुराना व्यवहार पाने के लिए, "//..." की जगह "सार्वजनिक" वैल्यू का इस्तेमाल किया जा सकता है. इस फ़्लैग के लिए --insupported_package_group_has_public_syntax को भी चालू करना ज़रूरी है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_java_common_parameters
डिफ़ॉल्ट: "सही"-
अगर वैल्यू को 'सही है' पर सेट किया जाता है, तो set_sources और Host_javabase पैरामीटर में मौजूद exit_jar औरhost_javabase पैरामीटर हटा दिए जाएंगे.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_new_actions_api
डिफ़ॉल्ट: "सही"-
अगर इसे 'सही है' पर सेट किया जाता है, तो कार्रवाइयां बनाने का एपीआई सिर्फ़ `ctx.actions` पर उपलब्ध है, `ctx` पर नहीं.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_no_attr_license
डिफ़ॉल्ट: "सही"-
अगर 'सही है' पर सेट किया जाता है, तो `attr.लाइसेंस` फ़ंक्शन बंद कर देता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_no_implicit_file_export
डिफ़ॉल्ट: "false"-
अगर इस नीति को सेट किया जाता है, तो (इस्तेमाल की गई) सोर्स फ़ाइलें तब तक 'निजी' के तौर पर सेट रहती हैं, जब तक कि उन्हें साफ़ तौर पर एक्सपोर्ट नहीं किया जाता. https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-24-file- पेमेंट्स.md देखें
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_no_rule_outputs_param
डिफ़ॉल्ट: "false"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Starlark फ़ंक्शन के `role()` फ़ंक्शन के `आउटपुट` पैरामीटर को बंद करता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_package_group_has_public_syntax
डिफ़ॉल्ट: "सही"-
package_group के `packages` एट्रिब्यूट में, सभी पैकेज या बिना पैकेज के लिए, "सार्वजनिक" या "निजी" लिखने की अनुमति मिलती है.
टैग: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_shel का कमांड पैरामीटर सिर्फ़ स्ट्रिंग स्वीकार करेगा
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_stop_exporting_language_modules
डिफ़ॉल्ट: "false"-
चालू होने पर, उपयोगकर्ता की .bzl फ़ाइलों में खास भाषा के कुछ मॉड्यूल (जैसे कि `cc_Common`) उपलब्ध नहीं होंगे. इन्हें सिर्फ़ उनसे जुड़े नियमों के डेटा स्टोर करने की जगहों से ही कॉल किया जा सकता है.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_struct_has_no_methods
डिफ़ॉल्ट: "false"-
स्ट्रक्चर के to_json और to_proto मेथड को बंद कर देता है, जो स्ट्रक्चर फ़ील्ड नेमस्पेस को प्रदूषित करते हैं. इसके बजाय, JSON के लिए json.encode या json.encode_indent या textproto के लिए proto.encode_text का इस्तेमाल करें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_top_level_aspects_require_providers
डिफ़ॉल्ट: "false"-
अगर नीति को 'सही है' पर सेट किया जाता है, तो टॉप लेवल आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) ज़रूरी कंपनियों के हिसाब से होगा. साथ ही, यह सिर्फ़ टॉप लेवल के उन टारगेट पर चलेगा जिनके नियमों के तहत विज्ञापन देने वाली कंपनियां, इस आसपेक्ट की ज़रूरी शर्तों को पूरा करती हैं.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_unambiguous_label_stringification
डिफ़ॉल्ट: "सही"-
सही होने पर, Bazel //foo:bar के बजाय, @//foo:bar को @//foo:bar पर लेबल करेगा. यह सिर्फ़ str(), % ऑपरेटर वगैरह के व्यवहार पर असर डालता है. इसी तरह, repr() के काम करने के तरीके में कोई बदलाव नहीं होता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/15916 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_use_cc_configure_from_rules_cc
डिफ़ॉल्ट: "false"-
सही होने पर, Bazel @bazel_tools से cc_config का इस्तेमाल करने की अनुमति नहीं देगा. माइग्रेशन से जुड़ी ज़्यादा जानकारी और निर्देशों के लिए, कृपया https://github.com/bazelbuild/bazel/issues/10134 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition
डिफ़ॉल्ट: "false"-
अगर 'सही है' पर सेट किया जाता है, तो निजी नियम के एट्रिब्यूट की विज़िबिलिटी, नियम के इस्तेमाल के बजाय, नियम की परिभाषा के हिसाब से जांची जाती है.
टैग: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]incompatible_do_not_split_linking_cmdline
डिफ़ॉल्ट: "सही"-
सही होने पर, Bazel अब लिंक करने के लिए इस्तेमाल किए जाने वाले कमांड लाइन फ़्लैग में बदलाव नहीं करता है. साथ ही, यह खुद तय नहीं करता है कि कौनसे फ़्लैग पैरामीटर फ़ाइल को भेजे जाएंगे और कौनसे नहीं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7670 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]keep_state_after_build
डिफ़ॉल्ट: "सही"-
गलत होने पर, बिल्ड खत्म होने पर Blaze इस बिल्ड से इनमेमोरी स्थिति को खारिज कर देगा. इसके बाद के बिल्ड में कोई बढ़ोतरी नहीं होगी.
टैग:loses_incremental_state
--skyframe_high_water_mark_threshold=<an integer>
डिफ़ॉल्ट: "85"-
Bzel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर Bazel को पता चलता है कि उसके बरकरार रखे गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड के बराबर है, तो यह बेवजह अस्थायी स्काईफ़्रेम स्थिति को छोड़ देगा. इसे ट्वीक करने से, (i) इस अस्थायी स्थिति के मेमोरी इस्तेमाल की वजह से जीसी थ्रैशिंग (जीसी) में होने वाले समय के असर को कम किया जा सकता है और (ii) ज़रूरत पड़ने पर स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगाई हो सकती है.
टैग:host_machine_resource_optimizations
--[no]track_incremental_state
डिफ़ॉल्ट: "सही"-
गलत होने पर, Blaze ऐसे डेटा को सेव नहीं रखेगा जो इंक्रीमेंटल (बढ़ने वाले) बिल्ड को अमान्य और फिर से जांचने की अनुमति देता है, ताकि इस बिल्ड की मेमोरी बचाई जा सके. इसके बाद के बिल्ड में कोई बढ़ोतरी नहीं होगी. आम तौर पर, इसे 'गलत' पर सेट करते समय --बैच के बारे में बताना होगा.
टैग:loses_incremental_state
- ऐसे विकल्प जो जानकारी डालने की जगह, फ़ॉर्मैट या जगह की जानकारी पर असर डालते हैं:
--[no]announce_rc
डिफ़ॉल्ट: "false"-
आरसी के विकल्पों का एलान करना है या नहीं.
टैग:affects_outputs
--[no]attempt_to_print_relative_paths
डिफ़ॉल्ट: "false"-
मैसेज के जगह की जानकारी वाला हिस्सा प्रिंट करते समय, फ़ाइल फ़ोल्डर की डायरेक्ट्री या --package_path से तय की गई किसी डायरेक्ट्री से संबंधित पाथ का इस्तेमाल करें.
टैग:terminal_output
--bes_backend=<a string>
डिफ़ॉल्ट: ""-
[SCHEME://]Host[:port] के तौर पर बिल्ड इवेंट सेवा (BES) बैकएंड एंडपॉइंट के बारे में बताता है. यह डिफ़ॉल्ट तौर पर, BES अपलोड को बंद करता है. काम करने वाली स्कीम, grpc और grpcs (टीएलएस की सुविधा वाले जीआरपीसी) हैं. अगर कोई स्कीम नहीं दी जाती है, तो Bazel grpcs को मान लेता है.
टैग:affects_outputs
--[no]bes_check_preceding_lifecycle_events
डिफ़ॉल्ट: "false"-
PublisherBuildToolEventStreamRequest पर चेक_preceding_lifecycle_events_present फ़ील्ड को सेट करता है. इसकी मदद से, BES को यह पता चलता है कि मौजूदा टूल इवेंट से मेल खाने वाले, पहले InvocationctStarted और BuildEnqueued इवेंट मिले हैं या नहीं.
टैग:affects_outputs
- ऐप्लिकेशन के
--bes_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
NAME=VALUE फ़ॉर्म में एक हेडर तय करें, जिसे BES अनुरोधों में शामिल किया जाएगा. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
टैग:affects_outputs
--bes_instance_name=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
उस इंस्टेंस का नाम बताता है जिसके तहत बीईएस, अपलोड किए गए बीईपी को बनाए रखेगा. डिफ़ॉल्ट तौर पर, यह वैल्यू शून्य पर सेट होती है.
टैग: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 मिनट"-
यह तय करता है कि ओओएमिंग के दौरान, बेज़ल को बीईएस/बीईपी के अपलोड होने तक कितना इंतज़ार करना चाहिए. यह फ़्लैग पक्का करता है कि जब जेवीएम बहुत ज़्यादा जीसी थ्रैशिंग करता है और किसी भी उपयोगकर्ता थ्रेड पर आगे नहीं बढ़ सकता है.
टैग: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>
डिफ़ॉल्ट: ""-
उस बेस यूआरएल के बारे में बताता है जहां उपयोगकर्ता, BES बैकएंड पर स्ट्रीम की गई जानकारी देख सकता है. Bazel, कॉल करने वाले आईडी से टर्मिनल पर जोड़े गए यूआरएल को आउटपुट करेगा.
टैग:terminal_output
--bes_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "0s"-
यह बताता है कि बिल्ड और टेस्ट खत्म होने के बाद, बेज़ल को BES/BEP अपलोड होने तक कितना इंतज़ार करना चाहिए. समय खत्म होने की मान्य संख्या वह संख्या होती है जिसके बाद एक इकाई होती है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (मिलीसेकंड). डिफ़ॉल्ट वैल्यू '0' है. इसका मतलब है कि कोई टाइम आउट नहीं है.
टैग:affects_outputs
--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_json_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो उस फ़ाइल में बिल्ड इवेंट प्रोटोकॉल का JSON सीरियलाइज़ेशन लिखें.
टैग:affects_outputs
--[no]build_event_json_file_path_conversion
डिफ़ॉल्ट: "सही"-
जब भी मुमकिन हो, बिल्ड इवेंट प्रोटोकॉल के json फ़ाइल वर्शन में मौजूद पाथ को दुनिया भर में मान्य यूआरआई में बदलें. अगर यह सुविधा बंद है, तो हमेशा file:// uri स्कीम का इस्तेमाल किया जाएगा
टैग:affects_outputs
--build_event_max_named_set_of_file_entries=<an integer>
डिफ़ॉल्ट: "-1"-
किसी एक name_set_of_files इवेंट के लिए एंट्री की ज़्यादा से ज़्यादा संख्या; दो से छोटी वैल्यू को अनदेखा किया जाता है और इवेंट को अलग-अलग हिस्सों में नहीं बांटा जाता. यह बिल्ड इवेंट प्रोटोकॉल में ज़्यादा से ज़्यादा इवेंट साइज़ को सीमित करने के लिए है. हालांकि, यह सीधे तौर पर इवेंट साइज़ को कंट्रोल नहीं करता. इवेंट का कुल साइज़, सेट के स्ट्रक्चर के साथ-साथ फ़ाइल और यूआरआई की लंबाई पर निर्भर करता है. यह हैश फ़ंक्शन पर निर्भर कर सकता है.
टैग:affects_outputs
--[no]build_event_publish_all_actions
डिफ़ॉल्ट: "false"-
क्या सभी कार्रवाइयां पब्लिश की जानी चाहिए.
टैग:affects_outputs
--build_event_text_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो उस फ़ाइल में बिल्ड इवेंट प्रोटोकॉल को टेक्स्ट के तौर पर लिखें
टैग:affects_outputs
--[no]build_event_text_file_path_conversion
डिफ़ॉल्ट: "सही"-
जब भी मुमकिन हो, बिल्ड इवेंट प्रोटोकॉल के टेक्स्ट फ़ाइल में मौजूद पाथ को दुनिया भर में मान्य यूआरआई में बदलें. अगर यह सुविधा बंद है, तो हमेशा file:// uri स्कीम का इस्तेमाल किया जाएगा
टैग:affects_outputs
--[no]experimental_announce_profile_path
डिफ़ॉल्ट: "false"-
चालू होने पर, लॉग में JSON प्रोफ़ाइल पाथ जोड़ता है.
टैग:affects_outputs
,bazel_monitoring
--[no]experimental_bep_target_summary
डिफ़ॉल्ट: "false"- Targetsummary इवेंट को पब्लिश करना है या नहीं.
--[no]experimental_build_event_expand_filesets
डिफ़ॉल्ट: "false"-
अगर सही हो, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, BEP में फ़ाइलसेट को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "false"-
अगर सही है, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी में मिलते-जुलते फ़ाइलसेट सिमलिंक को पूरी तरह ठीक करें. --experimental_build_event_expand_filesets की ज़रूरत है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
Bzel को बिल्ड इवेंट को ज़्यादा से ज़्यादा कितनी बार अपलोड करने की कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
डिफ़ॉल्ट: "1s"-
शुरू में, बीईपी अपलोड न होने पर, एक्सपोनेन्शियल बैकऑफ़ फिर से होने में कम से कम देरी. (exponent: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
चुनें कि बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को कैसे अपलोड करें.
टैग:affects_outputs
- ऐप्लिकेशन के
--experimental_profile_additional_tasks=<phase, action, action_check, action_lock, action_release, action_update, action_complete, info, create_package, remote_execution, local_execution, scanner, local_parse, upload_time, process_time, remote_queue, remote_setup, fetch, 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, local_cpu_usage, system_cpu_usage, local_memory_usage, system_memory_usage, 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 or unknown>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
प्रोफ़ाइल में शामिल किए जाने वाले कुछ अन्य टास्क के बारे में बताता है.
टैग:affects_outputs
,bazel_monitoring
--[no]experimental_profile_include_primary_output
डिफ़ॉल्ट: "false"-
कार्रवाई इवेंट में अतिरिक्त "out" एट्रिब्यूट शामिल करता है, जिसमें कार्रवाई के मुख्य आउटपुट का एक्ज़ीक्यूट पाथ होता है.
टैग:affects_outputs
,bazel_monitoring
--[no]experimental_profile_include_target_label
डिफ़ॉल्ट: "false"-
ऐक्शन इवेंट के JSON प्रोफ़ाइल डेटा में टारगेट लेबल शामिल होता है.
टैग:affects_outputs
,bazel_monitoring
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "false"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग:affects_outputs
--experimental_workspace_rules_log_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- Workspace के कुछ नियमों वाले इवेंट को इस फ़ाइल में, सीमांकित WorkspaceEvent प्रोटो के तौर पर लॉग करें.
--[no]generate_json_trace_profile
डिफ़ॉल्ट: "ऑटो"-
अगर चालू किया जाता है, तो Bazel, बिल्ड का प्रोफ़ाइल तैयार करता है और आउटपुट बेस में, फ़ाइल में JSON-फ़ॉर्मैट वाली प्रोफ़ाइल लिखता है. chrome://tracing में लोड करके प्रोफ़ाइल देखें. डिफ़ॉल्ट रूप से, Bazel सभी बिल्ड जैसे कमांड और क्वेरी के लिए प्रोफ़ाइल लिखता है.
टैग:affects_outputs
,bazel_monitoring
--[no]heap_dump_on_oom
डिफ़ॉल्ट: "false"-
अगर किसी ओओएम को फेंका जाता है, तो मैन्युअल तौर पर हीप डंप आउटपुट करना है या नहीं (-प्रयोगात्मक_oom_more_eagerly_threshold की वजह से होने वाले ओओएम भी शामिल हैं). डंप को <internal_base>/<invocation_id>.heapdump.hprof पर लिखा जाएगा. यह विकल्प, -XX:+HeapDumpOnOutOfMemoryError को असरदार ढंग से बदल देता है, जिससे कोई असर नहीं पड़ता, क्योंकि ओओएम को पकड़ा जाता है और उन्हें Runtime#halt पर रीडायरेक्ट कर दिया जाता है.
टैग:bazel_monitoring
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
TargetComplete इवेंट में, लेगसी key_OUTs फ़ील्ड को जनरेट होने की प्रोसेस को रोकने के लिए इसका इस्तेमाल करें. Bazel और resultsStore इंटिग्रेशन के लिए, आने वाले ज़रूरी टूल ज़रूरी हैं.
टैग:affects_outputs
--logging=<0 <= an integer <= 6>
डिफ़ॉल्ट: "3"-
लॉगिन करने का लेवल.
टैग:affects_outputs
--memory_profile=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर सेट किया जाता है, तो फ़ेज़ खत्म होने पर, तय की गई फ़ाइल में मेमोरी के इस्तेमाल का डेटा लिखें. साथ ही, बिल्ड के आखिर में लॉग को मास्टर करने के लिए स्टेबल हीप का इस्तेमाल करें.
टैग:affects_outputs
,bazel_monitoring
--memory_profile_stable_heap_parameters=<two integers, separated by a comma>
डिफ़ॉल्ट: "1,0"-
बिल्ड के आखिर में, मेमोरी प्रोफ़ाइल में स्टेबल हीप के हिसाब से कैलकुलेशन को ट्यून करें. यह कॉमा से अलग किए गए दो पूर्णांक होने चाहिए. पहला पैरामीटर, GCs की संख्या है. जीसी के बीच इंतज़ार करने के लिए, सेकंड की संख्या को दूसरा पैरामीटर कहा जाता है.
टैग:bazel_monitoring
--profile=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर सेट हो, तो Bazel को प्रोफ़ाइल करें और तय की गई फ़ाइल में डेटा लिखें. प्रोफ़ाइल का विश्लेषण करने के लिए, bazelAnalyze-profile का इस्तेमाल करें.
टैग:affects_outputs
,bazel_monitoring
--[no]slim_profile
डिफ़ॉल्ट: "सही"-
अगर प्रोफ़ाइल का साइज़ ज़्यादा बड़ा हो जाता है, तो इवेंट को मर्ज करके, JSON प्रोफ़ाइल के साइज़ को छोटा किया जा सकता है.
टैग:affects_outputs
,bazel_monitoring
--starlark_cpu_profile=<a string>
डिफ़ॉल्ट: ""-
बताई गई फ़ाइल में सभी Starlark थ्रेड के लिए, सीपीयू के इस्तेमाल की एक pprof प्रोफ़ाइल लिखता है.
टैग:bazel_monitoring
--tool_tag=<a string>
डिफ़ॉल्ट: ""-
इस Bazel बातचीत को एट्रिब्यूट करने के लिए टूल का नाम.
टैग:affects_outputs
,bazel_monitoring
- ऐप्लिकेशन के
--ui_event_filters=<Convert list of comma separated event kind to list of filters>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
तय करता है कि यूज़र इंटरफ़ेस (यूआई) में कौनसे इवेंट दिखाए जाएं. लीडिंग +/- का इस्तेमाल करके डिफ़ॉल्ट सेट में इवेंट जोड़े या हटाए जा सकते हैं. इसके अलावा, सीधे तौर पर असाइन करने की सुविधा के साथ डिफ़ॉल्ट सेट को पूरी तरह से बदला जा सकता है. काम करने वाले इवेंट टाइप के सेट में INFO, DEBUG, गड़बड़ी वगैरह शामिल हैं.
टैग:terminal_output
- दूसरे विकल्प, जिन्हें अलग से कैटगरी में नहीं बांटा गया है.:
- ऐप्लिकेशन के
--build_metadata=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
बिल्ड इवेंट में सप्लाई करने के लिए, कस्टम की-वैल्यू स्ट्रिंग पेयर.
टैग:terminal_output
--color=<yes, no or auto>
डिफ़ॉल्ट: "ऑटो"- आउटपुट में रंग भरने के लिए, टर्मिनल कंट्रोल का इस्तेमाल करें.
- ऐप्लिकेशन के
--config=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - आरसी फ़ाइलों से अतिरिक्त कॉन्फ़िगरेशन सेक्शन चुनता है; हर <command> के लिए, अगर ऐसा सेक्शन मौजूद होता है, तो यह <command>:<config> से विकल्प भी चुन लेता है; अगर यह सेक्शन किसी भी .rc फ़ाइल में मौजूद नहीं है, तो Blaze गड़बड़ी के साथ काम नहीं करेगा. कॉन्फ़िगरेशन सेक्शन और फ़्लैग के कॉम्बिनेशन, टूल/*.blazerc कॉन्फ़िगरेशन फ़ाइलों में मौजूद हैं.
--curses=<yes, no or auto>
डिफ़ॉल्ट: "ऑटो"- स्क्रोल करने वाले आउटपुट को कम से कम करने के लिए, टर्मिनल कर्सर के कंट्रोल का इस्तेमाल करें.
--[no]enable_platform_specific_config
डिफ़ॉल्ट: "false"- अगर सही है, तो Bazel bazelrc फ़ाइलों से, होस्ट-ओएस के हिसाब से कॉन्फ़िगर की जाने वाली लाइनों का इस्तेमाल करेगा. उदाहरण के लिए, अगर होस्ट ओएस, Linux है और आपके पास bazel बिल्ड चलाने का विकल्प है, तो Bazel, बिल्ड:Linux से शुरू होने वाली लाइनें चुनता है. काम करने वाले OS आइडेंटिफ़ायर, linux, macos, windows, freebsd, और Openbsd हैं. इस फ़्लैग को चालू करना, Linux पर --config=linux, Windows पर --config=windows वगैरह का इस्तेमाल करने के बराबर है.
- ऐप्लिकेशन के
--experimental_credential_helper=<An (unresolved) path to a credential helper for a scope.>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि दिए गए स्कोप (डोमेन) के लिए क्रेडेंशियल वापस पाने में उसका इस्तेमाल किया जा सके. क्रेडेंशियल हेल्पर के क्रेडेंशियल को <code>--google_default_credentials</code>, `--google_क्रेडेंशियल` या <code>.netrc</code> से ज़्यादा अहमियत दी जाती है. https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-Credential-helpers की जानकारी देखें.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मिनट"- उस अवधि को कॉन्फ़िगर करता है जिसके लिए क्रेडेंशियल हेल्पर के क्रेडेंशियल, कैश मेमोरी में सेव किए जाते हैं. किसी दूसरी वैल्यू से शुरू करने पर, पहले से मौजूद एंट्री का लाइफ़टाइम बदल जाएगा; कैश मेमोरी मिटाने के लिए शून्य पास करें. क्लीन कमांड, कैश मेमोरी को हमेशा मिटाता है, भले ही यह फ़्लैग किसी भी तरह का हो.
--experimental_credential_helper_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "5s"- क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. क्रेडेंशियल सहायक इस टाइम आउट के अंदर जवाब नहीं दे पाने पर, बातचीत शुरू नहीं कर पाएंगे.
--[no]experimental_skymeld_ui
डिफ़ॉल्ट: "false"-
जब दोनों प्रोसेस एक साथ चल रही हों, तब विश्लेषण और एक्ज़ीक्यूट करने के चरण की प्रोग्रेस, दोनों को दिखाता है.
टैग:terminal_output
--[no]experimental_windows_watchfs
डिफ़ॉल्ट: "false"- अगर सही है, तो --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
डिफ़ॉल्ट: "false"- पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं. डिफ़ॉल्ट रूप से बंद होता है.
--grpc_keepalive_time=<An immutable length of time.>
डिफ़ॉल्ट: ब्यौरा देखें- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो Bazel इतने समय बाद कनेक्शन पर कोई कार्रवाई नहीं करने के बाद पिंग भेजता है. यह सिर्फ़ तब पिंग करता है, जब कम से कम एक gRPC कॉल लंबित हो. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. कीप-अलाइव पिंग, डिफ़ॉल्ट रूप से बंद रहते हैं. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक से संपर्क करना होगा. उदाहरण के लिए, इस फ़्लैग के लिए 30 सेकंड की वैल्यू सेट करने के लिए, इस तरह से सेट करना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "20 सेकंड"- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव (चालू रखें) टाइम आउट कॉन्फ़िगर करता है. अगर कीप-अलाइव पिंग को --grpc_keepalive_time से चालू किया जाता है, तो Bazel को इतने समय के बाद पिंग का जवाब न मिलने पर, कनेक्शन बंद कर दिया जाता है. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. अगर कीप-अलाइव पिंग को बंद रखा जाता है, तो इस सेटिंग को अनदेखा कर दिया जाता है.
--[no]incompatible_disallow_symlink_file_to_dir
डिफ़ॉल्ट: "सही"-
अगर नीति को 'सही है' पर सेट किया जाता है, तो `ctx.actions.symlink` उस फ़ाइल को डायरेक्ट्री में सिमलिंक करने की अनुमति नहीं देगा.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_rule_name_parameter
डिफ़ॉल्ट: "सही"-
अगर 'सही है' पर सेट किया जाता है, तो `नियम` को `name` पैरामीटर के साथ कॉल नहीं किया जा सकता.
टैग:loading_and_analysis
,incompatible_change
--[no]progress_in_terminal_title
डिफ़ॉल्ट: "false"- टर्म के टाइटल में कमांड की प्रोग्रेस दिखाएं. यह देखने के लिए उपयोगी है कि कई टर्मिनल टैब होने पर bazel क्या काम कर रहा है.
--[no]show_progress
डिफ़ॉल्ट: "सही"- बिल्ड के दौरान प्रोग्रेस मैसेज दिखाता है.
--show_progress_rate_limit=<a double>
डिफ़ॉल्ट: "0.2"- आउटपुट में प्रोग्रेस मैसेज के बीच, कम से कम सेकंड.
--[no]show_timestamps
डिफ़ॉल्ट: "false"- मैसेज में टाइमस्टैंप शामिल करें
--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
डिफ़ॉल्ट: "false"- Linux/macOS पर: सही होने पर, bazel स्थानीय बदलावों के लिए हर फ़ाइल को स्कैन करने के बजाय, ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करता है. Windows पर: फ़िलहाल, यह फ़्लैग एक नॉन-ऑप नहीं है, लेकिन इसे --experimental_window_watchfs के साथ इस्तेमाल किया जा सकता है. किसी भी ओएस पर: अगर आपका फ़ाइल फ़ोल्डर नेटवर्क फ़ाइल सिस्टम पर है और फ़ाइलों में किसी रिमोट मशीन पर बदलाव किया जाता है, तो व्यवहार तय नहीं होता.
प्रोफ़ाइल का विश्लेषण करने के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--dump=<text or raw>
[-d
] डिफ़ॉल्ट: ब्यौरा देखें-
आउटपुट प्रोफ़ाइल का डेटा डंप, जिसे लोग आसानी से पढ़ सकते हैं 'टेक्स्ट' फ़ॉर्मैट या स्क्रिप्ट-फ़्रेंडली 'रॉ' फ़ॉर्मैट.
टैग:affects_outputs
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
क्वेरी के विकल्प
build के सभी विकल्प इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:
--aspect_deps=<off, conservative or precise>
डिफ़ॉल्ट: "कंज़र्वेटिव"-
जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तो आसपेक्ट डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि तय की गई सभी पहलू डिपेंडेंसी जोड़ी जाती हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के नियम की कैटगरी दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम की क्लास के आधार पर ऐक्टिव होते हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट की जांच करने के लिए, अन्य पैकेज लोड करने ज़रूरी होते हैं. इस वजह से, यह अन्य मोड की तुलना में धीमा हो जाता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता है: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह प्रोसेस, 'bazel क्वेरी' के दौरान नहीं चलती.
टैग:build_file_semantics
--[no]deduplicate_depsets
डिफ़ॉल्ट: "सही"-
फ़ाइनल Proto/textproto/json आउटपुट में, dep_set_of_files के बच्चों की नॉन-लीफ़ फ़ाइलों की डुप्लीकेट कॉपी हटाएं. यह उन साइटों की डुप्लीकेट कॉपी नहीं बनाती है जो किसी मौजूदा अभिभावक को शेयर नहीं करती हैं. इससे, कार्रवाइयों के इनपुट आर्टफ़ैक्ट की फ़ाइनल असरदार सूची पर कोई असर नहीं पड़ता.
टैग:terminal_output
--[no]graph:factored
डिफ़ॉल्ट: "सही"-
सही होने पर, ग्राफ़ पर 'फ़ैक्टर' निकाला जाएगा. इसका मतलब है कि टॉपॉलॉजिकली इक्विलंट नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल जोड़ दिए जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--graph:node_limit=<an integer>
डिफ़ॉल्ट: "512"-
आउटपुट में, ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि कोई काट-छांट नहीं की जाएगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--[no]implicit_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel के ज़रिए जोड़ा गया है. cquery के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग:build_file_semantics
--[no]include_artifacts
डिफ़ॉल्ट: "सही"-
इससे आउटपुट में, ऐक्शन इनपुट और आउटपुट के नाम शामिल होते हैं (अनुमानित रूप से बड़ा).
टैग:terminal_output
--[no]include_aspects
डिफ़ॉल्ट: "सही"-
क्वेरी, cquery: आउटपुट में पक्ष से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (निर्देशों को हमेशा अपनाया जाता है).
टैग:terminal_output
--[no]include_commandline
डिफ़ॉल्ट: "सही"-
आउटपुट में, ऐक्शन कमांड लाइन का कॉन्टेंट शामिल होता है (अनुमानित रूप से बड़ा).
टैग:terminal_output
--[no]include_file_write_contents
डिफ़ॉल्ट: "false"-
FileWrite और SourceSymlinkManifest की कार्रवाइयों (संभावित रूप से बड़ा) के लिए, फ़ाइल का कॉन्टेंट शामिल करें.
टैग:terminal_output
--[no]include_param_files
डिफ़ॉल्ट: "false"-
कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें (अनुमानित रूप से बड़ा). ध्यान दें: इस फ़्लैग को चालू करने पर --include_commandline फ़्लैग अपने-आप चालू हो जाएगा.
टैग:terminal_output
--[no]incompatible_display_source_file_location
डिफ़ॉल्ट: "सही"-
डिफ़ॉल्ट रूप से 'सही', सोर्स फ़ाइल का टारगेट दिखाता है. सही होने पर, लोकेशन आउटपुट में सोर्स फ़ाइलों की लाइन 1 की जगह दिखाता है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग:terminal_output
,incompatible_change
--[no]incompatible_package_group_includes_double_slash
डिफ़ॉल्ट: "सही"-
इस सुविधा को चालू करने पर, Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, पहले `//` की वैल्यू नहीं छोड़ी जाएगी.
टैग:terminal_output
,incompatible_change
--[no]infer_universe_scope
डिफ़ॉल्ट: "false"-
अगर सेट और --universe_scope को सेट नहीं किया जाता है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे कि`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई --universe_scope वैल्यू, शायद आपकी पसंद के मुताबिक न हो. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/query/language#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` (जैसे कि `cquery` पर नहीं) पर लागू होता है.
टैग:loading_and_analysis
--[no]line_terminator_null
डिफ़ॉल्ट: "false"-
हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाए या नहीं.
टैग:terminal_output
--[no]nodep_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, "nodep" एट्रिब्यूट की वैल्यू को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा, जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडेप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग:build_file_semantics
--output=<a string>
डिफ़ॉल्ट: "text"-
वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. aquery के लिए इन वैल्यू को इस्तेमाल किया जा सकता है: text, textproto, proto, jsonproto.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग:terminal_output
पर लागू होता है
--[no]proto:definition_stack
डिफ़ॉल्ट: "false"-
definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें, जो नियम की क्लास तय किए जाने के समय Starlark कॉल स्टैक के हर नियम के लिए रिकॉर्ड करता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, Select() के ज़रिए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट फ़्लैट कर दिए जाते हैं. सूची के टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन वह सूची है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप शून्य तक चपटे हो जाते हैं.
टैग:build_file_semantics
--[no]proto:include_synthetic_attribute_hash
डिफ़ॉल्ट: "false"- $internal_attr_hh एट्रिब्यूट का हिसाब लगाने और उसे पॉप्युलेट करने या न करने का विकल्प.
टैग:terminal_output
--[no]proto:instantiation_stack
डिफ़ॉल्ट: "false"-
हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग:terminal_output
--[no]proto:locations
डिफ़ॉल्ट: "सही"-
प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग:terminal_output
--proto:output_rule_attrs=<comma-separated list of options>
डिफ़ॉल्ट: "सभी"-
आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. किसी भी एट्रिब्यूट का आउटपुट न देने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --OUT=proto पर लागू होता है.
टैग:terminal_output
--[no]proto:rule_inputs_and_outputs
डिफ़ॉल्ट: "सही"-
रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग:terminal_output
--[no]relative_locations
डिफ़ॉल्ट: "false"-
सही होने पर, एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह तय होगी. डिफ़ॉल्ट रूप से, लोकेशन आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग:terminal_output
--[no]skyframe_state
डिफ़ॉल्ट: "false"-
ज़्यादा विश्लेषण किए बिना, Skyframe के मौजूदा ऐक्शन ग्राफ़ को डंप करें. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय करने की सुविधा काम नहीं करती. यह फ़्लैग सिर्फ़ --आउटपुट=प्रोटो या --आउटपुट=textproto के साथ उपलब्ध होता है.
टैग:terminal_output
--[no]tool_deps
डिफ़ॉल्ट: "सही"-
क्वेरी: बंद होने पर, 'होस्ट कॉन्फ़िगरेशन' या 'एक्ज़ीक्यूशन' टारगेट की डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाता जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर को मिलने वाला किनारा. आम तौर पर, यह उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, उस टूल के बारे में बताता है जिसे बिल्ड के दौरान लागू किया जाता है.
Cquery: बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट का पता लगाने वाले टॉप लेवल टारगेट से, होस्ट या एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. साथ ही, टारगेट कॉन्फ़िगरेशन में भी कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट ही दिखेंगे. इस विकल्प में, ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग:build_file_semantics
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का सेट, कॉमा लगाकर अलग किया गया. इसमें योग और घटाव वाले पैटर्न शामिल होते हैं. क्वेरी को संसार में निष्पादित किया जा सकता है, जबकि बताए गए लक्ष्यों के ट्रांज़िटिव बंद होने से परिभाषित होता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है.
cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब तैयार किए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट मान लिया जाता है. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए इस विकल्प को तय न करने से बिल्ड टूट सकता है.
टैग:loading_and_analysis
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]experimental_inprocess_symlink_creation
डिफ़ॉल्ट: "false"-
सिमलिंक ट्री बनाने के लिए, डायरेक्ट फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_remotable_source_manifests
डिफ़ॉल्ट: "false"-
सोर्स मेनिफ़ेस्ट कार्रवाइयों को फिर से चालू करना है या नहीं
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_split_coverage_postprocessing
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel एक नए स्पैम में जांच के लिए, कवरेज पोस्टप्रोसेसिंग करेगा.
टैग:execution
--[no]experimental_strict_fileset_output
डिफ़ॉल्ट: "false"-
अगर यह विकल्प चालू किया जाता है, तो फ़ाइलसेट, सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री को नहीं पीछे छोड़ते या सिमलिंक के प्रति संवेदनशील नहीं होते.
टैग:execution
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...>
डिफ़ॉल्ट: ""-
कार्रवाई के बाद की जाने वाली कार्रवाई की जानकारी में, कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो एक्ज़ीक्यूट करने की जानकारी देती हैं. कई आम कार्रवाइयां, एक्ज़ीक्यूट करने की जानकारी के साथ काम करती हैं, जैसे कि Genrun, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय ऑर्डर देना ज़रूरी होता है, क्योंकि एक ही मिनिमनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.
सिंटैक्स: "regex=[+-]key,regex=[+-]key,...".
उदाहरण:
'.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के चलने की जानकारी में, 'x' और 'z' जोड़ता है और 'y' को हटा देता है.
'GenTerms=+requires-x', जेनरूल की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूटिंग की जानकारी में 'requires-x' जोड़ता है.
'(?!GenTerms).*=-requires-x', सभी गैर-जेनरूल कार्रवाइयों के लिए, निष्पादन जानकारी से 'requires-x' को हटा देता है.
टैग:execution
,affects_outputs
,loading_and_analysis
--persistent_android_dex_desugar
-
कर्मचारियों का इस्तेमाल करके, स्थायी Android dex और Desugar कार्रवाइयों को चालू करें.
इसमें बड़ा होता है:
--strategy=Desugar=worker
--strategy=DexBuilder=worker
टैग:host_machine_resource_optimizations
,execution
--persistent_android_resource_processor
-
कर्मचारियों का इस्तेमाल करके, स्थायी Android संसाधन प्रोसेसर चालू करें.
यह इन जगहों तक फैलता है:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
--strategy=Aapt2Optimize=worker
--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
host_machine_resource_optimizations
execution
--persistent_multiplex_android_dex_desugar
-
कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android dex और desugar ऐक्शन चालू करें.
यह इन जगहों पर फैलता है:
--persistent_android_dex_desugar
--modify_execution_info=Desugar=+supports-multiplex-workers
--modify_execution_info=DexBuilder=+supports-multiplex-workers
टैग:host_machine_resource_optimizations
,execution
--persistent_multiplex_android_resource_processor
-
कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android रिसॉर्स प्रोसेसर को चालू करें.
यह इन जगहों तक फैलता है:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers
host_machine_resource_optimizations
execution
--persistent_multiplex_android_tools
-
Android के स्थायी और मल्टीप्लेक्स टूल चालू करें. जैसे- डेक्सिंग, डीयूगरिंग, और रिसॉर्स प्रोसेसिंग.
यह इन तक फैलता है:
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
- कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:
--android_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Android का टारगेट कंपाइलर.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_crosstool_top=<a build target label>
डिफ़ॉल्ट: "//external:android/crosstool"-
Android बिल्ड के लिए इस्तेमाल किए गए C++ कंपाइलर की जगह की जानकारी.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_manifest_merger=<legacy, android or force_android>
डिफ़ॉल्ट: "android"-
android_binary नियमों के लिए इस्तेमाल किए जाने वाले मेनिफ़ेस्ट मर्जर को चुनता है. फ़्लैग करें, ताकि पुराने मर्जर की मदद से, Android मेनिफ़ेस्ट को मर्ज करने में मदद मिल सके.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_platforms=<a build target label>
डिफ़ॉल्ट: ""-
ऐसे प्लैटफ़ॉर्म सेट करता है जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी फ़ाइल एक फ़ैट APKs होती है. इसमें, बताए गए हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_sdk=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk"-
उस Android SDK/प्लैटफ़ॉर्म के बारे में बताता है जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--apple_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Apple का टारगेट कंपाइलर. इसकी मदद से, टूलचेन के वैरिएंट चुने जा सकते हैं. उदाहरण के लिए, xcode-beta.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--apple_crosstool_top=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"-
Apple औरobjc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग:loses_incremental_state
,changes_inputs
--apple_grte_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
Apple का टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--cc_output_directory_tag=<a string>
डिफ़ॉल्ट: ""-
कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने के लिए सफ़िक्स के बारे में जानकारी देता है.
टैग:affects_outputs
,explicit_in_output_path
--compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग:loading_and_analysis
,execution
--coverage_output_generator=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_ सुझावों"-
रॉ कवरेज रिपोर्ट को पोस्ट करने के लिए इस्तेमाल होने वाली बाइनरी की जगह. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcov_ सुझावों' का इस्तेमाल करता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_report_generator=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_report_generator"-
कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:coverage_report_generator' होता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_support=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_support"-
उन सहायता फ़ाइलों की जगह जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई के इनपुट के लिए ज़रूरी होती हैं. डिफ़ॉल्ट रूप से '//tools/test:coverage_support' सेट होता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--crosstool_top=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"-
C++ कोड को कंपाइल करने के लिए इस्तेमाल होने वाले क्रॉसटूल पैकेज का लेबल.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--custom_malloc=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
यह तय करता है कि कस्टम Maloc लागू करने की सुविधा कैसे लागू की जाए. यह सेटिंग, बिल्ड के नियमों में मॉलक एट्रिब्यूट को बदल देती है.
टैग:changes_inputs
,affects_outputs
- ऐप्लिकेशन के
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के आगे - (नेगेटिव एक्सप्रेशन) लगाया जाएगा. साथ ही, इन्हें कॉमा लगाकर अलग किए गए कंस्ट्रेंट वैल्यू के टारगेट की सूची में (=) असाइन किया जाएगा. अगर कोई टारगेट, किसी भी नेगेटिव एक्सप्रेशन से मेल नहीं खाता और कम से कम एक पॉज़िटिव एक्सप्रेशन से मैच करता है, तो इसका टूलचेन रिज़ॉल्यूशन इस तरह परफ़ॉर्म किया जाएगा जैसे कि कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर बताया गया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64 //demo के तहत आने वाले किसी भी टारगेट में 'x86_64' जोड़ देगा, लेकिन इनके नाम में 'test' शामिल नहीं होगा.
टैग:loading_and_analysis
--[no]experimental_enable_objc_cc_deps
डिफ़ॉल्ट: "सही"-
यह objc_* नियमों को cc_library पर निर्भर करने की अनुमति देता है. साथ ही, इसकी वजह से कोई भी ऑब्जेसी डिपेंडेंसी --iOS_multi_cpu> में किसी भी वैल्यू के लिए --cpu को "ios_<--ios_cpu>" पर सेट करने के लिए सेट होती है.
टैग:loading_and_analysis
,incompatible_change
--[no]experimental_include_xcode_execution_requirements
डिफ़ॉल्ट: "false"-
अगर इस नीति को सेट किया जाता है, तो हर Xcode कार्रवाई के लिए "requires-xcode:{version}" को लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" चलाने की ज़रूरी शर्त भी जोड़ें.
टैग:loses_incremental_state
,loading_and_analysis
,execution
--[no]experimental_prefer_mutual_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 फ़ाइल में रजिस्टर करने वाले टूलचेन() से पहले किया जाएगा.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन में चुना जाता है और आपको इसे बदलने की ज़रूरत नहीं पड़ती.
टैग:action_command_lines
,affects_outputs
--host_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top को सेट नहीं किया गया है, तो इसे अनदेखा किया जाता है.
टैग:loading_and_analysis
,execution
--host_crosstool_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
डिफ़ॉल्ट रूप से, होस्ट कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler के विकल्पों का इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया गया है, तो Bazel, दिए गए Crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--host_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताया गया है, तो यह सेटिंग, होस्ट कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग:action_command_lines
,affects_outputs
--host_platform=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--[no]incompatible_disable_expand_if_all_available_in_flag_set
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel फ़्लैग_sets में expand_if_all_available को तय करने की अनुमति नहीं देगा(माइग्रेट करने से जुड़े निर्देशों के लिए https://github.com/bazelbuild/bazel/issues/7008 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'nonhost' सुविधाओं को चालू नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_android_toolchain_resolution
डिफ़ॉल्ट: "false"-
टूलचेन रिज़ॉल्यूशन का इस्तेमाल करके, Android के नियमों (Starlark और नेटिव) के लिए Android SDK चुनें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution
डिफ़ॉल्ट: "false"-
Apple SDK for apple के नियम (Starlark और local) चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, lto इंडेक्स करने वाली कमांड लाइनों के लिए, C++ लिंक की कार्रवाई वाली कमांड लाइन का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_cpu_and_compiler_attributes_from_cc_toolchain
डिफ़ॉल्ट: "सही"-
अगर सही है, तो cc_toolchain.cpu और cc_toolchain.compiler एट्रिब्यूट सेट होने पर Bazel शिकायत करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7075 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_legacy_whole_archive
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_require_ctx_in_configure_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel को cc_Common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 देखें).
टैग:loading_and_analysis
,incompatible_change
-
अगर टूलचेन पर इंटरफ़ेस के शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी ELF टूलचेन में यह सेटिंग काम करती है.
टैग:loading_and_analysis
,affects_outputs
,affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में बताता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिले iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
macOS ऐप्लिकेशन बनाने के लिए, macOS SDK टूल के वर्शन के बारे में जानकारी देता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से जुड़े macOS के SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--minimum_os_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह आपके कंपाइलेशन से टारगेट करता है, लेकिन ओएस का कम से कम वर्शन.
टैग:loading_and_analysis
,affects_outputs
--platform_mappings=<a relative path>
डिफ़ॉल्ट: ""-
मैपिंग फ़ाइल की जगह की जानकारी. इससे यह पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं किया गया है, तो किस प्लैटफ़ॉर्म का इस्तेमाल किया जाए या कोई प्लैटफ़ॉर्म पहले से मौजूद होने पर किस तरह के फ़्लैग सेट किए जाएं. मुख्य फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता होना चाहिए. डिफ़ॉल्ट तौर पर 'platform_mappings' (फ़ाइल फ़ोल्डर रूट के तहत आने वाली फ़ाइल).
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--platforms=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म की जानकारी देते हैं.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--python2_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से, यह सुविधा बंद है.
टैग:no_op
,deprecated
--python3_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अब काम नहीं करता. `--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 इंटरप्रेटर को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains इसकी मदद से बंद किया गया है.
टैग:loading_and_analysis
,affects_outputs
--target_platform_fallback=<a build target label>
डिफ़ॉल्ट: "@local_config_platform//:host"-
प्लैटफ़ॉर्म के नियम का लेबल. इसका इस्तेमाल तब किया जाना चाहिए, जब कोई टारगेट प्लैटफ़ॉर्म सेट न किया गया हो और कोई भी प्लैटफ़ॉर्म मैपिंग मौजूदा फ़्लैग से मेल न खाता हो.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह तय करता है कि किस वर्शन का इस्तेमाल करके, tvOS ऐप्लिकेशन बनाया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिलने वाले डिफ़ॉल्ट tvOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह WatchOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिलने वाले डिफ़ॉल्ट WatchOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--xcode_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताया गया है, तो सही बिल्ड ऐक्शन के लिए दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर इसकी जानकारी नहीं दी गई है, तो Xcode के एक्सक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xcode_version_config=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"-
xcode_config नियम का लेबल, बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए इस्तेमाल किया जाता है.
टैग:loses_incremental_state
,loading_and_analysis
- कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:
--[no]apple_enable_auto_dsym_dbg
डिफ़ॉल्ट: "false"-
dbg बिल्ड के लिए, डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलों) को जनरेट करना ज़बरदस्ती चालू करना है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]apple_generate_dsym
डिफ़ॉल्ट: "false"-
डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]build_runfile_links
डिफ़ॉल्ट: "सही"-
अगर सही है, तो रनफ़ाइलें बनाएं और सभी टारगेट के लिए जंगलों को सिमलिंक करें. गलत होने पर, जब भी हो सके, सिर्फ़ मेनिफ़ेस्ट लिखें.
टैग:affects_outputs
--[no]build_runfile_manifests
डिफ़ॉल्ट: "सही"-
अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह गलत है, तो उन्हें हटा दें. 'गलत' होने पर लोकल टेस्ट नहीं चलेंगे.
टैग:affects_outputs
--[no]build_test_dwp
डिफ़ॉल्ट: "false"-
इस सुविधा को चालू करने पर, स्टैटिक और फ़्रैक्शन के साथ C++ टेस्ट बनाते समय, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग:loading_and_analysis
,affects_outputs
--cc_proto_library_header_suffixes=<comma-separated list of options>
डिफ़ॉल्ट: ".pb.h"-
यह cc_proto_library बनाई जाने वाली हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग:affects_outputs
,loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated list of options>
डिफ़ॉल्ट: ".pb.cc"-
cc_proto_library से बनाई जाने वाली सोर्स फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info
डिफ़ॉल्ट: "false"-
proto_library में, वैकल्पिक Java एपीआई वर्शन के लिए, ज़्यादा कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_proto_extra_actions
डिफ़ॉल्ट: "false"-
proto_library में, वैकल्पिक Java एपीआई वर्शन के लिए, ज़्यादा कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_save_feature_state
डिफ़ॉल्ट: "false"-
चालू किए गए और अनुरोध किए गए फ़ंक्शन की स्थिति को कंपाइलेशन के आउटपुट के तौर पर सेव करें.
टैग:affects_outputs
,experimental
--fission=<a set of compilation modes>
डिफ़ॉल्ट: "नहीं"-
यह बताता है कि C++ के कंपाइलेशन और लिंक के लिए कौनसे कंपाइलेशन मोड, फ़ंक्शन का इस्तेमाल करते हैं. यह सभी मोड चालू करने के लिए {'Fastbuild', 'dbg', 'opt'} या विशेष वैल्यू 'yes' का कोई भी कॉम्बिनेशन और सभी मोड बंद करने के लिए 'no' हो सकता है.
टैग:loading_and_analysis
,action_command_lines
,affects_outputs
--[no]incompatible_always_include_files_in_data
डिफ़ॉल्ट: "सही"-
अगर सही है, तो नेटिव नियम अपनी रनफ़ाइल में <code>DefaultInfo.files</code> डेटा डिपेंडेंसी जोड़ देते हैं. यह डेटा, Starlark के नियमों (https://bazel.build/extending/rules#runfiles_features_to_avoid) के हिसाब से काम करता है.
टैग:affects_outputs
,incompatible_change
--[no]legacy_external_runfiles
डिफ़ॉल्ट: "सही"-
अगर सही है, तो .runfiles/wsname/external/repo के तहत, बाहरी डेटा स्टोर करने की जगहों के लिए रनफ़ाइल्स सिमलिंक जंगलों को बनाएं.
टैग:affects_outputs
--[no]objc_generate_linkmap
डिफ़ॉल्ट: "false"-
तय करता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग:affects_outputs
--[no]save_temps
डिफ़ॉल्ट: "false"-
अगर इस नीति को सेट किया जाता है, तो gcc से कुछ समय के लिए जनरेट होने वाले आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (पहले से प्रोसेस की गई C) और .ii फ़ाइलें (पहले से प्रोसेस की गई C++) शामिल हैं.
टैग:affects_outputs
- ऐसे विकल्प जो उपयोगकर्ता को सही आउटपुट को कॉन्फ़िगर करने देते हैं, उसकी वैल्यू पर असर होता है, जबकि इसकी वैल्यू पर असर नहीं पड़ता:
- ऐप्लिकेशन के
--action_env=<a 'name=value' assignment with an optional value part>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
टारगेट कॉन्फ़िगरेशन के साथ कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, वैल्यू को शुरू करने वाले एनवायरमेंट या नाम=वैल्यू के जोड़े से लिया जाएगा. इस पेयर की मदद से वैल्यू को, शुरू करने वाले एनवायरमेंट से अलग सेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत, अलग-अलग वैरिएबल के लिए उपलब्ध विकल्प.
टैग:action_command_lines
--android_cpu=<a string>
डिफ़ॉल्ट: "armeabi-v7a"-
Android टारगेट सीपीयू.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]android_databinding_use_androidx
डिफ़ॉल्ट: "false"-
AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]android_databinding_use_v3_4_args
डिफ़ॉल्ट: "false"-
3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--android_dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "बंद"-
यह तय करता है कि जब कोई cc_binary साफ़ तौर पर शेयर की गई लाइब्रेरी नहीं बनाता है, तो Android नियमों के C++ डेलिगेशन डाइनैमिक रूप से लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह चुनेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:affects_outputs
,loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>
डिफ़ॉल्ट: "वर्णमाला"-
Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्सक्लूट के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में, कॉन्फ़िगरेशन डायरेक्ट्री के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को हर लाइब्रेरी के मेनिफ़ेस्ट में क्रम से लगाया जाता है, जो उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आती है.
टैग:action_command_lines
,execution
--[no]android_resource_shrinking
डिफ़ॉल्ट: "false"-
यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को कम करने की सुविधा चालू करती है.
टैग:affects_outputs
,loading_and_analysis
- ऐप्लिकेशन के
--apple_bitcode=<'mode' or 'platform=mode', where 'mode' is none, embedded_markers or embedded, and 'platform' is ios, watchos, tvos, macos or catalyst>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
डिवाइस आर्किटेक्चर को टारगेट करने वाले कंपाइलेशन चरण के लिए, Apple बिटकोड मोड तय करें. वैल्यू, '[platform=]mode' फ़ॉर्म में हैं. इसमें प्लैटफ़ॉर्म वैकल्पिक है. जैसे, 'iOS', 'macos', 'tvos' या 'watchos'. अगर बिटकोड मोड दिया गया हो, तो खास तौर पर उस प्लैटफ़ॉर्म के लिए लागू किया जाता है. अगर इसे उपलब्ध नहीं कराया जाता है, तो यह सभी प्लैटफ़ॉर्म पर लागू होता है. मोड 'कोई नहीं', 'embed_markers' या 'एम्बेड किया गया' होना चाहिए. यह विकल्प कई बार दिया जा सकता है.
टैग:loses_incremental_state
--[no]build_python_zip
डिफ़ॉल्ट: "ऑटो"-
Python के लिए एक्ज़ीक्यूटेबल ज़िप बनाएं. Windows के लिए और दूसरे प्लैटफ़ॉर्म पर बंद करें
टैग:affects_outputs
- ऐप्लिकेशन के
--catalyst_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple Catalyst बाइनरी बनाने हैं.
टैग:loses_incremental_state
,loading_and_analysis
--[no]collect_code_coverage
डिफ़ॉल्ट: "false"-
अगर बताया जाएगा, तो Bazel, इंस्ट्रुमेंट कोड (जहां संभव हो ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) करेगा और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ --instrumentation_filter से मेल खाने वाले टारगेट ही प्रभावित होंगे. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए - इसकी जगह, 'bazeloverlay' कमांड का इस्तेमाल किया जाना चाहिए.
टैग:affects_outputs
--compilation_mode=<fastbuild, dbg or opt>
[-c
] डिफ़ॉल्ट: "Fastbuild"-
वह मोड तय करें जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग:affects_outputs
,action_command_lines
,explicit_in_output_path
- ऐप्लिकेशन के
--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
,explicit_in_output_path
--cs_fdo_absolute_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करके, कंपाइलेशन ऑप्टिमाइज़ करें. उस ZIP फ़ाइल के पूरे पाथ का नाम बताएं जिसमें प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल मौजूद हो.
टैग:affects_outputs
--cs_fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंटेशन वाली बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान हटाया जाएगा.
टैग:affects_outputs
--cs_fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली कॉन्टेक्स्ट सेंसिटिव प्रोफ़ाइल को दिखाने वाली cs_fdo_profile.
टैग:affects_outputs
- ऐप्लिकेशन के
--cxxopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--define=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
हर --define का विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है.
टैग:changes_inputs
,affects_outputs
--dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
यह तय करता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह चुनेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:loading_and_analysis
,affects_outputs
--[no]enable_fdo_profile_absolute_path
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है, तो fdo_absolute_profile_path के इस्तेमाल पर गड़बड़ी हो सकती है.
टैग:affects_outputs
--[no]enable_runfiles
डिफ़ॉल्ट: "ऑटो"-
रनफ़ाइल सिमलिंक ट्री चालू करें. डिफ़ॉल्ट रूप से, यह Windows और दूसरे प्लैटफ़ॉर्म पर बंद होता है.
टैग:affects_outputs
- ऐप्लिकेशन के
--experimental_action_listener=<a build target label>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अलग-अलग पहलुओं के पक्ष में नहीं दिखाया गया. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग:execution
,experimental
--[no]experimental_android_compress_java_resources
डिफ़ॉल्ट: "false"-
APK में Java रिसॉर्स को कंप्रेस करें
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_android_databinding_v2
डिफ़ॉल्ट: "false"-
Android databinding v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_android_resource_shrinking
डिफ़ॉल्ट: "false"-
यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को कम करने की सुविधा चालू करती है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex
डिफ़ॉल्ट: "false"-
डेक्स फ़ाइलों को फिर से लिखने के लिए रेक्स टूल का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--experimental_objc_fastbuild_options=<comma-separated list of options>
डिफ़ॉल्ट: "-O0,-DDEBUG=1"-
इन स्ट्रिंग का इस्तेमाल, objc फ़ास्ट बिल्ड कंपाइलर विकल्पों के तौर पर करता है.
टैग:action_command_lines
--[no]experimental_omitfp
डिफ़ॉल्ट: "false"-
अगर सही है, तो स्टैक अनवाइंड करने के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables की मदद से कंपाइल करें.
टैग:action_command_lines
,affects_outputs
,experimental
--[no]experimental_platform_in_output_dir
डिफ़ॉल्ट: "false"-
सही होने पर, टारगेट प्लैटफ़ॉर्म का इस्तेमाल सीपीयू के बजाय आउटपुट डायरेक्ट्री के नाम में किया जाता है.
टैग:affects_outputs
,experimental
--[no]experimental_use_llvm_covmap
डिफ़ॉल्ट: "false"-
अगर इसके बारे में बताया गया है, तो collections_code_coverage की सुविधा चालू होने पर Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
,experimental
--fat_apk_cpu=<comma-separated list of options>
डिफ़ॉल्ट: "armeabi-v7a"-
इस विकल्प को सेट करने पर, फ़ैट वाले ऐसे APKs चालू हो जाते हैं जिनमें तय किए गए सभी टारगेट आर्किटेक्चर के लिए नेटिव बाइनरी होती हैं. उदाहरण के लिए, --fat_apk_cpu=x86,armeabi-v7a. अगर इस फ़्लैग को तय किया गया है, तो android_binary नियमों की डिपेंडेंसी के लिए --android_cpu को अनदेखा किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]fat_apk_hwasan
डिफ़ॉल्ट: "false"-
HWASAN स्प्लिट बनाने हैं या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान हटाया जाएगा.
टैग:affects_outputs
--fdo_optimize=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कॉम्प्लेक्सेशन ऑप्टिमाइज़ करने के लिए एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री हो, कोई ऑटो प्रोफ़ाइल वाली afdo फ़ाइल हो या कोई LLVM प्रोफ़ाइल फ़ाइल दी गई हो. यह फ़्लैग उन फ़ाइलों को भी स्वीकार करता है जिन्हें लेबल के तौर पर बताया गया है (जैसे कि `//foo/bar:file.afdo` - आपको इससे जुड़े पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है. साथ ही, `fdo_profile` टारगेट को पॉइंट करने वाले लेबल भी लागू हो सकते हैं. इस फ़्लैग को `fdo_profile` नियम के तहत हटा दिया जाएगा.
टैग:affects_outputs
--fdo_prefetch_hints=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कैश मेमोरी प्रीफ़ेच संकेतों का इस्तेमाल करें.
टैग:affects_outputs
--fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल को दिखाने वाली fdo_profile.
टैग:affects_outputs
- ऐप्लिकेशन के
--features=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
ये सुविधाएं, सभी पैकेज के लिए डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> को लागू करने पर, यह सुविधा दुनिया भर में बंद हो जाएगी. नेगेटिव सुविधाएं, हमेशा पॉज़िटिव सुविधाओं को बदल देती हैं. इस फ़्लैग का इस्तेमाल, Bazel रिलीज़ के बिना, डिफ़ॉल्ट सुविधाओं में बदलावों को रोल आउट करने के लिए किया जाता है.
टैग:changes_inputs
,affects_outputs
--[no]force_pic
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") देते हैं. लिंक, बिना पीआईसी लाइब्रेरी के बजाय, पीआईसी में पहले से बनी लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक पोज़िशन पर निर्भर एक्ज़िक्यूटेबल ("-पाई") बनाते हैं.
टैग:loading_and_analysis
,affects_outputs
- ऐप्लिकेशन के
--host_action_env=<a 'name=value' assignment with an optional value part>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट या एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, वैल्यू को शुरू करने वाले एनवायरमेंट या नाम=वैल्यू के जोड़े से लिया जाएगा. इस पेयर की मदद से वैल्यू को, शुरू करने वाले एनवायरमेंट से अलग सेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत, अलग-अलग वैरिएबल के लिए उपलब्ध विकल्प.
टैग:action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt>
डिफ़ॉल्ट: "ऑप्ट"-
उस मोड के बारे में बताएं जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल का इस्तेमाल किया जाएगा. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग:affects_outputs
,action_command_lines
- ऐप्लिकेशन के
--host_conlyopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--host_copt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए जीसीसी को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_cpu=<a string>
डिफ़ॉल्ट: ""-
होस्ट के लिए सीपीयू.
टैग:changes_inputs
,affects_outputs
- ऐप्लिकेशन के
--host_cxxopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए जीसीसी को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_force_python=<PY2 or PY3>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट कॉन्फ़िगरेशन के लिए 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 भी देखें. यह विकल्प_1 से Option_n का मतलब, आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, बार.cc को छोड़कर //foo/ में सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--host_swiftcopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए, swiftc को पास करने के ज़्यादा विकल्प.
टैग:action_command_lines
,affects_outputs
--[no]incompatible_avoid_conflict_dlls
डिफ़ॉल्ट: "सही"-
इस सेटिंग को चालू करने पर, Windows पर cc_library से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (डीएलएल) का नाम बदलकर name_{hash}.dll कर दिया जाएगा. यहां हैश का हिसाब RepositoryName और DLL के पैकेज पाथ के आधार पर लगाया जाता है. यह विकल्प तब फ़ायदेमंद होता है, जब आपके पास एक ऐसा पैकेज हो जो एक ही नाम वाली कई cc_library पर निर्भर करता हो (जैसे कि //foo/bar1:utils और //foo/bar2:utils).
टैग:loading_and_analysis
,affects_outputs
,incompatible_change
--[no]incompatible_merge_genfiles_directory
डिफ़ॉल्ट: "सही"-
सही होने पर, जनरेट फ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_use_platforms_repo_for_constraints
डिफ़ॉल्ट: "सही"-
सही होने पर, @bazel_tools की कंस्ट्रेंट सेटिंग हटा दी जाती हैं.
टैग:affects_outputs
,incompatible_change
--[no]instrument_test_targets
डिफ़ॉल्ट: "false"-
कवरेज चालू होने पर, यह तय किया जाता है कि टेस्ट के नियमों को ध्यान में रखना है या नहीं. सेट किए जाने पर, --instrumentation_filter में शामिल किए गए टेस्ट के नियम लागू होते हैं. नहीं तो, जांच के नियमों को कवरेज इंस्ट्रुमेंटेशन से हमेशा बाहर रखा जाता है.
टैग:affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-/javatest[/:],-/test/java[/:]"-
कवरेज चालू होने पर, सिर्फ़ वही नियम लागू किए जाएंगे जिनके नाम, रेगुलर एक्सप्रेशन पर आधारित फ़िल्टर के ज़रिए शामिल किए गए हों. इसके बजाय, '-' से शुरू वाले नियमों को शामिल नहीं किया जाता. ध्यान रखें कि जब तक --instrument_test_targets को चालू नहीं किया जाता, तब तक सिर्फ़ गैर-टेस्ट नियम लागू किए जाते हैं.
टैग:affects_outputs
--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाला iOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'ios_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
- ऐप्लिकेशन के
--ios_multi_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
iOS_application बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें सभी तय आर्किटेक्चर शामिल हैं.
टैग:loses_incremental_state
,loading_and_analysis
--[no]legacy_whole_archive
डिफ़ॉल्ट: "सही"-
अब काम नहीं करता, इसकी जगह --insupported_remove_Legacy_whole_archive (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7362 देखें). इस सेटिंग के चालू होने पर, cc_binary के उन नियमों के लिए --whole-archive का इस्तेमाल करें जिनमें linkshared=True शामिल है. साथ ही, linkopts में linkstatic=True या '-static' का इस्तेमाल किया जाता है. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. जहां ज़रूरी हो, वहां क्लिक के लिए हमेशा लिंक=1 का इस्तेमाल करें. यह एक अच्छा विकल्प है.
टैग:action_command_lines
,affects_outputs
,deprecated
- ऐप्लिकेशन के
--linkopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--ltobackendopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
एलटीओ बैकएंड चरण को पास करने का अन्य विकल्प (--features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--ltoindexopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
एलटीओ इंडेक्स करने के चरण को पास करने का अन्य विकल्प (-features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--macos_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Apple macOS की बाइनरी बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट.
टैग:loses_incremental_state
,loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट के लिए, कम से कम काम करने वाले macOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--[no]objc_debug_with_GLIBCXX
डिफ़ॉल्ट: "false"-
अगर यह सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को परिभाषित करें.
टैग:action_command_lines
--[no]objc_enable_binary_stripping
डिफ़ॉल्ट: "false"-
लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिप करना है या नहीं. अगर यह फ़्लैग और --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 भी देखें. यह विकल्प_1 से Option_n का मतलब, आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ बार.cc को छोड़कर सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड (--features=thin_lto के तहत) को अपनी पसंद के हिसाब से पास करने के ज़्यादा विकल्प. इस विकल्प को कई बार इस्तेमाल किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल करने और रेगुलर एक्सप्रेशन पैटर्न को शामिल करने की सूची से है. इसके अलावा, Option_1 से Option_n विकल्प का मतलब आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0 //foo/ को छोड़कर bar.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>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, प्रोपेलर प्रोफ़ाइल की जानकारी का इस्तेमाल करें.प्रोपेलर प्रोफ़ाइल में दो फ़ाइलों में से कम से कम एक फ़ाइल, cc प्रोफ़ाइल और ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल स्वीकार करता है, जो प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, लेबल को परिभाषित करने वाली BUILD फ़ाइल जो कि लेबल को परिभाषित करती है, a/b/BUILD:खरीददारी_ऑप्टिमाइज़( name = " सेटिंग्स_profile", cc_profile = " रूपरेखा_cc_profile.txt", ld_profile = " सेटिंग्स_ld_profile.txt",) एनजीएल फ़ाइल्स निर्देश को संबंधित पैकेज में जोड़ना पड़ सकता है, ताकि ये फ़ाइलें Bazel को दिख सकें. विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --propler_optimize=//a/b:PROpelलर_profile
टैग:action_command_lines
,affects_outputs
--propeller_optimize_absolute_cc_profile=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Propiller ऑप्टिमाइज़ किए गए बिल्ड के लिए 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
-
सही होने पर, एक जैसी काम करने वाली नेटिव लाइब्रेरी अलग-अलग टारगेट के बीच शेयर की जाएंगी
टैग:loading_and_analysis
,affects_outputs
--[no]stamp
डिफ़ॉल्ट: "false"-
स्टैंप बाइनरी जिनमें तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह शामिल है.
टैग: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
- ऐप्लिकेशन के
--watchos_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनानी हैं.
टैग:loses_incremental_state
,loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाले WatchOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'watchos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--xbinary_fdo=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपलेशन ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile/ के साथ किया जाता है, तब ये विकल्प हमेशा लागू होते हैं, जैसे कि xbinary_fdo के बारे में कभी जानकारी न दी गई हो.
टैग:affects_outputs
- Bzel के मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--auto_cpu_environment_group=<a build target label>
डिफ़ॉल्ट: ""-
Environment_group का एलान करें, ताकि target_environment वैल्यू के लिए सीपीयू वैल्यू को अपने-आप मैप करने के लिए, उसका इस्तेमाल किया जा सके.
टैग:changes_inputs
,loading_and_analysis
,experimental
--[no]check_licenses
डिफ़ॉल्ट: "false"-
जांचें कि डिपेंडेंट पैकेज की तय की गई लाइसेंस से जुड़ी सीमाएं, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर न डालें. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: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
डिफ़ॉल्ट: "false"-
लेगसी डिवाइसों के लिए, ऐप्लिकेशन में Java 8 लाइब्रेरी शामिल करनी है या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]enforce_constraints
डिफ़ॉल्ट: "सही"-
यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर कोई टारगेट ऐसी डिपेंडेंसी है जो एक जैसे एनवायरमेंट के साथ काम नहीं करती, तो गड़बड़ियों की रिपोर्ट करता है
टैग:build_file_semantics
--[no]experimental_allow_android_library_deps_without_srcs
डिफ़ॉल्ट: "false"-
deps के साथ srcs-less android_library नियमों को अस्वीकार करने की अनुमति देने से ट्रांज़िशन में मदद करने के लिए फ़्लैग करें. डिफ़ॉल्ट रूप से इसे रोल आउट करने के लिए डिपो को साफ़ करना ज़रूरी है.
टैग:eagerness_to_exit
,loading_and_analysis
--[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
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, आउटपुट फ़ाइल वाले ज़रूरी टारगेट के लिए सिर्फ़ testonly चुनें. इसके लिए, सिर्फ़ जनरेट करने वाले नियम का टेस्ट देखें. यह 'किसको दिखे' सेटिंग से मेल खाता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disable_native_android_rules
डिफ़ॉल्ट: "false"-
चालू होने पर, Android के मूल नियमों का सीधे इस्तेमाल करने की सुविधा बंद हो जाती है. कृपया https://github.com/bazelbuild/मॉडल_android से Starlark Android के नियमों का इस्तेमाल करें
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_disable_native_apple_binary_rule
डिफ़ॉल्ट: "false"-
पुराने सिस्टम के साथ काम करने की सुविधा के लिए, इसे यहां रखा गया है.
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_force_strict_header_check_from_starlark
डिफ़ॉल्ट: "सही"-
अगर चालू है, तो Starlark API में हेडर की सख्त जांच सेट करें
टैग:loading_and_analysis
,changes_inputs
,incompatible_change
--[no]incompatible_validate_top_level_header_inclusions
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, टॉप लेवल डायरेक्ट्री के हेडर शामिल करने की भी पुष्टि करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]strict_filesets
डिफ़ॉल्ट: "false"-
अगर यह विकल्प चालू किया जाता है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है. यह Check_fileset_dependencies_recursively को बंद करने पर काम नहीं करता है.
टैग: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
डिफ़ॉल्ट: "false"-
अगर सही है, तो सिस्टम से मिलने वाले हेडर में पाथ (-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 भाषा के सिमैंटिक या उस बिल्ड एपीआई को इस्तेमाल करने पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]incompatible_disallow_legacy_py_provider
डिफ़ॉल्ट: "सही"-
नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
,incompatible_change
- टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:
--[no]allow_analysis_failures
डिफ़ॉल्ट: "false"-
सही होने पर, टारगेट किए गए किसी नियम का विश्लेषण नहीं हो पाता है. ऐसा होने पर, टारगेट के तहत किसी ऐसी स्थिति का विश्लेषण हो जाता है जिसमें गड़बड़ी की जानकारी होती है. इस वजह से, बिल्ड फ़ेल हो जाता है.
टैग:loading_and_analysis
,experimental
--analysis_testing_deps_limit=<an integer>
डिफ़ॉल्ट: "2000"-
for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट की मदद से, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा को पार करने से नियम में गड़बड़ी होगी.
टैग:loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure
डिफ़ॉल्ट: "false"-
अगर सही dex2oat कार्रवाई पूरी नहीं हो पाती है, तो टेस्ट रनटाइम के दौरान dex2oat को चलाने के बजाय बिल्ड टूट जाएगा.
टैग:loading_and_analysis
,experimental
--[no]experimental_android_use_parallel_dex2oat
डिफ़ॉल्ट: "false"-
android_test को तेज़ करने के लिए dex2oat का साथ-साथ इस्तेमाल करें.
टैग:loading_and_analysis
,host_machine_resource_optimizations
,experimental
--[no]ios_memleaks
डिफ़ॉल्ट: "false"-
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>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में जानकारी देता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू को Bazel क्लाइंट एनवायरमेंट या name=value पेयर से पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
टैग:test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers>
डिफ़ॉल्ट: "-1"- जांच के टाइम आउट होने के समय की डिफ़ॉल्ट वैल्यू को बदलें (सेकंड में). अगर एक पॉज़िटिव पूर्णांक मान दिया गया है, तो वह सभी कैटगरी को बदल देगा. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, मध्यम, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. किसी भी रूप में, -1 की वैल्यू ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने का निर्देश देती है.
--tvos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में किसी tvOS ऐप्लिकेशन को चलाते समय, सिम्युलेट करने वाला डिवाइस, जैसे कि 'Apple TV 1080p'. जिस मशीन पर सिम्युलेटर चलाया जाएगा उस पर 'xcrun SIMctl list devicetypes' चलाकर आप डिवाइस की एक सूची पा सकते हैं.
टैग:test_runner
--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
चलाते या टेस्ट करते समय, सिम्युलेटर पर चलने वाला tvOS का वर्शन.
टैग:test_runner
--watchos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में WatchOS ऐप्लिकेशन चलाते समय सिम्युलेट किया जाने वाला डिवाइस, जैसे कि 'Apple Watch - 38mm'. जिस मशीन पर सिम्युलेटर चलाया जाएगा उस पर 'xcrun SIMctl list devicetypes' चलाकर आप डिवाइस की एक सूची पा सकते हैं.
टैग:test_runner
--watchos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
दौड़ने या टेस्ट करने के दौरान, सिम्युलेटर पर चलने के लिए WatchOS का वर्शन.
टैग:test_runner
--[no]zip_undeclared_test_outputs
डिफ़ॉल्ट: "सही"-
अगर सही है, तो नहीं बताए गए टेस्ट आउटपुट ZIP फ़ाइल में संग्रहित किए जाएंगे.
टैग:test_runner
- क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:
--aspect_deps=<off, conservative or precise>
डिफ़ॉल्ट: "कंज़र्वेटिव"-
जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तो आसपेक्ट डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि तय की गई सभी पहलू डिपेंडेंसी जोड़ी जाती हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के नियम की कैटगरी दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम की क्लास के आधार पर ऐक्टिव होते हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट की जांच करने के लिए, अन्य पैकेज लोड करने ज़रूरी होते हैं. इस वजह से, यह अन्य मोड की तुलना में धीमा हो जाता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता है: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह प्रोसेस, 'bazel क्वेरी' के दौरान नहीं चलती.
टैग:build_file_semantics
--[no]deduplicate_depsets
डिफ़ॉल्ट: "सही"-
फ़ाइनल Proto/textproto/json आउटपुट में, dep_set_of_files के बच्चों की नॉन-लीफ़ फ़ाइलों की डुप्लीकेट कॉपी हटाएं. यह उन साइटों की डुप्लीकेट कॉपी नहीं बनाती है जो किसी मौजूदा अभिभावक को शेयर नहीं करती हैं. इससे, कार्रवाइयों के इनपुट आर्टफ़ैक्ट की फ़ाइनल असरदार सूची पर कोई असर नहीं पड़ता.
टैग:terminal_output
--[no]graph:factored
डिफ़ॉल्ट: "सही"-
सही होने पर, ग्राफ़ पर 'फ़ैक्टर' निकाला जाएगा. इसका मतलब है कि टॉपॉलॉजिकली इक्विलंट नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल जोड़ दिए जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--graph:node_limit=<an integer>
डिफ़ॉल्ट: "512"-
आउटपुट में, ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि कोई काट-छांट नहीं की जाएगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--[no]implicit_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel के ज़रिए जोड़ा गया है. cquery के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग:build_file_semantics
--[no]include_artifacts
डिफ़ॉल्ट: "सही"-
इससे आउटपुट में, ऐक्शन इनपुट और आउटपुट के नाम शामिल होते हैं (अनुमानित रूप से बड़ा).
टैग:terminal_output
--[no]include_aspects
डिफ़ॉल्ट: "सही"-
क्वेरी, cquery: आउटपुट में पक्ष से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (निर्देशों को हमेशा अपनाया जाता है).
टैग:terminal_output
--[no]include_commandline
डिफ़ॉल्ट: "सही"-
आउटपुट में, ऐक्शन कमांड लाइन का कॉन्टेंट शामिल होता है (अनुमानित रूप से बड़ा).
टैग:terminal_output
--[no]include_file_write_contents
डिफ़ॉल्ट: "false"-
FileWrite और SourceSymlinkManifest की कार्रवाइयों (संभावित रूप से बड़ा) के लिए, फ़ाइल का कॉन्टेंट शामिल करें.
टैग:terminal_output
--[no]include_param_files
डिफ़ॉल्ट: "false"-
कमांड में इस्तेमाल की गई पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें (अनुमानित रूप से बड़ा). ध्यान दें: इस फ़्लैग को चालू करने पर --include_commandline फ़्लैग अपने-आप चालू हो जाएगा.
टैग:terminal_output
--[no]incompatible_display_source_file_location
डिफ़ॉल्ट: "सही"-
डिफ़ॉल्ट रूप से 'सही', सोर्स फ़ाइल का टारगेट दिखाता है. सही होने पर, लोकेशन आउटपुट में सोर्स फ़ाइलों की लाइन 1 की जगह दिखाता है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग:terminal_output
,incompatible_change
--[no]incompatible_package_group_includes_double_slash
डिफ़ॉल्ट: "सही"-
इस सुविधा को चालू करने पर, Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, पहले `//` की वैल्यू नहीं छोड़ी जाएगी.
टैग:terminal_output
,incompatible_change
--[no]infer_universe_scope
डिफ़ॉल्ट: "false"-
अगर सेट और --universe_scope को सेट नहीं किया जाता है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे कि`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई --universe_scope वैल्यू, शायद आपकी पसंद के मुताबिक न हो. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/query/language#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` (जैसे कि `cquery` पर नहीं) पर लागू होता है.
टैग:loading_and_analysis
--[no]line_terminator_null
डिफ़ॉल्ट: "false"-
हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाए या नहीं.
टैग:terminal_output
--[no]nodep_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, "nodep" एट्रिब्यूट की वैल्यू को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा, जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडेप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग:build_file_semantics
--output=<a string>
डिफ़ॉल्ट: "text"-
वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. aquery के लिए इन वैल्यू को इस्तेमाल किया जा सकता है: text, textproto, proto, jsonproto.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग:terminal_output
पर लागू होता है
--[no]proto:definition_stack
डिफ़ॉल्ट: "false"-
definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें, जो नियम की क्लास तय किए जाने के समय Starlark कॉल स्टैक के हर नियम के लिए रिकॉर्ड करता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, Select() के ज़रिए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट फ़्लैट कर दिए जाते हैं. सूची के टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन वह सूची है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप शून्य तक चपटे हो जाते हैं.
टैग:build_file_semantics
--[no]proto:include_synthetic_attribute_hash
डिफ़ॉल्ट: "false"- $internal_attr_hh एट्रिब्यूट का हिसाब लगाने और उसे पॉप्युलेट करने या न करने का विकल्प.
टैग:terminal_output
--[no]proto:instantiation_stack
डिफ़ॉल्ट: "false"-
हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग:terminal_output
--[no]proto:locations
डिफ़ॉल्ट: "सही"-
प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग:terminal_output
--proto:output_rule_attrs=<comma-separated list of options>
डिफ़ॉल्ट: "सभी"-
आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. किसी भी एट्रिब्यूट का आउटपुट न देने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --OUT=proto पर लागू होता है.
टैग:terminal_output
--[no]proto:rule_inputs_and_outputs
डिफ़ॉल्ट: "सही"-
रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग:terminal_output
--[no]relative_locations
डिफ़ॉल्ट: "false"-
सही होने पर, एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह तय होगी. डिफ़ॉल्ट रूप से, लोकेशन आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग:terminal_output
--[no]skyframe_state
डिफ़ॉल्ट: "false"-
ज़्यादा विश्लेषण किए बिना, Skyframe के मौजूदा ऐक्शन ग्राफ़ को डंप करें. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय करने की सुविधा काम नहीं करती. यह फ़्लैग सिर्फ़ --आउटपुट=प्रोटो या --आउटपुट=textproto के साथ उपलब्ध होता है.
टैग:terminal_output
--[no]tool_deps
डिफ़ॉल्ट: "सही"-
क्वेरी: बंद होने पर, 'होस्ट कॉन्फ़िगरेशन' या 'एक्ज़ीक्यूशन' टारगेट की डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाता जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर को मिलने वाला किनारा. आम तौर पर, यह उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, उस टूल के बारे में बताता है जिसे बिल्ड के दौरान लागू किया जाता है.
Cquery: बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट का पता लगाने वाले टॉप लेवल टारगेट से, होस्ट या एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. साथ ही, टारगेट कॉन्फ़िगरेशन में भी कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट ही दिखेंगे. इस विकल्प में, ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग:build_file_semantics
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का सेट, कॉमा लगाकर अलग किया गया. इसमें योग और घटाव वाले पैटर्न शामिल होते हैं. क्वेरी को संसार में निष्पादित किया जा सकता है, जबकि बताए गए लक्ष्यों के ट्रांज़िटिव बंद होने से परिभाषित होता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है.
cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब तैयार किए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट मान लिया जाता है. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए इस विकल्प को तय न करने से बिल्ड टूट सकता है.
टैग:loading_and_analysis
- बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प:
--[no]collapse_duplicate_defines
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, गैर-ज़रूरी --परिभाषाओं को बिल्ड की शुरुआत में ही हटा दिया जाएगा. इससे कुछ खास तरह के मिलते-जुलते बिल्ड के लिए, विश्लेषण की कैश मेमोरी को होने वाले नुकसान से बचा जा सकता है.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_filter_library_jar_with_program_jar
डिफ़ॉल्ट: "false"-
LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए ProGuard ProgramJar को फ़िल्टर करें.
टैग:action_command_lines
--[no]experimental_inmemory_dotd_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, C++ .d फ़ाइलों को मेमोरी में, डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से पास किया जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_inmemory_jdeps_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_objc_include_scanning
डिफ़ॉल्ट: "false"-
मकसद C/C++ के लिए स्कैन करना है या नहीं.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]experimental_parse_headers_skipped_if_corresponding_srcs_found
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, अगर एक ही टारगेट में एक जैसे बेसनेम वाला सोर्स मिलता है, तो parse_headers सुविधा अलग से हेडर कंपाइलेशन ऐक्शन नहीं बनाती.
टैग:loading_and_analysis
,affects_outputs
--[no]experimental_retain_test_configuration_across_testonly
डिफ़ॉल्ट: "false"-
चालू होने पर, --trim_test_ Configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए, टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़े विवाद से जुड़ी समस्याओं को कम करना है. ऐसा तब किया जाता है, जब जांच न करने वाले नियम cc_test पर निर्भर होते हैं. --trim_test_Configuration गलत होने पर कोई असर नहीं होगा.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_starlark_cc_import
डिफ़ॉल्ट: "false"-
अगर चालू हो, तो cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग:loading_and_analysis
,experimental
--[no]experimental_unsupported_and_brittle_include_scanning
डिफ़ॉल्ट: "false"-
इनपुट फ़ाइलों से #include पंक्तियों को पार्स करके, C/C++ कंपाइलेशन में इनपुट को सीमित करना है या नहीं. यह कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और बढ़ोतरी को बेहतर बना सकता है. हालांकि, इससे बिल्ड खराब भी हो सकते हैं, क्योंकि शामिल स्कैनर, C प्रीप्रोसेसर सिमैंटिक को पूरी तरह लागू नहीं करता. खास तौर पर, यह डाइनैमिक #इन्क्लूसिव निर्देशों को नहीं समझता और प्रीप्रोसेसर कंडिशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी जो भी समस्याएं फ़ाइल की जाती हैं वे बंद हो जाएंगी.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]incremental_dexing
डिफ़ॉल्ट: "सही"-
क्या हर Jar फ़ाइल के लिए, ज़्यादातर काम अलग-अलग तरीके से किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]objc_use_dotd_pruning
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है, तो clang से उत्सर्जित होने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइलेशन में पास किए गए इनपुट के सेट को हटाने के लिए किया जाएगा.
टैग:changes_inputs
,loading_and_analysis
--[no]process_headers_in_dependencies
डिफ़ॉल्ट: "false"-
टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग:execution
--[no]trim_test_configuration
डिफ़ॉल्ट: "सही"-
चालू होने पर, जांच से जुड़े विकल्प, बिल्ड के टॉप लेवल से नीचे हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, गैर-टेस्टिंग नियमों का फिर से विश्लेषण नहीं होगा.
टैग:loading_and_analysis
,loses_incremental_state
--[no]use_singlejar_apkbuilder
डिफ़ॉल्ट: "सही"-
इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. अब इस पर कोई कार्रवाई नहीं की जा सकती. इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
- ऐसे विकल्प जो जानकारी डालने की जगह, फ़ॉर्मैट या जगह की जानकारी पर असर डालते हैं:
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-.*"-
टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. फ़्लैग, रेगुलर एक्सप्रेशन को इस्तेमाल करता है. इसकी जांच टूलचेन टाइप और चुनिंदा टारगेट से की जाती है, ताकि यह पता लगाया जा सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल है और हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन में माहिर विशेषज्ञों के लिए ही काम का हो.
टैग:terminal_output
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
- ऐप्लिकेशन के
--flag_alias=<a 'name=value' flag alias>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
स्टारलार्क फ़्लैग के लिए एक शॉर्टहैंड नाम सेट करता है. यह एक तर्क के रूप में "<key>=<value>" रूप में एक की-वैल्यू पेयर लेता है.
टैग:changes_inputs
--[no]incompatible_default_to_explicit_init_py
डिफ़ॉल्ट: "false"-
यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बने. आम तौर पर, जब किसी py_binary या py_test टारगेट मेंLegacy_create_init "अपने आप" (डिफ़ॉल्ट) पर सेट होती है, तो इस फ़्लैग के सेट होने पर ही गलत माना जाता है. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py2_outputs_are_suffixed
डिफ़ॉल्ट: "सही"-
अगर सही होता है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट आउटपुट रूट में दिखेंगे, जिसमें सफ़िक्स '-py2' होगा, जबकि Python 3 के लिए बनाए गए टारगेट रूट में दिखेंगे और Python से जुड़े सफ़िक्स के नहीं होंगे. इसका मतलब है कि `bazel-bin` सुविधा वाला सिमलिंक, Python 2 के बजाय Python 3 टारगेट को पॉइंट करेगा. अगर इस विकल्प को चालू किया जाता है, तो `--insupported_py3_is_default` को चालू करने का भी सुझाव दिया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py3_is_default
डिफ़ॉल्ट: "सही"-
सही होने पर, `py_binary` और `py_test` टारगेट जो अपना `python_version` (या `default_python_version`) सेट नहीं करते, तो वे डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. अगर इस फ़्लैग को सेट किया जाता है, तो आपको `--insupported_py2_OUTs_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
,explicit_in_output_path
- दूसरे विकल्प, जिन्हें अलग से कैटगरी में नहीं बांटा गया है.:
--[no]cache_test_results
[-t
] डिफ़ॉल्ट: "ऑटो"- अगर स्थिति को 'अपने-आप' पर सेट किया जाता है, तो Bazel फिर से जांच तब करता है, जब: (1) Bazel को जांच में हुए बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया जाता है, (3) --runs_per_test की मदद से कई टेस्ट चलाने का अनुरोध किया जाता है या(4) जांच पहले असफल हो जाती है. अगर इस नीति को 'हां' पर सेट किया जाता है, तो बाहरी के तौर पर मार्क किए गए टेस्ट के अलावा, Bazel जांच के सभी नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी जांच के नतीजे को कैश मेमोरी में सेव नहीं करेगा.
--[no]experimental_cancel_concurrent_tests
डिफ़ॉल्ट: "false"-
सही होने पर, Blaze पहले कभी भी किए जाने वाले टेस्ट को रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ कॉम्बिनेशन में इस्तेमाल किया जाता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_fetch_all_coverage_outputs
डिफ़ॉल्ट: "false"-
अगर सही है, तो बैजल कवरेज के दौरान हर टेस्ट के लिए, पूरी कवरेज डेटा डायरेक्ट्री फ़ेच करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_generate_llvm_lcov
डिफ़ॉल्ट: "false"-
अगर सही है, तो क्लैग के लिए कवरेज से एलसीओवी रिपोर्ट जनरेट होगी.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_j2objc_header_map
डिफ़ॉल्ट: "सही"- क्या आपको J2ObjC ट्रांसपिलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है.
--[no]experimental_j2objc_shorter_header_path
डिफ़ॉल्ट: "false"-
छोटे हेडर पाथ के साथ जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग:affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel>
डिफ़ॉल्ट: "javaBuilder"- यह सुविधा, Java कंपाइलेशन के लिए कम किए गए क्लासपाथ चालू करती है.
--[no]experimental_limit_android_lint_to_android_constrained_java
डिफ़ॉल्ट: "false"-
-इन्हें Android के साथ काम करने वाली लाइब्रेरी पर ही लागू करें.
टैग:affects_outputs
--[no]experimental_run_android_lint_on_java_rules
डिफ़ॉल्ट: "false"-
Java_* सोर्स की पुष्टि करनी है या नहीं.
टैग:affects_outputs
--[no]explicit_java_test_deps
डिफ़ॉल्ट: "false"- testरनर के डिप से गलती से जानकारी हासिल करने के बजाय, java_test में JUnit या Hamcrest के लिए डिपेंडेंसी साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ बाज़ल के लिए काम करता है.
--host_java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- JavaScript का इस्तेमाल करने वाले टूल में इस्तेमाल किए जाने वाले टूल, बिल्ड के दौरान काम करते हैं.
- ऐप्लिकेशन के
--host_javacopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड के दौरान काम करने वाले टूल बनाते समय, Javac को पास करने के दूसरे विकल्प.
- ऐप्लिकेशन के
--host_jvmopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java वीएम को पास करने के दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_exclusive_test_sandboxed
डिफ़ॉल्ट: "false"-
सही होने पर, सैंडबॉक्स रणनीति की मदद से खास टेस्ट चलाए जाएंगे. खास तौर पर स्थानीय स्तर पर टेस्ट चलाने के लिए 'लोकल' टैग जोड़ें
टैग:incompatible_change
--[no]incompatible_strict_action_env
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से किसी एनवायरमेंट वैरिएबल को इनहेरिट करना है, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान रखें कि ऐसा करने से, शेयर की गई कैश मेमोरी का इस्तेमाल करने पर क्रॉस-उपयोगकर्ता कैश मेमोरी में सेव होने से रोका जा सकता है.
टैग:loading_and_analysis
,incompatible_change
- ऐप्लिकेशन के
--j2objc_translation_flags=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - J2ObjC टूल को पास करने के दूसरे विकल्प.
--java_debug
-
इसकी वजह से, JavaScript टेस्ट की Java वर्चुअल मशीन को जांच शुरू करने से पहले, JDWP का पालन करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार करना पड़ता है. इसमें -test_OUT=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>
डिफ़ॉल्ट: "8"- जावा भाषा का वर्शन
--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>
डिफ़ॉल्ट: ब्यौरा देखें- ऐसी क्लास की सूची जनरेट करने के लिए बाइनरी तय करता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य dex में होना चाहिए.
- ऐप्लिकेशन के
--plugin=<a build target label>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड में इस्तेमाल करने के लिए प्लगिन. फ़िलहाल, java_plugin के साथ काम करता है.
--proguard_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- यह बताता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना चाहिए.
--proto_compiler=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc"-
प्रोटो-कंपाइलर का लेबल.
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_cc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain"-
proto_lang_toolchain() का लेबल जिसमें C++ Protos को कंपाइल करने का तरीका बताया गया है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
proto_lang_toolchain() का लेबल, जिसमें j2objc protos को कंपाइल करने का तरीका बताया गया है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_java=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"-
proto_lang_toolchain() का लेबल, जो Java Protos को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_javalite=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"-
proto_lang_toolchain() का लेबल, जो JavaLite Protos को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
- ऐप्लिकेशन के
--protocopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
प्रोटोबफ़ कंपाइलर को पास करने के ज़्यादा विकल्प.
टैग:affects_outputs
--[no]runs_per_test_detects_flakes
डिफ़ॉल्ट: "false"- सही होने पर, कोई भी शार्ड जिसमें कम से कम एक रन/अटैम पास होता है और कम से कम एक रन/अटैम फ़ेल होता है, उसे फ़्लेकी स्टेटस माना जाता है.
--shell_executable=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
Bzel के इस्तेमाल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को पहले Bazel सर्वर (जो कि Bazel सर्वर को स्टार्ट करता है) पर सेट किया जाता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर वह चलता है. Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash. ध्यान दें कि बैश के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी के बनने या रनटाइम के दौरान सिस्टम फ़ेल हो सकता है.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--test_arg=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - ऐसे अन्य विकल्प और तर्क तय करता है जिन्हें टेस्ट एक्ज़ीक्यूटेबल टेस्ट में पास किया जाना चाहिए. एक से ज़्यादा तर्क तय करने के लिए, एक से ज़्यादा बार इस्तेमाल किया जा सकता है. अगर कई टेस्ट किए जाते हैं, तो सभी को एक जैसे तर्क मिलेंगे. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
--test_filter=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- टेस्ट फ़्रेमवर्क पर भेजने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, जांच को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे बनाए गए टारगेट पर कोई असर नहीं पड़ता.
--test_result_expiration=<an integer>
डिफ़ॉल्ट: "-1"- यह विकल्प अब सेवा में नहीं है और इसका कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast
डिफ़ॉल्ट: "false"- टेस्ट रनर पर तेज़ी से फ़ॉरवर्ड नहीं किया जा सकता. पहली बार फ़ेल होने पर, टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit or disabled>
डिफ़ॉल्ट: "अश्लील"- टेस्टिंग की रणनीति तय करें: शार्डिंग का इस्तेमाल 'साफ़ तौर पर' करने के लिए, सिर्फ़ तब करें, जब 'sard_count' BUILD एट्रिब्यूट मौजूद हो. यह विकल्प 'बंद' है, क्योंकि इसमें कभी भी टेस्ट शार्डिंग नहीं होगी.
--tool_java_language_version=<a string>
डिफ़ॉल्ट: "8"- बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया जाने वाला 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
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]check_up_to_date
डिफ़ॉल्ट: "false"-
बिल न बनाएं. बस देखें कि क्या यह अप-टू-डेट है. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड सही तरीके से पूरा हो जाता है. अगर किसी चरण को लागू करने की ज़रूरत होती है, तो गड़बड़ी की रिपोर्ट की जाती है और बिल्ड फ़ेल हो जाता है.
टैग:execution
--dynamic_local_execution_delay=<an integer>
डिफ़ॉल्ट: "1000"-
अगर किसी बिल्ड के दौरान, रिमोट तौर पर एक्ज़ीक्यूशन कम से कम एक बार तेज़ था, तो लोकल एक्ज़ीक्यूशन में कितने मिलीसेकंड में देरी होनी चाहिए?
टैग:execution
,host_machine_resource_optimizations
- ऐप्लिकेशन के
--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
स्नीमोनिक के इस्तेमाल के लिए स्थानीय रणनीतियां. 'स्थानीय' को स्मरक के तौर पर पास करने पर, अनिर्दिष्ट निमोनिक के लिए डिफ़ॉल्ट सेट हो जाता है. [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 रणनीति का इस्तेमाल करते समय, सैंडबॉक्स की गई कार्रवाई को एक्ज़ीक्यूट किया जा सके. साथ ही, प्लैटफ़ॉर्म के ब्यौरे में रिमोट_execution_properties में ऐक्शन के लिए, पहले से कंटेनर इमेज एट्रिब्यूट मौजूद न हो. इस फ़्लैग की वैल्यू 'docker play' को हूबहू पास की जाती है, ताकि यह उसी सिंटैक्स और सिस्टम के साथ काम करे जो 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"-
यह कंट्रोल करता है कि डाइनैमिक एक्ज़ीक्यूशन से, लोकल मशीन पर कितना लोड लोड होना चाहिए. यह फ़्लैग बताता है कि डाइनैमिक एक्ज़ीक्यूशन में हम एक साथ कितनी कार्रवाइयां शेड्यूल करेंगे. यह प्रोसेस, Blaze की ज़रूरत के हिसाब से उपलब्ध सीपीयू की संख्या पर आधारित होती है. इसे --local_cpu_resources फ़्लैग से कंट्रोल किया जा सकता है.
अगर यह फ़्लैग 0 है, तो सभी कार्रवाइयां स्थानीय तौर पर तुरंत शेड्यूल हो जाती हैं. अगर 0 से ज़्यादा हो, तो स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या, उपलब्ध सीपीयू की संख्या के हिसाब से सीमित होती है. अगर < 1 है, तो शेड्यूल की जाने वाली कार्रवाइयों की संख्या ज़्यादा होने पर, लोकल तौर पर शेड्यूल की गई कार्रवाइयों की संख्या कम करने के लिए, लोड करने का फ़ैक्टर इस्तेमाल किया जाता है. इससे क्लीन बिल्ड केस में लोकल मशीन पर कम लोड पड़ता है, जहां लोकल मशीन ज़्यादा योगदान नहीं देती.
टैग:execution
,host_machine_resource_optimizations
--experimental_dynamic_slow_remote_time=<An immutable length of time.>
डिफ़ॉल्ट: "0"-
यह वैल्यू 0 से ज़्यादा होने पर, डाइनैमिक तरीके से चलने वाली कार्रवाई को सिर्फ़ रिमोट से चलाया जाना चाहिए. इसके बाद ही, स्थानीय तौर पर उसे चलाया जाता है, ताकि रिमोट टाइम आउट से बचा जा सके. इससे रिमोट एक्ज़ीक्यूशन सिस्टम पर होने वाली कुछ समस्याएं छिप सकती हैं. रिमोट एक्ज़ीक्यूशन की समस्याओं को मॉनिटर किए बिना, इस सुविधा को चालू न करें.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_enable_docker_sandbox
डिफ़ॉल्ट: "false"-
Docker-आधारित सैंडबॉक्सिंग चालू करें. अगर Docker इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं होता.
टैग:execution
--experimental_persistent_javac
-
एक्सपेरिमेंटल परसिस्टेंट Java कंपाइलर चालू करें.
यह इन जगहों तक फैलता है:
--strategy=Javac=worker
--strategy=JavaIjar=local
--strategy=JavaDeployJar=local
--strategy=JavaSourceJar=local
--strategy=Turbine=local
टैग:execution
,host_machine_resource_optimizations
--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">
डिफ़ॉल्ट: "0"-
अगर वैल्यू 0 है, तो कार्रवाई पूरी होते ही सैंडबॉक्स ट्री को मिटा दें. इसकी वजह से, कार्रवाई पूरी होने में देरी हो सकती है. अगर यह संख्या शून्य से ज़्यादा है, तो एसिंक्रोनस थ्रेड पूल पर इस तरह के थ्री को मिटाने की प्रोसेस तब पूरी करें, जब बिल्ड चल रहा हो और जब सर्वर इस्तेमाल में न हो, तब यह फ़्लैग से बताए गए साइज़ तक बढ़ जाए.
टैग:host_machine_resource_optimizations
,execution
--experimental_sandboxfs_path=<a string>
डिफ़ॉल्ट: "sandboxfs"-
Sandboxfs बाइनरी का पाथ, जिसका इस्तेमाल तब किया जाता है, जब --experimental_use_sandboxfs सही हैं. अगर कोई नाम नहीं है, तो PATH में मिले उस नाम की पहली बाइनरी का इस्तेमाल करें.
टैग:host_machine_resource_optimizations
,execution
--[no]experimental_split_xml_generation
डिफ़ॉल्ट: "सही"-
अगर यह फ़्लैग सेट किया जाता है और टेस्ट कार्रवाई से test.xml फ़ाइल जनरेट नहीं होती, तो Bazel एक अलग कार्रवाई का इस्तेमाल करके, टेस्ट लॉग वाली डमी test.xml फ़ाइल जनरेट करेगा. ऐसा न होने पर, Bazel, टेस्ट ऐक्शन के तौर पर test.xml जनरेट करता है.
टैग:execution
--experimental_total_worker_memory_limit_mb=<an integer, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "0"-
अगर यह सीमा शून्य से ज़्यादा है, तो सभी कामगारों का कुल मेमोरी इस्तेमाल तय सीमा से ज़्यादा हो जाने पर काम न करने वाले कर्मचारियों की मौत हो सकती है.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_use_hermetic_linux_sandbox
डिफ़ॉल्ट: "false"-
अगर नीति को 'सही है' पर सेट किया गया है, तो रूट को माउंट न करें, सिर्फ़ sandbox_add_mount_pair पर मिले कॉन्टेंट को ही माउंट करें. इनपुट फ़ाइलें सैंडबॉक्स से सिमलिंक करने के बजाय सैंडबॉक्स से हार्डलिंक की जाएंगी. अगर ऐक्शन इनपुट फ़ाइलें, सैंडबॉक्स से अलग किसी दूसरे फ़ाइल सिस्टम में मौजूद हैं, तो इनपुट फ़ाइलों की कॉपी बनाई जाएगी.
टैग:execution
--[no]experimental_use_sandboxfs
डिफ़ॉल्ट: "false"-
एक सिमलिंक ट्री बनाने के बजाय, कार्रवाइयों की एक्सक्रूट डायरेक्ट्री बनाने के लिए सैंडबॉक्स का इस्तेमाल करें. अगर "हां" है, तो --experimental_sandboxfs_path से मिली बाइनरी मान्य होनी चाहिए और वह सैंडबॉक्सfs के साथ काम करने वाले वर्शन से मेल खानी चाहिए. अगर "ऑटो" है, तो हो सकता है कि बाइनरी मौजूद न हो या वह उसके साथ काम न करती हो.
टैग:host_machine_resource_optimizations
,execution
--[no]experimental_use_windows_sandbox
डिफ़ॉल्ट: "false"- कार्रवाइयां चलाने के लिए, Windows सैंडबॉक्स का इस्तेमाल करें. अगर "हां" है, तो --experimental_Windows_sandbox_path से मिली बाइनरी मान्य होनी चाहिए और वह सैंडबॉक्स का इस्तेमाल करने वाले वर्शन से मेल खानी चाहिए. अगर "ऑटो" है, तो हो सकता है कि बाइनरी मौजूद न हो या वह उसके साथ काम न करती हो.
--experimental_windows_sandbox_path=<a string>
डिफ़ॉल्ट: "BazelSandbox.exe"- --experimental_use_Windows_sandbox सही होने पर इस्तेमाल करने के लिए, Windows सैंडबॉक्स बाइनरी का पाथ. अगर कोई नाम नहीं है, तो PATH में मिले उस नाम की पहली बाइनरी का इस्तेमाल करें.
--[no]experimental_worker_as_resource
डिफ़ॉल्ट: "false"-
इस सेटिंग के चालू होने पर, वर्कर को ResourceManager से संसाधनों के तौर पर हासिल किया जाता है.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_worker_cancellation
डिफ़ॉल्ट: "false"-
चालू होने पर, Bazel उन कर्मचारियों को रद्द करने के अनुरोध भेज सकता है जो उन्हें सपोर्ट करते हैं.
टैग:execution
--[no]experimental_worker_multiplex
डिफ़ॉल्ट: "सही"-
चालू होने पर, प्रयोग के तौर पर मल्टीप्लेक्सिंग सुविधा के साथ काम करने वाले वर्कर, उस सुविधा का इस्तेमाल करेंगे.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_worker_multiplex_sandboxing
डिफ़ॉल्ट: "false"-
चालू होने पर, मल्टीप्लेक्स वर्कर को सैंडबॉक्स किया जाएगा. इसके लिए, हर ऑफ़िस के अनुरोध के लिए एक अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल किया जाएगा. सिर्फ़ उन वर्कर को सैंडबॉक्स किया जाएगा जिनके लिए 'supports-multiplex-sandboxing' एक्ज़ीक्यूट करने की ज़रूरी शर्त पूरी होगी.
टैग:execution
--[no]experimental_worker_strict_flagfiles
डिफ़ॉल्ट: "false"-
चालू होने पर, वर्कर की खासियत का पालन न करने वाले वर्कर के लिए कार्रवाइयाँ आर्ग्युमेंट के तौर पर गड़बड़ी हो सकती है. वर्कर आर्ग्युमेंट में, आर्ग्युमेंट की सूची में सबसे आखिर में एक @flagfile आर्ग्युमेंट होना चाहिए.
टैग:execution
--genrule_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
जेननियम लागू करने का तरीका बताएं. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> का इस्तेमाल करें या सिर्फ़ जनरेटर को कंट्रोल करने के लिए --strategy=Gen rules=<value> का इस्तेमाल करें.
टैग:execution
- ऐप्लिकेशन के
--high_priority_workers=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
सबसे ज़्यादा प्राथमिकता वाले कर्मचारियों के काम के बारे में जानकारी. जब ज़्यादा प्राथमिकता वाले वर्कर चलाने होते हैं, तब बाकी सभी वर्कर को थ्रॉटल कर दिया जाता है.
टैग:execution
--[no]incompatible_remote_dangling_symlinks
डिफ़ॉल्ट: "सही"-
अगर सही पर सेट किया गया है और --insupported_remote_symlinks को भी सेट किया गया है, तो ऐक्शन आउटपुट में सिमलिंक को लटकने की अनुमति है.
टैग:execution
,incompatible_change
--[no]incompatible_remote_symlinks
डिफ़ॉल्ट: "सही"-
अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैशिंग/एक्ज़ीक्यूशन प्रोटोकॉल में ऐक्शन आउटपुट में सिमलिंक दिखाएगा. अगर ऐसा नहीं होता है, तो सिमलिंक का पालन किया जाएगा और उन्हें फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए #6631 पर जाएं.
टैग:execution
,incompatible_change
--[no]incompatible_sandbox_hermetic_tmp
डिफ़ॉल्ट: "false"-
अगर नीति को 'सही है' पर सेट किया जाता है, तो हर Linux सैंडबॉक्स के लिए खाली डायरेक्ट्री सेट की जाएगी. इसे होस्ट फ़ाइल सिस्टम के साथ /tmp करने के बजाय, /tmp के तौर पर माउंट किया जाएगा. सभी सैंडबॉक्स में होस्ट का/tmp देखते रहने के लिए --sandbox_add_mount_pair=/tmp इस्तेमाल करें.
टैग:execution
--[no]internal_spawn_scheduler
डिफ़ॉल्ट: "false"-
प्लेसहोल्डर का विकल्प, ताकि हम 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") का इस्तेमाल करता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<flow>) होती है. "auto", "Host_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. वैल्यू को 2,500 से ज़्यादा सेट करने पर, मेमोरी की समस्याएं हो सकती हैं. "auto", होस्ट के संसाधनों के आधार पर सही डिफ़ॉल्ट वैल्यू कैलकुलेट करता है.
टैग:host_machine_resource_optimizations
,execution
--[no]keep_going
[-k
] डिफ़ॉल्ट: "false"-
किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. हालांकि, फ़ेल हो चुके टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता, लेकिन इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें पूरी की जा सकती हैं.
टैग:eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "ऑटो"-
लोडिंग/विश्लेषण के चरण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") इस्तेमाल किया जाता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. "auto", "Host_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
--[no]reuse_sandbox_directories
डिफ़ॉल्ट: "false"-
अगर नीति को 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स वाले नॉन- वर्कर प्रोग्राम के लिए इस्तेमाल की गई डायरेक्ट्री का फिर से इस्तेमाल किया जा सकता है. ऐसा करने से, सेटअप करने में लगने वाले बेवजह खर्च से बचा जा सकता है.
टैग:host_machine_resource_optimizations
,execution
--sandbox_base=<a string>
डिफ़ॉल्ट: ""-
इसकी मदद से, सैंडबॉक्स इस पाथ के नीचे अपनी सैंडबॉक्स डायरेक्ट्री बना सकता है. आपके बिल्ड /टेस्ट में कई इनपुट फ़ाइलें होने पर, परफ़ॉर्मेंस को बेहतर बनाने के लिए tmpfs (जैसे कि/run / shm) पर कोई पाथ तय करें. ध्यान दें: कार्रवाइयों से जनरेट होने वाली आउटपुट और इंटरमीडिएट फ़ाइलों को होल्ड करने के लिए, आपको tmpfs पर ज़रूरत के मुताबिक रैम और खाली जगह की ज़रूरत है.
टैग:host_machine_resource_optimizations
,execution
--[no]sandbox_explicit_pseudoterminal
डिफ़ॉल्ट: "false"-
सैंडबॉक्स की गई कार्रवाइयों के लिए, साफ़ तौर पर स्यूडोटर्मिनल बनाने की सुविधा चालू करें. कुछ Linux डिस्ट्रिब्यूशन के लिए, प्रोसेस के ग्रुप आईडी को सैंडबॉक्स के अंदर 'tty' पर सेट करना ज़रूरी होता है, ताकि स्यूडोटर्मिनल काम कर सकें. अगर इससे समस्या आ रही है, तो इस फ़्लैग को बंद किया जा सकता है, ताकि दूसरे ग्रुप का इस्तेमाल किया जा सके.
टैग:execution
- ऐप्लिकेशन के
--sandbox_tmpfs_path=<an absolute path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
सैंडबॉक्स की गई कार्रवाइयों के लिए, इस ऐब्सलूट पाथ पर एक खाली और लिखने वाली डायरेक्ट्री लगाएं. अगर सैंडबॉक्सिंग इसके साथ काम करती है, तो इसे अनदेखा कर दिया जाए.
टैग:host_machine_resource_optimizations
,execution
--spawn_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
जानें कि Spwn कार्रवाइयों को डिफ़ॉल्ट रूप से कैसे एक्ज़ीक्यूट किया जाता है. यह सबसे ऊंची से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट को स्वीकार करता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है, जो उस कार्रवाई को लागू कर सके. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग:execution
- ऐप्लिकेशन के
--strategy=<a '[name=]value1[,..,valueN]' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
दूसरी वजहों के कंपाइलेशन को शेयर करने का तरीका बताएं. यह सबसे ऊंची से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट को स्वीकार करता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है, जो उस कार्रवाई को लागू कर सके. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग --spawn_strategy (और --genनियम_strategy) के ज़रिए सेट की गई वैल्यू को बदल देता है, अगर इसे mnemonic Genrole के साथ इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग:execution
- ऐप्लिकेशन के
--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
यह बदलें कि किसी खास regex_फ़िल्टर से मेल खाने वाली जानकारी वाले स्पॉन ऐक्शन को लागू करने के लिए, किस स्पॉन स्ट्रेटजी का इस्तेमाल करना चाहिए. रेगुलर एक्सप्रेशन फ़िल्टर मैचिंग के बारे में जानने के लिए, --per_file_copt: देखें. ब्यौरे से मैच करने वाले पहले regex_फ़िल्टर का इस्तेमाल किया जाता है. यह विकल्प रणनीति तय करने के लिए दूसरे फ़्लैग को ओवरराइड करता है. उदाहरण के लिए: --strategy_regexp=//foo.*\.cc,-//foo/bar=local की जानकारी, //foo.*.cc से मेल खाने पर, //foo/Bar से नहीं, बल्कि स्थानीय रणनीति का इस्तेमाल करके की जाती है. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed'' 'स्थानीय' कार्यनीति के साथ 'Compiling //foo/bar/baz' चलाएगा, लेकिन ऑर्डर उलटने पर वह 'सैंडबॉक्स' की मदद से चलेगा.
टैग:execution
- ऐप्लिकेशन के
--worker_extra_flag=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अतिरिक्त कमांड-फ़्लैग, जिन्हें वर्कर प्रोसेस के साथ-साथ --persistent_worker में भी भेजा जाएगा, जो mnemonic जैसे होते हैं. उदाहरण के लिए, --worker_extra_flag=Javac=--debug.
टैग:execution
,host_machine_resource_optimizations
- ऐप्लिकेशन के
--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - 'worker' रणनीति का इस्तेमाल करने पर, वर्कर प्रोसेस के कितने इंस्टेंस (जैसे, परसिस्टेंट Java कंपाइलर) लॉन्च हो सकते हैं. हर वर्कर एमनेमोनिक के लिए अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर बताया जा सकता है. एक पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल करता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<flow>) होती है. "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">
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर आप --experimental_worker_multiplex के साथ 'worker' रणनीति का इस्तेमाल करते हैं, तो मल्टीप्लेक्स वर्कर प्रोसेस के साथ-साथ कितने WorkRequests को मिल सकता है. हर वर्कर एमनेमोनिक के लिए अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर बताया जा सकता है. एक पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") का इस्तेमाल करता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<flow>) होती है. "auto", "Host_CPUS*.5". 'ऑटो', मशीन की क्षमता के आधार पर उचित डिफ़ॉल्ट वैल्यू कैलकुलेट करता है. "=value" ऐसे शब्दों के लिए डिफ़ॉल्ट वैल्यू सेट करता है जिनके बारे में जानकारी नहीं दी गई है.
टैग:execution
,host_machine_resource_optimizations
--[no]worker_quit_after_build
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, बिल्ड पूरा होने के बाद सभी वर्कर बाहर निकल जाते हैं.
टैग:execution
,host_machine_resource_optimizations
--[no]worker_sandboxing
डिफ़ॉल्ट: "false"-
चालू होने पर, वर्कर को सैंडबॉक्स किए गए एनवायरमेंट में एक्ज़ीक्यूट किया जाएगा.
टैग:execution
--[no]worker_verbose
डिफ़ॉल्ट: "false"- यह सुविधा चालू होने पर, वर्कर के शुरू होने, शटडाउन होने पर, वर्बोज़ मैसेज प्रिंट किए जाते हैं ...
- कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:
--[no]incompatible_disable_runtimes_filegroups
डिफ़ॉल्ट: "false"-
no-op.
टैग:action_command_lines
,loading_and_analysis
,deprecated
,incompatible_change
--[no]incompatible_dont_emit_static_libgcc
डिफ़ॉल्ट: "सही"-
no-op.
टैग:action_command_lines
,loading_and_analysis
,deprecated
,incompatible_change
--[no]incompatible_linkopts_in_user_link_flags
डिफ़ॉल्ट: "सही"-
अब काम नहीं करता.
टैग:action_command_lines
,loading_and_analysis
,deprecated
,incompatible_change
- कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:
--[no]build
डिफ़ॉल्ट: "सही"-
बिल्ड लागू करें. आम तौर पर, यह ऐसा ही होता है. --nobuild तय करने से, बिल्ड ऐक्शन को एक्ज़ीक्यूट करने से पहले बिल्ड बंद हो जाता है, पैकेज लोड होने और विश्लेषण के चरणों के पूरा होने पर शून्य दिखता है; यह मोड उन फ़ेज़ के टेस्ट करने के लिए उपयोगी है.
टैग:execution
,affects_outputs
--[no]experimental_run_validations
डिफ़ॉल्ट: "सही"-
इसके बजाय, --run_validation का इस्तेमाल करें.
टैग:execution
,affects_outputs
--[no]experimental_use_validation_aspect
डिफ़ॉल्ट: "false"-
आसपेक्ट का इस्तेमाल करके, पुष्टि करने वाली कार्रवाइयों को चलाना है या नहीं (टेस्ट के साथ एक जैसी कार्रवाई के लिए).
टैग:execution
,affects_outputs
- ऐप्लिकेशन के
--output_groups=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इसमें हर नाम से पहले + या - का इस्तेमाल करना ज़रूरी नहीं होता. आउटपुट ग्रुप के डिफ़ॉल्ट सेट में, + से शुरू होने वाले ग्रुप को जोड़ा जाता है और - से शुरू होने वाले ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप प्रीफ़िक्स नहीं है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हटा दिया जाता है. उदाहरण के लिए, --आउटपुट_ग्रुप=+foo,+bar, डिफ़ॉल्ट सेट, foo, और बार के यूनियन को बनाता है. वहीं, --return_groups=foo,bar की जगह डिफ़ॉल्ट सेट को इस तरह से ओवरराइड करता है, जैसे कि सिर्फ़ foo और बार.
टैग:execution
,affects_outputs
--[no]run_validations
डिफ़ॉल्ट: "सही"-
बिल्ड के हिस्से के तौर पर, पुष्टि करने से जुड़ी कार्रवाइयां चलाना है या नहीं. https://bazel.build/extending/rules#validation_actions देखें
टैग:execution
,affects_outputs
- ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, तय किए गए आउटपुट के मुताबिक उसकी वैल्यू पर असर डाल सकते हैं, जबकि असल में उस आउटपुट की वैल्यू पर असर डाल सकते हैं:
- ऐप्लिकेशन के
--aspects=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - टॉप लेवल टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा-सेपरेटेड लिस्ट. सूची में, अगर sample some_aspect ज़रूरी आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) वाली कंपनियों के बारे में ज़रूरी जानकारी देता है, तो some_aspect हर पहलू के बाद चलेगा. इसके अलावा, some_aspect ज़रूरी एट्रिब्यूट के बताए गए सभी ज़रूरी पहलुओं के बाद ही काम करेगा. इसके बाद कुछ_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: लॉग मैसेज इस तरह जनरेट करें जैसे 'सामान्य' पास किए गए हों, लेकिन असल में कोई फ़ाइल सिस्टम कार्रवाई न करें (टूल के लिए उपयोगी).
ध्यान दें कि सिर्फ़ उन सिमलिंक के नाम पर असर पड़ सकता है जिनके नाम, --symlink_prefix के मौजूदा वैल्यू से जनरेट हुए हैं; अगर प्रीफ़िक्स में बदलाव होता है, तो पहले से मौजूद कोई भी सिमलिंक बाकी रह जाएंगे.
टैग:affects_outputs
--[no]experimental_convenience_symlinks_bep_event
डिफ़ॉल्ट: "false"-
इस फ़्लैग से यह कंट्रोल किया जाता है कि हम बिल्ड इवेंटसुविधाSymlinksIdentified को बिल्ड इवेंट प्रोटोकॉल में पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में सुविधाSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक शामिल होंगे. गलत होने पर, BuildEventProtocol में needSymlinksIdentified एंट्री के लिए, कोई वैल्यू नहीं दिखेगी.
टैग:affects_outputs
- ऐप्लिकेशन के
--experimental_multi_cpu=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अब सेवा में नहीं है. No-op.
टैग:affects_outputs
,experimental
--remote_download_minimal
-
लोकल मशीन पर, रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ शिपिंग_metadata और --remote_download_इस=minimal.
इसमें बड़ा होता है:
--nobuild_runfile_links
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=minimal
टैग:affects_outputs
--remote_download_outputs=<all, minimal or toplevel>
डिफ़ॉल्ट: "सभी"-
अगर इस नीति को 'मिनिमल' पर सेट किया जाता है, तो लोकल मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होगा. हालांकि, लोकल ऐक्शन के लिए ज़रूरी आउटपुट आउटपुट सिर्फ़ कुछ ही होंगे. अगर 'टॉप-लेवल' पर सेट किया जाता है, तो यह'कम से कम' की तरह काम करता है. अंतर सिर्फ़ यह है कि यह टॉप लेवल टारगेट के आउटपुट भी लोकल मशीन से डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ बहुत मुश्किल है, तो दोनों विकल्पों से बिल्ड में लगने वाला समय काफ़ी कम हो सकता है.
टैग:affects_outputs
--remote_download_symlink_template=<a string>
डिफ़ॉल्ट: ""-
लोकल मशीन पर रिमोट बिल्ड आउटपुट डाउनलोड करने के बजाय, सॉफ़्ट लिंक बनाएं. सिंबॉलिक लिंक का टारगेट, टेंप्लेट स्ट्रिंग के रूप में तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं, जो ऑब्जेक्ट के हैश तक और बाइट में साइज़ तक बढ़ते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर CAS से ऑब्जेक्ट लोड करते हैं.
टैग:affects_outputs
--remote_download_toplevel
-
टॉप लेवल टारगेट के रिमोट आउटपुट सिर्फ़ लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ प्रिंट_metadata और --remote_download_इस=toplevel.
इसमें बढ़ता है:
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=toplevel
टैग:affects_outputs
--symlink_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह प्रीफ़िक्स, बिल्ड के बाद बनाए जाने वाले किसी भी सुविधा सिमलिंक से पहले जोड़ा जाता है. अगर इसे छोड़ा जाता है, तो डिफ़ॉल्ट वैल्यू, बिल्ड टूल के नाम के बाद हाइफ़न के बाद मौजूद होती है. अगर '/' पास हो जाता है, तो कोई सिमलिंक नहीं बनाए जाते और कोई चेतावनी नहीं भेजी जाती. चेतावनी: '/' के लिए उपलब्ध खास फ़ंक्शन को जल्द ही बंद कर दिया जाएगा. इसके बजाय, --experimental_convenience_symlinks=ignore का इस्तेमाल करें.
टैग:affects_outputs
- Bzel के मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--[no]experimental_docker_privileged
डिफ़ॉल्ट: "false"-
अगर यह सुविधा चालू की जाती है, तो कार्रवाई करते समय Bazel, 'docker चलाने' के लिए -- खास अधिकार वाला फ़्लैग पास कर देगा. आपके बिल्ड को इसकी ज़रूरत पड़ सकती है, लेकिन इससे हर्मेटिटी कम भी हो सकती है.
टैग:execution
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--[no]experimental_sandboxfs_map_symlink_targets
डिफ़ॉल्ट: "false"-
सही होने पर, सैंडबॉक्स में ऐक्शन इनपुट के तौर पर दिए गए सिंबॉलिक लिंक के टारगेट को मैप करता है. यह सुविधा पूरी तरह से उन गड़बड़ी नियमों को हल करने के लिए मौजूद है जो खुद ऐसा नहीं करते और ऐसे सभी नियमों के ठीक हो जाने के बाद उन्हें हटा दिया जाना चाहिए.
टैग:host_machine_resource_optimizations
,execution
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
--[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
डिफ़ॉल्ट: "सही"- कार्रवाइयों के लिए डिफ़ॉल्ट रूप से नेटवर्क ऐक्सेस करने दें. हो सकता है कि यह सभी सैंडबॉक्सिंग लागू करने के साथ काम न करे.
--[no]sandbox_fake_hostname
डिफ़ॉल्ट: "false"-
सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग:execution
--[no]sandbox_fake_username
डिफ़ॉल्ट: "false"-
सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'nobody' के तौर पर सेट करें.
टैग:execution
- ऐप्लिकेशन के
--sandbox_writable_path=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
सैंडबॉक्स की गई कार्रवाइयों के लिए, सैंडबॉक्स में किसी मौजूदा डायरेक्ट्री को लिखने लायक बनाएं (अगर सैंडबॉक्सिंग लागू करने पर काम करता है, नहीं तो इसे अनदेखा कर दिया जाता है).
टैग:execution
- यह विकल्प, Starlark भाषा या बिल्ड एपीआई के सिमैंटिक पर असर डालता है. ऐसा उस बिल्ड एपीआई को ऐक्सेस करने के लिए किया जा सकता है जिसे BUILD फ़ाइलें, .bzl फ़ाइलें या WORKSPACE फ़ाइलें ऐक्सेस करनी हैं.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "false"-
अगर sensitive_enforce_config_setting_ पहचानने के लिए गलत वैल्यू है, तो यह नॉप है. ऐसा न होने पर, अगर यह फ़्लैग गलत है, तो बिना किसी खास 'किसको दिखे' एट्रिब्यूट के बिना कोई भी config_setting //visible:public पर सेट कर दे. अगर यह फ़्लैग सही है, तो config_setting, दिखने के उसी लॉजिक का पालन करेगी जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:
--[no]check_tests_up_to_date
डिफ़ॉल्ट: "false"-
टेस्ट न करें. बस यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी जांच के नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर किसी टेस्ट को बनाने या उसे एक्ज़ीक्यूट करने की ज़रूरत पड़ती है, तो गड़बड़ी की शिकायत की जाती है और जांच नहीं हो पाती. यह विकल्प --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>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
किसी भी तरह की जांच फ़ेल होने पर, हर जांच को उसकी बताई गई संख्या तक फिर से करने की कोशिश की जाएगी. जिन परीक्षाओं को एक से ज़्यादा बार पास करने की ज़रूरत पड़ती है उन्हें जांच की खास जानकारी में 'FLAKY' के तौर पर मार्क किया जाता है. आम तौर पर, वैल्यू के तौर पर सिर्फ़ एक पूर्णांक या 'डिफ़ॉल्ट' स्ट्रिंग की जाती है. अगर पूर्णांक शामिल है, तो सभी टेस्ट N बार तक चलाए जाएंगे. अगर यह 'डिफ़ॉल्ट' है, तो सामान्य जांच के लिए सिर्फ़ एक बार जांच करने की कोशिश की जाएगी. साथ ही, उन जांचों के लिए तीन कोशिश की जाएगी जिन्हें उनके नियम (फ़्लेकी=1 एट्रिब्यूट) के हिसाब से, पूरी तरह से फ़्लैकी के तौर पर मार्क किया गया है. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. जहां flaky_test_attempts यह ऊपर है और regex_filter का मतलब है, रेगुलर एक्सप्रेशन पैटर्न को शामिल और बाहर करना. साथ ही, --runs_per_test भी देखें. उदाहरण: --flaky_test_attempts=//foo/.*,-//foo/bar/.*@3, //foo/ में सभी टेस्ट को तीन बार डीफ़्लेक्स करता है. इस विकल्प को कई बार इस्तेमाल किया जा सकता है. मेल खाने वाले सबसे हाल ही में पास किए गए तर्क को प्राथमिकता दी जाती है. अगर कुछ भी मैच नहीं करता है, तो व्यवहार ऊपर 'डिफ़ॉल्ट' के रूप में होता है.
टैग: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") का इस्तेमाल करता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<flow>) होती है. "auto", "Host_CPUS*.5". 0 का मतलब है कि लोकल संसाधन, लोकल टेस्ट जॉब की संख्या को एक साथ चलाने के लिए सीमित कर देंगे. इसे --jobs के लिए मान से ज़्यादा पर सेट करने का असर नहीं पड़ता.
टैग:execution
--[no]test_keep_going
डिफ़ॉल्ट: "सही"-
बंद होने पर, कोई भी टेस्ट पास नहीं होने पर पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से सभी टेस्ट चलाए जाते हैं, भले ही कुछ टेस्ट पास न हो पाएं.
टैग:execution
--test_strategy=<a string>
डिफ़ॉल्ट: ""-
यह बताता है कि टेस्ट करने के लिए किस रणनीति का इस्तेमाल करना है.
टैग:execution
--test_tmpdir=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- 'bazel टेस्ट' के इस्तेमाल के लिए, बेस अस्थायी डायरेक्ट्री के बारे में बताता है.
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]announce
डिफ़ॉल्ट: "false"-
अब सेवा में नहीं है. No-op.
टैग:affects_outputs
--[no]debug_spawn_scheduler
डिफ़ॉल्ट: "false"--[no]experimental_bep_target_summary
डिफ़ॉल्ट: "false"- Targetsummary इवेंट को पब्लिश करना है या नहीं.
--[no]experimental_build_event_expand_filesets
डिफ़ॉल्ट: "false"-
अगर सही हो, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, BEP में फ़ाइलसेट को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "false"-
अगर सही है, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी में मिलते-जुलते फ़ाइलसेट सिमलिंक को पूरी तरह ठीक करें. --experimental_build_event_expand_filesets की ज़रूरत है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
Bzel को बिल्ड इवेंट को ज़्यादा से ज़्यादा कितनी बार अपलोड करने की कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
डिफ़ॉल्ट: "1s"-
शुरू में, बीईपी अपलोड न होने पर, एक्सपोनेन्शियल बैकऑफ़ फिर से होने में कम से कम देरी. (exponent: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
चुनें कि बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को कैसे अपलोड करें.
टैग:affects_outputs
--[no]experimental_collect_local_sandbox_action_metrics
डिफ़ॉल्ट: "सही"-
चालू होने पर, एक्ज़ीक्यूशन के आंकड़े (जैसे कि उपयोगकर्ता और सिस्टम का समय) स्थानीय तौर पर की जाने वाली उन कार्रवाइयों के लिए रिकॉर्ड किए जाते हैं जो सैंडबॉक्सिंग का इस्तेमाल करती हैं
टैग:execution
--[no]experimental_docker_verbose
डिफ़ॉल्ट: "false"-
अगर यह सुविधा चालू की जाती है, तो Bazel, Docker सैंडबॉक्स की रणनीति के बारे में ज़्यादा वर्बोस मैसेज प्रिंट करेगा.
टैग:execution
--[no]experimental_materialize_param_files_directly
डिफ़ॉल्ट: "false"-
अगर पैरामीटर फ़ाइलों को मटेरियलाइज़ किया जा रहा है, तो डिस्क पर सीधे लिखने की सुविधा का इस्तेमाल करके ऐसा करें.
टैग:execution
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो Starlark की ऐसी वैल्यू लिखें जो Starlark के डेटा स्टोर करने की जगह के उन सभी नियमों की हल की गई जानकारी के साथ होती है जिन्हें लागू किया गया था.
टैग:affects_outputs
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "false"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग:affects_outputs
--explain=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
इसकी वजह, बिल्ड सिस्टम को लागू किए गए हर चरण के बारे में बताती है. इसकी वजह, बताई गई लॉग फ़ाइल में होती है.
टैग:affects_outputs
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
TargetComplete इवेंट में, लेगसी key_OUTs फ़ील्ड को जनरेट होने की प्रोसेस को रोकने के लिए इसका इस्तेमाल करें. Bazel और resultsStore इंटिग्रेशन के लिए, आने वाले ज़रूरी टूल ज़रूरी हैं.
टैग:affects_outputs
--[no]materialize_param_files
डिफ़ॉल्ट: "false"-
रिमोट ऐक्शन एक्ज़ीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें सेव करता है. कार्रवाइयों को डीबग करते समय काम आता है. यह --subcommands और --verbose_failures
टैग:execution
--max_config_changes_to_show=<an integer>
डिफ़ॉल्ट: "3"-
बिल्ड के विकल्पों में बदलाव की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नामों की दी गई संख्या दिखती है. अगर दी गई संख्या -1 है, तो सभी बदले गए विकल्प दिखाए जाएंगे.
टैग:terminal_output
--max_test_output_bytes=<an integer>
डिफ़ॉल्ट: "-1"-
हर जांच के लिए, ज़्यादा से ज़्यादा साइज़ के बारे में जानकारी देता है. ऐसा तब होता है, जब --test_OUT 'गड़बड़ी' या 'सभी' हो. बहुत ज़्यादा शोर वाले टेस्ट आउटपुट के आउटपुट को खराब होने से बचाने के लिए इसका इस्तेमाल किया जाता है. टेस्ट हेडर, लॉग साइज़ में शामिल होता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट में कुछ भी नहीं है या कुछ भी नहीं है.
टैग:test_runner
,terminal_output
,execution
--output_filter=<a valid Java regular expression>
डिफ़ॉल्ट: ब्यौरा देखें-
सिर्फ़ दिए गए रेगुलर एक्सप्रेशन से मेल खाने वाले नाम वाले नियमों के लिए चेतावनियां दिखाता है.
टैग:affects_outputs
--progress_report_interval=<an integer in 0-3600 range>
डिफ़ॉल्ट: "0"-
जो जॉब अब भी चल रही हैं उनकी रिपोर्ट के बीच में सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, हर मिनट में एक बार रिपोर्ट की प्रोग्रेस रिपोर्ट की जाएगी. --curses चालू होने पर, प्रोग्रेस की रिपोर्ट हर सेकंड दी जाती है.
टैग:affects_outputs
--remote_print_execution_messages=<failure, success or all>
डिफ़ॉल्ट: "failure"-
चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज को कब प्रिंट करना है. मान्य वैल्यू 'असफलता' होती हैं, सिर्फ़ काम न करने पर प्रिंट करने के लिए, सिर्फ़ सफलता पर प्रिंट करने के लिए `सफलता`, और हमेशा प्रिंट करने के लिए `सभी`.
टैग:terminal_output
--[no]sandbox_debug
डिफ़ॉल्ट: "false"-
सैंडबॉक्स करने की सुविधा के लिए, डीबग करने की सुविधाएं चालू करता है. इसमें दो चीज़ें शामिल हैं: पहली, सैंडबॉक्स रूट की सामग्री को बिल्ड के बाद वैसे ही छोड़ दिया जाता है (और अगर Sandboxfs का इस्तेमाल किया जा रहा है, तो फ़ाइल सिस्टम को माउंट करके छोड़ दिया जाता है); और दूसरा, एक्ज़ीक्यूशन पर ज़्यादा डीबग करने की जानकारी प्रिंट करता है. इससे Bazel या Starlark के नियमों के डेवलपर को, इनपुट फ़ाइलें वगैरह मौजूद न होने की वजह से डीबग करने में समस्या आ सकती है.
टैग:terminal_output
--show_result=<an integer>
डिफ़ॉल्ट: "1"-
बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए, यह बताएं कि उसे अप-टू-डेट किया गया है या नहीं. अगर हां, तो उन आउटपुट फ़ाइलों की सूची बनाएं जो बनाई गई थीं. प्रिंट की गई फ़ाइलें एक सुविधाजनक स्ट्रिंग होती हैं, जिसकी मदद से उन्हें कॉपी करके शेल पर चिपकाया जा सकता है. साथ ही, उन्हें एक्ज़ीक्यूट किया जा सकता है.
इस विकल्प के लिए एक पूर्णांक तर्क की ज़रूरत होती है. यह उन लक्ष्यों की थ्रेशोल्ड संख्या होती है जिनसे ऊपर की नतीजे की जानकारी प्रिंट नहीं की जाती. इस तरह, शून्य मैसेज दिखने से रोकता है और MAX_INT की वजह से नतीजे को प्रिंट करने की प्रोसेस हमेशा होती है. डिफ़ॉल्ट वैल्यू एक होती है.
टैग:affects_outputs
--[no]subcommands
[-s
] डिफ़ॉल्ट: "false"-
बिल्ड के दौरान लागू किए गए सबकमांड दिखाना. मिलते-जुलते फ़्लैग: --execution_log_json_file, --execution_log_binary_file (टूल-फ़्रेंडली फ़ॉर्मैट में, फ़ाइल में सबकमांड को लॉग करने के लिए).
टैग:terminal_output
--test_output=<summary, errors, all or streamed>
की डिफ़ॉल्ट सेटिंग: "खास जानकारी"-
पसंदीदा आउटपुट मोड के बारे में बताता है. मान्य वैल्यू, सिर्फ़ जांच के स्टेटस की खास जानकारी के लिए 'खास जानकारी' होती हैं. 'गड़बड़ियां', फ़ेल हो चुके टेस्ट के लिए टेस्ट लॉग प्रिंट करने के लिए, सभी जांच के लिए 'सभी' लॉग प्रिंट करने के लिए, और रीयल टाइम में सभी जांच के लिए 'स्ट्रीम किए गए' लॉग के लिए 'खास जानकारी' होती हैं. इससे --test_strategy वैल्यू पर ध्यान दिए बिना, एक बार में एक स्थानीय जांच लागू होगी.
टैग:test_runner
,terminal_output
,execution
--test_summary=<short, terse, detailed, none or testcase>
डिफ़ॉल्ट: "छोटा"-
टेस्ट की खास जानकारी का सही फ़ॉर्मैट बताता है. मान्य वैल्यू, सिर्फ़ किए गए जांच के बारे में जानकारी प्रिंट करने के लिए 'छोटा', 'सामान्य' होते हैं, सिर्फ़ असफल जांचों की जानकारी प्रिंट करने के लिए, 'सामान्य' होते हैं, फ़ेल हुए टेस्ट केस की पूरी जानकारी प्रिंट करने के लिए 'जानकारी', टेस्ट केस के रिज़ॉल्यूशन में खास जानकारी प्रिंट करने के लिए 'टेस्टकेस', फ़ेल हुए टेस्ट केस की पूरी जानकारी प्रिंट न करें, और खास जानकारी को हटाने के लिए 'कोई नहीं' प्रिंट न करें.
टैग:terminal_output
--[no]verbose_explanations
डिफ़ॉल्ट: "false"-
अगर --एक्सप्लेनेशंस चालू है, तो यह विकल्प, जानकारी को ज़्यादा शब्दों में दिखाता है. अगर --एक्सप्लेनेशंस को चालू नहीं किया जाता है, तो इसका कोई असर नहीं होता.
टैग:affects_outputs
--[no]verbose_failures
डिफ़ॉल्ट: "false"-
अगर कोई निर्देश काम नहीं करता, तो पूरी कमांड लाइन प्रिंट कर लें.
टैग:terminal_output
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
- ऐप्लिकेशन के
--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_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
--[no]experimental_guard_against_concurrent_changes
डिफ़ॉल्ट: "false"- रिमोट कैश मेमोरी में अपलोड करने से पहले, किसी कार्रवाई की इनपुट फ़ाइलों के समय की जांच करने की सुविधा बंद करने के लिए, इस सेटिंग को बंद करें. कुछ मामलों में, Linux kernel की वजह से फ़ाइलें लिखने में देरी हो सकती है. इसकी वजह से फ़ॉल्स पॉज़िटिव नतीजे मिल सकते हैं.
--experimental_remote_build_event_upload=<all or minimal>
डिफ़ॉल्ट: "सभी"- अगर यह वैल्यू 'सभी' पर सेट है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड किए जाते हैं. अगर इसे 'मिनिमल' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. हालांकि, BEP इस्तेमाल करने वालों के लिए ज़रूरी फ़ाइलें (जैसे, टेस्ट लॉग और टाइम प्रोफ़ाइल) होती हैं. file:// स्कीम का इस्तेमाल लोकल फ़ाइलों के पाथ के लिए होता है और bytestream:// स्कीम का इस्तेमाल अपलोड की गई (पहले से) फ़ाइलों के पाथ के लिए किया जाता है. डिफ़ॉल्ट रूप से 'सभी' चुनें.
--[no]experimental_remote_cache_async
डिफ़ॉल्ट: "false"- अगर सही है, तो रिमोट कैश I/O, इवेंट के इवेंट के तौर पर होने के बजाय, बैकग्राउंड में होगा.
--[no]experimental_remote_cache_compression
डिफ़ॉल्ट: "false"- अगर इस सेटिंग को चालू किया गया है, तो कैश ब्लॉब को zstd की मदद से कंप्रेस या डिकंप्रेस करें.
--experimental_remote_capture_corrupted_outputs=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जहां खराब आउटपुट को कैप्चर किया जाएगा.
--experimental_remote_downloader=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जा सकता है. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback
डिफ़ॉल्ट: "false"- रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर पर वापस जाना चाहिए या नहीं.
--[no]experimental_remote_execution_keepalive
डिफ़ॉल्ट: "false"- रिमोट एक्ज़ीक्यूशन कॉल के लिए कीपअलाइव (चालू रखें) का इस्तेमाल करना है या नहीं.
--experimental_remote_grpc_log=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry Protobufs के क्रम में, हर मैसेज के प्रीफ़िक्स वाला क्रम होता है. यह क्रम वाले इन प्रोटोबफ़ मैसेज के साइज़ को दिखाता है, जैसा कि LogEntry.writeDelimitedTo(OUTStream) के तरीके से किया गया है.
--[no]experimental_remote_mark_tool_inputs
डिफ़ॉल्ट: "false"- अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट परसिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache
डिफ़ॉल्ट: "false"- अगर नीति को 'सही है' पर सेट किया जाता है, तो मर्कल ट्री की कैलकुलेशन को याद किया जाएगा. इससे रिमोट कैश हिट का पता लगाने की स्पीड को बेहतर बनाने में मदद मिलेगी. कैश मेमोरी के पैर के मेमोरी प्रिंट को --experimental_remote_mercle_tree_cache_size की मदद से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer>
डिफ़ॉल्ट: "1000"- रिमोट कैश हिट चेकिंग स्पीड को बेहतर बनाने के लिए, याद किए जाने वाले मर्कले ट्री की संख्या. हालांकि, कैश को सॉफ़्ट रेफ़रंस पर Java की प्रोसेस के हिसाब से अपने-आप कम कर दिया जाता है, लेकिन बहुत ज़्यादा वैल्यू पर सेट करने पर, मेमोरी से बाहर की गड़बड़ियां हो सकती हैं. अगर यह 0 पर सेट है, तो कैश मेमोरी का साइज़ अनलिमिटेड है. सबसे अच्छी वैल्यू, प्रोजेक्ट के साइज़ के आधार पर अलग-अलग होती है. डिफ़ॉल्ट वैल्यू 1,000 होती है.
--[no]incompatible_remote_build_event_upload_respect_no_cache
डिफ़ॉल्ट: "false"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तरीके से कैश मेमोरी में सेव नहीं किया जा सकता.
--[no]incompatible_remote_downloader_send_all_headers
डिफ़ॉल्ट: "सही"-
कई वैल्यू वाले हेडर की सभी वैल्यू को पहले वाले हेडर के बजाय रिमोट डाउनलोडर को भेजना है या नहीं.
टैग:incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root
डिफ़ॉल्ट: "false"-
अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट से जुड़े होते हैं.
टैग:incompatible_change
--[no]incompatible_remote_results_ignore_disk
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो डिस्क कैश मेमोरी पर --noremote_upload_local_results और --noremote_accept_cached लागू नहीं किया जाएगा. अगर एक साथ कई कैश मेमोरी का इस्तेमाल किया जाता है:
--noremote_upload_local_results की वजह से नतीजे डिस्क की कैश मेमोरी में लिखे जाएंगे, लेकिन रिमोट कैश पर अपलोड नहीं किए जाएंगे.
--noremote_accept_cached का नतीजा डिस्क कैश में नतीजों की जांच करने के लिए, Bazel से होगा, लेकिन रिमोट कैश में नहीं.
no-remote-exec कार्रवाइयां डिस्क की कैश मेमोरी को दबा सकती हैं.
ज़्यादा जानकारी के लिए #8216 देखें.
टैग:incompatible_change
--[no]remote_accept_cached
डिफ़ॉल्ट: "सही"- रिमोट कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को स्वीकार करना है या नहीं.
--remote_bytestream_uri_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम, जिसे बिल्ड इवेंट स्ट्रीम में लिखा जाता है. यह विकल्प तब सेट किया जा सकता है, जब बिल्ड के लिए प्रॉक्सी का इस्तेमाल किया जाता है. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, अब रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इस नीति को सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.
--remote_cache=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- कैशिंग एंडपॉइंट का यूआरआई. इस तरह के स्कीमा के साथ काम करने वाले स्कीमा हैं एचटीटीपी, एचटीटीपीएस, जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc://, http:// या unix: schema के बारे में बताएं. https://bazel.build/remote/caching देखें
- ऐप्लिकेशन के
--remote_cache_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे कैश अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
- ऐप्लिकेशन के
--remote_default_exec_properties=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर कोई प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो डिफ़ॉल्ट exec प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए सेट करें.
टैग:affects_outputs
--remote_default_platform_properties=<a string>
डिफ़ॉल्ट: ""- अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से रिमोट_execution_properties सेट नहीं करता है, तो डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन एपीआई के लिए सेट करें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब रिमोट तौर पर एक्ज़ीक्यूशन के लिए, होस्ट प्लैटफ़ॉर्म को एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना गया हो.
- ऐप्लिकेशन के
--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>
डिफ़ॉल्ट: ब्यौरा देखें- होस्ट या होस्ट:रिमोट एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट नंबर. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
- ऐप्लिकेशन के
--remote_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
--remote_instance_name=<a string>
डिफ़ॉल्ट: ""- रिमोट एक्ज़ीक्यूशन एपीआई में, example_name के तौर पर पास करने वाली वैल्यू.
--[no]remote_local_fallback
डिफ़ॉल्ट: "false"- अगर रिमोट तरीके से एक्ज़ीक्यूट करने की सुविधा काम नहीं करती है, तो क्या आपको स्टैंडअलोन लोकल ऐक्शन रणनीति का इस्तेमाल करना चाहिए.
--remote_local_fallback_strategy=<a string>
डिफ़ॉल्ट: "स्थानीय"- नहीं, अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 देखें.
--remote_max_connections=<an integer>
डिफ़ॉल्ट: "100"-
एक साथ ज़्यादा से ज़्यादा कनेक्शन की संख्या, रिमोट कैश/एक्स्क्यूटर तक सीमित रखें. डिफ़ॉल्ट तौर पर, वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है, इसलिए Bazel --remote_max_ connections को एक साथ किए जा सकने वाले अनुरोधों के मुताबिक बना सकता है.
जीआरपीसी रिमोट कैश/एक्स्क्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को हैंडल कर सकता है. इसलिए, Bazel `--remote_max_ connections * 100` एक साथ किए जा सकने वाले अनुरोधों को पूरा कर सकता है.
टैग:host_machine_resource_optimizations
--remote_proxy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer>
डिफ़ॉल्ट: "0"- रिमोट कैश में सेव की जाने वाली रिमोट ऐक्शन की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर करते हैं.
--remote_retries=<an integer>
डिफ़ॉल्ट: "5"- कुछ समय के लिए होने वाली गड़बड़ी को ठीक करने के लिए, कितनी बार कोशिश की जा सकती है. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
--remote_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"- रिमोट एक्ज़ीक्यूशन और कैश कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट करने और रीड टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो वैल्यू को सेकंड के तौर पर समझा जाता है.
--[no]remote_upload_local_results
डिफ़ॉल्ट: "सही"- अगर रिमोट कैश मेमोरी के साथ काम करती है और उपयोगकर्ता के पास इसकी अनुमति है, तो क्या यह लोकल तौर पर एक्ज़ीक्यूट की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है या नहीं.
--[no]remote_verify_downloads
डिफ़ॉल्ट: "सही"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Bazel, सभी रिमोट डाउनलोड के हैश योग का हिसाब लगाएगा. साथ ही, अगर रिमोट तौर पर कैश मेमोरी में सेव की गई वैल्यू, अनुमानित वैल्यू से मेल नहीं खाती है, तो उसे खारिज कर दिया जाएगा.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
--auto_output_filter=<none, all, packages or subpackages>
डिफ़ॉल्ट: "कोई नहीं"- अगर --return_filter की वैल्यू नहीं दी गई है, तो इस विकल्प की वैल्यू का इस्तेमाल करके, अपने-आप फ़िल्टर बनाने की सुविधा का इस्तेमाल किया जाता है. अनुमति वाली वैल्यू 'कोई नहीं' (कुछ भी फ़िल्टर न करें / सब कुछ दिखाएं), 'सभी' (सब कुछ फ़िल्टर करें / कुछ भी न दिखाएं), 'पैकेज' (ब्लेज़ कमांड लाइन पर बताए गए पैकेज में मौजूद नियमों से मिले आउटपुट शामिल हैं), और 'सबपैकेज' हैं. जैसे, 'पैकेज'. हालांकि, इसमें सबपैकेज भी शामिल होते हैं). 'पैकेज' और 'सबपैकेज' वैल्यू के लिए, //java/foo और //javatest/foo को एक पैकेज माना जाता है)'.
--[no]build_manual_tests
डिफ़ॉल्ट: "false"- 'मैन्युअल' टैग किए गए टेस्ट टारगेट को बनाने के लिए बाध्य करता है. 'मैन्युअल' जांच को प्रोसेस नहीं किया जाता. यह विकल्प उन्हें हर हाल में बनाने के लिए मजबूर करता है, लेकिन उसे एक्ज़ीक्यूट नहीं करता.
--build_tag_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- टैग की कॉमा-सेपरेटेड लिस्ट के बारे में बताता है. बाहर रखे गए टैग के बारे में बताने के लिए, हर टैग से पहले वैकल्पिक रूप से '-' लगाया जा सकता है. केवल वे लक्ष्य बनाए जाएंगे, जिनमें कम से कम एक शामिल किया गया टैग होगा और कोई भी बहिष्कृत टैग शामिल नहीं होगा. यह विकल्प, 'test' कमांड से लागू किए गए टेस्ट के सेट पर असर नहीं डालता. इन्हें, जांच के लिए फ़िल्टर करने के विकल्पों से कंट्रोल किया जाता है, जैसे कि '--test_tag_filters'
--[no]build_tests_only
डिफ़ॉल्ट: "false"- अगर कहा गया है, तो सिर्फ़ *_test और test_suite के नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर तय किए गए दूसरे टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.
--combined_report=<none or lcov>
डिफ़ॉल्ट: "कोई नहीं"- इससे, कुल कवरेज की मनचाही रिपोर्ट के टाइप के बारे में पता चलता है. फ़िलहाल, सिर्फ़ LCOV काम करता है.
--[no]compile_one_dependency
डिफ़ॉल्ट: "false"- आर्ग्यूमेंट फ़ाइलों की एक डिपेंडेंसी कंपाइल करें. यह आईडीई में सोर्स फ़ाइलों के सिंटैक्स की जांच करने के लिए फ़ायदेमंद है. उदाहरण के लिए, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर किसी एक टारगेट को फिर से बनाकर. यह तर्क, सभी बिना फ़्लैग वाले तर्कों की व्याख्या करने के तरीके पर असर डालता है. इसे बनाने के लिए टारगेट न किए जाने वाले तर्क, सोर्स फ़ाइल नाम होते हैं. हर सोर्स फ़ाइल के नाम के लिए, उस पर निर्भर एक आर्बिट्रेरी टारगेट बनाया जाएगा.
--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
डिफ़ॉल्ट: "false"- विश्लेषण का चरण पूरा होने के तुरंत बाद, विश्लेषण की कैश मेमोरी को खारिज कर दें. इससे मेमोरी के इस्तेमाल को ~10% तक कम किया जाता है. हालांकि, इससे ऐप्लिकेशन के इंस्टॉल होने की रफ़्तार कम हो जाती है.
--disk_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जिसमें Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो इसे बना दिया जाएगा.
--embed_label=<a one-line string>
डिफ़ॉल्ट: ""- सोर्स कंट्रोल में किए गए बदलाव या रिलीज़ लेबल को बाइनरी में जोड़ें
--execution_log_binary_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- इस फ़ाइल में लागू किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, डीलिमिटेड स्पॉन प्रोटो के तौर पर लॉग करें. लॉग को पहले बिना क्रम के लिखा जाता है और फिर, शुरू करने की प्रक्रिया के आखिर में, एक स्थिर क्रम में (सीपीयू और मेमोरी इंटेंसिव हो सकता है) क्रम से लगाया जाता है. मिलते-जुलते फ़्लैग: --execution_log_json_file (ऑर्डर किए गए टेक्स्ट json फ़ॉर्मैट), --experimental_execution_log_file (अनऑर्डर्ड बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--execution_log_json_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- Sr/main/protobuf/spawn.proto के मुताबिक, एक्ज़ीक्यूट किए गए स्पॉन को इस फ़ाइल में लॉग करें, ताकि सीमांकित Spwn प्रोटो को json फ़ॉर्मैट के तौर पर दिखाया जा सके. लॉग को पहले बिना क्रम के लिखा जाता है और फिर, शुरू करने की प्रक्रिया के आखिर में, एक स्थिर क्रम में (सीपीयू और मेमोरी इंटेंसिव हो सकता है) क्रम से लगाया जाता है. मिलते-जुलते फ़्लैग: मिलते-जुलते फ़्लैग: --execution_log_binary_file (क्रम से दिए गए बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम वाले बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--[no]expand_test_suites
डिफ़ॉल्ट: "सही"-
विश्लेषण से पहले, test_suite के टारगेट को अपने कॉम्पोनेंट टेस्ट में बड़ा करें. जब यह फ़्लैग चालू होता है (डिफ़ॉल्ट तौर पर), तो टेस्ट सुइट से जुड़े टेस्ट पर नेगेटिव टारगेट पैटर्न लागू होंगे. अगर ऐसा नहीं है, तो ये पैटर्न लागू नहीं होंगे. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड लाइन पर टॉप-लेवल के पहलू लागू किए जाते हैं: इसके बाद वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--experimental_credential_helper=<An (unresolved) path to a credential helper for a scope.>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि दिए गए स्कोप (डोमेन) के लिए क्रेडेंशियल वापस पाने में उसका इस्तेमाल किया जा सके. क्रेडेंशियल हेल्पर के क्रेडेंशियल को <code>--google_default_credentials</code>, `--google_क्रेडेंशियल` या <code>.netrc</code> से ज़्यादा अहमियत दी जाती है. https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-Credential-helpers की जानकारी देखें.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मिनट"- उस अवधि को कॉन्फ़िगर करता है जिसके लिए क्रेडेंशियल हेल्पर के क्रेडेंशियल, कैश मेमोरी में सेव किए जाते हैं. किसी दूसरी वैल्यू से शुरू करने पर, पहले से मौजूद एंट्री का लाइफ़टाइम बदल जाएगा; कैश मेमोरी मिटाने के लिए शून्य पास करें. क्लीन कमांड, कैश मेमोरी को हमेशा मिटाता है, भले ही यह फ़्लैग किसी भी तरह का हो.
--experimental_credential_helper_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "5s"- क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. क्रेडेंशियल सहायक इस टाइम आउट के अंदर जवाब नहीं दे पाने पर, बातचीत शुरू नहीं कर पाएंगे.
--experimental_execution_log_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- इस फ़ाइल में लागू किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, डीलिमिटेड स्पॉन प्रोटो के तौर पर लॉग करें. यह फ़ाइल, Spwns के निष्पादन के क्रम में लिखी गई है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (क्रम से दिए गए बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --execution_log_json_file (क्रम से दिए गए टेक्स्ट json फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--[no]experimental_execution_log_spawn_metrics
डिफ़ॉल्ट: "false"- लागू किए गए Spwns लॉग में स्पॉन मेट्रिक शामिल करें.
--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: ""- अलग-अलग पहलुओं के पक्ष में नहीं दिखाया गया. एक्सटर्नल ऐक्शन को शेड्यूल करने के लिए टारगेट के सेट को फ़िल्टर करता है.
--[no]experimental_extra_action_top_level_only
डिफ़ॉल्ट: "false"- अलग-अलग पहलुओं के पक्ष में नहीं दिखाया गया. सिर्फ़ टॉप लेवल के टारगेट के लिए, extra_actions को शेड्यूल करता है.
--[no]experimental_prioritize_local_actions
डिफ़ॉल्ट: "सही"-
अगर सेट की जाती है, तो सिर्फ़ स्थानीय तौर पर की जा सकने वाली कार्रवाइयों को संसाधन हासिल करने का पहला मौका दिया जाता है. डाइनैमिक रूप से चलने वाले वर्कर को दूसरा मौका मिलता है और डाइनैमिक रूप से चलने वाली कार्रवाइयों को आखिरी मौका मिलता है.
टैग:execution
--experimental_spawn_scheduler
-
एक साथ कई कार्रवाइयां करने के लिए, स्थानीय या रिमोट तरीके से कार्रवाइयां करें. Bazel हर ऐक्शन को स्थानीय तौर पर और कहीं से भी उपलब्ध कराता है. साथ ही, सबसे पहले पूरा होने वाले ऐक्शन को चुनता है. अगर कोई कार्रवाई, वर्कर के साथ काम करती है, तो लोकल ऐक्शन, परसिस्टेंट वर्कर मोड में चलेगा. इसके बजाय, `--internal_spawn_scheduler` और `--strategy=<mnemonic>=Dynamic` फ़्लैग का इस्तेमाल करके, किसी व्यक्तिगत ऐक्शन mnemonic को डाइनैमिक एक्ज़ीक्यूशन करें.
इसमें बढ़ता है:
--internal_spawn_scheduler
--spawn_strategy=dynamic
--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
डिफ़ॉल्ट: "false"- पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं. डिफ़ॉल्ट रूप से बंद होता है.
--grpc_keepalive_time=<An immutable length of time.>
डिफ़ॉल्ट: ब्यौरा देखें- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो Bazel इतने समय बाद कनेक्शन पर कोई कार्रवाई नहीं करने के बाद पिंग भेजता है. यह सिर्फ़ तब पिंग करता है, जब कम से कम एक gRPC कॉल लंबित हो. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. कीप-अलाइव पिंग, डिफ़ॉल्ट रूप से बंद रहते हैं. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक से संपर्क करना होगा. उदाहरण के लिए, इस फ़्लैग के लिए 30 सेकंड की वैल्यू सेट करने के लिए, इस तरह से सेट करना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "20 सेकंड"- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव (चालू रखें) टाइम आउट कॉन्फ़िगर करता है. अगर कीप-अलाइव पिंग को --grpc_keepalive_time से चालू किया जाता है, तो Bazel को इतने समय के बाद पिंग का जवाब न मिलने पर, कनेक्शन बंद कर दिया जाता है. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. अगर कीप-अलाइव पिंग को बंद रखा जाता है, तो इस सेटिंग को अनदेखा कर दिया जाता है.
--[no]ignore_unsupported_sandboxing
डिफ़ॉल्ट: "false"- अगर इस सिस्टम पर सैंडबॉक्स करके गेम को चलाने की सुविधा काम नहीं करती, तो चेतावनी प्रिंट न करें.
--[no]incompatible_dont_use_javasourceinfoprovider
डिफ़ॉल्ट: "false"-
No-op
टैग:incompatible_change
--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "Host_CPUS"- Bazel के लिए उपलब्ध लोकल सीपीयू कोर की कुल संख्या, साफ़ तौर पर सेट करें, ताकि बिल्ड ऐक्शन पर खर्च किया जा सके. एक पूर्णांक या "Host_CPUS" लेता है. इसके बाद, वैकल्पिक तौर पर [-|*]<फ़्लोट> (उदाहरण के लिए, उपलब्ध सीपीयू (CPU) की कुल संख्या का अनुमान लगाने के लिए, Bazel सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
--local_ram_resources=<an integer, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "Host_RAM*.67"- Bazel के लिए उपलब्ध लोकल होस्ट रैम (एमबी में) की कुल संख्या साफ़ तौर पर सेट करें, ताकि उसे स्थानीय तौर पर एक्ज़ीक्यूट की गई बिल्ड कार्रवाइयों पर खर्च किया जा सके. एक पूर्णांक या "Host_RAM" लेता है. इसके बाद, वैकल्पिक रूप से [-|*]<floor> (उदाहरण के लिए, उपलब्ध रैम के आधे से ज़्यादा का इस्तेमाल करने के लिए, Host_RAM*.5). डिफ़ॉल्ट रूप से, ("Host_RAM*.67"), Bazel, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और यह पता लगाएगा कि कितनी रैम उपलब्ध है. वह इसका 67% इस्तेमाल करेगा.
--local_termination_grace_seconds=<an integer>
डिफ़ॉल्ट: "15"- समय खत्म होने की वजह से किसी लोकल प्रोसेस को बंद करने और उसे ज़बरदस्ती बंद करने के बीच का समय.
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- कोलन से अलग की गई इस सूची में बताया जाता है कि पैकेज कहां खोजने हैं. '%workspace%' से शुरू होने वाले एलिमेंट, बंद होने वाले फ़ाइल फ़ोल्डर से मिलते-जुलते हैं. अगर इसे खाली छोड़ा जाता है या इसे खाली छोड़ा जाता है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट होता है.
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर इस सुविधा को चालू किया जाता है, तो Bazel "लोडिंग पैकेज:" मैसेज प्रिंट करेगा.
--test_lang_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- इसमें, जांच के लिए इस्तेमाल की जाने वाली भाषाओं की कॉमा-सेपरेटेड लिस्ट होती है. बाहर रखी गई भाषाओं के बारे में बताने के लिए, हर भाषा के पहले '-' लिखा जा सकता है. सिर्फ़ वे टेस्ट टारगेट ही मिलेंगे जो खास भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया जाने वाला नाम, *_test नियम में भाषा के प्रीफ़िक्स के जैसा होना चाहिए. जैसे, 'cc', 'java', 'py' वगैरह में से कोई एक. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_size_filters=<comma-separated list of values: small, medium, large or enormous>
डिफ़ॉल्ट: ""- टेस्ट साइज़ की ऐसी सूची होती है जिसे कॉमा लगाकर अलग किया जाता है. शामिल नहीं किए गए साइज़ के बारे में बताने के लिए, हर साइज़ से पहले '-' लगाया जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जिनमें कम से कम एक साइज़ शामिल हो और उसमें बाहर रखा गया कोई साइज़ न हो. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_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 व्यवहार और टेस्ट कमांड पर असर डालता है.
--tls_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- किसी TLS सर्टिफ़िकेट का पाथ बताएं, जो सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसेमंद हो.
--tls_client_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट के बारे में बताएं. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए, TLS क्लाइंट कुंजी तय करें. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
--workspace_status_command=<path>
डिफ़ॉल्ट: ""- की/वैल्यू पेयर के तौर पर फ़ाइल फ़ोल्डर के स्टेटस की जानकारी देने के लिए, बिल्ड की शुरुआत में शुरू किया गया एक निर्देश. इससे जुड़ी पूरी जानकारी के लिए, उपयोगकर्ता का मैन्युअल देखें. उदाहरण के लिए, टूल/buildstamp/get_workspace_status देखें.
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]check_up_to_date
डिफ़ॉल्ट: "false"-
बिल न बनाएं. बस देखें कि क्या यह अप-टू-डेट है. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड सही तरीके से पूरा हो जाता है. अगर किसी चरण को लागू करने की ज़रूरत होती है, तो गड़बड़ी की रिपोर्ट की जाती है और बिल्ड फ़ेल हो जाता है.
टैग:execution
--[no]experimental_inprocess_symlink_creation
डिफ़ॉल्ट: "false"-
सिमलिंक ट्री बनाने के लिए, डायरेक्ट फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_remotable_source_manifests
डिफ़ॉल्ट: "false"-
सोर्स मेनिफ़ेस्ट कार्रवाइयों को फिर से चालू करना है या नहीं
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_split_coverage_postprocessing
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel एक नए स्पैम में जांच के लिए, कवरेज पोस्टप्रोसेसिंग करेगा.
टैग:execution
--[no]experimental_split_xml_generation
डिफ़ॉल्ट: "सही"-
अगर यह फ़्लैग सेट किया जाता है और टेस्ट कार्रवाई से test.xml फ़ाइल जनरेट नहीं होती, तो Bazel एक अलग कार्रवाई का इस्तेमाल करके, टेस्ट लॉग वाली डमी test.xml फ़ाइल जनरेट करेगा. ऐसा न होने पर, Bazel, टेस्ट ऐक्शन के तौर पर test.xml जनरेट करता है.
टैग:execution
--[no]experimental_strict_fileset_output
डिफ़ॉल्ट: "false"-
अगर यह विकल्प चालू किया जाता है, तो फ़ाइलसेट, सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री को नहीं पीछे छोड़ते या सिमलिंक के प्रति संवेदनशील नहीं होते.
टैग:execution
--genrule_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
जेननियम लागू करने का तरीका बताएं. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_strategy=<value> का इस्तेमाल करें या सिर्फ़ जनरेटर को कंट्रोल करने के लिए --strategy=Gen rules=<value> का इस्तेमाल करें.
टैग:execution
--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") का इस्तेमाल करता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<flow>) होती है. "auto", "Host_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. वैल्यू को 2,500 से ज़्यादा सेट करने पर, मेमोरी की समस्याएं हो सकती हैं. "auto", होस्ट के संसाधनों के आधार पर सही डिफ़ॉल्ट वैल्यू कैलकुलेट करता है.
टैग:host_machine_resource_optimizations
,execution
--[no]keep_going
[-k
] डिफ़ॉल्ट: "false"-
किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. हालांकि, फ़ेल हो चुके टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता, लेकिन इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें पूरी की जा सकती हैं.
टैग:eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "ऑटो"-
लोडिंग/विश्लेषण के चरण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") इस्तेमाल किया जाता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. "auto", "Host_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...>
डिफ़ॉल्ट: ""-
कार्रवाई के बाद की जाने वाली कार्रवाई की जानकारी में, कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो एक्ज़ीक्यूट करने की जानकारी देती हैं. कई आम कार्रवाइयां, एक्ज़ीक्यूट करने की जानकारी के साथ काम करती हैं, जैसे कि Genrun, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय ऑर्डर देना ज़रूरी होता है, क्योंकि एक ही मिनिमनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.
सिंटैक्स: "regex=[+-]key,regex=[+-]key,...".
उदाहरण:
'.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के चलने की जानकारी में, 'x' और 'z' जोड़ता है और 'y' को हटा देता है.
'GenTerms=+requires-x', जेनरूल की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूटिंग की जानकारी में 'requires-x' जोड़ता है.
'(?!GenTerms).*=-requires-x', सभी गैर-जेनरूल कार्रवाइयों के लिए, निष्पादन जानकारी से 'requires-x' को हटा देता है.
टैग:execution
,affects_outputs
,loading_and_analysis
--persistent_android_dex_desugar
-
कर्मचारियों का इस्तेमाल करके, स्थायी Android dex और Desugar कार्रवाइयों को चालू करें.
इसमें बड़ा होता है:
--strategy=Desugar=worker
--strategy=DexBuilder=worker
टैग:host_machine_resource_optimizations
,execution
--persistent_android_resource_processor
-
कर्मचारियों का इस्तेमाल करके, स्थायी Android संसाधन प्रोसेसर चालू करें.
यह इन जगहों तक फैलता है:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
--strategy=Aapt2Optimize=worker
--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
host_machine_resource_optimizations
execution
--persistent_multiplex_android_dex_desugar
-
कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android dex और desugar ऐक्शन चालू करें.
यह इन जगहों पर फैलता है:
--persistent_android_dex_desugar
--modify_execution_info=Desugar=+supports-multiplex-workers
--modify_execution_info=DexBuilder=+supports-multiplex-workers
टैग:host_machine_resource_optimizations
,execution
--persistent_multiplex_android_resource_processor
-
कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android रिसॉर्स प्रोसेसर को चालू करें.
यह इन जगहों तक फैलता है:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers
host_machine_resource_optimizations
execution
--persistent_multiplex_android_tools
-
Android के स्थायी और मल्टीप्लेक्स टूल चालू करें. जैसे- डेक्सिंग, डीयूगरिंग, और रिसॉर्स प्रोसेसिंग.
इसमें बड़ा होता है:
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
--spawn_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
जानें कि Spwn कार्रवाइयों को डिफ़ॉल्ट रूप से कैसे एक्ज़ीक्यूट किया जाता है. यह सबसे ऊंची से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट को स्वीकार करता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है, जो उस कार्रवाई को लागू कर सके. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग:execution
- ऐप्लिकेशन के
--strategy=<a '[name=]value1[,..,valueN]' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
दूसरी वजहों के कंपाइलेशन को शेयर करने का तरीका बताएं. यह सबसे ऊंची से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट को स्वीकार करता है. हर कार्रवाई के लिए, Bazel सबसे ज़्यादा प्राथमिकता वाली रणनीति चुनता है, जो उस कार्रवाई को लागू कर सके. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग --spawn_strategy (और --genनियम_strategy) के ज़रिए सेट की गई वैल्यू को बदल देता है, अगर इसे mnemonic Genrole के साथ इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, https://blog.bazel.build/2019/06/19/list-strategy.html पर जाएं.
टैग:execution
- ऐप्लिकेशन के
--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
यह बदलें कि किसी खास regex_फ़िल्टर से मेल खाने वाली जानकारी वाले स्पॉन ऐक्शन को लागू करने के लिए, किस स्पॉन स्ट्रेटजी का इस्तेमाल करना चाहिए. रेगुलर एक्सप्रेशन फ़िल्टर मैचिंग के बारे में जानने के लिए, --per_file_copt: देखें. ब्यौरे से मैच करने वाले पहले regex_फ़िल्टर का इस्तेमाल किया जाता है. यह विकल्प रणनीति तय करने के लिए दूसरे फ़्लैग को ओवरराइड करता है. उदाहरण के लिए: --strategy_regexp=//foo.*\.cc,-//foo/bar=local की जानकारी, //foo.*.cc से मेल खाने पर, //foo/Bar से नहीं, बल्कि स्थानीय रणनीति का इस्तेमाल करके की जाती है. उदाहरण: --strategy_regexp='Compiling.*/bar=local --strategy_regexp=Compiling=sandboxed'' 'स्थानीय' कार्यनीति के साथ 'Compiling //foo/bar/baz' चलाएगा, लेकिन ऑर्डर उलटने पर वह 'सैंडबॉक्स' की मदद से चलेगा.
टैग:execution
- कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:
--android_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Android का टारगेट कंपाइलर.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_crosstool_top=<a build target label>
डिफ़ॉल्ट: "//external:android/crosstool"-
Android बिल्ड के लिए इस्तेमाल किए गए C++ कंपाइलर की जगह की जानकारी.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_manifest_merger=<legacy, android or force_android>
डिफ़ॉल्ट: "android"-
android_binary नियमों के लिए इस्तेमाल किए जाने वाले मेनिफ़ेस्ट मर्जर को चुनता है. फ़्लैग करें, ताकि पुराने मर्जर की मदद से, Android मेनिफ़ेस्ट को मर्ज करने में मदद मिल सके.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_platforms=<a build target label>
डिफ़ॉल्ट: ""-
ऐसे प्लैटफ़ॉर्म सेट करता है जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी फ़ाइल एक फ़ैट APKs होती है. इसमें, बताए गए हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_sdk=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk"-
उस Android SDK/प्लैटफ़ॉर्म के बारे में बताता है जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--apple_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Apple का टारगेट कंपाइलर. इसकी मदद से, टूलचेन के वैरिएंट चुने जा सकते हैं. उदाहरण के लिए, xcode-beta.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--apple_crosstool_top=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"-
Apple औरobjc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग:loses_incremental_state
,changes_inputs
--apple_grte_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
Apple का टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--cc_output_directory_tag=<a string>
डिफ़ॉल्ट: ""-
कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने के लिए सफ़िक्स के बारे में जानकारी देता है.
टैग:affects_outputs
,explicit_in_output_path
--compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग:loading_and_analysis
,execution
--coverage_output_generator=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_ सुझावों"-
रॉ कवरेज रिपोर्ट को पोस्ट करने के लिए इस्तेमाल होने वाली बाइनरी की जगह. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcov_ सुझावों' का इस्तेमाल करता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_report_generator=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_report_generator"-
कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:coverage_report_generator' होता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_support=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_support"-
उन सहायता फ़ाइलों की जगह जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई के इनपुट के लिए ज़रूरी होती हैं. डिफ़ॉल्ट रूप से '//tools/test:coverage_support' सेट होता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--crosstool_top=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"-
C++ कोड को कंपाइल करने के लिए इस्तेमाल होने वाले क्रॉसटूल पैकेज का लेबल.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--custom_malloc=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
यह तय करता है कि कस्टम Maloc लागू करने की सुविधा कैसे लागू की जाए. यह सेटिंग, बिल्ड के नियमों में मॉलक एट्रिब्यूट को बदल देती है.
टैग:changes_inputs
,affects_outputs
- ऐप्लिकेशन के
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के आगे - (नेगेटिव एक्सप्रेशन) लगाया जाएगा. साथ ही, इन्हें कॉमा लगाकर अलग किए गए कंस्ट्रेंट वैल्यू के टारगेट की सूची में (=) असाइन किया जाएगा. अगर कोई टारगेट, किसी भी नेगेटिव एक्सप्रेशन से मेल नहीं खाता और कम से कम एक पॉज़िटिव एक्सप्रेशन से मैच करता है, तो इसका टूलचेन रिज़ॉल्यूशन इस तरह परफ़ॉर्म किया जाएगा जैसे कि कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर बताया गया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64 //demo के तहत आने वाले किसी भी टारगेट में 'x86_64' जोड़ देगा, लेकिन इनके नाम में 'test' शामिल नहीं होगा.
टैग:loading_and_analysis
--[no]experimental_enable_objc_cc_deps
डिफ़ॉल्ट: "सही"-
यह objc_* नियमों को cc_library पर निर्भर करने की अनुमति देता है. साथ ही, इसकी वजह से कोई भी ऑब्जेसी डिपेंडेंसी --iOS_multi_cpu> में किसी भी वैल्यू के लिए --cpu को "ios_<--ios_cpu>" पर सेट करने के लिए सेट होती है.
टैग:loading_and_analysis
,incompatible_change
--[no]experimental_include_xcode_execution_requirements
डिफ़ॉल्ट: "false"-
अगर इस नीति को सेट किया जाता है, तो हर Xcode कार्रवाई के लिए "requires-xcode:{version}" को लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" चलाने की ज़रूरी शर्त भी जोड़ें.
टैग:loses_incremental_state
,loading_and_analysis
,execution
--[no]experimental_prefer_mutual_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 फ़ाइल में रजिस्टर करने वाले टूलचेन() से पहले किया जाएगा.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन में चुना जाता है और आपको इसे बदलने की ज़रूरत नहीं पड़ती.
टैग:action_command_lines
,affects_outputs
--host_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top को सेट नहीं किया गया है, तो इसे अनदेखा किया जाता है.
टैग:loading_and_analysis
,execution
--host_crosstool_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
डिफ़ॉल्ट रूप से, होस्ट कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler के विकल्पों का इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया गया है, तो Bazel, दिए गए Crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--host_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताया गया है, तो यह सेटिंग, होस्ट कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग:action_command_lines
,affects_outputs
--host_platform=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--[no]incompatible_disable_expand_if_all_available_in_flag_set
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel फ़्लैग_sets में expand_if_all_available को तय करने की अनुमति नहीं देगा(माइग्रेट करने से जुड़े निर्देशों के लिए https://github.com/bazelbuild/bazel/issues/7008 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'nonhost' सुविधाओं को चालू नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_android_toolchain_resolution
डिफ़ॉल्ट: "false"-
टूलचेन रिज़ॉल्यूशन का इस्तेमाल करके, Android के नियमों (Starlark और नेटिव) के लिए Android SDK चुनें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution
डिफ़ॉल्ट: "false"-
Apple SDK for apple के नियम (Starlark और local) चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, lto इंडेक्स करने वाली कमांड लाइनों के लिए, C++ लिंक की कार्रवाई वाली कमांड लाइन का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_cpu_and_compiler_attributes_from_cc_toolchain
डिफ़ॉल्ट: "सही"-
अगर सही है, तो cc_toolchain.cpu और cc_toolchain.compiler एट्रिब्यूट सेट होने पर Bazel शिकायत करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7075 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_legacy_whole_archive
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_require_ctx_in_configure_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel को cc_Common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 देखें).
टैग:loading_and_analysis
,incompatible_change
-
अगर टूलचेन पर इंटरफ़ेस के शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी ELF टूलचेन में यह सेटिंग काम करती है.
टैग:loading_and_analysis
,affects_outputs
,affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में बताता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिले iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
macOS ऐप्लिकेशन बनाने के लिए, macOS SDK टूल के वर्शन के बारे में जानकारी देता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से जुड़े macOS के SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--minimum_os_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह आपके कंपाइलेशन से टारगेट करता है, लेकिन ओएस का कम से कम वर्शन.
टैग:loading_and_analysis
,affects_outputs
--platform_mappings=<a relative path>
डिफ़ॉल्ट: ""-
मैपिंग फ़ाइल की जगह की जानकारी. इससे यह पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं किया गया है, तो किस प्लैटफ़ॉर्म का इस्तेमाल किया जाए या कोई प्लैटफ़ॉर्म पहले से मौजूद होने पर किस तरह के फ़्लैग सेट किए जाएं. मुख्य फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता होना चाहिए. डिफ़ॉल्ट तौर पर 'platform_mappings' (फ़ाइल फ़ोल्डर रूट के तहत आने वाली फ़ाइल).
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--platforms=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म की जानकारी देते हैं.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--python2_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से, यह सुविधा बंद है.
टैग:no_op
,deprecated
--python3_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अब काम नहीं करता. `--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 इंटरप्रेटर को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains इसकी मदद से बंद किया गया है.
टैग:loading_and_analysis
,affects_outputs
--target_platform_fallback=<a build target label>
डिफ़ॉल्ट: "@local_config_platform//:host"-
प्लैटफ़ॉर्म के नियम का लेबल. इसका इस्तेमाल तब किया जाना चाहिए, जब कोई टारगेट प्लैटफ़ॉर्म सेट न किया गया हो और कोई भी प्लैटफ़ॉर्म मैपिंग मौजूदा फ़्लैग से मेल न खाता हो.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह तय करता है कि किस वर्शन का इस्तेमाल करके, tvOS ऐप्लिकेशन बनाया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिलने वाले डिफ़ॉल्ट tvOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह WatchOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिलने वाले डिफ़ॉल्ट WatchOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--xcode_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताया गया है, तो सही बिल्ड ऐक्शन के लिए दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर इसकी जानकारी नहीं दी गई है, तो Xcode के एक्सक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xcode_version_config=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"-
xcode_config नियम का लेबल, बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए इस्तेमाल किया जाता है.
टैग:loses_incremental_state
,loading_and_analysis
- कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:
--[no]apple_enable_auto_dsym_dbg
डिफ़ॉल्ट: "false"-
dbg बिल्ड के लिए, डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलों) को जनरेट करना ज़बरदस्ती चालू करना है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]apple_generate_dsym
डिफ़ॉल्ट: "false"-
डीबग सिंबल(.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
डिफ़ॉल्ट: "false"-
इस सुविधा को चालू करने पर, स्टैटिक और फ़्रैक्शन के साथ C++ टेस्ट बनाते समय, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग:loading_and_analysis
,affects_outputs
--cc_proto_library_header_suffixes=<comma-separated list of options>
डिफ़ॉल्ट: ".pb.h"-
यह cc_proto_library बनाई जाने वाली हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग:affects_outputs
,loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated list of options>
डिफ़ॉल्ट: ".pb.cc"-
cc_proto_library से बनाई जाने वाली सोर्स फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info
डिफ़ॉल्ट: "false"-
proto_library में, वैकल्पिक Java एपीआई वर्शन के लिए, ज़्यादा कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_proto_extra_actions
डिफ़ॉल्ट: "false"-
proto_library में, वैकल्पिक Java एपीआई वर्शन के लिए, ज़्यादा कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_run_validations
डिफ़ॉल्ट: "सही"-
इसके बजाय, --run_validation का इस्तेमाल करें.
टैग:execution
,affects_outputs
--[no]experimental_save_feature_state
डिफ़ॉल्ट: "false"-
चालू किए गए और अनुरोध किए गए फ़ंक्शन की स्थिति को कंपाइलेशन के आउटपुट के तौर पर सेव करें.
टैग:affects_outputs
,experimental
--[no]experimental_use_validation_aspect
डिफ़ॉल्ट: "false"-
आसपेक्ट का इस्तेमाल करके, पुष्टि करने वाली कार्रवाइयों को चलाना है या नहीं (टेस्ट के साथ एक जैसी कार्रवाई के लिए).
टैग:execution
,affects_outputs
--fission=<a set of compilation modes>
डिफ़ॉल्ट: "नहीं"-
यह बताता है कि C++ के कंपाइलेशन और लिंक के लिए कौनसे कंपाइलेशन मोड, फ़ंक्शन का इस्तेमाल करते हैं. यह सभी मोड चालू करने के लिए {'Fastbuild', 'dbg', 'opt'} या विशेष वैल्यू 'yes' का कोई भी कॉम्बिनेशन और सभी मोड बंद करने के लिए 'no' हो सकता है.
टैग:loading_and_analysis
,action_command_lines
,affects_outputs
--[no]incompatible_always_include_files_in_data
डिफ़ॉल्ट: "सही"-
अगर सही है, तो नेटिव नियम अपनी रनफ़ाइल में <code>DefaultInfo.files</code> डेटा डिपेंडेंसी जोड़ देते हैं. यह डेटा, Starlark के नियमों (https://bazel.build/extending/rules#runfiles_features_to_avoid) के हिसाब से काम करता है.
टैग:affects_outputs
,incompatible_change
--[no]legacy_external_runfiles
डिफ़ॉल्ट: "सही"-
अगर सही है, तो .runfiles/wsname/external/repo के तहत, बाहरी डेटा स्टोर करने की जगहों के लिए रनफ़ाइल्स सिमलिंक जंगलों को बनाएं.
टैग:affects_outputs
--[no]objc_generate_linkmap
डिफ़ॉल्ट: "false"-
तय करता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग:affects_outputs
- ऐप्लिकेशन के
--output_groups=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इसमें हर नाम से पहले + या - का इस्तेमाल करना ज़रूरी नहीं होता. आउटपुट ग्रुप के डिफ़ॉल्ट सेट में, + से शुरू होने वाले ग्रुप को जोड़ा जाता है और - से शुरू होने वाले ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप प्रीफ़िक्स नहीं है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हटा दिया जाता है. उदाहरण के लिए, --आउटपुट_ग्रुप=+foo,+bar, डिफ़ॉल्ट सेट, foo, और बार के यूनियन को बनाता है. वहीं, --return_groups=foo,bar की जगह डिफ़ॉल्ट सेट को इस तरह से ओवरराइड करता है, जैसे कि सिर्फ़ foo और बार.
टैग:execution
,affects_outputs
--[no]run_validations
डिफ़ॉल्ट: "सही"-
बिल्ड के हिस्से के तौर पर, पुष्टि करने से जुड़ी कार्रवाइयां चलाना है या नहीं. https://bazel.build/extending/rules#validation_actions
टैग देखें:execution
,affects_outputs
--[no]save_temps
डिफ़ॉल्ट: "false"-
अगर इस नीति को सेट किया जाता है, तो gcc से कुछ समय के लिए जनरेट होने वाले आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (पहले से प्रोसेस की गई C) और .ii फ़ाइलें (पहले से प्रोसेस की गई C++) शामिल हैं.
टैग:affects_outputs
- ऐसे विकल्प जो उपयोगकर्ता को सही आउटपुट को कॉन्फ़िगर करने देते हैं, उसकी वैल्यू पर असर होता है, जबकि इसकी वैल्यू पर असर नहीं पड़ता:
- ऐप्लिकेशन के
--action_env=<a 'name=value' assignment with an optional value part>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
टारगेट कॉन्फ़िगरेशन के साथ कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, वैल्यू को शुरू करने वाले एनवायरमेंट या नाम=वैल्यू के जोड़े से लिया जाएगा. इस पेयर की मदद से वैल्यू को, शुरू करने वाले एनवायरमेंट से अलग सेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत, अलग-अलग वैरिएबल के लिए उपलब्ध विकल्प.
टैग:action_command_lines
--android_cpu=<a string>
डिफ़ॉल्ट: "armeabi-v7a"-
Android टारगेट सीपीयू.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]android_databinding_use_androidx
डिफ़ॉल्ट: "false"-
AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]android_databinding_use_v3_4_args
डिफ़ॉल्ट: "false"-
3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--android_dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "बंद"-
यह तय करता है कि जब कोई cc_binary साफ़ तौर पर शेयर की गई लाइब्रेरी नहीं बनाता है, तो Android नियमों के C++ डेलिगेशन डाइनैमिक रूप से लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह चुनेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:affects_outputs
,loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>
डिफ़ॉल्ट: "वर्णमाला"-
Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्सक्लूट के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में, कॉन्फ़िगरेशन डायरेक्ट्री के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को हर लाइब्रेरी के मेनिफ़ेस्ट में क्रम से लगाया जाता है, जो उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आती है.
टैग:action_command_lines
,execution
--[no]android_resource_shrinking
डिफ़ॉल्ट: "false"-
यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को कम करने की सुविधा चालू करती है.
टैग:affects_outputs
,loading_and_analysis
- ऐप्लिकेशन के
--apple_bitcode=<'mode' or 'platform=mode', where 'mode' is none, embedded_markers or embedded, and 'platform' is ios, watchos, tvos, macos or catalyst>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
डिवाइस आर्किटेक्चर को टारगेट करने वाले कंपाइलेशन चरण के लिए, Apple बिटकोड मोड तय करें. वैल्यू, '[platform=]mode' फ़ॉर्म में हैं. इसमें प्लैटफ़ॉर्म वैकल्पिक है. जैसे, 'iOS', 'macos', 'tvos' या 'watchos'. अगर बिटकोड मोड दिया गया हो, तो खास तौर पर उस प्लैटफ़ॉर्म के लिए लागू किया जाता है. अगर इसे उपलब्ध नहीं कराया जाता है, तो यह सभी प्लैटफ़ॉर्म पर लागू होता है. मोड 'कोई नहीं', 'embed_markers' या 'एम्बेड किया गया' होना चाहिए. यह विकल्प कई बार दिया जा सकता है.
टैग:loses_incremental_state
- ऐप्लिकेशन के
--aspects=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - टॉप लेवल टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा-सेपरेटेड लिस्ट. सूची में, अगर sample some_aspect ज़रूरी आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) वाली कंपनियों के बारे में ज़रूरी जानकारी देता है, तो some_aspect हर पहलू के बाद चलेगा. इसके अलावा, some_aspect ज़रूरी एट्रिब्यूट के बताए गए सभी ज़रूरी पहलुओं के बाद ही काम करेगा. इसके बाद कुछ_aspect के पास, उन आसपेक्ट के प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, जैसे कि '//tools:my_def.bzl%my_aspect', जिसमें 'my_aspect', किसी फ़ाइल टूल/my_def.bzl से मिली टॉप-लेवल वैल्यू है
--[no]build_python_zip
डिफ़ॉल्ट: "ऑटो"-
Python के लिए एक्ज़ीक्यूटेबल ज़िप बनाएं. Windows के लिए और दूसरे प्लैटफ़ॉर्म पर बंद करें
टैग:affects_outputs
- ऐप्लिकेशन के
--catalyst_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple Catalyst बाइनरी बनाने हैं.
टैग:loses_incremental_state
,loading_and_analysis
--[no]collect_code_coverage
डिफ़ॉल्ट: "false"-
अगर बताया जाएगा, तो Bazel, इंस्ट्रुमेंट कोड (जहां संभव हो ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) करेगा और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ --instrumentation_filter से मेल खाने वाले टारगेट ही प्रभावित होंगे. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए - इसकी जगह, 'bazeloverlay' कमांड का इस्तेमाल किया जाना चाहिए.
टैग:affects_outputs
--compilation_mode=<fastbuild, dbg or opt>
[-c
] डिफ़ॉल्ट: "Fastbuild"-
वह मोड तय करें जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग:affects_outputs
,action_command_lines
,explicit_in_output_path
- ऐप्लिकेशन के
--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
,explicit_in_output_path
--cs_fdo_absolute_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करके, कंपाइलेशन ऑप्टिमाइज़ करें. उस ZIP फ़ाइल के पूरे पाथ का नाम बताएं जिसमें प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल मौजूद हो.
टैग:affects_outputs
--cs_fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंटेशन वाली बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान हटाया जाएगा.
टैग:affects_outputs
--cs_fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली कॉन्टेक्स्ट सेंसिटिव प्रोफ़ाइल को दिखाने वाली cs_fdo_profile.
टैग:affects_outputs
- ऐप्लिकेशन के
--cxxopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--define=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
हर --define का विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है.
टैग:changes_inputs
,affects_outputs
--dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
यह तय करता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह चुनेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:loading_and_analysis
,affects_outputs
--[no]enable_fdo_profile_absolute_path
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है, तो fdo_absolute_profile_path के इस्तेमाल पर गड़बड़ी हो सकती है.
टैग:affects_outputs
--[no]enable_runfiles
डिफ़ॉल्ट: "ऑटो"-
रनफ़ाइल सिमलिंक ट्री चालू करें. डिफ़ॉल्ट रूप से, यह Windows और दूसरे प्लैटफ़ॉर्म पर बंद होता है.
टैग:affects_outputs
- ऐप्लिकेशन के
--experimental_action_listener=<a build target label>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अलग-अलग पहलुओं के पक्ष में नहीं दिखाया गया. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग:execution
,experimental
--[no]experimental_android_compress_java_resources
डिफ़ॉल्ट: "false"-
APK में Java रिसॉर्स को कंप्रेस करें
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_android_databinding_v2
डिफ़ॉल्ट: "false"-
Android databinding v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_android_resource_shrinking
डिफ़ॉल्ट: "false"-
यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को कम करने की सुविधा चालू करती है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex
डिफ़ॉल्ट: "false"-
डेक्स फ़ाइलों को फिर से लिखने के लिए रेक्स टूल का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_convenience_symlinks
डिफ़ॉल्ट: "सामान्य"-
इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा सिमलिंक (बिल्ड के बाद फ़ाइल फ़ोल्डर में दिखने वाले सिमलिंक) को कैसे मैनेज किया जाएगा. संभावित वैल्यू:
सामान्य (डिफ़ॉल्ट): हर तरह के सुविधा सिमलिंक को बिल्ड के आधार पर बनाया या मिटाया जाएगा.
साफ़ करें: सभी सिमलिंक बिना किसी शर्त के हटा दिए जाएंगे.
ध्यान न दें: सिमलिंक अकेले छोड़े जाएंगे.
Log_only: लॉग मैसेज इस तरह जनरेट करें जैसे 'सामान्य' पास किए गए हों, लेकिन असल में कोई फ़ाइल सिस्टम कार्रवाई न करें (टूल के लिए उपयोगी).
ध्यान दें कि सिर्फ़ उन सिमलिंक के नाम पर असर पड़ सकता है जिनके नाम, --symlink_prefix के मौजूदा वैल्यू से जनरेट हुए हैं; अगर प्रीफ़िक्स में बदलाव होता है, तो पहले से मौजूद कोई भी सिमलिंक बाकी रह जाएंगे.
टैग:affects_outputs
--[no]experimental_convenience_symlinks_bep_event
डिफ़ॉल्ट: "false"-
इस फ़्लैग से यह कंट्रोल किया जाता है कि हम बिल्ड इवेंटसुविधाSymlinksIdentified को बिल्ड इवेंट प्रोटोकॉल में पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो BuildEventProtocol में सुविधाSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक शामिल होंगे. गलत होने पर, BuildEventProtocol में needSymlinksIdentified एंट्री के लिए, कोई वैल्यू नहीं दिखेगी.
टैग:affects_outputs
- ऐप्लिकेशन के
--experimental_multi_cpu=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अब सेवा में नहीं है. No-op.
टैग:affects_outputs
,experimental
--experimental_objc_fastbuild_options=<comma-separated list of options>
डिफ़ॉल्ट: "-O0,-DDEBUG=1"-
इन स्ट्रिंग का इस्तेमाल, objc फ़ास्ट बिल्ड कंपाइलर विकल्पों के तौर पर करता है.
टैग:action_command_lines
--[no]experimental_omitfp
डिफ़ॉल्ट: "false"-
अगर सही है, तो स्टैक अनवाइंड करने के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables की मदद से कंपाइल करें.
टैग:action_command_lines
,affects_outputs
,experimental
--[no]experimental_platform_in_output_dir
डिफ़ॉल्ट: "false"-
सही होने पर, टारगेट प्लैटफ़ॉर्म का इस्तेमाल सीपीयू के बजाय आउटपुट डायरेक्ट्री के नाम में किया जाता है.
टैग:affects_outputs
,experimental
--[no]experimental_use_llvm_covmap
डिफ़ॉल्ट: "false"-
अगर इसके बारे में बताया गया है, तो collections_code_coverage की सुविधा चालू होने पर Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
,experimental
--fat_apk_cpu=<comma-separated list of options>
डिफ़ॉल्ट: "armeabi-v7a"-
इस विकल्प को सेट करने पर, फ़ैट वाले ऐसे APKs चालू हो जाते हैं जिनमें तय किए गए सभी टारगेट आर्किटेक्चर के लिए नेटिव बाइनरी होती हैं. उदाहरण के लिए, --fat_apk_cpu=x86,armeabi-v7a. अगर इस फ़्लैग को तय किया गया है, तो android_binary नियमों की डिपेंडेंसी के लिए --android_cpu को अनदेखा किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]fat_apk_hwasan
डिफ़ॉल्ट: "false"-
HWASAN स्प्लिट बनाने हैं या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान हटाया जाएगा.
टैग:affects_outputs
--fdo_optimize=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कॉम्प्लेक्सेशन ऑप्टिमाइज़ करने के लिए एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री हो, कोई ऑटो प्रोफ़ाइल वाली afdo फ़ाइल हो या कोई LLVM प्रोफ़ाइल फ़ाइल दी गई हो. यह फ़्लैग उन फ़ाइलों को भी स्वीकार करता है जिन्हें लेबल के तौर पर बताया गया है (जैसे कि `//foo/bar:file.afdo` - आपको इससे जुड़े पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है. साथ ही, `fdo_profile` टारगेट को पॉइंट करने वाले लेबल भी लागू हो सकते हैं. इस फ़्लैग को `fdo_profile` नियम के तहत हटा दिया जाएगा.
टैग:affects_outputs
--fdo_prefetch_hints=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कैश मेमोरी प्रीफ़ेच संकेतों का इस्तेमाल करें.
टैग:affects_outputs
--fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल को दिखाने वाली fdo_profile.
टैग:affects_outputs
- ऐप्लिकेशन के
--features=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
ये सुविधाएं, सभी पैकेज के लिए डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> को लागू करने पर, यह सुविधा दुनिया भर में बंद हो जाएगी. नेगेटिव सुविधाएं, हमेशा पॉज़िटिव सुविधाओं को बदल देती हैं. इस फ़्लैग का इस्तेमाल, Bazel रिलीज़ के बिना, डिफ़ॉल्ट सुविधाओं में बदलावों को रोल आउट करने के लिए किया जाता है.
टैग:changes_inputs
,affects_outputs
--[no]force_pic
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") देते हैं. लिंक, बिना पीआईसी लाइब्रेरी के बजाय, पीआईसी में पहले से बनी लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक पोज़िशन पर निर्भर एक्ज़िक्यूटेबल ("-पाई") बनाते हैं.
टैग:loading_and_analysis
,affects_outputs
- ऐप्लिकेशन के
--host_action_env=<a 'name=value' assignment with an optional value part>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट या एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, वैल्यू को शुरू करने वाले एनवायरमेंट या नाम=वैल्यू के जोड़े से लिया जाएगा. इस पेयर की मदद से वैल्यू को, शुरू करने वाले एनवायरमेंट से अलग सेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत, अलग-अलग वैरिएबल के लिए उपलब्ध विकल्प.
टैग:action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt>
डिफ़ॉल्ट: "ऑप्ट"-
उस मोड के बारे में बताएं जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल का इस्तेमाल किया जाएगा. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग:affects_outputs
,action_command_lines
- ऐप्लिकेशन के
--host_conlyopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--host_copt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए जीसीसी को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_cpu=<a string>
डिफ़ॉल्ट: ""-
होस्ट के लिए सीपीयू.
टैग:changes_inputs
,affects_outputs
- ऐप्लिकेशन के
--host_cxxopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए जीसीसी को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_force_python=<PY2 or PY3>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट कॉन्फ़िगरेशन के लिए 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 भी देखें. यह विकल्प_1 से Option_n का मतलब, आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, बार.cc को छोड़कर //foo/ में सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--host_swiftcopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए, swiftc को पास करने के ज़्यादा विकल्प.
टैग:action_command_lines
,affects_outputs
--[no]incompatible_avoid_conflict_dlls
डिफ़ॉल्ट: "सही"-
इस सेटिंग को चालू करने पर, Windows पर cc_library से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (डीएलएल) का नाम बदलकर name_{hash}.dll कर दिया जाएगा. यहां हैश का हिसाब RepositoryName और DLL के पैकेज पाथ के आधार पर लगाया जाता है. यह विकल्प तब फ़ायदेमंद होता है, जब आपके पास एक ऐसा पैकेज हो जो एक ही नाम वाली कई cc_library पर निर्भर करता हो (जैसे कि //foo/bar1:utils और //foo/bar2:utils).
टैग:loading_and_analysis
,affects_outputs
,incompatible_change
--[no]incompatible_merge_genfiles_directory
डिफ़ॉल्ट: "सही"-
सही होने पर, जनरेट फ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_use_platforms_repo_for_constraints
डिफ़ॉल्ट: "सही"-
सही होने पर, @bazel_tools की कंस्ट्रेंट सेटिंग हटा दी जाती हैं.
टैग:affects_outputs
,incompatible_change
--[no]instrument_test_targets
डिफ़ॉल्ट: "false"-
कवरेज चालू होने पर, यह तय किया जाता है कि टेस्ट के नियमों को ध्यान में रखना है या नहीं. सेट किए जाने पर, --instrumentation_filter में शामिल किए गए टेस्ट के नियम लागू होते हैं. नहीं तो, जांच के नियमों को कवरेज इंस्ट्रुमेंटेशन से हमेशा बाहर रखा जाता है.
टैग:affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-/javatest[/:],-/test/java[/:]"-
कवरेज चालू होने पर, सिर्फ़ वही नियम लागू किए जाएंगे जिनके नाम, रेगुलर एक्सप्रेशन पर आधारित फ़िल्टर के ज़रिए शामिल किए गए हों. इसके बजाय, '-' से शुरू वाले नियमों को शामिल नहीं किया जाता. ध्यान रखें कि जब तक --instrument_test_targets को चालू नहीं किया जाता, तब तक सिर्फ़ गैर-टेस्ट नियम लागू किए जाते हैं.
टैग:affects_outputs
--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाला iOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'ios_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
- ऐप्लिकेशन के
--ios_multi_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
iOS_application बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें सभी तय आर्किटेक्चर शामिल हैं.
टैग:loses_incremental_state
,loading_and_analysis
--[no]legacy_whole_archive
डिफ़ॉल्ट: "सही"-
अब काम नहीं करता, इसकी जगह --insupported_remove_Legacy_whole_archive (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7362 देखें). इस सेटिंग के चालू होने पर, cc_binary के उन नियमों के लिए --whole-archive का इस्तेमाल करें जिनमें linkshared=True शामिल है. साथ ही, linkopts में linkstatic=True या '-static' का इस्तेमाल किया जाता है. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. जहां ज़रूरी हो, वहां क्लिक के लिए हमेशा लिंक=1 का इस्तेमाल करें. यह एक अच्छा विकल्प है.
टैग:action_command_lines
,affects_outputs
,deprecated
- ऐप्लिकेशन के
--linkopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--ltobackendopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
एलटीओ बैकएंड चरण को पास करने का अन्य विकल्प (--features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--ltoindexopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
एलटीओ इंडेक्स करने के चरण को पास करने का अन्य विकल्प (-features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--macos_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Apple macOS की बाइनरी बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट.
टैग:loses_incremental_state
,loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट के लिए, कम से कम काम करने वाले macOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--[no]objc_debug_with_GLIBCXX
डिफ़ॉल्ट: "false"-
अगर यह सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को परिभाषित करें.
टैग:action_command_lines
--[no]objc_enable_binary_stripping
डिफ़ॉल्ट: "false"-
लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिप करना है या नहीं. अगर यह फ़्लैग और --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 भी देखें. यह विकल्प_1 से Option_n का मतलब, आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ बार.cc को छोड़कर सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड (--features=thin_lto के तहत) को अपनी पसंद के हिसाब से पास करने के ज़्यादा विकल्प. इस विकल्प को कई बार इस्तेमाल किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल करने और रेगुलर एक्सप्रेशन पैटर्न को शामिल करने की सूची से है. इसके अलावा, Option_1 से Option_n विकल्प का मतलब आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0 //foo/ को छोड़कर bar.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>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, प्रोपेलर प्रोफ़ाइल की जानकारी का इस्तेमाल करें.प्रोपेलर प्रोफ़ाइल में दो फ़ाइलों में से कम से कम एक फ़ाइल, cc प्रोफ़ाइल और ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल स्वीकार करता है, जो प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, लेबल को परिभाषित करने वाली BUILD फ़ाइल जो कि लेबल को परिभाषित करती है, a/b/BUILD:खरीददारी_ऑप्टिमाइज़( name = " सेटिंग्स_profile", cc_profile = " रूपरेखा_cc_profile.txt", ld_profile = " सेटिंग्स_ld_profile.txt",) एनजीएल फ़ाइल्स निर्देश को संबंधित पैकेज में जोड़ना पड़ सकता है, ताकि ये फ़ाइलें Bazel को दिख सकें. विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --propler_optimize=//a/b:PROpelलर_profile
टैग:action_command_lines
,affects_outputs
--propeller_optimize_absolute_cc_profile=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Propiller ऑप्टिमाइज़ किए गए बिल्ड के लिए 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
-
सही होने पर, एक जैसी काम करने वाली नेटिव लाइब्रेरी अलग-अलग टारगेट के बीच शेयर की जाएंगी
टैग:loading_and_analysis
,affects_outputs
--[no]stamp
डिफ़ॉल्ट: "false"-
स्टैंप बाइनरी जिनमें तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह शामिल है.
टैग:affects_outputs
--strip=<always, sometimes or never>
डिफ़ॉल्ट: "कभी-कभी"-
यह तय करता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं ("-Wl,--strip-debug" का इस्तेमाल करके). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब है कि स्ट्रिप iff --compilation_mode=Fastbuild.
टैग:affects_outputs
- ऐप्लिकेशन के
--stripopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - '<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--swiftcopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
स्विफ़्ट कंपाइलेशन में भेजने के ज़्यादा विकल्प.
टैग:action_command_lines
--symlink_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह प्रीफ़िक्स, बिल्ड के बाद बनाए जाने वाले किसी भी सुविधा सिमलिंक से पहले जोड़ा जाता है. अगर इसे छोड़ा जाता है, तो डिफ़ॉल्ट वैल्यू, बिल्ड टूल के नाम के बाद हाइफ़न के बाद मौजूद होती है. अगर '/' पास हो जाता है, तो कोई सिमलिंक नहीं बनाए जाते और कोई चेतावनी नहीं भेजी जाती. चेतावनी: '/' के लिए उपलब्ध खास फ़ंक्शन को जल्द ही बंद कर दिया जाएगा. इसके बजाय, --experimental_convenience_symlinks=ignore का इस्तेमाल करें.
टैग:affects_outputs
- ऐप्लिकेशन के
--tvos_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Apple tvOS की बाइनरी बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट.
टैग:loses_incremental_state
,loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाला tvOS वर्शन. अगर इसकी जानकारी नहीं दी गई है, तो 'tvos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
- ऐप्लिकेशन के
--watchos_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनानी हैं.
टैग:loses_incremental_state
,loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाले WatchOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'watchos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--xbinary_fdo=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपलेशन ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile/ के साथ किया जाता है, तब ये विकल्प हमेशा लागू होते हैं, जैसे कि xbinary_fdo के बारे में कभी जानकारी न दी गई हो.
टैग:affects_outputs
- Bzel के मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--auto_cpu_environment_group=<a build target label>
डिफ़ॉल्ट: ""-
Environment_group का एलान करें, ताकि target_environment वैल्यू के लिए सीपीयू वैल्यू को अपने-आप मैप करने के लिए, उसका इस्तेमाल किया जा सके.
टैग:changes_inputs
,loading_and_analysis
,experimental
--[no]check_licenses
डिफ़ॉल्ट: "false"-
जांचें कि डिपेंडेंट पैकेज की तय की गई लाइसेंस से जुड़ी सीमाएं, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर न डालें. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: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
डिफ़ॉल्ट: "false"-
लेगसी डिवाइसों के लिए, ऐप्लिकेशन में Java 8 लाइब्रेरी शामिल करनी है या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]enforce_constraints
डिफ़ॉल्ट: "सही"-
यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर कोई टारगेट ऐसी डिपेंडेंसी है जो एक जैसे एनवायरमेंट के साथ काम नहीं करती, तो गड़बड़ियों की रिपोर्ट करता है
टैग:build_file_semantics
--[no]experimental_allow_android_library_deps_without_srcs
डिफ़ॉल्ट: "false"-
deps के साथ srcs-less android_library नियमों को अस्वीकार करने की अनुमति देने से ट्रांज़िशन में मदद करने के लिए फ़्लैग करें. डिफ़ॉल्ट रूप से इसे रोल आउट करने के लिए डिपो को साफ़ करना ज़रूरी है.
टैग:eagerness_to_exit
,loading_and_analysis
--[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
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, आउटपुट फ़ाइल वाले ज़रूरी टारगेट के लिए सिर्फ़ testonly चुनें. इसके लिए, सिर्फ़ जनरेट करने वाले नियम का टेस्ट देखें. यह 'किसको दिखे' सेटिंग से मेल खाता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disable_native_android_rules
डिफ़ॉल्ट: "false"-
चालू होने पर, Android के मूल नियमों का सीधे इस्तेमाल करने की सुविधा बंद हो जाती है. कृपया https://github.com/bazelbuild/मॉडल_android से Starlark Android के नियमों का इस्तेमाल करें
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_disable_native_apple_binary_rule
डिफ़ॉल्ट: "false"-
पुराने सिस्टम के साथ काम करने की सुविधा के लिए, इसे यहां रखा गया है.
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_force_strict_header_check_from_starlark
डिफ़ॉल्ट: "सही"-
अगर चालू है, तो Starlark API में हेडर की सख्त जांच सेट करें
टैग:loading_and_analysis
,changes_inputs
,incompatible_change
--[no]incompatible_validate_top_level_header_inclusions
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, टॉप लेवल डायरेक्ट्री के हेडर शामिल करने की भी पुष्टि करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]strict_filesets
डिफ़ॉल्ट: "false"-
अगर यह विकल्प चालू किया जाता है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है. यह Check_fileset_dependencies_recursively को बंद करने पर काम नहीं करता है.
टैग: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
डिफ़ॉल्ट: "false"-
अगर सही है, तो सिस्टम से मिलने वाले हेडर में पाथ (-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 भाषा के सिमैंटिक या उस बिल्ड एपीआई को इस्तेमाल करने पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "false"-
अगर sensitive_enforce_config_setting_ पहचानने के लिए गलत वैल्यू है, तो यह नॉप है. ऐसा न होने पर, अगर यह फ़्लैग गलत है, तो बिना किसी खास 'किसको दिखे' एट्रिब्यूट के बिना कोई भी config_setting //visible:public पर सेट कर दे. अगर यह फ़्लैग सही है, तो config_setting, दिखने के उसी लॉजिक का पालन करेगी जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_disallow_legacy_py_provider
डिफ़ॉल्ट: "सही"-
नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:
--[no]allow_analysis_failures
डिफ़ॉल्ट: "false"-
सही होने पर, टारगेट किए गए किसी नियम का विश्लेषण नहीं हो पाता है. ऐसा होने पर, टारगेट के तहत किसी ऐसी स्थिति का विश्लेषण हो जाता है जिसमें गड़बड़ी की जानकारी होती है. इस वजह से, बिल्ड फ़ेल हो जाता है.
टैग:loading_and_analysis
,experimental
--analysis_testing_deps_limit=<an integer>
डिफ़ॉल्ट: "2000"-
for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट की मदद से, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा को पार करने से नियम में गड़बड़ी होगी.
टैग:loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure
डिफ़ॉल्ट: "false"-
अगर सही dex2oat कार्रवाई पूरी नहीं हो पाती है, तो टेस्ट रनटाइम के दौरान dex2oat को चलाने के बजाय बिल्ड टूट जाएगा.
टैग:loading_and_analysis
,experimental
--[no]check_tests_up_to_date
डिफ़ॉल्ट: "false"-
टेस्ट न करें. बस यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर सभी जांच के नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर किसी टेस्ट को बनाने या उसे एक्ज़ीक्यूट करने की ज़रूरत पड़ती है, तो गड़बड़ी की शिकायत की जाती है और जांच नहीं हो पाती. यह विकल्प --check_up_to_date व्यवहार लागू करता है.
टैग:execution
--[no]experimental_android_use_parallel_dex2oat
डिफ़ॉल्ट: "false"-
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>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
किसी भी तरह की जांच फ़ेल होने पर, हर जांच को उसकी बताई गई संख्या तक फिर से करने की कोशिश की जाएगी. जिन परीक्षाओं को एक से ज़्यादा बार पास करने की ज़रूरत पड़ती है उन्हें जांच की खास जानकारी में 'FLAKY' के तौर पर मार्क किया जाता है. आम तौर पर, वैल्यू के तौर पर सिर्फ़ एक पूर्णांक या 'डिफ़ॉल्ट' स्ट्रिंग की जाती है. अगर पूर्णांक शामिल है, तो सभी टेस्ट N बार तक चलाए जाएंगे. अगर यह 'डिफ़ॉल्ट' है, तो सामान्य जांच के लिए सिर्फ़ एक बार जांच करने की कोशिश की जाएगी. साथ ही, उन जांचों के लिए तीन कोशिश की जाएगी जिन्हें उनके नियम (फ़्लेकी=1 एट्रिब्यूट) के हिसाब से, पूरी तरह से फ़्लैकी के तौर पर मार्क किया गया है. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. जहां flaky_test_attempts यह ऊपर है और regex_filter का मतलब है, रेगुलर एक्सप्रेशन पैटर्न को शामिल और बाहर करना. साथ ही, --runs_per_test भी देखें. उदाहरण: --flaky_test_attempts=//foo/.*,-//foo/bar/.*@3, //foo/ में सभी टेस्ट को तीन बार डीफ़्लेक्स करता है. इस विकल्प को कई बार इस्तेमाल किया जा सकता है. मेल खाने वाले सबसे हाल ही में पास किए गए तर्क को प्राथमिकता दी जाती है. अगर कुछ भी मैच नहीं करता है, तो व्यवहार ऊपर 'डिफ़ॉल्ट' के रूप में होता है.
टैग:execution
--[no]ios_memleaks
डिफ़ॉल्ट: "false"-
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") का इस्तेमाल करता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<flow>) होती है. "auto", "Host_CPUS*.5". 0 का मतलब है कि लोकल संसाधन, लोकल टेस्ट जॉब की संख्या को एक साथ चलाने के लिए सीमित कर देंगे. इसे --jobs के लिए मान से ज़्यादा पर सेट करने का असर नहीं पड़ता.
टैग:execution
- ऐप्लिकेशन के
--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - यह बताता है कि हर जांच को कितनी बार चलाना है. अगर इनमें से कोई भी कोशिश किसी वजह से पूरी नहीं हो पाती है, तो पूरी जांच को फ़ेल माना जाता है. आम तौर पर, डाली गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 सभी टेस्ट तीन बार चलाएगा. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. जहां 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>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में जानकारी देता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू को Bazel क्लाइंट एनवायरमेंट या name=value पेयर से पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
टैग:test_runner
--[no]test_keep_going
डिफ़ॉल्ट: "सही"-
बंद होने पर, कोई भी टेस्ट पास नहीं होने पर पूरा बिल्ड रुक जाएगा. डिफ़ॉल्ट रूप से सभी टेस्ट चलाए जाते हैं, भले ही कुछ टेस्ट पास न हो पाएं.
टैग:execution
--test_strategy=<a string>
डिफ़ॉल्ट: ""-
यह बताता है कि टेस्ट करने के लिए किस रणनीति का इस्तेमाल करना है.
टैग:execution
--test_timeout=<a single integer or comma-separated list of 4 integers>
डिफ़ॉल्ट: "-1"- जांच के टाइम आउट होने के समय की डिफ़ॉल्ट वैल्यू को बदलें (सेकंड में). अगर एक पॉज़िटिव पूर्णांक मान दिया गया है, तो वह सभी कैटगरी को बदल देगा. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, मध्यम, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. किसी भी रूप में, -1 की वैल्यू ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने का निर्देश देती है.
--test_tmpdir=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- 'bazel टेस्ट' के इस्तेमाल के लिए, बेस अस्थायी डायरेक्ट्री के बारे में बताता है.
--tvos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में किसी tvOS ऐप्लिकेशन को चलाते समय, सिम्युलेट करने वाला डिवाइस, जैसे कि 'Apple TV 1080p'. जिस मशीन पर सिम्युलेटर चलाया जाएगा उस पर 'xcrun SIMctl list devicetypes' चलाकर आप डिवाइस की एक सूची पा सकते हैं.
टैग:test_runner
--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
चलाते या टेस्ट करते समय, सिम्युलेटर पर चलने वाला tvOS का वर्शन.
टैग:test_runner
--watchos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में WatchOS ऐप्लिकेशन चलाते समय सिम्युलेट किया जाने वाला डिवाइस, जैसे कि 'Apple Watch - 38mm'. जिस मशीन पर सिम्युलेटर चलाया जाएगा उस पर 'xcrun SIMctl list devicetypes' चलाकर आप डिवाइस की एक सूची पा सकते हैं.
टैग:test_runner
--watchos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
दौड़ने या टेस्ट करने के दौरान, सिम्युलेटर पर चलने के लिए WatchOS का वर्शन.
टैग:test_runner
--[no]zip_undeclared_test_outputs
डिफ़ॉल्ट: "सही"-
अगर सही है, तो नहीं बताए गए टेस्ट आउटपुट ZIP फ़ाइल में संग्रहित किए जाएंगे.
टैग:test_runner
- बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प:
--[no]collapse_duplicate_defines
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, गैर-ज़रूरी --परिभाषाओं को बिल्ड की शुरुआत में ही हटा दिया जाएगा. इससे कुछ खास तरह के मिलते-जुलते बिल्ड के लिए, विश्लेषण की कैश मेमोरी को होने वाले नुकसान से बचा जा सकता है.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_filter_library_jar_with_program_jar
डिफ़ॉल्ट: "false"-
LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए ProGuard ProgramJar को फ़िल्टर करें.
टैग:action_command_lines
--[no]experimental_inmemory_dotd_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, C++ .d फ़ाइलों को मेमोरी में, डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से पास किया जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_inmemory_jdeps_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_objc_include_scanning
डिफ़ॉल्ट: "false"-
मकसद C/C++ के लिए स्कैन करना है या नहीं.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]experimental_parse_headers_skipped_if_corresponding_srcs_found
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, अगर एक ही टारगेट में एक जैसे बेसनेम वाला सोर्स मिलता है, तो parse_headers सुविधा अलग से हेडर कंपाइलेशन ऐक्शन नहीं बनाती.
टैग:loading_and_analysis
,affects_outputs
--[no]experimental_retain_test_configuration_across_testonly
डिफ़ॉल्ट: "false"-
चालू होने पर, --trim_test_ Configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए, टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़े विवाद से जुड़ी समस्याओं को कम करना है. ऐसा तब किया जाता है, जब जांच न करने वाले नियम cc_test पर निर्भर होते हैं. --trim_test_Configuration गलत होने पर कोई असर नहीं होगा.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_starlark_cc_import
डिफ़ॉल्ट: "false"-
अगर चालू हो, तो cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग:loading_and_analysis
,experimental
--[no]experimental_unsupported_and_brittle_include_scanning
डिफ़ॉल्ट: "false"-
इनपुट फ़ाइलों से #include पंक्तियों को पार्स करके, C/C++ कंपाइलेशन में इनपुट को सीमित करना है या नहीं. यह कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और बढ़ोतरी को बेहतर बना सकता है. हालांकि, इससे बिल्ड खराब भी हो सकते हैं, क्योंकि शामिल स्कैनर, C प्रीप्रोसेसर सिमैंटिक को पूरी तरह लागू नहीं करता. खास तौर पर, यह डाइनैमिक #इन्क्लूसिव निर्देशों को नहीं समझता और प्रीप्रोसेसर कंडिशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी जो भी समस्याएं फ़ाइल की जाती हैं वे बंद हो जाएंगी.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]incremental_dexing
डिफ़ॉल्ट: "सही"-
क्या हर Jar फ़ाइल के लिए, ज़्यादातर काम अलग-अलग तरीके से किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]objc_use_dotd_pruning
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है, तो clang से उत्सर्जित होने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइलेशन में पास किए गए इनपुट के सेट को हटाने के लिए किया जाएगा.
टैग:changes_inputs
,loading_and_analysis
--[no]process_headers_in_dependencies
डिफ़ॉल्ट: "false"-
टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग:execution
--[no]trim_test_configuration
डिफ़ॉल्ट: "सही"-
चालू होने पर, जांच से जुड़े विकल्प, बिल्ड के टॉप लेवल से नीचे हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, गैर-टेस्टिंग नियमों का फिर से विश्लेषण नहीं होगा.
टैग:loading_and_analysis
,loses_incremental_state
--[no]use_singlejar_apkbuilder
डिफ़ॉल्ट: "सही"-
इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. अब इस पर कोई कार्रवाई नहीं की जा सकती. इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
- ऐसे विकल्प जो जानकारी डालने की जगह, फ़ॉर्मैट या जगह की जानकारी पर असर डालते हैं:
--[no]announce
डिफ़ॉल्ट: "false"-
अब सेवा में नहीं है. No-op.
टैग:affects_outputs
--[no]experimental_bep_target_summary
डिफ़ॉल्ट: "false"- Targetsummary इवेंट को पब्लिश करना है या नहीं.
--[no]experimental_build_event_expand_filesets
डिफ़ॉल्ट: "false"-
अगर सही हो, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, BEP में फ़ाइलसेट को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "false"-
अगर सही है, तो आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी में मिलते-जुलते फ़ाइलसेट सिमलिंक को पूरी तरह ठीक करें. --experimental_build_event_expand_filesets की ज़रूरत है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
Bzel को बिल्ड इवेंट को ज़्यादा से ज़्यादा कितनी बार अपलोड करने की कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
डिफ़ॉल्ट: "1s"-
शुरू में, बीईपी अपलोड न होने पर, एक्सपोनेन्शियल बैकऑफ़ फिर से होने में कम से कम देरी. (exponent: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
चुनें कि बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को कैसे अपलोड करें.
टैग:affects_outputs
--[no]experimental_materialize_param_files_directly
डिफ़ॉल्ट: "false"-
अगर पैरामीटर फ़ाइलों को मटेरियलाइज़ किया जा रहा है, तो डिस्क पर सीधे लिखने की सुविधा का इस्तेमाल करके ऐसा करें.
टैग:execution
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "false"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग:affects_outputs
--explain=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
इसकी वजह, बिल्ड सिस्टम को लागू किए गए हर चरण के बारे में बताती है. इसकी वजह, बताई गई लॉग फ़ाइल में होती है.
टैग:affects_outputs
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
TargetComplete इवेंट में, लेगसी key_OUTs फ़ील्ड को जनरेट होने की प्रोसेस को रोकने के लिए इसका इस्तेमाल करें. Bazel और resultsStore इंटिग्रेशन के लिए, आने वाले ज़रूरी टूल ज़रूरी हैं.
टैग:affects_outputs
--[no]materialize_param_files
डिफ़ॉल्ट: "false"-
रिमोट ऐक्शन एक्ज़ीक्यूशन का इस्तेमाल करने पर भी, आउटपुट ट्री में इंटरमीडिएट पैरामीटर फ़ाइलें सेव करता है. कार्रवाइयों को डीबग करते समय काम आता है. यह --subcommands और --verbose_failures
टैग:execution
--max_config_changes_to_show=<an integer>
डिफ़ॉल्ट: "3"-
बिल्ड के विकल्पों में बदलाव की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नामों की दी गई संख्या दिखती है. अगर दी गई संख्या -1 है, तो सभी बदले गए विकल्प दिखाए जाएंगे.
टैग:terminal_output
--max_test_output_bytes=<an integer>
डिफ़ॉल्ट: "-1"-
हर जांच के लिए, ज़्यादा से ज़्यादा साइज़ के बारे में जानकारी देता है. ऐसा तब होता है, जब --test_OUT 'गड़बड़ी' या 'सभी' हो. बहुत ज़्यादा शोर वाले टेस्ट आउटपुट के आउटपुट को खराब होने से बचाने के लिए इसका इस्तेमाल किया जाता है. टेस्ट हेडर, लॉग साइज़ में शामिल होता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट में कुछ भी नहीं है या कुछ भी नहीं है.
टैग:test_runner
,terminal_output
,execution
--output_filter=<a valid Java regular expression>
डिफ़ॉल्ट: ब्यौरा देखें-
सिर्फ़ दिए गए रेगुलर एक्सप्रेशन से मेल खाने वाले नाम वाले नियमों के लिए चेतावनियां दिखाता है.
टैग:affects_outputs
--progress_report_interval=<an integer in 0-3600 range>
डिफ़ॉल्ट: "0"-
जो जॉब अब भी चल रही हैं उनकी रिपोर्ट के बीच में सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, हर मिनट में एक बार रिपोर्ट की प्रोग्रेस रिपोर्ट की जाएगी. --curses चालू होने पर, प्रोग्रेस की रिपोर्ट हर सेकंड दी जाती है.
टैग:affects_outputs
--show_result=<an integer>
डिफ़ॉल्ट: "1"-
बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए, यह बताएं कि उसे अप-टू-डेट किया गया है या नहीं. अगर हां, तो उन आउटपुट फ़ाइलों की सूची बनाएं जो बनाई गई थीं. प्रिंट की गई फ़ाइलें एक सुविधाजनक स्ट्रिंग होती हैं, जिसकी मदद से उन्हें कॉपी करके शेल पर चिपकाया जा सकता है. साथ ही, उन्हें एक्ज़ीक्यूट किया जा सकता है.
इस विकल्प के लिए एक पूर्णांक तर्क की ज़रूरत होती है. यह उन लक्ष्यों की थ्रेशोल्ड संख्या होती है जिनसे ऊपर की नतीजे की जानकारी प्रिंट नहीं की जाती. इस तरह, शून्य मैसेज दिखने से रोकता है और MAX_INT की वजह से नतीजे को प्रिंट करने की प्रोसेस हमेशा होती है. डिफ़ॉल्ट वैल्यू एक होती है.
टैग:affects_outputs
--[no]subcommands
[-s
] डिफ़ॉल्ट: "false"-
बिल्ड के दौरान लागू किए गए सबकमांड दिखाना. मिलते-जुलते फ़्लैग: --execution_log_json_file, --execution_log_binary_file (टूल-फ़्रेंडली फ़ॉर्मैट में, फ़ाइल में सबकमांड को लॉग करने के लिए).
टैग:terminal_output
--test_output=<summary, errors, all or streamed>
की डिफ़ॉल्ट सेटिंग: "खास जानकारी"-
पसंदीदा आउटपुट मोड के बारे में बताता है. मान्य वैल्यू, सिर्फ़ जांच के स्टेटस की खास जानकारी के लिए 'खास जानकारी' होती हैं. 'गड़बड़ियां', फ़ेल हो चुके टेस्ट के लिए टेस्ट लॉग प्रिंट करने के लिए, सभी जांच के लिए 'सभी' लॉग प्रिंट करने के लिए, और रीयल टाइम में सभी जांच के लिए 'स्ट्रीम किए गए' लॉग के लिए 'खास जानकारी' होती हैं. इससे --test_strategy वैल्यू पर ध्यान दिए बिना, एक बार में एक स्थानीय जांच लागू होगी.
टैग:test_runner
,terminal_output
,execution
--test_summary=<short, terse, detailed, none or testcase>
डिफ़ॉल्ट: "छोटा"-
टेस्ट की खास जानकारी का सही फ़ॉर्मैट बताता है. मान्य वैल्यू, सिर्फ़ किए गए जांच के बारे में जानकारी प्रिंट करने के लिए 'छोटा', 'सामान्य' होते हैं, सिर्फ़ असफल जांचों की जानकारी प्रिंट करने के लिए, 'सामान्य' होते हैं, फ़ेल हुए टेस्ट केस की पूरी जानकारी प्रिंट करने के लिए 'जानकारी', टेस्ट केस के रिज़ॉल्यूशन में खास जानकारी प्रिंट करने के लिए 'टेस्टकेस', फ़ेल हुए टेस्ट केस की पूरी जानकारी प्रिंट न करें, और खास जानकारी को हटाने के लिए 'कोई नहीं' प्रिंट न करें.
टैग:terminal_output
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-.*"-
टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. फ़्लैग, रेगुलर एक्सप्रेशन को इस्तेमाल करता है. इसकी जांच टूलचेन टाइप और चुनिंदा टारगेट से की जाती है, ताकि यह पता लगाया जा सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल है और हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन में माहिर विशेषज्ञों के लिए ही काम का हो.
टैग:terminal_output
--[no]verbose_explanations
डिफ़ॉल्ट: "false"-
अगर --एक्सप्लेनेशंस चालू है, तो यह विकल्प, जानकारी को ज़्यादा शब्दों में दिखाता है. अगर --एक्सप्लेनेशंस को चालू नहीं किया जाता है, तो इसका कोई असर नहीं होता.
टैग:affects_outputs
--[no]verbose_failures
डिफ़ॉल्ट: "false"-
अगर कोई निर्देश काम नहीं करता, तो पूरी कमांड लाइन प्रिंट कर लें.
टैग:terminal_output
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
- ऐप्लिकेशन के
--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
डिफ़ॉल्ट: "false"-
यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बने. आम तौर पर, जब किसी py_binary या py_test टारगेट मेंLegacy_create_init "अपने आप" (डिफ़ॉल्ट) पर सेट होती है, तो इस फ़्लैग के सेट होने पर ही गलत माना जाता है. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py2_outputs_are_suffixed
डिफ़ॉल्ट: "सही"-
अगर सही होता है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट आउटपुट रूट में दिखेंगे, जिसमें सफ़िक्स '-py2' होगा, जबकि Python 3 के लिए बनाए गए टारगेट रूट में दिखेंगे और Python से जुड़े सफ़िक्स के नहीं होंगे. इसका मतलब है कि `bazel-bin` सुविधा वाला सिमलिंक, Python 2 के बजाय Python 3 टारगेट को पॉइंट करेगा. अगर इस विकल्प को चालू किया जाता है, तो `--insupported_py3_is_default` को चालू करने का भी सुझाव दिया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py3_is_default
डिफ़ॉल्ट: "सही"-
सही होने पर, `py_binary` और `py_test` टारगेट जो अपना `python_version` (या `default_python_version`) सेट नहीं करते, तो वे डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. अगर इस फ़्लैग को सेट किया जाता है, तो आपको `--insupported_py2_OUTs_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
,explicit_in_output_path
--target_pattern_file=<a string>
डिफ़ॉल्ट: ""-
अगर सेट किया जाता है, तो बिल्ड कमांड लाइन के बजाय, यहां दी गई फ़ाइल के पैटर्न को पढ़ेगा. यहां फ़ाइल और कमांड लाइन पैटर्न के बारे में बताना एक गड़बड़ी है.
टैग:changes_inputs
- अलग-अलग विकल्प, जिन्हें किसी दूसरी कैटगरी में नहीं रखा जाता.:
--[no]build_manual_tests
डिफ़ॉल्ट: "false"- 'मैन्युअल' टैग किए गए टेस्ट टारगेट को बनाने के लिए बाध्य करता है. 'मैन्युअल' जांच को प्रोसेस नहीं किया जाता. यह विकल्प उन्हें हर हाल में बनाने के लिए मजबूर करता है, लेकिन उसे एक्ज़ीक्यूट नहीं करता.
--build_tag_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- टैग की कॉमा-सेपरेटेड लिस्ट के बारे में बताता है. बाहर रखे गए टैग के बारे में बताने के लिए, हर टैग से पहले वैकल्पिक रूप से '-' लगाया जा सकता है. केवल वे लक्ष्य बनाए जाएंगे, जिनमें कम से कम एक शामिल किया गया टैग होगा और कोई भी बहिष्कृत टैग शामिल नहीं होगा. यह विकल्प, 'test' कमांड से लागू किए गए टेस्ट के सेट पर असर नहीं डालता. इन्हें, जांच के लिए फ़िल्टर करने के विकल्पों से कंट्रोल किया जाता है, जैसे कि '--test_tag_filters'
--[no]build_tests_only
डिफ़ॉल्ट: "false"- अगर कहा गया है, तो सिर्फ़ *_test और test_suite के नियम बनाए जाएंगे. साथ ही, कमांड लाइन पर तय किए गए दूसरे टारगेट को अनदेखा कर दिया जाएगा. डिफ़ॉल्ट रूप से, अनुरोध की गई सभी चीज़ें बनाई जाएंगी.
--[no]cache_test_results
[-t
] डिफ़ॉल्ट: "ऑटो"- अगर स्थिति को 'अपने-आप' पर सेट किया जाता है, तो Bazel फिर से जांच तब करता है, जब: (1) Bazel को जांच में हुए बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया जाता है, (3) --runs_per_test की मदद से कई टेस्ट चलाने का अनुरोध किया जाता है या(4) जांच पहले असफल हो जाती है. अगर इस नीति को 'हां' पर सेट किया जाता है, तो बाहरी के तौर पर मार्क किए गए टेस्ट के अलावा, Bazel जांच के सभी नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी जांच के नतीजे को कैश मेमोरी में सेव नहीं करेगा.
--[no]compile_one_dependency
डिफ़ॉल्ट: "false"- आर्ग्यूमेंट फ़ाइलों की एक डिपेंडेंसी कंपाइल करें. यह आईडीई में सोर्स फ़ाइलों के सिंटैक्स की जांच करने के लिए फ़ायदेमंद है. उदाहरण के लिए, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाने के लिए, सोर्स फ़ाइल पर निर्भर किसी एक टारगेट को फिर से बनाकर. यह तर्क, सभी बिना फ़्लैग वाले तर्कों की व्याख्या करने के तरीके पर असर डालता है. इसे बनाने के लिए टारगेट न किए जाने वाले तर्क, सोर्स फ़ाइल नाम होते हैं. हर सोर्स फ़ाइल के नाम के लिए, उस पर निर्भर एक आर्बिट्रेरी टारगेट बनाया जाएगा.
--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
डिफ़ॉल्ट: "false"- विश्लेषण का चरण पूरा होने के तुरंत बाद, विश्लेषण की कैश मेमोरी को खारिज कर दें. इससे मेमोरी के इस्तेमाल को ~10% तक कम किया जाता है. हालांकि, इससे ऐप्लिकेशन के इंस्टॉल होने की रफ़्तार कम हो जाती है.
--execution_log_binary_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- इस फ़ाइल में लागू किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, डीलिमिटेड स्पॉन प्रोटो के तौर पर लॉग करें. लॉग को पहले बिना क्रम के लिखा जाता है और फिर, शुरू करने की प्रक्रिया के आखिर में, एक स्थिर क्रम में (सीपीयू और मेमोरी इंटेंसिव हो सकता है) क्रम से लगाया जाता है. मिलते-जुलते फ़्लैग: --execution_log_json_file (ऑर्डर किए गए टेक्स्ट json फ़ॉर्मैट), --experimental_execution_log_file (अनऑर्डर्ड बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--execution_log_json_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- Sr/main/protobuf/spawn.proto के मुताबिक, एक्ज़ीक्यूट किए गए स्पॉन को इस फ़ाइल में लॉग करें, ताकि सीमांकित Spwn प्रोटो को json फ़ॉर्मैट के तौर पर दिखाया जा सके. लॉग को पहले बिना क्रम के लिखा जाता है और फिर, शुरू करने की प्रक्रिया के आखिर में, एक स्थिर क्रम में (सीपीयू और मेमोरी इंटेंसिव हो सकता है) क्रम से लगाया जाता है. मिलते-जुलते फ़्लैग: मिलते-जुलते फ़्लैग: --execution_log_binary_file (क्रम से दिए गए बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम वाले बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--[no]expand_test_suites
डिफ़ॉल्ट: "सही"-
विश्लेषण से पहले, test_suite के टारगेट को अपने कॉम्पोनेंट टेस्ट में बड़ा करें. जब यह फ़्लैग चालू होता है (डिफ़ॉल्ट तौर पर), तो टेस्ट सुइट से जुड़े टेस्ट पर नेगेटिव टारगेट पैटर्न लागू होंगे. अगर ऐसा नहीं है, तो ये पैटर्न लागू नहीं होंगे. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड लाइन पर टॉप-लेवल के पहलू लागू किए जाते हैं: इसके बाद वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग:loading_and_analysis
--[no]experimental_cancel_concurrent_tests
डिफ़ॉल्ट: "false"-
सही होने पर, Blaze पहले कभी भी किए जाने वाले टेस्ट को रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ कॉम्बिनेशन में इस्तेमाल किया जाता है.
टैग:affects_outputs
,loading_and_analysis
--experimental_execution_log_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- इस फ़ाइल में लागू किए गए स्पॉन को src/main/protobuf/spawn.proto के मुताबिक, डीलिमिटेड स्पॉन प्रोटो के तौर पर लॉग करें. यह फ़ाइल, Spwns के निष्पादन के क्रम में लिखी गई है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (क्रम से दिए गए बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --execution_log_json_file (क्रम से दिए गए टेक्स्ट json फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमांड दिखाने के लिए).
--[no]experimental_execution_log_spawn_metrics
डिफ़ॉल्ट: "false"- लागू किए गए Spwns लॉग में स्पॉन मेट्रिक शामिल करें.
--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: ""- अलग-अलग पहलुओं के पक्ष में नहीं दिखाया गया. एक्सटर्नल ऐक्शन को शेड्यूल करने के लिए टारगेट के सेट को फ़िल्टर करता है.
--[no]experimental_extra_action_top_level_only
डिफ़ॉल्ट: "false"- अलग-अलग पहलुओं के पक्ष में नहीं दिखाया गया. सिर्फ़ टॉप लेवल के टारगेट के लिए, extra_actions को शेड्यूल करता है.
--[no]experimental_fetch_all_coverage_outputs
डिफ़ॉल्ट: "false"-
अगर सही है, तो बैजल कवरेज के दौरान हर टेस्ट के लिए, पूरी कवरेज डेटा डायरेक्ट्री फ़ेच करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_generate_llvm_lcov
डिफ़ॉल्ट: "false"-
अगर सही है, तो क्लैग के लिए कवरेज से एलसीओवी रिपोर्ट जनरेट होगी.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_j2objc_header_map
डिफ़ॉल्ट: "सही"- क्या आपको J2ObjC ट्रांसपिलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है.
--[no]experimental_j2objc_shorter_header_path
डिफ़ॉल्ट: "false"-
छोटे हेडर पाथ के साथ जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग:affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel>
डिफ़ॉल्ट: "javaBuilder"- यह सुविधा, Java कंपाइलेशन के लिए कम किए गए क्लासपाथ चालू करती है.
--[no]experimental_limit_android_lint_to_android_constrained_java
डिफ़ॉल्ट: "false"-
-इन्हें Android के साथ काम करने वाली लाइब्रेरी पर ही लागू करें.
टैग:affects_outputs
--[no]experimental_prioritize_local_actions
डिफ़ॉल्ट: "सही"-
अगर सेट की जाती है, तो सिर्फ़ स्थानीय तौर पर की जा सकने वाली कार्रवाइयों को संसाधन हासिल करने का पहला मौका दिया जाता है. डाइनैमिक रूप से चलने वाले वर्कर को दूसरा मौका मिलता है और डाइनैमिक रूप से चलने वाली कार्रवाइयों को आखिरी मौका मिलता है.
टैग:execution
--[no]experimental_run_android_lint_on_java_rules
डिफ़ॉल्ट: "false"-
Java_* सोर्स की पुष्टि करनी है या नहीं.
टैग:affects_outputs
--[no]explicit_java_test_deps
डिफ़ॉल्ट: "false"- testरनर के डिप से गलती से जानकारी हासिल करने के बजाय, java_test में JUnit या Hamcrest के लिए डिपेंडेंसी साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ बाज़ल के लिए काम करता है.
--host_java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- JavaScript का इस्तेमाल करने वाले टूल में इस्तेमाल किए जाने वाले टूल, बिल्ड के दौरान काम करते हैं.
- ऐप्लिकेशन के
--host_javacopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड के दौरान काम करने वाले टूल बनाते समय, Javac को पास करने के दूसरे विकल्प.
- ऐप्लिकेशन के
--host_jvmopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java वीएम को पास करने के दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_exclusive_test_sandboxed
डिफ़ॉल्ट: "false"-
सही होने पर, सैंडबॉक्स रणनीति की मदद से खास टेस्ट चलाए जाएंगे. खास तौर पर स्थानीय स्तर पर टेस्ट चलाने के लिए 'लोकल' टैग जोड़ें
टैग:incompatible_change
--[no]incompatible_strict_action_env
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से किसी एनवायरमेंट वैरिएबल को इनहेरिट करना है, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान रखें कि ऐसा करने से, शेयर की गई कैश मेमोरी का इस्तेमाल करने पर क्रॉस-उपयोगकर्ता कैश मेमोरी में सेव होने से रोका जा सकता है.
टैग:loading_and_analysis
,incompatible_change
- ऐप्लिकेशन के
--j2objc_translation_flags=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - J2ObjC टूल को पास करने के दूसरे विकल्प.
--java_debug
-
इसकी वजह से, JavaScript टेस्ट की Java वर्चुअल मशीन को जांच शुरू करने से पहले, JDWP का पालन करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार करना पड़ता है. इसमें -test_OUT=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>
डिफ़ॉल्ट: "8"- जावा भाषा का वर्शन
--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>
डिफ़ॉल्ट: ब्यौरा देखें- ऐसी क्लास की सूची जनरेट करने के लिए बाइनरी तय करता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य dex में होना चाहिए.
--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "Host_CPUS"- Bazel के लिए उपलब्ध लोकल सीपीयू कोर की कुल संख्या, साफ़ तौर पर सेट करें, ताकि बिल्ड ऐक्शन पर खर्च किया जा सके. एक पूर्णांक या "Host_CPUS" लेता है. इसके बाद, वैकल्पिक तौर पर [-|*]<फ़्लोट> (उदाहरण के लिए, उपलब्ध सीपीयू (CPU) की कुल संख्या का अनुमान लगाने के लिए, Bazel सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
--local_ram_resources=<an integer, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "Host_RAM*.67"- Bazel के लिए उपलब्ध लोकल होस्ट रैम (एमबी में) की कुल संख्या साफ़ तौर पर सेट करें, ताकि उसे स्थानीय तौर पर एक्ज़ीक्यूट की गई बिल्ड कार्रवाइयों पर खर्च किया जा सके. एक पूर्णांक या "Host_RAM" लेता है. इसके बाद, वैकल्पिक रूप से [-|*]<floor> (उदाहरण के लिए, उपलब्ध रैम के आधे से ज़्यादा का इस्तेमाल करने के लिए, Host_RAM*.5). डिफ़ॉल्ट रूप से, ("Host_RAM*.67"), Bazel, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा और यह पता लगाएगा कि कितनी रैम उपलब्ध है. वह इसका 67% इस्तेमाल करेगा.
--local_termination_grace_seconds=<an integer>
डिफ़ॉल्ट: "15"- समय खत्म होने की वजह से किसी लोकल प्रोसेस को बंद करने और उसे ज़बरदस्ती बंद करने के बीच का समय.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- कोलन से अलग की गई इस सूची में बताया जाता है कि पैकेज कहां खोजने हैं. '%workspace%' से शुरू होने वाले एलिमेंट, बंद होने वाले फ़ाइल फ़ोल्डर से मिलते-जुलते हैं. अगर इसे खाली छोड़ा जाता है या इसे खाली छोड़ा जाता है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट होता है.
- ऐप्लिकेशन के
--plugin=<a build target label>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड में इस्तेमाल करने के लिए प्लगिन. फ़िलहाल, java_plugin के साथ काम करता है.
--proguard_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- यह बताता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना चाहिए.
--proto_compiler=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc"-
प्रोटो-कंपाइलर का लेबल.
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_cc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain"-
proto_lang_toolchain() का लेबल जिसमें C++ Protos को कंपाइल करने का तरीका बताया गया है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
proto_lang_toolchain() का लेबल, जिसमें j2objc protos को कंपाइल करने का तरीका बताया गया है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_java=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"-
proto_lang_toolchain() का लेबल, जो Java Protos को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_javalite=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"-
proto_lang_toolchain() का लेबल, जो JavaLite Protos को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
- ऐप्लिकेशन के
--protocopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
प्रोटोबफ़ कंपाइलर को पास करने के ज़्यादा विकल्प.
टैग:affects_outputs
--[no]runs_per_test_detects_flakes
डिफ़ॉल्ट: "false"- सही होने पर, कोई भी शार्ड जिसमें कम से कम एक रन/अटैम पास होता है और कम से कम एक रन/अटैम फ़ेल होता है, उसे फ़्लेकी स्टेटस माना जाता है.
--shell_executable=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
Bzel के इस्तेमाल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को पहले Bazel सर्वर (जो कि Bazel सर्वर को स्टार्ट करता है) पर सेट किया जाता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर वह चलता है. Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash. ध्यान दें कि बैश के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी के बनने या रनटाइम के दौरान सिस्टम फ़ेल हो सकता है.
टैग:loading_and_analysis
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर इस सुविधा को चालू किया जाता है, तो Bazel "लोडिंग पैकेज:" मैसेज प्रिंट करेगा.
- ऐप्लिकेशन के
--test_arg=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - ऐसे अन्य विकल्प और तर्क तय करता है जिन्हें टेस्ट एक्ज़ीक्यूटेबल टेस्ट में पास किया जाना चाहिए. एक से ज़्यादा तर्क तय करने के लिए, एक से ज़्यादा बार इस्तेमाल किया जा सकता है. अगर कई टेस्ट किए जाते हैं, तो सभी को एक जैसे तर्क मिलेंगे. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
--test_filter=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- टेस्ट फ़्रेमवर्क पर भेजने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, जांच को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे बनाए गए टारगेट पर कोई असर नहीं पड़ता.
--test_lang_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- इसमें, जांच के लिए इस्तेमाल की जाने वाली भाषाओं की कॉमा-सेपरेटेड लिस्ट होती है. बाहर रखी गई भाषाओं के बारे में बताने के लिए, हर भाषा के पहले '-' लिखा जा सकता है. सिर्फ़ वे टेस्ट टारगेट ही मिलेंगे जो खास भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया जाने वाला नाम, *_test नियम में भाषा के प्रीफ़िक्स के जैसा होना चाहिए. जैसे, 'cc', 'java', 'py' वगैरह में से कोई एक. यह विकल्प --build_tests_only व्यवहार और टेस्ट कमांड पर असर डालता है.
--test_result_expiration=<an integer>
डिफ़ॉल्ट: "-1"- यह विकल्प अब सेवा में नहीं है और इसका कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast
डिफ़ॉल्ट: "false"- टेस्ट रनर पर तेज़ी से फ़ॉरवर्ड नहीं किया जा सकता. पहली बार फ़ेल होने पर, टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit or disabled>
डिफ़ॉल्ट: "अश्लील"- टेस्टिंग की रणनीति तय करें: शार्डिंग का इस्तेमाल 'साफ़ तौर पर' करने के लिए, सिर्फ़ तब करें, जब 'sard_count' BUILD एट्रिब्यूट मौजूद हो. यह विकल्प 'बंद' है, क्योंकि इसमें कभी भी टेस्ट शार्डिंग नहीं होगी.
--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>
डिफ़ॉल्ट: "8"- बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया जाने वाला 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
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- निर्देश के आउटपुट को कंट्रोल करने वाले विकल्प:
--[no]canonicalize_policy
डिफ़ॉल्ट: "false"-
बड़ा करने और फ़िल्टर करने के बाद, कैननिकल नीति आउटपुट करें. आउटपुट को साफ़ रखने के लिए, जब इस विकल्प को 'सही है' पर सेट किया जाता है, तब कैननिकल किए गए कमांड आर्ग्युमेंट नहीं दिखाए जाएंगे. ध्यान दें कि --for_command का दिया गया निर्देश, फ़िल्टर की गई नीति पर असर डालता है. अगर इसके लिए कोई निर्देश नहीं दिया गया है, तो डिफ़ॉल्ट निर्देश 'build' होता है.
टैग:affects_outputs
,terminal_output
--[no]show_warnings
डिफ़ॉल्ट: "false"-
आउटपुट पार्सर की चेतावनी, स्टैंडर्ड गड़बड़ी के लिए. उदाहरण के लिए, अलग-अलग फ़्लैग के विकल्पों के लिए.
टैग:affects_outputs
,terminal_output
- इस बात पर असर डालने वाले विकल्प कि Bazel मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को पूरी तरह से कैसे लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "false"-
अगर sensitive_enforce_config_setting_ पहचानने के लिए गलत वैल्यू है, तो यह नॉप है. ऐसा न होने पर, अगर यह फ़्लैग गलत है, तो बिना किसी खास 'किसको दिखे' एट्रिब्यूट के बिना कोई भी config_setting //visible:public पर सेट कर दे. अगर यह फ़्लैग सही है, तो config_setting, दिखने के उसी लॉजिक का पालन करेगी जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
--for_command=<a string>
डिफ़ॉल्ट: "build"-
वह निर्देश जिसके लिए विकल्पों को कैननिकल बनाया जाना चाहिए.
टैग:affects_outputs
,terminal_output
--invocation_policy=<a string>
डिफ़ॉल्ट: ""-
कैननिकल के विकल्पों पर, शुरू करने की नीति लागू होती है.
टैग:affects_outputs
,terminal_output
- रिमोट कैशिंग और एक्ज़ीक्यूट करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
--deleted_packages=<comma-separated list of package names>
डिफ़ॉल्ट: ""- पैकेज के नामों की कॉमा-सेपरेटेड लिस्ट, जिसे बिल्ड सिस्टम मानेगा. भले ही, वे पैकेज पाथ पर कहीं भी दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD को मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह इसकी शिकायत कर सकता है. ऐसा तब होता है, जब वह अब भी किसी दूसरी Package_path एंट्री में मौजूद हो. --deleted_packages x/y को तय करने से इस समस्या से बचा जा सकता है.
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- कोलन से अलग की गई इस सूची में बताया जाता है कि पैकेज कहां खोजने हैं. '%workspace%' से शुरू होने वाले एलिमेंट, बंद होने वाले फ़ाइल फ़ोल्डर से मिलते-जुलते हैं. अगर इसे खाली छोड़ा जाता है या इसे खाली छोड़ा जाता है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट होता है.
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर इस सुविधा को चालू किया जाता है, तो Bazel "लोडिंग पैकेज:" मैसेज प्रिंट करेगा.
साफ़ करने के विकल्प
build के सभी विकल्प इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- निर्देश के आउटपुट को कंट्रोल करने वाले विकल्प:
--[no]async
डिफ़ॉल्ट: "false"-
अगर सही हो, तो आउटपुट क्लीनिंग एसिंक्रोनस होती है. इस निर्देश के पूरा होने के बाद, उसी क्लाइंट में नए निर्देश लागू किए जा सकेंगे. हालांकि, बैकग्राउंड में डेटा मिटाने की प्रक्रिया जारी रह सकती है.
टैग:host_machine_resource_optimizations
--[no]expunge
डिफ़ॉल्ट: "false"-
अगर सही हो, तो क्लीनअप इस bazel इंस्टेंस के लिए काम करने वाले पूरे ट्री को हटा देता है. इसमें, bazel के बनाए गए अस्थायी और बिल्ड वाली आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर bazel सर्वर चालू है, तो यह उसे बंद कर देता है.
टैग:host_machine_resource_optimizations
--expunge_async
-
अगर साफ़ किया जाए, तो इस bazel इंस्टेंस के लिए, एसिंक्रोनस तरीके से काम करने वाले पूरे ट्री को हटा दिया जाता है. इसमें, bazel के बनाए गए सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल हैं. साथ ही, अगर bazel सर्वर काम कर रहा है, तो उसे बंद कर देता है. इस निर्देश के पूरा होने के बाद, उसी क्लाइंट में नए निर्देश लागू किए जा सकेंगे. हालांकि, बैकग्राउंड में डेटा मिटाने की प्रक्रिया जारी रह सकती है.
इसमें बड़ा होता है:
--expunge
--async
टैग:host_machine_resource_optimizations
--[no]remove_all_convenience_symlinks
डिफ़ॉल्ट: "false"-
सही होने पर, फ़ाइल फ़ोल्डर में सिंलिंक_प्रीफ़िक्स वाले सभी सिमलिंक मिटा दिए जाएंगे. इस फ़्लैग के बिना, सिर्फ़ पहले से तय सफ़िक्स वाले सिमलिंक ही सही किए जाते हैं.
टैग:affects_outputs
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग का कॉम्बिनेशन वगैरह) को पूरी तरह से कैसे लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
कॉन्फ़िगरेशन के विकल्प
कवरेज के विकल्प
test से सभी विकल्पों को इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
Cquery के विकल्प
test से सभी विकल्पों को इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:
--aspect_deps=<off, conservative or precise>
डिफ़ॉल्ट: "कंज़र्वेटिव"-
जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तो आसपेक्ट डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि तय की गई सभी पहलू डिपेंडेंसी जोड़ी जाती हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के नियम की कैटगरी दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम की क्लास के आधार पर ऐक्टिव होते हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट की जांच करने के लिए, अन्य पैकेज लोड करने ज़रूरी होते हैं. इस वजह से, यह अन्य मोड की तुलना में धीमा हो जाता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता है: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह प्रोसेस, 'bazel क्वेरी' के दौरान नहीं चलती.
टैग:build_file_semantics
--[no]graph:factored
डिफ़ॉल्ट: "सही"-
सही होने पर, ग्राफ़ पर 'फ़ैक्टर' निकाला जाएगा. इसका मतलब है कि टॉपॉलॉजिकली इक्विलंट नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल जोड़ दिए जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--graph:node_limit=<an integer>
डिफ़ॉल्ट: "512"-
आउटपुट में, ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि कोई काट-छांट नहीं की जाएगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--[no]implicit_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel के ज़रिए जोड़ा गया है. cquery के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग:build_file_semantics
--[no]include_aspects
डिफ़ॉल्ट: "सही"-
क्वेरी, cquery: आउटपुट में पक्ष से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (निर्देशों को हमेशा अपनाया जाता है).
टैग:terminal_output
--[no]incompatible_display_source_file_location
डिफ़ॉल्ट: "सही"-
डिफ़ॉल्ट रूप से 'सही', सोर्स फ़ाइल का टारगेट दिखाता है. सही होने पर, लोकेशन आउटपुट में सोर्स फ़ाइलों की लाइन 1 की जगह दिखाता है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग:terminal_output
,incompatible_change
--[no]incompatible_package_group_includes_double_slash
डिफ़ॉल्ट: "सही"-
इस सुविधा को चालू करने पर, Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, पहले `//` की वैल्यू नहीं छोड़ी जाएगी.
टैग:terminal_output
,incompatible_change
--[no]infer_universe_scope
डिफ़ॉल्ट: "false"-
अगर सेट और --universe_scope को सेट नहीं किया जाता है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे कि`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई --universe_scope वैल्यू, शायद आपकी पसंद के मुताबिक न हो. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/query/language#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` (जैसे कि `cquery` पर नहीं) पर लागू होता है.
टैग:loading_and_analysis
--[no]line_terminator_null
डिफ़ॉल्ट: "false"-
हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाए या नहीं.
टैग:terminal_output
--[no]nodep_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, "nodep" एट्रिब्यूट की वैल्यू को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा, जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडेप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग:build_file_semantics
--output=<a string>
डिफ़ॉल्ट: "लेबल"-
वह फ़ॉर्मैट जिसमें cquery नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_ kind, textproto, ट्रांज़िशन, proto, jsonproto. अगर आपने 'ट्रांज़िशन' चुना है, तो आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग:terminal_output
पर लागू होता है
--[no]proto:definition_stack
डिफ़ॉल्ट: "false"-
definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें, जो नियम की क्लास तय किए जाने के समय Starlark कॉल स्टैक के हर नियम के लिए रिकॉर्ड करता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, Select() के ज़रिए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट फ़्लैट कर दिए जाते हैं. सूची के टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन वह सूची है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप शून्य तक चपटे हो जाते हैं.
टैग:build_file_semantics
--[no]proto:include_configurations
डिफ़ॉल्ट: "सही"-
चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. बंद होने पर, cquery Proto आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग:affects_outputs
--[no]proto:include_synthetic_attribute_hash
डिफ़ॉल्ट: "false"- $internal_attr_hh एट्रिब्यूट का हिसाब लगाने और उसे पॉप्युलेट करने या न करने का विकल्प.
टैग:terminal_output
--[no]proto:instantiation_stack
डिफ़ॉल्ट: "false"-
हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग:terminal_output
--[no]proto:locations
डिफ़ॉल्ट: "सही"-
प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग:terminal_output
--proto:output_rule_attrs=<comma-separated list of options>
डिफ़ॉल्ट: "सभी"-
आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. किसी भी एट्रिब्यूट का आउटपुट न देने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --OUT=proto पर लागू होता है.
टैग:terminal_output
--[no]proto:rule_inputs_and_outputs
डिफ़ॉल्ट: "सही"-
रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग:terminal_output
--[no]relative_locations
डिफ़ॉल्ट: "false"-
सही होने पर, एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह तय होगी. डिफ़ॉल्ट रूप से, लोकेशन आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग:terminal_output
--show_config_fragments=<off, direct or transitive>
डिफ़ॉल्ट: "बंद"-
किसी नियम के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट और उसकी ट्रांज़िटिव डिपेंडेंसी दिखाता है. इससे, यह आकलन करने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ में कितनी काट-छांट की जा सकती है.
टैग:affects_outputs
--starlark:expr=<a string>
डिफ़ॉल्ट: ""-
कॉन्फ़िगर किए गए हर टारगेट को cquery के --port=starlark मोड में फ़ॉर्मैट करने के लिए, Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट, 'टारगेट' से जुड़ा है. अगर --starlark:expr या --starlark:file मौजूद नहीं है. हालांकि, यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट होगा. --starlark:expr और --starlark:file दोनों देना एक गड़बड़ी है.
टैग:terminal_output
--starlark:file=<a string>
डिफ़ॉल्ट: ""-
Starlark के 'फ़ॉर्मैट' नाम की फ़ाइल का नाम. यह एक आर्ग्युमेंट का नाम है. यह फ़ाइल, कॉन्फ़िगर किए गए हर टारगेट पर लागू होती है, ताकि कॉन्टेंट को स्ट्रिंग के तौर पर फ़ॉर्मैट किया जा सके. --starlark:expr और --starlark:file दोनों देना एक गड़बड़ी है. ज़्यादा जानकारी के लिए --आउटपुट=स्टारलार्क के लिए सहायता देखें.
टैग:terminal_output
--[no]tool_deps
डिफ़ॉल्ट: "सही"-
क्वेरी: बंद होने पर, 'होस्ट कॉन्फ़िगरेशन' या 'एक्ज़ीक्यूशन' टारगेट की डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाता जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर को मिलने वाला किनारा. आम तौर पर, यह उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, उस टूल के बारे में बताता है जिसे बिल्ड के दौरान लागू किया जाता है.
Cquery: बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट का पता लगाने वाले टॉप लेवल टारगेट से, होस्ट या एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. साथ ही, टारगेट कॉन्फ़िगरेशन में भी कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट ही दिखेंगे. इस विकल्प में, ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग:build_file_semantics
--transitions=<full, lite or none>
डिफ़ॉल्ट: "कोई नहीं"-
वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगा.
टैग:affects_outputs
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का सेट, कॉमा लगाकर अलग किया गया. इसमें योग और घटाव वाले पैटर्न शामिल होते हैं. क्वेरी को संसार में निष्पादित किया जा सकता है, जबकि बताए गए लक्ष्यों के ट्रांज़िटिव बंद होने से परिभाषित होता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है.
cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब तैयार किए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट मान लिया जाता है. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए इस विकल्प को तय न करने से बिल्ड टूट सकता है.
टैग:loading_and_analysis
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]experimental_inprocess_symlink_creation
डिफ़ॉल्ट: "false"-
सिमलिंक ट्री बनाने के लिए, डायरेक्ट फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_remotable_source_manifests
डिफ़ॉल्ट: "false"-
सोर्स मेनिफ़ेस्ट कार्रवाइयों को फिर से चालू करना है या नहीं
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_split_coverage_postprocessing
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel एक नए स्पैम में जांच के लिए, कवरेज पोस्टप्रोसेसिंग करेगा.
टैग:execution
--[no]experimental_strict_fileset_output
डिफ़ॉल्ट: "false"-
अगर यह विकल्प चालू किया जाता है, तो फ़ाइलसेट, सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री को नहीं पीछे छोड़ते या सिमलिंक के प्रति संवेदनशील नहीं होते.
टैग:execution
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...>
डिफ़ॉल्ट: ""-
कार्रवाई के बाद की जाने वाली कार्रवाई की जानकारी में, कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जो एक्ज़ीक्यूट करने की जानकारी देती हैं. कई आम कार्रवाइयां, एक्ज़ीक्यूट करने की जानकारी के साथ काम करती हैं, जैसे कि Genrun, CppCompile, Javac, StarlarkAction, TestRunner. एक से ज़्यादा वैल्यू तय करते समय ऑर्डर देना ज़रूरी होता है, क्योंकि एक ही मिनिमनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.
सिंटैक्स: "regex=[+-]key,regex=[+-]key,...".
उदाहरण:
'.*=+x,.*=-y,.*=+z', सभी कार्रवाइयों के चलने की जानकारी में, 'x' और 'z' जोड़ता है और 'y' को हटा देता है.
'GenTerms=+requires-x', जेनरूल की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूटिंग की जानकारी में 'requires-x' जोड़ता है.
'(?!GenTerms).*=-requires-x', सभी गैर-जेनरूल कार्रवाइयों के लिए, निष्पादन जानकारी से 'requires-x' को हटा देता है.
टैग:execution
,affects_outputs
,loading_and_analysis
--persistent_android_dex_desugar
-
कर्मचारियों का इस्तेमाल करके, स्थायी Android dex और Desugar कार्रवाइयों को चालू करें.
इसमें बड़ा होता है:
--strategy=Desugar=worker
--strategy=DexBuilder=worker
टैग:host_machine_resource_optimizations
,execution
--persistent_android_resource_processor
-
कर्मचारियों का इस्तेमाल करके, स्थायी Android संसाधन प्रोसेसर चालू करें.
यह इन जगहों तक फैलता है:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
--strategy=Aapt2Optimize=worker
--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
host_machine_resource_optimizations
execution
--persistent_multiplex_android_dex_desugar
-
कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android dex और desugar ऐक्शन चालू करें.
यह इन जगहों पर फैलता है:
--persistent_android_dex_desugar
--modify_execution_info=Desugar=+supports-multiplex-workers
--modify_execution_info=DexBuilder=+supports-multiplex-workers
टैग:host_machine_resource_optimizations
,execution
--persistent_multiplex_android_resource_processor
-
कर्मचारियों का इस्तेमाल करके, स्थायी मल्टीप्लेक्स Android रिसॉर्स प्रोसेसर को चालू करें.
यह इन जगहों तक फैलता है:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers
host_machine_resource_optimizations
execution
--persistent_multiplex_android_tools
-
Android के स्थायी और मल्टीप्लेक्स टूल चालू करें. जैसे- डेक्सिंग, डीयूगरिंग, और रिसॉर्स प्रोसेसिंग.
यह इन तक फैलता है:
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
- कार्रवाई करने के लिए इस्तेमाल किए जाने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:
--android_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Android का टारगेट कंपाइलर.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_crosstool_top=<a build target label>
डिफ़ॉल्ट: "//external:android/crosstool"-
Android बिल्ड के लिए इस्तेमाल किए गए C++ कंपाइलर की जगह की जानकारी.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_manifest_merger=<legacy, android or force_android>
डिफ़ॉल्ट: "android"-
android_binary नियमों के लिए इस्तेमाल किए जाने वाले मेनिफ़ेस्ट मर्जर को चुनता है. फ़्लैग करें, ताकि पुराने मर्जर की मदद से, Android मेनिफ़ेस्ट को मर्ज करने में मदद मिल सके.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_platforms=<a build target label>
डिफ़ॉल्ट: ""-
ऐसे प्लैटफ़ॉर्म सेट करता है जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म के बारे में बताया गया है, तो बाइनरी फ़ाइल एक फ़ैट APKs होती है. इसमें, बताए गए हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_sdk=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk"-
उस Android SDK/प्लैटफ़ॉर्म के बारे में बताता है जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--apple_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Apple का टारगेट कंपाइलर. इसकी मदद से, टूलचेन के वैरिएंट चुने जा सकते हैं. उदाहरण के लिए, xcode-beta.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--apple_crosstool_top=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"-
Apple औरobjc के नियमों और उनकी डिपेंडेंसी में इस्तेमाल किए जाने वाले क्रॉसटूल पैकेज का लेबल.
टैग:loses_incremental_state
,changes_inputs
--apple_grte_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
Apple का टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--cc_output_directory_tag=<a string>
डिफ़ॉल्ट: ""-
कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने के लिए सफ़िक्स के बारे में जानकारी देता है.
टैग:affects_outputs
,explicit_in_output_path
--compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.
टैग:loading_and_analysis
,execution
--coverage_output_generator=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:lcov_ सुझावों"-
रॉ कवरेज रिपोर्ट को पोस्ट करने के लिए इस्तेमाल होने वाली बाइनरी की जगह. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcov_ सुझावों' का इस्तेमाल करता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_report_generator=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_report_generator"-
कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. फ़िलहाल, यह एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल यानी बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:coverage_report_generator' होता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_support=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_support"-
उन सहायता फ़ाइलों की जगह जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई के इनपुट के लिए ज़रूरी होती हैं. डिफ़ॉल्ट रूप से '//tools/test:coverage_support' सेट होता है.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--crosstool_top=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"-
C++ कोड को कंपाइल करने के लिए इस्तेमाल होने वाले क्रॉसटूल पैकेज का लेबल.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--custom_malloc=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
यह तय करता है कि कस्टम Maloc लागू करने की सुविधा कैसे लागू की जाए. यह सेटिंग, बिल्ड के नियमों में मॉलक एट्रिब्यूट को बदल देती है.
टैग:changes_inputs
,affects_outputs
- ऐप्लिकेशन के
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन के आगे - (नेगेटिव एक्सप्रेशन) लगाया जाएगा. साथ ही, इन्हें कॉमा लगाकर अलग किए गए कंस्ट्रेंट वैल्यू के टारगेट की सूची में (=) असाइन किया जाएगा. अगर कोई टारगेट, किसी भी नेगेटिव एक्सप्रेशन से मेल नहीं खाता और कम से कम एक पॉज़िटिव एक्सप्रेशन से मैच करता है, तो इसका टूलचेन रिज़ॉल्यूशन इस तरह परफ़ॉर्म किया जाएगा जैसे कि कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर बताया गया हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64 //demo के तहत आने वाले किसी भी टारगेट में 'x86_64' जोड़ देगा, लेकिन इनके नाम में 'test' शामिल नहीं होगा.
टैग:loading_and_analysis
--[no]experimental_enable_objc_cc_deps
डिफ़ॉल्ट: "सही"-
यह objc_* नियमों को cc_library पर निर्भर करने की अनुमति देता है. साथ ही, इसकी वजह से कोई भी ऑब्जेसी डिपेंडेंसी --iOS_multi_cpu> में किसी भी वैल्यू के लिए --cpu को "ios_<--ios_cpu>" पर सेट करने के लिए सेट होती है.
टैग:loading_and_analysis
,incompatible_change
--[no]experimental_include_xcode_execution_requirements
डिफ़ॉल्ट: "false"-
अगर इस नीति को सेट किया जाता है, तो हर Xcode कार्रवाई के लिए "requires-xcode:{version}" को लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" चलाने की ज़रूरी शर्त भी जोड़ें.
टैग:loses_incremental_state
,loading_and_analysis
,execution
--[no]experimental_prefer_mutual_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 फ़ाइल में रजिस्टर करने वाले टूलचेन() से पहले किया जाएगा.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन में चुना जाता है और आपको इसे बदलने की ज़रूरत नहीं पड़ती.
टैग:action_command_lines
,affects_outputs
--host_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर. अगर --host_crosstool_top को सेट नहीं किया गया है, तो इसे अनदेखा किया जाता है.
टैग:loading_and_analysis
,execution
--host_crosstool_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
डिफ़ॉल्ट रूप से, होस्ट कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler के विकल्पों का इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया गया है, तो Bazel, दिए गए Crosstool_top के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--host_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताया गया है, तो यह सेटिंग, होस्ट कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग:action_command_lines
,affects_outputs
--host_platform=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--[no]incompatible_disable_expand_if_all_available_in_flag_set
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel फ़्लैग_sets में expand_if_all_available को तय करने की अनुमति नहीं देगा(माइग्रेट करने से जुड़े निर्देशों के लिए https://github.com/bazelbuild/bazel/issues/7008 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, c++ टूलचेन में 'होस्ट' और 'nonhost' सुविधाओं को चालू नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_android_toolchain_resolution
डिफ़ॉल्ट: "false"-
टूलचेन रिज़ॉल्यूशन का इस्तेमाल करके, Android के नियमों (Starlark और नेटिव) के लिए Android SDK चुनें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution
डिफ़ॉल्ट: "false"-
Apple SDK for apple के नियम (Starlark और local) चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, lto इंडेक्स करने वाली कमांड लाइनों के लिए, C++ लिंक की कार्रवाई वाली कमांड लाइन का फिर से इस्तेमाल नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_cpu_and_compiler_attributes_from_cc_toolchain
डिफ़ॉल्ट: "सही"-
अगर सही है, तो cc_toolchain.cpu और cc_toolchain.compiler एट्रिब्यूट सेट होने पर Bazel शिकायत करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7075 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_legacy_whole_archive
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_require_ctx_in_configure_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel को cc_Common.configure_features में 'ctx' पैरामीटर की ज़रूरत होगी (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7793 देखें).
टैग:loading_and_analysis
,incompatible_change
-
अगर टूलचेन पर इंटरफ़ेस के शेयर किए गए ऑब्जेक्ट इस्तेमाल किए जा सकते हैं, तो उनका इस्तेमाल करें. फ़िलहाल, सभी ELF टूलचेन में यह सेटिंग काम करती है.
टैग:loading_and_analysis
,affects_outputs
,affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में बताता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिले iOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
macOS ऐप्लिकेशन बनाने के लिए, macOS SDK टूल के वर्शन के बारे में जानकारी देता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से जुड़े macOS के SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--minimum_os_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह आपके कंपाइलेशन से टारगेट करता है, लेकिन ओएस का कम से कम वर्शन.
टैग:loading_and_analysis
,affects_outputs
--platform_mappings=<a relative path>
डिफ़ॉल्ट: ""-
मैपिंग फ़ाइल की जगह की जानकारी. इससे यह पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं किया गया है, तो किस प्लैटफ़ॉर्म का इस्तेमाल किया जाए या कोई प्लैटफ़ॉर्म पहले से मौजूद होने पर किस तरह के फ़्लैग सेट किए जाएं. मुख्य फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता होना चाहिए. डिफ़ॉल्ट तौर पर 'platform_mappings' (फ़ाइल फ़ोल्डर रूट के तहत आने वाली फ़ाइल).
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--platforms=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म की जानकारी देते हैं.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--python2_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अब काम नहीं करता. `--insupported_use_python_toolchains` की वजह से, यह सुविधा बंद है.
टैग:no_op
,deprecated
--python3_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अब काम नहीं करता. `--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 इंटरप्रेटर को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. अब काम नहीं करता; --insupported_use_python_toolchains इसकी मदद से बंद किया गया है.
टैग:loading_and_analysis
,affects_outputs
--target_platform_fallback=<a build target label>
डिफ़ॉल्ट: "@local_config_platform//:host"-
प्लैटफ़ॉर्म के नियम का लेबल. इसका इस्तेमाल तब किया जाना चाहिए, जब कोई टारगेट प्लैटफ़ॉर्म सेट न किया गया हो और कोई भी प्लैटफ़ॉर्म मैपिंग मौजूदा फ़्लैग से मेल न खाता हो.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह तय करता है कि किस वर्शन का इस्तेमाल करके, tvOS ऐप्लिकेशन बनाया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिलने वाले डिफ़ॉल्ट tvOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह WatchOS SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जा सकता है. अगर इसकी जानकारी नहीं दी गई है, तो 'xcode_version' से मिलने वाले डिफ़ॉल्ट WatchOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--xcode_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताया गया है, तो सही बिल्ड ऐक्शन के लिए दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर इसकी जानकारी नहीं दी गई है, तो Xcode के एक्सक्यूटर डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xcode_version_config=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"-
xcode_config नियम का लेबल, बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए इस्तेमाल किया जाता है.
टैग:loses_incremental_state
,loading_and_analysis
- कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:
--[no]apple_enable_auto_dsym_dbg
डिफ़ॉल्ट: "false"-
dbg बिल्ड के लिए, डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलों) को जनरेट करना ज़बरदस्ती चालू करना है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]apple_generate_dsym
डिफ़ॉल्ट: "false"-
डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करनी है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]build_runfile_links
डिफ़ॉल्ट: "सही"-
अगर सही है, तो रनफ़ाइलें बनाएं और सभी टारगेट के लिए जंगलों को सिमलिंक करें. गलत होने पर, जब भी हो सके, सिर्फ़ मेनिफ़ेस्ट लिखें.
टैग:affects_outputs
--[no]build_runfile_manifests
डिफ़ॉल्ट: "सही"-
अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर यह गलत है, तो उन्हें हटा दें. 'गलत' होने पर लोकल टेस्ट नहीं चलेंगे.
टैग:affects_outputs
--[no]build_test_dwp
डिफ़ॉल्ट: "false"-
इस सुविधा को चालू करने पर, स्टैटिक और फ़्रैक्शन के साथ C++ टेस्ट बनाते समय, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.
टैग:loading_and_analysis
,affects_outputs
--cc_proto_library_header_suffixes=<comma-separated list of options>
डिफ़ॉल्ट: ".pb.h"-
यह cc_proto_library बनाई जाने वाली हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग:affects_outputs
,loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated list of options>
डिफ़ॉल्ट: ".pb.cc"-
cc_proto_library से बनाई जाने वाली सोर्स फ़ाइलों के प्रीफ़िक्स सेट करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info
डिफ़ॉल्ट: "false"-
proto_library में, वैकल्पिक Java एपीआई वर्शन के लिए, ज़्यादा कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_proto_extra_actions
डिफ़ॉल्ट: "false"-
proto_library में, वैकल्पिक Java एपीआई वर्शन के लिए, ज़्यादा कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_save_feature_state
डिफ़ॉल्ट: "false"-
चालू किए गए और अनुरोध किए गए फ़ंक्शन की स्थिति को कंपाइलेशन के आउटपुट के तौर पर सेव करें.
टैग:affects_outputs
,experimental
--fission=<a set of compilation modes>
डिफ़ॉल्ट: "नहीं"-
यह बताता है कि C++ के कंपाइलेशन और लिंक के लिए कौनसे कंपाइलेशन मोड, फ़ंक्शन का इस्तेमाल करते हैं. यह सभी मोड चालू करने के लिए {'Fastbuild', 'dbg', 'opt'} या विशेष वैल्यू 'yes' का कोई भी कॉम्बिनेशन और सभी मोड बंद करने के लिए 'no' हो सकता है.
टैग:loading_and_analysis
,action_command_lines
,affects_outputs
--[no]incompatible_always_include_files_in_data
डिफ़ॉल्ट: "सही"-
अगर सही है, तो नेटिव नियम अपनी रनफ़ाइल में <code>DefaultInfo.files</code> डेटा डिपेंडेंसी जोड़ देते हैं. यह डेटा, Starlark के नियमों (https://bazel.build/extending/rules#runfiles_features_to_avoid) के हिसाब से काम करता है.
टैग:affects_outputs
,incompatible_change
--[no]legacy_external_runfiles
डिफ़ॉल्ट: "सही"-
अगर सही है, तो .runfiles/wsname/external/repo के तहत, बाहरी डेटा स्टोर करने की जगहों के लिए रनफ़ाइल्स सिमलिंक जंगलों को बनाएं.
टैग:affects_outputs
--[no]objc_generate_linkmap
डिफ़ॉल्ट: "false"-
तय करता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.
टैग:affects_outputs
--[no]save_temps
डिफ़ॉल्ट: "false"-
अगर इस नीति को सेट किया जाता है, तो gcc से कुछ समय के लिए जनरेट होने वाले आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (पहले से प्रोसेस की गई C) और .ii फ़ाइलें (पहले से प्रोसेस की गई C++) शामिल हैं.
टैग:affects_outputs
- ऐसे विकल्प जो उपयोगकर्ता को सही आउटपुट को कॉन्फ़िगर करने देते हैं, उसकी वैल्यू पर असर होता है, जबकि इसकी वैल्यू पर असर नहीं पड़ता:
- ऐप्लिकेशन के
--action_env=<a 'name=value' assignment with an optional value part>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
टारगेट कॉन्फ़िगरेशन के साथ कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, वैल्यू को शुरू करने वाले एनवायरमेंट या नाम=वैल्यू के जोड़े से लिया जाएगा. इस पेयर की मदद से वैल्यू को, शुरू करने वाले एनवायरमेंट से अलग सेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत, अलग-अलग वैरिएबल के लिए उपलब्ध विकल्प.
टैग:action_command_lines
--android_cpu=<a string>
डिफ़ॉल्ट: "armeabi-v7a"-
Android टारगेट सीपीयू.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]android_databinding_use_androidx
डिफ़ॉल्ट: "false"-
AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]android_databinding_use_v3_4_args
डिफ़ॉल्ट: "false"-
3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--android_dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "बंद"-
यह तय करता है कि जब कोई cc_binary साफ़ तौर पर शेयर की गई लाइब्रेरी नहीं बनाता है, तो Android नियमों के C++ डेलिगेशन डाइनैमिक रूप से लिंक किए जाएंगे या नहीं. 'डिफ़ॉल्ट' का मतलब है कि bazel यह चुनेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:affects_outputs
,loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>
डिफ़ॉल्ट: "वर्णमाला"-
Android बाइनरी के लिए, मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्सक्लूट के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में, कॉन्फ़िगरेशन डायरेक्ट्री के मुताबिक पाथ के हिसाब से क्रम में लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को हर लाइब्रेरी के मेनिफ़ेस्ट में क्रम से लगाया जाता है, जो उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आती है.
टैग:action_command_lines
,execution
--[no]android_resource_shrinking
डिफ़ॉल्ट: "false"-
यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को कम करने की सुविधा चालू करती है.
टैग:affects_outputs
,loading_and_analysis
- ऐप्लिकेशन के
--apple_bitcode=<'mode' or 'platform=mode', where 'mode' is none, embedded_markers or embedded, and 'platform' is ios, watchos, tvos, macos or catalyst>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
डिवाइस आर्किटेक्चर को टारगेट करने वाले कंपाइलेशन चरण के लिए, Apple बिटकोड मोड तय करें. वैल्यू, '[platform=]mode' फ़ॉर्म में हैं. इसमें प्लैटफ़ॉर्म वैकल्पिक है. जैसे, 'iOS', 'macos', 'tvos' या 'watchos'. अगर बिटकोड मोड दिया गया हो, तो खास तौर पर उस प्लैटफ़ॉर्म के लिए लागू किया जाता है. अगर इसे उपलब्ध नहीं कराया जाता है, तो यह सभी प्लैटफ़ॉर्म पर लागू होता है. मोड 'कोई नहीं', 'embed_markers' या 'एम्बेड किया गया' होना चाहिए. यह विकल्प कई बार दिया जा सकता है.
टैग:loses_incremental_state
--[no]build_python_zip
डिफ़ॉल्ट: "ऑटो"-
Python के लिए एक्ज़ीक्यूटेबल ज़िप बनाएं. Windows के लिए और दूसरे प्लैटफ़ॉर्म पर बंद करें
टैग:affects_outputs
- ऐप्लिकेशन के
--catalyst_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple Catalyst बाइनरी बनाने हैं.
टैग:loses_incremental_state
,loading_and_analysis
--[no]collect_code_coverage
डिफ़ॉल्ट: "false"-
अगर बताया जाएगा, तो Bazel, इंस्ट्रुमेंट कोड (जहां संभव हो ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल करके) करेगा और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ --instrumentation_filter से मेल खाने वाले टारगेट ही प्रभावित होंगे. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं बताया जाना चाहिए - इसकी जगह, 'bazeloverlay' कमांड का इस्तेमाल किया जाना चाहिए.
टैग:affects_outputs
--compilation_mode=<fastbuild, dbg or opt>
[-c
] डिफ़ॉल्ट: "Fastbuild"-
वह मोड तय करें जिसमें बाइनरी बनाई जाएगी. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग:affects_outputs
,action_command_lines
,explicit_in_output_path
- ऐप्लिकेशन के
--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
,explicit_in_output_path
--cs_fdo_absolute_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करके, कंपाइलेशन ऑप्टिमाइज़ करें. उस ZIP फ़ाइल के पूरे पाथ का नाम बताएं जिसमें प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल मौजूद हो.
टैग:affects_outputs
--cs_fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कॉन्टेक्स्ट के हिसाब से संवेदनशील एफ़डीओ इंस्ट्रुमेंटेशन वाली बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान हटाया जाएगा.
टैग:affects_outputs
--cs_fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली कॉन्टेक्स्ट सेंसिटिव प्रोफ़ाइल को दिखाने वाली cs_fdo_profile.
टैग:affects_outputs
- ऐप्लिकेशन के
--cxxopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--define=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
हर --define का विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है.
टैग:changes_inputs
,affects_outputs
--dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
यह तय करता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel यह चुनेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तौर पर लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:loading_and_analysis
,affects_outputs
--[no]enable_fdo_profile_absolute_path
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है, तो fdo_absolute_profile_path के इस्तेमाल पर गड़बड़ी हो सकती है.
टैग:affects_outputs
--[no]enable_runfiles
डिफ़ॉल्ट: "ऑटो"-
रनफ़ाइल सिमलिंक ट्री चालू करें. डिफ़ॉल्ट रूप से, यह Windows और दूसरे प्लैटफ़ॉर्म पर बंद होता है.
टैग:affects_outputs
- ऐप्लिकेशन के
--experimental_action_listener=<a build target label>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अलग-अलग पहलुओं के पक्ष में नहीं दिखाया गया. मौजूदा बिल्ड ऐक्शन में extra_action अटैच करने के लिए, action_listener का इस्तेमाल करें.
टैग:execution
,experimental
--[no]experimental_android_compress_java_resources
डिफ़ॉल्ट: "false"-
APK में Java रिसॉर्स को कंप्रेस करें
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_android_databinding_v2
डिफ़ॉल्ट: "false"-
Android databinding v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_android_resource_shrinking
डिफ़ॉल्ट: "false"-
यह सुविधा, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन को कम करने की सुविधा चालू करती है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex
डिफ़ॉल्ट: "false"-
डेक्स फ़ाइलों को फिर से लिखने के लिए रेक्स टूल का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--experimental_objc_fastbuild_options=<comma-separated list of options>
डिफ़ॉल्ट: "-O0,-DDEBUG=1"-
इन स्ट्रिंग का इस्तेमाल, objc फ़ास्ट बिल्ड कंपाइलर विकल्पों के तौर पर करता है.
टैग:action_command_lines
--[no]experimental_omitfp
डिफ़ॉल्ट: "false"-
अगर सही है, तो स्टैक अनवाइंड करने के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables की मदद से कंपाइल करें.
टैग:action_command_lines
,affects_outputs
,experimental
--[no]experimental_platform_in_output_dir
डिफ़ॉल्ट: "false"-
सही होने पर, टारगेट प्लैटफ़ॉर्म का इस्तेमाल सीपीयू के बजाय आउटपुट डायरेक्ट्री के नाम में किया जाता है.
टैग:affects_outputs
,experimental
--[no]experimental_use_llvm_covmap
डिफ़ॉल्ट: "false"-
अगर इसके बारे में बताया गया है, तो collections_code_coverage की सुविधा चालू होने पर Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
,experimental
--fat_apk_cpu=<comma-separated list of options>
डिफ़ॉल्ट: "armeabi-v7a"-
इस विकल्प को सेट करने पर, फ़ैट वाले ऐसे APKs चालू हो जाते हैं जिनमें तय किए गए सभी टारगेट आर्किटेक्चर के लिए नेटिव बाइनरी होती हैं. उदाहरण के लिए, --fat_apk_cpu=x86,armeabi-v7a. अगर इस फ़्लैग को तय किया गया है, तो android_binary नियमों की डिपेंडेंसी के लिए --android_cpu को अनदेखा किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]fat_apk_hwasan
डिफ़ॉल्ट: "false"-
HWASAN स्प्लिट बनाने हैं या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान हटाया जाएगा.
टैग:affects_outputs
--fdo_optimize=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कॉम्प्लेक्सेशन ऑप्टिमाइज़ करने के लिए एफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री हो, कोई ऑटो प्रोफ़ाइल वाली afdo फ़ाइल हो या कोई LLVM प्रोफ़ाइल फ़ाइल दी गई हो. यह फ़्लैग उन फ़ाइलों को भी स्वीकार करता है जिन्हें लेबल के तौर पर बताया गया है (जैसे कि `//foo/bar:file.afdo` - आपको इससे जुड़े पैकेज में `exports_files` डायरेक्टिव जोड़ना पड़ सकता है. साथ ही, `fdo_profile` टारगेट को पॉइंट करने वाले लेबल भी लागू हो सकते हैं. इस फ़्लैग को `fdo_profile` नियम के तहत हटा दिया जाएगा.
टैग:affects_outputs
--fdo_prefetch_hints=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कैश मेमोरी प्रीफ़ेच संकेतों का इस्तेमाल करें.
टैग:affects_outputs
--fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली प्रोफ़ाइल को दिखाने वाली fdo_profile.
टैग:affects_outputs
- ऐप्लिकेशन के
--features=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
ये सुविधाएं, सभी पैकेज के लिए डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> को लागू करने पर, यह सुविधा दुनिया भर में बंद हो जाएगी. नेगेटिव सुविधाएं, हमेशा पॉज़िटिव सुविधाओं को बदल देती हैं. इस फ़्लैग का इस्तेमाल, Bazel रिलीज़ के बिना, डिफ़ॉल्ट सुविधाओं में बदलावों को रोल आउट करने के लिए किया जाता है.
टैग:changes_inputs
,affects_outputs
--[no]force_pic
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") देते हैं. लिंक, बिना पीआईसी लाइब्रेरी के बजाय, पीआईसी में पहले से बनी लाइब्रेरी को प्राथमिकता देते हैं. साथ ही, लिंक पोज़िशन पर निर्भर एक्ज़िक्यूटेबल ("-पाई") बनाते हैं.
टैग:loading_and_analysis
,affects_outputs
- ऐप्लिकेशन के
--host_action_env=<a 'name=value' assignment with an optional value part>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट या एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, वैल्यू को शुरू करने वाले एनवायरमेंट या नाम=वैल्यू के जोड़े से लिया जाएगा. इस पेयर की मदद से वैल्यू को, शुरू करने वाले एनवायरमेंट से अलग सेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, सबसे नई जीत, अलग-अलग वैरिएबल के लिए उपलब्ध विकल्प.
टैग:action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt>
डिफ़ॉल्ट: "ऑप्ट"-
उस मोड के बारे में बताएं जिसमें बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल का इस्तेमाल किया जाएगा. वैल्यू: 'Fastbuild', 'dbg', 'opt'.
टैग:affects_outputs
,action_command_lines
- ऐप्लिकेशन के
--host_conlyopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--host_copt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए जीसीसी को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_cpu=<a string>
डिफ़ॉल्ट: ""-
होस्ट के लिए सीपीयू.
टैग:changes_inputs
,affects_outputs
- ऐप्लिकेशन के
--host_cxxopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए जीसीसी को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_force_python=<PY2 or PY3>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट कॉन्फ़िगरेशन के लिए 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 भी देखें. यह विकल्प_1 से Option_n का मतलब, आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, बार.cc को छोड़कर //foo/ में सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--host_swiftcopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
होस्ट टूल के लिए, swiftc को पास करने के ज़्यादा विकल्प.
टैग:action_command_lines
,affects_outputs
--[no]incompatible_avoid_conflict_dlls
डिफ़ॉल्ट: "सही"-
इस सेटिंग को चालू करने पर, Windows पर cc_library से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (डीएलएल) का नाम बदलकर name_{hash}.dll कर दिया जाएगा. यहां हैश का हिसाब RepositoryName और DLL के पैकेज पाथ के आधार पर लगाया जाता है. यह विकल्प तब फ़ायदेमंद होता है, जब आपके पास एक ऐसा पैकेज हो जो एक ही नाम वाली कई cc_library पर निर्भर करता हो (जैसे कि //foo/bar1:utils और //foo/bar2:utils).
टैग:loading_and_analysis
,affects_outputs
,incompatible_change
--[no]incompatible_merge_genfiles_directory
डिफ़ॉल्ट: "सही"-
सही होने पर, जनरेट फ़ाइल डायरेक्ट्री को बिन डायरेक्ट्री में फ़ोल्ड किया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_use_platforms_repo_for_constraints
डिफ़ॉल्ट: "सही"-
सही होने पर, @bazel_tools की कंस्ट्रेंट सेटिंग हटा दी जाती हैं.
टैग:affects_outputs
,incompatible_change
--[no]instrument_test_targets
डिफ़ॉल्ट: "false"-
कवरेज चालू होने पर, यह तय किया जाता है कि टेस्ट के नियमों को ध्यान में रखना है या नहीं. सेट किए जाने पर, --instrumentation_filter में शामिल किए गए टेस्ट के नियम लागू होते हैं. नहीं तो, जांच के नियमों को कवरेज इंस्ट्रुमेंटेशन से हमेशा बाहर रखा जाता है.
टैग:affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-/javatest[/:],-/test/java[/:]"-
कवरेज चालू होने पर, सिर्फ़ वही नियम लागू किए जाएंगे जिनके नाम, रेगुलर एक्सप्रेशन पर आधारित फ़िल्टर के ज़रिए शामिल किए गए हों. इसके बजाय, '-' से शुरू वाले नियमों को शामिल नहीं किया जाता. ध्यान रखें कि जब तक --instrument_test_targets को चालू नहीं किया जाता, तब तक सिर्फ़ गैर-टेस्ट नियम लागू किए जाते हैं.
टैग:affects_outputs
--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाला iOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'ios_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
- ऐप्लिकेशन के
--ios_multi_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
iOS_application बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट. नतीजा एक यूनिवर्सल बाइनरी है, जिसमें सभी तय आर्किटेक्चर शामिल हैं.
टैग:loses_incremental_state
,loading_and_analysis
--[no]legacy_whole_archive
डिफ़ॉल्ट: "सही"-
अब काम नहीं करता, इसकी जगह --insupported_remove_Legacy_whole_archive (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7362 देखें). इस सेटिंग के चालू होने पर, cc_binary के उन नियमों के लिए --whole-archive का इस्तेमाल करें जिनमें linkshared=True शामिल है. साथ ही, linkopts में linkstatic=True या '-static' का इस्तेमाल किया जाता है. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. जहां ज़रूरी हो, वहां क्लिक के लिए हमेशा लिंक=1 का इस्तेमाल करें. यह एक अच्छा विकल्प है.
टैग:action_command_lines
,affects_outputs
,deprecated
- ऐप्लिकेशन के
--linkopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--ltobackendopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
एलटीओ बैकएंड चरण को पास करने का अन्य विकल्प (--features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--ltoindexopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
एलटीओ इंडेक्स करने के चरण को पास करने का अन्य विकल्प (-features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--macos_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Apple macOS की बाइनरी बनाने के लिए, आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट.
टैग:loses_incremental_state
,loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट के लिए, कम से कम काम करने वाले macOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--[no]objc_debug_with_GLIBCXX
डिफ़ॉल्ट: "false"-
अगर यह सेट है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को परिभाषित करें.
टैग:action_command_lines
--[no]objc_enable_binary_stripping
डिफ़ॉल्ट: "false"-
लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिप करना है या नहीं. अगर यह फ़्लैग और --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 भी देखें. यह विकल्प_1 से Option_n का मतलब, आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ बार.cc को छोड़कर सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
- ऐप्लिकेशन के
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड (--features=thin_lto के तहत) को अपनी पसंद के हिसाब से पास करने के ज़्यादा विकल्प. इस विकल्प को कई बार इस्तेमाल किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल करने और रेगुलर एक्सप्रेशन पैटर्न को शामिल करने की सूची से है. इसके अलावा, Option_1 से Option_n विकल्प का मतलब आर्बिट्रेरी कमांड लाइन के विकल्पों से है. अगर किसी विकल्प में कॉमा लगा है, तो उसे बैकस्लैश से कोट किया जाना चाहिए. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0 //foo/ को छोड़कर bar.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>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, प्रोपेलर प्रोफ़ाइल की जानकारी का इस्तेमाल करें.प्रोपेलर प्रोफ़ाइल में दो फ़ाइलों में से कम से कम एक फ़ाइल, cc प्रोफ़ाइल और ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल स्वीकार करता है, जो प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, लेबल को परिभाषित करने वाली BUILD फ़ाइल जो कि लेबल को परिभाषित करती है, a/b/BUILD:खरीददारी_ऑप्टिमाइज़( name = " सेटिंग्स_profile", cc_profile = " रूपरेखा_cc_profile.txt", ld_profile = " सेटिंग्स_ld_profile.txt",) एनजीएल फ़ाइल्स निर्देश को संबंधित पैकेज में जोड़ना पड़ सकता है, ताकि ये फ़ाइलें Bazel को दिख सकें. विकल्प का इस्तेमाल इस तौर पर किया जाना चाहिए: --propler_optimize=//a/b:PROpelलर_profile
टैग:action_command_lines
,affects_outputs
--propeller_optimize_absolute_cc_profile=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Propiller ऑप्टिमाइज़ किए गए बिल्ड के लिए 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
-
सही होने पर, एक जैसी काम करने वाली नेटिव लाइब्रेरी अलग-अलग टारगेट के बीच शेयर की जाएंगी
टैग:loading_and_analysis
,affects_outputs
--[no]stamp
डिफ़ॉल्ट: "false"-
स्टैंप बाइनरी जिनमें तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह शामिल है.
टैग: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
- ऐप्लिकेशन के
--watchos_cpus=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
कॉमा लगाकर अलग की गई आर्किटेक्चर की सूची, जिसके लिए Apple WatchOS बाइनरी बनानी हैं.
टैग:loses_incremental_state
,loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम काम करने वाले WatchOS वर्शन. अगर जानकारी उपलब्ध नहीं है, तो 'watchos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--xbinary_fdo=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपलेशन ऑप्टिमाइज़ करने के लिए, XbinaryFDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम बताएं. जब इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile/ के साथ किया जाता है, तब ये विकल्प हमेशा लागू होते हैं, जैसे कि xbinary_fdo के बारे में कभी जानकारी न दी गई हो.
टैग:affects_outputs
- Bzel के मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--auto_cpu_environment_group=<a build target label>
डिफ़ॉल्ट: ""-
Environment_group का एलान करें, ताकि target_environment वैल्यू के लिए सीपीयू वैल्यू को अपने-आप मैप करने के लिए, उसका इस्तेमाल किया जा सके.
टैग:changes_inputs
,loading_and_analysis
,experimental
--[no]check_licenses
डिफ़ॉल्ट: "false"-
जांचें कि डिपेंडेंट पैकेज की तय की गई लाइसेंस से जुड़ी सीमाएं, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर न डालें. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती.
टैग: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
डिफ़ॉल्ट: "false"-
लेगसी डिवाइसों के लिए, ऐप्लिकेशन में Java 8 लाइब्रेरी शामिल करनी है या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]enforce_constraints
डिफ़ॉल्ट: "सही"-
यह जांच करता है कि हर टारगेट, किन एनवायरमेंट के साथ काम करता है. साथ ही, अगर कोई टारगेट ऐसी डिपेंडेंसी है जो एक जैसे एनवायरमेंट के साथ काम नहीं करती, तो गड़बड़ियों की रिपोर्ट करता है
टैग:build_file_semantics
--[no]experimental_allow_android_library_deps_without_srcs
डिफ़ॉल्ट: "false"-
deps के साथ srcs-less android_library नियमों को अस्वीकार करने की अनुमति देने से ट्रांज़िशन में मदद करने के लिए फ़्लैग करें. डिफ़ॉल्ट रूप से इसे रोल आउट करने के लिए डिपो को साफ़ करना ज़रूरी है.
टैग:eagerness_to_exit
,loading_and_analysis
--[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
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, आउटपुट फ़ाइल वाले ज़रूरी टारगेट के लिए सिर्फ़ testonly चुनें. इसके लिए, सिर्फ़ जनरेट करने वाले नियम का टेस्ट देखें. यह 'किसको दिखे' सेटिंग से मेल खाता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disable_native_android_rules
डिफ़ॉल्ट: "false"-
चालू होने पर, Android के मूल नियमों का सीधे इस्तेमाल करने की सुविधा बंद हो जाती है. कृपया https://github.com/bazelbuild/मॉडल_android से Starlark Android के नियमों का इस्तेमाल करें
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_disable_native_apple_binary_rule
डिफ़ॉल्ट: "false"-
पुराने सिस्टम के साथ काम करने की सुविधा के लिए, इसे यहां रखा गया है.
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_force_strict_header_check_from_starlark
डिफ़ॉल्ट: "सही"-
अगर चालू है, तो Starlark API में हेडर की सख्त जांच सेट करें
टैग:loading_and_analysis
,changes_inputs
,incompatible_change
--[no]incompatible_validate_top_level_header_inclusions
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, टॉप लेवल डायरेक्ट्री के हेडर शामिल करने की भी पुष्टि करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10047 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]strict_filesets
डिफ़ॉल्ट: "false"-
अगर यह विकल्प चालू किया जाता है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है. यह Check_fileset_dependencies_recursively को बंद करने पर काम नहीं करता है.
टैग: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
डिफ़ॉल्ट: "false"-
अगर सही है, तो सिस्टम से मिलने वाले हेडर में पाथ (-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 भाषा के सिमैंटिक या उस बिल्ड एपीआई को इस्तेमाल करने पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]incompatible_disallow_legacy_py_provider
डिफ़ॉल्ट: "सही"-
नहीं, इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
,incompatible_change
- टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:
--[no]allow_analysis_failures
डिफ़ॉल्ट: "false"-
सही होने पर, टारगेट किए गए किसी नियम का विश्लेषण नहीं हो पाता है. ऐसा होने पर, टारगेट के तहत किसी ऐसी स्थिति का विश्लेषण हो जाता है जिसमें गड़बड़ी की जानकारी होती है. इस वजह से, बिल्ड फ़ेल हो जाता है.
टैग:loading_and_analysis
,experimental
--analysis_testing_deps_limit=<an integer>
डिफ़ॉल्ट: "2000"-
for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ नियम एट्रिब्यूट की मदद से, ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा को पार करने से नियम में गड़बड़ी होगी.
टैग:loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure
डिफ़ॉल्ट: "false"-
अगर सही dex2oat कार्रवाई पूरी नहीं हो पाती है, तो टेस्ट रनटाइम के दौरान dex2oat को चलाने के बजाय बिल्ड टूट जाएगा.
टैग:loading_and_analysis
,experimental
--[no]experimental_android_use_parallel_dex2oat
डिफ़ॉल्ट: "false"-
android_test को तेज़ करने के लिए dex2oat का साथ-साथ इस्तेमाल करें.
टैग:loading_and_analysis
,host_machine_resource_optimizations
,experimental
--[no]ios_memleaks
डिफ़ॉल्ट: "false"-
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>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में जानकारी देता है. वैरिएबल को नाम से तय किया जा सकता है. इस स्थिति में, इसकी वैल्यू को Bazel क्लाइंट एनवायरमेंट या name=value पेयर से पढ़ा जाएगा. कई वैरिएबल तय करने के लिए, इस विकल्प का इस्तेमाल कई बार किया जा सकता है. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
टैग:test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers>
डिफ़ॉल्ट: "-1"- जांच के टाइम आउट होने के समय की डिफ़ॉल्ट वैल्यू को बदलें (सेकंड में). अगर एक पॉज़िटिव पूर्णांक मान दिया गया है, तो वह सभी कैटगरी को बदल देगा. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे छोटे, मध्यम, लंबे, और हमेशा के लिए (इसी क्रम में) टाइम आउट को बदल देंगे. किसी भी रूप में, -1 की वैल्यू ब्लेज़ को उस कैटगरी के लिए अपने डिफ़ॉल्ट टाइम आउट का इस्तेमाल करने का निर्देश देती है.
--tvos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में किसी tvOS ऐप्लिकेशन को चलाते समय, सिम्युलेट करने वाला डिवाइस, जैसे कि 'Apple TV 1080p'. जिस मशीन पर सिम्युलेटर चलाया जाएगा उस पर 'xcrun SIMctl list devicetypes' चलाकर आप डिवाइस की एक सूची पा सकते हैं.
टैग:test_runner
--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
चलाते या टेस्ट करते समय, सिम्युलेटर पर चलने वाला tvOS का वर्शन.
टैग:test_runner
--watchos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में WatchOS ऐप्लिकेशन चलाते समय सिम्युलेट किया जाने वाला डिवाइस, जैसे कि 'Apple Watch - 38mm'. जिस मशीन पर सिम्युलेटर चलाया जाएगा उस पर 'xcrun SIMctl list devicetypes' चलाकर आप डिवाइस की एक सूची पा सकते हैं.
टैग:test_runner
--watchos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
दौड़ने या टेस्ट करने के दौरान, सिम्युलेटर पर चलने के लिए WatchOS का वर्शन.
टैग:test_runner
--[no]zip_undeclared_test_outputs
डिफ़ॉल्ट: "सही"-
अगर सही है, तो नहीं बताए गए टेस्ट आउटपुट ZIP फ़ाइल में संग्रहित किए जाएंगे.
टैग:test_runner
- क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:
--aspect_deps=<off, conservative or precise>
डिफ़ॉल्ट: "कंज़र्वेटिव"-
जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तो आसपेक्ट डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि तय की गई सभी पहलू डिपेंडेंसी जोड़ी जाती हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के नियम की कैटगरी दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम की क्लास के आधार पर ऐक्टिव होते हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट की जांच करने के लिए, अन्य पैकेज लोड करने ज़रूरी होते हैं. इस वजह से, यह अन्य मोड की तुलना में धीमा हो जाता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता है: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह प्रोसेस, 'bazel क्वेरी' के दौरान नहीं चलती.
टैग:build_file_semantics
--[no]graph:factored
डिफ़ॉल्ट: "सही"-
सही होने पर, ग्राफ़ पर 'फ़ैक्टर' निकाला जाएगा. इसका मतलब है कि टॉपॉलॉजिकली इक्विलंट नोड को आपस में मर्ज कर दिया जाएगा और उनके लेबल जोड़ दिए जाएंगे. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--graph:node_limit=<an integer>
डिफ़ॉल्ट: "512"-
आउटपुट में, ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि कोई काट-छांट नहीं की जाएगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--[no]implicit_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, इंप्लिसिट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएगी जिस पर क्वेरी ऑपरेट होती है. इंप्लिसिट डिपेंडेंसी वह है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel के ज़रिए जोड़ा गया है. cquery के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग:build_file_semantics
--[no]include_aspects
डिफ़ॉल्ट: "सही"-
क्वेरी, cquery: आउटपुट में पक्ष से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (निर्देशों को हमेशा अपनाया जाता है).
टैग:terminal_output
--[no]incompatible_display_source_file_location
डिफ़ॉल्ट: "सही"-
डिफ़ॉल्ट रूप से 'सही', सोर्स फ़ाइल का टारगेट दिखाता है. सही होने पर, लोकेशन आउटपुट में सोर्स फ़ाइलों की लाइन 1 की जगह दिखाता है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग:terminal_output
,incompatible_change
--[no]incompatible_package_group_includes_double_slash
डिफ़ॉल्ट: "सही"-
इस सुविधा को चालू करने पर, Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, पहले `//` की वैल्यू नहीं छोड़ी जाएगी.
टैग:terminal_output
,incompatible_change
--[no]infer_universe_scope
डिफ़ॉल्ट: "false"-
अगर सेट और --universe_scope को सेट नहीं किया जाता है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे कि`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई --universe_scope वैल्यू, शायद आपकी पसंद के मुताबिक न हो. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/query/language#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` (जैसे कि `cquery` पर नहीं) पर लागू होता है.
टैग:loading_and_analysis
--[no]line_terminator_null
डिफ़ॉल्ट: "false"-
हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाए या नहीं.
टैग:terminal_output
--[no]nodep_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, "nodep" एट्रिब्यूट की वैल्यू को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा, जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडेप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग:build_file_semantics
--output=<a string>
डिफ़ॉल्ट: "लेबल"-
वह फ़ॉर्मैट जिसमें cquery नतीजे प्रिंट किए जाने चाहिए. cquery के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: label, label_ kind, textproto, ट्रांज़िशन, proto, jsonproto. अगर आपने 'ट्रांज़िशन' चुना है, तो आपको --transitions=(lite|full) विकल्प भी बताना होगा.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग:terminal_output
पर लागू होता है
--[no]proto:definition_stack
डिफ़ॉल्ट: "false"-
definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें, जो नियम की क्लास तय किए जाने के समय Starlark कॉल स्टैक के हर नियम के लिए रिकॉर्ड करता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, Select() के ज़रिए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट फ़्लैट कर दिए जाते हैं. सूची के टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन वह सूची है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप शून्य तक चपटे हो जाते हैं.
टैग:build_file_semantics
--[no]proto:include_configurations
डिफ़ॉल्ट: "सही"-
चालू होने पर, प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. बंद होने पर, cquery Proto आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.
टैग:affects_outputs
--[no]proto:include_synthetic_attribute_hash
डिफ़ॉल्ट: "false"- $internal_attr_hh एट्रिब्यूट का हिसाब लगाने और उसे पॉप्युलेट करने या न करने का विकल्प.
टैग:terminal_output
--[no]proto:instantiation_stack
डिफ़ॉल्ट: "false"-
हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग:terminal_output
--[no]proto:locations
डिफ़ॉल्ट: "सही"-
प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग:terminal_output
--proto:output_rule_attrs=<comma-separated list of options>
डिफ़ॉल्ट: "सभी"-
आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. किसी भी एट्रिब्यूट का आउटपुट न देने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --OUT=proto पर लागू होता है.
टैग:terminal_output
--[no]proto:rule_inputs_and_outputs
डिफ़ॉल्ट: "सही"-
रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग:terminal_output
--[no]relative_locations
डिफ़ॉल्ट: "false"-
सही होने पर, एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह तय होगी. डिफ़ॉल्ट रूप से, लोकेशन आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग:terminal_output
--show_config_fragments=<off, direct or transitive>
डिफ़ॉल्ट: "बंद"-
किसी नियम के लिए ज़रूरी कॉन्फ़िगरेशन फ़्रैगमेंट और उसकी ट्रांज़िटिव डिपेंडेंसी दिखाता है. इससे, यह आकलन करने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ में कितनी काट-छांट की जा सकती है.
टैग:affects_outputs
--starlark:expr=<a string>
डिफ़ॉल्ट: ""-
कॉन्फ़िगर किए गए हर टारगेट को cquery के --port=starlark मोड में फ़ॉर्मैट करने के लिए, Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट, 'टारगेट' से जुड़ा है. अगर --starlark:expr या --starlark:file मौजूद नहीं है. हालांकि, यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट होगा. --starlark:expr और --starlark:file दोनों देना एक गड़बड़ी है.
टैग:terminal_output
--starlark:file=<a string>
डिफ़ॉल्ट: ""-
Starlark के 'फ़ॉर्मैट' नाम की फ़ाइल का नाम. यह एक आर्ग्युमेंट का नाम है. यह फ़ाइल, कॉन्फ़िगर किए गए हर टारगेट पर लागू होती है, ताकि कॉन्टेंट को स्ट्रिंग के तौर पर फ़ॉर्मैट किया जा सके. --starlark:expr और --starlark:file दोनों देना एक गड़बड़ी है. ज़्यादा जानकारी के लिए --आउटपुट=स्टारलार्क के लिए सहायता देखें.
टैग:terminal_output
--[no]tool_deps
डिफ़ॉल्ट: "सही"-
क्वेरी: बंद होने पर, 'होस्ट कॉन्फ़िगरेशन' या 'एक्ज़ीक्यूशन' टारगेट की डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाता जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर को मिलने वाला किनारा. आम तौर पर, यह उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, उस टूल के बारे में बताता है जिसे बिल्ड के दौरान लागू किया जाता है.
Cquery: बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट का पता लगाने वाले टॉप लेवल टारगेट से, होस्ट या एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. साथ ही, टारगेट कॉन्फ़िगरेशन में भी कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट ही दिखेंगे. इस विकल्प में, ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग:build_file_semantics
--transitions=<full, lite or none>
डिफ़ॉल्ट: "कोई नहीं"-
वह फ़ॉर्मैट जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगा.
टैग:affects_outputs
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का सेट, कॉमा लगाकर अलग किया गया. इसमें योग और घटाव वाले पैटर्न शामिल होते हैं. क्वेरी को संसार में निष्पादित किया जा सकता है, जबकि बताए गए लक्ष्यों के ट्रांज़िटिव बंद होने से परिभाषित होता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है.
cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब तैयार किए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट मान लिया जाता है. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए इस विकल्प को तय न करने से बिल्ड टूट सकता है.
टैग:loading_and_analysis
- बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प:
--[no]collapse_duplicate_defines
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, गैर-ज़रूरी --परिभाषाओं को बिल्ड की शुरुआत में ही हटा दिया जाएगा. इससे कुछ खास तरह के मिलते-जुलते बिल्ड के लिए, विश्लेषण की कैश मेमोरी को होने वाले नुकसान से बचा जा सकता है.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_filter_library_jar_with_program_jar
डिफ़ॉल्ट: "false"-
LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए ProGuard ProgramJar को फ़िल्टर करें.
टैग:action_command_lines
--[no]experimental_inmemory_dotd_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, C++ .d फ़ाइलों को मेमोरी में, डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से पास किया जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_inmemory_jdeps_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_objc_include_scanning
डिफ़ॉल्ट: "false"-
मकसद C/C++ के लिए स्कैन करना है या नहीं.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]experimental_parse_headers_skipped_if_corresponding_srcs_found
डिफ़ॉल्ट: "false"-
यह सुविधा चालू होने पर, अगर एक ही टारगेट में एक जैसे बेसनेम वाला सोर्स मिलता है, तो parse_headers सुविधा अलग से हेडर कंपाइलेशन ऐक्शन नहीं बनाती.
टैग:loading_and_analysis
,affects_outputs
--[no]experimental_retain_test_configuration_across_testonly
डिफ़ॉल्ट: "false"-
चालू होने पर, --trim_test_ Configuration, testonly=1 के तौर पर मार्क किए गए नियमों के लिए, टेस्ट कॉन्फ़िगरेशन को ट्रिम नहीं करेगा. इसका मकसद, कार्रवाई से जुड़े विवाद से जुड़ी समस्याओं को कम करना है. ऐसा तब किया जाता है, जब जांच न करने वाले नियम cc_test पर निर्भर होते हैं. --trim_test_Configuration गलत होने पर कोई असर नहीं होगा.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_starlark_cc_import
डिफ़ॉल्ट: "false"-
अगर चालू हो, तो cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग:loading_and_analysis
,experimental
--[no]experimental_unsupported_and_brittle_include_scanning
डिफ़ॉल्ट: "false"-
इनपुट फ़ाइलों से #include पंक्तियों को पार्स करके, C/C++ कंपाइलेशन में इनपुट को सीमित करना है या नहीं. यह कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और बढ़ोतरी को बेहतर बना सकता है. हालांकि, इससे बिल्ड खराब भी हो सकते हैं, क्योंकि शामिल स्कैनर, C प्रीप्रोसेसर सिमैंटिक को पूरी तरह लागू नहीं करता. खास तौर पर, यह डाइनैमिक #इन्क्लूसिव निर्देशों को नहीं समझता और प्रीप्रोसेसर कंडिशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी जो भी समस्याएं फ़ाइल की जाती हैं वे बंद हो जाएंगी.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]incremental_dexing
डिफ़ॉल्ट: "सही"-
क्या हर Jar फ़ाइल के लिए, ज़्यादातर काम अलग-अलग तरीके से किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]objc_use_dotd_pruning
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है, तो clang से उत्सर्जित होने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइलेशन में पास किए गए इनपुट के सेट को हटाने के लिए किया जाएगा.
टैग:changes_inputs
,loading_and_analysis
--[no]process_headers_in_dependencies
डिफ़ॉल्ट: "false"-
टारगेट //a:a बनाते समय, उन सभी टारगेट के हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू है).
टैग:execution
--[no]trim_test_configuration
डिफ़ॉल्ट: "सही"-
चालू होने पर, जांच से जुड़े विकल्प, बिल्ड के टॉप लेवल से नीचे हटा दिए जाएंगे. यह फ़्लैग चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, गैर-टेस्टिंग नियमों का फिर से विश्लेषण नहीं होगा.
टैग:loading_and_analysis
,loses_incremental_state
--[no]use_singlejar_apkbuilder
डिफ़ॉल्ट: "सही"-
इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. अब इस पर कोई कार्रवाई नहीं की जा सकती. इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
- ऐसे विकल्प जो जानकारी डालने की जगह, फ़ॉर्मैट या जगह की जानकारी पर असर डालते हैं:
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-.*"-
टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. फ़्लैग, रेगुलर एक्सप्रेशन को इस्तेमाल करता है. इसकी जांच टूलचेन टाइप और चुनिंदा टारगेट से की जाती है, ताकि यह पता लगाया जा सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल है और हो सकता है कि यह सिर्फ़ टूलचेन रिज़ॉल्यूशन में माहिर विशेषज्ञों के लिए ही काम का हो.
टैग:terminal_output
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
- ऐप्लिकेशन के
--flag_alias=<a 'name=value' flag alias>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
स्टारलार्क फ़्लैग के लिए एक शॉर्टहैंड नाम सेट करता है. यह एक तर्क के रूप में "<key>=<value>" रूप में एक की-वैल्यू पेयर लेता है.
टैग:changes_inputs
--[no]incompatible_default_to_explicit_init_py
डिफ़ॉल्ट: "false"-
यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि Python टारगेट की रनफ़ाइल में __init__.py फ़ाइलें अपने-आप न बने. आम तौर पर, जब किसी py_binary या py_test टारगेट मेंLegacy_create_init "अपने आप" (डिफ़ॉल्ट) पर सेट होती है, तो इस फ़्लैग के सेट होने पर ही गलत माना जाता है. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py2_outputs_are_suffixed
डिफ़ॉल्ट: "सही"-
अगर सही होता है, तो Python 2 कॉन्फ़िगरेशन में बनाए गए टारगेट आउटपुट रूट में दिखेंगे, जिसमें सफ़िक्स '-py2' होगा, जबकि Python 3 के लिए बनाए गए टारगेट रूट में दिखेंगे और Python से जुड़े सफ़िक्स के नहीं होंगे. इसका मतलब है कि `bazel-bin` सुविधा वाला सिमलिंक, Python 2 के बजाय Python 3 टारगेट को पॉइंट करेगा. अगर इस विकल्प को चालू किया जाता है, तो `--insupported_py3_is_default` को चालू करने का भी सुझाव दिया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py3_is_default
डिफ़ॉल्ट: "सही"-
सही होने पर, `py_binary` और `py_test` टारगेट जो अपना `python_version` (या `default_python_version`) सेट नहीं करते, तो वे डिफ़ॉल्ट रूप से PY2 के बजाय PY3 पर सेट हो जाएंगे. अगर इस फ़्लैग को सेट किया जाता है, तो आपको `--insupported_py2_OUTs_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
,explicit_in_output_path
- दूसरे विकल्प, जिन्हें अलग से कैटगरी में नहीं बांटा गया है.:
--[no]cache_test_results
[-t
] डिफ़ॉल्ट: "ऑटो"- अगर स्थिति को 'अपने-आप' पर सेट किया जाता है, तो Bazel फिर से जांच तब करता है, जब: (1) Bazel को जांच में हुए बदलावों का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया जाता है, (3) --runs_per_test की मदद से कई टेस्ट चलाने का अनुरोध किया जाता है या(4) जांच पहले असफल हो जाती है. अगर इस नीति को 'हां' पर सेट किया जाता है, तो बाहरी के तौर पर मार्क किए गए टेस्ट के अलावा, Bazel जांच के सभी नतीजों को कैश मेमोरी में सेव कर लेता है. अगर इसे 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी जांच के नतीजे को कैश मेमोरी में सेव नहीं करेगा.
--[no]experimental_cancel_concurrent_tests
डिफ़ॉल्ट: "false"-
सही होने पर, Blaze पहले कभी भी किए जाने वाले टेस्ट को रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ कॉम्बिनेशन में इस्तेमाल किया जाता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_fetch_all_coverage_outputs
डिफ़ॉल्ट: "false"-
अगर सही है, तो बैजल कवरेज के दौरान हर टेस्ट के लिए, पूरी कवरेज डेटा डायरेक्ट्री फ़ेच करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_generate_llvm_lcov
डिफ़ॉल्ट: "false"-
अगर सही है, तो क्लैग के लिए कवरेज से एलसीओवी रिपोर्ट जनरेट होगी.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_j2objc_header_map
डिफ़ॉल्ट: "सही"- क्या आपको J2ObjC ट्रांसपिलेशन के साथ-साथ J2ObjC हेडर मैप जनरेट करना है.
--[no]experimental_j2objc_shorter_header_path
डिफ़ॉल्ट: "false"-
छोटे हेडर पाथ के साथ जनरेट करना है या नहीं ("_j2objc" के बजाय "_ios" का इस्तेमाल करता है).
टैग:affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel>
डिफ़ॉल्ट: "javaBuilder"- यह सुविधा, Java कंपाइलेशन के लिए कम किए गए क्लासपाथ चालू करती है.
--[no]experimental_limit_android_lint_to_android_constrained_java
डिफ़ॉल्ट: "false"-
-इन्हें Android के साथ काम करने वाली लाइब्रेरी पर ही लागू करें.
टैग:affects_outputs
--[no]experimental_run_android_lint_on_java_rules
डिफ़ॉल्ट: "false"-
Java_* सोर्स की पुष्टि करनी है या नहीं.
टैग:affects_outputs
--[no]explicit_java_test_deps
डिफ़ॉल्ट: "false"- testरनर के डिप से गलती से जानकारी हासिल करने के बजाय, java_test में JUnit या Hamcrest के लिए डिपेंडेंसी साफ़ तौर पर बताएं. फ़िलहाल, यह सिर्फ़ बाज़ल के लिए काम करता है.
--host_java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- JavaScript का इस्तेमाल करने वाले टूल में इस्तेमाल किए जाने वाले टूल, बिल्ड के दौरान काम करते हैं.
- ऐप्लिकेशन के
--host_javacopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड के दौरान काम करने वाले टूल बनाते समय, Javac को पास करने के दूसरे विकल्प.
- ऐप्लिकेशन के
--host_jvmopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java वीएम को पास करने के दूसरे विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_exclusive_test_sandboxed
डिफ़ॉल्ट: "false"-
सही होने पर, सैंडबॉक्स रणनीति की मदद से खास टेस्ट चलाए जाएंगे. खास तौर पर स्थानीय स्तर पर टेस्ट चलाने के लिए 'लोकल' टैग जोड़ें
टैग:incompatible_change
--[no]incompatible_strict_action_env
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_LIBRARY_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से किसी एनवायरमेंट वैरिएबल को इनहेरिट करना है, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान रखें कि ऐसा करने से, शेयर की गई कैश मेमोरी का इस्तेमाल करने पर क्रॉस-उपयोगकर्ता कैश मेमोरी में सेव होने से रोका जा सकता है.
टैग:loading_and_analysis
,incompatible_change
- ऐप्लिकेशन के
--j2objc_translation_flags=<comma-separated list of options>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - J2ObjC टूल को पास करने के दूसरे विकल्प.
--java_debug
-
इसकी वजह से, JavaScript टेस्ट की Java वर्चुअल मशीन को जांच शुरू करने से पहले, JDWP का पालन करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार करना पड़ता है. इसमें -test_OUT=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>
डिफ़ॉल्ट: "8"- जावा भाषा का वर्शन
--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>
डिफ़ॉल्ट: ब्यौरा देखें- ऐसी क्लास की सूची जनरेट करने के लिए बाइनरी तय करता है जो लेगसी मल्टीडेक्स को कंपाइल करते समय मुख्य dex में होना चाहिए.
- ऐप्लिकेशन के
--plugin=<a build target label>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - बिल्ड में इस्तेमाल करने के लिए प्लगिन. फ़िलहाल, java_plugin के साथ काम करता है.
--proguard_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- यह बताता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना चाहिए.
--proto_compiler=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:protoc"-
प्रोटो-कंपाइलर का लेबल.
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_cc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain"-
proto_lang_toolchain() का लेबल जिसमें C++ Protos को कंपाइल करने का तरीका बताया गया है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
proto_lang_toolchain() का लेबल, जिसमें j2objc protos को कंपाइल करने का तरीका बताया गया है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_java=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"-
proto_lang_toolchain() का लेबल, जो Java Protos को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_javalite=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"-
proto_lang_toolchain() का लेबल, जो JavaLite Protos को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
- ऐप्लिकेशन के
--protocopt=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
प्रोटोबफ़ कंपाइलर को पास करने के ज़्यादा विकल्प.
टैग:affects_outputs
--[no]runs_per_test_detects_flakes
डिफ़ॉल्ट: "false"- सही होने पर, कोई भी शार्ड जिसमें कम से कम एक रन/अटैम पास होता है और कम से कम एक रन/अटैम फ़ेल होता है, उसे फ़्लेकी स्टेटस माना जाता है.
--shell_executable=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
Bzel के इस्तेमाल के लिए, एक्ज़ीक्यूटेबल शेल का ऐब्सलूट पाथ. अगर यह सेट नहीं है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को पहले Bazel सर्वर (जो कि Bazel सर्वर को स्टार्ट करता है) पर सेट किया जाता है, तो Bazel इसका इस्तेमाल करता है. अगर इनमें से कोई भी सेट नहीं है, तो Bazel, हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह पाथ उस ऑपरेटिंग सिस्टम पर निर्भर करता है जिस पर वह चलता है. Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash. ध्यान दें कि बैश के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी के बनने या रनटाइम के दौरान सिस्टम फ़ेल हो सकता है.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--test_arg=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - ऐसे अन्य विकल्प और तर्क तय करता है जिन्हें टेस्ट एक्ज़ीक्यूटेबल टेस्ट में पास किया जाना चाहिए. एक से ज़्यादा तर्क तय करने के लिए, एक से ज़्यादा बार इस्तेमाल किया जा सकता है. अगर कई टेस्ट किए जाते हैं, तो सभी को एक जैसे तर्क मिलेंगे. सिर्फ़ 'bazel test' निर्देश पर इस्तेमाल किया जाता है.
--test_filter=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- टेस्ट फ़्रेमवर्क पर भेजने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, जांच को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे बनाए गए टारगेट पर कोई असर नहीं पड़ता.
--test_result_expiration=<an integer>
डिफ़ॉल्ट: "-1"- यह विकल्प अब सेवा में नहीं है और इसका कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast
डिफ़ॉल्ट: "false"- टेस्ट रनर पर तेज़ी से फ़ॉरवर्ड नहीं किया जा सकता. पहली बार फ़ेल होने पर, टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit or disabled>
डिफ़ॉल्ट: "अश्लील"- टेस्टिंग की रणनीति तय करें: शार्डिंग का इस्तेमाल 'साफ़ तौर पर' करने के लिए, सिर्फ़ तब करें, जब 'sard_count' BUILD एट्रिब्यूट मौजूद हो. यह विकल्प 'बंद' है, क्योंकि इसमें कभी भी टेस्ट शार्डिंग नहीं होगी.
--tool_java_language_version=<a string>
डिफ़ॉल्ट: "8"- बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया जाने वाला 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
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- निर्देश के आउटपुट को कंट्रोल करने वाले विकल्प:
--[no]action_cache
डिफ़ॉल्ट: "false"-
कैश मेमोरी में डेटा को डंप करने की कार्रवाई.
टैग:bazel_monitoring
--[no]packages
डिफ़ॉल्ट: "false"-
डंप पैकेज कैश मेमोरी का कॉन्टेंट.
टैग:bazel_monitoring
--[no]rule_classes
डिफ़ॉल्ट: "false"-
डंप रूल क्लास.
टैग:bazel_monitoring
--[no]rules
डिफ़ॉल्ट: "false"-
डंप के नियम, जिनमें संख्या और मेमोरी के इस्तेमाल की जानकारी भी शामिल है (अगर मेमोरी ट्रैक की जाती है).
टैग:bazel_monitoring
--skyframe=<off, summary, count, deps or rdeps>
डिफ़ॉल्ट: "बंद"-
डंप स्काईफ़्रेम ग्राफ़: 'off', 'summary', 'count', 'deps' या 'rdeps'.
टैग:bazel_monitoring
--skykey_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: ".*"-
आउटपुट के लिए SkyKey नाम का रेगुलर एक्सप्रेशन फ़िल्टर. इसका इस्तेमाल सिर्फ़ --skyframe=deps, rdeps के साथ किया जाता है.
टैग:bazel_monitoring
--skylark_memory=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
किसी तय पाथ पर, pprof के साथ काम करने वाली मेमोरी प्रोफ़ाइल को डंप करता है. ज़्यादा जानने के लिए, कृपया https://github.com/google/pprof देखें.
टैग:bazel_monitoring
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग का कॉम्बिनेशन वगैरह) को पूरी तरह से कैसे लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
फ़ेच के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]incompatible_remote_dangling_symlinks
डिफ़ॉल्ट: "सही"-
अगर सही पर सेट किया गया है और --insupported_remote_symlinks को भी सेट किया गया है, तो ऐक्शन आउटपुट में सिमलिंक को लटकने की अनुमति है.
टैग:execution
,incompatible_change
--[no]incompatible_remote_symlinks
डिफ़ॉल्ट: "सही"-
अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैशिंग/एक्ज़ीक्यूशन प्रोटोकॉल में ऐक्शन आउटपुट में सिमलिंक दिखाएगा. अगर ऐसा नहीं होता है, तो सिमलिंक का पालन किया जाएगा और उन्हें फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए #6631 पर जाएं.
टैग:execution
,incompatible_change
--[no]keep_going
[-k
] डिफ़ॉल्ट: "false"-
किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. हालांकि, फ़ेल हो चुके टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता, लेकिन इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें पूरी की जा सकती हैं.
टैग:eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "ऑटो"-
लोडिंग/विश्लेषण के चरण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") इस्तेमाल किया जाता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. "auto", "Host_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो उपयोगकर्ता को सही आउटपुट कॉन्फ़िगर करने की अनुमति देते हैं, उसकी वैल्यू पर असर पड़ता है, न कि उस पर असर होता है:
--bep_maximum_open_remote_upload_files=<an integer>
डिफ़ॉल्ट: "-1"-
BEP आर्टफ़ैक्ट अपलोड करने के दौरान, खुली हुई फ़ाइलों की ज़्यादा से ज़्यादा संख्या.
टैग:affects_outputs
--remote_download_minimal
-
लोकल मशीन पर, रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ शिपिंग_metadata और --remote_download_इस=minimal.
इसमें बड़ा होता है:
--nobuild_runfile_links
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=minimal
टैग:affects_outputs
--remote_download_outputs=<all, minimal or toplevel>
डिफ़ॉल्ट: "सभी"-
अगर इस नीति को 'मिनिमल' पर सेट किया जाता है, तो लोकल मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होगा. हालांकि, लोकल ऐक्शन के लिए ज़रूरी आउटपुट आउटपुट सिर्फ़ कुछ ही होंगे. अगर 'टॉप-लेवल' पर सेट किया जाता है, तो यह'कम से कम' की तरह काम करता है. अंतर सिर्फ़ यह है कि यह टॉप लेवल टारगेट के आउटपुट भी लोकल मशीन से डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ बहुत मुश्किल है, तो दोनों विकल्पों से बिल्ड में लगने वाला समय काफ़ी कम हो सकता है.
टैग:affects_outputs
--remote_download_symlink_template=<a string>
डिफ़ॉल्ट: ""-
लोकल मशीन पर रिमोट बिल्ड आउटपुट डाउनलोड करने के बजाय, सॉफ़्ट लिंक बनाएं. सिंबॉलिक लिंक का टारगेट, टेंप्लेट स्ट्रिंग के रूप में तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं, जो ऑब्जेक्ट के हैश तक और बाइट में साइज़ तक बढ़ते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर CAS से ऑब्जेक्ट लोड करते हैं.
टैग:affects_outputs
--remote_download_toplevel
-
टॉप लेवल टारगेट के रिमोट आउटपुट सिर्फ़ लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ प्रिंट_metadata और --remote_download_इस=toplevel.
यह इन पर लागू होता है:
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=toplevel
टैग:affects_outputs
- Bzel से मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "false"-
अगर sensitive_enforce_config_setting_ पहचानने के लिए गलत वैल्यू है, तो यह नॉप है. ऐसा न होने पर, अगर यह फ़्लैग गलत है, तो बिना किसी खास 'किसको दिखे' एट्रिब्यूट के बिना कोई भी config_setting //visible:public पर सेट कर दे. अगर यह फ़्लैग सही है, तो config_setting, दिखने के उसी लॉजिक का पालन करेगी जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो Starlark की ऐसी वैल्यू लिखें जो Starlark के डेटा स्टोर करने की जगह के उन सभी नियमों की हल की गई जानकारी के साथ होती है जिन्हें लागू किया गया था.
टैग:affects_outputs
--remote_print_execution_messages=<failure, success or all>
डिफ़ॉल्ट: "failure"-
चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज को कब प्रिंट करना है. मान्य वैल्यू 'असफलता' होती हैं, सिर्फ़ काम न करने पर प्रिंट करने के लिए, सिर्फ़ सफलता पर प्रिंट करने के लिए `सफलता`, और हमेशा प्रिंट करने के लिए `सभी`.
टैग:terminal_output
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
--[no]experimental_guard_against_concurrent_changes
डिफ़ॉल्ट: "false"- रिमोट कैश मेमोरी में अपलोड करने से पहले, किसी कार्रवाई की इनपुट फ़ाइलों के समय की जांच करने की सुविधा बंद करने के लिए, इस सेटिंग को बंद करें. कुछ मामलों में, Linux kernel की वजह से फ़ाइलें लिखने में देरी हो सकती है. इसकी वजह से फ़ॉल्स पॉज़िटिव नतीजे मिल सकते हैं.
--experimental_remote_build_event_upload=<all or minimal>
डिफ़ॉल्ट: "सभी"- अगर यह वैल्यू 'सभी' पर सेट है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड किए जाते हैं. अगर इसे 'मिनिमल' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. हालांकि, BEP इस्तेमाल करने वालों के लिए ज़रूरी फ़ाइलें (जैसे, टेस्ट लॉग और टाइम प्रोफ़ाइल) होती हैं. file:// स्कीम का इस्तेमाल लोकल फ़ाइलों के पाथ के लिए होता है और bytestream:// स्कीम का इस्तेमाल अपलोड की गई (पहले से) फ़ाइलों के पाथ के लिए किया जाता है. डिफ़ॉल्ट रूप से 'सभी' चुनें.
--[no]experimental_remote_cache_async
डिफ़ॉल्ट: "false"- अगर सही है, तो रिमोट कैश I/O, इवेंट के इवेंट के तौर पर होने के बजाय, बैकग्राउंड में होगा.
--[no]experimental_remote_cache_compression
डिफ़ॉल्ट: "false"- अगर इस सेटिंग को चालू किया गया है, तो कैश ब्लॉब को zstd की मदद से कंप्रेस या डिकंप्रेस करें.
--experimental_remote_capture_corrupted_outputs=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जहां खराब आउटपुट को कैप्चर किया जाएगा.
--experimental_remote_downloader=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जा सकता है. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback
डिफ़ॉल्ट: "false"- रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर पर वापस जाना चाहिए या नहीं.
--[no]experimental_remote_execution_keepalive
डिफ़ॉल्ट: "false"- रिमोट एक्ज़ीक्यूशन कॉल के लिए कीपअलाइव (चालू रखें) का इस्तेमाल करना है या नहीं.
--experimental_remote_grpc_log=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry Protobufs के क्रम में, हर मैसेज के प्रीफ़िक्स वाला क्रम होता है. यह क्रम वाले इन प्रोटोबफ़ मैसेज के साइज़ को दिखाता है, जैसा कि LogEntry.writeDelimitedTo(OUTStream) के तरीके से किया गया है.
--[no]experimental_remote_mark_tool_inputs
डिफ़ॉल्ट: "false"- अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट परसिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache
डिफ़ॉल्ट: "false"- अगर नीति को 'सही है' पर सेट किया जाता है, तो मर्कल ट्री की कैलकुलेशन को याद किया जाएगा. इससे रिमोट कैश हिट का पता लगाने की स्पीड को बेहतर बनाने में मदद मिलेगी. कैश मेमोरी के पैर के मेमोरी प्रिंट को --experimental_remote_mercle_tree_cache_size की मदद से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer>
डिफ़ॉल्ट: "1000"- रिमोट कैश हिट चेकिंग स्पीड को बेहतर बनाने के लिए, याद किए जाने वाले मर्कले ट्री की संख्या. हालांकि, कैश को सॉफ़्ट रेफ़रंस पर Java की प्रोसेस के हिसाब से अपने-आप कम कर दिया जाता है, लेकिन बहुत ज़्यादा वैल्यू पर सेट करने पर, मेमोरी से बाहर की गड़बड़ियां हो सकती हैं. अगर यह 0 पर सेट है, तो कैश मेमोरी का साइज़ अनलिमिटेड है. सबसे अच्छी वैल्यू, प्रोजेक्ट के साइज़ के आधार पर अलग-अलग होती है. डिफ़ॉल्ट वैल्यू 1,000 होती है.
--[no]incompatible_remote_build_event_upload_respect_no_cache
डिफ़ॉल्ट: "false"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तरीके से कैश मेमोरी में सेव नहीं किया जा सकता.
--[no]incompatible_remote_downloader_send_all_headers
डिफ़ॉल्ट: "सही"-
कई वैल्यू वाले हेडर की सभी वैल्यू को पहले वाले हेडर के बजाय रिमोट डाउनलोडर को भेजना है या नहीं.
टैग:incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root
डिफ़ॉल्ट: "false"-
अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट से जुड़े होते हैं.
टैग:incompatible_change
--[no]incompatible_remote_results_ignore_disk
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो डिस्क कैश मेमोरी पर --noremote_upload_local_results और --noremote_accept_cached लागू नहीं किया जाएगा. अगर एक साथ कई कैश मेमोरी का इस्तेमाल किया जाता है:
--noremote_upload_local_results की वजह से नतीजे डिस्क की कैश मेमोरी में लिखे जाएंगे, लेकिन रिमोट कैश पर अपलोड नहीं किए जाएंगे.
--noremote_accept_cached का नतीजा डिस्क कैश में नतीजों की जांच करने के लिए, Bazel से होगा, लेकिन रिमोट कैश में नहीं.
no-remote-exec कार्रवाइयां डिस्क की कैश मेमोरी को दबा सकती हैं.
ज़्यादा जानकारी के लिए #8216 देखें.
टैग:incompatible_change
--[no]remote_accept_cached
डिफ़ॉल्ट: "सही"- रिमोट कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को स्वीकार करना है या नहीं.
--remote_bytestream_uri_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम, जिसे बिल्ड इवेंट स्ट्रीम में लिखा जाता है. यह विकल्प तब सेट किया जा सकता है, जब बिल्ड के लिए प्रॉक्सी का इस्तेमाल किया जाता है. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, अब रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इस नीति को सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.
--remote_cache=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- कैशिंग एंडपॉइंट का यूआरआई. इस तरह के स्कीमा के साथ काम करने वाले स्कीमा हैं एचटीटीपी, एचटीटीपीएस, जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc://, http:// या unix: schema के बारे में बताएं. https://bazel.build/remote/caching देखें
- ऐप्लिकेशन के
--remote_cache_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे कैश अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
- ऐप्लिकेशन के
--remote_default_exec_properties=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर कोई प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो डिफ़ॉल्ट exec प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए सेट करें.
टैग:affects_outputs
--remote_default_platform_properties=<a string>
डिफ़ॉल्ट: ""- अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से रिमोट_execution_properties सेट नहीं करता है, तो डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन एपीआई के लिए सेट करें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब रिमोट तौर पर एक्ज़ीक्यूशन के लिए, होस्ट प्लैटफ़ॉर्म को एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना गया हो.
- ऐप्लिकेशन के
--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>
डिफ़ॉल्ट: ब्यौरा देखें- होस्ट या होस्ट:रिमोट एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट नंबर. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
- ऐप्लिकेशन के
--remote_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
--remote_instance_name=<a string>
डिफ़ॉल्ट: ""- रिमोट एक्ज़ीक्यूशन एपीआई में, example_name के तौर पर पास करने वाली वैल्यू.
--[no]remote_local_fallback
डिफ़ॉल्ट: "false"- अगर रिमोट तरीके से एक्ज़ीक्यूट करने की सुविधा काम नहीं करती है, तो क्या आपको स्टैंडअलोन लोकल ऐक्शन रणनीति का इस्तेमाल करना चाहिए.
--remote_local_fallback_strategy=<a string>
डिफ़ॉल्ट: "स्थानीय"- नहीं, अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 देखें.
--remote_max_connections=<an integer>
डिफ़ॉल्ट: "100"-
एक साथ ज़्यादा से ज़्यादा कनेक्शन की संख्या, रिमोट कैश/एक्स्क्यूटर तक सीमित रखें. डिफ़ॉल्ट तौर पर, वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है, इसलिए Bazel --remote_max_ connections को एक साथ किए जा सकने वाले अनुरोधों के मुताबिक बना सकता है.
जीआरपीसी रिमोट कैश/एक्स्क्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को हैंडल कर सकता है. इसलिए, Bazel `--remote_max_ connections * 100` एक साथ किए जा सकने वाले अनुरोधों को पूरा कर सकता है.
टैग:host_machine_resource_optimizations
--remote_proxy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer>
डिफ़ॉल्ट: "0"- रिमोट कैश में सेव की जाने वाली रिमोट ऐक्शन की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर करते हैं.
--remote_retries=<an integer>
डिफ़ॉल्ट: "5"- कुछ समय के लिए होने वाली गड़बड़ी को ठीक करने के लिए, कितनी बार कोशिश की जा सकती है. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
--remote_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"- रिमोट एक्ज़ीक्यूशन और कैश कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट करने और रीड टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो वैल्यू को सेकंड के तौर पर समझा जाता है.
--[no]remote_upload_local_results
डिफ़ॉल्ट: "सही"- अगर रिमोट कैश मेमोरी के साथ काम करती है और उपयोगकर्ता के पास इसकी अनुमति है, तो क्या यह लोकल तौर पर एक्ज़ीक्यूट की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है या नहीं.
--[no]remote_verify_downloads
डिफ़ॉल्ट: "सही"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Bazel, सभी रिमोट डाउनलोड के हैश योग का हिसाब लगाएगा. साथ ही, अगर रिमोट तौर पर कैश मेमोरी में सेव की गई वैल्यू, अनुमानित वैल्यू से मेल नहीं खाती है, तो उसे खारिज कर दिया जाएगा.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
--deleted_packages=<comma-separated list of package names>
डिफ़ॉल्ट: ""- पैकेज के नामों की कॉमा-सेपरेटेड लिस्ट, जिसे बिल्ड सिस्टम मानेगा. भले ही, वे पैकेज पाथ पर कहीं भी दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD को मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह इसकी शिकायत कर सकता है. ऐसा तब होता है, जब वह अब भी किसी दूसरी Package_path एंट्री में मौजूद हो. --deleted_packages x/y को तय करने से इस समस्या से बचा जा सकता है.
--disk_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जिसमें Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो इसे बना दिया जाएगा.
- ऐप्लिकेशन के
--experimental_credential_helper=<An (unresolved) path to a credential helper for a scope.>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि दिए गए स्कोप (डोमेन) के लिए क्रेडेंशियल वापस पाने में उसका इस्तेमाल किया जा सके. क्रेडेंशियल हेल्पर के क्रेडेंशियल को <code>--google_default_credentials</code>, `--google_क्रेडेंशियल` या <code>.netrc</code> से ज़्यादा अहमियत दी जाती है. https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-Credential-helpers की जानकारी देखें.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मिनट"- उस अवधि को कॉन्फ़िगर करता है जिसके लिए क्रेडेंशियल हेल्पर के क्रेडेंशियल, कैश मेमोरी में सेव किए जाते हैं. किसी दूसरी वैल्यू से शुरू करने पर, पहले से मौजूद एंट्री का लाइफ़टाइम बदल जाएगा; कैश मेमोरी मिटाने के लिए शून्य पास करें. क्लीन कमांड, कैश मेमोरी को हमेशा मिटाता है, भले ही यह फ़्लैग किसी भी तरह का हो.
--experimental_credential_helper_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "5s"- क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. क्रेडेंशियल सहायक इस टाइम आउट के अंदर जवाब नहीं दे पाने पर, बातचीत शुरू नहीं कर पाएंगे.
--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
डिफ़ॉल्ट: "false"- पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं. डिफ़ॉल्ट रूप से बंद होता है.
--grpc_keepalive_time=<An immutable length of time.>
डिफ़ॉल्ट: ब्यौरा देखें- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो Bazel इतने समय बाद कनेक्शन पर कोई कार्रवाई नहीं करने के बाद पिंग भेजता है. यह सिर्फ़ तब पिंग करता है, जब कम से कम एक gRPC कॉल लंबित हो. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. कीप-अलाइव पिंग, डिफ़ॉल्ट रूप से बंद रहते हैं. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक से संपर्क करना होगा. उदाहरण के लिए, इस फ़्लैग के लिए 30 सेकंड की वैल्यू सेट करने के लिए, इस तरह से सेट करना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "20 सेकंड"- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव (चालू रखें) टाइम आउट कॉन्फ़िगर करता है. अगर कीप-अलाइव पिंग को --grpc_keepalive_time से चालू किया जाता है, तो Bazel को इतने समय के बाद पिंग का जवाब न मिलने पर, कनेक्शन बंद कर दिया जाता है. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. अगर कीप-अलाइव पिंग को बंद रखा जाता है, तो इस सेटिंग को अनदेखा कर दिया जाता है.
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- कोलन से अलग की गई इस सूची में बताया जाता है कि पैकेज कहां खोजने हैं. '%workspace%' से शुरू होने वाले एलिमेंट, बंद होने वाले फ़ाइल फ़ोल्डर से मिलते-जुलते हैं. अगर इसे खाली छोड़ा जाता है या इसे खाली छोड़ा जाता है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट होता है.
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर इस सुविधा को चालू किया जाता है, तो Bazel "लोडिंग पैकेज:" मैसेज प्रिंट करेगा.
--tls_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- किसी TLS सर्टिफ़िकेट का पाथ बताएं, जो सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसेमंद हो.
--tls_client_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट के बारे में बताएं. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए, TLS क्लाइंट कुंजी तय करें. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
सहायता के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 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
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के ऐसे विकल्प जो अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
जानकारी के विकल्प
build के सभी विकल्प इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
--[no]show_make_env
डिफ़ॉल्ट: "false"-
आउटपुट में "बनाएं" एनवायरमेंट शामिल करें.
टैग:affects_outputs
,terminal_output
- Bzel कमांड के लिए जेनरिक इनपुट को तय करने या उसमें बदलाव करने के विकल्प जो अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
लाइसेंस के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
मोबाइल से इंस्टॉल करने के विकल्प
build के सभी विकल्प इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--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 में बताए गए SDK टूल का इस्तेमाल किया जाता है.
टैग:changes_inputs
- कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:
--[no]incremental
डिफ़ॉल्ट: "false"-
इंक्रीमेंटल इंस्टॉल करना है या नहीं. अगर सही हो, तो जिस डिवाइस पर कोड को इंस्टॉल करना है उसकी स्थिति को पढ़कर ग़ैर-ज़रूरी काम से बचने की कोशिश करें. साथ ही, उस जानकारी का इस्तेमाल करें. अगर यह नीति गलत है (डिफ़ॉल्ट तौर पर), तो हमेशा पूरी तरह से इंस्टॉल करें.
टैग:loading_and_analysis
--[no]split_apks
डिफ़ॉल्ट: "false"-
डिवाइस पर ऐप्लिकेशन इंस्टॉल और अपडेट करने के लिए, स्प्लिट 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
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
--incremental_install_verbosity=<a string>
डिफ़ॉल्ट: ""-
इंंक्रीमेंटल इंस्टॉल के लिए कितने शब्दों में जानकारी दी जाए. डीबग लॉग करने के लिए, वैल्यू को 1 पर सेट करें.
टैग:bazel_monitoring
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
मॉडक्वेरी के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]keep_going
[-k
] डिफ़ॉल्ट: "false"-
किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. हालांकि, फ़ेल हो चुके टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता, लेकिन इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें पूरी की जा सकती हैं.
टैग:eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "ऑटो"-
लोडिंग/विश्लेषण के चरण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") इस्तेमाल किया जाता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. "auto", "Host_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "false"-
अगर sensitive_enforce_config_setting_ पहचानने के लिए गलत वैल्यू है, तो यह नॉप है. ऐसा न होने पर, अगर यह फ़्लैग गलत है, तो बिना किसी खास 'किसको दिखे' एट्रिब्यूट के बिना कोई भी config_setting //visible:public पर सेट कर दे. अगर यह फ़्लैग सही है, तो config_setting, दिखने के उसी लॉजिक का पालन करेगी जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- मॉड क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:
--charset=<utf8 or ascii>
डिफ़ॉल्ट: "utf8"-
ट्री के लिए इस्तेमाल किए जाने वाले वर्ण सेट को चुनता है. सिर्फ़ टेक्स्ट आउटपुट पर असर डालता है. मान्य वैल्यू "utf8" या "ascii" हैं. डिफ़ॉल्ट "utf8" है
टैग:terminal_output
--[no]cycles
डिफ़ॉल्ट: "false"-
दिखाए गए ट्री के अंदर डिपेंडेंसी साइकल की जानकारी देता है, जिन्हें आम तौर पर डिफ़ॉल्ट रूप से अनदेखा किया जाता है.
टैग:execution
--depth=<an integer>
डिफ़ॉल्ट: "-1"-
डिपेंडेंसी ट्री की डिसप्ले डेप्थ ज़्यादा से ज़्यादा. उदाहरण के लिए, 1 गहराई सीधे तौर पर डिपेंडेंसी दिखाता है. ट्री, पाथ, और all_paths के लिए, यह डिफ़ॉल्ट रूप से Integer.MAX_VALUE होता है, जबकि dep और 'डेप' के लिए डिफ़ॉल्ट तौर पर यह 1 पर सेट होता है (टारगेट की गई पत्तियों और उनके पैरंट के अलावा सिर्फ़ रूट का सीधा डिप दिखाता है).
टैग:execution
--[no]extra
डिफ़ॉल्ट: "false"-
क्वेरी में, मॉड्यूल के मौजूदा वर्शन (अगर बदला गया है) में समाधान किए जाने की वजह भी दिखेगी. सिर्फ़ जानकारी देने वाली क्वेरी के लिए, डिफ़ॉल्ट तौर पर 'सही' पर सेट होता है.
टैग:execution
--from=<a list of <module>s separated by comma>
डिफ़ॉल्ट: "रूट"-
ऐसा मॉड्यूल(मॉड्यूल) जहां से डिपेंडेंसी ग्राफ़ क्वेरी दिखेगी. सही सिमैंटिक के लिए हर क्वेरी के ब्यौरे की जांच करें. डिफ़ॉल्ट तौर पर रूट का इस्तेमाल करता है.
टैग:execution
--[no]include_unused
डिफ़ॉल्ट: "false"-
क्वेरी में उन मॉड्यूल को भी ध्यान में रखा जाएगा जो इस्तेमाल नहीं किए गए हैं. ये मॉड्यूल, चुनने के बाद मॉड्यूल रिज़ॉल्यूशन ग्राफ़ में मौजूद नहीं होते हैं. ऐसा कम से कम वर्शन चुनने या बदलाव के नियमों की वजह से होता है. हर क्वेरी टाइप के लिए इसका अलग-अलग असर हो सकता है. जैसे, all_paths कमांड में नए पाथ या एक्सप्लेनेशन कमांड में अतिरिक्त डिपेंडेंसी.
टैग:execution
--output=<text, json or graph>
डिफ़ॉल्ट: "text"-
वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए इन वैल्यू की अनुमति है: text, json, ग्राफ़
टैग:terminal_output
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
--deleted_packages=<comma-separated list of package names>
डिफ़ॉल्ट: ""- पैकेज के नामों की कॉमा-सेपरेटेड लिस्ट, जिसे बिल्ड सिस्टम मानेगा. भले ही, वे पैकेज पाथ पर कहीं भी दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD को मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह इसकी शिकायत कर सकता है. ऐसा तब होता है, जब वह अब भी किसी दूसरी Package_path एंट्री में मौजूद हो. --deleted_packages x/y को तय करने से इस समस्या से बचा जा सकता है.
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- कोलन से अलग की गई इस सूची में बताया जाता है कि पैकेज कहां खोजने हैं. '%workspace%' से शुरू होने वाले एलिमेंट, बंद होने वाले फ़ाइल फ़ोल्डर से मिलते-जुलते हैं. अगर इसे खाली छोड़ा जाता है या इसे खाली छोड़ा जाता है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट होता है.
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर इस सुविधा को चालू किया जाता है, तो Bazel "लोडिंग पैकेज:" मैसेज प्रिंट करेगा.
Print_action के विकल्प
build के सभी विकल्प इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
- ऐप्लिकेशन के
--print_action_mnemonics=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - ऐसी सूचियां जिनके हिसाब से screen_action डेटा फ़िल्टर किया जा सके. खाली छोड़ने पर कोई फ़िल्टर नहीं किया जाता.
क्वेरी के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]incompatible_remote_dangling_symlinks
डिफ़ॉल्ट: "सही"-
अगर सही पर सेट किया गया है और --insupported_remote_symlinks को भी सेट किया गया है, तो ऐक्शन आउटपुट में सिमलिंक को लटकने की अनुमति है.
टैग:execution
,incompatible_change
--[no]incompatible_remote_symlinks
डिफ़ॉल्ट: "सही"-
अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैशिंग/एक्ज़ीक्यूशन प्रोटोकॉल में ऐक्शन आउटपुट में सिमलिंक दिखाएगा. अगर ऐसा नहीं होता है, तो सिमलिंक का पालन किया जाएगा और उन्हें फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए #6631 पर जाएं.
टैग:execution
,incompatible_change
--[no]keep_going
[-k
] डिफ़ॉल्ट: "false"-
किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. हालांकि, फ़ेल हो चुके टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता, लेकिन इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें पूरी की जा सकती हैं.
टैग:eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "ऑटो"-
लोडिंग/विश्लेषण के चरण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") इस्तेमाल किया जाता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. "auto", "Host_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
- ऐसे विकल्प जो उपयोगकर्ता को सही आउटपुट कॉन्फ़िगर करने की अनुमति देते हैं, उसकी वैल्यू पर असर पड़ता है, न कि उस पर असर होता है:
--bep_maximum_open_remote_upload_files=<an integer>
डिफ़ॉल्ट: "-1"-
BEP आर्टफ़ैक्ट अपलोड करने के दौरान, खुली हुई फ़ाइलों की ज़्यादा से ज़्यादा संख्या.
टैग:affects_outputs
--remote_download_minimal
-
लोकल मशीन पर, रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ शिपिंग_metadata और --remote_download_इस=minimal.
इसमें बड़ा होता है:
--nobuild_runfile_links
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=minimal
टैग:affects_outputs
--remote_download_outputs=<all, minimal or toplevel>
डिफ़ॉल्ट: "सभी"-
अगर इस नीति को 'मिनिमल' पर सेट किया जाता है, तो लोकल मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होगा. हालांकि, लोकल ऐक्शन के लिए ज़रूरी आउटपुट आउटपुट सिर्फ़ कुछ ही होंगे. अगर 'टॉप-लेवल' पर सेट किया जाता है, तो यह'कम से कम' की तरह काम करता है. अंतर सिर्फ़ यह है कि यह टॉप लेवल टारगेट के आउटपुट भी लोकल मशीन से डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ बहुत मुश्किल है, तो दोनों विकल्पों से बिल्ड में लगने वाला समय काफ़ी कम हो सकता है.
टैग:affects_outputs
--remote_download_symlink_template=<a string>
डिफ़ॉल्ट: ""-
लोकल मशीन पर रिमोट बिल्ड आउटपुट डाउनलोड करने के बजाय, सॉफ़्ट लिंक बनाएं. सिंबॉलिक लिंक का टारगेट, टेंप्लेट स्ट्रिंग के रूप में तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं, जो ऑब्जेक्ट के हैश तक और बाइट में साइज़ तक बढ़ते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर CAS से ऑब्जेक्ट लोड करते हैं.
टैग:affects_outputs
--remote_download_toplevel
-
टॉप लेवल टारगेट के रिमोट आउटपुट सिर्फ़ लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ प्रिंट_metadata और --remote_download_इस=toplevel.
यह इन पर लागू होता है:
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=toplevel
टैग:affects_outputs
- Bzel से मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "false"-
अगर sensitive_enforce_config_setting_ पहचानने के लिए गलत वैल्यू है, तो यह नॉप है. ऐसा न होने पर, अगर यह फ़्लैग गलत है, तो बिना किसी खास 'किसको दिखे' एट्रिब्यूट के बिना कोई भी config_setting //visible:public पर सेट कर दे. अगर यह फ़्लैग सही है, तो config_setting, दिखने के उसी लॉजिक का पालन करेगी जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- क्वेरी आउटपुट और सिमेंटिक्स से जुड़े विकल्प:
--aspect_deps=<off, conservative or precise>
डिफ़ॉल्ट: "कंज़र्वेटिव"-
जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तो आसपेक्ट डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि कोई आसपेक्ट डिपेंडेंसी हल नहीं की गई है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि तय की गई सभी पहलू डिपेंडेंसी जोड़ी जाती हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के नियम की कैटगरी दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलुओं को जोड़ा गया है जो डायरेक्ट डिपेंडेंसी के नियम की क्लास के आधार पर ऐक्टिव होते हैं. ध्यान दें कि सटीक मोड में किसी एक टारगेट की जांच करने के लिए, अन्य पैकेज लोड करने ज़रूरी होते हैं. इस वजह से, यह अन्य मोड की तुलना में धीमा हो जाता है. यह भी ध्यान रखें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता है: किसी पहलू को कंप्यूट करने या न करने का फ़ैसला, विश्लेषण के चरण में लिया जाता है. यह प्रोसेस, 'bazel क्वेरी' के दौरान नहीं चलती.
टैग:build_file_semantics
--[no]experimental_graphless_query
डिफ़ॉल्ट: "ऑटो"-
सही होने पर, क्वेरी लागू करने के तरीके का इस्तेमाल किया जाता है, जो ग्राफ़ की कॉपी नहीं बनाता. लागू करने का नया तरीका सिर्फ़ --order_out=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 फ़ाइल में साफ़ तौर पर नहीं बताया गया है, लेकिन bazel के ज़रिए जोड़ा गया है. cquery के लिए, यह विकल्प ऐसे टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है जिनका समाधान हो चुका है.
टैग:build_file_semantics
--[no]include_aspects
डिफ़ॉल्ट: "सही"-
क्वेरी, cquery: आउटपुट में पक्ष से जनरेट की गई कार्रवाइयों को शामिल करना है या नहीं. क्वेरी: no-op (निर्देशों को हमेशा अपनाया जाता है).
टैग:terminal_output
--[no]incompatible_display_source_file_location
डिफ़ॉल्ट: "सही"-
डिफ़ॉल्ट रूप से 'सही', सोर्स फ़ाइल का टारगेट दिखाता है. सही होने पर, लोकेशन आउटपुट में सोर्स फ़ाइलों की लाइन 1 की जगह दिखाता है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग:terminal_output
,incompatible_change
--[no]incompatible_lexicographical_output
डिफ़ॉल्ट: "सही"-
अगर यह विकल्प सेट किया गया है, तो यह, lexico लिखने के क्रम में --order_आउटपुट=ऑटो आउटपुट के क्रम में दिखता है.
टैग:terminal_output
,incompatible_change
--[no]incompatible_package_group_includes_double_slash
डिफ़ॉल्ट: "सही"-
इस सुविधा को चालू करने पर, Package_group के `packages` एट्रिब्यूट को आउटपुट करते समय, पहले `//` की वैल्यू नहीं छोड़ी जाएगी.
टैग:terminal_output
,incompatible_change
--[no]infer_universe_scope
डिफ़ॉल्ट: "false"-
अगर सेट और --universe_scope को सेट नहीं किया जाता है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि दुनिया के स्कोप वाले फ़ंक्शन (जैसे कि`allrdeps`) का इस्तेमाल करने वाले क्वेरी एक्सप्रेशन के लिए बताई गई --universe_scope वैल्यू, शायद आपकी पसंद के मुताबिक न हो. इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/query/language#sky-query देखें. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `query` (जैसे कि `cquery` पर नहीं) पर लागू होता है.
टैग:loading_and_analysis
--[no]line_terminator_null
डिफ़ॉल्ट: "false"-
हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाए या नहीं.
टैग:terminal_output
--[no]nodep_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, "nodep" एट्रिब्यूट की वैल्यू को डिपेंडेंसी ग्राफ़ में शामिल किया जाएगा, जिस पर क्वेरी ऑपरेट होती है. "नोडप" एट्रिब्यूट का एक सामान्य उदाहरण "विज़िबिलिटी" है. बिल्ड लैंग्वेज में सभी "नोडेप" एट्रिब्यूट के बारे में जानने के लिए, `जानकारी बिल्ड-भाषा` के आउटपुट को चलाएं और पार्स करें.
टैग: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>
डिफ़ॉल्ट: "ऑटो"-
नतीजों को बिना किसी क्रम के (नहीं), डिपेंडेंसी के क्रम में (डीप) या पूरी तरह से क्रम में दिखाएं. डिफ़ॉल्ट तौर पर 'अपने-आप' सेट होता है. इसका मतलब है कि आउटपुट फ़ॉर्मैटर के आधार पर, आउटपुट या तो डिपेंडेंसी के हिसाब से या पूरी तरह से व्यवस्थित, नतीजे मिलते हैं. ये नतीजे, प्रोटो, मिनरैंक, मैक्सरैंक, और ग्राफ़ के लिए डिपेंडेंसी के तौर पर क्रम में लगाए जाते हैं. ये सभी विकल्पों के लिए, पूरी तरह से क्रम में लगाए जाते हैं. जब आउटपुट पूरी तरह से क्रम में होता है, तो नोड पूरी तरह से डिटर्मिनिस्टिक (कुल) के क्रम में प्रिंट किए जाते हैं. सबसे पहले, सभी नोड को वर्णमाला के क्रम में लगाया जाता है. इसके बाद, सूची के हर नोड का इस्तेमाल पोस्ट-ऑर्डर डेप्थ-फ़र्स्ट खोज की शुरुआत के रूप में किया जाता है. इसमें विज़िट नहीं किए गए नोड के आउटगोइंग किनारे अगले नोड के वर्णमाला के क्रम में ट्रैवर्स किए जाते हैं. आखिर में, नोड उस क्रम में प्रिंट किए जाते हैं जिस क्रम में उन्हें विज़िट किया गया था.
टैग:terminal_output
--order_results
-
नतीजे के तौर पर, डिपेंडेंसी के क्रम (डिफ़ॉल्ट) या बिना क्रम के फ़ैशन में नतीजे देता है. बिना क्रम वाला आउटपुट तेज़ी से काम करता है, लेकिन यह सिर्फ़ तब काम करता है, जब --आउटपुट, minrank, maxrank या ग्राफ़ के तौर पर न जोड़ा गया हो.
इसमें बड़ा होता है:
--order_output=auto
टैग:terminal_output
--output=<a string>
डिफ़ॉल्ट: "लेबल"-
वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: बिल्ड, ग्राफ़, लेबल, label_ kind, लोकेशन, maxrank, minrank, पैकेज, Proto, xml.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. ऐसा न होने पर, उन्हें हटा दिया जाता है. यह विकल्प --OUT=proto
टैग:terminal_output
पर लागू होता है
--[no]proto:definition_stack
डिफ़ॉल्ट: "false"-
definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें, जो नियम की क्लास तय किए जाने के समय Starlark कॉल स्टैक के हर नियम के लिए रिकॉर्ड करता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, Select() के ज़रिए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट फ़्लैट कर दिए जाते हैं. सूची के टाइप के लिए, फ़्लैट किया गया प्रज़ेंटेशन वह सूची है जिसमें चुने गए मैप की हर वैल्यू सिर्फ़ एक बार होती है. स्केलर टाइप शून्य तक चपटे हो जाते हैं.
टैग:build_file_semantics
--[no]proto:include_synthetic_attribute_hash
डिफ़ॉल्ट: "false"- $internal_attr_hh एट्रिब्यूट का हिसाब लगाने और उसे पॉप्युलेट करने या न करने का विकल्प.
टैग:terminal_output
--[no]proto:instantiation_stack
डिफ़ॉल्ट: "false"-
हर नियम के इंस्टैंशिएट कॉल स्टैक को भरें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग:terminal_output
--[no]proto:locations
डिफ़ॉल्ट: "सही"-
प्रोटो आउटपुट में जगह की जानकारी दिखाना है या नहीं.
टैग:terminal_output
--proto:output_rule_attrs=<comma-separated list of options>
डिफ़ॉल्ट: "सभी"-
आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर, यह सभी एट्रिब्यूट पर सेट होता है. किसी भी एट्रिब्यूट का आउटपुट न देने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प --OUT=proto पर लागू होता है.
टैग:terminal_output
--[no]proto:rule_inputs_and_outputs
डिफ़ॉल्ट: "सही"-
रूल_इनपुट और नियम_आउटपुट फ़ील्ड को पॉप्युलेट करना है या नहीं.
टैग:terminal_output
--query_file=<a string>
डिफ़ॉल्ट: ""-
सेट किए जाने पर, क्वेरी, कमांड लाइन के बजाय, यहां दी गई फ़ाइल में मौजूद क्वेरी को पढ़ेगी. यहां फ़ाइल और कमांड लाइन क्वेरी के बारे में बताना एक गड़बड़ी है.
टैग:changes_inputs
--[no]relative_locations
डिफ़ॉल्ट: "false"-
सही होने पर, एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह तय होगी. डिफ़ॉल्ट रूप से, लोकेशन आउटपुट एक ऐब्सलूट पाथ होता है. यह सभी मशीनों पर एक जैसा नहीं होगा. सभी मशीनों पर एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग:terminal_output
--[no]strict_test_suite
डिफ़ॉल्ट: "false"-
अगर सही होता है, तो test() एक्सप्रेशन किसी ऐसे test_suite का सामना करने पर गड़बड़ी का मैसेज देता है जिसमें नॉन-टेस्ट टारगेट मौजूद होते हैं.
टैग:build_file_semantics
,eagerness_to_exit
--[no]tool_deps
डिफ़ॉल्ट: "सही"-
क्वेरी: बंद होने पर, 'होस्ट कॉन्फ़िगरेशन' या 'एक्ज़ीक्यूशन' टारगेट की डिपेंडेंसी को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाता जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से प्रोटोकॉल कंपाइलर को मिलने वाला किनारा. आम तौर पर, यह उसी 'टारगेट' प्रोग्राम के हिस्से के बजाय, उस टूल के बारे में बताता है जिसे बिल्ड के दौरान लागू किया जाता है.
Cquery: बंद होने पर, कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो कॉन्फ़िगर किए गए इस टारगेट का पता लगाने वाले टॉप लेवल टारगेट से, होस्ट या एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. साथ ही, टारगेट कॉन्फ़िगरेशन में भी कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप लेवल टारगेट, होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट के कॉन्फ़िगर किए गए टारगेट ही दिखेंगे. इस विकल्प में, ऐसे टूलचेन शामिल नहीं होंगे जिनका समाधान हो चुका है.
टैग:build_file_semantics
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का सेट, कॉमा लगाकर अलग किया गया. इसमें योग और घटाव वाले पैटर्न शामिल होते हैं. क्वेरी को संसार में निष्पादित किया जा सकता है, जबकि बताए गए लक्ष्यों के ट्रांज़िटिव बंद होने से परिभाषित होता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है.
cquery के लिए, इस विकल्प का इनपुट वे टारगेट हैं जिनके तहत सभी जवाब तैयार किए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं दिया गया है, तो टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट मान लिया जाता है. ध्यान दें: अगर क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों की मदद से नहीं बनाए जा सकते, तो cquery के लिए इस विकल्प को तय न करने से बिल्ड टूट सकता है.
टैग:loading_and_analysis
--[no]xml:default_values
डिफ़ॉल्ट: "false"-
सही होने पर, नियम के एट्रिब्यूट जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है, प्रिंट कर दी जाती हैं; वरना उन्हें छोड़ दिया जाता है.
टैग:terminal_output
--[no]xml:line_numbers
डिफ़ॉल्ट: "सही"-
अगर सही है, तो एक्सएमएल आउटपुट में लाइन नंबर शामिल होते हैं. इस विकल्प को बंद करने से, फ़र्क़ को पढ़ने में आसानी हो सकती है. यह विकल्प सिर्फ़ --OUT=xml पर लागू होता है.
टैग:terminal_output
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो Starlark की ऐसी वैल्यू लिखें जो Starlark के डेटा स्टोर करने की जगह के उन सभी नियमों की हल की गई जानकारी के साथ होती है जिन्हें लागू किया गया था.
टैग:affects_outputs
--remote_print_execution_messages=<failure, success or all>
डिफ़ॉल्ट: "failure"-
चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज को कब प्रिंट करना है. मान्य वैल्यू 'असफलता' होती हैं, सिर्फ़ काम न करने पर प्रिंट करने के लिए, सिर्फ़ सफलता पर प्रिंट करने के लिए `सफलता`, और हमेशा प्रिंट करने के लिए `सभी`.
टैग:terminal_output
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
--[no]experimental_guard_against_concurrent_changes
डिफ़ॉल्ट: "false"- रिमोट कैश मेमोरी में अपलोड करने से पहले, किसी कार्रवाई की इनपुट फ़ाइलों के समय की जांच करने की सुविधा बंद करने के लिए, इस सेटिंग को बंद करें. कुछ मामलों में, Linux kernel की वजह से फ़ाइलें लिखने में देरी हो सकती है. इसकी वजह से फ़ॉल्स पॉज़िटिव नतीजे मिल सकते हैं.
--experimental_remote_build_event_upload=<all or minimal>
डिफ़ॉल्ट: "सभी"- अगर यह वैल्यू 'सभी' पर सेट है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड किए जाते हैं. अगर इसे 'मिनिमल' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. हालांकि, BEP इस्तेमाल करने वालों के लिए ज़रूरी फ़ाइलें (जैसे, टेस्ट लॉग और टाइम प्रोफ़ाइल) होती हैं. file:// स्कीम का इस्तेमाल लोकल फ़ाइलों के पाथ के लिए होता है और bytestream:// स्कीम का इस्तेमाल अपलोड की गई (पहले से) फ़ाइलों के पाथ के लिए किया जाता है. डिफ़ॉल्ट रूप से 'सभी' चुनें.
--[no]experimental_remote_cache_async
डिफ़ॉल्ट: "false"- अगर सही है, तो रिमोट कैश I/O, इवेंट के इवेंट के तौर पर होने के बजाय, बैकग्राउंड में होगा.
--[no]experimental_remote_cache_compression
डिफ़ॉल्ट: "false"- अगर इस सेटिंग को चालू किया गया है, तो कैश ब्लॉब को zstd की मदद से कंप्रेस या डिकंप्रेस करें.
--experimental_remote_capture_corrupted_outputs=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जहां खराब आउटपुट को कैप्चर किया जाएगा.
--experimental_remote_downloader=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जा सकता है. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback
डिफ़ॉल्ट: "false"- रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर पर वापस जाना चाहिए या नहीं.
--[no]experimental_remote_execution_keepalive
डिफ़ॉल्ट: "false"- रिमोट एक्ज़ीक्यूशन कॉल के लिए कीपअलाइव (चालू रखें) का इस्तेमाल करना है या नहीं.
--experimental_remote_grpc_log=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry Protobufs के क्रम में, हर मैसेज के प्रीफ़िक्स वाला क्रम होता है. यह क्रम वाले इन प्रोटोबफ़ मैसेज के साइज़ को दिखाता है, जैसा कि LogEntry.writeDelimitedTo(OUTStream) के तरीके से किया गया है.
--[no]experimental_remote_mark_tool_inputs
डिफ़ॉल्ट: "false"- अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट परसिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache
डिफ़ॉल्ट: "false"- अगर नीति को 'सही है' पर सेट किया जाता है, तो मर्कल ट्री की कैलकुलेशन को याद किया जाएगा. इससे रिमोट कैश हिट का पता लगाने की स्पीड को बेहतर बनाने में मदद मिलेगी. कैश मेमोरी के पैर के मेमोरी प्रिंट को --experimental_remote_mercle_tree_cache_size की मदद से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer>
डिफ़ॉल्ट: "1000"- रिमोट कैश हिट चेकिंग स्पीड को बेहतर बनाने के लिए, याद किए जाने वाले मर्कले ट्री की संख्या. हालांकि, कैश को सॉफ़्ट रेफ़रंस पर Java की प्रोसेस के हिसाब से अपने-आप कम कर दिया जाता है, लेकिन बहुत ज़्यादा वैल्यू पर सेट करने पर, मेमोरी से बाहर की गड़बड़ियां हो सकती हैं. अगर यह 0 पर सेट है, तो कैश मेमोरी का साइज़ अनलिमिटेड है. सबसे अच्छी वैल्यू, प्रोजेक्ट के साइज़ के आधार पर अलग-अलग होती है. डिफ़ॉल्ट वैल्यू 1,000 होती है.
--[no]incompatible_remote_build_event_upload_respect_no_cache
डिफ़ॉल्ट: "false"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तरीके से कैश मेमोरी में सेव नहीं किया जा सकता.
--[no]incompatible_remote_downloader_send_all_headers
डिफ़ॉल्ट: "सही"-
कई वैल्यू वाले हेडर की सभी वैल्यू को पहले वाले हेडर के बजाय रिमोट डाउनलोडर को भेजना है या नहीं.
टैग:incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root
डिफ़ॉल्ट: "false"-
अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट से जुड़े होते हैं.
टैग:incompatible_change
--[no]incompatible_remote_results_ignore_disk
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो डिस्क कैश मेमोरी पर --noremote_upload_local_results और --noremote_accept_cached लागू नहीं किया जाएगा. अगर एक साथ कई कैश मेमोरी का इस्तेमाल किया जाता है:
--noremote_upload_local_results की वजह से नतीजे डिस्क की कैश मेमोरी में लिखे जाएंगे, लेकिन रिमोट कैश पर अपलोड नहीं किए जाएंगे.
--noremote_accept_cached का नतीजा डिस्क कैश में नतीजों की जांच करने के लिए, Bazel से होगा, लेकिन रिमोट कैश में नहीं.
no-remote-exec कार्रवाइयां डिस्क की कैश मेमोरी को दबा सकती हैं.
ज़्यादा जानकारी के लिए #8216 देखें.
टैग:incompatible_change
--[no]remote_accept_cached
डिफ़ॉल्ट: "सही"- रिमोट कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को स्वीकार करना है या नहीं.
--remote_bytestream_uri_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम, जिसे बिल्ड इवेंट स्ट्रीम में लिखा जाता है. यह विकल्प तब सेट किया जा सकता है, जब बिल्ड के लिए प्रॉक्सी का इस्तेमाल किया जाता है. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, अब रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इस नीति को सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.
--remote_cache=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- कैशिंग एंडपॉइंट का यूआरआई. इस तरह के स्कीमा के साथ काम करने वाले स्कीमा हैं एचटीटीपी, एचटीटीपीएस, जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc://, http:// या unix: schema के बारे में बताएं. https://bazel.build/remote/caching देखें
- ऐप्लिकेशन के
--remote_cache_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे कैश अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
- ऐप्लिकेशन के
--remote_default_exec_properties=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर कोई प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो डिफ़ॉल्ट exec प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए सेट करें.
टैग:affects_outputs
--remote_default_platform_properties=<a string>
डिफ़ॉल्ट: ""- अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से रिमोट_execution_properties सेट नहीं करता है, तो डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन एपीआई के लिए सेट करें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब रिमोट तौर पर एक्ज़ीक्यूशन के लिए, होस्ट प्लैटफ़ॉर्म को एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना गया हो.
- ऐप्लिकेशन के
--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>
डिफ़ॉल्ट: ब्यौरा देखें- होस्ट या होस्ट:रिमोट एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट नंबर. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
- ऐप्लिकेशन के
--remote_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
--remote_instance_name=<a string>
डिफ़ॉल्ट: ""- रिमोट एक्ज़ीक्यूशन एपीआई में, example_name के तौर पर पास करने वाली वैल्यू.
--[no]remote_local_fallback
डिफ़ॉल्ट: "false"- अगर रिमोट तरीके से एक्ज़ीक्यूट करने की सुविधा काम नहीं करती है, तो क्या आपको स्टैंडअलोन लोकल ऐक्शन रणनीति का इस्तेमाल करना चाहिए.
--remote_local_fallback_strategy=<a string>
डिफ़ॉल्ट: "स्थानीय"- नहीं, अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 देखें.
--remote_max_connections=<an integer>
डिफ़ॉल्ट: "100"-
एक साथ ज़्यादा से ज़्यादा कनेक्शन की संख्या, रिमोट कैश/एक्स्क्यूटर तक सीमित रखें. डिफ़ॉल्ट तौर पर, वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है, इसलिए Bazel --remote_max_ connections को एक साथ किए जा सकने वाले अनुरोधों के मुताबिक बना सकता है.
जीआरपीसी रिमोट कैश/एक्स्क्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को हैंडल कर सकता है. इसलिए, Bazel `--remote_max_ connections * 100` एक साथ किए जा सकने वाले अनुरोधों को पूरा कर सकता है.
टैग:host_machine_resource_optimizations
--remote_proxy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer>
डिफ़ॉल्ट: "0"- रिमोट कैश में सेव की जाने वाली रिमोट ऐक्शन की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर करते हैं.
--remote_retries=<an integer>
डिफ़ॉल्ट: "5"- कुछ समय के लिए होने वाली गड़बड़ी को ठीक करने के लिए, कितनी बार कोशिश की जा सकती है. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
--remote_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"- रिमोट एक्ज़ीक्यूशन और कैश कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट करने और रीड टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो वैल्यू को सेकंड के तौर पर समझा जाता है.
--[no]remote_upload_local_results
डिफ़ॉल्ट: "सही"- अगर रिमोट कैश मेमोरी के साथ काम करती है और उपयोगकर्ता के पास इसकी अनुमति है, तो क्या यह लोकल तौर पर एक्ज़ीक्यूट की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है या नहीं.
--[no]remote_verify_downloads
डिफ़ॉल्ट: "सही"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Bazel, सभी रिमोट डाउनलोड के हैश योग का हिसाब लगाएगा. साथ ही, अगर रिमोट तौर पर कैश मेमोरी में सेव की गई वैल्यू, अनुमानित वैल्यू से मेल नहीं खाती है, तो उसे खारिज कर दिया जाएगा.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
--deleted_packages=<comma-separated list of package names>
डिफ़ॉल्ट: ""- पैकेज के नामों की कॉमा-सेपरेटेड लिस्ट, जिसे बिल्ड सिस्टम मानेगा. भले ही, वे पैकेज पाथ पर कहीं भी दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD को मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह इसकी शिकायत कर सकता है. ऐसा तब होता है, जब वह अब भी किसी दूसरी Package_path एंट्री में मौजूद हो. --deleted_packages x/y को तय करने से इस समस्या से बचा जा सकता है.
--disk_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जिसमें Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो इसे बना दिया जाएगा.
- ऐप्लिकेशन के
--experimental_credential_helper=<An (unresolved) path to a credential helper for a scope.>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि दिए गए स्कोप (डोमेन) के लिए क्रेडेंशियल वापस पाने में उसका इस्तेमाल किया जा सके. क्रेडेंशियल हेल्पर के क्रेडेंशियल को <code>--google_default_credentials</code>, `--google_क्रेडेंशियल` या <code>.netrc</code> से ज़्यादा अहमियत दी जाती है. https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-Credential-helpers की जानकारी देखें.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मिनट"- उस अवधि को कॉन्फ़िगर करता है जिसके लिए क्रेडेंशियल हेल्पर के क्रेडेंशियल, कैश मेमोरी में सेव किए जाते हैं. किसी दूसरी वैल्यू से शुरू करने पर, पहले से मौजूद एंट्री का लाइफ़टाइम बदल जाएगा; कैश मेमोरी मिटाने के लिए शून्य पास करें. क्लीन कमांड, कैश मेमोरी को हमेशा मिटाता है, भले ही यह फ़्लैग किसी भी तरह का हो.
--experimental_credential_helper_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "5s"- क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. क्रेडेंशियल सहायक इस टाइम आउट के अंदर जवाब नहीं दे पाने पर, बातचीत शुरू नहीं कर पाएंगे.
--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
डिफ़ॉल्ट: "false"- पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं. डिफ़ॉल्ट रूप से बंद होता है.
--grpc_keepalive_time=<An immutable length of time.>
डिफ़ॉल्ट: ब्यौरा देखें- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो Bazel इतने समय बाद कनेक्शन पर कोई कार्रवाई नहीं करने के बाद पिंग भेजता है. यह सिर्फ़ तब पिंग करता है, जब कम से कम एक gRPC कॉल लंबित हो. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. कीप-अलाइव पिंग, डिफ़ॉल्ट रूप से बंद रहते हैं. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक से संपर्क करना होगा. उदाहरण के लिए, इस फ़्लैग के लिए 30 सेकंड की वैल्यू सेट करने के लिए, इस तरह से सेट करना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "20 सेकंड"- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव (चालू रखें) टाइम आउट कॉन्फ़िगर करता है. अगर कीप-अलाइव पिंग को --grpc_keepalive_time से चालू किया जाता है, तो Bazel को इतने समय के बाद पिंग का जवाब न मिलने पर, कनेक्शन बंद कर दिया जाता है. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. अगर कीप-अलाइव पिंग को बंद रखा जाता है, तो इस सेटिंग को अनदेखा कर दिया जाता है.
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- कोलन से अलग की गई इस सूची में बताया जाता है कि पैकेज कहां खोजने हैं. '%workspace%' से शुरू होने वाले एलिमेंट, बंद होने वाले फ़ाइल फ़ोल्डर से मिलते-जुलते हैं. अगर इसे खाली छोड़ा जाता है या इसे खाली छोड़ा जाता है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट होता है.
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर इस सुविधा को चालू किया जाता है, तो Bazel "लोडिंग पैकेज:" मैसेज प्रिंट करेगा.
--tls_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- किसी TLS सर्टिफ़िकेट का पाथ बताएं, जो सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसेमंद हो.
--tls_client_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट के बारे में बताएं. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए, TLS क्लाइंट कुंजी तय करें. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
चलाने के विकल्प
build के सभी विकल्प इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, तय किए गए आउटपुट को कॉन्फ़िगर कर सकते हैं. इससे, उसकी वैल्यू पर असर पड़ता है, न कि उस पर असर होता है:
--script_path=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर सेट किया जाता है, तो टारगेट को शुरू करने वाली फ़ाइल के लिए एक शेल स्क्रिप्ट लिखें. अगर यह विकल्प सेट है, तो टारगेट को bazel से नहीं चलाया जाता. टारगेट '//foo' को शुरू करने के लिए 'bazel play --script_path=foo //foo && ./foo' का इस्तेमाल करें. यह 'bazel Run //foo' से अलग है, क्योंकि इसमें bazel लॉक रिलीज़ हो गया है और एक्ज़ीक्यूटेबल, टर्मिनल के स्टडिन से कनेक्ट है.
टैग:affects_outputs
,execution
- वे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग का कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
शटडाउन के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- निर्देश के आउटपुट को कंट्रोल करने वाले विकल्प:
--iff_heap_size_greater_than=<an integer>
डिफ़ॉल्ट: "0"-
अगर जेवीएम की कुल मेमोरी (एमबी में) इस वैल्यू से ज़्यादा है, तो शटडाउन शून्य के अलावा किसी दूसरी वैल्यू पर भी काम करेगा.
टैग:loses_incremental_state
,eagerness_to_exit
- इस बात पर असर डालने वाले विकल्प कि Bazel मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को पूरी तरह से कैसे लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
सिंक करने के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]configure
डिफ़ॉल्ट: "गलत"-
सिर्फ़ उन डेटा स्टोर करने की जगह को सिंक करें जिन्हें सिस्टम-कॉन्फ़िगरेशन के लिए, 'कॉन्फ़िगर करें' के तौर पर मार्क किया गया है.
टैग:changes_inputs
--[no]incompatible_remote_dangling_symlinks
डिफ़ॉल्ट: "सही"-
अगर सही पर सेट किया गया है और --insupported_remote_symlinks को भी सेट किया गया है, तो ऐक्शन आउटपुट में सिमलिंक को लटकने की अनुमति है.
टैग:execution
,incompatible_change
--[no]incompatible_remote_symlinks
डिफ़ॉल्ट: "सही"-
अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैशिंग/एक्ज़ीक्यूशन प्रोटोकॉल में ऐक्शन आउटपुट में सिमलिंक दिखाएगा. अगर ऐसा नहीं होता है, तो सिमलिंक का पालन किया जाएगा और उन्हें फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए #6631 पर जाएं.
टैग:execution
,incompatible_change
--[no]keep_going
[-k
] डिफ़ॉल्ट: "false"-
किसी गड़बड़ी के बाद, जितना हो सके उतना जारी रखें. हालांकि, फ़ेल हो चुके टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता, लेकिन इन टारगेट से जुड़ी दूसरी ज़रूरी शर्तें पूरी की जा सकती हैं.
टैग:eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "ऑटो"-
लोडिंग/विश्लेषण के चरण के लिए इस्तेमाल किए जाने वाले पैरलल थ्रेड की संख्या. इसके लिए, कोई पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") इस्तेमाल किया जाता है. वैकल्पिक रूप से, इसके बाद कोई कार्रवाई ([-|*]<Flo>) होती है. "auto", "Host_CPUS*.5". "auto", होस्ट के संसाधनों के आधार पर उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
- ऐप्लिकेशन के
--only=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर यह विकल्प दिया गया है, तो सिर्फ़ इस विकल्प के साथ बताए गए डेटा स्टोर करने की जगह को सिंक करें. फिर भी सभी (या सभी कॉन्फ़िगर-जैसे, कॉन्फ़िगरेशन) पुराने मानें.
टैग:changes_inputs
- ऐसे विकल्प जो उपयोगकर्ता को सही आउटपुट कॉन्फ़िगर करने की अनुमति देते हैं, उसकी वैल्यू पर असर पड़ता है, न कि उस पर असर होता है:
--bep_maximum_open_remote_upload_files=<an integer>
डिफ़ॉल्ट: "-1"-
BEP आर्टफ़ैक्ट अपलोड करने के दौरान, खुली हुई फ़ाइलों की ज़्यादा से ज़्यादा संख्या.
टैग:affects_outputs
--remote_download_minimal
-
लोकल मशीन पर, रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ शिपिंग_metadata और --remote_download_इस=minimal.
इसमें बड़ा होता है:
--nobuild_runfile_links
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=minimal
टैग:affects_outputs
--remote_download_outputs=<all, minimal or toplevel>
डिफ़ॉल्ट: "सभी"-
अगर इस नीति को 'मिनिमल' पर सेट किया जाता है, तो लोकल मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होगा. हालांकि, लोकल ऐक्शन के लिए ज़रूरी आउटपुट आउटपुट सिर्फ़ कुछ ही होंगे. अगर 'टॉप-लेवल' पर सेट किया जाता है, तो यह'कम से कम' की तरह काम करता है. अंतर सिर्फ़ यह है कि यह टॉप लेवल टारगेट के आउटपुट भी लोकल मशीन से डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ बहुत मुश्किल है, तो दोनों विकल्पों से बिल्ड में लगने वाला समय काफ़ी कम हो सकता है.
टैग:affects_outputs
--remote_download_symlink_template=<a string>
डिफ़ॉल्ट: ""-
लोकल मशीन पर रिमोट बिल्ड आउटपुट डाउनलोड करने के बजाय, सॉफ़्ट लिंक बनाएं. सिंबॉलिक लिंक का टारगेट, टेंप्लेट स्ट्रिंग के रूप में तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं, जो ऑब्जेक्ट के हैश तक और बाइट में साइज़ तक बढ़ते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर CAS से ऑब्जेक्ट लोड करते हैं.
टैग:affects_outputs
--remote_download_toplevel
-
टॉप लेवल टारगेट के रिमोट आउटपुट सिर्फ़ लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ प्रिंट_metadata और --remote_download_इस=toplevel.
यह इन पर लागू होता है:
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=toplevel
टैग:affects_outputs
- Bzel से मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "false"-
अगर sensitive_enforce_config_setting_ पहचानने के लिए गलत वैल्यू है, तो यह नॉप है. ऐसा न होने पर, अगर यह फ़्लैग गलत है, तो बिना किसी खास 'किसको दिखे' एट्रिब्यूट के बिना कोई भी config_setting //visible:public पर सेट कर दे. अगर यह फ़्लैग सही है, तो config_setting, दिखने के उसी लॉजिक का पालन करेगी जिसका इस्तेमाल दूसरे सभी नियमों के लिए किया जाता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट के लिए दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो Starlark की ऐसी वैल्यू लिखें जो Starlark के डेटा स्टोर करने की जगह के उन सभी नियमों की हल की गई जानकारी के साथ होती है जिन्हें लागू किया गया था.
टैग:affects_outputs
--remote_print_execution_messages=<failure, success or all>
डिफ़ॉल्ट: "failure"-
चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज को कब प्रिंट करना है. मान्य वैल्यू 'असफलता' होती हैं, सिर्फ़ काम न करने पर प्रिंट करने के लिए, सिर्फ़ सफलता पर प्रिंट करने के लिए `सफलता`, और हमेशा प्रिंट करने के लिए `सभी`.
टैग:terminal_output
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
--[no]experimental_guard_against_concurrent_changes
डिफ़ॉल्ट: "false"- रिमोट कैश मेमोरी में अपलोड करने से पहले, किसी कार्रवाई की इनपुट फ़ाइलों के समय की जांच करने की सुविधा बंद करने के लिए, इस सेटिंग को बंद करें. कुछ मामलों में, Linux kernel की वजह से फ़ाइलें लिखने में देरी हो सकती है. इसकी वजह से फ़ॉल्स पॉज़िटिव नतीजे मिल सकते हैं.
--experimental_remote_build_event_upload=<all or minimal>
डिफ़ॉल्ट: "सभी"- अगर यह वैल्यू 'सभी' पर सेट है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड किए जाते हैं. अगर इसे 'मिनिमल' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. हालांकि, BEP इस्तेमाल करने वालों के लिए ज़रूरी फ़ाइलें (जैसे, टेस्ट लॉग और टाइम प्रोफ़ाइल) होती हैं. file:// स्कीम का इस्तेमाल लोकल फ़ाइलों के पाथ के लिए होता है और bytestream:// स्कीम का इस्तेमाल अपलोड की गई (पहले से) फ़ाइलों के पाथ के लिए किया जाता है. डिफ़ॉल्ट रूप से 'सभी' चुनें.
--[no]experimental_remote_cache_async
डिफ़ॉल्ट: "false"- अगर सही है, तो रिमोट कैश I/O, इवेंट के इवेंट के तौर पर होने के बजाय, बैकग्राउंड में होगा.
--[no]experimental_remote_cache_compression
डिफ़ॉल्ट: "false"- अगर इस सेटिंग को चालू किया गया है, तो कैश ब्लॉब को zstd की मदद से कंप्रेस या डिकंप्रेस करें.
--experimental_remote_capture_corrupted_outputs=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जहां खराब आउटपुट को कैप्चर किया जाएगा.
--experimental_remote_downloader=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जा सकता है. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback
डिफ़ॉल्ट: "false"- रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर पर वापस जाना चाहिए या नहीं.
--[no]experimental_remote_execution_keepalive
डिफ़ॉल्ट: "false"- रिमोट एक्ज़ीक्यूशन कॉल के लिए कीपअलाइव (चालू रखें) का इस्तेमाल करना है या नहीं.
--experimental_remote_grpc_log=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry Protobufs के क्रम में, हर मैसेज के प्रीफ़िक्स वाला क्रम होता है. यह क्रम वाले इन प्रोटोबफ़ मैसेज के साइज़ को दिखाता है, जैसा कि LogEntry.writeDelimitedTo(OUTStream) के तरीके से किया गया है.
--[no]experimental_remote_mark_tool_inputs
डिफ़ॉल्ट: "false"- अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट परसिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache
डिफ़ॉल्ट: "false"- अगर नीति को 'सही है' पर सेट किया जाता है, तो मर्कल ट्री की कैलकुलेशन को याद किया जाएगा. इससे रिमोट कैश हिट का पता लगाने की स्पीड को बेहतर बनाने में मदद मिलेगी. कैश मेमोरी के पैर के मेमोरी प्रिंट को --experimental_remote_mercle_tree_cache_size की मदद से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer>
डिफ़ॉल्ट: "1000"- रिमोट कैश हिट चेकिंग स्पीड को बेहतर बनाने के लिए, याद किए जाने वाले मर्कले ट्री की संख्या. हालांकि, कैश को सॉफ़्ट रेफ़रंस पर Java की प्रोसेस के हिसाब से अपने-आप कम कर दिया जाता है, लेकिन बहुत ज़्यादा वैल्यू पर सेट करने पर, मेमोरी से बाहर की गड़बड़ियां हो सकती हैं. अगर यह 0 पर सेट है, तो कैश मेमोरी का साइज़ अनलिमिटेड है. सबसे अच्छी वैल्यू, प्रोजेक्ट के साइज़ के आधार पर अलग-अलग होती है. डिफ़ॉल्ट वैल्यू 1,000 होती है.
--[no]incompatible_remote_build_event_upload_respect_no_cache
डिफ़ॉल्ट: "false"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तरीके से कैश मेमोरी में सेव नहीं किया जा सकता.
--[no]incompatible_remote_downloader_send_all_headers
डिफ़ॉल्ट: "सही"-
कई वैल्यू वाले हेडर की सभी वैल्यू को पहले वाले हेडर के बजाय रिमोट डाउनलोडर को भेजना है या नहीं.
टैग:incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root
डिफ़ॉल्ट: "false"-
अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट से जुड़े होते हैं.
टैग:incompatible_change
--[no]incompatible_remote_results_ignore_disk
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो डिस्क कैश मेमोरी पर --noremote_upload_local_results और --noremote_accept_cached लागू नहीं किया जाएगा. अगर एक साथ कई कैश मेमोरी का इस्तेमाल किया जाता है:
--noremote_upload_local_results की वजह से नतीजे डिस्क की कैश मेमोरी में लिखे जाएंगे, लेकिन रिमोट कैश पर अपलोड नहीं किए जाएंगे.
--noremote_accept_cached का नतीजा डिस्क कैश में नतीजों की जांच करने के लिए, Bazel से होगा, लेकिन रिमोट कैश में नहीं.
no-remote-exec कार्रवाइयां डिस्क की कैश मेमोरी को दबा सकती हैं.
ज़्यादा जानकारी के लिए #8216 देखें.
टैग:incompatible_change
--[no]remote_accept_cached
डिफ़ॉल्ट: "सही"- रिमोट कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को स्वीकार करना है या नहीं.
--remote_bytestream_uri_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम, जिसे बिल्ड इवेंट स्ट्रीम में लिखा जाता है. यह विकल्प तब सेट किया जा सकता है, जब बिल्ड के लिए प्रॉक्सी का इस्तेमाल किया जाता है. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, अब रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इस नीति को सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.
--remote_cache=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- कैशिंग एंडपॉइंट का यूआरआई. इस तरह के स्कीमा के साथ काम करने वाले स्कीमा हैं एचटीटीपी, एचटीटीपीएस, जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc://, http:// या unix: schema के बारे में बताएं. https://bazel.build/remote/caching देखें
- ऐप्लिकेशन के
--remote_cache_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे कैश अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
- ऐप्लिकेशन के
--remote_default_exec_properties=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर कोई प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो डिफ़ॉल्ट exec प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए सेट करें.
टैग:affects_outputs
--remote_default_platform_properties=<a string>
डिफ़ॉल्ट: ""- अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से रिमोट_execution_properties सेट नहीं करता है, तो डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन एपीआई के लिए सेट करें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब रिमोट तौर पर एक्ज़ीक्यूशन के लिए, होस्ट प्लैटफ़ॉर्म को एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना गया हो.
- ऐप्लिकेशन के
--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>
डिफ़ॉल्ट: ब्यौरा देखें- होस्ट या होस्ट:रिमोट एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट नंबर. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
- ऐप्लिकेशन के
--remote_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
--remote_instance_name=<a string>
डिफ़ॉल्ट: ""- रिमोट एक्ज़ीक्यूशन एपीआई में, example_name के तौर पर पास करने वाली वैल्यू.
--[no]remote_local_fallback
डिफ़ॉल्ट: "false"- अगर रिमोट तरीके से एक्ज़ीक्यूट करने की सुविधा काम नहीं करती है, तो क्या आपको स्टैंडअलोन लोकल ऐक्शन रणनीति का इस्तेमाल करना चाहिए.
--remote_local_fallback_strategy=<a string>
डिफ़ॉल्ट: "स्थानीय"- नहीं, अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 देखें.
--remote_max_connections=<an integer>
डिफ़ॉल्ट: "100"-
एक साथ ज़्यादा से ज़्यादा कनेक्शन की संख्या, रिमोट कैश/एक्स्क्यूटर तक सीमित रखें. डिफ़ॉल्ट तौर पर, वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है, इसलिए Bazel --remote_max_ connections को एक साथ किए जा सकने वाले अनुरोधों के मुताबिक बना सकता है.
जीआरपीसी रिमोट कैश/एक्स्क्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को हैंडल कर सकता है. इसलिए, Bazel `--remote_max_ connections * 100` एक साथ किए जा सकने वाले अनुरोधों को पूरा कर सकता है.
टैग:host_machine_resource_optimizations
--remote_proxy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer>
डिफ़ॉल्ट: "0"- रिमोट कैश में सेव की जाने वाली रिमोट ऐक्शन की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर करते हैं.
--remote_retries=<an integer>
डिफ़ॉल्ट: "5"- कुछ समय के लिए होने वाली गड़बड़ी को ठीक करने के लिए, कितनी बार कोशिश की जा सकती है. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
--remote_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"- रिमोट एक्ज़ीक्यूशन और कैश कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट करने और रीड टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो वैल्यू को सेकंड के तौर पर समझा जाता है.
--[no]remote_upload_local_results
डिफ़ॉल्ट: "सही"- अगर रिमोट कैश मेमोरी के साथ काम करती है और उपयोगकर्ता के पास इसकी अनुमति है, तो क्या यह लोकल तौर पर एक्ज़ीक्यूट की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है या नहीं.
--[no]remote_verify_downloads
डिफ़ॉल्ट: "सही"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Bazel, सभी रिमोट डाउनलोड के हैश योग का हिसाब लगाएगा. साथ ही, अगर रिमोट तौर पर कैश मेमोरी में सेव की गई वैल्यू, अनुमानित वैल्यू से मेल नहीं खाती है, तो उसे खारिज कर दिया जाएगा.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
--deleted_packages=<comma-separated list of package names>
डिफ़ॉल्ट: ""- पैकेज के नामों की कॉमा-सेपरेटेड लिस्ट, जिसे बिल्ड सिस्टम मानेगा. भले ही, वे पैकेज पाथ पर कहीं भी दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD को मिटाने के बाद, अगर बिल्ड सिस्टम को '//x:y/z' लेबल मिलता है, तो वह इसकी शिकायत कर सकता है. ऐसा तब होता है, जब वह अब भी किसी दूसरी Package_path एंट्री में मौजूद हो. --deleted_packages x/y को तय करने से इस समस्या से बचा जा सकता है.
--disk_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जिसमें Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो इसे बना दिया जाएगा.
- ऐप्लिकेशन के
--experimental_credential_helper=<An (unresolved) path to a credential helper for a scope.>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि दिए गए स्कोप (डोमेन) के लिए क्रेडेंशियल वापस पाने में उसका इस्तेमाल किया जा सके. क्रेडेंशियल हेल्पर के क्रेडेंशियल को <code>--google_default_credentials</code>, `--google_क्रेडेंशियल` या <code>.netrc</code> से ज़्यादा अहमियत दी जाती है. https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-Credential-helpers की जानकारी देखें.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मिनट"- उस अवधि को कॉन्फ़िगर करता है जिसके लिए क्रेडेंशियल हेल्पर के क्रेडेंशियल, कैश मेमोरी में सेव किए जाते हैं. किसी दूसरी वैल्यू से शुरू करने पर, पहले से मौजूद एंट्री का लाइफ़टाइम बदल जाएगा; कैश मेमोरी मिटाने के लिए शून्य पास करें. क्लीन कमांड, कैश मेमोरी को हमेशा मिटाता है, भले ही यह फ़्लैग किसी भी तरह का हो.
--experimental_credential_helper_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "5s"- क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. क्रेडेंशियल सहायक इस टाइम आउट के अंदर जवाब नहीं दे पाने पर, बातचीत शुरू नहीं कर पाएंगे.
--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
डिफ़ॉल्ट: "false"- पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं. डिफ़ॉल्ट रूप से बंद होता है.
--grpc_keepalive_time=<An immutable length of time.>
डिफ़ॉल्ट: ब्यौरा देखें- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो Bazel इतने समय बाद कनेक्शन पर कोई कार्रवाई नहीं करने के बाद पिंग भेजता है. यह सिर्फ़ तब पिंग करता है, जब कम से कम एक gRPC कॉल लंबित हो. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. कीप-अलाइव पिंग, डिफ़ॉल्ट रूप से बंद रहते हैं. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक से संपर्क करना होगा. उदाहरण के लिए, इस फ़्लैग के लिए 30 सेकंड की वैल्यू सेट करने के लिए, इस तरह से सेट करना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "20 सेकंड"- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव (चालू रखें) टाइम आउट कॉन्फ़िगर करता है. अगर कीप-अलाइव पिंग को --grpc_keepalive_time से चालू किया जाता है, तो Bazel को इतने समय के बाद पिंग का जवाब न मिलने पर, कनेक्शन बंद कर दिया जाता है. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. अगर कीप-अलाइव पिंग को बंद रखा जाता है, तो इस सेटिंग को अनदेखा कर दिया जाता है.
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- कोलन से अलग की गई इस सूची में बताया जाता है कि पैकेज कहां खोजने हैं. '%workspace%' से शुरू होने वाले एलिमेंट, बंद होने वाले फ़ाइल फ़ोल्डर से मिलते-जुलते हैं. अगर इसे खाली छोड़ा जाता है या इसे खाली छोड़ा जाता है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट होता है.
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर इस सुविधा को चालू किया जाता है, तो Bazel "लोडिंग पैकेज:" मैसेज प्रिंट करेगा.
--tls_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- किसी TLS सर्टिफ़िकेट का पाथ बताएं, जो सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसेमंद हो.
--tls_client_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट के बारे में बताएं. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए, TLS क्लाइंट कुंजी तय करें. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
जांच के विकल्प
build के सभी विकल्प इनहेरिट करता है.
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- वे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]incompatible_remote_dangling_symlinks
डिफ़ॉल्ट: "सही"-
अगर सही पर सेट किया गया है और --insupported_remote_symlinks को भी सेट किया गया है, तो ऐक्शन आउटपुट में सिमलिंक को लटकने की अनुमति है.
टैग:execution
,incompatible_change
--[no]incompatible_remote_symlinks
डिफ़ॉल्ट: "सही"-
अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट कैशिंग/एक्ज़ीक्यूशन प्रोटोकॉल में ऐक्शन आउटपुट में सिमलिंक दिखाएगा. अगर ऐसा नहीं होता है, तो सिमलिंक का पालन किया जाएगा और उन्हें फ़ाइलों या डायरेक्ट्री के तौर पर दिखाया जाएगा. ज़्यादा जानकारी के लिए #6631 पर जाएं.
टैग:execution
,incompatible_change
- ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, सही आउटपुट को कॉन्फ़िगर करने की अनुमति देते हैं. इन विकल्पों की मदद से, टैग की वैल्यू पर असर पड़ता है, न कि उस पर असर होता है:
--bep_maximum_open_remote_upload_files=<an integer>
डिफ़ॉल्ट: "-1"-
BEP आर्टफ़ैक्ट अपलोड करने के दौरान, खुली हुई फ़ाइलों की ज़्यादा से ज़्यादा संख्या.
टैग:affects_outputs
--remote_download_minimal
-
लोकल मशीन पर, रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ शिपिंग_metadata और --remote_download_इस=minimal.
इसमें बड़ा होता है:
--nobuild_runfile_links
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=minimal
टैग:affects_outputs
--remote_download_outputs=<all, minimal or toplevel>
डिफ़ॉल्ट: "सभी"-
अगर इस नीति को 'मिनिमल' पर सेट किया जाता है, तो लोकल मशीन पर कोई भी रिमोट बिल्ड आउटपुट डाउनलोड नहीं होगा. हालांकि, लोकल ऐक्शन के लिए ज़रूरी आउटपुट आउटपुट सिर्फ़ कुछ ही होंगे. अगर 'टॉप-लेवल' पर सेट किया जाता है, तो यह'कम से कम' की तरह काम करता है. अंतर सिर्फ़ यह है कि यह टॉप लेवल टारगेट के आउटपुट भी लोकल मशीन से डाउनलोड करता है. अगर नेटवर्क बैंडविड्थ बहुत मुश्किल है, तो दोनों विकल्पों से बिल्ड में लगने वाला समय काफ़ी कम हो सकता है.
टैग:affects_outputs
--remote_download_symlink_template=<a string>
डिफ़ॉल्ट: ""-
लोकल मशीन पर रिमोट बिल्ड आउटपुट डाउनलोड करने के बजाय, सॉफ़्ट लिंक बनाएं. सिंबॉलिक लिंक का टारगेट, टेंप्लेट स्ट्रिंग के रूप में तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {hash} और {size_bytes} शामिल हो सकते हैं, जो ऑब्जेक्ट के हैश तक और बाइट में साइज़ तक बढ़ते हैं. उदाहरण के लिए, ये सिंबॉलिक लिंक ऐसे FUSE फ़ाइल सिस्टम पर ले जा सकते हैं जो मांग पर CAS से ऑब्जेक्ट लोड करते हैं.
टैग:affects_outputs
--remote_download_toplevel
-
टॉप लेवल टारगेट के रिमोट आउटपुट सिर्फ़ लोकल मशीन पर डाउनलोड करता है. यह फ़्लैग, फ़्लैग के लिए एक शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dotd_files, --experimental_action_cache_store_ प्रिंट_metadata और --remote_download_इस=toplevel.
यह इन पर लागू होता है:
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=toplevel
टैग:affects_outputs
- Bzel से मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को लागू करने के तरीके पर असर डालने वाले विकल्प:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
--[no]print_relative_test_log_paths
डिफ़ॉल्ट: "false"-
अगर सही है, तो किसी टेस्ट लॉग का पाथ प्रिंट करते समय, ऐसे मिलते-जुलते पाथ का इस्तेमाल करें जो 'टेस्टलॉग' सुविधा सिमलिंक का इस्तेमाल करता हो. ध्यान दें - बाद में किसी अलग कॉन्फ़िगरेशन के साथ 'build'/'test'/वगैरह शुरू करने से इस सिमलिंक का टारगेट बदल सकता है, जिसकी वजह से, पहले प्रिंट किया गया पाथ अब काम का नहीं रहता.
टैग:affects_outputs
--remote_print_execution_messages=<failure, success or all>
डिफ़ॉल्ट: "failure"-
चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज को कब प्रिंट करना है. मान्य वैल्यू 'असफलता' होती हैं, सिर्फ़ काम न करने पर प्रिंट करने के लिए, सिर्फ़ सफलता पर प्रिंट करने के लिए `सफलता`, और हमेशा प्रिंट करने के लिए `सभी`.
टैग:terminal_output
--[no]test_verbose_timeout_warnings
डिफ़ॉल्ट: "false"-
अगर सही हो, तो अतिरिक्त चेतावनियों को तब प्रिंट करें, जब जांच के चलने का असली समय, टेस्ट में बताए गए टाइम आउट (चाहे साफ़ तौर पर दिखे या साफ़ तौर पर) से मेल न खाता हो.
टैग:affects_outputs
--[no]verbose_test_summary
डिफ़ॉल्ट: "सही"-
अगर सही है, तो जांच की खास जानकारी में अतिरिक्त जानकारी (समय, रन न होने की संख्या वगैरह) प्रिंट करें.
टैग:affects_outputs
- Bzel कमांड के लिए सामान्य इनपुट को तय करने या उसमें बदलाव करने के विकल्प, जो अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
--[no]experimental_guard_against_concurrent_changes
डिफ़ॉल्ट: "false"- रिमोट कैश मेमोरी में अपलोड करने से पहले, किसी कार्रवाई की इनपुट फ़ाइलों के समय की जांच करने की सुविधा बंद करने के लिए, इस सेटिंग को बंद करें. कुछ मामलों में, Linux kernel की वजह से फ़ाइलें लिखने में देरी हो सकती है. इसकी वजह से फ़ॉल्स पॉज़िटिव नतीजे मिल सकते हैं.
--experimental_remote_build_event_upload=<all or minimal>
डिफ़ॉल्ट: "सभी"- अगर यह वैल्यू 'सभी' पर सेट है, तो बीईपी से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड किए जाते हैं. अगर इसे 'मिनिमल' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. हालांकि, BEP इस्तेमाल करने वालों के लिए ज़रूरी फ़ाइलें (जैसे, टेस्ट लॉग और टाइम प्रोफ़ाइल) होती हैं. file:// स्कीम का इस्तेमाल लोकल फ़ाइलों के पाथ के लिए होता है और bytestream:// स्कीम का इस्तेमाल अपलोड की गई (पहले से) फ़ाइलों के पाथ के लिए किया जाता है. डिफ़ॉल्ट रूप से 'सभी' चुनें.
--[no]experimental_remote_cache_async
डिफ़ॉल्ट: "false"- अगर सही है, तो रिमोट कैश I/O, इवेंट के इवेंट के तौर पर होने के बजाय, बैकग्राउंड में होगा.
--[no]experimental_remote_cache_compression
डिफ़ॉल्ट: "false"- अगर इस सेटिंग को चालू किया गया है, तो कैश ब्लॉब को zstd की मदद से कंप्रेस या डिकंप्रेस करें.
--experimental_remote_capture_corrupted_outputs=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जहां खराब आउटपुट को कैप्चर किया जाएगा.
--experimental_remote_downloader=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जा सकता है. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. देखें: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback
डिफ़ॉल्ट: "false"- रिमोट डाउनलोडर के काम न करने पर, लोकल डाउनलोडर पर वापस जाना चाहिए या नहीं.
--[no]experimental_remote_execution_keepalive
डिफ़ॉल्ट: "false"- रिमोट एक्ज़ीक्यूशन कॉल के लिए कीपअलाइव (चालू रखें) का इस्तेमाल करना है या नहीं.
--experimental_remote_grpc_log=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में सीरियलाइज़ किए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry Protobufs के क्रम में, हर मैसेज के प्रीफ़िक्स वाला क्रम होता है. यह क्रम वाले इन प्रोटोबफ़ मैसेज के साइज़ को दिखाता है, जैसा कि LogEntry.writeDelimitedTo(OUTStream) के तरीके से किया गया है.
--[no]experimental_remote_mark_tool_inputs
डिफ़ॉल्ट: "false"- अगर 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट को टूल इनपुट के तौर पर मार्क करेगा. इसका इस्तेमाल, रिमोट परसिस्टेंट वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache
डिफ़ॉल्ट: "false"- अगर नीति को 'सही है' पर सेट किया जाता है, तो मर्कल ट्री की कैलकुलेशन को याद किया जाएगा. इससे रिमोट कैश हिट का पता लगाने की स्पीड को बेहतर बनाने में मदद मिलेगी. कैश मेमोरी के पैर के मेमोरी प्रिंट को --experimental_remote_mercle_tree_cache_size की मदद से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer>
डिफ़ॉल्ट: "1000"- रिमोट कैश हिट चेकिंग स्पीड को बेहतर बनाने के लिए, याद किए जाने वाले मर्कले ट्री की संख्या. हालांकि, कैश को सॉफ़्ट रेफ़रंस पर Java की प्रोसेस के हिसाब से अपने-आप कम कर दिया जाता है, लेकिन बहुत ज़्यादा वैल्यू पर सेट करने पर, मेमोरी से बाहर की गड़बड़ियां हो सकती हैं. अगर यह 0 पर सेट है, तो कैश मेमोरी का साइज़ अनलिमिटेड है. सबसे अच्छी वैल्यू, प्रोजेक्ट के साइज़ के आधार पर अलग-अलग होती है. डिफ़ॉल्ट वैल्यू 1,000 होती है.
--[no]incompatible_remote_build_event_upload_respect_no_cache
डिफ़ॉल्ट: "false"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो बीईपी से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते. ऐसा तब होता है, जब जनरेट करने वाली कार्रवाई को रिमोट तरीके से कैश मेमोरी में सेव नहीं किया जा सकता.
--[no]incompatible_remote_downloader_send_all_headers
डिफ़ॉल्ट: "सही"-
कई वैल्यू वाले हेडर की सभी वैल्यू को पहले वाले हेडर के बजाय रिमोट डाउनलोडर को भेजना है या नहीं.
टैग:incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root
डिफ़ॉल्ट: "false"-
अगर इसे 'सही है' पर सेट किया जाता है, तो आउटपुट पाथ, वर्किंग डायरेक्ट्री के बजाय इनपुट रूट से जुड़े होते हैं.
टैग:incompatible_change
--[no]incompatible_remote_results_ignore_disk
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो डिस्क कैश मेमोरी पर --noremote_upload_local_results और --noremote_accept_cached लागू नहीं किया जाएगा. अगर एक साथ कई कैश मेमोरी का इस्तेमाल किया जाता है:
--noremote_upload_local_results की वजह से नतीजे डिस्क की कैश मेमोरी में लिखे जाएंगे, लेकिन रिमोट कैश पर अपलोड नहीं किए जाएंगे.
--noremote_accept_cached का नतीजा डिस्क कैश में नतीजों की जांच करने के लिए, Bazel से होगा, लेकिन रिमोट कैश में नहीं.
no-remote-exec कार्रवाइयां डिस्क की कैश मेमोरी को दबा सकती हैं.
ज़्यादा जानकारी के लिए #8216 देखें.
टैग:incompatible_change
--[no]remote_accept_cached
डिफ़ॉल्ट: "सही"- रिमोट कैश मेमोरी में सेव की गई कार्रवाई के नतीजों को स्वीकार करना है या नहीं.
--remote_bytestream_uri_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- bytestream:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम, जिसे बिल्ड इवेंट स्ट्रीम में लिखा जाता है. यह विकल्प तब सेट किया जा सकता है, जब बिल्ड के लिए प्रॉक्सी का इस्तेमाल किया जाता है. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, अब रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इस नीति को सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट होगा.
--remote_cache=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- कैशिंग एंडपॉइंट का यूआरआई. इस तरह के स्कीमा के साथ काम करने वाले स्कीमा हैं एचटीटीपी, एचटीटीपीएस, जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc://, http:// या unix: schema के बारे में बताएं. https://bazel.build/remote/caching देखें
- ऐप्लिकेशन के
--remote_cache_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे कैश अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
- ऐप्लिकेशन के
--remote_default_exec_properties=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर कोई प्लैटफ़ॉर्म पहले से exec_properties सेट नहीं करता है, तो डिफ़ॉल्ट exec प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए सेट करें.
टैग:affects_outputs
--remote_default_platform_properties=<a string>
डिफ़ॉल्ट: ""- अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से रिमोट_execution_properties सेट नहीं करता है, तो डिफ़ॉल्ट प्लैटफ़ॉर्म प्रॉपर्टी को रिमोट तौर पर एक्ज़ीक्यूशन एपीआई के लिए सेट करें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब रिमोट तौर पर एक्ज़ीक्यूशन के लिए, होस्ट प्लैटफ़ॉर्म को एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर चुना गया हो.
- ऐप्लिकेशन के
--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>
डिफ़ॉल्ट: ब्यौरा देखें- होस्ट या होस्ट:रिमोट एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट नंबर. इस तरह के स्कीमा का इस्तेमाल किया जा सकता है: जीआरपीसी, grpcs (TLS चालू किए गए Grpc) और unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. TLS को बंद करने के लिए, grpc:// या unix: स्कीमा के बारे में बताएं.
- ऐप्लिकेशन के
--remote_header=<a 'name=value' assignment>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - कोई ऐसा हेडर तय करें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को कई बार तय करके, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल दी जाएंगी.
--remote_instance_name=<a string>
डिफ़ॉल्ट: ""- रिमोट एक्ज़ीक्यूशन एपीआई में, example_name के तौर पर पास करने वाली वैल्यू.
--[no]remote_local_fallback
डिफ़ॉल्ट: "false"- अगर रिमोट तरीके से एक्ज़ीक्यूट करने की सुविधा काम नहीं करती है, तो क्या आपको स्टैंडअलोन लोकल ऐक्शन रणनीति का इस्तेमाल करना चाहिए.
--remote_local_fallback_strategy=<a string>
डिफ़ॉल्ट: "स्थानीय"- नहीं, अब काम नहीं करता. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 देखें.
--remote_max_connections=<an integer>
डिफ़ॉल्ट: "100"-
एक साथ ज़्यादा से ज़्यादा कनेक्शन की संख्या, रिमोट कैश/एक्स्क्यूटर तक सीमित रखें. डिफ़ॉल्ट तौर पर, वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है.
एचटीटीपी रिमोट कैश मेमोरी के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है, इसलिए Bazel --remote_max_ connections को एक साथ किए जा सकने वाले अनुरोधों के मुताबिक बना सकता है.
जीआरपीसी रिमोट कैश/एक्स्क्यूटर के लिए, एक gRPC चैनल आम तौर पर एक साथ 100 से ज़्यादा अनुरोधों को हैंडल कर सकता है. इसलिए, Bazel `--remote_max_ connections * 100` एक साथ किए जा सकने वाले अनुरोधों को पूरा कर सकता है.
टैग:host_machine_resource_optimizations
--remote_proxy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer>
डिफ़ॉल्ट: "0"- रिमोट कैश में सेव की जाने वाली रिमोट ऐक्शन की प्राथमिकता. प्राथमिकता वाली खास वैल्यू के सिमेंटिक्स, सर्वर पर निर्भर करते हैं.
--remote_retries=<an integer>
डिफ़ॉल्ट: "5"- कुछ समय के लिए होने वाली गड़बड़ी को ठीक करने के लिए, कितनी बार कोशिश की जा सकती है. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
--remote_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"- रिमोट एक्ज़ीक्यूशन और कैश कॉल के लिए इंतज़ार करने का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट करने और रीड टाइम आउट, दोनों है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो वैल्यू को सेकंड के तौर पर समझा जाता है.
--[no]remote_upload_local_results
डिफ़ॉल्ट: "सही"- अगर रिमोट कैश मेमोरी के साथ काम करती है और उपयोगकर्ता के पास इसकी अनुमति है, तो क्या यह लोकल तौर पर एक्ज़ीक्यूट की गई कार्रवाई के नतीजों को रिमोट कैश मेमोरी में अपलोड करना है या नहीं.
--[no]remote_verify_downloads
डिफ़ॉल्ट: "सही"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Bazel, सभी रिमोट डाउनलोड के हैश योग का हिसाब लगाएगा. साथ ही, अगर रिमोट तौर पर कैश मेमोरी में सेव की गई वैल्यू, अनुमानित वैल्यू से मेल नहीं खाती है, तो उसे खारिज कर दिया जाएगा.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
--disk_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जिसमें Bazel, कार्रवाइयों और ऐक्शन के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो इसे बना दिया जाएगा.
- ऐप्लिकेशन के
--experimental_credential_helper=<An (unresolved) path to a credential helper for a scope.>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि दिए गए स्कोप (डोमेन) के लिए क्रेडेंशियल वापस पाने में उसका इस्तेमाल किया जा सके. क्रेडेंशियल हेल्पर के क्रेडेंशियल को <code>--google_default_credentials</code>, `--google_क्रेडेंशियल` या <code>.netrc</code> से ज़्यादा अहमियत दी जाती है. https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-Credential-helpers की जानकारी देखें.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मिनट"- उस अवधि को कॉन्फ़िगर करता है जिसके लिए क्रेडेंशियल हेल्पर के क्रेडेंशियल, कैश मेमोरी में सेव किए जाते हैं. किसी दूसरी वैल्यू से शुरू करने पर, पहले से मौजूद एंट्री का लाइफ़टाइम बदल जाएगा; कैश मेमोरी मिटाने के लिए शून्य पास करें. क्लीन कमांड, कैश मेमोरी को हमेशा मिटाता है, भले ही यह फ़्लैग किसी भी तरह का हो.
--experimental_credential_helper_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "5s"- क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है. क्रेडेंशियल सहायक इस टाइम आउट के अंदर जवाब नहीं दे पाने पर, बातचीत शुरू नहीं कर पाएंगे.
--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
डिफ़ॉल्ट: "false"- पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, https://cloud.google.com/docs/authentication पर जाएं. डिफ़ॉल्ट रूप से बंद होता है.
--grpc_keepalive_time=<An immutable length of time.>
डिफ़ॉल्ट: ब्यौरा देखें- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो Bazel इतने समय बाद कनेक्शन पर कोई कार्रवाई नहीं करने के बाद पिंग भेजता है. यह सिर्फ़ तब पिंग करता है, जब कम से कम एक gRPC कॉल लंबित हो. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. कीप-अलाइव पिंग, डिफ़ॉल्ट रूप से बंद रहते हैं. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक से संपर्क करना होगा. उदाहरण के लिए, इस फ़्लैग के लिए 30 सेकंड की वैल्यू सेट करने के लिए, इस तरह से सेट करना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "20 सेकंड"- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव (चालू रखें) टाइम आउट कॉन्फ़िगर करता है. अगर कीप-अलाइव पिंग को --grpc_keepalive_time से चालू किया जाता है, तो Bazel को इतने समय के बाद पिंग का जवाब न मिलने पर, कनेक्शन बंद कर दिया जाता है. समय को दूसरी जानकारी के स्तर के तौर पर माना जाता है. एक सेकंड से कम का मान सेट करना एक गड़बड़ी है. अगर कीप-अलाइव पिंग को बंद रखा जाता है, तो इस सेटिंग को अनदेखा कर दिया जाता है.
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
--tls_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- किसी TLS सर्टिफ़िकेट का पाथ बताएं, जो सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसेमंद हो.
--tls_client_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट के बारे में बताएं. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए, TLS क्लाइंट कुंजी तय करें. क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
वर्शन के विकल्प
- कमांड से पहले दिखने वाले और क्लाइंट के ज़रिए पार्स किए गए विकल्प:
- ऐप्लिकेशन के
--distdir=<a path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
संग्रह डाउनलोड करने के लिए नेटवर्क ऐक्सेस करने से पहले, संग्रह खोजने के लिए अतिरिक्त जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "false"-
अगर सेट किया जाता है, तो डेटा स्टोर करने की जगह की कैश मेमोरी, कॉपी करने के बजाय कैश हिट होने पर फ़ाइल को हार्डलिंक करेगी. डिस्क की जगह बचाने के लिए ऐसा किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "false"-
अगर सही है, तो रिपॉज़िटरी डाउनलोड के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल आईडी के तौर पर करें. अगर इसके बारे में नहीं बताया गया है, तो ऐसा करें. इससे यूआरएल में बदलाव होता है और उन्हें फिर से डाउनलोड किया जाता है, भले ही कैश में उसी हैश वाला कोई डाउनलोड मौजूद हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव करने की वजह से, गलत डेटा स्टोर करने की जगहों को कैश मेमोरी की मदद से मास्क न किया जाए.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "false"-
इस नीति को सेट करने पर, बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं होती.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड से जुड़ी गड़बड़ी को ठीक करने की कोशिश की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो बार-बार कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark रिपॉज़िटरी के नियमों में सभी टाइम आउट को स्केल करें. इस तरह, बाहरी डेटा स्टोर करने की जगह ऐसी मशीनों पर काम करती हैं जो नियम बनाने वाले की उम्मीद से धीमी हैं.
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट को दिए गए फ़ैक्टर के हिसाब से स्केल करें
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति, बाहरी डेटा स्टोर करने की जगहों को फ़ेच करने के दौरान डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह बताती है. तर्क के तौर पर एक खाली स्ट्रिंग, कैश मेमोरी को बंद करने का अनुरोध करती है.
टैग:bazel_internal_configuration
- ऐसे विकल्प जिनकी मदद से उपयोगकर्ता, तय किए गए आउटपुट को कॉन्फ़िगर कर सकते हैं. इससे, उसकी वैल्यू पर असर पड़ता है, न कि उस पर असर होता है:
--[no]gnu_format
डिफ़ॉल्ट: "false"-
अगर सेट हो, तो GNU स्टैंडर्ड में बताए गए तरीकों का इस्तेमाल करके, वर्शन को stdout में लिखें.
टैग:affects_outputs
,execution
- वे विकल्प जो इस बात पर असर डालते हैं कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग का कॉम्बिनेशन वगैरह) को किस तरह लागू करता है:
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह खाली नहीं है, तो यह ऐसी फ़ाइल के बारे में बताता है जिसमें रिज़ॉल्व की गई वैल्यू मौजूद है और इसके लिए रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
- ऐप्लिकेशन के
--experimental_verify_repository_rules=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
अगर रिपॉज़िटरी के नियमों की ऐसी सूची है जिसके हिसाब से, आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, तो यह ज़रूरी है कि फ़ाइल, --experimental_repository_hash_file में दी गई हो.
टैग:affects_outputs
,experimental
- यह विकल्प, Starlark भाषा के सिमैंटिक या उस बिल्ड एपीआई पर असर डालता है जिसे BUILD फ़ाइलों, .bzl फ़ाइलों या वर्कस्पेस फ़ाइलों से ऐक्सेस किया जा सकता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
No-op
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
- ऐप्लिकेशन के
--allow_yanked_versions=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
मॉड्यूल के वर्शन की जानकारी `<module1>@<version1>,<module2>@<version2>` में डालें, जिसे हल किए गए डिपेंडेंसी ग्राफ़ में इस्तेमाल किया जा सकता है. भले ही, उन्हें रजिस्ट्री में यंक किए गए के तौर पर सेट किया गया हो, जहां से वे आते हैं. ऐसा तब भी किया जा सकता है, जब वे गैर-रजिस्ट्री ओवरराइड से न आ रहे हों. ऐसा न करने पर, यंक किए गए वर्शन की वजह से रिज़ॉल्यूशन फ़ेल हो जाएगा. `BZLMOD_ALLOW_YANKED_VERSIONS` एनवायरमेंट वैरिएबल के साथ, अनुमति वाले यांक किए गए वर्शन को भी तय किया जा सकता है. 'सभी' कीवर्ड का इस्तेमाल करके, इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
देखें कि Bazel मॉड्यूल के साथ bazel वर्शन काम करता है या नहीं. मान्य वैल्यू वे होती हैं जिन्हें समस्या को हल करने के लिए भेजने के लिए `गड़बड़ी`, जांच को बंद करने के लिए `बंद` या मेल न खाने पर चेतावनी प्रिंट करने के लिए `बंद` किया जाता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में सीधे तौर पर बताई गई `bazel_dep` डिपेंडेंसी, समाधान किए गए डिपेंडेंसी ग्राफ़ में दिए गए वर्शन जैसे ही हैं या नहीं. जांच की सुविधा बंद करने के लिए, मान्य वैल्यू 'बंद' हैं. मेल न खाने पर चेतावनी को प्रिंट करने के लिए `चेतावनी` या मेल न खाने पर `गड़बड़ी`, समाधान न होने पर सूचना देने के लिए.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "false"-
अगर सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को अनदेखा कर देता है. ध्यान दें कि अगर वह रूट मॉड्यूल नहीं है, तो MODULE.bazel में उन डेवलपर डिपेंडेंसी को हमेशा अनदेखा किया जाता है. भले ही, इस फ़्लैग की वैल्यू कुछ भी हो.
टैग:loading_and_analysis
- ऐप्लिकेशन के
--override_module=<an equals-separated mapping of module name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री वाले मॉड्यूल को बदलता है.
- ऐप्लिकेशन के
--registry=<a string>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है -
Bzel मॉड्यूल डिपेंडेंसी का पता लगाने के लिए, इस्तेमाल की जाने वाली रजिस्ट्री तय करता है. क्रम अहम है: मॉड्यूल को पहले पिछली रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब ही देखा जाएगा, जब वे पहले वाली रजिस्ट्री में मौजूद नहीं होंगे.
टैग:changes_inputs
- ऐसे विकल्प जो डेटा की जानकारी, उनके फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "false"- डिफ़ॉल्ट रूप से, ऐक्शन टाइप की संख्या 20 मिनिमनिक तक सीमित होती है. साथ ही, सबसे ज़्यादा कार्रवाइयां की जा सकती हैं. इस विकल्प को सेट करने से सभी स्मृतियों के आंकड़े लिखे जाएंगे.
- ऐसे विकल्प जो Bazel कमांड में सामान्य इनपुट के बारे में बताते हैं या उसमें बदलाव करते हैं. ये विकल्प अन्य कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय तय की गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और प्रोसेस करने के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक निर्देश (`अनुमति दें`, `ब्लॉक करें` या `फिर से लिखें`) से शुरू होती है जिसके बाद एक होस्ट नाम (‘अनुमति दें` और `ब्लॉक करें` के लिए) या दो पैटर्न, एक का मिलान करने के लिए और एक विकल्प यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें `$1` से शुरू होने वाली पिछली-पहचान होती हैं. एक ही यूआरएल के लिए कई `फिर से लिखें` निर्देश देना संभव है और इस मामले में एक से ज़्यादा यूआरएल दिए जाएंगे.
- दूसरे विकल्प, जिन्हें अलग से किसी कैटगरी में नहीं रखा गया हो.:
- ऐप्लिकेशन के
--override_repository=<an equals-separated mapping of repository name to path>
बार इस्तेमाल करने का डेटा इकट्ठा किया गया है - लोकल डायरेक्ट्री के साथ रिपॉज़िटरी को बदलता है.
विकल्प इफ़ेक्ट टैग
unknown |
इस विकल्प में ऐसे इफ़ेक्ट होते हैं जिनके बारे में जानकारी नहीं है या जिनके बारे में कोई दस्तावेज़ नहीं दिया गया है. |
no_op |
इस विकल्प का कोई असर नहीं पड़ता. |
loses_incremental_state |
इस विकल्प की वैल्यू बदलने से इंक्रीमेंटल स्थिति में काफ़ी कमी आ सकती है. इससे बिल्ड धीमा हो जाता है. सर्वर के रीस्टार्ट होने या डिपेंडेंसी ग्राफ़ के एक बड़े हिस्से के अमान्य होने की वजह से, हो सकता है कि स्टेटस खत्म हो जाए. |
changes_inputs |
यह विकल्प उन इनपुट को सक्रिय रूप से बदल देता है जिन्हें bazel बिल्ड के लिए मानता है, जैसे कि फ़ाइल सिस्टम पाबंदियां, रिपॉज़िटरी वर्शन या अन्य विकल्प. |
affects_outputs |
यह विकल्प bazel के आउटपुट पर असर डालता है. यह टैग जान-बूझकर बड़ा किया गया है. इसमें ट्रांज़िटिव असर शामिल हो सकता है और इससे पड़ने वाले आउटपुट के बारे में कोई जानकारी नहीं दी गई है. |
build_file_semantics |
यह विकल्प BUILD या .bzl फ़ाइलों के सिमैंटिक पर असर डालता है. |
bazel_internal_configuration |
यह विकल्प, bazel-internal मशीनरी की सेटिंग पर असर डालता है. इस टैग का मतलब यह नहीं है कि बिल्ड आर्टफ़ैक्ट पर कोई असर पड़ा है. |
loading_and_analysis |
यह विकल्प, डिपेंडेंसी का ग्राफ़ बनाने और लोड होने के साथ-साथ उसका विश्लेषण करने पर भी असर डालता है. |
execution |
यह विकल्प, एक्ज़ीक्यूशन के चरण पर असर डालता है. जैसे, सैंडबॉक्सिंग या रिमोट एक्ज़ीक्यूशन से जुड़े विकल्प. |
host_machine_resource_optimizations |
यह विकल्प ऐसे ऑप्टिमाइज़ेशन को ट्रिगर करता है जो किसी मशीन से जुड़ा हो सकता है और जिसके सभी मशीनों पर काम करने की गारंटी नहीं है. ऑप्टिमाइज़ेशन में, परफ़ॉर्मेंस के अन्य पहलुओं, जैसे कि मेमोरी या सीपीयू की लागत के साथ ट्रेड-ऑफ़ शामिल हो सकता है. |
eagerness_to_exit |
यह विकल्प इस बात को बदलता है कि बड़ी बेताबी से काम न आने पर, बैजल कितनी देर तक काम करेगा. इसमें असफलता के बावजूद आगे बढ़ने और बातचीत को खत्म करने का विकल्प होता है. |
bazel_monitoring |
इस विकल्प का इस्तेमाल, बाज़ल के व्यवहार और परफ़ॉर्मेंस को मॉनिटर करने के लिए किया जाता है. |
terminal_output |
यह विकल्प, bazel के टर्मिनल आउटपुट पर असर डालता है. |
action_command_lines |
यह विकल्प, एक या उससे ज़्यादा बिल्ड ऐक्शन के कमांड लाइन आर्ग्युमेंट को बदलता है. |
test_runner |
यह विकल्प बिल्ड के टेस्टर एनवायरमेंट को बदल देता है. |
विकल्प मेटाडेटा टैग
experimental |
यह विकल्प, प्रयोग के तौर पर शुरू की गई ऐसी सुविधा को ट्रिगर करता है जिसके काम करने के तरीके की कोई गारंटी नहीं होती. |
incompatible_change |
यह विकल्प, नुकसान पहुंचा सकने वाले बदलाव को ट्रिगर करता है. माइग्रेशन के लिए पूरी तरह तैयार है या नहीं, इसकी जांच करने या नई सुविधा को रिलीज़ होने से पहले इस्तेमाल करने के लिए, इस विकल्प का इस्तेमाल करें |
deprecated |
यह विकल्प अब काम नहीं करता. ऐसा हो सकता है कि जिस सुविधा पर इसका असर पड़ रहा है वह अब काम न करती हो या जानकारी देने के लिए किसी दूसरे तरीके को प्राथमिकता दी गई हो. |
explicit_in_output_path |
यह विकल्प आउटपुट डायरेक्ट्री में साफ़ तौर पर बताया गया है. |