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 |
बेज़ल सर्वर प्रोसेस की अंदरूनी स्थिति को डंप करता है. |
fetch |
बाहरी रिपॉज़िटरी फ़ेच करता है, जो टारगेट के लिए ज़रूरी शर्तें हैं. |
help |
प्रिंट आदेश या इंडेक्स के लिए सहायता करता है. |
info |
bazel सर्वर के बारे में रनटाइम जानकारी दिखाता है. |
license |
इस सॉफ़्टवेयर के लाइसेंस को प्रिंट करता है. |
mobile-install |
मोबाइल डिवाइसों पर टारगेट इंस्टॉल करता है. |
modquery |
Bzlmod के बाहरी डिपेंडेंसी ग्राफ़ की क्वेरी |
print_action |
फ़ाइल को कंपाइल करने के लिए, कमांड लाइन आर्ग्युमेंट को प्रिंट करता है. |
query |
डिपेंडेंसी ग्राफ़ क्वेरी लागू करता है. |
run |
बताए गए टारगेट को चलाता है. |
shutdown |
आपको बेज़ल सर्वर बंद करना होगा. |
sync |
फ़ाइल फ़ोल्डर की फ़ाइल में दी गई सभी रिपॉज़िटरी सिंक की जाती हैं |
test |
तय किए गए टेस्ट टारगेट बनाता और चलाता है. |
version |
वर्शन की जानकारी प्रिंट करने के लिए. |
स्टार्टअप के विकल्प
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने उन्हें पार्स किया है:
--[no]autodetect_server_javabase
डिफ़ॉल्ट: "सही"-
जब --noautodetect_server_javabase पास किया जाता है, तो बेज़ल, बेज़ल सर्वर चलाने के लिए स्थानीय जेडीके के पास नहीं जाता.
टैग:affects_outputs
,loses_incremental_state
--[no]batch
डिफ़ॉल्ट: "गलत"-
अगर सेट किया जाता है, तो Bazel, स्टैंडर्ड क्लाइंट/सर्वर मोड के बजाय सर्वर के बजाय क्लाइंट प्रोसेस के तौर पर चलेगा. इसे बंद कर दिया गया है और इसे हटा दिया जाएगा. अगर आप इंतज़ार कर रहे सर्वर से बचना चाहते हैं, तो कृपया साफ़ तौर पर सर्वर बंद कर दें.
टैग:loses_incremental_state
,bazel_internal_configuration
,deprecated
--[no]batch_cpu_scheduling
डिफ़ॉल्ट: "गलत"-
सिर्फ़ Linux पर: Blaze के लिए, 'बैच' सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति उन वर्कलोड के लिए फ़ायदेमंद है जो इंटरैक्टिव नहीं होते, लेकिन उनकी अहमियत को कम नहीं करना चाहते. 'पुरुष 2 scher_setscheduler' देखें. गलत होने पर, Bazel सिस्टम कॉल नहीं करता है.
टैग:host_machine_resource_optimizations
--bazelrc=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
उपयोगकर्ता .bazelrc फ़ाइल की जगह, जहां Bazel के विकल्पों की डिफ़ॉल्ट वैल्यू मौजूद हैं. /dev/null यह बताता है कि आगे की सभी `--bazelrc`को अनदेखा कर दिया जाएगा और यह उपयोगकर्ता rc फ़ाइल में खोज को बंद करने में मदद करता है, जैसे रिलीज़ बिल्ड में.
यह विकल्प एक से ज़्यादा बार भी बताया जा सकता है.
जैसे `--bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc`,
1) x.rc और y.rc को पढ़ लिया जाता है.
2) /.com के पिछले /dev/null की वजह से z.rc को अनदेखा किया जाता है.
अगर जानकारी नहीं दी गई हो, तो Bazel, इन दो जगहों पर दिखने वाली पहली .bazelrc फ़ाइल का इस्तेमाल करता है: फ़ाइल फ़ोल्डर की डायरेक्ट्री, फिर उपयोगकर्ता की होम डायरेक्ट्री.
ध्यान दें: बैच लाइन के किसी भी विकल्प की जगह, कमांड लाइन के विकल्प हमेशा लागू होंगे.
टैग:changes_inputs
--[no]block_for_lock
डिफ़ॉल्ट: "सही"-
जब --noblock_for_lock का इस्तेमाल होता है, तो बज़ल दौड़ने वाले कमांड के पूरा होने का इंतज़ार नहीं करता, बल्कि तुरंत बाहर निकल जाता है.
टैग:eagerness_to_exit
--[no]client_debug
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो क्लाइंट से डीबग करने के लिए डीबग जानकारी लॉग करें. इस विकल्प को बदलने से सर्वर रीस्टार्ट नहीं होगा.
टैग:affects_outputs
,bazel_monitoring
--connect_timeout_secs=<an integer>
डिफ़ॉल्ट: "30"-
सर्वर से कनेक्ट करने के लिए क्लाइंट के हर बार इंतज़ार करने का समय
टैग:bazel_internal_configuration
--[no]expand_configs_in_place
डिफ़ॉल्ट: "सही"-
सामान्य कॉन्फ़िगरेशन और कमांड लाइन के तय विकल्पों के बीच तय किए गए पॉइंट को बढ़ाने के बजाय, 'कॉन्फ़िगर करें' फ़्लैग की जगह को तय किया गया है.
टैग:no_op
,deprecated
--failure_detail_out=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर इस नीति को सेट किया जाता है, तो सर्वर के काम न कर पाने की स्थिति में 'GerPC' की मदद से शिकायत करने के साथ-साथ, खराबी_पूरी जानकारी वाला प्रोटोटाइप लिखने के लिए, जगह की जानकारी देता है. नहीं तो, जगह की जानकारी ${EXPIRE_BASE}/failure_detail.rawproto होगी.
टैग:affects_outputs
,loses_incremental_state
--[no]home_rc
डिफ़ॉल्ट: "सही"- $HOME/.bazenrc पर, घर पर मौजूद बजर फ़ाइल को ढूंढना है या नहीं
टैग:changes_inputs
--[no]idle_server_tasks
डिफ़ॉल्ट: "सही"-
सर्वर के कुछ समय से इस्तेमाल में न होने पर, System.gc() चलाएं
टैग:loses_incremental_state
,host_machine_resource_optimizations
--[no]ignore_all_rc_files
डिफ़ॉल्ट: "गलत"-
इससे, सभी आरसी फ़ाइलों को बंद कर दिया जाता है, फिर चाहे rc-बदलाव करने वाले दूसरे फ़्लैग की वैल्यू कुछ भी हो. भले ही, इन फ़्लैग को बाद में, स्टार्टअप के विकल्पों की सूची में शामिल किया गया हो.
टैग:changes_inputs
- डिफ़ॉल्ट
--io_nice_level={-1,0,1,2,3,4,5,6,7}
: "-1" -
सिर्फ़ Linux पर, sys_ioprio_set सिस्टम कॉल का इस्तेमाल करके, शेड्यूल करने की सबसे अच्छी जानकारी के लिए 0 से 7 तक का लेवल सेट करें. शून्य सबसे ज़्यादा प्राथमिकता है, 7 सबसे कम है. मीटिंग शेड्यूल करने वाला व्यक्ति, प्राथमिकता 4 के तहत ही ऐसा कर सकता है. अगर नेगेटिव वैल्यू पर सेट किया जाता है, तो 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>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर इस नीति को सेट किया जाता है, तो आउटपुट की वह जगह तय होती है जहां बिल्ड का पूरा आउटपुट लिखा जाएगा. अगर ऐसा नहीं है, तो जगह की जानकारी ${EXPIRE_ROOT}/_blaze_${USER}/${MD5_OF_WORKSPACE_ROOT} होगी. ध्यान दें: अगर आप इस वैल्यू के लिए एक से दूसरे Bazel को शुरू करने का विकल्प चुनते हैं, तो शायद आप एक नया, अतिरिक्त Bazel सर्वर शुरू करेंगे. Bazen हर तय आउटपुट बेस के लिए ठीक एक सर्वर शुरू करता है. आम तौर पर, हर फ़ाइल फ़ोल्डर में एक आउटपुट बेस होता है - हालांकि, इस विकल्प में आपके पास हर फ़ाइल फ़ोल्डर के लिए एक से ज़्यादा आउटपुट बेस हो सकते हैं. साथ ही, एक ही मशीन पर एक ही क्लाइंट के लिए कई बिल्ड चल सकते हैं. Bazel सर्वर को शटडाउन करने का तरीका जानने के लिए, 'bazel help shutdown' देखें.
टैग:affects_outputs
,loses_incremental_state
--output_user_root=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
उपयोगकर्ता के हिसाब से बनाई गई वह डायरेक्ट्री जिसके नीचे सभी बिल्ड आउटपुट लिखे जाते हैं; यह डिफ़ॉल्ट रूप से $USER का फ़ंक्शन है, लेकिन कॉन्सटेंट को तय करके, सहयोग करने वाले उपयोगकर्ताओं के बीच शेयर किया जा सकता है.
टैग:affects_outputs
,loses_incremental_state
--[no]preemptible
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो दूसरा निर्देश शुरू होने पर, निर्देश को पहले से रोका जा सकता है.
टैग:eagerness_to_exit
--server_jvm_out=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
सर्वर की जेवीएम का आउटपुट लिखने की जगह. अगर यह सेट नहीं है, तो आउटपुट में 'बेस' पर डिफ़ॉल्ट रूप से जगह सेट होती है.
टैग:affects_outputs
,loses_incremental_state
--[no]shutdown_on_low_sys_mem
डिफ़ॉल्ट: "गलत"-
अगर max_idle_secs सेट हो और बिल्ड सर्वर कुछ समय से इस्तेमाल में न हो, तो सिस्टम में कम रैम होने पर सर्वर शट डाउन करें. सिर्फ़ Linux पर.
टैग:eagerness_to_exit
,loses_incremental_state
--[no]system_rc
डिफ़ॉल्ट: "सही"-
सिस्टम के हिसाब से बैजलर को ढूंढना है या नहीं.
टैग:changes_inputs
--[no]unlimit_coredumps
डिफ़ॉल्ट: "गलत"-
सर्वर के कोरडंप (JVM) और सामान्य स्थितियों में क्लाइंट के लिए सॉफ़्ट कोरडंप की सीमा को हार्ड लिमिट तक बढ़ाता है. इस फ़्लैग को अपने बैजल पर एक बार चिपकाएं और इसके बारे में भूल जाएं, ताकि जब आप उन्हें ऐसी स्थिति में डालें, जिससे वे ट्रिगर हों, तो आपको कोरडंप मिल जाए.
टैग:bazel_internal_configuration
--[no]watchfs
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो बेज़ल किसी बदलाव के लिए हर फ़ाइल को स्कैन करने के बजाय, लोकल बदलावों के लिए ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करता है.
टैग:deprecated
--[no]windows_enable_symlinks
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो फ़ाइल को कॉपी करने के बजाय, Windows पर असली सिंबल वाले लिंक बनाए जाएंगे. Windows डेवलपर मोड को चालू करना ज़रूरी है. साथ ही, Windows 10 का 1703 या इसके बाद का वर्शन होना चाहिए.
टैग:bazel_internal_configuration
--[no]workspace_rc
डिफ़ॉल्ट: "सही"- $workspace/.bazelrc पर फ़ाइल फ़ोल्डर बज़ेलर फ़ाइल ढूंढना है या नहीं
टैग:changes_inputs
- अलग-अलग कैटगरी में नहीं रखा गया.:
--host_jvm_args=<jvm_arg>
बार कई बार इस्तेमाल किया गया- JVM को पास करने के लिए फ़्लैग करें.
--host_jvm_debug
-
कुछ और जेवीएम स्टार्टअप फ़्लैग जोड़ने का सुविधा विकल्प. इससे, जेवीएम की अनुमति वाले डीबगर (जैसे, Eclipse) से पोर्ट 5005 से कनेक्ट होने तक, जेवीएम स्टार्टअप के दौरान इंतज़ार करता है.
इसमें यह भी शामिल है:
--host_jvm_args=-Xdebug
--host_jvm_args=-Xrunjdwp:transport=dt_socket,server=y,address=5005
--host_jvm_profile=<profiler_name>
डिफ़ॉल्ट: ""- कुछ प्रोफ़ाइलर/डीबगर खास JVM स्टार्टअप फ़्लैग जोड़ने के लिए सुविधा का विकल्प. बैज़ल के पास जानी-पहचानी वैल्यू की एक सूची है, जिसे हार्डकोड किए गए जेवीएम स्टार्टअप फ़्लैग के लिए मैप किया जाता है. ऐसा हो सकता है कि यह कुछ फ़ाइलों के लिए हार्डकोड वाले पाथ खोज रहा हो.
--server_javabase=<jvm path>
डिफ़ॉल्ट: ""- BVM को एक्ज़ीक्यूट करने के लिए, इस्तेमाल किए गए JVM का पाथ.
सभी निर्देशों के लिए, आम तौर पर इस्तेमाल होने वाले विकल्प
- ऐसे विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range>
डिफ़ॉल्ट: "1048576"-
stdout / stderr फ़ाइलों का ज़्यादा से ज़्यादा साइज़, जिसे कंसोल पर प्रिंट किया जाएगा. -1 का मतलब है कि कोई सीमा नहीं है.
टैग:execution
--[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
-
लोकल मशीन से रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, फ़्लैग करने के लिए इस्तेमाल किया जाने वाला शॉर्टकट है: --action_cache_store_ आउटपुट_metadata, --experimental_inमेमोरी_jdeps_files, --experimental_inspam_डॉट_files और --remote_download_outputs=minimal.
इसमें यह भी शामिल है:
--nobuild_runfile_links
--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>
डिफ़ॉल्ट: ""-
रिमोट बिल्ड आउटपुट को स्थानीय मशीन में डाउनलोड करने के बजाय, सिंबॉलिक लिंक बनाएं. सिंबॉलिक लिंक के टारगेट को टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {has} और {size_bytes} हो सकते हैं. साथ ही, ऑब्जेक्ट के हैश की जगह पर और साइज़ की जानकारी बाइट में बढ़ सकती है. उदाहरण के लिए, ये सिंबॉलिक लिंक, FUSE फ़ाइल सिस्टम पर ले जा सकते हैं. मांग पर कैस के ऑब्जेक्ट को लोड किया जाता है.
टैग:affects_outputs
--remote_download_toplevel
-
लोकल मशीन से सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट डाउनलोड किए जाते हैं. यह फ़्लैग, फ़्लैग करने के लिए इस्तेमाल किया जाने वाला शॉर्टकट है: --action_cache_store_ आउटपुट_metadata, --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dogd_files और --remote_download_outputs=toplevel.
इसमें यह भी शामिल है:
--action_cache_store_output_metadata
--remote_download_outputs=toplevel
टैग:affects_outputs
--repo_env=<a 'name=value' assignment with an optional value part>
बार कई बार इस्तेमाल किया गया-
इससे ज़्यादा एनवायरमेंट वैरिएबल तय होते हैं. ये सिर्फ़ रिपॉज़िटरी के नियमों के लिए उपलब्ध होते हैं. ध्यान रखें कि किसी भी तरह से रिपॉज़िटरी के नियमों में पूरा एनवायरमेंट दिखता है. इस तरह, यह कार्रवाई ग्राफ़ को अमान्य किए बिना, विकल्पों के ज़रिए रिपॉज़िटरी में पास की जा सकती है.
टैग:action_command_lines
- वे विकल्प जो इस बात पर असर डालते हैं कि Bazel, बिल्ड के मान्य इनपुट को किस तरह लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--[no]check_bzl_visibility
डिफ़ॉल्ट: "सही"-
अगर यह विकल्प बंद है, तो चेतावनियों के लिए .bzl लोड से जुड़ी गड़बड़ियां मैनेज की जाती हैं.
टैग:build_file_semantics
- यह विकल्प Starlark भाषा के सिमेंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों को ऐक्सेस करने लायक बिल्ड एपीआई पर असर डालता है.:
--[no]enable_bzlmod
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो Bzlmod डिपेंडेंसी मैनेजमेंट सिस्टम को, WORKSPACE के मुकाबले प्राथमिकता दी जाती है. ज़्यादा जानकारी पाने के लिए, https://bazel.build/docs/bzlmod पर जाएं.
टैग:loading_and_analysis
--[no]experimental_action_resource_set
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो स्थानीय एक्ज़ीक्यूशन के लिए ctx.action.run() और ctx.action.run_shell() एक resource_set पैरामीटर स्वीकार करती है. नहीं तो, मेमोरी और 1 सीपीयू के लिए यह डिफ़ॉल्ट रूप से 250 एमबी होगा.
टैग:execution
,build_file_semantics
,experimental
-
अगर सही पर सेट किया जाता है, तो टैग, टारगेट से कार्रवाइयों की एक्ज़ीक्यूशन की ज़रूरी शर्तों में बदल जाएंगे. ऐसा नहीं होने पर, टैग को प्रमोट नहीं किया जाता है. ज़्यादा जानकारी पाने के लिए, https://github.com/bazelbuild/bazel/issues/8830 पर जाएं.
टैग:build_file_semantics
,experimental
--[no]experimental_analysis_test_call
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया गया है, तो test_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
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो अपने-आप जनरेट होने वाला //बाहरी पैकेज अब उपलब्ध नहीं होगा. Bazel अब भी 'external/BUILD' फ़ाइल को पार्स नहीं कर पाएगा. हालांकि, बिना नाम वाले पैकेज से बाहरी/ तक पहुंचने वाले ग्लोब्स काम करेंगे.
टैग:loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_enable_android_migration_apis
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Android Starlark के माइग्रेशन के लिए ज़रूरी एपीआई चालू हो जाते हैं.
टैग:build_file_semantics
--[no]experimental_enable_scl_dialect
डिफ़ॉल्ट: "गलत"-
सही पर सेट होने पर, लोड() स्टेटमेंट में .scl फ़ाइलों का इस्तेमाल किया जा सकता है.
टैग:build_file_semantics
--[no]experimental_get_fixed_configured_action_env
डिफ़ॉल्ट: "गलत"-
अगर यह चालू है, तो Action.env भी सुविधा कॉन्फ़िगरेशन के ज़रिए तय किए गए, तय किए गए एनवायरमेंट वैरिएबल दिखाएगा.
टैग:loading_and_analysis
,experimental
--[no]experimental_google_legacy_api
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Google के लेगसी कोड से जुड़े, Starlark बिल्ड एपीआई के कई एक्सपेरिमेंट के बारे में पता चलता है.
टैग:loading_and_analysis
,experimental
--[no]experimental_java_library_export
डिफ़ॉल्ट: "गलत"-
अगर यह नीति चालू है, तोexperiment_java_library_export_do_not_use मॉड्यूल उपलब्ध है.
टैग:loading_and_analysis
,incompatible_change
--[no]experimental_lazy_template_expansion
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो विकल्प के तौर पर बदली गई वैल्यू को जांचने के लिए, ctx.action.expand_template() टेंप्लेटDict पैरामीटर स्वीकार करता है.
टैग:execution
,build_file_semantics
,experimental
--[no]experimental_platforms_api
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो डीबग करने के लिए प्लैटफ़ॉर्म से जुड़े कई Starlark एपीआई चालू होते हैं.
टैग:loading_and_analysis
,experimental
--[no]experimental_repo_remote_exec
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो formula_rule का इस्तेमाल करके, रिमोट एक्ज़ीक्यूट करने की कुछ सुविधाएं मिलती हैं.
टैग:build_file_semantics
,loading_and_analysis
,experimental
--[no]experimental_sibling_repository_layout
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो मुख्य डेटा स्टोर करने की जगह में, नॉन-मेन रिपॉज़िटरी को रिपॉज़िटरी के मुख्य रिपॉज़िटरी के साथ लिंक किया जाता है. इसका मतलब यह है कि सभी डेटा स्टोर करने की जगहें, $ आउटपुट_base/execution_root डायरेक्ट्री में मौजूद डायरेक्ट चाइल्ड डेटा हैं. असल टॉप-लेवल 'बाहरी' डायरेक्ट्री के लिए $आउटपुट_base/execution_root/__main__/external छोड़ने का साइड इफ़ेक्ट होता है.
टैग:action_command_lines
,bazel_internal_configuration
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]incompatible_always_check_depset_elements
डिफ़ॉल्ट: "सही"-
देखें कि सभी कंस्ट्रक्टर में डीप एलिमेंट में जोड़े गए एलिमेंट मान्य हैं या नहीं. एलिमेंट में बदलाव नहीं किया जाना चाहिए, लेकिन पुराने तौर पर डेप्सेट(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
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो नियम के एट्रिब्यूट 'cfg = "host" को सेट नहीं किए जा सकते. नियमों को इसके बजाय 'cfg = "exec" सेट करना चाहिए.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_disable_target_provider_fields
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स की मदद से, 'टारगेट' ऑब्जेक्ट पर सेवा देने वाली कंपनियों को ऐक्सेस करने की सुविधा बंद करें. इसके बजाय, सेवा देने वाली कंपनी की कुंजी का सिंटैक्स इस्तेमाल करें. उदाहरण के लिए, नियम लागू करने के फ़ंक्शन में से `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
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो glob() के `allow_खाली` आर्ग्युमेंट की डिफ़ॉल्ट वैल्यू 'गलत' होती है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disallow_legacy_javainfo
डिफ़ॉल्ट: "सही"-
अब सेवा में नहीं है. नहीं.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disallow_struct_provider_syntax
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो हो सकता है कि नियम लागू करने वाले फ़ंक्शन, स्ट्रक्चर्ड डेटा न दिखाएं. इसके बजाय, उन्हें सेवा देने वाली कंपनियों के इंस्टेंस की सूची दिखानी होगी.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_existing_rules_immutable_view
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' और 'नेटिव.Existing_rule' पर सेट करें, तो नेटिव
टैग:build_file_semantics
,loading_and_analysis
,incompatible_change
--[no]incompatible_fix_package_group_reporoot_syntax
डिफ़ॉल्ट: "सही"-
पैकेज_ग्रुप की `पैकेज` विशेषता, किसी भी रिपॉज़िटरी में सभी पैकेज के बजाय मौजूदा रिपॉज़िटरी में सभी पैकेज को रेफ़र करने के लिए "//..." वैल्यू का मतलब बदलता है. पुराना व्यवहार पाने के लिए, खास वैल्यू "//" की जगह "//" का इस्तेमाल करें. इस फ़्लैग के लिए --insupported_package_group_has_public_syntax भी चालू करना ज़रूरी है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_java_common_parameters
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो package_source में Host_javabase पैरामीटर और कंपाइल के Host_javabase पैरामीटर को हटा दिया जाएगा.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_new_actions_api
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो कार्रवाई बनाने के लिए एपीआई, सिर्फ़ `lock.action` पर उपलब्ध होगा, न कि `ctx` पर.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_no_attr_license
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो `attr.लाइसेंस` फ़ंक्शन बंद हो जाता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_no_implicit_file_export
डिफ़ॉल्ट: "गलत"-
अगर सेट की गई (इस्तेमाल की गई) सोर्स फ़ाइलें, पैकेज निजी होती हैं, तो उन्हें सीधे तौर पर एक्सपोर्ट नहीं किया जाता. https://github.com/bazelbuild/proposals/blob/Master/designs/2019-10-24-file-visible.md देखें
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_no_rule_outputs_param
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो `rule()` Starlark फ़ंक्शन का `आउटपुट` पैरामीटर बंद हो जाता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_package_group_has_public_syntax
डिफ़ॉल्ट: "सही"-
पैकेज_ग्रुप के `पैकेज` एट्रिब्यूट, सभी पैकेज या 'पैकेज नहीं' के बारे में बताने के लिए "सार्वजनिक" या "निजी" लिखने की अनुमति देते हैं.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_require_linker_input_cc_api
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Create_linking_context के लिए, Library_to_link के बजाय link__inputs की ज़रूरत होगी. Linking_context के पुराने गैटर भी बंद हो जाएंगे. साथ ही, बस linker_inputs उपलब्ध हो जाएंगे.
टैग:build_file_semantics
,loading_and_analysis
,incompatible_change
--[no]incompatible_run_shell_command_string
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया गया है, तो Actions.run_shell का कमांड पैरामीटर सिर्फ़ स्ट्रिंग को स्वीकार करेगा
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_stop_exporting_language_modules
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो उपयोगकर्ता के हिसाब से .bzl फ़ाइलों में कुछ खास भाषा के मॉड्यूल (जैसे कि `cc_normal`) उपलब्ध नहीं होते हैं. हो सकता है कि उन्हें सिर्फ़ उनसे जुड़े नियमों के डेटा स्टोर करने की जगहों में कॉल किया जा सके.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_struct_has_no_methods
डिफ़ॉल्ट: "गलत"-
to_json और to_proto स्ट्रक्चर के तरीके बंद कर देता है, जो स्ट्रक्चर फ़ील्ड के नेमस्पेस को प्रदूषित करता है. इसके बजाय, JSON के लिए json.encode या json.encode_indent या टेक्स्टप्रोटो के लिए proto.encode_text का इस्तेमाल करें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_top_level_aspects_require_providers
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो टॉप लेवल का मकसद सिर्फ़ उन कंपनियों को मिलेगा जो ज़रूरी हैं. साथ ही, ये सिर्फ़ उन टॉप लेवल टारगेट पर लागू होंगी जिनके लिए विज्ञापन देने वाली कंपनियां, ज़रूरी शर्त पूरी करती हैं.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_unambiguous_label_stringification
डिफ़ॉल्ट: "सही"-
सही होने पर, Bazel, @foo:bar के बजाय @//foo:bar से @//foo:bar लेबल करेगा. इससे सिर्फ़ str(), % ऑपरेटर, और इसी तरह का व्यवहार पर असर पड़ता है; repr() में बदलाव नहीं होता. ज़्यादा जानकारी पाने के लिए, https://github.com/bazelbuild/bazel/issues/15916 पर जाएं.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_use_cc_configure_from_rules_cc
डिफ़ॉल्ट: "गलत"-
सही होने पर, Bazel, @bazel_tools से cc_configure का इस्तेमाल करने की अनुमति नहीं देगा. ज़्यादा जानकारी और माइग्रेशन से जुड़े निर्देशों के लिए, कृपया https://github.com/bazelbuild/bazel/issues/10134 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_visibility_private_attributes_at_definition
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो नियम के इस्तेमाल के बजाय, निजी नियम के एट्रिब्यूट की विज़िबिलिटी, नियम की परिभाषा के मुताबिक जांची जाती है.
टैग:build_file_semantics
,incompatible_change
--max_computation_steps=<a long integer>
डिफ़ॉल्ट: "0"-
BUILD फ़ाइल से एक्ज़ीक्यूट किए जा सकने वाले Starlark कैलकुलेशन के चरणों की ज़्यादा से ज़्यादा संख्या. शून्य का मतलब कोई सीमा नहीं है.
टैग:build_file_semantics
--nested_set_depth_limit=<an integer>
डिफ़ॉल्ट: "3,500"-
डेपसेट में अंदरूनी तौर पर मौजूद ग्राफ़ की ज़्यादा से ज़्यादा गहराई (जिसे NestedSet भी कहा जाता है), जिसके ऊपर Depset() कंस्ट्रक्टर काम नहीं करेगा.
टैग:loading_and_analysis
- बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प:
--[no]heuristically_drop_nodes
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो ब्लेड बचत करने के लिए, FileState और DirectoryListing नोड में FileState और DirectoryListingState नोड को हटा दिया जाता है. हमें उम्मीद है कि इन नोड की फिर से ज़रूरत होगी. अगर ऐसा है, तो प्रोग्राम फिर से उनका आकलन करेगा.
टैग:loses_incremental_state
--[no]incompatible_do_not_split_linking_cmdline
डिफ़ॉल्ट: "सही"-
सही होने पर, Bazel, जोड़ने के लिए इस्तेमाल किए जाने वाले कमांड लाइन फ़्लैग में बदलाव नहीं करता. साथ ही, यह भी तय नहीं करता कि पैरामीटर फ़ाइल में कौनसे फ़्लैग फ़्लैग करेंगे और कौनसे नहीं. ज़्यादा जानकारी पाने के लिए, https://github.com/bazelbuild/bazel/issues/7670 पर जाएं.
टैग:loading_and_analysis
,incompatible_change
--[no]keep_state_after_build
डिफ़ॉल्ट: "सही"-
गलत होने पर, ब्लेज़ इस बिल्ड के खत्म होने के बाद, मेमोरी की स्थिति को खारिज कर देगा. इस मामले में, बाद के बिल्ड में कोई बढ़ोतरी नहीं होगी.
टैग:loses_incremental_state
--[no]track_incremental_state
डिफ़ॉल्ट: "सही"-
गलत होने पर, Blaze डेटा बनाए नहीं रखेगा. इसकी मदद से, इस बिल्ड में मेमोरी सेव करने के लिए, अमान्य बिल्ड पर अमान्यता और फिर से आकलन किया जा सकेगा. इस मामले में, बाद के बिल्ड में कोई बढ़ोतरी नहीं होगी. आम तौर पर, इसे 'गलत है' पर सेट करते समय, आपको बैच तय करना होगा.
टैग:loses_incremental_state
- ऐसे विकल्प जो बोली की जानकारी, फ़ॉर्मैट, या जगह की जानकारी पर असर डालते हैं:
--[no]announce_rc
डिफ़ॉल्ट: "गलत"-
आरसी के विकल्पों के बारे में एलान करना है या नहीं.
टैग:affects_outputs
--[no]attempt_to_print_relative_paths
डिफ़ॉल्ट: "गलत"-
मैसेज के जगह की जानकारी देने वाले हिस्से को प्रिंट करते समय, फ़ाइल फ़ोल्डर की डायरेक्ट्री या --package_path की बताई गई किसी एक डायरेक्ट्री के पाथ का इस्तेमाल करें.
टैग:terminal_output
--bes_backend=<a string>
डिफ़ॉल्ट: ""-
बिल्ड इवेंट सेवा (बीईएस) बैकएंड एंडपॉइंट की जानकारी, [SCHEME://]होस्ट[:PORT] रूप में दी गई है. BES अपलोड को डिफ़ॉल्ट तौर पर बंद रखा गया है. ऐसी स्कीम जिनके लिए grpc और grpcs (TLS के साथ-साथ चालू किए गए फ़ॉर्मैट) इस्तेमाल किए जा सकते हैं. अगर कोई स्कीम नहीं दी गई है, तो Bazel, grpcs का इस्तेमाल कर सकता है.
टैग:affects_outputs
--[no]bes_check_preceding_lifecycle_events
डिफ़ॉल्ट: "गलत"-
publishBuildToolEventStreamRequest के फ़ील्ड में Check_preceding_lifecycle_events_present सेट करता है. यह BES को यह पता लगाने के लिए सेट करता है कि क्या उसे मौजूदा टूल इवेंट से मेल खाने वाले Invo ठहरने की कोशिश की शुरुआत और BuildEnqueed वाले इवेंट मिले या नहीं.
टैग: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>
डिफ़ॉल्ट: ब्यौरा देखें- किसी प्रॉक्सी का इस्तेमाल करके, Build Event Service से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ यूनिक्स डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--bes_results_url=<a string>
डिफ़ॉल्ट: ""-
वह बेस यूआरएल तय करता है जहां उपयोगकर्ता, बीईएस बैकएंड में स्ट्रीम की गई जानकारी देख सकता है. Bazel, यूआरएल को शुरू करने वाले के आईडी से जुड़े यूआरएल को टर्मिनल के तौर पर जनरेट करेगा.
टैग:terminal_output
--bes_system_keywords=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया-
-इसमें सीधे तौर पर शामिल किए जाने वाले सूचना कीवर्ड की सूची के बारे में बताया जाता है, लेकिन --bes_keyword के ज़रिए दिए गए कीवर्ड के लिए user_keyword=" प्रीफ़िक्स शामिल नहीं होता. बिल्ड सेवा ऑपरेटर का मकसद --bes_lifecycle_events=false सेट करना और PublishLifecycleEvent को कॉल करते समय कीवर्ड शामिल करना है. बिल्ड का इस्तेमाल करके बनाए गए सेवा ऑपरेटर, उपयोगकर्ताओं को फ़्लैग की वैल्यू में बदलाव करने से रोकें.
टैग:affects_outputs
--bes_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "0s"-
यह तय करता है कि बिल्ड और टेस्ट खत्म होने के बाद, BES/BEP अपलोड होने के लिए कितनी देर तक इंतज़ार करना चाहिए. मान्य समय खत्म होना, एक स्वाभाविक संख्या होती है. इसके बाद एक यूनिट होती है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (मिलीसेकंड). डिफ़ॉल्ट वैल्यू '0' होती है. इसका मतलब है कि कोई टाइम आउट नहीं है.
टैग:affects_outputs
--bes_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async>
डिफ़ॉल्ट: "visitt_for_upload_complete"-
यह तय करता है कि क्या बिल्ड इवेंट सर्विस अपलोड, बिल्ड के पूरा होने पर ब्लॉक होना चाहिए या शुरू करने वाले को तुरंत बंद कर देना चाहिए और बैकग्राउंड में अपलोड पूरा कर देना चाहिए. 'Wet_for_upload_complete' (डिफ़ॉल्ट), 'nowait_for_upload_complete' या 'full_async' पर जाएं.
टैग:eagerness_to_exit
--build_event_binary_file=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो उस फ़ाइल में बिल्ड इवेंट प्रोटोकॉल के बारे में बताने वाली अलग-अलग बाइनरी बाइनरी लिखें. इसका मतलब है --bes_upload_mode=visitt_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
डिफ़ॉल्ट: "गलत"-
सभी कार्रवाइयां पब्लिश होनी चाहिए या नहीं.
टैग: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
डिफ़ॉल्ट: "गलत"-
चालू होने पर, यह लॉग में JSON प्रोफ़ाइल पाथ जोड़ता है.
टैग:bazel_monitoring
--[no]experimental_bep_target_summary
डिफ़ॉल्ट: "गलत"- टारगेट की गई खास जानकारी वाले इवेंट प्रकाशित करने हैं या नहीं.
--[no]experimental_build_event_expand_filesets
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में Filesसेट को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "गलत"-
सही होने पर, आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी के मिलते-जुलते 'फ़ाइलसेट' सिमलिंक का पूरी तरह से समाधान करें. --experimental_build_event_expand_filessets की ज़रूरत है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
Bez को बिल्ड इवेंट को फिर से अपलोड करने की कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
डिफ़ॉल्ट: "1s"-
बीईपी अपलोड नहीं हो पाने पर, एक्सपोनेंशियल बैकऑफ़ बार-बार कोशिश करने पर लगने वाला कम से कम समय. (एक्सपोनेंट: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह पेज, बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुनता है.
टैग:affects_outputs
--[no]experimental_collect_load_average_in_profiler
डिफ़ॉल्ट: "सही"-
अगर इस नीति को चालू किया जाता है, तो प्रोफ़ाइल बनाने वाला प्रोफ़ाइल सिस्टम के कुल लोड का औसत इकट्ठा करेगा.
टैग:bazel_monitoring
--[no]experimental_collect_pressure_stall_indicators
डिफ़ॉल्ट: "गलत"-
चालू होने पर, प्रोफ़ाइलर Linux PSI डेटा इकट्ठा करता है.
टैग:bazel_monitoring
--[no]experimental_collect_resource_estimation
डिफ़ॉल्ट: "गलत"-
इसके चालू होने पर, प्रोफ़ाइलर, लोकल ऐक्शन के लिए सीपीयू और मेमोरी के इस्तेमाल का अनुमान लगाता है.
टैग:bazel_monitoring
--[no]experimental_collect_system_network_usage
डिफ़ॉल्ट: "गलत"-
इसके चालू होने पर, प्रोफ़ाइलर सिस्टम के नेटवर्क के इस्तेमाल को इकट्ठा करता है.
टैग:bazel_monitoring
--[no]experimental_collect_worker_data_in_profiler
डिफ़ॉल्ट: "गलत"-
चालू होने पर, प्रोफ़ाइलर वर्कर का एग्रीगेट किया गया रिसॉर्स डेटा इकट्ठा करता है.
टैग:bazel_monitoring
--experimental_profile_additional_tasks=<phase, action, action_check, action_lock, action_release, action_update, action_complete, 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, action_cache_counts, local_cpu_usage, system_cpu_usage, cpu_usage_estimation, local_memory_usage, system_memory_usage, memory_usage_estimation, system_network_up_usage, system_network_down_usage, workers_memory_usage, system_load_average, starlark_parser, starlark_user_fn, starlark_builtin_fn, starlark_user_compiled_fn, starlark_repository_fn, action_fs_staging, remote_cache_check, remote_download, remote_network, filesystem_traversal, worker_execution, worker_setup, worker_borrow, worker_working, worker_copying_outputs, credential_helper, pressure_stall_io, pressure_stall_memory, dynamic_lock or unknown>
बार कई बार इस्तेमाल किया गया-
प्रोफ़ाइल में शामिल किए जाने वाले अतिरिक्त प्रोफ़ाइल टास्क तय करता है.
टैग:bazel_monitoring
--[no]experimental_profile_include_primary_output
डिफ़ॉल्ट: "गलत"-
इसमें कार्रवाई इवेंट के अतिरिक्त "आउट" एट्रिब्यूट शामिल होता है. इसमें, कार्रवाई के प्राइमरी आउटपुट का exec पाथ शामिल होता है.
टैग:bazel_monitoring
--[no]experimental_profile_include_target_label
डिफ़ॉल्ट: "गलत"-
इसमें, कार्रवाई इवेंट के JSON प्रोफ़ाइल के डेटा में टारगेट लेबल शामिल होता है.
टैग:bazel_monitoring
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "गलत"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय उन्हें सीधे रिमोट स्टोरेज में अपलोड करें.
टैग:affects_outputs
--experimental_workspace_rules_log_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- इस फ़ाइल में, Workspace के नियमों वाले कुछ इवेंट को डीलिमिटेड WorkspaceEvent प्रोटो के तौर पर लॉग करें.
--[no]generate_json_trace_profile
डिफ़ॉल्ट: "अपने-आप"-
चालू होने पर, Bazel, बिल्ड को प्रोफ़ाइल बनाता है और आउटपुट के फ़ॉर्मैट में फ़ाइल में JSON-फ़ॉर्मैट की प्रोफ़ाइल बनाता है. chrome://ttracking में लोड करके प्रोफ़ाइल देखें. डिफ़ॉल्ट रूप से, Bazel, बिल्ड-जैसे सभी निर्देशों और क्वेरी के लिए प्रोफ़ाइल लिखता है.
टैग:bazel_monitoring
--[no]heap_dump_on_oom
डिफ़ॉल्ट: "गलत"-
अगर कोई ओओएम (ओओएम) फेंक दिया जाता है, तो मैन्युअल तरीके से हीप डंप बनाया जाता है. इसमें --experimental_oom_more_eagerly_threshold के साथ ओओएम भी शामिल है. डंप को < आउटपुट_base>/<invoition_id>.heapdump.hprof पर लिखा जाएगा. इस विकल्प को चालू करने पर -XX:+ HeapDumpOnOutOfMemoryError का असर होता है, जिससे कोई असर नहीं पड़ता. इसकी वजह यह है कि OOM को पकड़ लिया जाता है और Runtime#halt पर रीडायरेक्ट कर दिया जाता है.
टैग:bazel_monitoring
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
इसका इस्तेमाल करें, ताकि Targetcomplete इवेंट में जानदार लेगसी आउटपुट आउटपुट फ़ील्ड को बंद किया जा सके.
टैग:affects_outputs
--logging=<0 <= an integer <= 6>
डिफ़ॉल्ट: "3"-
लॉगिंग लेवल.
टैग:affects_outputs
--memory_profile=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर सेट किया गया है, तो बिल्ड के आखिर में तय की गई फ़ाइल में, मेमोरी के इस्तेमाल से जुड़ा डेटा लिखें. साथ ही, बिल्ड के आखिर में मास्टर लॉग में स्टेबल हीप लिखें.
टैग:bazel_monitoring
--memory_profile_stable_heap_parameters=<integers, separated by a comma expected in pairs>
डिफ़ॉल्ट: "1,0"-
बिल्डिंग के आखिर में, स्टेबल हीप की कंप्यूट कंप्यूटिंग की ट्यून करें. पूर्णांकों की संख्या और यहां तक कि कॉमा से अलग की गई संख्या भी होनी चाहिए. हर जोड़े में, पहला इंटीजर पूरा होने के लिए GC की संख्या होती है. हर जोड़े का दूसरा पूर्णांक, GC के बीच इंतज़ार करने के लिए सेकंड की संख्या होता है. उदाहरण: 24,44,000 लोगों को 4 सेकंड के रोकने के साथ 2 जीसी चाहिए. इसके बाद, शून्य सेकंड से कम समय में 4 जीसी हटाएं
टैग:bazel_monitoring
--profile=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
सेट होने पर, Bazel पर क्लिक करें और बताई गई फ़ाइल में डेटा लिखें. प्रोफ़ाइल का विश्लेषण करने के लिए बैज विश्लेषण प्रोफ़ाइल.
टैग:bazel_monitoring
--[no]record_full_profiler_data
डिफ़ॉल्ट: "गलत"-
डिफ़ॉल्ट रूप से, Bazel Profiler तेज़ और कई इवेंट के लिए सिर्फ़ एग्रीगेट किया गया डेटा रिकॉर्ड करेगा, जैसे कि फ़ाइल बनाना. अगर यह विकल्प चालू है, तो प्रोफ़ाइलर हर इवेंट को रिकॉर्ड करेगा. इसका मतलब है कि ज़्यादा सटीक प्रोफ़ाइलिंग डेटा और LARGE परफ़ॉर्मेंस हिट रिकॉर्ड हो जाएंगे. यह विकल्प सिर्फ़ तब लागू होता है, जब --प्रोफ़ाइल भी इस्तेमाल की गई हो.
टैग:bazel_monitoring
--remote_print_execution_messages=<failure, success or all>
डिफ़ॉल्ट: "असफलता"-
चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज कब प्रिंट करने हैं. वैल्यू पूरी न होने पर प्रिंट करने के लिए `अचानक`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए 'सफलता', और हमेशा प्रिंट करने के लिए 'सभी' का इस्तेमाल किया जाता है.
टैग:terminal_output
--[no]slim_profile
डिफ़ॉल्ट: "सही"-
अगर प्रोफ़ाइल का साइज़ बहुत बड़ा है, तो JSON प्रोफ़ाइल को छोटा करके इवेंट को मर्ज किया जा सकता है.
टैग:bazel_monitoring
--starlark_cpu_profile=<a string>
डिफ़ॉल्ट: ""-
बताई गई फ़ाइल में, सभी Starlark थ्रेड के लिए, सीपीयू के इस्तेमाल की pprof प्रोफ़ाइल में लिखता है.
टैग:bazel_monitoring
--tool_tag=<a string>
डिफ़ॉल्ट: ""-
इस बेज़ल न्योते को एट्रिब्यूट करने के लिए टूल का नाम.
टैग:affects_outputs
,bazel_monitoring
--ui_event_filters=<Convert list of comma separated event kind to list of filters>
बार कई बार इस्तेमाल किया गया-
यह दिखाता है कि यूज़र इंटरफ़ेस (यूआई) में कौनसे इवेंट दिखाने हैं. लीडिंग +/- का इस्तेमाल करके, डिफ़ॉल्ट इवेंट को डिफ़ॉल्ट इवेंट में जोड़ा या हटाया जा सकता है. इसके अलावा, डिफ़ॉल्ट सेट को पूरी तरह से डायरेक्ट असाइनमेंट से बदला जा सकता है. काम करने वाले इवेंट टाइप के सेट में, जानकारी, डीबग, गड़बड़ी वगैरह शामिल है.
टैग:terminal_output
- रिमोट कैश मेमोरी और एक्ज़ीक्यूशन के विकल्प:
--experimental_circuit_breaker_strategy=<failure>
डिफ़ॉल्ट: ब्यौरा देखें-
यह सर्किट ब्रेकर के इस्तेमाल की रणनीति तय करता है. उपलब्ध रणनीतियां "असफल" हैं. विकल्प के लिए अमान्य वैल्यू पर, विकल्प जैसा सेट नहीं किया गया है.
टैग:execution
--[no]experimental_guard_against_concurrent_changes
डिफ़ॉल्ट: "गलत"- किसी कार्रवाई को रिमोट कैश में अपलोड करने से पहले, इनपुट फ़ाइलों के समय की जांच को बंद करने के लिए इसे बंद करें. ऐसे मामले भी हो सकते हैं, जहां Linux कर्नेल, फ़ाइलों को लिखने में देरी करता है. इस वजह से फ़ॉल्स पॉज़िटिव बदलाव मिल सकते हैं.
--[no]experimental_remote_cache_async
डिफ़ॉल्ट: "गलत"- अगर यह सही है, तो रिमोट कैश I/O का इस्तेमाल, प्रॉपर्टी के किसी हिस्से के तौर पर होने के बजाय, बैकग्राउंड में होगा.
--experimental_remote_cache_ttl=<An immutable length of time.>
डिफ़ॉल्ट: "3 घंटे"-
हाल ही में इकट्ठा किए गए TTL (टीटीएल) की गारंटी, रिमोट कैश में दी जाती है.ऐसा तब होता है, जब आपके डाइजेस्ट का हाल ही में रेफ़रंस दिया गया हो. उदाहरण के लिए, ActionAction या FindMissingBlobs. Bazel, BLOBs की TTL (टीटीएल) के मुताबिक कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, यह बढ़ोतरी वाले बिल्ड में GetActionResult को बार-बार कॉल नहीं करता है. वैल्यू को असली TTL (टीटीएल) से थोड़ा कम सेट करना चाहिए. ऐसा इसलिए, क्योंकि सर्वर से डाइजेस्ट मिलने के बाद, और Bazel उन्हें मिलने के बीच एक अंतर होता है.
टैग:execution
--experimental_remote_capture_corrupted_outputs=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- ऐसी डायरेक्ट्री का पाथ जहां खराब आउटपुट कैप्चर किए जाएंगे.
--[no]experimental_remote_discard_merkle_trees
डिफ़ॉल्ट: "गलत"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो getActionResult() और Execute() में कॉल के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़े इनपुट मैपिंग की कॉपी को खारिज करें. इससे मेमोरी के इस्तेमाल में काफ़ी कमी आती है, लेकिन दूर की कैश मेमोरी से जगह खाली करने और फिर से कोशिश करने पर Bazel उन्हें दोबारा जांचता है.
--experimental_remote_downloader=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट एसेट एपीआई यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जा सकता है. इन स्कीमा में grpc, grpcs, (TLS के साथ grpc) और Unix (स्थानीय UNIX सॉकेट) शामिल हैं. अगर कोई स्कीमा नहीं दिया गया है, तो Bazel, डिफ़ॉल्ट तौर पर grpcs का इस्तेमाल करेगा. देखें: https://github.com/bazelbuild/remote-apis/blob/Master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback
डिफ़ॉल्ट: "गलत"- अगर रिमोट डाउनलोड करने की सुविधा काम नहीं करती, तो स्थानीय डाउनलोडर पर वापस जाएं या नहीं.
--[no]experimental_remote_execution_keepalive
डिफ़ॉल्ट: "गलत"- रिमोट एक्ज़ीक्यूशन कॉल के लिए, कीपअलाइव का इस्तेमाल करना है या नहीं.
--experimental_remote_failure_rate_threshold=<an integer in 0-100 range>
डिफ़ॉल्ट: "10"-
किसी खास समयावधि के लिए, गड़बड़ी की दर के इस्तेमाल की अनुमति वाली संख्या को प्रतिशत में सेट करती है. इसके बाद, रिमोट कैश/एक्ज़ीक्यूटर को कॉल करना बंद कर देती है. डिफ़ॉल्ट रूप से, वैल्यू 10 होती है. इसे 0 पर सेट करने का मतलब कोई सीमा नहीं है.
टैग:execution
--experimental_remote_failure_window_interval=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"-
वह अंतराल जिसमें रिमोट अनुरोधों की गड़बड़ी की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव मान में, फ़ेलियर अवधि का हिसाब लगाने की प्रक्रिया की पूरी अवधि का हिसाब लगाया जाता है.इस यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s) और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो मान को सेकंड में समझा जाता है.
टैग:execution
--[no]experimental_remote_mark_tool_inputs
डिफ़ॉल्ट: "गलत"- अगर सही पर सेट है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट इनपुट के तौर पर इनपुट दिखाएगा. इसका इस्तेमाल दूर से लगातार काम करने वाले वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache
डिफ़ॉल्ट: "गलत"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट को जांचने की स्पीड को बेहतर बनाने के लिए, Merkle ट्री (डेटा की गणना करने की सुविधा) से जुड़े कैलकुलेशन को मैप किया जाएगा. कैश मेमोरी में मौजूद मेमोरी फ़ुट फ़ुट को --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer>
डिफ़ॉल्ट: "1000"- Merkle के पेड़ों की संख्या, जिनसे कैश मेमोरी में सेव किए गए हिट की जांच की रफ़्तार बेहतर हो गई. हालांकि, सॉफ़्ट रेफ़रंस के तौर पर इस्तेमाल किए जा रहे Java डेटा को कैश मेमोरी में अपने-आप फ़िल्टर कर दिया जाता है. हालांकि, मेमोरी बहुत ज़्यादा होने पर ऐसा हो सकता है कि मेमोरी में गड़बड़ी हो. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड होता है. प्रोजेक्ट की साइज़ के हिसाब से, ऑप्टिमल वैल्यू अलग-अलग होती है. डिफ़ॉल्ट संख्या 1000 है.
--[no]incompatible_remote_build_event_upload_respect_no_cache
डिफ़ॉल्ट: "गलत"- अब सेवा में नहीं है. नहीं. इसके बजाय --remote_build_event_upload=minimal का इस्तेमाल करें.
--[no]incompatible_remote_disallow_symlink_in_tree_artifact
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो रिमोट तरीके से की गई कार्रवाई में, ऐसा मिलता-जुलता ट्री आर्टफ़ैक्ट नहीं बनाया जा सकता जिसमें मिलते-जुलते सिमलिंक हों. हालांकि, इस फ़्लैग के बावजूद, पूरे सिमलिंक की अनुमति नहीं है.
टैग:execution
,incompatible_change
--[no]incompatible_remote_downloader_send_all_headers
डिफ़ॉल्ट: "सही"-
कई वैल्यू वाले हेडर की सभी वैल्यू, पहले वाले के बजाय रिमोट डाउनलोडर पर ही भेजें.
टैग:incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root
डिफ़ॉल्ट: "गलत"-
सही पर सेट होने पर, आउटपुट पाथ काम करने वाली डायरेक्ट्री के बजाय इनपुट रूट से मिलते-जुलते हैं.
टैग:incompatible_change
--[no]incompatible_remote_results_ignore_disk
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो डिस्क कैश पर --noremote_upload_local_results और --noremote_ accepted_cached लागू नहीं होगा. --disk_cache और --remote_cache, (संयुक्त कैश) सेट किए जाने पर:
--noremote_upload_local_results परिणामों को डिस्क कैश पर लिखा जाएगा, लेकिन दूरस्थ कैश पर अपलोड नहीं किया जाएगा.
--noremote_Acceptable_cached का नतीजा यह होगा कि Bazel, डिस्क कैश में नतीजों की जांच करेगा, लेकिन रिमोट कैश में नहीं.
रिमोट-एक्ज़ीक्यूट नहीं किया जा सकता, तो डिस्क की कैश मेमोरी पर असर पड़ सकता है.
ज़्यादा जानकारी के लिए #8216 देखें.
टैग:incompatible_change
--[no]remote_accept_cached
डिफ़ॉल्ट: "सही"- क्या आपको दूसरी जगह से कैश मेमोरी में सेव की गई कार्रवाई के नतीजे स्वीकार करने हैं.
--remote_build_event_upload=<all or minimal>
डिफ़ॉल्ट: "कम से कम"- अगर इसे 'सभी' पर सेट किया जाता है, तो BEP से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड किए जाते हैं. 'कम से कम' पर सेट किए जाने पर, BEP से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश में अपलोड नहीं किए जाते हैं.इनमें BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलें शामिल हैं. उदाहरण के लिए, टेस्ट लॉग और समय वाली प्रोफ़ाइल. बाइटस्ट्रीम:// स्कीम का इस्तेमाल हमेशा फ़ाइलों के यूआरआई के लिए किया जाता है, भले ही वे रिमोट कैश के न हों. 'कम से कम' पर डिफ़ॉल्ट रूप से सेट है.
--remote_bytestream_uri_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- बाइट नाम और इंस्टेंस का नाम, बाइटस्ट्रीम:// यूआरआई में इस्तेमाल किया जाना चाहिए, जिसे इवेंट स्ट्रीम बनाने के लिए लिखा जाता है. यह विकल्प तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती. अगर यह नीति सेट नहीं की जाती, तो डिफ़ॉल्ट रूप से इसका फ़ॉर्मैट {0}${hostname}/${instance_name}" होगा.
--remote_cache=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- कैश मेमोरी में सेव होने वाले एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS के साथ TLS चालू), और यूनिक्स (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel, डिफ़ॉल्ट तौर पर grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए grpc://, http:// या unix: स्कीमा की जानकारी दें. https://bazel.build/remote/caching पर क्लिक करें
--[no]remote_cache_compression
डिफ़ॉल्ट: "गलत"- चालू होने पर, zstd के साथ कैश ब्लॉब को कंप्रेस/डिप्रेस करें.
--remote_cache_header=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया- ऐसा हेडर डालें जो कैश मेमोरी के अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को एक से ज़्यादा बार बताने पर, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल जाएंगी.
--remote_default_exec_properties=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया-
अगर कोई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_property को सेट नहीं करता है, तो डिफ़ॉल्ट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए डिफ़ॉल्ट exec प्रॉपर्टी सेट करें.
टैग:affects_outputs
--remote_default_platform_properties=<a string>
डिफ़ॉल्ट: ""- डिफ़ॉल्ट स्क्रिप्ट प्रॉपर्टी को रिमोट एक्ज़ीक्यूशन एपीआई के लिए सेट करें. हालांकि, अगर लागू करने वाला प्लैटफ़ॉर्म पहले से Remote_execution_property को सेट नहीं करता है, तो उसे सेट कर दें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब रिमोट प्लैटफ़ॉर्म के लिए एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर होस्ट प्लैटफ़ॉर्म को चुना गया हो.
--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>
डिफ़ॉल्ट: ब्यौरा देखें- होस्ट या रिमोट:एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट. इन स्कीमा में grpc, grpcs, (TLS के साथ grpc) और Unix (स्थानीय UNIX सॉकेट) शामिल हैं. अगर कोई स्कीमा नहीं दिया गया है, तो Bazel, डिफ़ॉल्ट तौर पर grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए grpc:// या unix: स्कीमा डालें.
--remote_grpc_log=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- अगर इस फ़ील्ड को सेट किया गया है, तो फ़ाइल का पाथ, gRPC कॉल से जुड़ी जानकारी लॉग करने में मदद करता है. इस लॉग में, क्रम के हिसाब से com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry प्रोटोबफ़ का क्रम होता है. हर क्रम में यह मैसेज, वैरिएंट वाले मैसेज से शुरू होता है, जैसा कि LogEntry.writeDelimitedTo(InputStream) तरीके से किया जाता है.
--remote_header=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया- ऐसा हेडर डालें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को एक से ज़्यादा बार बताने पर, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल जाएंगी.
--remote_instance_name=<a string>
डिफ़ॉल्ट: ""- रिमोट एक्ज़ीक्यूशन एपीआई में इंस्टेंस_नाम के तौर पर पास करने के लिए वैल्यू.
--[no]remote_local_fallback
डिफ़ॉल्ट: "गलत"- रिमोट एक्ज़ीक्यूशन नहीं होने पर, क्या किसी लोकल एक्ज़ीक्यूशन की रणनीति पर वापस जाना है या नहीं.
--remote_local_fallback_strategy=<a string>
डिफ़ॉल्ट: "स्थानीय"- नहीं, नहीं. ज़्यादा जानकारी पाने के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.
--remote_max_connections=<an integer>
डिफ़ॉल्ट: "100"-
रिमोट कैश/एक्ज़ीक्यूटर के साथ, एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, इसकी सीमा तय करें. डिफ़ॉल्ट रूप से यह वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब कोई सीमा नहीं है.
एचटीटीपी रिमोट कैश के लिए, एक बार में एक टीसीपी कनेक्शन से ही एक अनुरोध को पूरा किया जा सकता है. इसलिए, Bazel, --remote_max_connections एक साथ किए जाने वाले अनुरोधों को पूरा कर सकता है.
gRPC रिमोट कैश/एक्ज़ीक्यूटर के लिए, आम तौर पर एक gRPC चैनल 100 से ज़्यादा अनुरोधों को हैंडल कर सकता है, ताकि Bazel करीब-करीब `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग:host_machine_resource_optimizations
--remote_proxy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ यूनिक्स डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer>
डिफ़ॉल्ट: "0"- रिमोट कैश मेमोरी में सेव की जाने वाली दूर से की जाने वाली कार्रवाइयों की प्राथमिकता. खास प्राथमिकता की वैल्यू के सिमैंटिक, सर्वर पर निर्भर होते हैं.
--remote_retries=<an integer>
डिफ़ॉल्ट: "5"- कुछ समय के लिए दिखने वाली गड़बड़ी से जुड़ी फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो दोबारा कोशिश नहीं की जा सकती.
--remote_retry_max_delay=<An immutable length of time.>
डिफ़ॉल्ट: "5s"- रिमोट की फिर से कोशिश करने के बीच ज़्यादा से ज़्यादा बैकऑफ़ देरी. इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो मान को सेकंड में समझा जाता है.
--remote_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"- रिमोट और कैश मेमोरी से जुड़े कॉल के लिए इंतज़ार का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट करने और पढ़ने का टाइम आउट, दोनों होता है. इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो मान को सेकंड में समझा जाता है.
--[no]remote_upload_local_results
डिफ़ॉल्ट: "सही"- अगर रिमोट कैश का इस्तेमाल किया जा सकता है और उपयोगकर्ता ऐसा कर सकता है, तो रिमोट तरीके से बनाई गई कार्रवाई के नतीजों को रिमोट कैश में अपलोड करें या नहीं.
--[no]remote_verify_downloads
डिफ़ॉल्ट: "सही"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट तरीके से डाउनलोड की गई सभी वैल्यू के हैश की गिनती करेगा. अगर ये वैल्यू उम्मीद के मुताबिक नहीं होती हैं, तो ये हैश किए गए वैल्यू को खारिज कर देते हैं.
- ऐसे अन्य विकल्प जिन्हें कैटगरी में नहीं बांटा गया है.:
--build_metadata=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया-
बिल्ड इवेंट में सप्लाई करने के लिए, कस्टम की-वैल्यू स्ट्रिंग का पेयर.
टैग:terminal_output
--color=<yes, no or auto>
डिफ़ॉल्ट: "अपने-आप"- आउटपुट का रंग बदलने के लिए, टर्मिनल कंट्रोल का इस्तेमाल करें.
--config=<a string>
बार कई बार इस्तेमाल किया गया- आरसी फ़ाइलों से अतिरिक्त कॉन्फ़िगरेशन सेक्शन चुनता है; हर <command> के लिए, अगर ऐसा सेक्शन मौजूद है, तो वह <command>:<config> के विकल्पों को भी ले लेता है; अगर यह सेक्शन किसी भी .rc फ़ाइल में मौजूद नहीं है, तो ब्लेज़ गड़बड़ी के साथ फ़ेल हो जाता है. ये कॉन्फ़िगरेशन सेक्शन और फ़्लैग कॉम्बिनेशन, मिलते-जुलते टूल/*.blazerc कॉन्फ़िगरेशन फ़ाइलों में मौजूद होते हैं.
--curses=<yes, no or auto>
डिफ़ॉल्ट: "अपने-आप"- स्क्रोल करने वाले आउटपुट को कम करने के लिए, टर्मिनल कर्सर कंट्रोल का इस्तेमाल करें.
--disk_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जहां बेज़ल, कार्रवाइयों और कार्रवाई के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.
--[no]enable_platform_specific_config
डिफ़ॉल्ट: "गलत"- सही होने पर, Bazel, bazelrc फ़ाइलों से होस्ट-ओएस की खास कॉन्फ़िगरेशन लाइनों को चुन लेता है. उदाहरण के लिए, अगर होस्ट OS Linux है और आप bazel बिल्ड चलाते हैं, तो Bazel, build:linux से शुरू होने वाली लाइनें लेता है. ओएस आइडेंटिफ़ायर chrome, macos, Windows, freebsd, और Openbsd होते हैं. इस फ़्लैग को चालू करना, Linux पर --config=linux, Windows पर --config=विंडो वगैरह वगैरह का इस्तेमाल करने जैसा है.
--experimental_credential_helper=<Path to a credential helper. It may be absolute, relative to the PATH environment variable, or %workspace%-relative. The path be optionally prefixed by a scope followed by an '='. The scope is a domain name, optionally with a single leading '*' wildcard component. A helper applies to URIs matching its scope, with more specific scopes preferred. If a helper has no scope, it applies to every URI.>
बार कई बार इस्तेमाल किया गया- डेटा स्टोर करने की जगह, कैश मेमोरी में सेव करने, और बिल्ड इवेंट की सेवा को ऐक्सेस करने के लिए, क्रेडेंशियल हेल्पर को इस्तेमाल करने के लिए कॉन्फ़िगर किया जाता है. किसी सहायक की ओर से दिए गए क्रेडेंशियल को --google_default_क्रेडेंशियल, --google_क्रेडेंशियल, .netrc फ़ाइल, या पुष्टीकरण पैरामीटर के लिए दिए गए क्रेडेंशियल से ज़्यादा अहमियत दी जाती है. ये पैरामीटर, हमले का हिस्सा होने के बारे में बताने वाले ईमेल का डेटा रिपॉज़िट किए जाने की तारीख कई हेल्पर सेट अप करने के लिए कई बार तय किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-क्रेडेंशियल-helpers.md पर जाएं.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मीटर"- क्रेडेंशियल हेल्पर से मिलने वाले क्रेडेंशियल को कैश मेमोरी में सेव किया जाता है. किसी अलग वैल्यू के साथ शुरू करने से, पहले से मौजूद एंट्री का लाइफ़टाइम अडजस्ट हो जाएगा. कैश मेमोरी मिटाने के लिए, शून्य पास करें. एक साफ़ कमांड हमेशा इस फ़्लैग को नज़रअंदाज़ करके, कैश मेमोरी को साफ़ करता है.
--experimental_credential_helper_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "10 सेकंड"- क्रेडेंशियल हेल्पर के लिए, टाइम आउट को कॉन्फ़िगर करता है. क्रेडेंशियल की मदद करने वाले सहायक लोग, इस टाइम आउट में जवाब नहीं दे पाएंगे और उन्हें शुरू नहीं कर पाएंगे.
--[no]experimental_skymeld_ui
डिफ़ॉल्ट: "गलत"-
इन दोनों तरीकों के एक साथ चलने पर, विश्लेषण और लागू करने की फ़ेज़ प्रोग्रेस दिखाता है.
टैग:terminal_output
--[no]experimental_windows_watchfs
डिफ़ॉल्ट: "गलत"- अगर सही है, तो --watchfs के लिए Windows की सुविधा काम करती है. नहीं तो, Windows पर एक नॉन-ऑप विंडो देखें. --watchfs को भी चालू करना न भूलें.
--google_auth_scopes=<comma-separated list of options>
डिफ़ॉल्ट: "https://www.googleapis.com/auth/cloud-platform"- Google Cloud में पुष्टि करने के तरीकों की सूची, कॉमा लगाकर अलग की गई है.
--google_credentials=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- पुष्टि करने वाले क्रेडेंशियल पाने के लिए, फ़ाइल की जानकारी दी जाती है. ज़्यादा जानकारी पाने के लिए, https://cloud.google.com/docs/authentication पर जाएं.
--[no]google_default_credentials
डिफ़ॉल्ट: "गलत"- पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी पाने के लिए, https://cloud.google.com/docs/authentication पर जाएं. डिफ़ॉल्ट रूप से बंद रहती है.
--grpc_keepalive_time=<An immutable length of time.>
डिफ़ॉल्ट: ब्यौरा देखें- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव पिंग को कॉन्फ़िगर करता है. अगर इस सेटिंग को सेट किया जाता है, तो काफ़ी देर तक कनेक्शन के बारे में पढ़ने के लिए, 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.action.symlink` का इस्तेमाल करके, किसी फ़ाइल को डायरेक्ट्री में सिमलिंक नहीं किया जा सकेगा.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_rule_name_parameter
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो `नियम` का इस्तेमाल किसी `name` पैरामीटर के साथ नहीं किया जा सकता.
टैग:loading_and_analysis
,incompatible_change
--[no]progress_in_terminal_title
डिफ़ॉल्ट: "गलत"- टर्मिनल के शीर्षक में कमांड की प्रोग्रेस दिखाएं. यह देखने में उपयोगी है कि कई टर्मिनल टैब होने पर बेज़ल क्या कर रहा है.
--[no]show_progress
डिफ़ॉल्ट: "सही"- किसी बिल्ड के दौरान प्रोग्रेस मैसेज दिखाएं.
--show_progress_rate_limit=<a double>
डिफ़ॉल्ट: "0.2"- आउटपुट मैसेज में, कम से कम कितने सेकंड लगेंगे.
--[no]show_timestamps
डिफ़ॉल्ट: "गलत"- मैसेज में टाइमस्टैंप जोड़ें
--tls_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- ऐसे TLS सर्टिफ़िकेट का पाथ डालें जिस पर सर्वर सर्टिफ़िकेट की मदद से भरोसा किया जाता है.
--tls_client_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए, TLS क्लाइंट सर्टिफ़िकेट बताएं. आपको क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए, TLS क्लाइंट कुंजी तय करें. इसके अलावा, क्लाइंट सर्टिफ़िकेट चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
--ui_actions_shown=<an integer>
डिफ़ॉल्ट: "8"-
ज़्यादा जानकारी वाले बार में दिखाई गई एक साथ की जाने वाली कार्रवाइयों की संख्या. हर कार्रवाई को एक अलग लाइन में दिखाया जाता है. प्रगति बार हमेशा कम से कम एक दिखाता है. 1 से कम की सभी संख्याओं को 1 पर मैप किया जाता है.
टैग:terminal_output
--[no]watchfs
डिफ़ॉल्ट: "गलत"- Linux/macOS पर: सही होने पर, bazel किसी बदलाव के लिए हर फ़ाइल को स्कैन करने के बजाय, लोकल बदलावों के लिए ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करती है. Windows पर, फ़िलहाल, यह फ़्लैग बिना किसी कार्रवाई के है. हालांकि, इसे --experimental_विंडो_watchfs के साथ चालू किया जा सकता है. किसी भी ओएस पर, अगर आपका फ़ाइल फ़ोल्डर किसी नेटवर्क फ़ाइल सिस्टम पर है, तो उसका व्यवहार तय नहीं होता है. साथ ही, रिमोट मशीन से फ़ाइलों में बदलाव किया जाता है.
विश्लेषण-प्रोफ़ाइल के विकल्प
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने उन्हें पार्स किया है:
--distdir=<a path>
बार कई बार इस्तेमाल किया गया-
संग्रहित करने के लिए नेटवर्क ऐक्सेस करने से पहले, उन्हें खोजने के लिए दूसरी जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "गलत"-
अगर इसे सेट किया जाता है, तो कैश मेमोरी में सेव होने वाले डेटा को कॉपी करने के बजाय रिपॉज़िटरी कैश मेमोरी, डेटा को हार्डलिंक कर देगी. इसका इस्तेमाल डिस्क में मौजूद जगह बचाने के लिए किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो डेटा के रिपॉज़िटरी के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल यूआरएल के तौर पर करें. इससे, यूआरएल में बदलाव होता है जिसकी वजह से डेटा फिर से डाउनलोड होता है. ऐसा तब भी होता है, जब कैश मेमोरी में एक ही हैश वाला डाउनलोड शामिल हो. इसका इस्तेमाल इस बात की पुष्टि करने के लिए किया जा सकता है कि यूआरएल में किए गए बदलावों की वजह से, कैश मेमोरी में सेव किए गए डेटा को सेव करने की सुविधा काम नहीं कर रही.
टैग:loading_and_analysis
,experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड करने की गड़बड़ी में फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो दोबारा कोशिश नहीं की जा सकती.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने के नियमों के सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड में बदलाव किए बिना, डेटा स्टोर करने की ऐसी जगहों पर काम किया जा सकता है जो नियम के लेखक की तुलना में धीमी हों.
टैग:bazel_internal_configuration
,experimental
--http_connector_attempts=<an integer>
डिफ़ॉल्ट: "8"-
http के ज़रिए डाउनलोड किए जाने वाले वीडियो की ज़्यादा से ज़्यादा संख्या.
टैग:bazel_internal_configuration
--http_connector_retry_max_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "0s"-
http डाउनलोड करने की फिर से कोशिश करने का ज़्यादा से ज़्यादा समय. शून्य से बड़ी वैल्यू के साथ, टाइम आउट की सबसे ज़्यादा वैल्यू तय नहीं की जाती.
टैग:bazel_internal_configuration
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
यहां दिए गए फ़ैक्टर के हिसाब से, एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
इसमें बाहरी स्टोर करने की जगहों को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू को कैश मेमोरी में सेव करने की जगह होती है. एक खाली स्ट्रिंग, जिसमें आर्ग्युमेंट के तौर पर, कैश मेमोरी को बंद करने का अनुरोध किया गया हो. अगर ऐसा नहीं है, तो '< आउटपुट_user_root>/cache/repos/v1' का डिफ़ॉल्ट इस्तेमाल किया जाता है
टैग:bazel_internal_configuration
--[no]repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया जाता है, तो रिपॉज़िटरी फ़ेच करने के दौरान, ctx.download{,_and_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं है. फिर भी, ctx.execute इंटरनेट को ऐक्सेस करने वाली आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग:bazel_internal_configuration
- बिल्डिंग एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:
--experimental_oom_more_eagerly_threshold=<an integer in 0-100 range>
डिफ़ॉल्ट: "100"-
अगर इस फ़्लैग को 100 से कम पर सेट किया जाता है, तो बेज़ल तब तक OOM करेगा, जब तक कि पूरे जीसी में दो के बाद भी, "पुरानी पीढ़ी के" हीप के प्रतिशत की संख्या ज़्यादा नहीं है.
टैग:host_machine_resource_optimizations
- वे विकल्प जो यह तय करते हैं कि Bazel, बिल्ड के मान्य इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
यह नीति खाली न होने पर, एक ऐसी फ़ाइल की जानकारी देती है जिसमें रिज़ॉल्व की गई वैल्यू होती है. इसके लिए, रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--experimental_verify_repository_rules=<a string>
बार कई बार इस्तेमाल किया गया-
अगर डेटा स्टोर करने से जुड़े उन नियमों की सूची जिसके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, फ़ाइल को --experimental_repository_ash_file में दिखाया जाता है.
टैग:affects_outputs
,experimental
- यह विकल्प Starlark भाषा के सिमेंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों को ऐक्सेस करने लायक बिल्ड एपीआई पर असर डालता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
नहीं
टैग:no_op
,deprecated
,experimental
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
--allow_yanked_versions=<a string>
बार कई बार इस्तेमाल किया गया-
मॉड्यूल वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर बताया गया है, जिसे रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में अनुमति दी जाएगी, भले ही वे रजिस्ट्री में याक के तौर पर सेट किए गए हों (अगर वे NonRegistryOverride से नहीं आ रहे हों). अगर ऐसा नहीं है, तो याक किए गए वर्शन की वजह से रिज़ॉल्यूशन काम नहीं करेगा. आप `BZLMOD_ALLOW_YANKED_VersionS` परिवेश वैरिएबल के साथ, मंज़ूर किया गया याक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Ba आवाज़ मॉड्यूल के बेज़ल वर्शन के साथ काम करने की सुविधा की जांच करें. मान्य वैल्यू 'गड़बड़ी' है. इसे समस्या की पहचान नहीं करने पर, जांच करने की अनुमति नहीं दी जाती. इसके अलावा, `चेतावनी` दिखाने के लिए, `गड़बड़ी` की जानकारी दी जाती है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में तय की गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो समाधान किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. सही वैल्यू न होने पर, जांच को बंद करने के लिए `बंद करें` पर सेट किया जाता है. ऐसा न होने पर चेतावनी मिलने पर उसे `चेतावनी` देने के लिए सेट किया जाता है.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो Baze ध्यान दें कि अगर MODULE.bazel में यह डेवलपर डिपेंडेंसी है, तो ध्यान न दें कि यह फ़्लैग मॉड्यूल की वैल्यू पर ध्यान दिए बिना रूट मॉड्यूल है या नहीं.
टैग:loading_and_analysis
--lockfile_mode=<off, update or error>
डिफ़ॉल्ट: "बंद" है-
यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे करना है या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य मान `अपडेट` होते हैं. साथ ही, अगर लॉकफ़ाइल इस्तेमाल करने के लिए उनमें कोई गड़बड़ी होती है, तो उन्हें अपडेट किया जाता है. साथ ही, अगर वे अप-टू-डेट नहीं हैं या फिर उन्हें लॉकफ़ाइल से पढ़ना या लिखना नहीं है, तो गड़बड़ी होती है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई बार इस्तेमाल किया गया- मॉड्यूल को स्थानीय पाथ से <module name>=<path> के तौर पर बदलें. अगर दिया गया पाथ एक पूरा पाथ है, तो इसे इसी तरह इस्तेमाल किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `bazel info workspace` का आउटपुट है
--registry=<a string>
बार कई बार इस्तेमाल किया गया-
यह, रजिस्ट्री को बताता है कि इसका इस्तेमाल Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किया जाए. क्रम अहम है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब दिखेगा, जब वे पिछली रजिस्ट्री से छूट जाएंगी.
टैग:changes_inputs
- ऐसे विकल्प जो बिल्ड टाइम के ऑप्टिमाइज़ेशन को ट्रिगर करते हैं:
--experimental_gc_thrashing_limits=<comma separated pairs of <period>:<count>>
डिफ़ॉल्ट: ""-
सीमाएं, अगर उन तक पहुंचा जाता है, तो GcTharaishDetecter ने OOM के साथ Bazel को बंद कर दिया. हर सीमा को <period>:<count> के तौर पर बताया गया है, जहां अवधि एक अवधि और गिनती एक धनात्मक पूर्णांक होती है. <period> में लगातार एक साथ काम करने वाले <count> पूरे जीसी के बाद, अवधि के लिए इस्तेमाल किए गए स्पेस का कितना हिस्सा, {2}experimental_oom_more_eagerly_threshold प्रतिशत से ज़्यादा होता है. एक से ज़्यादा सीमाएं, कॉमा की मदद से अलग की जा सकती हैं.
टैग:host_machine_resource_optimizations
--[no]gc_thrashing_limits_retained_heap_limiter_mutually_exclusive
डिफ़ॉल्ट: "सही"-
अगर सही है, तो खाली --experimental_gc_thraish_limits के बारे में बताने से, बरकरार रखे गए Heaplimiter को बंद कर दिया जाता है, ताकि यह GcThrishDetecter के साथ मिलकर काम कर सके. गलत पर सेट करने से, दोनों एक ही निर्देश के लिए चालू रहते हैं.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0>
डिफ़ॉल्ट: "2147483647"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बज़ल को पता चलता है कि उसके हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो पूरा GC इवेंट होने पर, वह ज़रूरत के मुताबिक स्काईफ़्रेम स्थिति में कई बार छूट देगा. डिफ़ॉल्ट रूप से Integer.MAX_VALUE डिफ़ॉल्ट तौर पर अनलिमिटेड होता है. शून्य का मतलब है कि GC के पूरे इवेंट में कभी भी कमी नहीं होगी. अगर सीमा पूरी हो जाती है, तो किसी पूरी GC इवेंट के होने पर Skyframe की स्थिति में गिरावट नहीं आएगी. साथ ही, हीप हीप के प्रतिशत की तय सीमा भी पार हो जाएगी.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0>
डिफ़ॉल्ट: "2147483647"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बैजल को पता चलता है कि उसके हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो एक छोटा GC इवेंट होने पर, वह ज़रूरत के मुताबिक स्काईफ़्रेम स्थिति को कई बार छोड़ देगा. हालांकि, शुरू करने पर कई बार ऐसा होगा. डिफ़ॉल्ट रूप से Integer.MAX_VALUE डिफ़ॉल्ट तौर पर अनलिमिटेड होता है. शून्य का मतलब है कि GC के छोटे इवेंट में कभी भी गिरावट नहीं होगी. अगर सीमा पूरी हो जाती है, तो किसी छोटे GC इवेंट के ट्रिगर होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा. साथ ही, हीप हीप के प्रतिशत की सीमा पार हो जाएगी.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer>
डिफ़ॉल्ट: "85"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बेज़ल को लगता है कि उसके रखरखाव वाले हीप प्रतिशत का इस्तेमाल कम से कम इस सीमा तक है, तो वह कुछ समय के लिए स्काईफ़्रेम की गैर-ज़रूरी स्थिति में नहीं आएगा. इसे बदलने से, जीसी थ्रॉशिंग के असर को कम किया जा सकता है. हालांकि, जीसी थ्रैशिंग की वजह से, (i) इस अस्थायी स्थिति की मेमोरी का इस्तेमाल करना और (ii) राज्य की ज़रूरत के हिसाब से उसे दोबारा बनाना काफ़ी महंगा पड़ता है.
टैग:host_machine_resource_optimizations
- ऐसे विकल्प जो बोली की जानकारी, फ़ॉर्मैट, या जगह की जानकारी पर असर डालते हैं:
--dump=<text or raw>
[-d
] डिफ़ॉल्ट है: ब्यौरा देखें-
पूरी प्रोफ़ाइल का डेटा डंप बनाएं, जिसे 'टेक्स्ट' के फ़ॉर्मैट में या स्क्रिप्ट के मुताबिक 'रॉ' फ़ॉर्मैट में पढ़ा जा सके.
टैग:affects_outputs
--[no]experimental_command_profile
डिफ़ॉल्ट: "गलत"- Java में मौजूद फ़्लाइट रिकॉर्डर की प्रोफ़ाइल प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद किसी file.jfr में रिकॉर्ड करता है. इस फ़्लैग का सिंटैक्स और सिमेंटिक अलग-अलग तरह के प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, आने वाले समय में बदल सकता है. अपने जोखिम पर इसका इस्तेमाल करें.
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई टाइप की संख्या 20 वर्ण के ज़्यादा होती है. इसे लागू करने के लिए, सबसे ज़्यादा संख्या का इस्तेमाल किया जाता है. इस विकल्प को सेट करने पर सभी शब्दावली के लिए आंकड़े लिखे जाएंगे.
- Baze कमांड के लिए जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो दूसरी कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली न हो, तो WORKSPACE फ़ाइल की जगह समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और एक्ज़ीक्यूशन के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में कई लाइनें होती हैं. इनमें से हर एक के साथ एक डायरेक्टिव होता है (`allow`, `block` या `rewrite`). इसके बाद होस्ट का नाम होता है (`allow` या `block`) या दो पैटर्न होते हैं, एक मेल खाने वाला होता है, और वैकल्पिक यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें$1 से शुरू होता है. एक ही यूआरएल के लिए एक से ज़्यादा `rewrite` डायरेक्टिव देना संभव है. इस मामले में, एक से ज़्यादा यूआरएल देना.
--experimental_worker_for_repo_fetching=<off, platform or virtual>
डिफ़ॉल्ट: "बंद" है- रीपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. इसके अलावा, रेपो फ़ेच को रीस्टार्ट किया जाता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर 'प्लैटफ़ॉर्म थ्रेड' या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करें.
- ऐसे अन्य विकल्प जिन्हें कैटगरी में नहीं बांटा गया है.:
--override_repository=<an equals-separated mapping of repository name to path>
बार कई बार इस्तेमाल किया गया- डेटा स्टोर करने की जगह को <repository name>=<path> के तौर पर स्थानीय पाथ में बदलें. अगर दिया गया पाथ एक सटीक पाथ है, तो इसे इसी तरह इस्तेमाल किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा डायरेक्ट्री से जुड़ा है. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `bazel info workspace` का आउटपुट है
क्वेरी के विकल्प
build से सभी विकल्प इनहेरिट करता है.
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने उन्हें पार्स किया है:
--distdir=<a path>
बार कई बार इस्तेमाल किया गया-
संग्रहित करने के लिए नेटवर्क ऐक्सेस करने से पहले, उन्हें खोजने के लिए दूसरी जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "गलत"-
अगर इसे सेट किया जाता है, तो कैश मेमोरी में सेव होने वाले डेटा को कॉपी करने के बजाय रिपॉज़िटरी कैश मेमोरी, डेटा को हार्डलिंक कर देगी. इसका इस्तेमाल डिस्क में मौजूद जगह बचाने के लिए किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो डेटा के रिपॉज़िटरी के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल यूआरएल के तौर पर करें. इससे, यूआरएल में बदलाव होता है जिसकी वजह से डेटा फिर से डाउनलोड होता है. ऐसा तब भी होता है, जब कैश मेमोरी में एक ही हैश वाला डाउनलोड शामिल हो. इसका इस्तेमाल इस बात की पुष्टि करने के लिए किया जा सकता है कि यूआरएल में किए गए बदलावों की वजह से, कैश मेमोरी में सेव किए गए डेटा को सेव करने की सुविधा काम नहीं कर रही.
टैग:loading_and_analysis
,experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड करने की गड़बड़ी में फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो दोबारा कोशिश नहीं की जा सकती.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने के नियमों के सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड में बदलाव किए बिना, डेटा स्टोर करने की ऐसी जगहों पर काम किया जा सकता है जो नियम के लेखक की तुलना में धीमी हों.
टैग:bazel_internal_configuration
,experimental
--http_connector_attempts=<an integer>
डिफ़ॉल्ट: "8"-
http के ज़रिए डाउनलोड किए जाने वाले वीडियो की ज़्यादा से ज़्यादा संख्या.
टैग:bazel_internal_configuration
--http_connector_retry_max_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "0s"-
http डाउनलोड करने की फिर से कोशिश करने का ज़्यादा से ज़्यादा समय. शून्य से बड़ी वैल्यू के साथ, टाइम आउट की सबसे ज़्यादा वैल्यू तय नहीं की जाती.
टैग:bazel_internal_configuration
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
यहां दिए गए फ़ैक्टर के हिसाब से, एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
इसमें बाहरी स्टोर करने की जगहों को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू को कैश मेमोरी में सेव करने की जगह होती है. एक खाली स्ट्रिंग, जिसमें आर्ग्युमेंट के तौर पर, कैश मेमोरी को बंद करने का अनुरोध किया गया हो. अगर ऐसा नहीं है, तो '< आउटपुट_user_root>/cache/repos/v1' का डिफ़ॉल्ट इस्तेमाल किया जाता है
टैग:bazel_internal_configuration
--[no]repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया जाता है, तो रिपॉज़िटरी फ़ेच करने के दौरान, ctx.download{,_and_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं है. फिर भी, ctx.execute इंटरनेट को ऐक्सेस करने वाली आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग:bazel_internal_configuration
- बिल्डिंग एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:
--experimental_oom_more_eagerly_threshold=<an integer in 0-100 range>
डिफ़ॉल्ट: "100"-
अगर इस फ़्लैग को 100 से कम पर सेट किया जाता है, तो बेज़ल तब तक OOM करेगा, जब तक कि पूरे जीसी में दो के बाद भी, "पुरानी पीढ़ी के" हीप के प्रतिशत की संख्या ज़्यादा नहीं है.
टैग:host_machine_resource_optimizations
- वे विकल्प जो यह तय करते हैं कि Bazel, बिल्ड के मान्य इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
यह नीति खाली न होने पर, एक ऐसी फ़ाइल की जानकारी देती है जिसमें रिज़ॉल्व की गई वैल्यू होती है. इसके लिए, रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--experimental_verify_repository_rules=<a string>
बार कई बार इस्तेमाल किया गया-
अगर डेटा स्टोर करने से जुड़े उन नियमों की सूची जिसके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, फ़ाइल को --experimental_repository_ash_file में दिखाया जाता है.
टैग:affects_outputs
,experimental
- यह विकल्प Starlark भाषा के सिमेंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों को ऐक्सेस करने लायक बिल्ड एपीआई पर असर डालता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
नहीं
टैग:no_op
,deprecated
,experimental
- क्वेरी के आउटपुट और सिमैंटिक से जुड़े विकल्प:
--aspect_deps=<off, conservative or precise>
डिफ़ॉल्ट: "कंज़र्वेटिव"-
जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से किसी एक में हो, तो आसपेक्ट डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी पक्ष की डिपेंडेंसी का समाधान नहीं हुआ है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि बताए गए सभी आसपेक्ट डिपेंडेंसी जोड़े गए हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के लिए नियम की कैटगरी दी गई हो. इसका मतलब है कि सीधे तौर पर डिपेंडेंसी के नियम की कैटगरी के तहत, सिर्फ़ वे आसपेक्ट जोड़े गए हैं जो शायद चालू हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इस वजह से, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि पूरी तरह सटीक मोड भी नहीं होता: फै़सले के आधार पर यह तय किया जाता है कि आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को कैलकुलेट करना है या नहीं. यह फ़ैसला 'बेज़ल क्वेरी' के दौरान नहीं चलता.
टैग:build_file_semantics
--[no]deduplicate_depsets
डिफ़ॉल्ट: "सही"-
आखिरी प्रोटो/textproto/json आउटपुट में, dep_set_of_फ़ाइलों के नॉन-लीफ़ वाले बच्चों के डुप्लीकेट डेटा हटाएं. यह उन गिरावटों को डीडुप्लीकेट नहीं करता है जो ताज़िक अभिभावक को शेयर नहीं करते हैं. हालांकि, इससे कार्रवाइयों की इनपुट आर्टफ़ैक्ट की आखिरी असरदार सूची पर कोई असर नहीं पड़ता.
टैग:terminal_output
--[no]experimental_parallel_aquery_output
डिफ़ॉल्ट: "गलत"- क्वेरी क्वेरी प्रोटो/टेक्स्टप्रोटो को साथ-साथ लिखा जाना चाहिए. अन्य आउटपुट फ़ॉर्मैट के लिए नहीं.
--[no]graph:factored
डिफ़ॉल्ट: "सही"-
अगर सही है, तो ग्राफ़ को 'फ़ैक्टर' किया जाता है.जैसे, भौगोलिक स्थिति के बराबर नोड को एक साथ मर्ज कर दिया जाता है. साथ ही, उनके लेबल आपस में जुड़ जाते हैं. यह विकल्प सिर्फ़ -- आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--graph:node_limit=<an integer>
डिफ़ॉल्ट: "512"-
आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल छोटे कर दिए जाएंगे -1 का मतलब है काट-छांट नहीं. यह विकल्प सिर्फ़ -- आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--[no]implicit_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, इंडिपेंडेंट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी जिस पर क्वेरी ऑपरेट की जाती है. इंप्लिसिट डिपेंडेंसी, BUILD फ़ाइल में साफ़ तौर पर नहीं बताई जाती. हालांकि, इसे bazel में जोड़ा जाता है. क्वेरी के लिए, यह विकल्प फ़िल्टर किए गए टूलचेन को फ़िल्टर करने पर कंट्रोल करता है.
टैग: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
डिफ़ॉल्ट: "गलत"-
FileWrite और SourceSymlinkManifest कार्रवाइयों (शायद ज़्यादा बड़ी) के लिए फ़ाइल का कॉन्टेंट शामिल करें.
टैग:terminal_output
--[no]include_param_files
डिफ़ॉल्ट: "गलत"-
कमांड में शामिल पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें (हो सकता है कि बड़ा हो). ध्यान दें: इस फ़्लैग को चालू करने से --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
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट करके और 'यूनिवर्स_स्कोप' को सेट नहीं किया जाता है, तो क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर, 'यूनिवर्स_स्कोप' की वैल्यू का पता लगाया जाएगा. ध्यान दें कि यूनिवर्स के दायरे वाले फ़ंक्शन (उदाहरण के लिए, `allrdeps`) का इस्तेमाल करने वाली क्वेरी एक्सप्रेशन के लिए तय --यूनीवर्स_स्कोप की वैल्यू आपकी पसंद के मुताबिक नहीं हो सकती है. इसलिए, आपको इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query देखें. अगर --universa_scope सेट हो, तो इस विकल्प की वैल्यू को नज़रअंदाज़ कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `क्वेरी` पर लागू होता है (उदाहरण के लिए, `cquery` नहीं).
टैग:loading_and_analysis
--[no]line_terminator_null
डिफ़ॉल्ट: "गलत"-
क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाता है.
टैग:terminal_output
--[no]nodep_deps
डिफ़ॉल्ट: "सही"-
अगर यह चालू है, तो "nodep" एट्रिब्यूट के डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी जिस पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "किसको दिखे" है. बिल्ड भाषा में सभी "नोडप" विशेषताओं के बारे में जानने के लिए `info build-language` के आउटपुट को चलाएं और पार्स करें.
टैग:build_file_semantics
--output=<a string>
डिफ़ॉल्ट: "टेक्स्ट"-
वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: text, textproto, proto, Stream_proto, jsonproto.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो BUILD फ़ाइल में साफ़ तौर पर तय नहीं किए गए एट्रिब्यूट शामिल होते हैं. ऐसा न होने पर, उन्हें छोड़ दिया जाता है. यह विकल्प --आउटपुट=प्रोटो
टैग पर लागू होता है:terminal_output
--[no]proto:definition_stack
डिफ़ॉल्ट: "गलत"-
डेफ़िनिशन_स्टैक प्रोटो फ़ील्ड को पॉप्युलेट करें. यह हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है, जहां नियम की क्लास तय होने के दौरान Starlark कॉल स्टैक होता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, Select() से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट फ़्लैट हो जाते हैं. सूची के टाइप को फ़्लैट करने के विकल्प को चुनने पर, चुने गए मैप की हर वैल्यू को सिर्फ़ एक बार शामिल किया जाता है. स्केलर के प्रकार शून्य हो जाते हैं.
टैग:build_file_semantics
--[no]proto:include_attribute_source_aspects
डिफ़ॉल्ट: "गलत"-
हर एट्रिब्यूट के सोर्स_aspect_name प्रोटो फ़ील्ड में, सोर्स का आसपेक्ट रेशियो डालें. अगर एट्रिब्यूट मौजूद नहीं है, तो खाली स्ट्रिंग डालें.
टैग:terminal_output
--[no]proto:include_synthetic_attribute_hash
डिफ़ॉल्ट: "गलत"- $internal_attr_ash एट्रिब्यूट को कैलकुलेट करना और पॉप्युलेट करना है या नहीं.
टैग:terminal_output
--[no]proto:instantiation_stack
डिफ़ॉल्ट: "गलत"-
हर एक नियम के इंस्टैंशिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग:terminal_output
--[no]proto:locations
डिफ़ॉल्ट: "सही"-
प्रोटो आउटपुट में जगह की जानकारी का इस्तेमाल करें या नहीं.
टैग:terminal_output
--proto:output_rule_attrs=<comma-separated list of options>
डिफ़ॉल्ट: "सभी"-
आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर यह सभी एट्रिब्यूट पर लागू होता है. किसी भी एट्रिब्यूट को आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प -- आउटपुट=प्रोटो पर लागू होता है.
टैग:terminal_output
--[no]proto:rule_inputs_and_outputs
डिफ़ॉल्ट: "सही"-
नियम_इनपुट और नियम_आउटपुट फ़ील्ड को भरना है या नहीं.
टैग:terminal_output
--query_file=<a string>
डिफ़ॉल्ट: ""-
अगर इस नीति को सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां बताई गई फ़ाइल से क्वेरी को पढ़ेगी. यहां किसी फ़ाइल के साथ-साथ कमांड-लाइन क्वेरी डालने में कोई गड़बड़ी हुई.
टैग:changes_inputs
--[no]relative_locations
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक सटीक रास्ता होता है और यह मशीनों पर एक जैसा नहीं होगा. सभी मशीनों में एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग:terminal_output
--[no]skyframe_state
डिफ़ॉल्ट: "गलत"-
अतिरिक्त विश्लेषण किए बिना, Skyframe से मौजूदा कार्रवाई ग्राफ़ को खारिज करें. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय नहीं किया जा सकता. यह फ़्लैग सिर्फ़ -- आउटपुट=प्रोटो या -- आउटपुट=टेक्स्टप्रोटो के साथ उपलब्ध है.
टैग:terminal_output
--[no]tool_deps
डिफ़ॉल्ट: "सही"-
क्वेरी: अगर यह नीति बंद हो, तो 'एक्ज़ीक्यूट करने से जुड़े कॉन्फ़िगरेशन' पर निर्भरता को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाएगा जिस पर क्वेरी काम करती है. 'एक्ज़ीक्यूट कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक, आम तौर पर एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान चलाए गए टूल पर ले जाता है.
क्वेरी: अगर यह बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो लागू किए गए इस टारगेट को खोजने वाले टॉप-लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट भी वापस मिलेंगे. अगर टॉप-लेवल टारगेट एक्ज़ीक्यूट कॉन्फ़िगरेशन में है, तो सिर्फ़ एक्ज़ीक्यूट किए गए टारगेट ही दिखाए जाएंगे. यह विकल्प, ठीक किए गए टूलचेन को बाहर नहीं रखेगा.
टैग:build_file_semantics
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा जाने वाला और घटाने वाला). क्वेरी को दिए गए टारगेट के ट्रांज़िटिव बंद होने के ब्रह्मांड में तय किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और क्वेरी कमांड के लिए किया जाता है.
क्वेरी के लिए, इस विकल्प में इनपुट उन सभी जवाबों को टारगेट करता है जिनके तहत जवाब बनाए गए हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प तय नहीं किया गया है, तो यह माना जाता है कि सबसे ऊपर के टारगेट को क्वेरी एक्सप्रेशन से पार्स किया गया टारगेट माना जाता है. ध्यान दें: क्वेरी के लिए, इस विकल्प को तय न करने से बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट टॉप-लेवल के विकल्पों के साथ बनाए नहीं जा सकते.
टैग:loading_and_analysis
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
--allow_yanked_versions=<a string>
बार कई बार इस्तेमाल किया गया-
मॉड्यूल वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर बताया गया है, जिसे रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में अनुमति दी जाएगी, भले ही वे रजिस्ट्री में याक के तौर पर सेट किए गए हों (अगर वे NonRegistryOverride से नहीं आ रहे हों). अगर ऐसा नहीं है, तो याक किए गए वर्शन की वजह से रिज़ॉल्यूशन काम नहीं करेगा. आप `BZLMOD_ALLOW_YANKED_VersionS` परिवेश वैरिएबल के साथ, मंज़ूर किया गया याक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Ba आवाज़ मॉड्यूल के बेज़ल वर्शन के साथ काम करने की सुविधा की जांच करें. मान्य वैल्यू 'गड़बड़ी' है. इसे समस्या की पहचान नहीं करने पर, जांच करने की अनुमति नहीं दी जाती. इसके अलावा, `चेतावनी` दिखाने के लिए, `गड़बड़ी` की जानकारी दी जाती है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में तय की गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो समाधान किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. सही वैल्यू न होने पर, जांच को बंद करने के लिए `बंद करें` पर सेट किया जाता है. ऐसा न होने पर चेतावनी मिलने पर उसे `चेतावनी` देने के लिए सेट किया जाता है.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो Baze ध्यान दें कि अगर MODULE.bazel में यह डेवलपर डिपेंडेंसी है, तो ध्यान न दें कि यह फ़्लैग मॉड्यूल की वैल्यू पर ध्यान दिए बिना रूट मॉड्यूल है या नहीं.
टैग:loading_and_analysis
--lockfile_mode=<off, update or error>
डिफ़ॉल्ट: "बंद" है-
यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे करना है या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य मान `अपडेट` होते हैं. साथ ही, अगर लॉकफ़ाइल इस्तेमाल करने के लिए उनमें कोई गड़बड़ी होती है, तो उन्हें अपडेट किया जाता है. साथ ही, अगर वे अप-टू-डेट नहीं हैं या फिर उन्हें लॉकफ़ाइल से पढ़ना या लिखना नहीं है, तो गड़बड़ी होती है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई बार इस्तेमाल किया गया- मॉड्यूल को स्थानीय पाथ से <module name>=<path> के तौर पर बदलें. अगर दिया गया पाथ एक पूरा पाथ है, तो इसे इसी तरह इस्तेमाल किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `bazel info workspace` का आउटपुट है
--registry=<a string>
बार कई बार इस्तेमाल किया गया-
यह, रजिस्ट्री को बताता है कि इसका इस्तेमाल Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किया जाए. क्रम अहम है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब दिखेगा, जब वे पिछली रजिस्ट्री से छूट जाएंगी.
टैग:changes_inputs
- ऐसे विकल्प जो बिल्ड टाइम के ऑप्टिमाइज़ेशन को ट्रिगर करते हैं:
--experimental_gc_thrashing_limits=<comma separated pairs of <period>:<count>>
डिफ़ॉल्ट: ""-
सीमाएं, अगर उन तक पहुंचा जाता है, तो GcTharaishDetecter ने OOM के साथ Bazel को बंद कर दिया. हर सीमा को <period>:<count> के तौर पर बताया गया है, जहां अवधि एक अवधि और गिनती एक धनात्मक पूर्णांक होती है. <period> में लगातार एक साथ काम करने वाले <count> पूरे जीसी के बाद, अवधि के लिए इस्तेमाल किए गए स्पेस का कितना हिस्सा, {2}experimental_oom_more_eagerly_threshold प्रतिशत से ज़्यादा होता है. एक से ज़्यादा सीमाएं, कॉमा की मदद से अलग की जा सकती हैं.
टैग:host_machine_resource_optimizations
--[no]gc_thrashing_limits_retained_heap_limiter_mutually_exclusive
डिफ़ॉल्ट: "सही"-
अगर सही है, तो खाली --experimental_gc_thraish_limits के बारे में बताने से, बरकरार रखे गए Heaplimiter को बंद कर दिया जाता है, ताकि यह GcThrishDetecter के साथ मिलकर काम कर सके. गलत पर सेट करने से, दोनों एक ही निर्देश के लिए चालू रहते हैं.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0>
डिफ़ॉल्ट: "2147483647"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बज़ल को पता चलता है कि उसके हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो पूरा GC इवेंट होने पर, वह ज़रूरत के मुताबिक स्काईफ़्रेम स्थिति में कई बार छूट देगा. डिफ़ॉल्ट रूप से Integer.MAX_VALUE डिफ़ॉल्ट तौर पर अनलिमिटेड होता है. शून्य का मतलब है कि GC के पूरे इवेंट में कभी भी कमी नहीं होगी. अगर सीमा पूरी हो जाती है, तो किसी पूरी GC इवेंट के होने पर Skyframe की स्थिति में गिरावट नहीं आएगी. साथ ही, हीप हीप के प्रतिशत की तय सीमा भी पार हो जाएगी.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0>
डिफ़ॉल्ट: "2147483647"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बैजल को पता चलता है कि उसके हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो एक छोटा GC इवेंट होने पर, वह ज़रूरत के मुताबिक स्काईफ़्रेम स्थिति को कई बार छोड़ देगा. हालांकि, शुरू करने पर कई बार ऐसा होगा. डिफ़ॉल्ट रूप से Integer.MAX_VALUE डिफ़ॉल्ट तौर पर अनलिमिटेड होता है. शून्य का मतलब है कि GC के छोटे इवेंट में कभी भी गिरावट नहीं होगी. अगर सीमा पूरी हो जाती है, तो किसी छोटे GC इवेंट के ट्रिगर होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा. साथ ही, हीप हीप के प्रतिशत की सीमा पार हो जाएगी.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer>
डिफ़ॉल्ट: "85"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बेज़ल को लगता है कि उसके रखरखाव वाले हीप प्रतिशत का इस्तेमाल कम से कम इस सीमा तक है, तो वह कुछ समय के लिए स्काईफ़्रेम की गैर-ज़रूरी स्थिति में नहीं आएगा. इसे बदलने से, जीसी थ्रॉशिंग के असर को कम किया जा सकता है. हालांकि, जीसी थ्रैशिंग की वजह से, (i) इस अस्थायी स्थिति की मेमोरी का इस्तेमाल करना और (ii) राज्य की ज़रूरत के हिसाब से उसे दोबारा बनाना काफ़ी महंगा पड़ता है.
टैग:host_machine_resource_optimizations
- ऐसे विकल्प जो बोली की जानकारी, फ़ॉर्मैट, या जगह की जानकारी पर असर डालते हैं:
--[no]experimental_command_profile
डिफ़ॉल्ट: "गलत"- Java में मौजूद फ़्लाइट रिकॉर्डर की प्रोफ़ाइल प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद किसी file.jfr में रिकॉर्ड करता है. इस फ़्लैग का सिंटैक्स और सिमेंटिक अलग-अलग तरह के प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, आने वाले समय में बदल सकता है. अपने जोखिम पर इसका इस्तेमाल करें.
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई टाइप की संख्या 20 वर्ण के ज़्यादा होती है. इसे लागू करने के लिए, सबसे ज़्यादा संख्या का इस्तेमाल किया जाता है. इस विकल्प को सेट करने पर सभी शब्दावली के लिए आंकड़े लिखे जाएंगे.
- Baze कमांड के लिए जेनरिक इनपुट तय करने या उसमें बदलाव करने के विकल्प, जो दूसरी कैटगरी में नहीं आते.:
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली न हो, तो WORKSPACE फ़ाइल की जगह समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
- रिमोट कैश मेमोरी और एक्ज़ीक्यूशन के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में कई लाइनें होती हैं. इनमें से हर एक के साथ एक डायरेक्टिव होता है (`allow`, `block` या `rewrite`). इसके बाद होस्ट का नाम होता है (`allow` या `block`) या दो पैटर्न होते हैं, एक मेल खाने वाला होता है, और वैकल्पिक यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें$1 से शुरू होता है. एक ही यूआरएल के लिए एक से ज़्यादा `rewrite` डायरेक्टिव देना संभव है. इस मामले में, एक से ज़्यादा यूआरएल देना.
--experimental_worker_for_repo_fetching=<off, platform or virtual>
डिफ़ॉल्ट: "बंद" है- रीपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. इसके अलावा, रेपो फ़ेच को रीस्टार्ट किया जाता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर 'प्लैटफ़ॉर्म थ्रेड' या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करें.
- ऐसे अन्य विकल्प जिन्हें कैटगरी में नहीं बांटा गया है.:
--override_repository=<an equals-separated mapping of repository name to path>
बार कई बार इस्तेमाल किया गया- डेटा स्टोर करने की जगह को <repository name>=<path> के तौर पर स्थानीय पाथ में बदलें. अगर दिया गया पाथ एक सटीक पाथ है, तो इसे इसी तरह इस्तेमाल किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा डायरेक्ट्री से जुड़ा है. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह फ़ाइल फ़ोल्डर की रूट के बराबर है, जो `bazel info workspace` का आउटपुट है
- विकल्प जो बिल्ड एक्ज़ीक्यूशन को कंट्रोल करते हैं:
--[no]experimental_inprocess_symlink_creation
डिफ़ॉल्ट: "गलत"-
सिमलिंक ट्री बनाने के लिए, सीधे फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_remotable_source_manifests
डिफ़ॉल्ट: "गलत"-
सोर्स मेनिफ़ेस्ट ऐक्शन को बदला जा सकने वाला बनाना है
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_split_coverage_postprocessing
डिफ़ॉल्ट: "गलत"-
अगर यह नीति सही है, तो Bazel, नए स्पॉन में टेस्ट के लिए कवरेज के बाद, प्रोसेस करेगा.
टैग:execution
--[no]experimental_strict_fileset_output
डिफ़ॉल्ट: "गलत"-
अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री में अदला-बदली नहीं करेंगे या सिमलिंक का संवेदनशील नहीं होंगे.
टैग:execution
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...>
डिफ़ॉल्ट: ""-
कार्रवाई की जानकारी के आधार पर, 'कार्रवाई' से जुड़ी जानकारी में कुंजियां जोड़ें या हटाएं. यह नीति सिर्फ़ उन कार्रवाइयों पर लागू होती है जिनमें प्रोग्राम चलाने की जानकारी होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी होती है. उदाहरण के लिए, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. कई वैल्यू तय करते समय, ऑर्डर अहम होता है. ऐसा इसलिए होता है, क्योंकि एक से ज़्यादा रेगुलर एक्सप्रेशन में एक से ज़्यादा रेगुलर एक्सप्रेशन लागू हो सकते हैं.
सिंटैक्स: "regex=[+-key,regex=[+-key],...".
उदाहरण:
'.*=+x,.*=-y,.*=+z', 'x' और 'z' को जोड़ देता है. साथ ही, 'y' को हटा देता है. इसके लिए, सभी कार्रवाइयों के लिए कार्रवाई की जानकारी नहीं दी जाती.
'Genrule=+Requires-x' जोड़ने पर 'Requires-x' जुड़ जाता है.
'(?!Genrule).*=-Requires-x', गैर-Genrule कार्रवाइयों के लिए लागू होने वाली जानकारी से 'Requires-x' हटा देता है.
टैग:execution
,affects_outputs
,loading_and_analysis
--persistent_android_dex_desugar
-
कर्मचारियों की मदद से, Android पर काम करने वाली और Desgar की स्थायी कार्रवाइयों को चालू करें.
इसमें यह भी शामिल है:
--internal_persistent_android_dex_desugar
--strategy=Desugar=worker
--strategy=DexBuilder=worker
टैग:host_machine_resource_optimizations
,execution
--persistent_android_resource_processor
-
कर्मचारियों की मदद से, Android पर लगातार काम करने वाले संसाधन को चालू करें.
इसमें यह भी शामिल है:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
}--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
host_machine_resource_optimizations
execution
--persistent_multiplex_android_dex_desugar
-
कर्मचारियों की मदद से, मल्टीप्लेक्स Android Dex और Desgar कार्रवाइयां लगातार करें.
इसमें यह भी शामिल है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
--persistent_multiplex_android_resource_processor
-
कर्मचारियों की मदद से, मल्टीप्लेक्स Android रिसॉर्स प्रोसेसर को स्थायी तौर पर चालू करें.
इसमें यह भी शामिल है:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
}--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers
host_machine_resource_optimizations
execution
--persistent_multiplex_android_tools
-
Android और उससे जुड़े मल्टीप्लेक्स टूल (डेक्सिंग, डीज़र्जिंग, रिसॉर्स प्रोसेसिंग) को चालू करें.
इसमें यह भी शामिल है:
--internal_persistent_multiplex_busybox_tools
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
--[no]use_target_platform_for_tests
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bazel, जांच करने वाले ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करके टेस्ट करेगा.
टैग:execution
- ऐसे ऐक्शनचेन टूल को कॉन्फ़िगर करने के विकल्प जो कार्रवाई करने के लिए इस्तेमाल होते हैं:
--android_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट कंपाइलर.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_crosstool_top=<a build target label>
डिफ़ॉल्ट: "//external:android/crosstool"-
Android बिल्ड के लिए इस्तेमाल किए गए C++ कंपाइलर की जगह.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_manifest_merger=<legacy, android or force_android>
डिफ़ॉल्ट: "android"-
android_binary नियमों के लिए इस्तेमाल करने के लिए, मेनिफ़ेस्ट मर्जर को चुनता है. फ़्लैग करें, ताकि लेगसी मर्जर की मदद से, Android मेनिफ़ेस्ट मर्जर पर ट्रांज़िशन किया जा सके.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_platforms=<a build target label>
डिफ़ॉल्ट: ""-
Android_binary टारगेट के इस्तेमाल करने वाले प्लैटफ़ॉर्म सेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें, हर खास टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी होती हैं.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_sdk=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk"-
यह, Android SDK/प्लैटफ़ॉर्म के बारे में बताता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--apple_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_ascendingr'.
टैग: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>
डिफ़ॉल्ट: ब्यौरा देखें-
कस्टम मैलक लागू करना तय करता है. यह सेटिंग, बिल्ड नियमों में मॉलोक एट्रिब्यूट को बदल देती है.
टैग:changes_inputs
,affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment>
बार कई बार इस्तेमाल किया गया-
कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन को - (नेगेटिव एक्सप्रेशन) प्रीफ़िक्स के साथ, कॉमा से अलग किए गए कंस्ट्रेंट वैल्यू टारगेट की सूची में असाइन करें. अगर कोई टारगेट, किसी नेगेटिव एक्सप्रेशन से मैच नहीं करता है और कम से कम एक पॉज़िटिव एक्सप्रेशन है, तो इसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा जैसे यह कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर दिखाता हो. उदाहरण: //डेमो,-टेस्ट=@प्लैटफ़ॉर्म
टैग:loading_and_analysis
--[no]experimental_enable_objc_cc_deps
डिफ़ॉल्ट: "सही"-
objc_* नियमों को cc_library पर निर्भर करने और किसी भी objc डिपेंडेंसी को --ios_<--ios_cpu> पर सेट करने की अनुमति देता है.
टैग:loading_and_analysis
,incompatible_change
--[no]experimental_include_xcode_execution_requirements
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया जाता है, तो हर Xcode कार्रवाई के लिए, "Requires-xcode:{version}" लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न इस्तेमाल करने वाला लेबल है, तो लागू करने के लिए, "Requires-xcode-label:{version_label}" के लिए ज़रूरी शर्त भी जोड़ें.
टैग:loses_incremental_state
,loading_and_analysis
,execution
--[no]experimental_prefer_mutual_xcode
डिफ़ॉल्ट: "सही"-
अगर सही है, तो हाल ही के Xcode का इस्तेमाल करें जो स्थानीय और दूर, दोनों जगह उपलब्ध है. अगर गलत है या उपलब्ध वर्शन उपलब्ध नहीं हैं, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode के वर्शन का इस्तेमाल करें.
टैग:loses_incremental_state
--extra_execution_platforms=<comma-separated list of options>
डिफ़ॉल्ट: ""-
वे प्लैटफ़ॉर्म जो एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं, ताकि कार्रवाइयां की जा सकें. प्लैटफ़ॉर्म सटीक टारगेट या टारगेट पैटर्न के तौर पर बताए जा सकते हैं. रजिस्टर हो जाने के बाद, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इसके लिए, spot_file वाली फ़ाइल पर बताया गया होगा... चिप.
टैग:execution
--extra_toolchains=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया-
टूलचेन का इस्तेमाल करते समय, इन दो बातों पर ध्यान देना चाहिए: टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर बताया जा सकता है. रजिस्टर किए गए टूलटूल (टूल_टूलचेन)() में बताई गई टूल चेन से पहले, इन टूलचेन का इस्तेमाल किया जाएगा.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
चेक इन की गई लाइब्रेरी की लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन से चुनी जाती है और आपको इसे कभी भी बदलने की ज़रूरत नहीं होती.
टैग:action_command_lines
,affects_outputs
--host_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
C++ कंपाइलर, जिसका इस्तेमाल होस्ट कंपाइलेशन के लिए किया जाता है. अगर --host_crossTool_top सेट नहीं है, तो इसे अनदेखा कर दिया जाता है.
टैग:loading_and_analysis
,execution
--host_crosstool_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
डिफ़ॉल्ट रूप से, --crosstool_top और --compiler विकल्प को भी exec कॉन्फ़िगरेशन के लिए इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया गया है, तो Bazel, दिए गए क्रॉसटूल_टॉप के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--host_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर इस सेटिंग के बारे में बताया गया हो, तो exec कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग:action_command_lines
,affects_outputs
--host_platform=<a build target label>
डिफ़ॉल्ट: "@local_config_platform//:host"-
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--[no]incompatible_disable_expand_if_all_available_in_flag_set
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel,expand_if_all_available को फ़्लैग_सेट में दिखाने की अनुमति नहीं देगा(माइग्रेशन के निर्देशों के लिए https://github.com/bazelbuild/bazel/issues/7008 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल c++ टूलटिप में 'host' और 'nonhost' सुविधाएं चालू नहीं करेगा (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_android_toolchain_resolution
डिफ़ॉल्ट: "गलत"-
Android नियमों (Starलार्क और नेटिव) के लिए Android SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution
डिफ़ॉल्ट: "गलत"-
Apple के नियमों (Starlark और नेटिव) के लिए Apple SDK चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, lto इंडेक्सिंग कमांड लाइन के लिए, C++ लिंक वाले ऐक्शन कमांड का दोबारा इस्तेमाल नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 पर जाएं).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_objc_linking_info_migration
डिफ़ॉल्ट: "सही"-
अगर सही है, तो ObjC में पहले से मौजूद नियमों को, ObjcProvider के बजाय, CCInfo से लिंक करने की जानकारी मिलेगी. जानकारी और माइग्रेशन की जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/16939 देखें
टैग:loading_and_analysis
,changes_inputs
,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
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल को cc_normal.configure_features (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7793 देखें) में 'ctx' पैरामीटर की ज़रूरत होगी.
टैग: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 SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल macOS ऐप्लिकेशन बनाने के लिए किया जाता है. अगर जानकारी न दी गई हो, तो '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>
डिफ़ॉल्ट: ब्यौरा देखें-
ऐसा py_runtime का लेबल जो Python की अनुवादक को दिखाता है. इसने टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया. बहिष्कृत; --insupported_use_python_toolchains से बंद किया गया.
टैग:loading_and_analysis
,affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टीवी ऐप्लिकेशन बनाने के लिए tvOS SDK का वर्शन बताता है. अगर इसके बारे में जानकारी न दी गई हो, तो 'xcode_version' के डिफ़ॉल्ट tvOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह, WatchOS SDK के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जाता है. अगर नीति तय नहीं की गई है, तो 'xcode_version' के डिफ़ॉल्ट WatchOS SDK वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xcode_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताया गया हो, तो बिल्ड से जुड़ी काम की कार्रवाइयों के लिए Xcode का इस्तेमाल किया जाता है. अगर बताया नहीं गया हो, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--xcode_version_config=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"-
बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए, xcode_config नियम का लेबल.
टैग:loses_incremental_state
,loading_and_analysis
- ऐसे निर्देश जो कमांड के आउटपुट को कंट्रोल करते हैं:
--[no]apple_enable_auto_dsym_dbg
डिफ़ॉल्ट: "गलत"-
dbg बिल्ड के लिए डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करने की सुविधा चालू करनी है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]apple_generate_dsym
डिफ़ॉल्ट: "गलत"-
डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करना है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]build_runfile_links
डिफ़ॉल्ट: "सही"-
अगर सही हो, तो सभी टारगेट के लिए रन फ़ाइलों को सिमलिंक फ़ॉरेस्ट बनाएं. अगर गलत है, तो जब भी हो सके, सिर्फ़ मेनिफ़ेस्ट लिखें.
टैग:affects_outputs
--[no]build_runfile_manifests
डिफ़ॉल्ट: "सही"-
अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर गलत है, तो उन्हें छोड़ दें. गलत होने पर, स्थानीय जांच नहीं हो पाएगी.
टैग:affects_outputs
--[no]build_test_dwp
डिफ़ॉल्ट: "गलत"-
अगर इसे चालू किया गया हो, तो C++ की जांच को स्टैटिक तौर पर और फ़िस के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल अपने-आप बन जाएगी.
टैग:loading_and_analysis
,affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options>
, डिफ़ॉल्ट: ".pb.h"-
उन हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है जिन्हें cc_proto_library बनाता है.
टैग:affects_outputs
,loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options>
डिफ़ॉल्ट: ".pb.cc"-
उन सोर्स फ़ाइलों के प्रीफ़िक्स सेट करता है जिन्हें cc_proto_library बनाता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info
डिफ़ॉल्ट: "गलत"-
proto_library में Java की एपीआई के दूसरे वर्शन के लिए, अतिरिक्त कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_proto_extra_actions
डिफ़ॉल्ट: "गलत"-
proto_library में Java की एपीआई के दूसरे वर्शन के लिए, अतिरिक्त कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_save_feature_state
डिफ़ॉल्ट: "गलत"-
वीडियो को चालू करने के मोड और चालू किए गए अनुरोधों को कंपाइल करने के लिए, सेव की गई स्थिति को सेव करें.
टैग:affects_outputs
,experimental
--fission=<a set of compilation modes>
डिफ़ॉल्ट: "नहीं"-
यह तय करता है कि कंपाइलेशन के कौनसे मोड C++ के कंपाइलेशन और लिंक के लिए फ़िशन का इस्तेमाल करते हैं. सभी मोड को चालू करने के लिए {'fastbuild', 'dbg', 'opt'} या खास वैल्यू 'yes' का कॉम्बिनेशन हो सकता है. इससे, सभी मोड को बंद किया जा सकता है.
टैग:loading_and_analysis
,action_command_lines
,affects_outputs
--[no]incompatible_always_include_files_in_data
डिफ़ॉल्ट: "सही"-
अगर सही है, तो नेटिव नियम अपनी रनफ़ाइल में डेटा डिपेंडेंसी के लिए <code>DefaultInfo.files</code> जोड़ते हैं. यह, Starlark नियमों (https://bazel.build/extending/rule#runfiles_features_to_aallow) के लिए सुझाए गए तरीकों से मेल खाता है.
टैग:affects_outputs
,incompatible_change
--[no]legacy_external_runfiles
डिफ़ॉल्ट: "सही"-
अगर सही है, तो .runfiles/wsname/external/repo में .runfiles/repo के साथ-साथ बाहरी डेटा स्टोर करने की जगहों के लिए रनफ़ाइल सिमलिंक जंगल बनाएं.
टैग:affects_outputs
--[no]objc_generate_linkmap
डिफ़ॉल्ट: "गलत"-
यह तय करता है कि लिंक मैप फ़ाइल जनरेट करनी है या नहीं.
टैग:affects_outputs
--[no]save_temps
डिफ़ॉल्ट: "गलत"-
अगर यह सेट है, तो gcc के अस्थायी आउटपुट सेव हो जाएंगे. इनमें .s फ़ाइलें (असेंबल करने का कोड), .i फ़ाइलें (पहले से प्रोसेस की गईं C) और .ii फ़ाइलें (पहले से प्रोसेस किए गए C++) शामिल हैं.
टैग:affects_outputs
- ऐसे विकल्प जो उपयोगकर्ता को उसके आउटपुट के बजाय, सही आउटपुट को कॉन्फ़िगर करने देते हैं:
--action_env=<a 'name=value' assignment with an optional value part>
बार कई बार इस्तेमाल किया गया-
पर्यावरण वैरिएबल के उस सेट के बारे में बताता है जो टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध है. वैरिएबल या तो नाम से तय किए जा सकते हैं, जहां मामले को शुरू करने के एनवायरमेंट से लिया जाएगा या नाम=वैल्यू पेयर से, वैल्यू को शुरू करने के एनवायरमेंट से अलग सेट किया जाएगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, लेकिन एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, नए वैरिएबल के लिए इकट्ठा किए गए विकल्प इकट्ठा होते हैं.
टैग:action_command_lines
--android_cpu=<a string>
डिफ़ॉल्ट: "armeabi-v7a"-
Android पर सीपीयू.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]android_databinding_use_androidx
डिफ़ॉल्ट: "गलत"-
AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]android_databinding_use_v3_4_args
डिफ़ॉल्ट: "गलत"-
3.4.0 तर्क वाले android databinding v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--android_dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "बंद" है-
यह तय करता है कि जब किसी cc_binary ने साफ़ तौर पर 'शेयर की गई लाइब्रेरी' नहीं बनाई हो, तो Android के नियमों के C++ वर्शन को डाइनैमिक तौर पर लिंक किया जाए या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बैज़ल डाइनैमिक तौर पर लिंक करने का विकल्प चुनेगा. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक रूप से लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:affects_outputs
,loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>
डिफ़ॉल्ट: "वर्णमाला"-
Android बाइनरी के लिए मेनिफ़ेस्ट मर्जर को भेजे गए मेनिफ़ेस्ट के क्रम को सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्ज़ीक्यूट के हिसाब से पाथ के हिसाब से क्रम में लगाया गया है. ALPHABETIAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट, आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री से जुड़े पाथ के हिसाब से क्रम में लगाए जाते हैं. डिपेंडेंसी का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट का क्रम, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग:action_command_lines
,execution
--[no]android_resource_shrinking
डिफ़ॉल्ट: "गलत"-
ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए संसाधनों को छोटा करने की सुविधा चालू करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]build_python_zip
डिफ़ॉल्ट: "अपने-आप"-
Python का एक्ज़ीक्यूटिव ज़िप बनाएं; Windows पर, दूसरे प्लैटफ़ॉर्म पर बंद
टैग:affects_outputs
--catalyst_cpus=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया-
उन आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है, जिनके लिए Apple Catalyst बाइनरी बनाना है.
टैग:loses_incremental_state
,loading_and_analysis
--[no]collect_code_coverage
डिफ़ॉल्ट: "गलत"-
अगर तय किया गया है, तो बेज़ल इंस्ट्रूमेंटेशन कोड का इस्तेमाल करेगा (जहां संभव हो, ऑफ़लाइन इंस्ट्रुमेंट का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ वे टारगेट पर असर होगा जो -- इंस्ट्रूमेंटेशन_फ़िल्टर से मेल खाते हैं. आम तौर पर, यह विकल्प सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'बेज़ल कवरेज' निर्देश का इस्तेमाल किया जाना चाहिए.
टैग: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>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, CSFDO की प्रोफ़ाइल जानकारी का इस्तेमाल करें. उस 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>
बार कई बार इस्तेमाल किया गया-
हर --परिभाषित विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है.
टैग:changes_inputs
,affects_outputs
--dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
यह तय करता है कि C++ बाइनरी लिंक करने के लिए, डाइनैमिक तौर पर लिंक करना है या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बेज़ल यह चुनेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक रूप से लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग: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>
बार कई बार इस्तेमाल किया गया-
शर्तों के पक्ष में बहिष्कृत. बिल्ड की मौजूदा कार्रवाइयों के साथ अलग से कोई ऐक्शन जोड़ने के लिए, action_listener का इस्तेमाल करें.
टैग:execution
,experimental
--[no]experimental_android_compress_java_resources
डिफ़ॉल्ट: "गलत"-
APK के Java संसाधनों को कंप्रेस करें
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_android_databinding_v2
डिफ़ॉल्ट: "गलत"-
Android डेटा बाइंडिंग v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_android_resource_shrinking
डिफ़ॉल्ट: "गलत"-
ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए संसाधनों को छोटा करने की सुविधा चालू करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex
डिफ़ॉल्ट: "गलत"-
डेक्स फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करें
टैग: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
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो स्टैक अनविंड करने के लिए libunwin का इस्तेमाल करें और -fomit-frame-pointer और -fasynchronus-unwind-tables के साथ कंपाइल करें.
टैग:action_command_lines
,affects_outputs
,experimental
--[no]experimental_platform_in_output_dir
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो टारगेट प्लैटफ़ॉर्म का इस्तेमाल सीपीयू के बजाय, आउटपुट डायरेक्ट्री में किया जाता है.
टैग:affects_outputs
,experimental
--[no]experimental_use_llvm_covmap
डिफ़ॉल्ट: "गलत"-
अगर जानकारी दी गई हो, तो Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा. ऐसा कलेक्ट_कोड_कवरेज के चालू होने पर होगा.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
,experimental
--fat_apk_cpu=<comma-separated set 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
डिफ़ॉल्ट: "गलत"-
HWASAN स्प्लिट बनाने हैं या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी कोड जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह डायरेक्ट्री का वह नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान डंप किया जाता है.
टैग:affects_outputs
--fdo_optimize=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, एफ़डीओ की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री है. इसके अलावा, ऐसी afdo फ़ाइल भी होती है जिसमें ऑटो प्रोफ़ाइल या LLVM प्रोफ़ाइल फ़ाइल होती है. यह फ़्लैग, लेबल के तौर पर बताई गई फ़ाइलें भी स्वीकार करता है (उदाहरण के लिए, `//foo/bar:file.afdo` - आपको इससे जुड़े पैकेज के लिए, `exports_files` डायरेक्टिव जोड़ना पड़ सकता है) और लेबल के लिए, fdo_profile` टारगेट करना होगा. इस फ़्लैग की जगह `fdo_profile` नियम लागू होगा.
टैग:affects_outputs
--fdo_prefetch_hints=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कैश मेमोरी में सेव किए गए सुझावों का इस्तेमाल करें.
टैग:affects_outputs
--fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली fdo_profile प्रोफ़ाइल.
टैग:affects_outputs
--features=<a string>
बार कई बार इस्तेमाल किया गया-
टारगेट कॉन्फ़िगरेशन के दौरान बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> तय करने पर, यह सुविधा बंद हो जाएगी. नेगेटिव सुविधाएं हमेशा अच्छी सुविधाओं को बदल देती हैं. ये भी देखें --host_features
टैग:changes_inputs
,affects_outputs
--[no]force_pic
डिफ़ॉल्ट: "गलत"-
इसके चालू होने पर, सभी C++ कंपाइलेशन से स्थान-स्वतंत्र कोड ("-fPIC") मिलता है, लिंक गैर-PIC लाइब्रेरी के बजाय PIC पहले से बनी लाइब्रेरी को प्राथमिकता देते हैं और लिंक, स्थान-स्वतंत्र एक्ज़ीक्यूटेबल ("-pie") तैयार करते हैं.
टैग:loading_and_analysis
,affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल या तो नाम से तय किए जा सकते हैं, जहां मामले को शुरू करने के एनवायरमेंट से लिया जाएगा या नाम=वैल्यू पेयर से, वैल्यू को शुरू करने के एनवायरमेंट से अलग सेट किया जाएगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, लेकिन एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, नए वैरिएबल के लिए इकट्ठा किए गए विकल्प इकट्ठा होते हैं.
टैग:action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt>
डिफ़ॉल्ट: "ऑप्ट"-
उस मोड के बारे में बताएं जिसका इस्तेमाल करके, बिल्ड के दौरान टूल बनाए गए थे. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग:affects_outputs
,action_command_lines
--host_conlyopt=<a string>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूट करने के कॉन्फ़िगरेशन में C (C++) सोर्स फ़ाइलें कंपाइल करते समय C कंपाइलर को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_copt=<a string>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूट कॉन्फ़िगरेशन में बनाए गए टूल के लिए C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_cpu=<a string>
डिफ़ॉल्ट: ""-
होस्ट सीपीयू.
टैग:changes_inputs
,affects_outputs
--host_cxxopt=<a string>
बार कई बार इस्तेमाल किया गया-
exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर में पास करने के लिए अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_features=<a string>
बार कई बार इस्तेमाल किया गया-
exe कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> तय करने पर, यह सुविधा बंद हो जाएगी. नेगेटिव सुविधाएं हमेशा अच्छी सुविधाओं को बदल देती हैं.
टैग:changes_inputs
,affects_outputs
--host_force_python=<PY2 or PY3>
डिफ़ॉल्ट: ब्यौरा देखें-
exec कॉन्फ़िगरेशन के लिए, Python वर्शन को बदल देता है. यह "PY2" या "PY3" हो सकता है.
टैग:loading_and_analysis
,affects_outputs
--host_linkopt=<a string>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूट कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंक करने वाले को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट टारगेट के लिए, कम से कम macOS वर्शन काम करता है. अगर जानकारी न दी गई हो, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूशन कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तरीके से पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter का मतलब है, रेगुलर एक्सप्रेशन के पैटर्न को शामिल करना और बाहर रखना. (यह भी देखें -- इंस्ट्रूमेंटेशन_फ़िल्टर). विकल्प_1 का मतलब है आर्बिट्रेरी कमांड लाइन विकल्प. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना ज़रूरी है. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, Bar.cc को छोड़कर //foo/ में सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
--host_swiftcopt=<a string>
बार कई बार इस्तेमाल किया गया-
exec टूल के लिए swiftc में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--[no]incompatible_auto_exec_groups
डिफ़ॉल्ट: "गलत"-
चालू होने पर, किसी नियम में इस्तेमाल किए जाने वाले हर टूलचेन के लिए, एक एक्ज़ीक्यूटिव ग्रुप अपने-आप बन जाता है. इसके लिए, काम करने के नियम के हिसाब से, इसकी कार्रवाइयों पर `टूलचेन` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_avoid_conflict_dlls
डिफ़ॉल्ट: "सही"-
अगर यह सुविधा चालू है, तो Windows पर cc_library की ओर से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (DLL) का नाम बदलकर name_{has}.dll कर दिया जाएगा. इसमें, RepositoryName और DLL के पैकेज पाथ के आधार पर हैश का हिसाब लगाया जाता है. यह विकल्प तब काम आता है, जब आपके पास एक पैकेज होता है जो एक ही नाम वाले कई cc_library पर निर्भर करता है (उदाहरण के लिए, //foo/bar1:utils और //foo/bar2:utils).
टैग:loading_and_analysis
,affects_outputs
,incompatible_change
--[no]incompatible_merge_genfiles_directory
डिफ़ॉल्ट: "सही"-
अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में बदल दिया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_use_host_features
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो टारगेट कॉन्फ़िगरेशन के लिए --features का इस्तेमाल करें और exec कॉन्फ़िगरेशन के लिए --host_features] का इस्तेमाल करें.
टैग:changes_inputs
,affects_outputs
,incompatible_change
--[no]instrument_test_targets
डिफ़ॉल्ट: "गलत"-
कवरेज की सुविधा चालू होने पर, यह तय किया जाता है कि टेस्टिंग के नियमों का पालन करना है या नहीं. सेट होने पर, -- इंस्ट्रूमेंटेशन_फ़िल्टर के शामिल किए गए टेस्ट नियम लागू किए जाते हैं. नहीं तो, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रुमेंटेशन से बाहर रखा जाता है.
टैग:affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-/javatests[/:],-/test/java[/:]"-
कवरेज चालू होने पर, सिर्फ़ रेगुलर एक्सप्रेशन पर आधारित फ़िल्टर की मदद से शामिल किए गए नामों वाले नियम ही लागू किए जाएंगे. इसके बजाय '-' से शुरू होने वाले नियम शामिल नहीं किए जाते हैं. ध्यान रखें कि सिर्फ़ बिना टेस्ट वाले नियम तब तक लागू होते हैं, जब तक कि -- मनपसंद_टेस्ट_टारगेट चालू न हो.
टैग: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 और या तो linkstatic=True या '-static' linkopts में हो. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. जहां ज़रूरी हो वहां हमेशा linklink=1 का इस्तेमाल करना एक बेहतर विकल्प है.
टैग:action_command_lines
,affects_outputs
,deprecated
--linkopt=<a string>
बार कई बार इस्तेमाल किया गया-
लिंक करते समय gcc में पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--ltobackendopt=<a string>
बार कई बार इस्तेमाल किया गया-
एलटीओ बैकएंड चरण में जाने के लिए अतिरिक्त विकल्प (-feature=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
डिफ़ॉल्ट: "गलत"-
अगर इस मोड को सेट किया जाता है और 'dbg' पर सेट किया जाता है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC और GLIBसीपी_CONCEPT_CheckS के बारे में बताएं.
टैग:action_command_lines
--[no]objc_enable_binary_stripping
डिफ़ॉल्ट: "गलत"-
लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी हैं या नहीं. अगर इस फ़्लैग और --compilation_mode=opt दोनों के बारे में बताया गया हो, तो बाइनरी स्ट्रिपिंग किए जाएंगे.
टैग:action_command_lines
--objccopt=<a string>
बार कई बार इस्तेमाल किया गया-
Objective-C/C++ सोर्स फ़ाइलें कंपाइल करते समय gcc में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई बार इस्तेमाल किया गया-
कुछ फ़ाइलों को कंपाइल करते समय, विकल्प के तौर पर 'गुप्त कॉपी' पास करने के लिए कुछ और विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter का मतलब है, रेगुलर एक्सप्रेशन के पैटर्न को शामिल करना और बाहर रखना. (यह भी देखें -- इंस्ट्रूमेंटेशन_फ़िल्टर). विकल्प_1 का मतलब है आर्बिट्रेरी कमांड लाइन विकल्प. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना ज़रूरी है. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में .cc/
टैग: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>
बार कई बार इस्तेमाल किया गया-
कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड को (चुनिंदा सुविधाओं में=thin_lto) भेजने के लिए, चुनिंदा विकल्प चुने जाते हैं. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, सूची की सूची और रेगुलर एक्सप्रेशन के पैटर्न को शामिल नहीं करता है. Option_1 का मतलब है आर्बिट्रेरी कमांड लाइन विकल्प. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना ज़रूरी है. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, ofoo में सभी o फ़ाइलों के LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.वे बिड को //foo/ में नहीं छोड़ सकते.
टैग:action_command_lines
,affects_outputs
--platform_suffix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स बताता है.
टैग:loses_incremental_state
,affects_outputs
,loading_and_analysis
--propeller_optimize=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propels प्रोफ़ाइल की जानकारी का इस्तेमाल करें.प्रोपेलर प्रोफ़ाइल में, कम से कम दो फ़ाइलों में से एक की कॉपी और एक प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल को स्वीकार करता है. इसे प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों के बारे में बताना चाहिए. उदाहरण के लिए, लेबल की पहचान करने वाली BUILD फ़ाइल, a/b/BUILD:propel_optimize( name = "propel_profile", cc_profile = "propel_cc_profile.txt", ld_profile = "propel_ld_profile.txt",) में, index_files डायरेक्टिव को इन फ़ाइलों में लिखा जाना चाहिए, ताकि ये फ़ाइलें बेज़ल को दिखें. इस विकल्प का इस्तेमाल, इन चीज़ों के लिए किया जाना चाहिए: --propel_optimize=//a/b:propel_profile
टैग:action_command_lines
,affects_outputs
--propeller_optimize_absolute_cc_profile=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
प्रोपेलर ऑप्टिमाइज़ वाले बिल्ड के लिए, cc_profile फ़ाइल का पूरा पाथ नाम.
टैग:affects_outputs
--propeller_optimize_absolute_ld_profile=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
प्रोपेलर ऑप्टिमाइज़ वाले बिल्ड के लिए ld_profile फ़ाइल का पूरा पाथ नाम.
टैग:affects_outputs
--run_under=<a prefix in front of command>
डिफ़ॉल्ट: ब्यौरा देखें- 'टेस्ट' और 'रन' कमांड के लिए, एक्ज़ीक्यूट करने से पहले शुरू करने के लिए उपसर्ग लगाएं. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो आखिरी कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. कुछ उदाहरण: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग:action_command_lines
-
अगर सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी अलग-अलग टारगेट में शेयर की जाएंगी
टैग:loading_and_analysis
,affects_outputs
--[no]stamp
डिफ़ॉल्ट: "गलत"-
बाइनरी के साथ तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह स्टैंप करें
टैग:affects_outputs
--strip=<always, sometimes or never>
डिफ़ॉल्ट: "कभी-कभी"-
यह बताता है कि बाइनरी और शेयर की गई लाइब्रेरी को "-Wl---strip-debug" का इस्तेमाल करके हटाना है या नहीं). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब होता है, स्लिप if-compilation_mode=fastbuild.
टैग:affects_outputs
--stripopt=<a string>
बार कई बार इस्तेमाल किया गया- '<name>.striped' बाइनरी जनरेट करते समय स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.
टैग: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_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_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--xbinary_fdo=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO की प्रोफ़ाइल जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम डालें. अगर इस विकल्प का इस्तेमाल --fdo_स्टीमेशन/--fdo_optimize/--fdo_profile, साथ किया जाता है, तो ये विकल्प हमेशा लागू होंगे, जैसे कि xbinary_fdo को कभी तय नहीं किया गया है.
टैग:affects_outputs
- वे विकल्प जो इस बात पर असर डालते हैं कि Bazel, बिल्ड के मान्य इनपुट को किस तरह लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--auto_cpu_environment_group=<a build target label>
डिफ़ॉल्ट: ""-
सीपीयू वैल्यू को target_Environment वैल्यू के साथ अपने-आप मैप करने के लिए,Environment_group का एलान करें.
टैग:changes_inputs
,loading_and_analysis
,experimental
--[no]check_licenses
डिफ़ॉल्ट: "गलत"-
जांच लें कि डिपेंडेंट पैकेज के ज़रिए लागू की गई लाइसेंस देने की सीमाएं, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर नहीं डालती हैं. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग:build_file_semantics
--[no]check_visibility
डिफ़ॉल्ट: "सही"-
अगर यह नीति बंद है, तो डिपेंडेंसी के लिए टारगेट डिपेंडेंसी में गड़बड़ियों को कम किया जाता है.
टैग:build_file_semantics
--[no]desugar_for_android
डिफ़ॉल्ट: "सही"-
चाहे वे डेक्सिंग करने से पहले देसूर Java 8 बाइटकोड लें या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]desugar_java8_libs
डिफ़ॉल्ट: "गलत"-
पुराने डिवाइसों के लिए, ऐप्लिकेशन में काम करने वाली Java 8 लाइब्रेरी शामिल करनी हैं या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]enforce_constraints
डिफ़ॉल्ट: "सही"-
हर टारगेट के साथ काम करने वाले एनवायरमेंट की जांच करता है. साथ ही, अगर किसी टारगेट में ऐसी डिपेंडेंसी है जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो वह गड़बड़ियां बताता है
टैग:build_file_semantics
--[no]experimental_allow_android_library_deps_without_srcs
डिफ़ॉल्ट: "गलत"-
डेस्क से, बिना src वाले 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
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो आउटपुट फ़ाइलों के लिए ज़रूरी जांच वाले फ़ॉर्मैट की जांच करें. इसके लिए, जांच करने के नियम का सिर्फ़ टेस्ट देखें. यह विज़िबिलिटी चेकिंग से मेल खाता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_check_visibility_for_toolchains
डिफ़ॉल्ट: "गलत"-
चालू होने पर, विज़िबिलिटी चेकिंग टूल लागू करने की प्रोसेस पर भी लागू होती है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disable_native_android_rules
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो नेटिव Android के नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rule_android से Starlark Android नियमों का उपयोग करें
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_disable_native_apple_binary_rule
डिफ़ॉल्ट: "गलत"-
नहीं. पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया था.
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_force_strict_header_check_from_starlark
डिफ़ॉल्ट: "सही"-
अगर यह सुविधा चालू है, तो Starlark API में हेडर हेडर की सख्त जांच सेट करें
टैग:loading_and_analysis
,changes_inputs
,incompatible_change
--[no]incompatible_python_disable_py2
डिफ़ॉल्ट: "सही"-
सही होने पर, Python 2 की सेटिंग का इस्तेमाल करने से गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2सिर्फ़ शामिल हैं. ज़्यादा जानकारी पाने के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_validate_top_level_header_inclusions
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, टॉप लेवल डायरेक्ट्री हेडर को शामिल करने की पुष्टि भी करेगा (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/10047 देखें).
टैग:loading_and_analysis
,incompatible_change
--python_native_rules_allowlist=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
अनुमति वाली सूची (पैकेज_ग्रुप टारगेट) लागू करते समय इस्तेमाल करना.
टैग:loading_and_analysis
--[no]strict_filesets
डिफ़ॉल्ट: "गलत"-
अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलें, गड़बड़ी के तौर पर रिपोर्ट किए जाते हैं. अगर यह चेक_fileset_dependencies_recursive को बंद किया गया है, तो यह काम नहीं करेगा.
टैग:build_file_semantics
,eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default>
डिफ़ॉल्ट: "गड़बड़ी"-
जब तक यह बंद न हो, तब तक यह जांच करता है कि प्रोटो_लाइब्रेरी का टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर दिखाता है.
टैग:build_file_semantics
,eagerness_to_exit
,incompatible_change
--strict_public_imports=<off, warn, error, strict or default>
डिफ़ॉल्ट: "बंद" है-
जब तक यह बंद न हो, तब तक यह जांच की जाती है कि प्रोटो_लाइब्रेरी का टारगेट, 'सार्वजनिक तौर पर इंपोर्ट करें' में एक्सपोर्ट किए गए सभी टारगेट को साफ़ तौर पर बताता है या नहीं.
टैग:build_file_semantics
,eagerness_to_exit
,incompatible_change
--[no]strict_system_includes
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो सिस्टम से मिले हेडर में पाथ (-isystem) शामिल करने की ज़रूरत पड़ती है.
टैग:loading_and_analysis
,eagerness_to_exit
--target_environment=<a build target label>
बार कई बार इस्तेमाल किया गया-
इस बिल्ड के लिए टारगेट एनवायरमेंट की जानकारी देता है. "परिवेश" नियम के हिसाब से कोई लेबल होना चाहिए. अगर बताया गया हो, तो सभी टॉप-लेवल टारगेट का इस एनवायरमेंट के साथ काम करना ज़रूरी है.
टैग:changes_inputs
- ऐसे विकल्प जो किसी बिल्ड के साइनिंग आउटपुट पर असर डालते हैं:
--apk_signing_method=<v1, v2, v1_v2 or v4>
डिफ़ॉल्ट: "v1_v2"-
APK को साइन करने के लिए इस्तेमाल करना
टैग:action_command_lines
,affects_outputs
,loading_and_analysis
--[no]device_debug_entitlements
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है और कंपाइल करने वाला मोड 'ऑप्ट-इन' नहीं किया जाता है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल हो जाएंगे.
टैग:changes_inputs
--ios_signing_cert_name=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
iOS साइनिंग के लिए इस्तेमाल किया जाने वाला सर्टिफ़िकेट नाम. इस नीति को सेट न करने पर, यह प्रावधान वाली प्रोफ़ाइल के तौर पर सेट हो जाएगा. कोडसाइन के मैन पेज (SIGNING IDENTITIES) के अनुसार, सर्टिफ़िकेट के आम तौर पर इस्तेमाल होने वाले नाम की सर्टिफ़िकेट की कुंजी या सबस्ट्रिंग हो सकती है.
टैग:action_command_lines
- यह विकल्प Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों से ऐक्सेस करने लायक बिल्ड एपीआई पर असर डालता है.:
--[no]incompatible_disallow_legacy_py_provider
डिफ़ॉल्ट: "सही"-
नहीं, नहीं. इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_disallow_sdk_frameworks_attributes
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो objc_library औरobjc_export में sdk_frameworks और Weak_sdk_frameworks एट्रिब्यूट की अनुमति नहीं दें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_objc_alwayslink_by_default
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो objc_library और objc_Import पर हमेशा लिंक करने वाले एट्रिब्यूट के लिए, डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_python_disallow_native_rules
डिफ़ॉल्ट: "गलत"-
सही होने पर, पहले से मौजूद py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, Rules_python के नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग:loading_and_analysis
,incompatible_change
- ऐसे विकल्प जो टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करते हैं:
--[no]allow_analysis_failures
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो नियम के टारगेट की जांच में हुई गड़बड़ी की वजह से विश्लेषण में गड़बड़ी हुई.
टैग:loading_and_analysis
,experimental
--analysis_testing_deps_limit=<an integer>
डिफ़ॉल्ट: "2000"-
for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन करने वाली ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा को पार करने पर नियम में गड़बड़ी हो सकती है.
टैग:loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure
डिफ़ॉल्ट: "गलत"-
अगर सही Dex2oat कार्रवाई नहीं हो पाती है, तो टेस्ट रनटाइम के दौरान dex2oat चलाने के बजाय बिल्ड टूट सकता है.
टैग:loading_and_analysis
,experimental
--[no]experimental_android_use_parallel_dex2oat
डिफ़ॉल्ट: "गलत"-
android_test को तेज़ी से लोड करने के लिए, dex2oat का इस्तेमाल एक साथ करें.
टैग:loading_and_analysis
,host_machine_resource_optimizations
,experimental
--[no]ios_memleaks
डिफ़ॉल्ट: "गलत"-
ios_test टारगेट में मेमोरी लीक की जांच करें.
टैग:action_command_lines
--ios_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में मौजूद iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किया जाने वाला डिवाइस. उदाहरण के लिए, 'iPhone 6'. आप सिम्युलेटर पर उस डिवाइस पर 'xcrun simctl list devicetype' चलाकर डिवाइसों की सूची पा सकते हैं जिस पर सिम्युलेटर चलेगा.
टैग: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 का मतलब है रेगुलर एक्सप्रेशन पैटर्न को शामिल करना और बाहर रखना (यह भी देखें -- इंस्ट्रूमेंटेशन_फ़िल्टर). उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3 foo/bar के अलावा तीन बार //foo/में सभी टेस्ट चलाता है. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सबसे हाल ही में पास होने वाले आर्ग्युमेंट को प्राथमिकता मिलती है. अगर कुछ भी मेल नहीं खाता है, तो जांच सिर्फ़ एक बार की जाएगी.
--test_env=<a 'name=value' assignment with an optional value part>
बार कई बार इस्तेमाल किया गया-
यह, टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल, नाम से तय किए जा सकते हैं. ऐसा होने पर, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से या name=value जोड़े से पढ़ी जाएगी. इस विकल्प का इस्तेमाल कई वैरिएबल के बारे में बताने के लिए कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'बेज़ल टेस्ट' निर्देश से किया जाता है.
टैग:test_runner
- डिफ़ॉल्ट
--test_timeout=<a single integer or comma-separated list of 4 integers>
: "-1" - जांच के टाइम आउट होने की डिफ़ॉल्ट वैल्यू को बदलें (सेकंड में). अगर एक पॉज़िटिव पूर्णांक वैल्यू दी गई है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा से अलग किए गए चार पूर्णांक बताए गए हैं, तो वे छोटे, मध्यम, लंबे, और हमेशा के लिए (इसके क्रम में) टाइम आउट बदल देंगे. दोनों में से किसी भी फ़ॉर्म में, -1 का मान बदलने के लिए ब्लेज़ को डिफ़ॉल्ट श्रेणी बताने का विकल्प दिया जाता है.
--tvos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में, TOS ऐप्लिकेशन को चलाने के दौरान सिम्युलेट किया गया डिवाइस, जैसे कि 'Apple TV 1080p'. आप सिम्युलेटर पर उस डिवाइस पर 'xcrun simctl list devicetype' चलाकर डिवाइसों की सूची पा सकते हैं जिस पर सिम्युलेटर चलेगा.
टैग:test_runner
--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
चलने या टेस्ट करने के दौरान, सिम्युलेटर पर tvOS का वर्शन.
टैग:test_runner
--watchos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर डिवाइस, जिस पर सिम्युलेटर चलाते समय स्मार्टवॉच का ऐप्लिकेशन इस्तेमाल किया जा सकता है. उदाहरण के लिए, 'Apple Watch - 38 मि॰मी॰'. आप सिम्युलेटर पर उस डिवाइस पर 'xcrun simctl list devicetype' चलाकर डिवाइसों की सूची पा सकते हैं जिस पर सिम्युलेटर चलेगा.
टैग: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} में से किसी एक में हो, तो आसपेक्ट डिपेंडेंसी को कैसे हल करें. 'बंद' का मतलब है कि किसी भी पक्ष की डिपेंडेंसी का समाधान नहीं हुआ है. 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि बताए गए सभी आसपेक्ट डिपेंडेंसी जोड़े गए हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के लिए नियम की कैटगरी दी गई हो. इसका मतलब है कि सीधे तौर पर डिपेंडेंसी के नियम की कैटगरी के तहत, सिर्फ़ वे आसपेक्ट जोड़े गए हैं जो शायद चालू हैं. ध्यान दें कि सटीक मोड में, किसी एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इस वजह से, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि पूरी तरह सटीक मोड भी नहीं होता: फै़सले के आधार पर यह तय किया जाता है कि आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को कैलकुलेट करना है या नहीं. यह फ़ैसला 'बेज़ल क्वेरी' के दौरान नहीं चलता.
टैग:build_file_semantics
--[no]deduplicate_depsets
डिफ़ॉल्ट: "सही"-
आखिरी प्रोटो/textproto/json आउटपुट में, dep_set_of_फ़ाइलों के नॉन-लीफ़ वाले बच्चों के डुप्लीकेट डेटा हटाएं. यह उन गिरावटों को डीडुप्लीकेट नहीं करता है जो ताज़िक अभिभावक को शेयर नहीं करते हैं. हालांकि, इससे कार्रवाइयों की इनपुट आर्टफ़ैक्ट की आखिरी असरदार सूची पर कोई असर नहीं पड़ता.
टैग:terminal_output
--[no]experimental_parallel_aquery_output
डिफ़ॉल्ट: "गलत"- क्वेरी क्वेरी प्रोटो/टेक्स्टप्रोटो को साथ-साथ लिखा जाना चाहिए. अन्य आउटपुट फ़ॉर्मैट के लिए नहीं.
--[no]graph:factored
डिफ़ॉल्ट: "सही"-
अगर सही है, तो ग्राफ़ को 'फ़ैक्टर' किया जाता है.जैसे, भौगोलिक स्थिति के बराबर नोड को एक साथ मर्ज कर दिया जाता है. साथ ही, उनके लेबल आपस में जुड़ जाते हैं. यह विकल्प सिर्फ़ -- आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--graph:node_limit=<an integer>
डिफ़ॉल्ट: "512"-
आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल छोटे कर दिए जाएंगे -1 का मतलब है काट-छांट नहीं. यह विकल्प सिर्फ़ -- आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--[no]implicit_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, इंडिपेंडेंट डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी जिस पर क्वेरी ऑपरेट की जाती है. इंप्लिसिट डिपेंडेंसी, BUILD फ़ाइल में साफ़ तौर पर नहीं बताई जाती. हालांकि, इसे bazel में जोड़ा जाता है. क्वेरी के लिए, यह विकल्प फ़िल्टर किए गए टूलचेन को फ़िल्टर करने पर कंट्रोल करता है.
टैग: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
डिफ़ॉल्ट: "गलत"-
FileWrite और SourceSymlinkManifest कार्रवाइयों (शायद ज़्यादा बड़ी) के लिए फ़ाइल का कॉन्टेंट शामिल करें.
टैग:terminal_output
--[no]include_param_files
डिफ़ॉल्ट: "गलत"-
कमांड में शामिल पैरामीटर फ़ाइलों का कॉन्टेंट शामिल करें (हो सकता है कि बड़ा हो). ध्यान दें: इस फ़्लैग को चालू करने से --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
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट करके और 'यूनिवर्स_स्कोप' को सेट नहीं किया जाता है, तो क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर, 'यूनिवर्स_स्कोप' की वैल्यू का पता लगाया जाएगा. ध्यान दें कि यूनिवर्स के दायरे वाले फ़ंक्शन (उदाहरण के लिए, `allrdeps`) का इस्तेमाल करने वाली क्वेरी एक्सप्रेशन के लिए तय --यूनीवर्स_स्कोप की वैल्यू आपकी पसंद के मुताबिक नहीं हो सकती है. इसलिए, आपको इस विकल्प का इस्तेमाल सिर्फ़ तब करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query देखें. अगर --universa_scope सेट हो, तो इस विकल्प की वैल्यू को नज़रअंदाज़ कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ `क्वेरी` पर लागू होता है (उदाहरण के लिए, `cquery` नहीं).
टैग:loading_and_analysis
--[no]line_terminator_null
डिफ़ॉल्ट: "गलत"-
क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया जाता है.
टैग:terminal_output
--[no]nodep_deps
डिफ़ॉल्ट: "सही"-
अगर यह चालू है, तो "nodep" एट्रिब्यूट के डिपेंडेंसी, उस डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी जिस पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "किसको दिखे" है. बिल्ड भाषा में सभी "नोडप" विशेषताओं के बारे में जानने के लिए `info build-language` के आउटपुट को चलाएं और पार्स करें.
टैग:build_file_semantics
--output=<a string>
डिफ़ॉल्ट: "टेक्स्ट"-
वह फ़ॉर्मैट जिसमें क्वेरी के नतीजे प्रिंट किए जाने चाहिए. क्वेरी के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: text, textproto, proto, Stream_proto, jsonproto.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो BUILD फ़ाइल में साफ़ तौर पर तय नहीं किए गए एट्रिब्यूट शामिल होते हैं. ऐसा न होने पर, उन्हें छोड़ दिया जाता है. यह विकल्प --आउटपुट=प्रोटो
टैग पर लागू होता है:terminal_output
--[no]proto:definition_stack
डिफ़ॉल्ट: "गलत"-
डेफ़िनिशन_स्टैक प्रोटो फ़ील्ड को पॉप्युलेट करें. यह हर नियम के इंस्टेंस के लिए रिकॉर्ड करता है, जहां नियम की क्लास तय होने के दौरान Starlark कॉल स्टैक होता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, Select() से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट फ़्लैट हो जाते हैं. सूची के टाइप को फ़्लैट करने के विकल्प को चुनने पर, चुने गए मैप की हर वैल्यू को सिर्फ़ एक बार शामिल किया जाता है. स्केलर के प्रकार शून्य हो जाते हैं.
टैग:build_file_semantics
--[no]proto:include_attribute_source_aspects
डिफ़ॉल्ट: "गलत"-
हर एट्रिब्यूट के सोर्स_aspect_name प्रोटो फ़ील्ड में, सोर्स का आसपेक्ट रेशियो डालें. अगर एट्रिब्यूट मौजूद नहीं है, तो खाली स्ट्रिंग डालें.
टैग:terminal_output
--[no]proto:include_synthetic_attribute_hash
डिफ़ॉल्ट: "गलत"- $internal_attr_ash एट्रिब्यूट को कैलकुलेट करना और पॉप्युलेट करना है या नहीं.
टैग:terminal_output
--[no]proto:instantiation_stack
डिफ़ॉल्ट: "गलत"-
हर एक नियम के इंस्टैंशिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए स्टैक का मौजूद होना ज़रूरी है
टैग:terminal_output
--[no]proto:locations
डिफ़ॉल्ट: "सही"-
प्रोटो आउटपुट में जगह की जानकारी का इस्तेमाल करें या नहीं.
टैग:terminal_output
--proto:output_rule_attrs=<comma-separated list of options>
डिफ़ॉल्ट: "सभी"-
आउटपुट में शामिल करने के लिए, एट्रिब्यूट की कॉमा-सेपरेटेड लिस्ट. डिफ़ॉल्ट तौर पर यह सभी एट्रिब्यूट पर लागू होता है. किसी भी एट्रिब्यूट को आउटपुट न करने के लिए, खाली स्ट्रिंग पर सेट करें. यह विकल्प -- आउटपुट=प्रोटो पर लागू होता है.
टैग:terminal_output
--[no]proto:rule_inputs_and_outputs
डिफ़ॉल्ट: "सही"-
नियम_इनपुट और नियम_आउटपुट फ़ील्ड को भरना है या नहीं.
टैग:terminal_output
--query_file=<a string>
डिफ़ॉल्ट: ""-
अगर इस नीति को सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां बताई गई फ़ाइल से क्वेरी को पढ़ेगी. यहां किसी फ़ाइल के साथ-साथ कमांड-लाइन क्वेरी डालने में कोई गड़बड़ी हुई.
टैग:changes_inputs
--[no]relative_locations
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह का आउटपुट एक सटीक रास्ता होता है और यह मशीनों पर एक जैसा नहीं होगा. सभी मशीनों में एक जैसा नतीजा पाने के लिए, इस विकल्प को 'सही' पर सेट किया जा सकता है.
टैग:terminal_output
--[no]skyframe_state
डिफ़ॉल्ट: "गलत"-
अतिरिक्त विश्लेषण किए बिना, Skyframe से मौजूदा कार्रवाई ग्राफ़ को खारिज करें. ध्यान दें: फ़िलहाल, --skyframe_state के साथ टारगेट तय नहीं किया जा सकता. यह फ़्लैग सिर्फ़ -- आउटपुट=प्रोटो या -- आउटपुट=टेक्स्टप्रोटो के साथ उपलब्ध है.
टैग:terminal_output
--[no]tool_deps
डिफ़ॉल्ट: "सही"-
क्वेरी: अगर यह नीति बंद हो, तो 'एक्ज़ीक्यूट करने से जुड़े कॉन्फ़िगरेशन' पर निर्भरता को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाएगा जिस पर क्वेरी काम करती है. 'एक्ज़ीक्यूट कॉन्फ़िगरेशन' डिपेंडेंसी एज, जैसे कि किसी 'proto_library' नियम से प्रोटोकॉल कंपाइलर तक, आम तौर पर एक ही 'टारगेट' प्रोग्राम के हिस्से के बजाय, बिल्ड के दौरान चलाए गए टूल पर ले जाता है.
क्वेरी: अगर यह बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर देता है जो लागू किए गए इस टारगेट को खोजने वाले टॉप-लेवल टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन करते हैं. इसका मतलब है कि अगर टॉप-लेवल टारगेट टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट भी वापस मिलेंगे. अगर टॉप-लेवल टारगेट एक्ज़ीक्यूट कॉन्फ़िगरेशन में है, तो सिर्फ़ एक्ज़ीक्यूट किए गए टारगेट ही दिखाए जाएंगे. यह विकल्प, ठीक किए गए टूलचेन को बाहर नहीं रखेगा.
टैग:build_file_semantics
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ा जाने वाला और घटाने वाला). क्वेरी को दिए गए टारगेट के ट्रांज़िटिव बंद होने के ब्रह्मांड में तय किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और क्वेरी कमांड के लिए किया जाता है.
क्वेरी के लिए, इस विकल्प में इनपुट उन सभी जवाबों को टारगेट करता है जिनके तहत जवाब बनाए गए हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प तय नहीं किया गया है, तो यह माना जाता है कि सबसे ऊपर के टारगेट को क्वेरी एक्सप्रेशन से पार्स किया गया टारगेट माना जाता है. ध्यान दें: क्वेरी के लिए, इस विकल्प को तय न करने से बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट टॉप-लेवल के विकल्पों के साथ बनाए नहीं जा सकते.
टैग:loading_and_analysis
- ऐसे विकल्प जो बिल्ड टाइम के ऑप्टिमाइज़ेशन को ट्रिगर करते हैं:
--[no]collapse_duplicate_defines
डिफ़ॉल्ट: "सही"-
चालू होने पर, ग़ैर-ज़रूरी -- शायद तय की गई चीज़ें, बिल्ड की शुरुआत में ही हटा दी जाएंगी. इससे, कुछ खास तरह के बिल्ड के लिए, विश्लेषण की कैश मेमोरी में होने वाली कमी से बचा जा सकता है.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_filter_library_jar_with_program_jar
डिफ़ॉल्ट: "गलत"-
लाइब्रेरीजेर में मौजूद किसी भी क्लास को हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग:action_command_lines
--[no]experimental_inmemory_dotd_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, C++ .d फ़ाइलों को डिस्क में लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_inmemory_jdeps_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलें, डिस्क में लिखे जाने के बजाय सीधे रिमोट बिल्ड नोड से मेमोरी में पास होंगी.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_objc_include_scanning
डिफ़ॉल्ट: "गलत"-
C-C++ के मकसद के लिए स्कैनिंग शामिल करें या नहीं.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]experimental_retain_test_configuration_across_testonly
डिफ़ॉल्ट: "गलत"-
चालू होने पर, --trim_test_config, testonly=1 के रूप में मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन में काट-छांट नहीं की जाएगी. इसका मकसद उन मामलों में कार्रवाई की समस्याओं को कम करना है जब जांच के नियम cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_config 'गलत' है, तो कोई असर नहीं पड़ता.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_starlark_cc_import
डिफ़ॉल्ट: "गलत"-
चालू होने पर, cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग:loading_and_analysis
,experimental
--[no]experimental_unsupported_and_brittle_include_scanning
डिफ़ॉल्ट: "गलत"-
इनपुट फ़ाइलों से #include लाइन को पार्स करके, C/C++ कंपाइलेशन को छोटा करके इनपुट करें. यह कंपाइलेशन इनपुट ट्री के साइज़ को कम करके, परफ़ॉर्मेंस को बेहतर बनाने और परफ़ॉर्मेंस को बेहतर बनाने के लिए इस्तेमाल किया जा सकता है. हालांकि, यह बिल्ड को भी तोड़ सकता है, क्योंकि शामिल करने वाला स्कैनर, सी प्रीप्रोसेसर सिमेंटिक को पूरी तरह लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता है और प्रीप्रोसेसर कंडीशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. शिकायत किए गए इस फ़्लैग से जुड़ी सभी समस्याओं को बंद कर दिया जाएगा.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]incremental_dexing
डिफ़ॉल्ट: "सही"-
ज़्यादातर Java फ़ाइल के लिए, डेक्सिंग का अलग-अलग काम करता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]objc_use_dotd_pruning
डिफ़ॉल्ट: "सही"-
अगर सेट की गई, तो clang की ओर से उत्सर्जित की जाने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइल में भेजे जाने वाले इनपुट सेट को हटाने के लिए किया जाएगा.
टैग:changes_inputs
,loading_and_analysis
--[no]process_headers_in_dependencies
डिफ़ॉल्ट: "गलत"-
कोई टारगेट //a:a बनाते समय, सभी टारगेट में //a:a वाले हेडर प्रोसेस होते हैं (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू होती है).
टैग:execution
--[no]trim_test_configuration
डिफ़ॉल्ट: "सही"-
चालू होने पर, टेस्ट से जुड़े विकल्प, बिल्ड के ऊपरी लेवल से नीचे हटा दिए जाएंगे. अगर यह फ़्लैग चालू है, तो टेस्ट को नॉन-टेस्ट नियमों के लिए डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने पर, नॉन-टेस्ट नियमों का दोबारा विश्लेषण नहीं होगा.
टैग:loading_and_analysis
,loses_incremental_state
--[no]use_singlejar_apkbuilder
डिफ़ॉल्ट: "सही"-
इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. इस पर अब कोई कार्रवाई नहीं होगी. इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
- ऐसे विकल्प जो बोली की जानकारी, फ़ॉर्मैट, या जगह की जानकारी पर असर डालते हैं:
- डिफ़ॉल्ट
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
: "-.*" -
टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. फ़्लैग एक रेगुलर एक्सप्रेशन लेता है. इसे टूलचेन टाइप और खास टारगेट के लिए जांचा जाता है, ताकि यह देखा जा सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा से अलग किया जा सकता है. साथ ही, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल है और यह सिर्फ़ टूलटिप के रिज़ॉल्यूशन में विशेषज्ञों के काम का हो सकता है.
टैग:terminal_output
- किसी सामान्य इनपुट के बारे में बताने या उसे बदलने वाले ऐसे विकल्प जो किसी दूसरी कैटगरी में नहीं आते हैं:
--flag_alias=<a 'name=value' flag alias>
बार कई बार इस्तेमाल किया गया-
किसी Starstark फ़्लैग के लिए शॉर्टहैंड नाम सेट करता है. यह "<key>=<value>" रूप में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग:changes_inputs
--[no]incompatible_default_to_explicit_init_py
डिफ़ॉल्ट: "गलत"-
यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि __init__.py फ़ाइलें Python टारगेट की रनटाइम में अपने-आप न बन जाएं. सटीक रूप से, जब किसी 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_ आउटपुटs_are_suffixed` पर सेट करने का सुझाव भी दिया जाता है.
टैग:loading_and_analysis
,affects_outputs
,incompatible_change
--[no]incompatible_use_python_toolchains
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो एक्ज़ीक्यूटेबल नेटिव Python नियम का इस्तेमाल किया जाएगा. इसके लिए, Python टूलचेन से तय किए गए Python रनटाइम का इस्तेमाल किया जाएगा. इसके लिए, --python_top जैसे पुराने फ़्लैग का इस्तेमाल किया जाएगा.
टैग: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
] डिफ़ॉल्ट: "अपने-आप"- अगर 'ऑटो' पर सेट किया जाता है, तो बेज़ल फिर से टेस्ट करता है अगर: (1) बेज़ल को टेस्ट या उसकी डिपेंडेंसी में बदलाव का पता चलता है, (2) टेस्ट को बाहरी के तौर पर मार्क किया गया है और (3) टेस्ट के लिए --runs_per_test का इस्तेमाल करके अनुरोध किया गया है(4) टेस्ट पहले पूरा नहीं हो सका. अगर 'हां' पर सेट किया जाता है, तो Bazel सभी टेस्ट के नतीजों को कैश मेमोरी में रखता है. हालांकि, बाहरी जांच के नतीजों में ऐसा नहीं किया जाता. अगर 'no' पर सेट किया जाता है, तो Bazel कोई भी जांच के नतीजे कैश मेमोरी में नहीं रखता.
--[no]experimental_cancel_concurrent_tests
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो पहली बार सफल होने पर ब्लेज़ एक साथ चलाने वाले टेस्ट को रद्द कर देगा. यह सिर्फ़ --runs_per_test_detects_flakes के साथ मिलकर काम करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_fetch_all_coverage_outputs
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो कवरेज चलाने के दौरान, Bazel, हर टेस्ट के लिए पूरी कवरेज की डेटा डायरेक्ट्री फ़ेच करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_generate_llvm_lcov
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो Clang के लिए कवरेज एक LCOV रिपोर्ट जनरेट करेगा.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_j2objc_header_map
डिफ़ॉल्ट: "सही"- J2ObjC ट्रांसलेशन के साथ-साथ, J2ObjC हेडर मैप जनरेट करना है या नहीं.
--[no]experimental_j2objc_shorter_header_path
डिफ़ॉल्ट: "गलत"-
छोटे हेडर पाथ से जनरेट करने के लिए, "_j2objc" के बजाय "_ios" का इस्तेमाल होता है.
टैग:affects_outputs
--experimental_java_classpath=<off, javabuilder or bazel>
डिफ़ॉल्ट: "javabuilder"- Java कंपाइलेशन के लिए कम क्लासपाथ चालू करता है.
--[no]experimental_limit_android_lint_to_android_constrained_java
डिफ़ॉल्ट: "गलत"-
Android के साथ काम करने वाली लाइब्रेरी का इस्तेमाल करने के लिए --experimental_run_android_lint_on_java_rule.
टैग:affects_outputs
--[no]experimental_run_android_lint_on_java_rules
डिफ़ॉल्ट: "गलत"-
java_* सोर्स की पुष्टि करनी है या नहीं.
टैग:affects_outputs
--[no]explicit_java_test_deps
डिफ़ॉल्ट: "गलत"- TestRunner के डिप से गलती से मिलने के बजाय java_test में JUnit या Hancrest के लिए साफ़ तौर पर निर्भरता बताएं. फ़िलहाल, सिर्फ़ बेज़ल के लिए काम करता है.
--host_java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- ऐसे Java लॉन्चर का इस्तेमाल किया जाने वाला Java लॉन्चर जो बिल्ड के दौरान चलाया जाता है.
--host_javacopt=<a string>
बार कई बार इस्तेमाल किया गया- बिल्ड के दौरान लागू होने वाले टूल बनाते समय, javac में पास करने के लिए अन्य विकल्प.
--host_jvmopt=<a string>
बार कई बार इस्तेमाल किया गया- बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल को बनाते समय Java वीएम में पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_check_sharding_support
डिफ़ॉल्ट: "सही"-
अगर सही है, तो टेस्ट रनर से यह पता नहीं चलेगा कि टेस्ट रनर यह बताता है कि वह TEST_SHARD_STATUS_FILE के पाथ में फ़ाइल को छूकर, शार्डिंग के साथ काम करता है या नहीं. अगर गलत है, तो टेस्ट रनर में शार्डिंग का इस्तेमाल नहीं किया जा सकता. इससे हर शार्ड में सभी टेस्ट चल जाएंगे.
टैग:incompatible_change
--[no]incompatible_exclusive_test_sandboxed
डिफ़ॉल्ट: "सही"-
अगर सही है, तो सैंडबॉक्स की रणनीति के साथ खास जांच की जाएगी. स्थानीय तौर पर की जाने वाली खास जांच को लागू करने के लिए, 'लोकल' टैग जोड़ें
टैग:incompatible_change
--[no]incompatible_strict_action_env
डिफ़ॉल्ट: "गलत"-
सही होने पर, Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है और LD_Library_PATH को इनहेरिट नहीं करता. अगर आपको क्लाइंट से खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान रखें कि ऐसा करने से किसी शेयर की गई कैश मेमोरी का इस्तेमाल किए जाने पर, क्रॉस-उपयोगकर्ता कैशिंग को रोका जा सकता है.
टैग:loading_and_analysis
,incompatible_change
--j2objc_translation_flags=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया- J2ObjC टूल को पास करने के लिए अन्य विकल्प.
--java_debug
-
यह, किसी JavaScript जांच की Java वर्चुअल मशीन को जांच शुरू करने से पहले, जेडीडब्ल्यूपी के मुताबिक डीबगर (जैसे कि jdb) से कनेक्शन के लिए इंतज़ार करने देता है. लागू -test_ आउटपुट=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
डिफ़ॉल्ट: "सही"- सीधे स्रोत से IJAR कंपाइल करें.
--java_language_version=<a string>
डिफ़ॉल्ट: ""- Java का भाषा वर्शन
--java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया गया है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "लॉन्चर" विशेषता इस फ़्लैग को ओवरराइड करती है.
--java_runtime_version=<a string>
डिफ़ॉल्ट: "local_jdk"- Java रनटाइम वर्शन
--javacopt=<a string>
बार कई बार इस्तेमाल किया गया- javac में पास करने के लिए ज़्यादा विकल्प.
--jvmopt=<a string>
बार कई बार इस्तेमाल किया गया- Java वीएम पास करने के लिए ज़्यादा विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- लेगसी मल्टीडेक्स कंपाइल करते समय, क्लास की सूची जनरेट करने के लिए बाइनरी फ़ाइल का इस्तेमाल किया जा सकता है.
--optimizing_dexer=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- बिना शार्डिंग के डिक्सिंग के लिए इस्तेमाल की जाने वाली बाइनरी फ़ाइल के बारे में बताता है.
--plugin=<a build target label>
बार कई बार इस्तेमाल किया गया- बिल्ड में इस्तेमाल करने के लिए प्लग इन. अभी यह java_plugins के साथ काम करता है.
--proguard_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- यह बताता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल करना है.
--proto_compiler=<a build target label>
: "@bazel_tools//tools/proto:protos"-
प्रोटो-कंपाइलर का लेबल.
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_cc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain"-
proto_lang_toolchain() का लेबल जो C++ प्रोटो को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_j2objc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"-
proto_lang_toolchain() का लेबल जो j2objc protos को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_java=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:java_toolchain"-
proto_lang_toolchain() का लेबल जो Java प्रोटो को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_javalite=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:javalite_toolchain"-
proto_lang_toolchain() का लेबल जो JavaLite प्रोटो को कंपाइल करने का तरीका बताता है
टैग:affects_outputs
,loading_and_analysis
--protocopt=<a string>
बार कई बार इस्तेमाल किया गया-
प्रोटोबफ़ कंपाइलर में पास करने के लिए अन्य विकल्प.
टैग:affects_outputs
--[no]runs_per_test_detects_flakes
डिफ़ॉल्ट: "गलत"- अगर सही है, तो कम से कम एक दौड़ या कोशिश में सफल कम से कम एक शार्ड को FLAKY स्टेटस मिलता है.
--shell_executable=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
Bzel के इस्तेमाल के लिए शेल एक्ज़ीक्यूटेबल का पूरा पाथ. अगर इस नीति को सेट नहीं किया जाता है, तो BAZEL_SH एनवायरमेंट वैरिएबल, पहले बेज़ेल इनोवेशन पर सेट होता है. यह शुरू करने का काम Bazel सर्वर को चालू करना होता है. अगर इनमें से कोई भी सेट नहीं किया जाता है, तो Bazel एक ऑपरेटिंग सिस्टम के आधार पर हार्ड कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करेगा (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash). ध्यान दें कि ऐसे शेल का इस्तेमाल करने से जो जनरेट नहीं हो सकता है वह जनरेट की गई बाइनरी में काम नहीं कर पाता या रनटाइम बंद हो सकता है.
टैग:loading_and_analysis
--test_arg=<a string>
बार कई बार इस्तेमाल किया गया- ऐसे दूसरे विकल्प और आर्ग्युमेंट के बारे में बताता है जिन्हें टेस्ट एक्ज़ीक्यूटेबल को भेजा जाना चाहिए. इसका इस्तेमाल, कई आर्ग्युमेंट को तय करने के लिए एक से ज़्यादा बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो दोनों को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ 'बेज़ल टेस्ट' निर्देश से किया जाता है.
--test_filter=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, टेस्ट की प्रोसेस को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे उन टारगेट पर असर नहीं पड़ता है जो बनाए गए हैं.
- डिफ़ॉल्ट
--test_result_expiration=<an integer>
: "-1" - इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं पड़ता.
--[no]test_runner_fail_fast
डिफ़ॉल्ट: "गलत"- फ़ॉरवर्ड करने की सुविधा, टेस्ट रनर के लिए तुरंत उपलब्ध नहीं होती. पहली बार कनेक्ट न होने पर, टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce>
डिफ़ॉल्ट: "अश्लील"- टेस्ट शार्डिंग के लिए रणनीति तय करें: 'अश्लील' फ़ॉर्मैट का इस्तेमाल सिर्फ़ शार्ड का इस्तेमाल करने के लिए करें. ऐसा सिर्फ़ तब करें, जब 'shar_count' BUILD एट्रिब्यूट मौजूद हो. 'बंद है' का इस्तेमाल करके, टेस्ट शार्डिंग का इस्तेमाल कभी न करें. 'force'=k' को लागू करने के लिए, 'kd' शार्ड को लागू करें. भले ही, 'sard_count' BUILD एट्रिब्यूट पर ध्यान न दिया गया हो.
--tool_java_language_version=<a string>
डिफ़ॉल्ट: ""- ऐसा Java वर्शन जिसमें किसी टूल को इस्तेमाल करने के दौरान, ज़रूरी टूल चलाने के लिए इस्तेमाल किया जाता था
--tool_java_runtime_version=<a string>
डिफ़ॉल्ट: "remotejdk_11"- बिल्ड के दौरान टूल चलाने के लिए, इस्तेमाल किया गया Java रनटाइम वर्शन
--[no]use_ijars
डिफ़ॉल्ट: "सही"- चालू होने पर, इस विकल्प की वजह से Java कंपाइल इंटरफ़ेस जार का इस्तेमाल करता है. इसके नतीजे के तौर पर, इंक्रीमेंटल (बढ़ने वाले) कंपाइलेशन में बढ़ोतरी होगी. हालांकि, गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.
बिल्ड के विकल्प
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने उन्हें पार्स किया है:
--distdir=<a path>
बार कई बार इस्तेमाल किया गया-
संग्रहित करने के लिए नेटवर्क ऐक्सेस करने से पहले, उन्हें खोजने के लिए दूसरी जगहें.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "गलत"-
अगर इसे सेट किया जाता है, तो कैश मेमोरी में सेव होने वाले डेटा को कॉपी करने के बजाय रिपॉज़िटरी कैश मेमोरी, डेटा को हार्डलिंक कर देगी. इसका इस्तेमाल डिस्क में मौजूद जगह बचाने के लिए किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो डेटा के रिपॉज़िटरी के यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल यूआरएल के तौर पर करें. इससे, यूआरएल में बदलाव होता है जिसकी वजह से डेटा फिर से डाउनलोड होता है. ऐसा तब भी होता है, जब कैश मेमोरी में एक ही हैश वाला डाउनलोड शामिल हो. इसका इस्तेमाल इस बात की पुष्टि करने के लिए किया जा सकता है कि यूआरएल में किए गए बदलावों की वजह से, कैश मेमोरी में सेव किए गए डेटा को सेव करने की सुविधा काम नहीं कर रही.
टैग:loading_and_analysis
,experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
डाउनलोड करने की गड़बड़ी में फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो दोबारा कोशिश नहीं की जा सकती.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने के नियमों के सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड में बदलाव किए बिना, डेटा स्टोर करने की ऐसी जगहों पर काम किया जा सकता है जो नियम के लेखक की तुलना में धीमी हों.
टैग:bazel_internal_configuration
,experimental
--http_connector_attempts=<an integer>
डिफ़ॉल्ट: "8"-
http के ज़रिए डाउनलोड किए जाने वाले वीडियो की ज़्यादा से ज़्यादा संख्या.
टैग:bazel_internal_configuration
--http_connector_retry_max_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "0s"-
http डाउनलोड करने की फिर से कोशिश करने का ज़्यादा से ज़्यादा समय. शून्य से बड़ी वैल्यू के साथ, टाइम आउट की सबसे ज़्यादा वैल्यू तय नहीं की जाती.
टैग:bazel_internal_configuration
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
यहां दिए गए फ़ैक्टर के हिसाब से, एचटीटीपी डाउनलोड से जुड़े सभी टाइम आउट बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
इसमें बाहरी स्टोर करने की जगहों को फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू को कैश मेमोरी में सेव करने की जगह होती है. एक खाली स्ट्रिंग, जिसमें आर्ग्युमेंट के तौर पर, कैश मेमोरी को बंद करने का अनुरोध किया गया हो. अगर ऐसा नहीं है, तो '< आउटपुट_user_root>/cache/repos/v1' का डिफ़ॉल्ट इस्तेमाल किया जाता है
टैग:bazel_internal_configuration
--[no]repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया जाता है, तो रिपॉज़िटरी फ़ेच करने के दौरान, ctx.download{,_and_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं है. फिर भी, ctx.execute इंटरनेट को ऐक्सेस करने वाली आर्बिट्रेरी एक्ज़ीक्यूटेबल चला सकता है.
टैग:bazel_internal_configuration
- बिल्डिंग एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:
--[no]check_up_to_date
डिफ़ॉल्ट: "गलत"-
बिल्ड पूरा न करें, बस देखें कि क्या वह अप-टू-डेट है. अगर सभी टारगेट अप-टू-डेट हैं, तो उनका बिल्ड सही तरीके से पूरा हो जाता है. किसी भी एक चरण को लागू करने पर गड़बड़ी की रिपोर्ट की जाती है और बिल्ड पूरा नहीं हो पाता.
टैग:execution
--dynamic_local_execution_delay=<an integer>
डिफ़ॉल्ट: "1000"-
अगर किसी बिल्ड को कम से कम एक बार तेज़ी से चलाया जाता है, तो स्थानीय एक्ज़ीक्यूशन में कितने मिलीसेकंड देरी होनी चाहिए?
टैग:execution
,host_machine_resource_optimizations
--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment>
बार कई बार इस्तेमाल किया गया-
स्थानीय रणनीतियों के मुताबिक: दिए गए शब्द का इस्तेमाल करने के लिए - सबसे पहले लागू होने वाली रणनीति का इस्तेमाल किया जाता है. उदाहरण के लिए, `worker,sandboxed` में ऐसी कार्रवाइयां चलती हैं जो लगातार काम करने वाले लोगों को काम करने की रणनीति का इस्तेमाल करने में मदद करती हैं. साथ ही, इसमें वे सभी काम करते हैं जो सैंडबॉक्स की रणनीति का इस्तेमाल करते हैं. अगर कोई संदर्भ नहीं दिया जाता है, तो रणनीतियों की सूची का इस्तेमाल, सभी शब्दावली में फ़ॉलबैक के तौर पर किया जाता है. अगर `experimental_local_lockfree_आउटपुट` सेट है,तो डिफ़ॉल्ट फ़ॉलबैक सूची`worker, sandboxed` या `worker,sandboxed,standalone` है. यह [mnemonic=] है
टैग:execution
,host_machine_resource_optimizations
--dynamic_remote_strategy=<a '[name=]value1[,..,valueN]' assignment>
बार कई बार इस्तेमाल किया गया-
इस नीति का इस्तेमाल, दिए गए नीति के मुताबिक इस्तेमाल करने के लिए किया जाता है - पहली लागू रणनीति का इस्तेमाल किया जाता है. अगर कोई संदर्भ नहीं दिया जाता है, तो रणनीतियों की सूची का इस्तेमाल, सभी शब्दावली में फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची `रिमोट` है, इसलिए आम तौर पर इस फ़्लैग को साफ़ तौर पर सेट करने की ज़रूरत नहीं है. [mnemonic={0/}]remote_stratevy[,remote_stratesy,...] लेता है
टैग:execution
,host_machine_resource_optimizations
--experimental_docker_image=<a string>
डिफ़ॉल्ट: ""-
डॉकर इमेज का नाम बताएं (उदाहरण के लिए, "ubuntu:new"). इसका इस्तेमाल, डॉकर रणनीति का इस्तेमाल करते समय सैंडबॉक्स की गई कार्रवाई करने के लिए किया जाना चाहिए. साथ ही, प्लैटफ़ॉर्म के ब्यौरे में दी गई रिमोट_execution_property में कार्रवाई के लिए पहले से कोई कंटेनर-इमेज एट्रिब्यूट नहीं दिया गया है. इस फ़्लैग की वैल्यू, 'डॉकर रन' पर बोलकर दी जाती है. इसलिए, इसमें वही सिंटैक्स और तरीके इस्तेमाल किए जा सकते हैं जो डॉकर खुद करता है.
टैग:execution
--[no]experimental_docker_use_customized_images
डिफ़ॉल्ट: "सही"-
चालू होने पर, मौजूदा उपयोगकर्ता के uid और gid को डॉक करने के लिए, उसका इस्तेमाल करने से पहले इंजेक्ट करें. अगर बिल्ड / टेस्ट उस उपयोगकर्ता पर निर्भर करता है जिसका नाम कंटेनर में है और नाम और होम डायरेक्ट्री मौजूद है, तो ऐसा करना ज़रूरी है. यह सुविधा डिफ़ॉल्ट रूप से चालू रहती है. हालांकि, इमेज को अपने-आप पसंद के मुताबिक बनाने की सुविधा आपके मामले में काम नहीं करती या आप जानते हैं कि आपको इसकी ज़रूरत नहीं है. हालांकि, इसे बंद किया जा सकता है.
टैग:execution
--[no]experimental_dynamic_exclude_tools
डिफ़ॉल्ट: "सही"-
सेट किए जाने पर, "टूल के लिए" बनाए गए टारगेट, डाइनैमिक एक्ज़ीक्यूशन के दायरे में नहीं आते. इस तरह के टारगेट को बढ़ाने की संभावना नहीं है. इसलिए, लोकल साइकल खर्च करने लायक नहीं हैं.
टैग:execution
,host_machine_resource_optimizations
--experimental_dynamic_local_load_factor=<a double>
डिफ़ॉल्ट: "0"-
यह कंट्रोल करता है कि डाइनैमिक मशीन चलाने से लेकर लोकल मशीन पर कितना लोड करना है. यह फ़्लैग इस बात को अडजस्ट करता है कि डाइनैमिक एक्ज़ीक्यूशन में कितनी कार्रवाइयां हमें शेड्यूल करेंगी. यह इस बात पर आधारित है कि CPUs ब्लेज़ के उपलब्ध होने की संख्या कितनी है - इसे --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
डिफ़ॉल्ट: "गलत"-
डॉकर पर आधारित सैंडबॉक्स करने की सुविधा चालू करें. अगर डॉकर इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं होगा.
टैग:execution
--experimental_oom_more_eagerly_threshold=<an integer in 0-100 range>
डिफ़ॉल्ट: "100"-
अगर इस फ़्लैग को 100 से कम पर सेट किया जाता है, तो बेज़ल तब तक OOM करेगा, जब तक कि पूरे जीसी में दो के बाद भी, "पुरानी पीढ़ी के" हीप के प्रतिशत की संख्या ज़्यादा नहीं है.
टैग: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"-
अगर शून्य है, तो कार्रवाई पूरी होते ही सैंडबॉक्स ट्री को मिटा दें, क्योंकि कार्रवाई पूरी होने में देरी हो सकती है. अगर यह संख्या शून्य से ज़्यादा है, तो एसिंक्रोनस थ्रेड पूल में इन तीन डेटा को मिटाएं. इनके बाद, बिल्ड चलने के दौरान साइज़ 1 हो. साथ ही, सर्वर के कुछ समय से इस्तेमाल में न होने पर, इस फ़्लैग के बताए गए साइज़ तक बढ़ाया जाता है.
टैग:host_machine_resource_optimizations
,execution
--experimental_sandbox_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "0"-
अगर > 0 है, तो हर Linux सैंडबॉक्स, मेमोरी में तय की गई संख्या (एमबी) तक सीमित रहेगा. इसके लिए, cgroups v1 और v2 को ऐक्सेस करना ज़रूरी है. साथ ही, उपयोगकर्ताओं को cgroups dir के लिए अनुमति देनी होगी.
टैग:execution
--experimental_sandboxfs_path=<a string>
डिफ़ॉल्ट: "sandboxfs"-
-experimental_use_sandboxf के सही होने पर, सैंडबॉक्सf बाइनरी का पाथ. अगर कोई नाम है, तो PATH में पाए जाने वाले नाम की पहली बाइनरी का इस्तेमाल करें.
टैग:host_machine_resource_optimizations
,execution
--[no]experimental_shrink_worker_pool
डिफ़ॉल्ट: "गलत"-
अगर वर्कर मेमोरी में ज़्यादा दबाव है, तो चालू होने पर वर्कर पूल को छोटा किया जा सकता है. यह फ़्लैग सिर्फ़ तब काम करता है, जब फ़्लैग_experiment_total_worker_मेमोरी_limit_mb को चालू किया गया हो.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_split_xml_generation
डिफ़ॉल्ट: "सही"-
अगर इस फ़्लैग को सेट किया जाता है और जांच कार्रवाई से test.xml फ़ाइल जनरेट नहीं होती है, तो Bazel एक अलग कार्रवाई का इस्तेमाल करके, टेस्ट लॉग वाली एक डमी test.xml फ़ाइल जनरेट करेगा. ऐसा न करने पर, Bazel, जांच कार्रवाई के हिस्से के तौर पर एक test.xml जनरेट करता है.
टैग:execution
--experimental_total_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "0"-
अगर यह सीमा शून्य से ज़्यादा है, तो सभी वर्कर के मेमोरी का इस्तेमाल, तय सीमा से ज़्यादा होने पर उनकी मौत हो सकती है.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_use_hermetic_linux_sandbox
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया गया है, तो रूट को माउंट न करें. सिर्फ़ सैंडबॉक्स_add_माउंट_जोड़ें के साथ दी गई वैल्यू को माउंट करें. इनपुट फ़ाइलें, सैंडबॉक्स से सिम्युलेट किए जाने के बजाय सैंडबॉक्स से हार्डलिंक की जाएंगी. अगर इनपुट इनपुट फ़ाइलें, सैंडबॉक्स से अलग किसी फ़ाइल सिस्टम पर मौजूद हैं, तो इनपुट फ़ाइलें कॉपी हो जाएंगी.
टैग:execution
--[no]experimental_use_sandboxfs
डिफ़ॉल्ट: "गलत"-
सिंबल लिंक ट्री बनाने के बजाय, एक्ज़ीक्यूट डायरेक्ट्री से कार्रवाइयां करने के लिए सैंडबॉक्सfs का इस्तेमाल करें. अगर "yes" है, तो --experimental_sandboxfs_path से दी गई बाइनरी फ़ाइल मान्य होनी चाहिए और सैंडबॉक्सfs के साथ काम करने वाले वर्शन से जुड़ी होनी चाहिए. अगर "ऑटो", तो बाइनरी मौजूद नहीं है या काम नहीं करता.
टैग:host_machine_resource_optimizations
,execution
--[no]experimental_use_semaphore_for_jobs
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो सेमीफ़ोर का इस्तेमाल करके एक साथ कई नौकरियों की संख्या तय करें.
टैग:host_machine_resource_optimizations
,execution
--[no]experimental_use_windows_sandbox
डिफ़ॉल्ट: "गलत"- कार्रवाइयां चलाने के लिए, Windows सैंडबॉक्स का इस्तेमाल करें. अगर "yes" है, तो --experimental_विंडो_sandbox_path से दी गई बाइनरी फ़ाइल मान्य होनी चाहिए और सैंडबॉक्सfs के साथ काम करने वाले वर्शन से जुड़ी होनी चाहिए. अगर "ऑटो", तो बाइनरी मौजूद नहीं है या काम नहीं करता.
--experimental_windows_sandbox_path=<a string>
डिफ़ॉल्ट: "BazelSandbox.exe"- --experimental_use_विंडो_sandbox 'सही' होने पर Windows सैंडबॉक्स बाइनरी का पाथ. अगर कोई नाम है, तो PATH में पाए जाने वाले नाम की पहली बाइनरी का इस्तेमाल करें.
--experimental_worker_allowlist=<comma-separated set of options>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर खाली न हो, तो सिर्फ़ उन कर्मचारियों को ही काम करने दें जो दिए गए वर्कर कुंजी के नाम का इस्तेमाल कर रहे हैं.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_worker_as_resource
डिफ़ॉल्ट: "सही"-
नहीं, नहीं. इसे जल्द ही हटा दिया जाएगा.
टैग:no_op
--[no]experimental_worker_cancellation
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो बेज़ल अपने-आप काम करने वाले कर्मचारियों को रद्द करने का अनुरोध भेज सकता है.
टैग:execution
--experimental_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "0"-
अगर यह सीमा शून्य से ज़्यादा है, तो वर्कर की मेमोरी का इस्तेमाल सीमा से ज़्यादा होने पर, हो सकता है कि कर्मचारी की मौत हो जाए. अगर इसका इस्तेमाल डाइनैमिक तरीके से एक्ज़ीक्यूशन और `--experimental_Dynamic_ignore_local_signals=9` के साथ नहीं किया जाता है, तो इससे आपका बिल्ड क्रैश हो सकता है.
टैग:execution
,host_machine_resource_optimizations
--experimental_worker_metrics_poll_interval=<An immutable length of time.>
डिफ़ॉल्ट: "5s"-
कर्मचारियों की मेट्रिक इकट्ठा करने और उसे हटाने की कोशिश के बीच की अवधि. परफ़ॉर्मेंस की वजहों से 1 सेकंड से कम नहीं हो सकते.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_worker_multiplex_sandboxing
डिफ़ॉल्ट: "गलत"-
चालू होने पर, मल्टीप्लेक्स वर्कर को हर काम के अनुरोध के लिए, एक अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल करके सैंडबॉक्स किया जाएगा. सिर्फ़ उन वर्कर को सैंडबॉक्स किया जाएगा जिन्हें 'support-मल्टीप्लेक्स-सैंडबॉक्सिंग' लागू करने की ज़रूरत है.
टैग:execution
--[no]experimental_worker_strict_flagfiles
डिफ़ॉल्ट: "गलत"-
अगर नीति को चालू किया गया है, तो वर्कर के लिए तय की गई ज़रूरी शर्तों को पूरा न करने वाले ऐक्शन आर्ग्युमेंट में गड़बड़ी हो सकती है. वर्कर आर्ग्युमेंट के आर्ग्युमेंट की सूची में, एक @flagfile आर्ग्युमेंट होना चाहिए.
टैग:execution
--genrule_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
जीनोरल लागू करने का तरीका बताएं. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_stratepy=<value> का इस्तेमाल करें या सिर्फ़ genrule को कंट्रोल करने के लिए --stratety=Genrule=<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
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो हर सैंडबॉक्स सैंडबॉक्स को होस्ट फ़ाइल सिस्टम के साथ /tmp के बजाय, /tmp के तौर पर माउंट किया जाएगा. सभी सैंडबॉक्स में होस्ट की/tmp फ़ाइल देखने के लिए, --sandbox_add_mount_duo=/tmp का इस्तेमाल करें.
टैग:execution
--[no]internal_spawn_scheduler
डिफ़ॉल्ट: "गलत"-
प्लेसहोल्डर का विकल्प, ताकि हम ब्लेज़ में यह बता सकें कि स्पॉन शेड्यूलर चालू है या नहीं.
टैग:execution
,host_machine_resource_optimizations
--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
[-j
] डिफ़ॉल्ट: "अपने-आप"-
एक साथ की जाने वाली नौकरियों की संख्या. पूर्णांक लेता है या कीवर्ड ("ऑटो", "होस्ट_सीपीएस"), वैकल्पिक रूप से इसके बाद कार्रवाई ([-|**]<फ़्लो>) लगता है "auto", "Host_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. वैल्यू 2500 से ज़्यादा होने पर, मेमोरी से जुड़ी समस्याएं आ सकती हैं. "ऑटो", होस्ट संसाधनों के आधार पर सही डिफ़ॉल्ट की गिनती करता है.
टैग:host_machine_resource_optimizations
,execution
--[no]keep_going
[-k
] डिफ़ॉल्ट: "गलत"-
किसी गड़बड़ी के बाद, ज़्यादा से ज़्यादा बुकिंग जारी रखें. हालांकि, जो टारगेट पूरा नहीं हो सका और जिस पर निर्भर है उसका विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की दूसरी ज़रूरी शर्तें भी हो सकती हैं.
टैग:eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "अपने-आप"-
लोड होने/विश्लेषण के चरण के लिए समानांतर थ्रेड का इस्तेमाल किया जाता है. पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. इसके बाद, कार्रवाई ([-|*]<फ़्लो>) जैसे विकल्प को चुना जाता है. "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
--[no]reuse_sandbox_directories
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स न किए गए एक्ज़ीक्यूशन में इस्तेमाल होने वाली डायरेक्ट्री, फिर से इस्तेमाल की जा सकती हैं. ऐसा, ग़ैर-ज़रूरी सेटअप की लागत से बचने के लिए किया जाता है.
टैग:host_machine_resource_optimizations
,execution
--sandbox_base=<a string>
डिफ़ॉल्ट: ""-
इसकी मदद से, सैंडबॉक्स इस पाथ के नीचे अपनी सैंडबॉक्स डायरेक्ट्री बनाता है. जब आपके बिल्ड /टेस्ट में कई इनपुट फ़ाइलें होती हैं, तो परफ़ॉर्मेंस को बेहतर बनाने के लिए, tmpf (जैसे कि/run / shh) में कोई पाथ डालें. ध्यान दें: रनिंग ऐक्शन से जनरेट की गई आउटपुट और इंटरमीडिएट फ़ाइलों को बनाए रखने के लिए, आपको tmpfs में ज़रूरत के हिसाब से रैम और खाली जगह की ज़रूरत होती है.
टैग:host_machine_resource_optimizations
,execution
--[no]sandbox_explicit_pseudoterminal
डिफ़ॉल्ट: "गलत"-
सैंडबॉक्स की गई कार्रवाइयों के लिए, साफ़ तौर पर पहचान बदलने वाली सुविधाएं बनाना. कुछ Linux डिस्ट्रिब्यूशन के लिए, प्रोसेस के ग्रुप आईडी को सैंडबॉक्स में 'tty' सेट करना ज़रूरी होता है. इससे, स्यूडोटर्मिनल काम कर पाते हैं. अगर इससे समस्याएं आ रही हैं, तो इस फ़्लैग को बंद किया जा सकता है, ताकि दूसरे ग्रुप का इस्तेमाल किया जा सके.
टैग:execution
--sandbox_tmpfs_path=<an absolute path>
बार कई बार इस्तेमाल किया गया-
सैंडबॉक्स की गई कार्रवाइयों के लिए, इस डीबग पाथ में एक खाली और लिखने लायक डायरेक्ट्री माउंट करें (अगर सैंडबॉक्स की सुविधा काम करती है, तो इसे नज़रअंदाज़ कर दें).
टैग:host_machine_resource_optimizations
,execution
--[no]skip_incompatible_explicit_targets
डिफ़ॉल्ट: "गलत"-
ऐसे टारगेट को छोड़ें जो कमांड लाइन में साफ़ तौर पर दिखते हैं. डिफ़ॉल्ट रूप से, ऐसे टारगेट बनाने की वजह से गड़बड़ी होती है. हालांकि, इस विकल्प के चालू होने पर वे बिना आवाज़ के नहीं चल जाते. देखें: https://bazel.build/extending/platforms#skipping-insupported-targets
टैग:loading_and_analysis
--spawn_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
तय करें कि डिफ़ॉल्ट रूप से, स्पॉन ऐक्शन को कैसे लागू किया जाता है. सबसे ज़्यादा से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार की जाती है. हर कार्रवाई के लिए, बेज़ल सबसे ज़्यादा प्राथमिकता वाली रणनीति को चुनते हैं. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी पाने के लिए, https://blog.bazel.build/2019/06/19/list-stratepy.html पर जाएं.
टैग:execution
--strategy=<a '[name=]value1[,..,valueN]' assignment>
बार कई बार इस्तेमाल किया गया-
स्पॉन की अन्य कार्रवाइयों को कंपाइल करने का तरीका बताएं. सबसे ज़्यादा से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार की जाती है. हर कार्रवाई के लिए, बेज़ल सबसे ज़्यादा प्राथमिकता वाली रणनीति को चुनते हैं. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग --spawn_stratety (अगर -- mnemonic Genrule के साथ इस्तेमाल किया गया है) को --genrule_stratety) से सेट की गई वैल्यू बदलता है. ज़्यादा जानकारी पाने के लिए, https://blog.bazel.build/2019/06/19/list-stratepy.html पर जाएं.
टैग:execution
--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment>
बार कई बार इस्तेमाल किया गया-
तय करें कि किसी खास regex_filter से मैच करने वाली जानकारी का इस्तेमाल करने के लिए, कौनसी स्पॉन रणनीति इस्तेमाल की जानी चाहिए. रेगुलर एक्सप्रेशन फ़िल्टर से मिलान करने की जानकारी पाने के लिए, --per_file_copt देखें. ब्यौरे से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. यह विकल्प, रणनीति के बारे में बताने वाले दूसरे फ़्लैग को बदल देता है. उदाहरण: --stratepy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि स्थानीय रणनीति का इस्तेमाल करके कार्रवाइयां करनी होंगी. ऐसा तब होगा, जब उनके ब्यौरे //foo.*.cc के बजाय //foo/bar से मेल खाते हों. उदाहरण: --stratepy_regexp='Compling.*/bar=local --strategi_regexp=Compling=sandboxed' 'लोकल' रणनीति के साथ 'Compling //foo/bar/baz' चलाएगा. हालांकि, ऑर्डर उलटने पर यह 'सैंडबॉक्स' के साथ काम करेगा.
टैग:execution
--worker_extra_flag=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया-
ज़्यादा कमांड वाले फ़्लैग, जिन्हें --persistent_worker, के अलावा वर्कर प्रोसेस में पास किया जाएगा. उदाहरण के लिए, --worker_extra_flag=Javac=--debug.
टैग:execution
,host_machine_resource_optimizations
--worker_max_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
बार कई बार इस्तेमाल किया गया-
अगर आपने 'वर्कर' रणनीति का इस्तेमाल किया है, तो हर तरह के स्थायी कर्मचारी के कितने इंस्टेंस लॉन्च किए जा सकते हैं. हर नाम के हिसाब से अलग-अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर बताया जा सकता है. यह सीमा वर्कर बटन पर आधारित होती है, जिन्हें मोमोनिक लेवल के आधार पर अलग-अलग किया जाता है. हालांकि, स्टार्टअप फ़्लैग और एनवायरमेंट में भी ऐसा किया जा सकता है. हालांकि, कुछ मामलों में हर फ़्लैग के लिए तय किए गए नियमों से ज़्यादा कर्मचारियों का इस्तेमाल किया जा सकता है. पूर्णांक लेता है या कीवर्ड ("ऑटो", "होस्ट_सीपीएस"), वैकल्पिक रूप से इसके बाद कार्रवाई ([-|**]<फ़्लो>) लगता है "auto", "Host_CPUS*.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_multix के साथ-साथ 'वर्कर' रणनीति का इस्तेमाल किया जाता है, तो इससे जुड़े कितने अनुरोध एक साथ हो सकते हैं. हर नाम के हिसाब से अलग-अलग वैल्यू देने के लिए, इसे [name=value] के तौर पर बताया जा सकता है. यह सीमा वर्कर बटन पर आधारित होती है, जिन्हें मोमोनिक लेवल के आधार पर अलग-अलग किया जाता है. हालांकि, स्टार्टअप फ़्लैग और एनवायरमेंट में भी ऐसा किया जा सकता है. हालांकि, कुछ मामलों में हर फ़्लैग के लिए तय किए गए नियमों से ज़्यादा कर्मचारियों का इस्तेमाल किया जा सकता है. पूर्णांक लेता है या कीवर्ड ("ऑटो", "होस्ट_सीपीएस"), वैकल्पिक रूप से इसके बाद कार्रवाई ([-|**]<फ़्लो>) लगता है "auto", "Host_CPUS*.5". 'अपने-आप', मशीन की क्षमता के आधार पर सही डिफ़ॉल्ट की गिनती करता है. "=value", वैल्यू के तौर पर तय नहीं किए गए शब्दों के लिए एक डिफ़ॉल्ट वैल्यू सेट करता है.
टैग:execution
,host_machine_resource_optimizations
--[no]worker_multiplex
डिफ़ॉल्ट: "सही"-
इसके उपलब्ध होने पर, कर्मचारी मल्टीप्लेक्स का इस्तेमाल करेंगे.
टैग:execution
,host_machine_resource_optimizations
--[no]worker_quit_after_build
डिफ़ॉल्ट: "गलत"-
अगर सुविधा चालू है, तो बिल्ड पूरा होने के बाद सभी वर्कर काम करना बंद कर देते हैं.
टैग:execution
,host_machine_resource_optimizations
--[no]worker_sandboxing
डिफ़ॉल्ट: "गलत"-
अगर इसे चालू किया जाता है, तो वर्कर सैंडबॉक्स वाले एनवायरमेंट में काम करेंगे.
टैग:execution
--[no]worker_verbose
डिफ़ॉल्ट: "गलत"- चालू होने पर, वर्कर के शुरू होते ही, वर्बोस मैसेज को प्रिंट कर देता है. साथ ही, ...
- ऐसे विकल्प जो कार्रवाई करने के लिए इस्तेमाल होने वाले टूलचेन को कॉन्फ़िगर करते हैं:
--[no]incompatible_disable_runtimes_filegroups
डिफ़ॉल्ट: "गलत"-
बिना मंज़ूरी वाले रेफ़रल कोड
टैग:action_command_lines
,loading_and_analysis
,deprecated
,incompatible_change
--[no]incompatible_dont_emit_static_libgcc
डिफ़ॉल्ट: "सही"-
बिना मंज़ूरी वाले रेफ़रल कोड
टैग: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
--target_platform_fallback=<a string>
डिफ़ॉल्ट: ""-
इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं पड़ता.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
- ऐसे विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:
--[no]build
डिफ़ॉल्ट: "सही"-
बिल्ड को एक्ज़ीक्यूट करें, यह एक आम बात है. --nobuild तय करने से बिल्ड कार्रवाइयां पूरा होने से पहले ही बिल्ड बंद हो जाता है, अगर पैकेज लोड होने और विश्लेषण के फ़ेज़ पूरे हो जाते हैं, तो वैल्यू शून्य हो जाती है. यह मोड उन फ़ेज़ की जांच करने के लिए उपयोगी है.
टैग:execution
,affects_outputs
--[no]experimental_run_validations
डिफ़ॉल्ट: "सही"-
इसके बजाय --run_मान्यता का इस्तेमाल करें.
टैग:execution
,affects_outputs
--[no]experimental_use_validation_aspect
डिफ़ॉल्ट: "गलत"-
जांच करने के दौरान, उसका साथ का इस्तेमाल करके पुष्टि करने की कार्रवाइयां की जा सकती हैं या नहीं.
टैग:execution
,affects_outputs
--output_groups=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया-
कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. हर ग्रुप के नाम से पहले + या - का निशान लगाया जाता है. + से शुरू होने वाले ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ दिया जाता है, जबकि प्रीफ़िक्स वाले ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप को प्रीफ़िक्स नहीं किया गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हट जाता है. मतलब
टैग:execution
,affects_outputs
--[no]run_validations
डिफ़ॉल्ट: "सही"-
बिल्ड के हिस्से के तौर पर पुष्टि करने की कार्रवाइयां करनी हैं या नहीं. https://baZE.build/buildending/rule#मान्यation_action
टैग:execution
,affects_outputs
- ऐसे विकल्प डालें जो उपयोगकर्ता को उसके आउटपुट के बजाय, सही आउटपुट को कॉन्फ़िगर करने देते हैं, जिससे उसकी वैल्यू पर असर पड़ता है:
--aspects=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया- टॉप-लेवल टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा-सेपरेटेड लिस्ट. अगर सूची में, आसपेक्ट_aspect के लिए ज़रूरी शर्त लागू करने वाली कंपनियों से जुड़ी ज़रूरी जानकारी दी जाती है, तो did_aspect ऐसे हर पहलू के बाद काम करेगा जिसके बारे में पहले बताया गया है. साथ ही, आसपेक्ट रेशियो (चौड़ाई-ऊंचाई का डेटा) की सूची में, कुछ विज्ञापन देने वाले उन प्रोवाइडर को भी शामिल करते हैं जिनके लिए data_aspect ज़रूरी है. इसके अलावा, मैनेज किया जाने वाला कुछ एट्रिब्यूट, एट्रिब्यूट की ज़रूरत वाले सभी ज़रूरी पहलुओं को दिखाने पर काम करता है. इसके बाद,Some_aspect के पास उन आसपेक्ट प्रोवाइडर की वैल्यू का ऐक्सेस होगा. <bzl-file-label>%<aspect_name>, जैसे कि '//tools:my_def.bzl%my_aspect', जहां 'my_aspect' किसी फ़ाइल टूल/my_def.bzl की टॉप-लेवल वैल्यू है
- डिफ़ॉल्ट
--bep_maximum_open_remote_upload_files=<an integer>
: "-1" -
BEP आर्टफ़ैक्ट अपलोड के दौरान, खुली हुई फ़ाइलों की ज़्यादा से ज़्यादा संख्या.
टैग:affects_outputs
--[no]experimental_convenience_symlinks
डिफ़ॉल्ट: "सामान्य"-
यह फ़्लैग इस बात को कंट्रोल करता है कि सुविधा के सिमलिंक, (बिल्डिंग के बाद फ़ाइल फ़ोल्डर में दिखने वाले सिमलिंक) को कैसे मैनेज किया जाएगा. संभावित वैल्यू:
सामान्य (डिफ़ॉल्ट): हर तरह का सुविधाजनक सिमलिंक बनाया या मिटाया जाएगा, जैसा कि बिल्ड ने तय किया है.
साफ़: सभी सिमलिंक, बिना शर्त के मिटाए जाएंगे.
अनदेखा करें: सिमलिंक अकेले रह जाएंगे.
log_only: लॉग मैसेज जनरेट करें जैसे कि 'सामान्य' पास किया गया हो, लेकिन असल में कोई फ़ाइल सिस्टम कार्रवाई न करें (टूल के लिए उपयोगी).
ध्यान दें कि सिर्फ़ वही सिमलिंक जिन पर मौजूदा नाम ---linklink_prefix की वैल्यू से जनरेट हुआ है, उन पर असर पड़ सकता है: अगर प्रीफ़िक्स बदलता है, तो पहले से मौजूद सभी सिमलिंक ही रह जाएंगे.
टैग:affects_outputs
--[no]experimental_convenience_symlinks_bep_event
डिफ़ॉल्ट: "गलत"-
इस फ़्लैग से यह कंट्रोल किया जाता है कि हम BuildEventProSimlinksIdd को BuildEventProtocol में पहचानेंगे या नहीं. अगर वैल्यू 'सही' है, तो BuildEventProtocol में][=SymlinksIdentified के लिए, एक एंट्री होगी, जिसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक होंगे. अगर 'गलत है' पर सेट किया जाता है, तो BuildEventProtocol मेंसुविधा के सिमलिंक वाले आईडी को खाली छोड़ दिया जाएगा.
टैग:affects_outputs
--experimental_multi_cpu=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया-
अब सेवा में नहीं है. नहीं.
टैग:affects_outputs
,experimental
--[no]incompatible_use_platforms_repo_for_constraints
डिफ़ॉल्ट: "सही"-
बिना मंज़ूरी वाली कार्रवाई की गई.
टैग:affects_outputs
,incompatible_change
--remote_download_minimal
-
लोकल मशीन से रिमोट बिल्ड आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, फ़्लैग करने के लिए इस्तेमाल किया जाने वाला शॉर्टकट है: --action_cache_store_ आउटपुट_metadata, --experimental_inमेमोरी_jdeps_files, --experimental_inspam_डॉट_files और --remote_download_outputs=minimal.
इसमें यह भी शामिल है:
--nobuild_runfile_links
--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>
डिफ़ॉल्ट: ""-
रिमोट बिल्ड आउटपुट को स्थानीय मशीन में डाउनलोड करने के बजाय, सिंबॉलिक लिंक बनाएं. सिंबॉलिक लिंक के टारगेट को टेंप्लेट स्ट्रिंग के तौर पर तय किया जा सकता है. इस टेंप्लेट स्ट्रिंग में {has} और {size_bytes} हो सकते हैं. साथ ही, ऑब्जेक्ट के हैश की जगह पर और साइज़ की जानकारी बाइट में बढ़ सकती है. उदाहरण के लिए, ये सिंबॉलिक लिंक, FUSE फ़ाइल सिस्टम पर ले जा सकते हैं. मांग पर कैस के ऑब्जेक्ट को लोड किया जाता है.
टैग:affects_outputs
--remote_download_toplevel
-
लोकल मशीन से सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट डाउनलोड किए जाते हैं. यह फ़्लैग, फ़्लैग करने के लिए इस्तेमाल किया जाने वाला शॉर्टकट है: --action_cache_store_ आउटपुट_metadata, --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_dogd_files और --remote_download_outputs=toplevel.
इसमें यह भी शामिल है:
--action_cache_store_output_metadata
--remote_download_outputs=toplevel
टैग:affects_outputs
--symlink_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
वह प्रीफ़िक्स, जो बिल्ड के बाद बनाए गए किसी भी सुविधा वाले सिम्लिंक के पहले जोड़ा जाता है. अगर इसे छोड़ा जाता है, तो डिफ़ॉल्ट वैल्यू, बिल्ड टूल का नाम होती है. इसके बाद, हाइफ़न फ़ंक्शन का इस्तेमाल किया जाता है. अगर '/' पास किया जाता है, तो कोई सिमलिंक नहीं बनाया जाता और कोई चेतावनी नहीं दी जाती. चेतावनी: '/' के लिए खास फ़ंक्शन जल्द ही बंद कर दिया जाएगा; इसके बजाय --experimental_convenience_symlinks=ignore को इस्तेमाल करें.
टैग:affects_outputs
- वे विकल्प जो इस बात पर असर डालते हैं कि Bazel, बिल्ड के मान्य इनपुट को किस तरह लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--[no]experimental_docker_privileged
डिफ़ॉल्ट: "गलत"-
अगर यह चालू है, तो Bazel, कार्रवाइयों को चलाते समय 'docker Run' के लिए, खास अधिकार वाले फ़्लैग को पास कर देगा. ऐसा आपके बिल्ड के लिए ज़रूरी हो सकता है, लेकिन इससे भी जानकारी कम हो सकती है.
टैग:execution
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
यह नीति खाली न होने पर, एक ऐसी फ़ाइल की जानकारी देती है जिसमें रिज़ॉल्व की गई वैल्यू होती है. इसके लिए, रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--[no]experimental_sandboxfs_map_symlink_targets
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो सैंडबॉक्स में ऐक्शन इनपुट के तौर पर दिए गए सिंबल वाले लिंक के टारगेट को मैप करता है. यह सुविधा सिर्फ़ उन गड़बड़ी के नियमों को ठीक करने के लिए है जो अपने-आप यह नहीं करती. ऐसे सभी नियमों को ठीक करने के बाद, इसे हटाया जाना चाहिए.
टैग:host_machine_resource_optimizations
,execution
--experimental_verify_repository_rules=<a string>
बार कई बार इस्तेमाल किया गया-
अगर डेटा स्टोर करने से जुड़े उन नियमों की सूची जिसके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए, फ़ाइल को --experimental_repository_ash_file में दिखाया जाता है.
टैग:affects_outputs
,experimental
--[no]incompatible_legacy_local_fallback
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो सैंडबॉक्स की गई डिफ़ॉल्ट तरीके से लागू की गई फ़ॉलबैक को, स्थानीय रणनीति में शामिल कर दिया जाता है. यह फ़्लैग आखिर में डिफ़ॉल्ट रूप से 'गलत' पर सेट हो जाएगा. इसके बाद, बिना किसी विकल्प वाला विकल्प बन जाएगा. इसके बजाय, फ़ॉलबैक को कॉन्फ़िगर करने के लिए, --stratesy, --spawn_stratety या --Dynamic_local_strategi का इस्तेमाल करें.
टैग: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
डिफ़ॉल्ट: "गलत"-
सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.
टैग:execution
--[no]sandbox_fake_username
डिफ़ॉल्ट: "गलत"-
सैंडबॉक्स की गई कार्रवाइयों के लिए, मौजूदा उपयोगकर्ता नाम को 'कोई नहीं' में बदलें.
टैग:execution
--sandbox_writable_path=<a string>
बार कई बार इस्तेमाल किया गया-
सैंडबॉक्स की गई कार्रवाइयों के लिए, किसी मौजूदा डायरेक्ट्री को सैंडबॉक्स में लिखें (अगर सैंडबॉक्स की सुविधा काम करती हो, तो उसे अनदेखा कर दें).
टैग:execution
- यह विकल्प Starlark भाषा के सिमेंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों को ऐक्सेस करने लायक बिल्ड एपीआई पर असर डालता है.:
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
नहीं
टैग:no_op
,deprecated
,experimental
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "गलत"-
अगर यह काम नहीं करता है, तो यह ग़ैर-ज़रूरी है. अगर यह फ़्लैग गलत है, तो //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
डिफ़ॉल्ट: "गलत"-
जांच न करें, बस देखें कि वे अप-टू-डेट हैं या नहीं. अगर जांच के सभी नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर कोई जांच करने या उसे लागू करने की ज़रूरत होती है, तो गड़बड़ी की रिपोर्ट की जाती है और जांच नहीं हो पाती है. यह विकल्प --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 बार तक चलाए जाएंगे. अगर 'डिफ़ॉल्ट' है, तो सामान्य जांचों के लिए सिर्फ़ एक बार कोशिश की जाएगी. साथ ही, उन जांचों के लिए तीन कोशिश की जाएगी जो उनके नियम (flaky=1 एट्रिब्यूट) के तौर पर साफ़ तौर पर मार्क की गई हैं. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. जहां flky_test_attempts ऊपर है, तो regex_filter रेगुलर एक्सप्रेशन के पैटर्न को शामिल करने और बाहर रखने के लिए है (और देखें --runs_per_test). उदाहरण: --flaky_test_attempts=//foo/.*,-//foo/bar/.*@3 foo/bar में तीन बार होने वाले टेस्ट को छोड़कर //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">
डिफ़ॉल्ट: "अपने-आप"-
एक साथ चलाने के लिए, स्थानीय टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. पूर्णांक लेता है या कीवर्ड ("ऑटो", "होस्ट_सीपीएस"), वैकल्पिक रूप से इसके बाद कार्रवाई ([-|**]<फ़्लो>) लगता है "auto", "Host_CPUS*.5". 0 का मतलब है कि स्थानीय संसाधन, स्थानीय टेस्ट जॉब की संख्या को सीमित कर देंगे. इसके बजाय, वे एक साथ काम करेंगे. इसे -- --नौकरी के लिए वैल्यू से ज़्यादा सेट करने पर कोई असर नहीं पड़ता.
टैग:execution
--[no]test_keep_going
डिफ़ॉल्ट: "सही"-
बंद होने पर, अगर कोई जांच पास नहीं होती है, तो पूरा बिल्ड बंद हो जाएगा. डिफ़ॉल्ट रूप से सभी टेस्ट किए जाते हैं, भले ही कुछ टेस्ट पास न हुए हों.
टैग:execution
--test_strategy=<a string>
डिफ़ॉल्ट: ""-
यह बताता है कि जांच करते समय किस रणनीति का इस्तेमाल करना चाहिए.
टैग:execution
--test_tmpdir=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- यह 'बेज़ल टेस्ट' के लिए आधार अस्थायी डायरेक्ट्री तय करता है.
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
--allow_yanked_versions=<a string>
बार कई बार इस्तेमाल किया गया-
मॉड्यूल वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर बताया गया है, जिसे रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में अनुमति दी जाएगी, भले ही वे रजिस्ट्री में याक के तौर पर सेट किए गए हों (अगर वे NonRegistryOverride से नहीं आ रहे हों). अगर ऐसा नहीं है, तो याक किए गए वर्शन की वजह से रिज़ॉल्यूशन काम नहीं करेगा. आप `BZLMOD_ALLOW_YANKED_VersionS` परिवेश वैरिएबल के साथ, मंज़ूर किया गया याक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (इसका सुझाव नहीं दिया जाता).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Ba आवाज़ मॉड्यूल के बेज़ल वर्शन के साथ काम करने की सुविधा की जांच करें. मान्य वैल्यू 'गड़बड़ी' है. इसे समस्या की पहचान नहीं करने पर, जांच करने की अनुमति नहीं दी जाती. इसके अलावा, `चेतावनी` दिखाने के लिए, `गड़बड़ी` की जानकारी दी जाती है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
देखें कि रूट मॉड्यूल में तय की गई डायरेक्ट `bazel_dep` डिपेंडेंसी, वही वर्शन हैं जो समाधान किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. सही वैल्यू न होने पर, जांच को बंद करने के लिए `बंद करें` पर सेट किया जाता है. ऐसा न होने पर चेतावनी मिलने पर उसे `चेतावनी` देने के लिए सेट किया जाता है.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो Baze ध्यान दें कि अगर MODULE.bazel में यह डेवलपर डिपेंडेंसी है, तो ध्यान न दें कि यह फ़्लैग मॉड्यूल की वैल्यू पर ध्यान दिए बिना रूट मॉड्यूल है या नहीं.
टैग:loading_and_analysis
--lockfile_mode=<off, update or error>
डिफ़ॉल्ट: "बंद" है-
यह बताता है कि लॉकफ़ाइल का इस्तेमाल कैसे करना है या नहीं. लॉकफ़ाइल का इस्तेमाल करने के लिए मान्य मान `अपडेट` होते हैं. साथ ही, अगर लॉकफ़ाइल इस्तेमाल करने के लिए उनमें कोई गड़बड़ी होती है, तो उन्हें अपडेट किया जाता है. साथ ही, अगर वे अप-टू-डेट नहीं हैं या फिर उन्हें लॉकफ़ाइल से पढ़ना या लिखना नहीं है, तो गड़बड़ी होती है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई बार इस्तेमाल किया गया- मॉड्यूल को स्थानीय पाथ से <module name>=<path> के तौर पर बदलें. अगर दिया गया पाथ एक पूरा पाथ है, तो इसे इसी तरह इस्तेमाल किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से है. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `bazel info workspace` का आउटपुट है
--registry=<a string>
बार कई बार इस्तेमाल किया गया-
यह, रजिस्ट्री को बताता है कि इसका इस्तेमाल Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किया जाए. क्रम अहम है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा और बाद की रजिस्ट्री में तब दिखेगा, जब वे पिछली रजिस्ट्री से छूट जाएंगी.
टैग:changes_inputs
- ऐसे विकल्प जो बिल्ड टाइम के ऑप्टिमाइज़ेशन को ट्रिगर करते हैं:
--experimental_gc_thrashing_limits=<comma separated pairs of <period>:<count>>
डिफ़ॉल्ट: ""-
सीमाएं, अगर उन तक पहुंचा जाता है, तो GcTharaishDetecter ने OOM के साथ Bazel को बंद कर दिया. हर सीमा को <period>:<count> के तौर पर बताया गया है, जहां अवधि एक अवधि और गिनती एक धनात्मक पूर्णांक होती है. <period> में लगातार एक साथ काम करने वाले <count> पूरे जीसी के बाद, अवधि के लिए इस्तेमाल किए गए स्पेस का कितना हिस्सा, {2}experimental_oom_more_eagerly_threshold प्रतिशत से ज़्यादा होता है. एक से ज़्यादा सीमाएं, कॉमा की मदद से अलग की जा सकती हैं.
टैग:host_machine_resource_optimizations
--[no]gc_thrashing_limits_retained_heap_limiter_mutually_exclusive
डिफ़ॉल्ट: "सही"-
अगर सही है, तो खाली --experimental_gc_thraish_limits के बारे में बताने से, बरकरार रखे गए Heaplimiter को बंद कर दिया जाता है, ताकि यह GcThrishDetecter के साथ मिलकर काम कर सके. गलत पर सेट करने से, दोनों एक ही निर्देश के लिए चालू रहते हैं.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_full_gc_drops_per_invocation=<an integer, >= 0>
डिफ़ॉल्ट: "2147483647"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बज़ल को पता चलता है कि उसके हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो पूरा GC इवेंट होने पर, वह ज़रूरत के मुताबिक स्काईफ़्रेम स्थिति में कई बार छूट देगा. डिफ़ॉल्ट रूप से Integer.MAX_VALUE डिफ़ॉल्ट तौर पर अनलिमिटेड होता है. शून्य का मतलब है कि GC के पूरे इवेंट में कभी भी कमी नहीं होगी. अगर सीमा पूरी हो जाती है, तो किसी पूरी GC इवेंट के होने पर Skyframe की स्थिति में गिरावट नहीं आएगी. साथ ही, हीप हीप के प्रतिशत की तय सीमा भी पार हो जाएगी.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_minor_gc_drops_per_invocation=<an integer, >= 0>
डिफ़ॉल्ट: "2147483647"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बैजल को पता चलता है कि उसके हीप प्रतिशत का इस्तेमाल --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो एक छोटा GC इवेंट होने पर, वह ज़रूरत के मुताबिक स्काईफ़्रेम स्थिति को कई बार छोड़ देगा. हालांकि, शुरू करने पर कई बार ऐसा होगा. डिफ़ॉल्ट रूप से Integer.MAX_VALUE डिफ़ॉल्ट तौर पर अनलिमिटेड होता है. शून्य का मतलब है कि GC के छोटे इवेंट में कभी भी गिरावट नहीं होगी. अगर सीमा पूरी हो जाती है, तो किसी छोटे GC इवेंट के ट्रिगर होने पर, Skyframe की स्थिति को कम नहीं किया जाएगा. साथ ही, हीप हीप के प्रतिशत की सीमा पार हो जाएगी.
टैग:host_machine_resource_optimizations
--skyframe_high_water_mark_threshold=<an integer>
डिफ़ॉल्ट: "85"-
Bazel के इंटरनल स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग. अगर बेज़ल को लगता है कि उसके रखरखाव वाले हीप प्रतिशत का इस्तेमाल कम से कम इस सीमा तक है, तो वह कुछ समय के लिए स्काईफ़्रेम की गैर-ज़रूरी स्थिति में नहीं आएगा. इसे बदलने से, जीसी थ्रॉशिंग के असर को कम किया जा सकता है. हालांकि, जीसी थ्रैशिंग की वजह से, (i) इस अस्थायी स्थिति की मेमोरी का इस्तेमाल करना और (ii) राज्य की ज़रूरत के हिसाब से उसे दोबारा बनाना काफ़ी महंगा पड़ता है.
टैग:host_machine_resource_optimizations
- ऐसे विकल्प जो बोली की जानकारी, फ़ॉर्मैट, या जगह की जानकारी पर असर डालते हैं:
--[no]announce
डिफ़ॉल्ट: "गलत"-
अब सेवा में नहीं है. नहीं.
टैग:affects_outputs
--[no]debug_spawn_scheduler
डिफ़ॉल्ट: "गलत"--[no]experimental_bep_target_summary
डिफ़ॉल्ट: "गलत"- टारगेट की गई खास जानकारी वाले इवेंट प्रकाशित करने हैं या नहीं.
--[no]experimental_build_event_expand_filesets
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में Filesसेट को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "गलत"-
सही होने पर, आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी के मिलते-जुलते 'फ़ाइलसेट' सिमलिंक का पूरी तरह से समाधान करें. --experimental_build_event_expand_filessets की ज़रूरत है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
Bez को बिल्ड इवेंट को फिर से अपलोड करने की कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
डिफ़ॉल्ट: "1s"-
बीईपी अपलोड नहीं हो पाने पर, एक्सपोनेंशियल बैकऑफ़ बार-बार कोशिश करने पर लगने वाला कम से कम समय. (एक्सपोनेंट: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह पेज, बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुनता है.
टैग:affects_outputs
--[no]experimental_collect_local_sandbox_action_metrics
डिफ़ॉल्ट: "सही"-
चालू होने पर, सैंडबॉक्स की सुविधा का इस्तेमाल करने वाली स्थानीय कार्रवाइयों के लिए, चलाने का तरीका (जैसे कि उपयोगकर्ता और सिस्टम का समय) रिकॉर्ड किया जाता है
टैग:execution
--[no]experimental_command_profile
डिफ़ॉल्ट: "गलत"- Java में मौजूद फ़्लाइट रिकॉर्डर की प्रोफ़ाइल प्रोफ़ाइल को आउटपुट बेस डायरेक्ट्री में मौजूद किसी file.jfr में रिकॉर्ड करता है. इस फ़्लैग का सिंटैक्स और सिमेंटिक अलग-अलग तरह के प्रोफ़ाइल टाइप या आउटपुट फ़ॉर्मैट के साथ काम करने के लिए, आने वाले समय में बदल सकता है. अपने जोखिम पर इसका इस्तेमाल करें.
--[no]experimental_docker_verbose
डिफ़ॉल्ट: "गलत"-
इसके चालू होने पर, Bazel, डॉकर सैंडबॉक्स की रणनीति के बारे में ज़्यादा शब्दों में मैसेज प्रिंट करेगा.
टैग:execution
--[no]experimental_materialize_param_files_directly
डिफ़ॉल्ट: "गलत"-
अगर पैरामीटर की फ़ाइलों को मटीरियल से हटाया जा रहा है, तो सीधे डिस्क में जाकर ऐसा करें.
टैग:execution
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई टाइप की संख्या 20 वर्ण के ज़्यादा होती है. इसे लागू करने के लिए, सबसे ज़्यादा संख्या का इस्तेमाल किया जाता है. इस विकल्प को सेट करने पर सभी शब्दावली के लिए आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो StarLrk का डेटा स्टोर करने के सभी नियमों की जानकारी के साथ, Starlark की वैल्यू लिखें.
टैग:affects_outputs
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "गलत"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय उन्हें सीधे रिमोट स्टोरेज में अपलोड करें.
टैग:affects_outputs
--explain=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड सिस्टम से बिल्ड के हर एक चरण की जानकारी मिलती है. जानकारी बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग:affects_outputs
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
इसका इस्तेमाल करें, ताकि Targetcomplete इवेंट में जानदार लेगसी आउटपुट आउटपुट फ़ील्ड को बंद किया जा सके.
टैग:affects_outputs
--[no]materialize_param_files
डिफ़ॉल्ट: "गलत"-
रिमोट ट्री का इस्तेमाल करके आउटपुट आउटपुट ट्री में भी लिखता है. भले ही, रिमोट ऐक्शन का इस्तेमाल किया जा रहा हो. यह डीबग करने में मदद करता है. यह --सबकॉमैंड्स और --verbose_failures से पता चलता है.
टैग:execution
--max_config_changes_to_show=<an integer>
डिफ़ॉल्ट: "3"-
बिल्ड के विकल्पों में हुए बदलाव की वजह से विश्लेषण कैश को खारिज करने पर, बदले गए विकल्पों के नामों की संख्या दिखती है. अगर दी गई संख्या -1 है, तो सभी बदले गए विकल्प दिखाए जाएंगे.
टैग:terminal_output
- डिफ़ॉल्ट
--max_test_output_bytes=<an integer>
: "-1" -
-टेस्ट लॉग का सबसे बड़ा साइज़ तब तय किया जाता है, जब --test_ आउटपुट 'गड़बड़ी' या 'सभी' हो. इसकी मदद से, बहुत ज़्यादा शोर वाले टेस्ट आउटपुट से, आउटपुट पर पड़ने वाले असर से बचने में मदद मिलती है. टेस्ट हेडर, लॉग साइज़ में शामिल होता है. नकारात्मक मानों की कोई सीमा नहीं है. आउटपुट कुछ भी नहीं है.
टैग:test_runner
,terminal_output
,execution
--output_filter=<a valid Java regular expression>
डिफ़ॉल्ट: ब्यौरा देखें-
सिर्फ़ उन नियमों के लिए चेतावनियां दिखाता है जिनका नाम दिए गए रेगुलर एक्सप्रेशन से मेल खाता है.
टैग:affects_outputs
--progress_report_interval=<an integer in 0-3600 range>
डिफ़ॉल्ट: "0"-
अभी भी चल रही नौकरियों की रिपोर्ट के बीच कुल सेकंड. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट होगी. इसके बाद, 30 सेकंड प्रोसेस होगी और उसके बाद, हर मिनट एक बार रिपोर्ट की जाएगी. जब --कर्सर चालू होते हैं, तो हर सेकंड की प्रोग्रेस रिपोर्ट की जाती है.
टैग:affects_outputs
--remote_print_execution_messages=<failure, success or all>
डिफ़ॉल्ट: "असफलता"-
चुनें कि रिमोट एक्ज़ीक्यूशन मैसेज कब प्रिंट करने हैं. वैल्यू पूरी न होने पर प्रिंट करने के लिए `अचानक`, सिर्फ़ सफलताओं पर प्रिंट करने के लिए 'सफलता', और हमेशा प्रिंट करने के लिए 'सभी' का इस्तेमाल किया जाता है.
टैग:terminal_output
--[no]sandbox_debug
डिफ़ॉल्ट: "गलत"-
सैंडबॉक्स करने की सुविधा के लिए डीबग करने की सुविधाएं चालू करता है. इसमें दो चीज़ें शामिल होती हैं: पहला, सैंडबॉक्स रूट कॉन्टेंट को बिल्ड के बाद नज़रअंदाज़ कर दिया जाता है (और अगर सैंडबॉक्सf इस्तेमाल में है, तो फ़ाइल सिस्टम माउंट किया हुआ रहता है); और दूसरा, एक्ज़ीक्यूशन पर अतिरिक्त डीबगिंग जानकारी प्रिंट करता है. इससे Bazel या Starlark के डेवलपर के लिए यह तय किया जा सकता है कि उनकी इनपुट फ़ाइलें मौजूद न होने की वजह से, डीबग करने में समस्या होगी.
टैग:terminal_output
--show_result=<an integer>
डिफ़ॉल्ट: "1"-
बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए, यह बताएं कि उसे अप-टू-डेट रखा गया था या नहीं. अगर हां, तो बनाई गई आउटपुट फ़ाइलों की सूची. प्रिंट की गई फ़ाइलें शेल में कॉपी+पेस्ट करने के लिए आसान स्ट्रिंग हैं, ताकि उन्हें चलाया जा सके.
इस विकल्प के लिए एक पूर्णांक तर्क होना ज़रूरी है, जो उन टारगेट की थ्रेशोल्ड संख्या होती है जिनके ऊपर नतीजे की जानकारी प्रिंट नहीं की जाती. इसलिए, शून्य होने से मैसेज छिप जाता है. MAX_INT नतीजे को प्रिंट करने की वजह हमेशा होती है. डिफ़ॉल्ट वैल्यू एक होती है.
अगर टारगेट के लिए कुछ भी नहीं बनाया गया है, तो इसके नतीजों को थ्रेशोल्ड के नीचे रखने के लिए नतीजों को हटाया जा सकता है.
टैग:affects_outputs
--[no]subcommands
[-s
] डिफ़ॉल्ट: "गलत"-
बिल्डिंग के दौरान चलाए गए सबकॉमैंड को दिखाएं. इससे जुड़े फ़्लैग: --execution_log_json_file, --execution_log_binary_file (टूल के साथ काम करने वाले फ़ॉर्मैट में फ़ाइल में सबकॉमैंड को लॉग करने के लिए).
टैग:terminal_output
--test_output=<summary, errors, all or streamed>
डिफ़ॉल्ट: "खास जानकारी"-
ज़रूरी आउटपुट मोड के बारे में बताता है. मान्य वैल्यू, सिर्फ़ आउटपुट की जांच की स्थिति की खास जानकारी के लिए 'खास जानकारी' होती हैं. इसमें, जांच न हो पाने वाले टेस्ट लॉग को भी 'गड़बड़ी' के तौर पर प्रिंट किया जाता है. सभी टेस्ट के लिए 'सभी' प्रिंट करें और सभी टेस्ट के लिए, आउटपुट लॉग में 'स्ट्रीम की गई' वैल्यू डालें. इससे, टेस्ट को एक-एक करके स्थानीय तौर पर एक्ज़ीक्यूट किया जाएगा, चाहे --test_strategi वैल्यू कुछ भी हो.
टैग:test_runner
,terminal_output
,execution
--test_summary=<short, terse, detailed, none or testcase>
डिफ़ॉल्ट: "छोटा"-
जांच की खास जानकारी के मनचाहे फ़ॉर्मैट के बारे में बताता है. मान्य वैल्यू, जांचे गए टेस्ट के बारे में जानकारी को प्रिंट करने के लिए 'छोटा' होती हैं. इसके अलावा, जो टेस्ट होते हैं सिर्फ़ उनके बारे में जानकारी को प्रिंट करने के लिए, टेस्ट केस के रिज़ॉल्यूशन को प्रिंट कराने के लिए 'ज़्यादा जानकारी' प्रिंट करें.
टैग:terminal_output
--[no]verbose_explanations
डिफ़ॉल्ट: "गलत"-
अगर --plain की सुविधा चालू हो, तो दिए गए एक्सप्लेनेशंस की जानकारी पाने की सेटिंग में बदलाव किया जाता है. अगर --plain की सुविधा चालू नहीं है, तो कोई असर नहीं पड़ेगा.
टैग:affects_outputs
--[no]verbose_failures
डिफ़ॉल्ट: "गलत"-
अगर कोई निर्देश नहीं मिलता, तो पूरी कमांड लाइन का प्रिंट लें.
टैग:terminal_output
- किसी सामान्य इनपुट के बारे में बताने या उसे बदलने वाले ऐसे विकल्प जो किसी दूसरी कैटगरी में नहीं आते हैं:
--aspects_parameters=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया-
कमांड-लाइन के आसपेक्ट पैरामीटर की वैल्यू तय करता है. हर पैरामीटर वैल्यू, <param_name>=<param_value> के ज़रिए तय की जाती है, उदाहरण के लिए, 'my_param=my_val', जहां 'my_param', पैरामीटर की सूची में कुछ आसपेक्ट पैरामीटर का पैरामीटर है या सूची में मौजूद किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. हालांकि, एक ही पैरामीटर में वैल्यू एक से ज़्यादा बार असाइन करने की अनुमति नहीं है.
टैग:loading_and_analysis
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय बताई गई समाधान की गई फ़ाइल पढ़ें
टैग:changes_inputs
--target_pattern_file=<a string>
डिफ़ॉल्ट: ""-
अगर सेट किया जाता है, तो बिल्ड, कमांड लाइन के बजाय यहां बताई गई फ़ाइल से पैटर्न को पढ़ेगा. यहां फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न बताने में कोई गड़बड़ी हुई.
टैग:changes_inputs
- रिमोट कैश मेमोरी और एक्ज़ीक्यूशन के विकल्प:
--experimental_circuit_breaker_strategy=<failure>
डिफ़ॉल्ट: ब्यौरा देखें-
यह सर्किट ब्रेकर के इस्तेमाल की रणनीति तय करता है. उपलब्ध रणनीतियां "असफल" हैं. विकल्प के लिए अमान्य वैल्यू पर, विकल्प जैसा सेट नहीं किया गया है.
टैग:execution
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में कई लाइनें होती हैं. इनमें से हर एक के साथ एक डायरेक्टिव होता है (`allow`, `block` या `rewrite`). इसके बाद होस्ट का नाम होता है (`allow` या `block`) या दो पैटर्न होते हैं, एक मेल खाने वाला होता है, और वैकल्पिक यूआरएल के रूप में इस्तेमाल करने के लिए, जिसमें$1 से शुरू होता है. एक ही यूआरएल के लिए एक से ज़्यादा `rewrite` डायरेक्टिव देना संभव है. इस मामले में, एक से ज़्यादा यूआरएल देना.
--[no]experimental_guard_against_concurrent_changes
डिफ़ॉल्ट: "गलत"- किसी कार्रवाई को रिमोट कैश में अपलोड करने से पहले, इनपुट फ़ाइलों के समय की जांच को बंद करने के लिए इसे बंद करें. ऐसे मामले भी हो सकते हैं, जहां Linux कर्नेल, फ़ाइलों को लिखने में देरी करता है. इस वजह से फ़ॉल्स पॉज़िटिव बदलाव मिल सकते हैं.
--[no]experimental_remote_cache_async
डिफ़ॉल्ट: "गलत"- अगर यह सही है, तो रिमोट कैश I/O का इस्तेमाल, प्रॉपर्टी के किसी हिस्से के तौर पर होने के बजाय, बैकग्राउंड में होगा.
--experimental_remote_cache_eviction_retries=<an integer>
डिफ़ॉल्ट: "0"-
अगर बिल्ड को कैश मेमोरी में सेव करने से जुड़ी गड़बड़ी हुई है, तो फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. कोई गैर-शून्य मान, निहित रूप से सही सेट किया जाएगा --insupported_remote_use_new_exit_code_for_lost_inputs.
टैग:execution
--experimental_remote_cache_ttl=<An immutable length of time.>
डिफ़ॉल्ट: "3 घंटे"-
हाल ही में इकट्ठा किए गए TTL (टीटीएल) की गारंटी, रिमोट कैश में दी जाती है.ऐसा तब होता है, जब आपके डाइजेस्ट का हाल ही में रेफ़रंस दिया गया हो. उदाहरण के लिए, ActionAction या FindMissingBlobs. Bazel, BLOBs की TTL (टीटीएल) के मुताबिक कई ऑप्टिमाइज़ेशन करता है. उदाहरण के लिए, यह बढ़ोतरी वाले बिल्ड में GetActionResult को बार-बार कॉल नहीं करता है. वैल्यू को असली TTL (टीटीएल) से थोड़ा कम सेट करना चाहिए. ऐसा इसलिए, क्योंकि सर्वर से डाइजेस्ट मिलने के बाद, और Bazel उन्हें मिलने के बीच एक अंतर होता है.
टैग:execution
--experimental_remote_capture_corrupted_outputs=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- ऐसी डायरेक्ट्री का पाथ जहां खराब आउटपुट कैप्चर किए जाएंगे.
--[no]experimental_remote_discard_merkle_trees
डिफ़ॉल्ट: "गलत"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो getActionResult() और Execute() में कॉल के दौरान, इनपुट रूट के Merkle ट्री और उससे जुड़े इनपुट मैपिंग की कॉपी को खारिज करें. इससे मेमोरी के इस्तेमाल में काफ़ी कमी आती है, लेकिन दूर की कैश मेमोरी से जगह खाली करने और फिर से कोशिश करने पर Bazel उन्हें दोबारा जांचता है.
--experimental_remote_downloader=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट एसेट एपीआई यूआरआई, जिसे रिमोट डाउनलोड प्रॉक्सी के तौर पर इस्तेमाल किया जा सकता है. इन स्कीमा में grpc, grpcs, (TLS के साथ grpc) और Unix (स्थानीय UNIX सॉकेट) शामिल हैं. अगर कोई स्कीमा नहीं दिया गया है, तो Bazel, डिफ़ॉल्ट तौर पर grpcs का इस्तेमाल करेगा. देखें: https://github.com/bazelbuild/remote-apis/blob/Master/build/bazel/remote/asset/v1/remote_asset.proto
--[no]experimental_remote_downloader_local_fallback
डिफ़ॉल्ट: "गलत"- अगर रिमोट डाउनलोड करने की सुविधा काम नहीं करती, तो स्थानीय डाउनलोडर पर वापस जाएं या नहीं.
--[no]experimental_remote_execution_keepalive
डिफ़ॉल्ट: "गलत"- रिमोट एक्ज़ीक्यूशन कॉल के लिए, कीपअलाइव का इस्तेमाल करना है या नहीं.
--experimental_remote_failure_rate_threshold=<an integer in 0-100 range>
डिफ़ॉल्ट: "10"-
किसी खास समयावधि के लिए, गड़बड़ी की दर के इस्तेमाल की अनुमति वाली संख्या को प्रतिशत में सेट करती है. इसके बाद, रिमोट कैश/एक्ज़ीक्यूटर को कॉल करना बंद कर देती है. डिफ़ॉल्ट रूप से, वैल्यू 10 होती है. इसे 0 पर सेट करने का मतलब कोई सीमा नहीं है.
टैग:execution
--experimental_remote_failure_window_interval=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"-
वह अंतराल जिसमें रिमोट अनुरोधों की गड़बड़ी की दर का हिसाब लगाया जाता है. शून्य या नेगेटिव मान में, फ़ेलियर अवधि का हिसाब लगाने की प्रक्रिया की पूरी अवधि का हिसाब लगाया जाता है.इस यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s) और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो मान को सेकंड में समझा जाता है.
टैग:execution
--[no]experimental_remote_mark_tool_inputs
डिफ़ॉल्ट: "गलत"- अगर सही पर सेट है, तो Bazel, रिमोट एक्ज़ीक्यूटर के लिए इनपुट इनपुट के तौर पर इनपुट दिखाएगा. इसका इस्तेमाल दूर से लगातार काम करने वाले वर्कर को लागू करने के लिए किया जा सकता है.
--[no]experimental_remote_merkle_tree_cache
डिफ़ॉल्ट: "गलत"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो रिमोट कैश हिट को जांचने की स्पीड को बेहतर बनाने के लिए, Merkle ट्री (डेटा की गणना करने की सुविधा) से जुड़े कैलकुलेशन को मैप किया जाएगा. कैश मेमोरी में मौजूद मेमोरी फ़ुट फ़ुट को --experimental_remote_merkle_tree_cache_size से कंट्रोल किया जाता है.
--experimental_remote_merkle_tree_cache_size=<a long integer>
डिफ़ॉल्ट: "1000"- Merkle के पेड़ों की संख्या, जिनसे कैश मेमोरी में सेव किए गए हिट की जांच की रफ़्तार बेहतर हो गई. हालांकि, सॉफ़्ट रेफ़रंस के तौर पर इस्तेमाल किए जा रहे Java डेटा को कैश मेमोरी में अपने-आप फ़िल्टर कर दिया जाता है. हालांकि, मेमोरी बहुत ज़्यादा होने पर ऐसा हो सकता है कि मेमोरी में गड़बड़ी हो. अगर इसे 0 पर सेट किया जाता है, तो कैश मेमोरी का साइज़ अनलिमिटेड होता है. प्रोजेक्ट की साइज़ के हिसाब से, ऑप्टिमल वैल्यू अलग-अलग होती है. डिफ़ॉल्ट संख्या 1000 है.
--experimental_worker_for_repo_fetching=<off, platform or virtual>
डिफ़ॉल्ट: "बंद" है- रीपो फ़ेच करने के लिए इस्तेमाल किया जाने वाला थ्रेडिंग मोड. अगर यह 'बंद है' पर सेट है, तो किसी वर्कर थ्रेड का इस्तेमाल नहीं किया जाता है. इसके अलावा, रेपो फ़ेच को रीस्टार्ट किया जाता है. अगर ऐसा नहीं है, तो 'प्लैटफ़ॉर्म' पर सेट होने पर 'प्लैटफ़ॉर्म थ्रेड' या 'वर्चुअल' पर सेट होने पर वर्चुअल थ्रेड का इस्तेमाल करें.
--[no]incompatible_remote_build_event_upload_respect_no_cache
डिफ़ॉल्ट: "गलत"- अब सेवा में नहीं है. नहीं. इसके बजाय --remote_build_event_upload=minimal का इस्तेमाल करें.
--[no]incompatible_remote_disallow_symlink_in_tree_artifact
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो रिमोट तरीके से की गई कार्रवाई में, ऐसा मिलता-जुलता ट्री आर्टफ़ैक्ट नहीं बनाया जा सकता जिसमें मिलते-जुलते सिमलिंक हों. हालांकि, इस फ़्लैग के बावजूद, पूरे सिमलिंक की अनुमति नहीं है.
टैग:execution
,incompatible_change
--[no]incompatible_remote_downloader_send_all_headers
डिफ़ॉल्ट: "सही"-
कई वैल्यू वाले हेडर की सभी वैल्यू, पहले वाले के बजाय रिमोट डाउनलोडर पर ही भेजें.
टैग:incompatible_change
--[no]incompatible_remote_output_paths_relative_to_input_root
डिफ़ॉल्ट: "गलत"-
सही पर सेट होने पर, आउटपुट पाथ काम करने वाली डायरेक्ट्री के बजाय इनपुट रूट से मिलते-जुलते हैं.
टैग:incompatible_change
--[no]incompatible_remote_results_ignore_disk
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो डिस्क कैश पर --noremote_upload_local_results और --noremote_ accepted_cached लागू नहीं होगा. --disk_cache और --remote_cache, (संयुक्त कैश) सेट किए जाने पर:
--noremote_upload_local_results परिणामों को डिस्क कैश पर लिखा जाएगा, लेकिन दूरस्थ कैश पर अपलोड नहीं किया जाएगा.
--noremote_Acceptable_cached का नतीजा यह होगा कि Bazel, डिस्क कैश में नतीजों की जांच करेगा, लेकिन रिमोट कैश में नहीं.
रिमोट-एक्ज़ीक्यूट नहीं किया जा सकता, तो डिस्क की कैश मेमोरी पर असर पड़ सकता है.
ज़्यादा जानकारी के लिए #8216 देखें.
टैग:incompatible_change
--[no]incompatible_remote_use_new_exit_code_for_lost_inputs
डिफ़ॉल्ट: "सही"-
अगर वैल्यू 'सही' पर सेट है, तो बिल्ड 34 के बजाय नए एग्ज़िट कोड 39 का इस्तेमाल करेगा. ऐसा तब होगा, जब रिमोट कैश बिल्ड के दौरान ब्लॉब को हटा दे.
टैग:incompatible_change
--[no]remote_accept_cached
डिफ़ॉल्ट: "सही"- क्या आपको दूसरी जगह से कैश मेमोरी में सेव की गई कार्रवाई के नतीजे स्वीकार करने हैं.
--remote_build_event_upload=<all or minimal>
डिफ़ॉल्ट: "कम से कम"- अगर इसे 'सभी' पर सेट किया जाता है, तो BEP से रेफ़र किए गए सभी लोकल आउटपुट, रिमोट कैश मेमोरी में अपलोड किए जाते हैं. 'कम से कम' पर सेट किए जाने पर, BEP से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश में अपलोड नहीं किए जाते हैं.इनमें BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलें शामिल हैं. उदाहरण के लिए, टेस्ट लॉग और समय वाली प्रोफ़ाइल. बाइटस्ट्रीम:// स्कीम का इस्तेमाल हमेशा फ़ाइलों के यूआरआई के लिए किया जाता है, भले ही वे रिमोट कैश के न हों. 'कम से कम' पर डिफ़ॉल्ट रूप से सेट है.
--remote_bytestream_uri_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- बाइट नाम और इंस्टेंस का नाम, बाइटस्ट्रीम:// यूआरआई में इस्तेमाल किया जाना चाहिए, जिसे इवेंट स्ट्रीम बनाने के लिए लिखा जाता है. यह विकल्प तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इस वजह से --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती. अगर यह नीति सेट नहीं की जाती, तो डिफ़ॉल्ट रूप से इसका फ़ॉर्मैट {0}${hostname}/${instance_name}" होगा.
--remote_cache=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- कैश मेमोरी में सेव होने वाले एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS के साथ TLS चालू), और यूनिक्स (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया गया है, तो Bazel, डिफ़ॉल्ट तौर पर grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए grpc://, http:// या unix: स्कीमा की जानकारी दें. https://bazel.build/remote/caching पर क्लिक करें
--[no]remote_cache_compression
डिफ़ॉल्ट: "गलत"- चालू होने पर, zstd के साथ कैश ब्लॉब को कंप्रेस/डिप्रेस करें.
--remote_cache_header=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया- ऐसा हेडर डालें जो कैश मेमोरी के अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को एक से ज़्यादा बार बताने पर, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल जाएंगी.
--remote_default_exec_properties=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया-
अगर कोई एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_property को सेट नहीं करता है, तो डिफ़ॉल्ट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए डिफ़ॉल्ट exec प्रॉपर्टी सेट करें.
टैग:affects_outputs
--remote_default_platform_properties=<a string>
डिफ़ॉल्ट: ""- डिफ़ॉल्ट स्क्रिप्ट प्रॉपर्टी को रिमोट एक्ज़ीक्यूशन एपीआई के लिए सेट करें. हालांकि, अगर लागू करने वाला प्लैटफ़ॉर्म पहले से Remote_execution_property को सेट नहीं करता है, तो उसे सेट कर दें. इस वैल्यू का इस्तेमाल तब भी किया जाएगा, जब रिमोट प्लैटफ़ॉर्म के लिए एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर होस्ट प्लैटफ़ॉर्म को चुना गया हो.
--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>
डिफ़ॉल्ट: ब्यौरा देखें- होस्ट या रिमोट:एक्ज़ीक्यूशन एंडपॉइंट का पोर्ट. इन स्कीमा में grpc, grpcs, (TLS के साथ grpc) और Unix (स्थानीय UNIX सॉकेट) शामिल हैं. अगर कोई स्कीमा नहीं दिया गया है, तो Bazel, डिफ़ॉल्ट तौर पर grpcs का इस्तेमाल करेगा. TLS को बंद करने के लिए grpc:// या unix: स्कीमा डालें.
--remote_grpc_log=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- अगर इस फ़ील्ड को सेट किया गया है, तो फ़ाइल का पाथ, gRPC कॉल से जुड़ी जानकारी लॉग करने में मदद करता है. इस लॉग में, क्रम के हिसाब से com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry प्रोटोबफ़ का क्रम होता है. हर क्रम में यह मैसेज, वैरिएंट वाले मैसेज से शुरू होता है, जैसा कि LogEntry.writeDelimitedTo(InputStream) तरीके से किया जाता है.
--remote_header=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया- ऐसा हेडर डालें जिसे अनुरोधों में शामिल किया जाएगा: --remote_header=Name=Value. फ़्लैग को एक से ज़्यादा बार बताने पर, एक से ज़्यादा हेडर पास किए जा सकते हैं. एक ही नाम की कई वैल्यू, कॉमा लगाकर अलग की गई सूची में बदल जाएंगी.
--remote_instance_name=<a string>
डिफ़ॉल्ट: ""- रिमोट एक्ज़ीक्यूशन एपीआई में इंस्टेंस_नाम के तौर पर पास करने के लिए वैल्यू.
--[no]remote_local_fallback
डिफ़ॉल्ट: "गलत"- रिमोट एक्ज़ीक्यूशन नहीं होने पर, क्या किसी लोकल एक्ज़ीक्यूशन की रणनीति पर वापस जाना है या नहीं.
--remote_local_fallback_strategy=<a string>
डिफ़ॉल्ट: "स्थानीय"- नहीं, नहीं. ज़्यादा जानकारी पाने के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.
--remote_max_connections=<an integer>
डिफ़ॉल्ट: "100"-
रिमोट कैश/एक्ज़ीक्यूटर के साथ, एक साथ ज़्यादा से ज़्यादा कितने कनेक्शन हो सकते हैं, इसकी सीमा तय करें. डिफ़ॉल्ट रूप से यह वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब कोई सीमा नहीं है.
एचटीटीपी रिमोट कैश के लिए, एक बार में एक टीसीपी कनेक्शन से ही एक अनुरोध को पूरा किया जा सकता है. इसलिए, Bazel, --remote_max_connections एक साथ किए जाने वाले अनुरोधों को पूरा कर सकता है.
gRPC रिमोट कैश/एक्ज़ीक्यूटर के लिए, आम तौर पर एक gRPC चैनल 100 से ज़्यादा अनुरोधों को हैंडल कर सकता है, ताकि Bazel करीब-करीब `--remote_max_connections * 100` अनुरोध कर सकता है.
टैग:host_machine_resource_optimizations
--remote_proxy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- प्रॉक्सी के ज़रिए रिमोट कैश से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ यूनिक्स डोमेन सॉकेट (unix:/path/to/socket) को कॉन्फ़िगर करने के लिए किया जा सकता है.
--remote_result_cache_priority=<an integer>
डिफ़ॉल्ट: "0"- रिमोट कैश मेमोरी में सेव की जाने वाली दूर से की जाने वाली कार्रवाइयों की प्राथमिकता. खास प्राथमिकता की वैल्यू के सिमैंटिक, सर्वर पर निर्भर होते हैं.
--remote_retries=<an integer>
डिफ़ॉल्ट: "5"- कुछ समय के लिए दिखने वाली गड़बड़ी से जुड़ी फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो दोबारा कोशिश नहीं की जा सकती.
--remote_retry_max_delay=<An immutable length of time.>
डिफ़ॉल्ट: "5s"- रिमोट की फिर से कोशिश करने के बीच ज़्यादा से ज़्यादा बैकऑफ़ देरी. इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो मान को सेकंड में समझा जाता है.
--remote_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"- रिमोट और कैश मेमोरी से जुड़े कॉल के लिए इंतज़ार का ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट करने और पढ़ने का टाइम आउट, दोनों होता है. इन यूनिट का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (ms). अगर इकाई को छोड़ दिया जाता है, तो मान को सेकंड में समझा जाता है.
--[no]remote_upload_local_results
डिफ़ॉल्ट: "सही"- अगर रिमोट कैश का इस्तेमाल किया जा सकता है और उपयोगकर्ता ऐसा कर सकता है, तो रिमोट तरीके से बनाई गई कार्रवाई के नतीजों को रिमोट कैश में अपलोड करें या नहीं.
--[no]remote_verify_downloads
डिफ़ॉल्ट: "सही"- अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Bazel, रिमोट तरीके से डाउनलोड की गई सभी वैल्यू के हैश की गिनती करेगा. अगर ये वैल्यू उम्मीद के मुताबिक नहीं होती हैं, तो ये हैश किए गए वैल्यू को खारिज कर देते हैं.
- ऐसे अन्य विकल्प जिन्हें कैटगरी में नहीं बांटा गया है.:
--auto_output_filter=<none, all, packages or subpackages>
डिफ़ॉल्ट: "कोई नहीं"- ---आउटपुट_फ़िल्टर तय नहीं होने पर, इस विकल्प की वैल्यू का इस्तेमाल करके अपने-आप एक फ़िल्टर बन जाता है. इन वैल्यू में 'कोई नहीं' ('सब कुछ फ़िल्टर करें / सब कुछ दिखाएं'), 'सभी' (सब कुछ फ़िल्टर करें / कुछ न दिखाएं), 'पैकेज' (ब्लेज़ कमांड लाइन पर बताए गए पैकेज से जुड़े आउटपुट शामिल हैं), और सब-पैकेज (जैसे कि 'पैकेज') भी शामिल हैं. 'पैकेज' और 'सबपैकेज' वैल्यू के लिए //java/foo और //javatests/foo को एक पैकेज माना जाता है)'.
--[no]build_manual_tests
डिफ़ॉल्ट: "गलत"- ऐसे टेस्ट टारगेट जिन्हें हर हाल में 'मैन्युअल' के तौर पर टैग किया जाता है. 'मैन्युअल' जांच को प्रोसेस नहीं किया जाता. यह विकल्प उन्हें बनाने के लिए मजबूर करता है (लेकिन चलाया नहीं जाता).
--build_tag_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- कॉमा लगाकर अलग किए गए टैग की सूची के बारे में बताता है. बाहर रखे गए टैग की जानकारी देने के लिए, हर टैग के पहले '-' का इस्तेमाल किया जा सकता है. सिर्फ़ ऐसे टारगेट बनाए जाएंगे जिनमें शामिल कम से कम एक टैग शामिल होगा और उसमें कोई बाहर रखा गया टैग नहीं होगा. इस विकल्प से 'टेस्ट' निर्देश के साथ किए गए टेस्ट के सेट पर कोई असर नहीं पड़ता. ये जांच करने के विकल्पों पर लागू होते हैं, उदाहरण के लिए '--test_tag_filters
--[no]build_tests_only
डिफ़ॉल्ट: "गलत"- अगर बताया गया है, तो सिर्फ़ कमांड लाइन पर दिए गए *_test और test_suite नियमों को अनदेखा किया जाएगा. डिफ़ॉल्ट तौर पर, वह सब कुछ बना दिया जाएगा जिसका अनुरोध किया गया था.
--combined_report=<none or lcov>
डिफ़ॉल्ट: "कोई नहीं"- सुविधा के हिसाब से तैयार की गई कवरेज की खास तरह की रिपोर्ट के बारे में बताती है. इस समय सिर्फ़ LCOV ही काम करता है.
--[no]compile_one_dependency
डिफ़ॉल्ट: "गलत"- आर्ग्युमेंट फ़ाइलों का एक डिपेंडेंसी कंपाइल करें. यह, आईडीई में मौजूद सोर्स फ़ाइलों की सिंटैक्स जांच के लिए फ़ायदेमंद है. उदाहरण के लिए, एक ही टारगेट को फिर से बनाकर जो सोर्स फ़ाइल पर निर्भर होता है. इससे, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाया जा सकता है. यह आर्ग्युमेंट, सभी नॉन-फ़्लैग आर्ग्युमेंट के बारे में जानकारी देने के तरीके पर असर डालते हैं. हालांकि, ये टारगेट फ़ाइल बनने के बजाय सोर्स फ़ाइल नाम हैं. हर सोर्स फ़ाइल नाम के लिए, एक आर्बिट्रेरी टारगेट बनाया जाएगा जो इस पर निर्भर करेगा.
--deleted_packages=<comma-separated list of package names>
बार कई बार इस्तेमाल किया गया- उन पैकेज के नामों की कॉमा-सेपरेटेड लिस्ट होती है जिन्हें बिल्ड सिस्टम मौजूद नहीं मानता है, भले ही वे पैकेज पाथ पर कहीं भी दिख रहे हों. किसी मौजूदा पैकेज 'x' का सब-पैकेज 'x/y' मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट के x/y/BUILD को मिटाने के बाद, अगर यह अब भी किसी दूसरी package_path एंट्री से लेबल '//x:y/z' मिलता है, तो बिल्ड सिस्टम शिकायत कर सकता है. --delete_packages x/y बताने से यह समस्या हल नहीं होगी.
--[no]discard_analysis_cache
डिफ़ॉल्ट: "गलत"- विश्लेषण के चरण के खत्म होने के तुरंत बाद, विश्लेषण को खारिज करें. मेमोरी का इस्तेमाल ~10% तक कम करता है, लेकिन धीरे-धीरे बढ़ता है.
--disk_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जहां बेज़ल, कार्रवाइयों और कार्रवाई के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.
--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>
डिफ़ॉल्ट: ब्यौरा देखें- इस फ़ाइल में लागू स्पान को लॉग इन करें और डिलिमिटेड स्पैन वाले प्रोटो को JSON के तौर पर दिखाएं. ऐसा src/main/protobuf/spawn.proto के मुताबिक किया गया है. लॉग को सबसे पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, शुरू करने के आखिर में, एक स्टेबल ऑर्डर के हिसाब से क्रम में लगाया जाता है. यह सीपीयू और मेमोरी का इस्तेमाल करने में ज़्यादा समय ले सकता है. मिलते-जुलते फ़्लैग: मिलते-जुलते फ़्लैग: --execution_log_binary_file (ऑर्डर किया गया बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --experimental_execution_log_file (ऑर्डर नहीं किया गया बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकॉमैंड दिखाने के लिए).
--[no]execution_log_sort
डिफ़ॉल्ट: "सही"- एक्ज़ीक्यूशन लॉग को क्रम से लगाना है या नहीं. लॉग को अनिश्चित समय के लिए बनाने की लागत पर, मेमोरी की परफ़ॉर्मेंस को बेहतर बनाने के लिए, इसे 'गलत' पर सेट किया जाता है.
--[no]expand_test_suites
डिफ़ॉल्ट: "सही"-
विश्लेषण से पहले, test_suite टारगेट को उनके कॉम्पोनेंट की जांच में शामिल करें. जब यह फ़्लैग चालू होता है (डिफ़ॉल्ट), तो टेस्ट सुइट से जुड़े टेस्ट पर नेगेटिव टारगेट पैटर्न लागू होंगे. ऐसा नहीं करने पर ऐसा नहीं होगा. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड-लेवल आसपेक्ट को कमांड लाइन पर लागू किया जाता है. इसके बाद, ये test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग:loading_and_analysis
--experimental_dynamic_ignore_local_signals=<a comma-separated list of signal numbers>
डिफ़ॉल्ट: ब्यौरा देखें-
यह ओएस सिग्नल नंबर की सूची लेता है. अगर इनमें से किसी भी सिग्नल की मदद से डाइनैमिक ब्रांच को स्थानीय तौर पर चालू किया जाता है, तो रिमोट ब्रांच को काम पूरा करने की अनुमति मिल जाएगी. स्थायी वर्कर के लिए, इससे सिर्फ़ वे सिग्नल प्रभावित होते हैं जो वर्कर प्रोसेस को मारते हैं.
टैग:execution
--experimental_execution_log_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- इस फ़ाइल में दिखाए गए स्पान को src/main/protobuf/spawn.proto के मुताबिक, डीलिमिटेड स्पॉन प्रोटो के तौर पर लॉग करें. यह फ़ाइल स्पान एक्ज़ीक्यूशन के क्रम में लिखी गई है. मिलते-जुलते फ़्लैग: --execution_log_binary_file (ऑर्डर किया गया बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --execution_log_json_file (ऑर्डर किया गया टेक्स्ट json फ़ॉर्मैट), -subcommands (टर्मिनल आउटपुट में सबकॉमैंड दिखाने के लिए).
--[no]experimental_execution_log_spawn_metrics
डिफ़ॉल्ट: "गलत"- एक्ज़ीक्यूट किए गए स्पॉन लॉग में, स्पॉन मेट्रिक को शामिल करें.
--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: ""- शर्तों के पक्ष में बहिष्कृत. टारगेट के सेट को फ़िल्टर करके, ad_actions को शेड्यूल करें.
--[no]experimental_extra_action_top_level_only
डिफ़ॉल्ट: "गलत"- शर्तों के पक्ष में बहिष्कृत. सिर्फ़ टॉप लेवल टारगेट के लिए external_action शेड्यूल करता है.
--[no]experimental_prioritize_local_actions
डिफ़ॉल्ट: "सही"-
अगर सेट किया जाता है, तो सिर्फ़ स्थानीय तौर पर चल सकने वाली कार्रवाइयों को संसाधन हासिल करने का पहला मौका दिया जाता है. डाइनैमिक रूप से चलने वाले वर्कर को दूसरा मौका मिलता है. साथ ही, डाइनैमिक तौर पर चलाई जाने वाली स्टैंडअलोन कार्रवाइयां आखिरी हो जाती हैं.
टैग:execution
--experimental_spawn_scheduler
-
साथ-साथ कार्रवाई करने के साथ-साथ कहीं और जाकर भी, डाइनैमिक एक्ज़ीक्यूशन चालू करें. Bazel, हर कार्रवाई को स्थानीय स्तर पर और कहीं से भी करता है. साथ ही, पहले कार्रवाई को पूरा करता है. अगर कोई कार्रवाई वर्कर के साथ काम करती है, तो लोकल ऐक्शन स्थायी वर्कर मोड में चलेगा. किसी अलग कार्रवाई वाले पाठ्यक्रम के लिए डाइनैमिक तरीके से एक्ज़ीक्यूशन चालू करने के लिए, `--internal_spawn_scheduler` और `--stratesy=<mnemonic>=Dynamic` फ़्लैग का इस्तेमाल करें.
इसमें यह भी शामिल है:
--internal_spawn_scheduler
--spawn_strategy=dynamic
--[no]experimental_worker_sandbox_hardening
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो वर्कर एक कठोर सैंडबॉक्स में चलते हैं.
टैग:execution
--[no]ignore_unsupported_sandboxing
डिफ़ॉल्ट: "गलत"- इस सिस्टम पर सैंडबॉक्स किए गए प्रोग्राम के काम न करने पर चेतावनी प्रिंट न करें.
--[no]incompatible_dont_use_javasourceinfoprovider
डिफ़ॉल्ट: "गलत"-
नहीं
टैग:incompatible_change
--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "Host_CPUS"- Bazel पर उपलब्ध लोकल सीपीयू कोर की कुल संख्या साफ़ तौर पर तय करें, ताकि वे स्थानीय तौर पर बनाई गई कार्रवाइयों पर खर्च कर सकें. पूर्णांक लेता है या "होस्ट_सीपीयूएस" लेता है. इसके बाद [-|*]<फ़्लो> (उदाहरण के लिए, Host_CPUS*.5, ताकि उपलब्ध सीपीयू कोर में से आधे का इस्तेमाल किया जा सके).डिफ़ॉल्ट रूप से, Bazel, उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाने के लिए, सिस्टम कॉन्फ़िगरेशन से क्वेरी करेगा.
--local_extra_resources=<a named float, 'name=value'>
बार कई बार इस्तेमाल किया गया- Bzel पर उपलब्ध ज़्यादा संसाधनों की संख्या सेट करें. स्ट्रिंग-फ़्लोट पेयर में लेता है. कई तरह के अतिरिक्त संसाधन बताने के लिए, कई बार इस्तेमाल किया जा सकता है. Bazel, साथ ही उपलब्ध अतिरिक्त संसाधनों और ज़रूरी अतिरिक्त संसाधनों के आधार पर, एक साथ चलने वाली कार्रवाइयों को सीमित करेगा. टेस्ट में "रिसॉर्स:<resoucename>:<amount>" फ़ॉर्मैट के टैग का इस्तेमाल करके, ज़रूरत के हिसाब से अतिरिक्त संसाधनों की जानकारी दी जा सकती है. इस फ़्लैग के साथ उपलब्ध सीपीयू, रैम और रिसॉर्स सेट नहीं किए जा सकते.
--local_ram_resources=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.>
: "होस्ट_रैम*.67"- Bize को उपलब्ध लोकल होस्ट रैम की कुल रकम साफ़ तौर पर (एमबी में) तय करें. इससे, बिल्ड से जुड़ी कार्रवाइयों को स्थानीय तौर पर लागू किया जा सकेगा. पूर्णांक या "होस्ट_रैम" लेता है. इसके बाद [-|*]<फ़्लो> (उदाहरण के लिए, होस्ट_रैम*.5, ताकि उपलब्ध रैम का आधा हिस्सा इस्तेमाल किया जा सके). डिफ़ॉल्ट रूप से, (“Host_RAM*.67”), Bazel, रैम की उपलब्ध मात्रा का अनुमान लगाने के लिए सिस्टम कॉन्फ़िगरेशन के बारे में क्वेरी करेगा और 67% रैम का इस्तेमाल करेगा.
--local_termination_grace_seconds=<an integer>
डिफ़ॉल्ट: "15"- टाइम आउट की वजह से, स्थानीय प्रक्रिया को खत्म करने और उसे ज़बरदस्ती बंद करने के बीच इंतज़ार करना.
--override_repository=<an equals-separated mapping of repository name to path>
बार कई बार इस्तेमाल किया गया- डेटा स्टोर करने की जगह को <repository name>=<path> के तौर पर स्थानीय पाथ में बदलें. अगर दिया गया पाथ एक सटीक पाथ है, तो इसे इसी तरह इस्तेमाल किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा डायरेक्ट्री से जुड़ा है. अगर दिया गया पाथ '%workspace%' से शुरू होता है, तो यह फ़ाइल फ़ोल्डर के रूट से मिलता-जुलता है, जो `bazel info workspace` का आउटपुट है
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- कोलन से अलग की गई सूची, जिसमें पैकेज खोजे जा सकते हैं. '%workspace%' से शुरू होने वाले एलिमेंट, आस-पास के फ़ाइल फ़ोल्डर के हिसाब से होते हैं. अगर इसे हटाया जाता है या खाली छोड़ा जाता है, तो डिफ़ॉल्ट रूप से 'बेज़ल की जानकारी के लिए डिफ़ॉल्ट पैकेज पाथ' आउटपुट मिल जाता है.
--[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 व्यवहार और टेस्ट कमांड पर होता है.
--workspace_status_command=<path>
डिफ़ॉल्ट: ""- बिल्ड की शुरुआत में, कुंजी/वैल्यू पेयर के तौर पर फ़ाइल फ़ोल्डर की स्थिति की जानकारी देने के लिए दिया गया निर्देश. पूरी जानकारी के लिए उपयोगकर्ता का मैन्युअल देखें. उदाहरण के लिए, टूल/buildstamp/get_workspace_status भी देखें.
- बिल्ड प्रोसेस को कंट्रोल करने वाले विकल्प:
--[no]check_up_to_date
डिफ़ॉल्ट: "गलत"-
बिल्ड पूरा न करें, बस देखें कि क्या वह अप-टू-डेट है. अगर सभी टारगेट अप-टू-डेट हैं, तो उनका बिल्ड सही तरीके से पूरा हो जाता है. किसी भी एक चरण को लागू करने पर गड़बड़ी की रिपोर्ट की जाती है और बिल्ड पूरा नहीं हो पाता.
टैग:execution
--[no]experimental_inprocess_symlink_creation
डिफ़ॉल्ट: "गलत"-
सिमलिंक ट्री बनाने के लिए, सीधे फ़ाइल सिस्टम को कॉल करना है या नहीं
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_remotable_source_manifests
डिफ़ॉल्ट: "गलत"-
सोर्स मेनिफ़ेस्ट ऐक्शन को बदला जा सकने वाला बनाना है
टैग:loading_and_analysis
,execution
,experimental
--[no]experimental_split_coverage_postprocessing
डिफ़ॉल्ट: "गलत"-
अगर यह नीति सही है, तो Bazel, नए स्पॉन में टेस्ट के लिए कवरेज के बाद, प्रोसेस करेगा.
टैग:execution
--[no]experimental_split_xml_generation
डिफ़ॉल्ट: "सही"-
अगर इस फ़्लैग को सेट किया जाता है और जांच कार्रवाई से test.xml फ़ाइल जनरेट नहीं होती है, तो Bazel एक अलग कार्रवाई का इस्तेमाल करके, टेस्ट लॉग वाली एक डमी test.xml फ़ाइल जनरेट करेगा. ऐसा न करने पर, Bazel, जांच कार्रवाई के हिस्से के तौर पर एक test.xml जनरेट करता है.
टैग:execution
--[no]experimental_strict_fileset_output
डिफ़ॉल्ट: "गलत"-
अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों की तरह मानेगा. वे डायरेक्ट्री में अदला-बदली नहीं करेंगे या सिमलिंक का संवेदनशील नहीं होंगे.
टैग:execution
--[no]experimental_use_semaphore_for_jobs
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया जाता है, तो सेमीफ़ोर का इस्तेमाल करके एक साथ कई नौकरियों की संख्या तय करें.
टैग:host_machine_resource_optimizations
,execution
--genrule_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
जीनोरल लागू करने का तरीका बताएं. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_stratepy=<value> का इस्तेमाल करें या सिर्फ़ genrule को कंट्रोल करने के लिए --stratety=Genrule=<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
] डिफ़ॉल्ट: "अपने-आप"-
एक साथ की जाने वाली नौकरियों की संख्या. पूर्णांक लेता है या कीवर्ड ("ऑटो", "होस्ट_सीपीएस"), वैकल्पिक रूप से इसके बाद कार्रवाई ([-|**]<फ़्लो>) लगता है "auto", "Host_CPUS*.5". वैल्यू, 1 से 5,000 के बीच होनी चाहिए. वैल्यू 2500 से ज़्यादा होने पर, मेमोरी से जुड़ी समस्याएं आ सकती हैं. "ऑटो", होस्ट संसाधनों के आधार पर सही डिफ़ॉल्ट की गिनती करता है.
टैग:host_machine_resource_optimizations
,execution
--[no]keep_going
[-k
] डिफ़ॉल्ट: "गलत"-
किसी गड़बड़ी के बाद, ज़्यादा से ज़्यादा बुकिंग जारी रखें. हालांकि, जो टारगेट पूरा नहीं हो सका और जिस पर निर्भर है उसका विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की दूसरी ज़रूरी शर्तें भी हो सकती हैं.
टैग:eagerness_to_exit
--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "अपने-आप"-
लोड होने/विश्लेषण के चरण के लिए समानांतर थ्रेड का इस्तेमाल किया जाता है. पूर्णांक या कीवर्ड ("ऑटो", "Host_CPUS", "Host_RAM") लेता है. इसके बाद, कार्रवाई ([-|*]<फ़्लो>) जैसे विकल्प को चुना जाता है. "auto", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर सही डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
--modify_execution_info=<regex=[+-]key,regex=[+-]key,...>
डिफ़ॉल्ट: ""-
कार्रवाई की जानकारी के आधार पर, 'कार्रवाई' से जुड़ी जानकारी में कुंजियां जोड़ें या हटाएं. यह नीति सिर्फ़ उन कार्रवाइयों पर लागू होती है जिनमें प्रोग्राम चलाने की जानकारी होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी होती है. उदाहरण के लिए, Genrule, CppCompile, Javac, StarlarkAction, TestRunner. कई वैल्यू तय करते समय, ऑर्डर अहम होता है. ऐसा इसलिए होता है, क्योंकि एक से ज़्यादा रेगुलर एक्सप्रेशन में एक से ज़्यादा रेगुलर एक्सप्रेशन लागू हो सकते हैं.
सिंटैक्स: "regex=[+-key,regex=[+-key],...".
उदाहरण:
'.*=+x,.*=-y,.*=+z', 'x' और 'z' को जोड़ देता है. साथ ही, 'y' को हटा देता है. इसके लिए, सभी कार्रवाइयों के लिए कार्रवाई की जानकारी नहीं दी जाती.
'Genrule=+Requires-x' जोड़ने पर 'Requires-x' जुड़ जाता है.
'(?!Genrule).*=-Requires-x', गैर-Genrule कार्रवाइयों के लिए लागू होने वाली जानकारी से 'Requires-x' हटा देता है.
टैग:execution
,affects_outputs
,loading_and_analysis
--persistent_android_dex_desugar
-
कर्मचारियों की मदद से, Android पर काम करने वाली और Desgar की स्थायी कार्रवाइयों को चालू करें.
इसमें यह भी शामिल है:
--internal_persistent_android_dex_desugar
--strategy=Desugar=worker
--strategy=DexBuilder=worker
टैग:host_machine_resource_optimizations
,execution
--persistent_android_resource_processor
-
कर्मचारियों की मदद से, Android पर लगातार काम करने वाले संसाधन को चालू करें.
इसमें यह भी शामिल है:
--internal_persistent_busybox_tools
--strategy=AaptPackage=worker
--strategy=AndroidResourceParser=worker
--strategy=AndroidResourceValidator=worker
--strategy=AndroidResourceCompiler=worker
--strategy=RClassGenerator=worker
--strategy=AndroidResourceLink=worker
--strategy=AndroidAapt2=worker
--strategy=AndroidAssetMerger=worker
--strategy=AndroidResourceMerger=worker
--strategy=AndroidCompiledResourceMerger=worker
--strategy=ManifestMerger=worker
--strategy=AndroidManifestMerger=worker
}--strategy=Aapt2Optimize=worker
--strategy=AARGenerator=worker
host_machine_resource_optimizations
execution
--persistent_multiplex_android_dex_desugar
-
कर्मचारियों की मदद से, मल्टीप्लेक्स Android Dex और Desgar कार्रवाइयां लगातार करें.
इसमें यह भी शामिल है:
--persistent_android_dex_desugar
--internal_persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
--persistent_multiplex_android_resource_processor
-
कर्मचारियों की मदद से, मल्टीप्लेक्स Android रिसॉर्स प्रोसेसर को स्थायी तौर पर चालू करें.
इसमें यह भी शामिल है:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
}--modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
--modify_execution_info=AARGenerator=+supports-multiplex-workers
host_machine_resource_optimizations
execution
--persistent_multiplex_android_tools
-
Android और उससे जुड़े मल्टीप्लेक्स टूल (डेक्सिंग, डीज़र्जिंग, रिसॉर्स प्रोसेसिंग) को चालू करें.
इसमें यह भी शामिल है:
--internal_persistent_multiplex_busybox_tools
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
--[no]skip_incompatible_explicit_targets
डिफ़ॉल्ट: "गलत"-
ऐसे टारगेट को छोड़ें जो कमांड लाइन में साफ़ तौर पर दिखते हैं. डिफ़ॉल्ट रूप से, ऐसे टारगेट बनाने की वजह से गड़बड़ी होती है. हालांकि, इस विकल्प के चालू होने पर वे बिना आवाज़ के नहीं चल जाते. देखें: https://bazel.build/extending/platforms#skipping-insupported-targets
टैग:loading_and_analysis
--spawn_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
तय करें कि डिफ़ॉल्ट रूप से, स्पॉन ऐक्शन को कैसे लागू किया जाता है. सबसे ज़्यादा से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार की जाती है. हर कार्रवाई के लिए, बेज़ल सबसे ज़्यादा प्राथमिकता वाली रणनीति को चुनते हैं. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. ज़्यादा जानकारी पाने के लिए, https://blog.bazel.build/2019/06/19/list-stratepy.html पर जाएं.
टैग:execution
--strategy=<a '[name=]value1[,..,valueN]' assignment>
बार कई बार इस्तेमाल किया गया-
स्पॉन की अन्य कार्रवाइयों को कंपाइल करने का तरीका बताएं. सबसे ज़्यादा से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट स्वीकार की जाती है. हर कार्रवाई के लिए, बेज़ल सबसे ज़्यादा प्राथमिकता वाली रणनीति को चुनते हैं. डिफ़ॉल्ट वैल्यू "remote,worker,sandboxed,local" है. यह फ़्लैग --spawn_stratety (अगर -- mnemonic Genrule के साथ इस्तेमाल किया गया है) को --genrule_stratety) से सेट की गई वैल्यू बदलता है. ज़्यादा जानकारी पाने के लिए, https://blog.bazel.build/2019/06/19/list-stratepy.html पर जाएं.
टैग:execution
--strategy_regexp=<a '<RegexFilter>=value[,value]' assignment>
बार कई बार इस्तेमाल किया गया-
तय करें कि किसी खास regex_filter से मैच करने वाली जानकारी का इस्तेमाल करने के लिए, कौनसी स्पॉन रणनीति इस्तेमाल की जानी चाहिए. रेगुलर एक्सप्रेशन फ़िल्टर से मिलान करने की जानकारी पाने के लिए, --per_file_copt देखें. ब्यौरे से मेल खाने वाले आखिरी regex_filter का इस्तेमाल किया जाता है. यह विकल्प, रणनीति के बारे में बताने वाले दूसरे फ़्लैग को बदल देता है. उदाहरण: --stratepy_regexp=//foo.*\.cc,-//foo/bar=local का मतलब है कि स्थानीय रणनीति का इस्तेमाल करके कार्रवाइयां करनी होंगी. ऐसा तब होगा, जब उनके ब्यौरे //foo.*.cc के बजाय //foo/bar से मेल खाते हों. उदाहरण: --stratepy_regexp='Compling.*/bar=local --strategi_regexp=Compling=sandboxed' 'लोकल' रणनीति के साथ 'Compling //foo/bar/baz' चलाएगा. हालांकि, ऑर्डर उलटने पर यह 'सैंडबॉक्स' के साथ काम करेगा.
टैग:execution
--[no]use_target_platform_for_tests
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bazel, जांच करने वाले ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करके टेस्ट करेगा.
टैग:execution
- ऐसे ऐक्शनचेन टूल को कॉन्फ़िगर करने के विकल्प जो कार्रवाई करने के लिए इस्तेमाल होते हैं:
--android_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट कंपाइलर.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_crosstool_top=<a build target label>
डिफ़ॉल्ट: "//external:android/crosstool"-
Android बिल्ड के लिए इस्तेमाल किए गए C++ कंपाइलर की जगह.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_manifest_merger=<legacy, android or force_android>
डिफ़ॉल्ट: "android"-
android_binary नियमों के लिए इस्तेमाल करने के लिए, मेनिफ़ेस्ट मर्जर को चुनता है. फ़्लैग करें, ताकि लेगसी मर्जर की मदद से, Android मेनिफ़ेस्ट मर्जर पर ट्रांज़िशन किया जा सके.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_platforms=<a build target label>
डिफ़ॉल्ट: ""-
Android_binary टारगेट के इस्तेमाल करने वाले प्लैटफ़ॉर्म सेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें, हर खास टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी होती हैं.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_sdk=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/android:sdk"-
यह, Android SDK/प्लैटफ़ॉर्म के बारे में बताता है, जिसका इस्तेमाल Android ऐप्लिकेशन बनाने के लिए किया जाता है.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--apple_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_ascendingr'.
टैग: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>
डिफ़ॉल्ट: ब्यौरा देखें-
कस्टम मैलक लागू करना तय करता है. यह सेटिंग, बिल्ड नियमों में मॉलोक एट्रिब्यूट को बदल देती है.
टैग:changes_inputs
,affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment>
बार कई बार इस्तेमाल किया गया-
कॉमा लगाकर अलग किए गए रेगुलर एक्सप्रेशन की सूची. हर एक्सप्रेशन को - (नेगेटिव एक्सप्रेशन) प्रीफ़िक्स के साथ, कॉमा से अलग किए गए कंस्ट्रेंट वैल्यू टारगेट की सूची में असाइन करें. अगर कोई टारगेट, किसी नेगेटिव एक्सप्रेशन से मैच नहीं करता है और कम से कम एक पॉज़िटिव एक्सप्रेशन है, तो इसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा जैसे यह कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर दिखाता हो. उदाहरण: //डेमो,-टेस्ट=@प्लैटफ़ॉर्म
टैग:loading_and_analysis
--[no]experimental_enable_objc_cc_deps
डिफ़ॉल्ट: "सही"-
objc_* नियमों को cc_library पर निर्भर करने और किसी भी objc डिपेंडेंसी को --ios_<--ios_cpu> पर सेट करने की अनुमति देता है.
टैग:loading_and_analysis
,incompatible_change
--[no]experimental_include_xcode_execution_requirements
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया जाता है, तो हर Xcode कार्रवाई के लिए, "Requires-xcode:{version}" लागू करने की ज़रूरी शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न इस्तेमाल करने वाला लेबल है, तो लागू करने के लिए, "Requires-xcode-label:{version_label}" के लिए ज़रूरी शर्त भी जोड़ें.
टैग:loses_incremental_state
,loading_and_analysis
,execution
--[no]experimental_prefer_mutual_xcode
डिफ़ॉल्ट: "सही"-
अगर सही है, तो हाल ही के Xcode का इस्तेमाल करें जो स्थानीय और दूर, दोनों जगह उपलब्ध है. अगर गलत है या उपलब्ध वर्शन उपलब्ध नहीं हैं, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode के वर्शन का इस्तेमाल करें.
टैग:loses_incremental_state
--extra_execution_platforms=<comma-separated list of options>
डिफ़ॉल्ट: ""-
वे प्लैटफ़ॉर्म जो एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर उपलब्ध हैं, ताकि कार्रवाइयां की जा सकें. प्लैटफ़ॉर्म सटीक टारगेट या टारगेट पैटर्न के तौर पर बताए जा सकते हैं. रजिस्टर हो जाने के बाद, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इसके लिए, spot_file वाली फ़ाइल पर बताया गया होगा... चिप.
टैग:execution
--extra_toolchains=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया-
टूलचेन का इस्तेमाल करते समय, इन दो बातों पर ध्यान देना चाहिए: टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर बताया जा सकता है. रजिस्टर किए गए टूलटूल (टूल_टूलचेन)() में बताई गई टूल चेन से पहले, इन टूलचेन का इस्तेमाल किया जाएगा.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
चेक इन की गई लाइब्रेरी की लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन से चुनी जाती है और आपको इसे कभी भी बदलने की ज़रूरत नहीं होती.
टैग:action_command_lines
,affects_outputs
--host_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
C++ कंपाइलर, जिसका इस्तेमाल होस्ट कंपाइलेशन के लिए किया जाता है. अगर --host_crossTool_top सेट नहीं है, तो इसे अनदेखा कर दिया जाता है.
टैग:loading_and_analysis
,execution
--host_crosstool_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
डिफ़ॉल्ट रूप से, --crosstool_top और --compiler विकल्प को भी exec कॉन्फ़िगरेशन के लिए इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया गया है, तो Bazel, दिए गए क्रॉसटूल_टॉप के लिए डिफ़ॉल्ट libc और कंपाइलर का इस्तेमाल करता है.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--host_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर इस सेटिंग के बारे में बताया गया हो, तो exec कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग:action_command_lines
,affects_outputs
--host_platform=<a build target label>
डिफ़ॉल्ट: "@local_config_platform//:host"-
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट सिस्टम की जानकारी देता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--[no]incompatible_disable_expand_if_all_available_in_flag_set
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel,expand_if_all_available को फ़्लैग_सेट में दिखाने की अनुमति नहीं देगा(माइग्रेशन के निर्देशों के लिए https://github.com/bazelbuild/bazel/issues/7008 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल c++ टूलटिप में 'host' और 'nonhost' सुविधाएं चालू नहीं करेगा (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7407 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_android_toolchain_resolution
डिफ़ॉल्ट: "गलत"-
Android नियमों (Starलार्क और नेटिव) के लिए Android SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution
डिफ़ॉल्ट: "गलत"-
Apple के नियमों (Starlark और नेटिव) के लिए Apple SDK चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, lto इंडेक्सिंग कमांड लाइन के लिए, C++ लिंक वाले ऐक्शन कमांड का दोबारा इस्तेमाल नहीं करेगा (ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/6791 पर जाएं).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_objc_linking_info_migration
डिफ़ॉल्ट: "सही"-
अगर सही है, तो ObjC में पहले से मौजूद नियमों को, ObjcProvider के बजाय, CCInfo से लिंक करने की जानकारी मिलेगी. जानकारी और माइग्रेशन की जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/16939 देखें
टैग:loading_and_analysis
,changes_inputs
,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
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल को cc_normal.configure_features (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7793 देखें) में 'ctx' पैरामीटर की ज़रूरत होगी.
टैग: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 SDK टूल के उस वर्शन के बारे में बताता है जिसका इस्तेमाल macOS ऐप्लिकेशन बनाने के लिए किया जाता है. अगर जानकारी न दी गई हो, तो '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>
डिफ़ॉल्ट: ब्यौरा देखें-
ऐसा py_runtime का लेबल जो Python की अनुवादक को दिखाता है. इसने टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया. बहिष्कृत; --insupported_use_python_toolchains से बंद किया गया.
टैग:loading_and_analysis
,affects_outputs
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टीवी ऐप्लिकेशन बनाने के लिए tvOS SDK का वर्शन बताता है. अगर इसके बारे में जानकारी न दी गई हो, तो 'xcode_version' के डिफ़ॉल्ट tvOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
यह, WatchOS SDK के उस वर्शन के बारे में बताता है जिसका इस्तेमाल, WatchOS ऐप्लिकेशन बनाने के लिए किया जाता है. अगर नीति तय नहीं की गई है, तो 'xcode_version' के डिफ़ॉल्ट WatchOS SDK वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xcode_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताया गया हो, तो बिल्ड से जुड़ी काम की कार्रवाइयों के लिए Xcode का इस्तेमाल किया जाता है. अगर बताया नहीं गया हो, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--xcode_version_config=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"-
बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए, xcode_config नियम का लेबल.
टैग:loses_incremental_state
,loading_and_analysis
- ऐसे निर्देश जो कमांड के आउटपुट को कंट्रोल करते हैं:
--[no]apple_enable_auto_dsym_dbg
डिफ़ॉल्ट: "गलत"-
dbg बिल्ड के लिए डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करने की सुविधा चालू करनी है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]apple_generate_dsym
डिफ़ॉल्ट: "गलत"-
डीबग सिंबल(.dSYM) फ़ाइल(फ़ाइलें) जनरेट करना है या नहीं.
टैग:affects_outputs
,action_command_lines
--[no]build
डिफ़ॉल्ट: "सही"-
बिल्ड को एक्ज़ीक्यूट करें, यह एक आम बात है. --nobuild तय करने से बिल्ड कार्रवाइयां पूरा होने से पहले ही बिल्ड बंद हो जाता है, अगर पैकेज लोड होने और विश्लेषण के फ़ेज़ पूरे हो जाते हैं, तो वैल्यू शून्य हो जाती है. यह मोड उन फ़ेज़ की जांच करने के लिए उपयोगी है.
टैग:execution
,affects_outputs
--[no]build_runfile_links
डिफ़ॉल्ट: "सही"-
अगर सही हो, तो सभी टारगेट के लिए रन फ़ाइलों को सिमलिंक फ़ॉरेस्ट बनाएं. अगर गलत है, तो जब भी हो सके, सिर्फ़ मेनिफ़ेस्ट लिखें.
टैग:affects_outputs
--[no]build_runfile_manifests
डिफ़ॉल्ट: "सही"-
अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर गलत है, तो उन्हें छोड़ दें. गलत होने पर, स्थानीय जांच नहीं हो पाएगी.
टैग:affects_outputs
--[no]build_test_dwp
डिफ़ॉल्ट: "गलत"-
अगर इसे चालू किया गया हो, तो C++ की जांच को स्टैटिक तौर पर और फ़िस के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल अपने-आप बन जाएगी.
टैग:loading_and_analysis
,affects_outputs
--cc_proto_library_header_suffixes=<comma-separated set of options>
, डिफ़ॉल्ट: ".pb.h"-
उन हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है जिन्हें cc_proto_library बनाता है.
टैग:affects_outputs
,loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated set of options>
डिफ़ॉल्ट: ".pb.cc"-
उन सोर्स फ़ाइलों के प्रीफ़िक्स सेट करता है जिन्हें cc_proto_library बनाता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info
डिफ़ॉल्ट: "गलत"-
proto_library में Java की एपीआई के दूसरे वर्शन के लिए, अतिरिक्त कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_proto_extra_actions
डिफ़ॉल्ट: "गलत"-
proto_library में Java की एपीआई के दूसरे वर्शन के लिए, अतिरिक्त कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_run_validations
डिफ़ॉल्ट: "सही"-
इसके बजाय --run_मान्यता का इस्तेमाल करें.
टैग:execution
,affects_outputs
--[no]experimental_save_feature_state
डिफ़ॉल्ट: "गलत"-
वीडियो को चालू करने के मोड और चालू किए गए अनुरोधों को कंपाइल करने के लिए, सेव की गई स्थिति को सेव करें.
टैग:affects_outputs
,experimental
--[no]experimental_use_validation_aspect
डिफ़ॉल्ट: "गलत"-
जांच करने के दौरान, उसका साथ का इस्तेमाल करके पुष्टि करने की कार्रवाइयां की जा सकती हैं या नहीं.
टैग:execution
,affects_outputs
--fission=<a set of compilation modes>
डिफ़ॉल्ट: "नहीं"-
यह तय करता है कि कंपाइलेशन के कौनसे मोड C++ के कंपाइलेशन और लिंक के लिए फ़िशन का इस्तेमाल करते हैं. सभी मोड को चालू करने के लिए {'fastbuild', 'dbg', 'opt'} या खास वैल्यू 'yes' का कॉम्बिनेशन हो सकता है. इससे, सभी मोड को बंद किया जा सकता है.
टैग:loading_and_analysis
,action_command_lines
,affects_outputs
--[no]incompatible_always_include_files_in_data
डिफ़ॉल्ट: "सही"-
अगर सही है, तो नेटिव नियम अपनी रनफ़ाइल में डेटा डिपेंडेंसी के लिए <code>DefaultInfo.files</code> जोड़ते हैं. यह, Starlark नियमों (https://bazel.build/extending/rule#runfiles_features_to_aallow) के लिए सुझाए गए तरीकों से मेल खाता है.
टैग:affects_outputs
,incompatible_change
--[no]legacy_external_runfiles
डिफ़ॉल्ट: "सही"-
अगर सही है, तो .runfiles/wsname/external/repo में .runfiles/repo के साथ-साथ बाहरी डेटा स्टोर करने की जगहों के लिए रनफ़ाइल सिमलिंक जंगल बनाएं.
टैग:affects_outputs
--[no]objc_generate_linkmap
डिफ़ॉल्ट: "गलत"-
यह तय करता है कि लिंक मैप फ़ाइल जनरेट करनी है या नहीं.
टैग:affects_outputs
--output_groups=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया-
कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. हर ग्रुप के नाम से पहले + या - का निशान लगाया जाता है. + से शुरू होने वाले ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ दिया जाता है, जबकि प्रीफ़िक्स वाले ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप को प्रीफ़िक्स नहीं किया गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट हट जाता है. मतलब
टैग:execution
,affects_outputs
--[no]run_validations
डिफ़ॉल्ट: "सही"-
बिल्ड के हिस्से के तौर पर पुष्टि करने की कार्रवाइयां करनी हैं या नहीं. https://bazel.build/extending/rule#मान्येशन_ACTIONS देखें
टैग:execution
,affects_outputs
--[no]save_temps
डिफ़ॉल्ट: "गलत"-
अगर यह सेट है, तो gcc के अस्थायी आउटपुट सेव हो जाएंगे. इनमें .s फ़ाइलें (असेंबल करने का कोड), .i फ़ाइलें (पहले से प्रोसेस की गईं C) और .ii फ़ाइलें (पहले से प्रोसेस किए गए C++) शामिल हैं.
टैग:affects_outputs
- ऐसे विकल्प जो उपयोगकर्ता को उसके आउटपुट के बजाय, सही आउटपुट को कॉन्फ़िगर करने देते हैं:
--action_env=<a 'name=value' assignment with an optional value part>
बार कई बार इस्तेमाल किया गया-
पर्यावरण वैरिएबल के उस सेट के बारे में बताता है जो टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध है. वैरिएबल या तो नाम से तय किए जा सकते हैं, जहां मामले को शुरू करने के एनवायरमेंट से लिया जाएगा या नाम=वैल्यू पेयर से, वैल्यू को शुरू करने के एनवायरमेंट से अलग सेट किया जाएगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, लेकिन एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, नए वैरिएबल के लिए इकट्ठा किए गए विकल्प इकट्ठा होते हैं.
टैग:action_command_lines
--android_cpu=<a string>
डिफ़ॉल्ट: "armeabi-v7a"-
Android पर सीपीयू.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]android_databinding_use_androidx
डिफ़ॉल्ट: "गलत"-
AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ databinding v2 के साथ किया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]android_databinding_use_v3_4_args
डिफ़ॉल्ट: "गलत"-
3.4.0 तर्क वाले android databinding v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--android_dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "बंद" है-
यह तय करता है कि जब किसी cc_binary ने साफ़ तौर पर 'शेयर की गई लाइब्रेरी' नहीं बनाई हो, तो Android के नियमों के C++ वर्शन को डाइनैमिक तौर पर लिंक किया जाए या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बैज़ल डाइनैमिक तौर पर लिंक करने का विकल्प चुनेगा. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक रूप से लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:affects_outputs
,loading_and_analysis
--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency>
डिफ़ॉल्ट: "वर्णमाला"-
Android बाइनरी के लिए मेनिफ़ेस्ट मर्जर को भेजे गए मेनिफ़ेस्ट के क्रम को सेट करता है. अल्फ़ाबेटिकल का मतलब है कि मेनिफ़ेस्ट को एक्ज़ीक्यूट के हिसाब से पाथ के हिसाब से क्रम में लगाया गया है. ALPHABETIAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट, आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री से जुड़े पाथ के हिसाब से क्रम में लगाए जाते हैं. डिपेंडेंसी का मतलब है कि हर लाइब्रेरी के मेनिफ़ेस्ट का क्रम, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.
टैग:action_command_lines
,execution
--[no]android_resource_shrinking
डिफ़ॉल्ट: "गलत"-
ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए संसाधनों को छोटा करने की सुविधा चालू करता है.
टैग:affects_outputs
,loading_and_analysis
--aspects=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया- टॉप-लेवल टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा-सेपरेटेड लिस्ट. अगर सूची में, आसपेक्ट_aspect के लिए ज़रूरी शर्त लागू करने वाली कंपनियों से जुड़ी ज़रूरी जानकारी दी जाती है, तो did_aspect ऐसे हर पहलू के बाद काम करेगा जिसके बारे में पहले बताया गया है. साथ ही, आसपेक्ट रेशियो (चौड़ाई-ऊंचाई का डेटा) की सूची में, कुछ विज्ञापन देने वाले उन प्रोवाइडर को भी शामिल करते हैं जिनके लिए data_aspect ज़रूरी है. इसके अलावा, मैनेज किया जाने वाला कुछ एट्रिब्यूट, एट्रिब्यूट की ज़रूरत वाले सभी ज़रूरी पहलुओं को दिखाने पर काम करता है. इसके बाद,Some_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
डिफ़ॉल्ट: "गलत"-
अगर तय किया गया है, तो बेज़ल इंस्ट्रूमेंटेशन कोड का इस्तेमाल करेगा (जहां संभव हो, ऑफ़लाइन इंस्ट्रुमेंट का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ वे टारगेट पर असर होगा जो -- इंस्ट्रूमेंटेशन_फ़िल्टर से मेल खाते हैं. आम तौर पर, यह विकल्प सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'बेज़ल कवरेज' निर्देश का इस्तेमाल किया जाना चाहिए.
टैग: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>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, CSFDO की प्रोफ़ाइल जानकारी का इस्तेमाल करें. उस 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>
बार कई बार इस्तेमाल किया गया-
हर --परिभाषित विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है.
टैग:changes_inputs
,affects_outputs
--dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
यह तय करता है कि C++ बाइनरी लिंक करने के लिए, डाइनैमिक तौर पर लिंक करना है या नहीं. 'डिफ़ॉल्ट' का मतलब है कि बेज़ल यह चुनेगा कि डाइनैमिक तौर पर लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक रूप से लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग: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>
बार कई बार इस्तेमाल किया गया-
शर्तों के पक्ष में बहिष्कृत. बिल्ड की मौजूदा कार्रवाइयों के साथ अलग से कोई ऐक्शन जोड़ने के लिए, action_listener का इस्तेमाल करें.
टैग:execution
,experimental
--[no]experimental_android_compress_java_resources
डिफ़ॉल्ट: "गलत"-
APK के Java संसाधनों को कंप्रेस करें
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_android_databinding_v2
डिफ़ॉल्ट: "गलत"-
Android डेटा बाइंडिंग v2 का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_android_resource_shrinking
डिफ़ॉल्ट: "गलत"-
ProGuard का इस्तेमाल करने वाले android_binary APKs के लिए संसाधनों को छोटा करने की सुविधा चालू करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex
डिफ़ॉल्ट: "गलत"-
डेक्स फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_convenience_symlinks
डिफ़ॉल्ट: "सामान्य"-
यह फ़्लैग इस बात को कंट्रोल करता है कि सुविधा के सिमलिंक, (बिल्डिंग के बाद फ़ाइल फ़ोल्डर में दिखने वाले सिमलिंक) को कैसे मैनेज किया जाएगा. संभावित वैल्यू:
सामान्य (डिफ़ॉल्ट): हर तरह का सुविधाजनक सिमलिंक बनाया या मिटाया जाएगा, जैसा कि बिल्ड ने तय किया है.
साफ़: सभी सिमलिंक, बिना शर्त के मिटाए जाएंगे.
अनदेखा करें: सिमलिंक अकेले रह जाएंगे.
log_only: लॉग मैसेज जनरेट करें जैसे कि 'सामान्य' पास किया गया हो, लेकिन असल में कोई फ़ाइल सिस्टम कार्रवाई न करें (टूल के लिए उपयोगी).
ध्यान दें कि सिर्फ़ वही सिमलिंक जिन पर मौजूदा नाम ---linklink_prefix की वैल्यू से जनरेट हुआ है, उन पर असर पड़ सकता है: अगर प्रीफ़िक्स बदलता है, तो पहले से मौजूद सभी सिमलिंक ही रह जाएंगे.
टैग:affects_outputs
--[no]experimental_convenience_symlinks_bep_event
डिफ़ॉल्ट: "गलत"-
इस फ़्लैग से यह कंट्रोल किया जाता है कि हम BuildEventProSimlinksIdd को BuildEventProtocol में पहचानेंगे या नहीं. अगर वैल्यू 'सही' है, तो BuildEventProtocol में][=SymlinksIdentified के लिए, एक एंट्री होगी, जिसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक होंगे. अगर 'गलत है' पर सेट किया जाता है, तो BuildEventProtocol मेंसुविधा के सिमलिंक वाले आईडी को खाली छोड़ दिया जाएगा.
टैग:affects_outputs
--experimental_multi_cpu=<comma-separated list of options>
बार कई बार इस्तेमाल किया गया-
अब सेवा में नहीं है. नहीं.
टैग:affects_outputs
,experimental
--experimental_objc_fastbuild_options=<comma-separated list of options>
डिफ़ॉल्ट: "-O0,-DDEBUG=1"-
इन स्ट्रिंग का इस्तेमाल objc फ़ास्टबिल्ड कंपाइलर के विकल्प के तौर पर करता है.
टैग:action_command_lines
--[no]experimental_omitfp
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो स्टैक अनविंड करने के लिए libunwin का इस्तेमाल करें और -fomit-frame-pointer और -fasynchronus-unwind-tables के साथ कंपाइल करें.
टैग:action_command_lines
,affects_outputs
,experimental
--[no]experimental_platform_in_output_dir
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो टारगेट प्लैटफ़ॉर्म का इस्तेमाल सीपीयू के बजाय, आउटपुट डायरेक्ट्री में किया जाता है.
टैग:affects_outputs
,experimental
--[no]experimental_use_llvm_covmap
डिफ़ॉल्ट: "गलत"-
अगर जानकारी दी गई हो, तो Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा. ऐसा कलेक्ट_कोड_कवरेज के चालू होने पर होगा.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
,experimental
--fat_apk_cpu=<comma-separated set 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
डिफ़ॉल्ट: "गलत"-
HWASAN स्प्लिट बनाने हैं या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी कोड जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह डायरेक्ट्री का वह नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान डंप किया जाता है.
टैग:affects_outputs
--fdo_optimize=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, एफ़डीओ की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. ऐसी ZIP फ़ाइल का नाम बताएं जिसमें .gcda फ़ाइल ट्री है. इसके अलावा, ऐसी afdo फ़ाइल भी होती है जिसमें ऑटो प्रोफ़ाइल या LLVM प्रोफ़ाइल फ़ाइल होती है. यह फ़्लैग, लेबल के तौर पर बताई गई फ़ाइलें भी स्वीकार करता है (उदाहरण के लिए, `//foo/bar:file.afdo` - आपको इससे जुड़े पैकेज के लिए, `exports_files` डायरेक्टिव जोड़ना पड़ सकता है) और लेबल के लिए, fdo_profile` टारगेट करना होगा. इस फ़्लैग की जगह `fdo_profile` नियम लागू होगा.
टैग:affects_outputs
--fdo_prefetch_hints=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कैश मेमोरी में सेव किए गए सुझावों का इस्तेमाल करें.
टैग:affects_outputs
--fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली fdo_profile प्रोफ़ाइल.
टैग:affects_outputs
--features=<a string>
बार कई बार इस्तेमाल किया गया-
टारगेट कॉन्फ़िगरेशन के दौरान बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> तय करने पर, यह सुविधा बंद हो जाएगी. नेगेटिव सुविधाएं हमेशा अच्छी सुविधाओं को बदल देती हैं. ये भी देखें --host_features
टैग:changes_inputs
,affects_outputs
--[no]force_pic
डिफ़ॉल्ट: "गलत"-
इसके चालू होने पर, सभी C++ कंपाइलेशन से स्थान-स्वतंत्र कोड ("-fPIC") मिलता है, लिंक गैर-PIC लाइब्रेरी के बजाय PIC पहले से बनी लाइब्रेरी को प्राथमिकता देते हैं और लिंक, स्थान-स्वतंत्र एक्ज़ीक्यूटेबल ("-pie") तैयार करते हैं.
टैग:loading_and_analysis
,affects_outputs
--host_action_env=<a 'name=value' assignment with an optional value part>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में बताता है. वैरिएबल या तो नाम से तय किए जा सकते हैं, जहां मामले को शुरू करने के एनवायरमेंट से लिया जाएगा या नाम=वैल्यू पेयर से, वैल्यू को शुरू करने के एनवायरमेंट से अलग सेट किया जाएगा. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, लेकिन एक ही वैरिएबल के लिए दिए गए विकल्पों के लिए, नए वैरिएबल के लिए इकट्ठा किए गए विकल्प इकट्ठा होते हैं.
टैग:action_command_lines
--host_compilation_mode=<fastbuild, dbg or opt>
डिफ़ॉल्ट: "ऑप्ट"-
उस मोड के बारे में बताएं जिसका इस्तेमाल करके, बिल्ड के दौरान टूल बनाए गए थे. वैल्यू: 'fastbuild', 'dbg', 'opt'.
टैग:affects_outputs
,action_command_lines
--host_conlyopt=<a string>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूट करने के कॉन्फ़िगरेशन में C (C++) सोर्स फ़ाइलें कंपाइल करते समय C कंपाइलर को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_copt=<a string>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूट कॉन्फ़िगरेशन में बनाए गए टूल के लिए C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_cpu=<a string>
डिफ़ॉल्ट: ""-
होस्ट सीपीयू.
टैग:changes_inputs
,affects_outputs
--host_cxxopt=<a string>
बार कई बार इस्तेमाल किया गया-
exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर में पास करने के लिए अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_features=<a string>
बार कई बार इस्तेमाल किया गया-
exe कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, ये सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद होंगी. -<feature> तय करने पर, यह सुविधा बंद हो जाएगी. नेगेटिव सुविधाएं हमेशा अच्छी सुविधाओं को बदल देती हैं.
टैग:changes_inputs
,affects_outputs
--host_force_python=<PY2 or PY3>
डिफ़ॉल्ट: ब्यौरा देखें-
exec कॉन्फ़िगरेशन के लिए, Python वर्शन को बदल देता है. यह "PY2" या "PY3" हो सकता है.
टैग:loading_and_analysis
,affects_outputs
--host_linkopt=<a string>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूट कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंक करने वाले को पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट टारगेट के लिए, कम से कम macOS वर्शन काम करता है. अगर जानकारी न दी गई हो, तो 'macos_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई बार इस्तेमाल किया गया-
एक्ज़ीक्यूशन कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तरीके से पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter का मतलब है, रेगुलर एक्सप्रेशन के पैटर्न को शामिल करना और बाहर रखना. (यह भी देखें -- इंस्ट्रूमेंटेशन_फ़िल्टर). विकल्प_1 का मतलब है आर्बिट्रेरी कमांड लाइन विकल्प. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना ज़रूरी है. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, Bar.cc को छोड़कर //foo/ में सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
--host_swiftcopt=<a string>
बार कई बार इस्तेमाल किया गया-
exec टूल के लिए swiftc में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--[no]incompatible_auto_exec_groups
डिफ़ॉल्ट: "गलत"-
चालू होने पर, किसी नियम में इस्तेमाल किए जाने वाले हर टूलचेन के लिए, एक एक्ज़ीक्यूटिव ग्रुप अपने-आप बन जाता है. इसके लिए, काम करने के नियम के हिसाब से, इसकी कार्रवाइयों पर `टूलचेन` पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/17134 पर जाएं.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_avoid_conflict_dlls
डिफ़ॉल्ट: "सही"-
अगर यह सुविधा चालू है, तो Windows पर cc_library की ओर से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (DLL) का नाम बदलकर name_{has}.dll कर दिया जाएगा. इसमें, RepositoryName और DLL के पैकेज पाथ के आधार पर हैश का हिसाब लगाया जाता है. यह विकल्प तब काम आता है, जब आपके पास एक पैकेज होता है जो एक ही नाम वाले कई cc_library पर निर्भर करता है (उदाहरण के लिए, //foo/bar1:utils और //foo/bar2:utils).
टैग:loading_and_analysis
,affects_outputs
,incompatible_change
--[no]incompatible_merge_genfiles_directory
डिफ़ॉल्ट: "सही"-
अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में बदल दिया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_use_host_features
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो टारगेट कॉन्फ़िगरेशन के लिए --features का इस्तेमाल करें और exec कॉन्फ़िगरेशन के लिए --host_features] का इस्तेमाल करें.
टैग:changes_inputs
,affects_outputs
,incompatible_change
--[no]instrument_test_targets
डिफ़ॉल्ट: "गलत"-
कवरेज की सुविधा चालू होने पर, यह तय किया जाता है कि टेस्टिंग के नियमों का पालन करना है या नहीं. सेट होने पर, -- इंस्ट्रूमेंटेशन_फ़िल्टर के शामिल किए गए टेस्ट नियम लागू किए जाते हैं. नहीं तो, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रुमेंटेशन से बाहर रखा जाता है.
टैग:affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-/javatests[/:],-/test/java[/:]"-
कवरेज चालू होने पर, सिर्फ़ रेगुलर एक्सप्रेशन पर आधारित फ़िल्टर की मदद से शामिल किए गए नामों वाले नियम ही लागू किए जाएंगे. इसके बजाय '-' से शुरू होने वाले नियम शामिल नहीं किए जाते हैं. ध्यान रखें कि सिर्फ़ बिना टेस्ट वाले नियम तब तक लागू होते हैं, जब तक कि -- मनपसंद_टेस्ट_टारगेट चालू न हो.
टैग: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 और या तो linkstatic=True या '-static' linkopts में हो. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. जहां ज़रूरी हो वहां हमेशा linklink=1 का इस्तेमाल करना एक बेहतर विकल्प है.
टैग:action_command_lines
,affects_outputs
,deprecated
--linkopt=<a string>
बार कई बार इस्तेमाल किया गया-
लिंक करते समय gcc में पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--ltobackendopt=<a string>
बार कई बार इस्तेमाल किया गया-
एलटीओ बैकएंड चरण में जाने के लिए अतिरिक्त विकल्प (-feature=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
डिफ़ॉल्ट: "गलत"-
अगर इस मोड को सेट किया जाता है और 'dbg' पर सेट किया जाता है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC और GLIBसीपी_CONCEPT_CheckS के बारे में बताएं.
टैग:action_command_lines
--[no]objc_enable_binary_stripping
डिफ़ॉल्ट: "गलत"-
लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी हैं या नहीं. अगर इस फ़्लैग और --compilation_mode=opt दोनों के बारे में बताया गया हो, तो बाइनरी स्ट्रिपिंग किए जाएंगे.
टैग:action_command_lines
--objccopt=<a string>
बार कई बार इस्तेमाल किया गया-
Objective-C/C++ सोर्स फ़ाइलें कंपाइल करते समय gcc में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई बार इस्तेमाल किया गया-
कुछ फ़ाइलों को कंपाइल करते समय, विकल्प के तौर पर 'गुप्त कॉपी' पास करने के लिए कुछ और विकल्प. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter का मतलब है, रेगुलर एक्सप्रेशन के पैटर्न को शामिल करना और बाहर रखना. (यह भी देखें -- इंस्ट्रूमेंटेशन_फ़िल्टर). विकल्प_1 का मतलब है आर्बिट्रेरी कमांड लाइन विकल्प. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना ज़रूरी है. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में .cc/
टैग: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>
बार कई बार इस्तेमाल किया गया-
कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड को (चुनिंदा सुविधाओं में=thin_lto) भेजने के लिए, चुनिंदा विकल्प चुने जाते हैं. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, सूची की सूची और रेगुलर एक्सप्रेशन के पैटर्न को शामिल नहीं करता है. Option_1 का मतलब है आर्बिट्रेरी कमांड लाइन विकल्प. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना ज़रूरी है. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\.o,-//foo/bar\.o@-O0, ofoo में सभी o फ़ाइलों के LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.वे बिड को //foo/ में नहीं छोड़ सकते.
टैग:action_command_lines
,affects_outputs
--platform_suffix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
कॉन्फ़िगरेशन डायरेक्ट्री में जोड़ा जाने वाला सफ़िक्स बताता है.
टैग:loses_incremental_state
,affects_outputs
,loading_and_analysis
--propeller_optimize=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propels प्रोफ़ाइल की जानकारी का इस्तेमाल करें.प्रोपेलर प्रोफ़ाइल में, कम से कम दो फ़ाइलों में से एक की कॉपी और एक प्रोफ़ाइल होनी चाहिए. यह फ़्लैग एक बिल्ड लेबल को स्वीकार करता है. इसे प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों के बारे में बताना चाहिए. उदाहरण के लिए, लेबल की पहचान करने वाली BUILD फ़ाइल, a/b/BUILD:propel_optimize( name = "propel_profile", cc_profile = "propel_cc_profile.txt", ld_profile = "propel_ld_profile.txt",) में, index_files डायरेक्टिव को इन फ़ाइलों में लिखा जाना चाहिए, ताकि ये फ़ाइलें बेज़ल को दिखें. इस विकल्प का इस्तेमाल, इन चीज़ों के लिए किया जाना चाहिए: --propel_optimize=//a/b:propel_profile
टैग:action_command_lines
,affects_outputs
--propeller_optimize_absolute_cc_profile=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
प्रोपेलर ऑप्टिमाइज़ वाले बिल्ड के लिए, cc_profile फ़ाइल का पूरा पाथ नाम.
टैग:affects_outputs
--propeller_optimize_absolute_ld_profile=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
प्रोपेलर ऑप्टिमाइज़ वाले बिल्ड के लिए ld_profile फ़ाइल का पूरा पाथ नाम.
टैग:affects_outputs
--run_under=<a prefix in front of command>
डिफ़ॉल्ट: ब्यौरा देखें- 'टेस्ट' और 'रन' कमांड के लिए, एक्ज़ीक्यूट करने से पहले शुरू करने के लिए उपसर्ग लगाएं. अगर वैल्यू 'foo -bar' है और एक्ज़ीक्यूशन कमांड लाइन 'test_binary -baz' है, तो आखिरी कमांड लाइन 'foo -bar test_binary -baz' होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. कुछ उदाहरण: 'valgrind', 'strace', 'strace -c', 'valgrind --quiet --num-callers=20', '//package:target', '//package:target --options'.
टैग:action_command_lines
-
अगर सही है, तो एक जैसी सुविधाओं वाली नेटिव लाइब्रेरी अलग-अलग टारगेट में शेयर की जाएंगी
टैग:loading_and_analysis
,affects_outputs
--[no]stamp
डिफ़ॉल्ट: "गलत"-
बाइनरी के साथ तारीख, उपयोगकर्ता नाम, होस्टनेम, फ़ाइल फ़ोल्डर की जानकारी वगैरह स्टैंप करें
टैग:affects_outputs
--strip=<always, sometimes or never>
डिफ़ॉल्ट: "कभी-कभी"-
यह बताता है कि बाइनरी और शेयर की गई लाइब्रेरी को "-Wl---strip-debug" का इस्तेमाल करके हटाना है या नहीं). 'कभी-कभी' की डिफ़ॉल्ट वैल्यू का मतलब होता है, स्लिप if-compilation_mode=fastbuild.
टैग:affects_outputs
--stripopt=<a string>
बार कई बार इस्तेमाल किया गया- '<name>.striped' बाइनरी जनरेट करते समय स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.
टैग: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_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_sdk_version' का इस्तेमाल करता है.
टैग:loses_incremental_state
--xbinary_fdo=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO की प्रोफ़ाइल जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम डालें. अगर इस विकल्प का इस्तेमाल --fdo_स्टीमेशन/--fdo_optimize/--fdo_profile, साथ किया जाता है, तो ये विकल्प हमेशा लागू होंगे, जैसे कि xbinary_fdo को कभी तय नहीं किया गया है.
टैग:affects_outputs
- वे विकल्प जो इस बात पर असर डालते हैं कि Bazel, बिल्ड के मान्य इनपुट को किस तरह लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--auto_cpu_environment_group=<a build target label>
डिफ़ॉल्ट: ""-
सीपीयू वैल्यू को target_Environment वैल्यू के साथ अपने-आप मैप करने के लिए,Environment_group का एलान करें.
टैग:changes_inputs
,loading_and_analysis
,experimental
--[no]check_licenses
डिफ़ॉल्ट: "गलत"-
जांच लें कि डिपेंडेंट पैकेज के ज़रिए लागू की गई लाइसेंस देने की सीमाएं, बनाए जा रहे टारगेट के डिस्ट्रिब्यूशन मोड पर असर नहीं डालती हैं. डिफ़ॉल्ट रूप से, लाइसेंस की जांच नहीं की जाती है.
टैग:build_file_semantics
--[no]check_visibility
डिफ़ॉल्ट: "सही"-
अगर यह नीति बंद है, तो डिपेंडेंसी के लिए टारगेट डिपेंडेंसी में गड़बड़ियों को कम किया जाता है.
टैग:build_file_semantics
--[no]desugar_for_android
डिफ़ॉल्ट: "सही"-
चाहे वे डेक्सिंग करने से पहले देसूर Java 8 बाइटकोड लें या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]desugar_java8_libs
डिफ़ॉल्ट: "गलत"-
पुराने डिवाइसों के लिए, ऐप्लिकेशन में काम करने वाली Java 8 लाइब्रेरी शामिल करनी हैं या नहीं.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]enforce_constraints
डिफ़ॉल्ट: "सही"-
हर टारगेट के साथ काम करने वाले एनवायरमेंट की जांच करता है. साथ ही, अगर किसी टारगेट में ऐसी डिपेंडेंसी है जो एक ही एनवायरमेंट के साथ काम नहीं करती हैं, तो वह गड़बड़ियां बताता है
टैग:build_file_semantics
--[no]experimental_allow_android_library_deps_without_srcs
डिफ़ॉल्ट: "गलत"-
डेस्क से, बिना src वाले 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
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो आउटपुट फ़ाइलों के लिए ज़रूरी जांच वाले फ़ॉर्मैट की जांच करें. इसके लिए, जांच करने के नियम का सिर्फ़ टेस्ट देखें. यह विज़िबिलिटी चेकिंग से मेल खाता है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_check_visibility_for_toolchains
डिफ़ॉल्ट: "गलत"-
चालू होने पर, विज़िबिलिटी चेकिंग टूल लागू करने की प्रोसेस पर भी लागू होती है.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disable_native_android_rules
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो नेटिव Android के नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rule_android से Starlark Android नियमों का उपयोग करें
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_disable_native_apple_binary_rule
डिफ़ॉल्ट: "गलत"-
नहीं. पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया था.
टैग:eagerness_to_exit
,incompatible_change
--[no]incompatible_force_strict_header_check_from_starlark
डिफ़ॉल्ट: "सही"-
अगर यह सुविधा चालू है, तो Starlark API में हेडर हेडर की सख्त जांच सेट करें
टैग:loading_and_analysis
,changes_inputs
,incompatible_change
--[no]incompatible_python_disable_py2
डिफ़ॉल्ट: "सही"-
सही होने पर, Python 2 की सेटिंग का इस्तेमाल करने से गड़बड़ी होगी. इसमें python_version=PY2, srcs_version=PY2, और srcs_version=PY2सिर्फ़ शामिल हैं. ज़्यादा जानकारी पाने के लिए, https://github.com/bazelbuild/bazel/issues/15684 पर जाएं.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_validate_top_level_header_inclusions
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, टॉप लेवल डायरेक्ट्री हेडर को शामिल करने की पुष्टि भी करेगा (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/10047 देखें).
टैग:loading_and_analysis
,incompatible_change
--python_native_rules_allowlist=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
अनुमति वाली सूची (पैकेज_ग्रुप टारगेट) लागू करते समय इस्तेमाल करना.
टैग:loading_and_analysis
--[no]strict_filesets
डिफ़ॉल्ट: "गलत"-
अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलें, गड़बड़ी के तौर पर रिपोर्ट किए जाते हैं. अगर यह चेक_fileset_dependencies_recursive को बंद किया गया है, तो यह काम नहीं करेगा.
टैग:build_file_semantics
,eagerness_to_exit
--strict_proto_deps=<off, warn, error, strict or default>
डिफ़ॉल्ट: "गड़बड़ी"-
जब तक यह बंद न हो, तब तक यह जांच करता है कि प्रोटो_लाइब्रेरी का टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर दिखाता है.
टैग:build_file_semantics
,eagerness_to_exit
,incompatible_change
--strict_public_imports=<off, warn, error, strict or default>
डिफ़ॉल्ट: "बंद" है-
जब तक यह बंद न हो, तब तक यह जांच की जाती है कि प्रोटो_लाइब्रेरी का टारगेट, 'सार्वजनिक तौर पर इंपोर्ट करें' में एक्सपोर्ट किए गए सभी टारगेट को साफ़ तौर पर बताता है या नहीं.
टैग:build_file_semantics
,eagerness_to_exit
,incompatible_change
--[no]strict_system_includes
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो सिस्टम से मिले हेडर में पाथ (-isystem) शामिल करने की ज़रूरत पड़ती है.
टैग:loading_and_analysis
,eagerness_to_exit
--target_environment=<a build target label>
बार कई बार इस्तेमाल किया गया-
इस बिल्ड के लिए टारगेट एनवायरमेंट की जानकारी देता है. "परिवेश" नियम के हिसाब से कोई लेबल होना चाहिए. अगर बताया गया हो, तो सभी टॉप-लेवल टारगेट का इस एनवायरमेंट के साथ काम करना ज़रूरी है.
टैग:changes_inputs
- ऐसे विकल्प जो किसी बिल्ड के साइनिंग आउटपुट पर असर डालते हैं:
--apk_signing_method=<v1, v2, v1_v2 or v4>
डिफ़ॉल्ट: "v1_v2"-
APK को साइन करने के लिए इस्तेमाल करना
टैग:action_command_lines
,affects_outputs
,loading_and_analysis
--[no]device_debug_entitlements
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है और कंपाइल करने वाला मोड 'ऑप्ट-इन' नहीं किया जाता है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल हो जाएंगे.
टैग:changes_inputs
--ios_signing_cert_name=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
iOS साइनिंग के लिए इस्तेमाल किया जाने वाला सर्टिफ़िकेट नाम. इस नीति को सेट न करने पर, यह प्रावधान वाली प्रोफ़ाइल के तौर पर सेट हो जाएगा. कोडसाइन के मैन पेज (SIGNING IDENTITIES) के अनुसार, सर्टिफ़िकेट के आम तौर पर इस्तेमाल होने वाले नाम की सर्टिफ़िकेट की कुंजी या सबस्ट्रिंग हो सकती है.
टैग:action_command_lines
- यह विकल्प Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों से ऐक्सेस करने लायक बिल्ड एपीआई पर असर डालता है.:
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "गलत"-
अगर यह काम नहीं करता है, तो यह ग़ैर-ज़रूरी है. अगर यह फ़्लैग गलत है, तो //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_disallow_sdk_frameworks_attributes
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो objc_library औरobjc_export में sdk_frameworks और Weak_sdk_frameworks एट्रिब्यूट की अनुमति नहीं दें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर सही है, तो config_setting दिखने से जुड़ी पाबंदियां लागू करें. गलत होने पर, हर config_setting हर टारगेट को दिखती है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_objc_alwayslink_by_default
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो objc_library और objc_Import पर हमेशा लिंक करने वाले एट्रिब्यूट के लिए, डिफ़ॉल्ट वैल्यू को सही पर सेट करें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_python_disallow_native_rules
डिफ़ॉल्ट: "गलत"-
सही होने पर, पहले से मौजूद py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, Rules_python के नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.
टैग:loading_and_analysis
,incompatible_change
- ऐसे विकल्प जो टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करते हैं:
--[no]allow_analysis_failures
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो नियम के टारगेट की जांच में हुई गड़बड़ी की वजह से विश्लेषण में गड़बड़ी हुई.
टैग:loading_and_analysis
,experimental
--analysis_testing_deps_limit=<an integer>
डिफ़ॉल्ट: "2000"-
for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट की मदद से ट्रांज़िशन करने वाली ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा को पार करने पर नियम में गड़बड़ी हो सकती है.
टैग:loading_and_analysis
--[no]break_build_on_parallel_dex2oat_failure
डिफ़ॉल्ट: "गलत"-
अगर सही Dex2oat कार्रवाई नहीं हो पाती है, तो टेस्ट रनटाइम के दौरान dex2oat चलाने के बजाय बिल्ड टूट सकता है.
टैग:loading_and_analysis
,experimental
--[no]check_tests_up_to_date
डिफ़ॉल्ट: "गलत"-
जांच न करें, बस देखें कि वे अप-टू-डेट हैं या नहीं. अगर जांच के सभी नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर कोई जांच करने या उसे लागू करने की ज़रूरत होती है, तो गड़बड़ी की रिपोर्ट की जाती है और जांच नहीं हो पाती है. यह विकल्प --check_up_to_date व्यवहार का मतलब है.
टैग:execution
--[no]experimental_android_use_parallel_dex2oat
डिफ़ॉल्ट: "गलत"-
android_test को तेज़ी से लोड करने के लिए, dex2oat का इस्तेमाल एक साथ करें.
टैग:loading_and_analysis
,host_machine_resource_optimizations
,experimental
--flaky_test_attempts=<a positive integer, the string "default", or test_regex@attempts. This flag may be passed more than once>
बार कई बार इस्तेमाल किया गया-
जांच में कोई गड़बड़ी होने पर, हर बार कोशिश की जाएगी कि यह तय संख्या में बार-बार की जाए. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश करनी पड़ती है उन्हें टेस्ट की खास जानकारी में 'FLAKY' के तौर पर मार्क किया जाता है. आम तौर पर, तय की गई वैल्यू सिर्फ़ एक पूर्णांक या स्ट्रिंग 'डिफ़ॉल्ट' होती है. अगर पूर्णांक है, तो सभी टेस्ट N बार तक चलाए जाएंगे. अगर 'डिफ़ॉल्ट' है, तो सामान्य जांचों के लिए सिर्फ़ एक बार कोशिश की जाएगी. साथ ही, उन जांचों के लिए तीन कोशिश की जाएगी जो उनके नियम (flaky=1 एट्रिब्यूट) के तौर पर साफ़ तौर पर मार्क की गई हैं. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. जहां flky_test_attempts ऊपर है, तो regex_filter रेगुलर एक्सप्रेशन के पैटर्न को शामिल करने और बाहर रखने के लिए है (और देखें --runs_per_test). उदाहरण: --flaky_test_attempts=//foo/.*,-//foo/bar/.*@3 foo/bar में तीन बार होने वाले टेस्ट को छोड़कर //foo/में सभी टेस्ट को डीफ़्लेक्स करता है. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सबसे हाल ही में पास होने वाले आर्ग्युमेंट को प्राथमिकता मिलती है. अगर कुछ भी मेल नहीं खाता है, तो इसे ऊपर दिए गए 'डिफ़ॉल्ट' की तरह माना जाएगा.
टैग:execution
--[no]ios_memleaks
डिफ़ॉल्ट: "गलत"-
ios_test टारगेट में मेमोरी लीक की जांच करें.
टैग:action_command_lines
--ios_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में मौजूद iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किया जाने वाला डिवाइस. उदाहरण के लिए, 'iPhone 6'. आप सिम्युलेटर पर उस डिवाइस पर 'xcrun simctl list devicetype' चलाकर डिवाइसों की सूची पा सकते हैं जिस पर सिम्युलेटर चलेगा.
टैग:test_runner
--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
चल रहा या टेस्ट करते समय, सिम्युलेटर पर चलने वाला iOS का वर्शन. अगर टारगेट डिवाइस की जानकारी नियम में दी गई है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.
टैग:test_runner
--local_test_jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "अपने-आप"-
एक साथ चलाने के लिए, स्थानीय टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. पूर्णांक लेता है या कीवर्ड ("ऑटो", "होस्ट_सीपीएस"), वैकल्पिक रूप से इसके बाद कार्रवाई ([-|**]<फ़्लो>) लगता है "auto", "Host_CPUS*.5". 0 का मतलब है कि स्थानीय संसाधन, स्थानीय टेस्ट जॉब की संख्या को सीमित कर देंगे. इसके बजाय, वे एक साथ काम करेंगे. इसे -- --नौकरी के लिए वैल्यू से ज़्यादा सेट करने पर कोई असर नहीं पड़ता.
टैग:execution
--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once>
बार कई बार इस्तेमाल किया गया- हर जांच को चलाने की संख्या तय करता है. अगर कोई भी वजह किसी भी वजह से पूरी नहीं हो पाती है, तो पूरी जांच को फ़ेल माना जाता है. आम तौर पर, तय की गई वैल्यू सिर्फ़ एक पूर्णांक होती है. उदाहरण: --runs_per_test=3 सभी टेस्ट को तीन बार चलाएगा. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. जहां Run_per_test एक इंटेजर मान को दर्शाता है, और regex_filter का मतलब है रेगुलर एक्सप्रेशन पैटर्न को शामिल करना और बाहर रखना (यह भी देखें -- इंस्ट्रूमेंटेशन_फ़िल्टर). उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3 foo/bar के अलावा तीन बार //foo/में सभी टेस्ट चलाता है. इस विकल्प को एक से ज़्यादा बार पास किया जा सकता है. सबसे हाल ही में पास होने वाले आर्ग्युमेंट को प्राथमिकता मिलती है. अगर कुछ भी मेल नहीं खाता है, तो जांच सिर्फ़ एक बार की जाएगी.
--test_env=<a 'name=value' assignment with an optional value part>
बार कई बार इस्तेमाल किया गया-
यह, टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अन्य एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल, नाम से तय किए जा सकते हैं. ऐसा होने पर, इसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से या name=value जोड़े से पढ़ी जाएगी. इस विकल्प का इस्तेमाल कई वैरिएबल के बारे में बताने के लिए कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'बेज़ल टेस्ट' निर्देश से किया जाता है.
टैग: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>
डिफ़ॉल्ट: ब्यौरा देखें- यह 'बेज़ल टेस्ट' के लिए आधार अस्थायी डायरेक्ट्री तय करता है.
--tvos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में, TOS ऐप्लिकेशन को चलाने के दौरान सिम्युलेट किया गया डिवाइस, जैसे कि 'Apple TV 1080p'. आप सिम्युलेटर पर उस डिवाइस पर 'xcrun simctl list devicetype' चलाकर डिवाइसों की सूची पा सकते हैं जिस पर सिम्युलेटर चलेगा.
टैग:test_runner
--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
चलने या टेस्ट करने के दौरान, सिम्युलेटर पर tvOS का वर्शन.
टैग:test_runner
--watchos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर डिवाइस, जिस पर सिम्युलेटर चलाते समय स्मार्टवॉच का ऐप्लिकेशन इस्तेमाल किया जा सकता है. उदाहरण के लिए, 'Apple Watch - 38 मि॰मी॰'. आप सिम्युलेटर पर उस डिवाइस पर 'xcrun simctl list devicetype' चलाकर डिवाइसों की सूची पा सकते हैं जिस पर सिम्युलेटर चलेगा.
टैग: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
डिफ़ॉल्ट: "सही"-
चालू होने पर, ग़ैर-ज़रूरी -- शायद तय की गई चीज़ें, बिल्ड की शुरुआत में ही हटा दी जाएंगी. इससे, कुछ खास तरह के बिल्ड के लिए, विश्लेषण की कैश मेमोरी में होने वाली कमी से बचा जा सकता है.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_filter_library_jar_with_program_jar
डिफ़ॉल्ट: "गलत"-
लाइब्रेरीजेर में मौजूद किसी भी क्लास को हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग:action_command_lines
--[no]experimental_inmemory_dotd_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, C++ .d फ़ाइलों को डिस्क में लिखने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_inmemory_jdeps_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलें, डिस्क में लिखे जाने के बजाय सीधे रिमोट बिल्ड नोड से मेमोरी में पास होंगी.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_objc_include_scanning
डिफ़ॉल्ट: "गलत"-
C-C++ के मकसद के लिए स्कैनिंग शामिल करें या नहीं.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]experimental_retain_test_configuration_across_testonly
डिफ़ॉल्ट: "गलत"-
चालू होने पर, --trim_test_config, testonly=1 के रूप में मार्क किए गए नियमों के लिए टेस्ट कॉन्फ़िगरेशन में काट-छांट नहीं की जाएगी. इसका मकसद उन मामलों में कार्रवाई की समस्याओं को कम करना है जब जांच के नियम cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_config 'गलत' है, तो कोई असर नहीं पड़ता.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_starlark_cc_import
डिफ़ॉल्ट: "गलत"-
चालू होने पर, cc_Import के Starlark वर्शन का इस्तेमाल किया जा सकता है.
टैग:loading_and_analysis
,experimental
--[no]experimental_unsupported_and_brittle_include_scanning
डिफ़ॉल्ट: "गलत"-
इनपुट फ़ाइलों से #include लाइन को पार्स करके, C/C++ कंपाइलेशन को छोटा करके इनपुट करें. यह कंपाइलेशन इनपुट ट्री के साइज़ को कम करके, परफ़ॉर्मेंस को बेहतर बनाने और परफ़ॉर्मेंस को बेहतर बनाने के लिए इस्तेमाल किया जा सकता है. हालांकि, यह बिल्ड को भी तोड़ सकता है, क्योंकि शामिल करने वाला स्कैनर, सी प्रीप्रोसेसर सिमेंटिक को पूरी तरह लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता है और प्रीप्रोसेसर कंडीशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. शिकायत किए गए इस फ़्लैग से जुड़ी सभी समस्याओं को बंद कर दिया जाएगा.
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]incremental_dexing
डिफ़ॉल्ट: "सही"-
ज़्यादातर Java फ़ाइल के लिए, डेक्सिंग का अलग-अलग काम करता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]objc_use_dotd_pruning
डिफ़ॉल्ट: "सही"-
अगर सेट की गई, तो clang की ओर से उत्सर्जित की जाने वाली .d फ़ाइलों का इस्तेमाल, objc कंपाइल में भेजे जाने वाले इनपुट सेट को हटाने के लिए किया जाएगा.
टैग:changes_inputs
,loading_and_analysis
--[no]process_headers_in_dependencies
डिफ़ॉल्ट: "गलत"-
कोई टारगेट //a:a बनाते समय, सभी टारगेट में //a:a वाले हेडर प्रोसेस होते हैं (अगर टूलचेन के लिए हेडर प्रोसेसिंग चालू होती है).
टैग:execution
--[no]trim_test_configuration
डिफ़ॉल्ट: "सही"-
चालू होने पर, टेस्ट से जुड़े विकल्प, बिल्ड के ऊपरी लेवल से नीचे हटा दिए जाएंगे. अगर यह फ़्लैग चालू है, तो टेस्ट को नॉन-टेस्ट नियमों के लिए डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने पर, नॉन-टेस्ट नियमों का दोबारा विश्लेषण नहीं होगा.
टैग:loading_and_analysis
,loses_incremental_state
--[no]use_singlejar_apkbuilder
डिफ़ॉल्ट: "सही"-
इस विकल्प के इस्तेमाल पर रोक लगा दी गई है. इस पर अब कोई कार्रवाई नहीं होगी. इसे जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
- ऐसे विकल्प जो बोली की जानकारी, फ़ॉर्मैट, या जगह की जानकारी पर असर डालते हैं:
--[no]announce
डिफ़ॉल्ट: "गलत"-
अब सेवा में नहीं है. नहीं.
टैग:affects_outputs
--[no]experimental_bep_target_summary
डिफ़ॉल्ट: "गलत"- टारगेट की गई खास जानकारी वाले इवेंट प्रकाशित करने हैं या नहीं.
--[no]experimental_build_event_expand_filesets
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो आउटपुट फ़ाइलें दिखाते समय, बीईपी में Filesसेट को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "गलत"-
सही होने पर, आउटपुट फ़ाइलें प्रज़ेंट करते समय, बीईपी के मिलते-जुलते 'फ़ाइलसेट' सिमलिंक का पूरी तरह से समाधान करें. --experimental_build_event_expand_filessets की ज़रूरत है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
Bez को बिल्ड इवेंट को फिर से अपलोड करने की कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
डिफ़ॉल्ट: "1s"-
बीईपी अपलोड नहीं हो पाने पर, एक्सपोनेंशियल बैकऑफ़ बार-बार कोशिश करने पर लगने वाला कम से कम समय. (एक्सपोनेंट: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह पेज, बिल्ड इवेंट प्रोटोकॉल में बताए गए आर्टफ़ैक्ट को अपलोड करने का तरीका चुनता है.
टैग:affects_outputs
--[no]experimental_materialize_param_files_directly
डिफ़ॉल्ट: "गलत"-
अगर पैरामीटर की फ़ाइलों को मटीरियल से हटाया जा रहा है, तो सीधे डिस्क में जाकर ऐसा करें.
टैग:execution
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "गलत"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय उन्हें सीधे रिमोट स्टोरेज में अपलोड करें.
टैग:affects_outputs
--explain=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड सिस्टम से बिल्ड के हर एक चरण की जानकारी मिलती है. जानकारी बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग:affects_outputs
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
इसका इस्तेमाल करें, ताकि Targetcomplete इवेंट में जानदार लेगसी आउटपुट आउटपुट फ़ील्ड को बंद किया जा सके.
टैग:affects_outputs
--[no]materialize_param_files
डिफ़ॉल्ट: "गलत"-
रिमोट ट्री का इस्तेमाल करके आउटपुट आउटपुट ट्री में भी लिखता है. भले ही, रिमोट ऐक्शन का इस्तेमाल किया जा रहा हो. यह डीबग करने में मदद करता है. यह --सबकॉमैंड्स और --verbose_failures से पता चलता है.
टैग:execution
--max_config_changes_to_show=<an integer>
डिफ़ॉल्ट: "3"-
बिल्ड के विकल्पों में हुए बदलाव की वजह से विश्लेषण कैश को खारिज करने पर, बदले गए विकल्पों के नामों की संख्या दिखती है. अगर दी गई संख्या -1 है, तो सभी बदले गए विकल्प दिखाए जाएंगे.
टैग:terminal_output
- डिफ़ॉल्ट
--max_test_output_bytes=<an integer>
: "-1" -
-टेस्ट लॉग का सबसे बड़ा साइज़ तब तय किया जाता है, जब --test_ आउटपुट 'गड़बड़ी' या 'सभी' हो. इसकी मदद से, बहुत ज़्यादा शोर वाले टेस्ट आउटपुट से, आउटपुट पर पड़ने वाले असर से बचने में मदद मिलती है. टेस्ट हेडर, लॉग साइज़ में शामिल होता है. नकारात्मक मानों की कोई सीमा नहीं है. आउटपुट कुछ भी नहीं है.
टैग:test_runner
,terminal_output
,execution
--output_filter=<a valid Java regular expression>
डिफ़ॉल्ट: ब्यौरा देखें-
सिर्फ़ उन नियमों के लिए चेतावनियां दिखाता है जिनका नाम दिए गए रेगुलर एक्सप्रेशन से मेल खाता है.
टैग:affects_outputs
--progress_report_interval=<an integer in 0-3600 range>
डिफ़ॉल्ट: "0"-
अभी भी चल रही नौकरियों की रिपोर्ट के बीच कुल सेकंड. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट होगी. इसके बाद, 30 सेकंड प्रोसेस होगी और उसके बाद, हर मिनट एक बार रिपोर्ट की जाएगी. जब --कर्सर चालू होते हैं, तो हर सेकंड की प्रोग्रेस रिपोर्ट की जाती है.
टैग:affects_outputs
--show_result=<an integer>
डिफ़ॉल्ट: "1"-
बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए, यह बताएं कि उसे अप-टू-डेट रखा गया था या नहीं. अगर हां, तो बनाई गई आउटपुट फ़ाइलों की सूची. प्रिंट की गई फ़ाइलें शेल में कॉपी+पेस्ट करने के लिए आसान स्ट्रिंग हैं, ताकि उन्हें चलाया जा सके.
इस विकल्प के लिए एक पूर्णांक तर्क होना ज़रूरी है, जो उन टारगेट की थ्रेशोल्ड संख्या होती है जिनके ऊपर नतीजे की जानकारी प्रिंट नहीं की जाती. इसलिए, शून्य होने से मैसेज छिप जाता है. MAX_INT नतीजे को प्रिंट करने की वजह हमेशा होती है. डिफ़ॉल्ट वैल्यू एक होती है.
अगर टारगेट के लिए कुछ भी नहीं बनाया गया है, तो इसके नतीजों को थ्रेशोल्ड के नीचे रखने के लिए नतीजों को हटाया जा सकता है.
टैग:affects_outputs
--[no]subcommands
[-s
] डिफ़ॉल्ट: "गलत"-
बिल्डिंग के दौरान चलाए गए सबकॉमैंड को दिखाएं. इससे जुड़े फ़्लैग: --execution_log_json_file, --execution_log_binary_file (टूल के साथ काम करने वाले फ़ॉर्मैट में फ़ाइल में सबकॉमैंड को लॉग करने के लिए).
टैग:terminal_output
--test_output=<summary, errors, all or streamed>
डिफ़ॉल्ट: "खास जानकारी"-
ज़रूरी आउटपुट मोड के बारे में बताता है. मान्य वैल्यू, सिर्फ़ आउटपुट की जांच की स्थिति की खास जानकारी के लिए 'खास जानकारी' होती हैं. इसमें, जांच न हो पाने वाले टेस्ट लॉग को भी 'गड़बड़ी' के तौर पर प्रिंट किया जाता है. सभी टेस्ट के लिए 'सभी' प्रिंट करें और सभी टेस्ट के लिए, आउटपुट लॉग में 'स्ट्रीम की गई' वैल्यू डालें. इससे, टेस्ट को एक-एक करके स्थानीय तौर पर एक्ज़ीक्यूट किया जाएगा, चाहे --test_strategi वैल्यू कुछ भी हो.
टैग: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
डिफ़ॉल्ट: "गलत"-
अगर --plain की सुविधा चालू हो, तो दिए गए एक्सप्लेनेशंस की जानकारी पाने की सेटिंग में बदलाव किया जाता है. अगर --plain की सुविधा चालू नहीं है, तो कोई असर नहीं पड़ेगा.
टैग:affects_outputs
--[no]verbose_failures
डिफ़ॉल्ट: "गलत"-
अगर कोई निर्देश नहीं मिलता, तो पूरी कमांड लाइन का प्रिंट लें.
टैग:terminal_output
- किसी सामान्य इनपुट के बारे में बताने या उसे बदलने वाले ऐसे विकल्प जो किसी दूसरी कैटगरी में नहीं आते हैं:
--aspects_parameters=<a 'name=value' assignment>
बार कई बार इस्तेमाल किया गया-
कमांड-लाइन के आसपेक्ट पैरामीटर की वैल्यू तय करता है. हर पैरामीटर वैल्यू, <param_name>=<param_value> के ज़रिए तय की जाती है, उदाहरण के लिए, 'my_param=my_val', जहां 'my_param', पैरामीटर की सूची में कुछ आसपेक्ट पैरामीटर का पैरामीटर है या सूची में मौजूद किसी पहलू के लिए ज़रूरी है. इस विकल्प का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. हालांकि, एक ही पैरामीटर में वैल्यू एक से ज़्यादा बार असाइन करने की अनुमति नहीं है.
टैग:loading_and_analysis
--flag_alias=<a 'name=value' flag alias>
बार कई बार इस्तेमाल किया गया-
किसी Starstark फ़्लैग के लिए शॉर्टहैंड नाम सेट करता है. यह "<key>=<value>" रूप में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग:changes_inputs
--[no]incompatible_default_to_explicit_init_py
डिफ़ॉल्ट: "गलत"- यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि __init__.py फ़ाइलें Python टारगेट की रनटाइम में अपने-आप न बन जाएं. सटीक रूप से, जब किसी py_binary या py_test टारगेट में legac