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 |
bazel के लिए वर्शन की जानकारी प्रिंट करता है. |
स्टार्टअप विकल्प
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने पार्स किए हैं:
--[no]autodetect_server_javabase
डिफ़ॉल्ट: "सही"-
जब --noautodetect_server_javabase पास हो जाता है, तो बेजल सर्वर चलाने के बजाय, Bazel स्थानीय JDK पर वापस नहीं आता.
टैग:affects_outputs
,loses_incremental_state
--[no]batch
डिफ़ॉल्ट: "गलत"-
अगर यह सेट है, तो Bazel को बिना स्टैंडर्ड क्लाइंट/सर्वर मोड के सर्वर के बजाय क्लाइंट के तौर पर इस्तेमाल किया जाएगा. इसे बहिष्कृत कर दिया गया है और निकाल दिया जाएगा, अगर आप धीमा सर्वर से बचना चाहते हैं, तो कृपया सर्वर को शट डाउन करना पसंद करें.
टैग:loses_incremental_state
,bazel_internal_configuration
,deprecated
--[no]batch_cpu_scheduling
डिफ़ॉल्ट: "गलत"-
सिर्फ़ Linux पर; Blaze के लिए 'बैच' सीपीयू शेड्यूलिंग का इस्तेमाल करें. यह नीति ऐसे वर्कलोड के लिए काम की है जो इंटरैक्टिव नहीं होते, लेकिन उनकी अहमियत को कम नहीं करना चाहते. 'man 2 sted_setScheduler' देखें. अगर गलत हो, तो फिर बेज़ल सिस्टम कॉल नहीं करता है.
टैग: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) z.rc को पिछले /dev/null की वजह से अनदेखा किया जाता है.
अगर यह तय नहीं है, तो Bazel पहले दो .bazelrc फ़ाइल का इस्तेमाल करता है, जो इन दो जगहों पर मिलती है: फ़ाइल फ़ोल्डर की डायरेक्ट्री, फिर उपयोगकर्ता की होम डायरेक्ट्री.
ध्यान दें: कमांड लाइन विकल्प हमेशा bazelrc में किसी भी विकल्प की जगह लेंगे.
टैग:changes_inputs
--[no]block_for_lock
डिफ़ॉल्ट: "सही"-
जब --noblock_for_lock पास हो जाता है, तब बेज़ल रनिंग कमांड के पूरा होने का इंतज़ार नहीं करता, बल्कि तुरंत बाहर निकल जाता है.
टैग:eagerness_to_exit
--[no]client_debug
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो क्लाइंट से डीबग जानकारी को stderr में लॉग करें. इस विकल्प को बदलने से सर्वर रीस्टार्ट नहीं होगा.
टैग:affects_outputs
,bazel_monitoring
--connect_timeout_secs=<an integer>
डिफ़ॉल्ट: "30"-
सर्वर से कनेक्ट करने की हर कोशिश में क्लाइंट के इंतज़ार का समय
टैग:bazel_internal_configuration
--[no]expand_configs_in_place
डिफ़ॉल्ट: "सही"-
सामान्य rc विकल्पों और कमांड-लाइन दिए गए विकल्पों के बीच फ़िक्स पॉइंट एक्सपैंशन के बजाय, कॉन्फ़िगर करने के लिए --config फ़्लैग को उसके स्थान पर करने की सुविधा में बदलाव किया गया.
टैग:no_op
,deprecated
--failure_detail_out=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर यह सेट है, तो अगर सर्वर के काम नहीं कर पाने की स्थिति में, gRPC के ज़रिए इसकी रिपोर्ट नहीं की जा सकती है, तो असफलता के ब्यौरे वाला प्रोटोबफ़ मैसेज लिखने के लिए जगह की जानकारी देता है. नहीं तो, जगह की जानकारी ${Plug_BASE}/failure_detail.rawproto होगी.
टैग:affects_outputs
,loses_incremental_state
--[no]home_rc
डिफ़ॉल्ट: "सही"-
चाहे होम बैज वाली फ़ाइल $HOME/.bazelrc पर देखना हो या नहीं
टैग:changes_inputs
--[no]idle_server_tasks
डिफ़ॉल्ट: "सही"-
सर्वर के कुछ समय से इस्तेमाल में न होने पर, System.gc() चलाएं
टैग:loses_incremental_state
,host_machine_resource_optimizations
--[no]ignore_all_rc_files
डिफ़ॉल्ट: "गलत"-
सभी आरसी फ़ाइलों में बदलाव करता है, आरसीआई-में बदलाव करने वाले दूसरे फ़्लैग के मान चाहे कुछ भी हों, भले ही ये फ़्लैग बाद में स्टार्टअप विकल्पों की सूची में आते हों.
टैग:changes_inputs
--io_nice_level={-1,0,1,2,3,4,5,6,7}
डिफ़ॉल्ट: "-1"-
सिर्फ़ Linux पर; sys_ioprio_set सिस्टम कॉल का इस्तेमाल करके, सबसे अच्छी कोशिश करने वाले IO शेड्यूलिंग के लिए, 0-7 से एक लेवल सेट करें. 0 उच्चतम प्राथमिकता है, 7 सबसे कम है. हो सकता है कि शेड्यूल करने वाले व्यक्ति को प्राथमिकता 4 में ही शामिल किया जाए. अगर वैल्यू नेगेटिव पर सेट है, तो Bazel सिस्टम कॉल नहीं करता है.
टैग:host_machine_resource_optimizations
--local_startup_timeout_secs=<an integer>
डिफ़ॉल्ट: "120"-
सर्वर से कनेक्ट होने में क्लाइंट को ज़्यादा से ज़्यादा कितना समय लगेगा
टैग:bazel_internal_configuration
--macos_qos_class=<a string>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
macOS पर चलने पर, bazel सर्वर की QoS सेवा की क्लास सेट करता है. इस फ़्लैग का दूसरे सभी प्लैटफ़ॉर्म पर कोई असर नहीं पड़ता है. हालांकि, इसकी मदद से यह पक्का किया जा सकता है कि आरसी फ़ाइलों में बिना कोई बदलाव किए इन्हें शेयर किया जा सकता है. संभावित वैल्यू ये हैं: उपयोगकर्ता-इंटरैक्टिव, उपयोगकर्ता की ओर से शुरू की गई, डिफ़ॉल्ट, यूटिलिटी, और बैकग्राउंड.
टैग:host_machine_resource_optimizations
--max_idle_secs=<integer>
डिफ़ॉल्ट: "10800"-
बिल्ड सर्वर को शट डाउन करने से पहले, वह बंद होने में लगने वाला समय. शून्य का मतलब है कि सर्वर कभी भी बंद नहीं होगा. इसे सिर्फ़ सर्वर स्टार्टअप पर पढ़ा जाता है. इस विकल्प को बदलने से सर्वर रीस्टार्ट नहीं होगा.
टैग:eagerness_to_exit
,loses_incremental_state
--output_base=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर यह सेट है, तो आउटपुट वाली उस जगह के बारे में बताता है जहां सभी बिल्ड आउटपुट लिखे जाएंगे. अगर ऐसा नहीं है, तो जगह की जानकारी ${Input_ROOT}/_blaze_${USER}/${MD5_OF_WORKSPACE_ROOT} होगी. नोट: अगर आप इस मान के लिए एक से अगले Bazel शुरू करने की जगह से कोई अलग विकल्प तय करते हैं, तो आप एक नया, अतिरिक्त Bazel सर्वर शुरू करेंगे. Bazel हर तय आउटपुट आधार पर ठीक एक सर्वर शुरू करता है. आम तौर पर, हर फ़ाइल फ़ोल्डर में एक आउटपुट बेस होता है. हालांकि, इस विकल्प से हर फ़ाइल फ़ोल्डर में कई आउटपुट बेस हो सकते हैं. इस तरह, एक ही मशीन पर एक ही क्लाइंट के लिए कई बिल्ड चल सकते हैं. Bazel सर्वर को बंद करने का तरीका जानने के लिए, 'bazel help shutdown' देखें.
टैग:affects_outputs
,loses_incremental_state
--output_user_root=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
उपयोगकर्ता के हिसाब से बनी डायरेक्ट्री, जिसमें सभी बिल्ड आउटपुट लिखे जाते हैं; डिफ़ॉल्ट रूप से, यह $USER का फ़ंक्शन होता है. हालांकि, इसमें कॉन्सटेंट तय करने के बाद, इसे इस्तेमाल करने वाले उपयोगकर्ताओं के साथ शेयर किया जा सकता है.
टैग:affects_outputs
,loses_incremental_state
--[no]preemptible
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो कोई और निर्देश मिलने पर इस निर्देश को रोका जा सकता है.
टैग:eagerness_to_exit
--server_jvm_out=<path>
डिफ़ॉल्ट: ब्यौरा देखें-
सर्वर के जेवीएम का आउटपुट लिखने की जगह. अगर नीति को सेट नहीं किया जाता है, तो डिफ़ॉल्ट रूप से, आउटपुट_बेस की जगह की जानकारी मिल जाती है.
टैग:affects_outputs
,loses_incremental_state
--[no]shutdown_on_low_sys_mem
डिफ़ॉल्ट: "गलत"-
अगर max_idle_secs सेट है और बिल्ड सर्वर कुछ समय से इस्तेमाल में नहीं है, तो सिस्टम में कम रैम की कमी होने पर सर्वर बंद कर दें. सिर्फ़ Linux.
टैग:eagerness_to_exit
,loses_incremental_state
--[no]system_rc
डिफ़ॉल्ट: "सही"-
चाहे पूरे सिस्टम का बैजल लगाना हो या नहीं.
टैग:changes_inputs
--[no]unlimit_coredumps
डिफ़ॉल्ट: "गलत"-
सामान्य स्थितियों में सर्वर (जेवीएम सहित) और क्लाइंट के कोरडंप बनाने के लिए सॉफ़्ट कोरडंप सीमा को हार्ड सीमा तक बढ़ा देता है. अपने फ़्लैग को एक बार अपने बैजल में चिपकाएं और इसके बारे में भूल जाएं ताकि आपको कोई ऐसी स्थिति मिले जब वे ट्रिगर हो जाएं.
टैग:bazel_internal_configuration
--[no]watchfs
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो बेज़ल बदलाव करने के लिए, हर फ़ाइल को स्कैन करने के बजाय, लोकल बदलावों के लिए ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करता है.
टैग: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>
बार कई इस्तेमाल किए गए- BVM को प्रोसेस करने वाले 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>
डिफ़ॉल्ट: ""- प्रोफ़ाइलर/डीबगर के लिए खास जेवीएम स्टार्टअप फ़्लैग जोड़ने का सुविधा विकल्प. बेज़ेल में उन जाने-पहचाने मानों की सूची है जिन्हें वह हार्ड कोड किए गए जेवीएम स्टार्टअप फ़्लैग के साथ मैप करता है. यह शायद कुछ फ़ाइलों के लिए हार्डकोड किए गए कुछ पाथ खोज रहा है.
--server_javabase=<jvm path>
डिफ़ॉल्ट: ""- BVM को चलाने के लिए इस्तेमाल किए गए जेवीएम का पाथ.
सभी निर्देशों के लिए, ये विकल्प सामान्य हैं
- बिल्डिंग निष्पादन को नियंत्रित करने वाले विकल्प:
--experimental_oom_more_eagerly_threshold=<an integer>
डिफ़ॉल्ट: "100"-
अगर इस फ़्लैग को 100 से कम के मान पर सेट किया गया है, तो बाज़ेल तब ही OOM करेगा, जब GC के दो पूरे होने के बाद भी (पुरानी पीढ़ी) के हीप का इस्तेमाल प्रतिशत में होगा.
टैग:host_machine_resource_optimizations
--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range>
डिफ़ॉल्ट: "1048576"-
stdout / stderr फ़ाइलों का ज़्यादा से ज़्यादा साइज़, जिसे कंसोल पर प्रिंट किया जाएगा. -1 का मतलब है कि कोई सीमा तय नहीं है.
टैग:execution
- ऐसे विकल्प जो उपयोगकर्ता को उसके आउटपुट के मुताबिक, सही आउटपुट को कॉन्फ़िगर करने देते हैं, इससे उसकी वैल्यू पर असर पड़ता है:
--repo_env=<a 'name=value' assignment with an optional value part>
बार कई इस्तेमाल किए गए-
इससे सिर्फ़ उन वैरिएबल के बारे में पता चलता है जो सिर्फ़ रिपॉज़िटरी नियमों के लिए उपलब्ध हैं. ध्यान दें कि डेटा स्टोर करने के नियमों में फिर भी पूरा एनवायरमेंट दिखता है, लेकिन इस तरह से कार्रवाई ग्राफ़ को अमान्य किए बिना ही विकल्पों की मदद से डेटा स्टोर करने की जगह पर कॉन्फ़िगरेशन की जानकारी भेजी जा सकती है.
टैग:action_command_lines
- वे विकल्प जो यह तय करते हैं कि Bazel, बिल्ड के मान्य इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--[no]check_bzl_visibility
डिफ़ॉल्ट: "सही"-
अगर इस सेटिंग को 'बंद है' पर सेट किया जाता है, तो .bzl लोड होने से जुड़ी गड़बड़ियां कम हो जाती हैं. चेतावनियां मिलने की संख्या कम हो जाती है.
टैग:build_file_semantics
- यह विकल्प Starlark की भाषा के सिमेंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE की फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.:
--[no]enable_bzlmod
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bzlmod डिपेंडेंसी मैनेजमेंट सिस्टम चालू हो जाता है और WORKSPACE को प्राथमिकता दी जाती है. ज़्यादा जानकारी के लिए, https://bazel.build/build/bzlmod पर जाएं.
टैग:loading_and_analysis
--[no]experimental_action_resource_set
डिफ़ॉल्ट: "सही"-
अगर यह नीति 'सही है' पर सेट है, तो ctx.action.run() और ctx.action.run_shell() प्रोसेस को पूरा करने के लिए, संसाधन_सेट पैरामीटर को स्वीकार करते हैं. इसके अलावा, मेमोरी और 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
डिफ़ॉल्ट: "सही"-
अगर इसे चालू किया गया है, तो एक 'किसको दिखे'` फ़ंक्शन जोड़ता है. <bzl फ़ाइलें, लोड() स्टेटमेंट के लिए अपनी विज़िबिलिटी सेट करने के लिए, टॉप-लेवल की जांच के दौरान कॉल कर सकती हैं.
टैग:loading_and_analysis
,experimental
-
सही पर सेट होने पर, cc_shared_library नियम के लिए ज़रूरी नियम और एट्रिब्यूट और Starlark एपीआई के तरीके उपलब्ध होंगे
टैग:build_file_semantics
,loading_and_analysis
,experimental
--[no]experimental_disable_external_package
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो अपने-आप जनरेट होने वाला //बाहरी पैकेज अब उपलब्ध नहीं होगा. Bazel अब भी फ़ाइल 'बाहरी/BUILD' को पार्स नहीं कर पाएगा. हालांकि, बिना नाम वाले पैकेज से बाहरी// तक पहुंचने वाले ग्लोब काम करेंगे.
टैग:loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_enable_android_migration_apis
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो Android Starlark माइग्रेशन के लिए ज़रूरी एपीआई को चालू कर देती है.
टैग:build_file_semantics
--[no]experimental_get_fixed_configured_action_env
डिफ़ॉल्ट: "गलत"-
चालू होने पर, action.env सुविधा कॉन्फ़िगरेशन के ज़रिए तय किए गए एनवायरमेंट वैरिएबल को भी दिखाएगा.
टैग:loading_and_analysis
,experimental
--[no]experimental_google_legacy_api
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'सही है' पर सेट किया गया है, तो इसमें स्टार लेगसी एपीआई के कई एक्सपेरिमेंटल हिस्से मौजूद हैं, जो Google के लेगसी कोड से जुड़े हैं.
टैग:loading_and_analysis
,experimental
--[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
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो डेटा एक्सपोर्ट करने के कुछ नियमों को लागू करके, रिमोट कंट्रोल की सुविधा का इस्तेमाल किया जा सकता है.
टैग:build_file_semantics
,loading_and_analysis
,experimental
--[no]experimental_sibling_repository_layout
डिफ़ॉल्ट: "गलत"-
अगर सही पर सेट की गई है, तो गैर-मुख्य डेटा स्टोर करने की जगहों को एक्ज़ीक्यूशन रूट में मुख्य डेटा स्टोर करने की जगह के सिमलिंक के तौर पर लगाया जाता है. इसका मतलब है कि सभी डेटा स्टोर करने की जगहें, $ आउटपुट_बेस/execution_root डायरेक्ट्री में सीधे तौर पर मौजूद चिल्ड्रन होती हैं. इससे, टॉप-लेवल 'external' की डायरेक्ट्री को $निकालें_base/execution_root/__main__/external खाली करने का असर होता है.
टैग:action_command_lines
,bazel_internal_configuration
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]incompatible_always_check_depset_elements
डिफ़ॉल्ट: "सही"-
सभी कंस्ट्रक्टर में, डेपसेट में जोड़े गए एलिमेंट की वैधता की जांच करें. एलिमेंट में बदलाव नहीं किया जा सकता, लेकिन ऐतिहासिक रूप से depset(direct=...) कंस्ट्रक्टर जांच करना भूल गया. डिसेट एलिमेंट में सूचियों के बजाय tuples का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10313 पर जाएं.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_depset_for_libraries_to_link_getter
डिफ़ॉल्ट: "सही"-
सही होने पर, Bazel अब link_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
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो फ़ील्ड सिंटैक्स के ज़रिए 'target' ऑब्जेक्ट पर, सेवा देने वाली कंपनियों को ऐक्सेस करने की सुविधा बंद करें. इसके बजाय, provider-key सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, किसी नियम को लागू करने वाले फ़ंक्शन से `my_info` को ऐक्सेस करने के लिए, `ctx.attr.dep.my_info` का इस्तेमाल करने के बजाय, `ctx.attr.dep[MyInfo]` का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/9014 पर जाएं.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_disallow_empty_glob
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो glob() के `allow_empty` आर्ग्युमेंट की डिफ़ॉल्ट वैल्यू 'गलत' होती है.
टैग: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
डिफ़ॉल्ट: "सही"-
अगर यह नीति सही पर सेट है, तो यह ऐसा टेक्स्ट होती है जिसमें बदला जा सकने वाला टेक्स्ट मौजूद होता है.हालांकि, इसके लिए नेटिव.मौजूद_नियम और मौजूदा कोड, नेटिव मौजूदा नियमों का इस्तेमाल नहीं किया जाता.
टैग:build_file_semantics
,loading_and_analysis
,incompatible_change
--[no]incompatible_fix_package_group_reporoot_syntax
डिफ़ॉल्ट: "सही"-
package_group के `packages` एट्रिब्यूट में, किसी भी रिपॉज़िटरी में सभी पैकेज के बजाय, मौजूदा रिपॉज़िटरी में सभी पैकेज को रेफ़र करने के लिए "//..." मान का मतलब बदलता है. पुराना व्यवहार पाने के लिए, आप "//..." के बजाय खास वैल्यू "सार्वजनिक" का इस्तेमाल कर सकते हैं. इस फ़्लैग के लिए ज़रूरी है कि --insupported_package_group_has_public_syntax भी चालू हो.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_java_common_parameters
डिफ़ॉल्ट: "सही"-
अगर यह नीति 'सही है' पर सेट है, तो Pack_sources में host_javabase, और host_javabase पैरामीटर को, सभी कंपाइल से हटा दिया जाएगा.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_new_actions_api
डिफ़ॉल्ट: "सही"-
अगर यह नीति 'सही है' पर सेट है, तो कार्रवाइयां बनाने के लिए एपीआई सिर्फ़ `ctx`.` पर उपलब्ध होगा, न कि `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 के बजाय linker_inputs की ज़रूरत होगी. linked_context के पुराने गैटर को भी बंद कर दिया जाएगा. साथ ही, सिर्फ़ linker_input.
टैग: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 या textproto के लिए proto.encode_text का इस्तेमाल करें.
टैग:build_file_semantics
,incompatible_change
--[no]incompatible_top_level_aspects_require_providers
डिफ़ॉल्ट: "गलत"-
अगर सही पर सेट की गई है, तो टॉप लेवल का आसपेक्ट सिर्फ़ उन प्रोवाइडर के काम करेगा जो ज़रूरी हैं. साथ ही, वे टॉप लेवल के सिर्फ़ उन टारगेट पर चलते हैं जिनके नियमों के विज्ञापन देने वाली कंपनियां, ज़रूरी शर्त को पूरा करती हैं.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_unambiguous_label_stringification
डिफ़ॉल्ट: "सही"-
सही होने पर, 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_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>
डिफ़ॉल्ट: "3500"-
ग्राफ़ के अंदरूनी हिस्सों की गहराई को डेप्सेट (जिसे NestedSet भी कहा जाता है) तक इंटिग्रेट किया गया है. इसके आगे, depset() कंस्ट्रक्टर काम नहीं करेगा.
टैग:loading_and_analysis
- बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प
--[no]experimental_heuristically_drop_nodes
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो मेमोरी बचाने के लिए, फ़ाइल और 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
--skyframe_high_water_mark_threshold=<an integer>
डिफ़ॉल्ट: "85"-
Bazel के अंदरूनी स्काईफ़्रेम इंजन के बेहतर कॉन्फ़िगरेशन के लिए फ़्लैग करें. अगर बेज़ल को पता चलता है कि उसके बनाए गए हीप प्रतिशत का इस्तेमाल कम से कम इस थ्रेशोल्ड तक है, तो यह गैर-ज़रूरी स्काईफ़्रेम स्थिति को छोड़ देगा. इसमें बदलाव करके आप जीसी थ्रेशिंग के असर को कम कर सकते हैं. जीसी थ्रैशिंग तब होती है, जब जीसी थ्रैशिंग, (i) इस अस्थायी स्थिति की मेमोरी के इस्तेमाल की वजह से होती है और (ii) जब इसकी ज़रूरत होती है, तो इसमें स्टेट को फिर से जोड़ने की ज़रूरत नहीं होती.
टैग:host_machine_resource_optimizations
--[no]track_incremental_state
डिफ़ॉल्ट: "सही"-
अगर यह 'गलत है' पर सेट है, तो ब्लेज़ ऐसा डेटा सेव नहीं करता जो इन-बिल्ट बिल्ड को अमान्य बनाने और उनका फिर से आकलन करने की अनुमति देता है, ताकि इस बिल्ड पर मेमोरी सेव की जा सके. बाद के बिल्ड में इसके लिए इंक्रीमेंटल (बढ़ने वाली) बढ़ोतरी नहीं होगी. आम तौर पर, जब इसे 'गलत है' पर सेट किया जाता है, तो --बैच में रखना होता है.
टैग:loses_incremental_state
- वे विकल्प जो लॉगिंग की वर्बोसिटी, फ़ॉर्मैट या जगह पर असर डालते हैं:
--[no]announce_rc
डिफ़ॉल्ट: "गलत"-
आरसी के विकल्पों की जानकारी देनी है या नहीं.
टैग:affects_outputs
--[no]attempt_to_print_relative_paths
डिफ़ॉल्ट: "गलत"-
मैसेज के जगह की जानकारी वाला हिस्सा प्रिंट करते समय, फ़ाइल फ़ोल्डर की डायरेक्ट्री या --package_path की बताई गई किसी एक डायरेक्ट्री से जुड़े पाथ का इस्तेमाल करें.
टैग:terminal_output
--bes_backend=<a string>
डिफ़ॉल्ट: ""-
बिल्ड इवेंट सर्विस (BES) बैकएंड एंडपॉइंट को [SCHEME://]Host[:PORT] फ़ॉर्म में दिखाता है. डिफ़ॉल्ट तौर पर, BES से जुड़े वीडियो अपलोड करने की सुविधा बंद होती है. grpc और grpcs काम करते हैं, यानी TLS के साथ grpc. अगर कोई स्कीम नहीं दी जाती है, तो Bazel को grpcs माना जाएगा.
टैग:affects_outputs
--[no]bes_check_preceding_lifecycle_events
डिफ़ॉल्ट: "गलत"-
पब्लिश बिल्डटूल इवेंट स्ट्रीम रिक्वेस्ट पर फ़ील्ड Check_preceding_lifecycle_events_present सेट करता है. इससे BES को यह जांचने में मदद मिलती है कि पहले से चालू टूल इवेंट से मेल खाने वाला शुरू करने और उसका बिल्ड किया गया इवेंट मिला या नहीं.
टैग: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>
बार कई इस्तेमाल किए गए-
बीईएस ("command_name=<command_name> ", "protocol_name=BEP") पर प्रकाशित किए गए कीवर्ड के डिफ़ॉल्ट सेट को जोड़ने के लिए, सूचना कीवर्ड की सूची तय करती है. डिफ़ॉल्ट वैल्यू 'कोई नहीं' होती है.
टैग:affects_outputs
--[no]bes_lifecycle_events
डिफ़ॉल्ट: "सही"-
तय करें कि बीईएस लाइफ़साइकल इवेंट पब्लिश करने हैं या नहीं. (डिफ़ॉल्ट रूप से 'सही' होता है).
टैग:affects_outputs
--bes_oom_finish_upload_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "10 मिनट"-
यह बताता है कि बेज़ ओमिंग के दौरान, BES/BEP का डेटा अपलोड होने में कितना समय लगेगा. यह फ़्लैग यह पक्का करता है कि जेवीएम गंभीर GC थ्रैशिंग हो. साथ ही, यह किसी भी उपयोगकर्ता थ्रेड पर प्रगति नहीं कर सकता.
टैग: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 को भेजे जाने वाले एसटीडीआउट या एसएफ़टीपी के आकार का ज़्यादा से ज़्यादा साइज़ बताता है.
टैग:affects_outputs
--bes_proxy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- किसी प्रॉक्सी का इस्तेमाल करके, Build Event Service से कनेक्ट करें. फ़िलहाल, इस फ़्लैग का इस्तेमाल सिर्फ़ Unix डोमेन सॉकेट (यूनिक्स:/path/to/socket) कॉन्फ़िगर करने के लिए किया जा सकता है.
--bes_results_url=<a string>
डिफ़ॉल्ट: ""-
वह बेस यूआरएल तय करता है जहां उपयोगकर्ता, बीईएस बैकएंड में स्ट्रीम की गई जानकारी देख सकता है. न्योते से शुरू होने वाले यूआरएल को Bazel, टर्मिनल में न्योते के आईडी से जोड़े गए यूआरएल को दिखाएगा.
टैग:terminal_output
--bes_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "0s"-
तय करता है कि बिल्ड और जांच के खत्म होने के बाद, BES/BEP का अपलोड पूरा होने में कितना समय लगेगा. मान्य समय समाप्ति का मतलब है, एक प्राकृतिक संख्या और उसके बाद एक यूनिट: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (मिलीसेकंड). डिफ़ॉल्ट वैल्यू '0' होती है. इसका मतलब है कि समय तय नहीं है.
टैग:affects_outputs
--build_event_binary_file=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो फ़ाइल में बिल्ड इवेंट प्रोटोकॉल को दिखाने के लिए, वैरिएबल डीलिमिटेड बाइनरी का इस्तेमाल करें. यह विकल्प लागू होता है --bes_upload_mode=weit_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
डिफ़ॉल्ट: "सही"-
जब भी संभव हो, बिल्ड इवेंट प्रोटोकॉल के पाथ को बिल्ड इवेंट प्रोटोकॉल में, दुनिया भर में मान्य यूआरआई में बदलें. बंद होने पर, 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 प्रोफ़ाइल पाथ जोड़ता है.
टैग:affects_outputs
,bazel_monitoring
--[no]experimental_bep_target_summary
डिफ़ॉल्ट: "गलत"- टारगेट की खास जानकारी वाले इवेंट को प्रकाशित करना है या नहीं.
--[no]experimental_build_event_expand_filesets
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो आउटपुट फ़ाइलों को दिखाते समय, BEP में Fileset को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो आउटपुट फ़ाइलों को दिखाते समय, BEP में रिलेटिव फ़ाइलसेट सिमलिंक को ठीक करें. --experimental_build_event_expand_filesets ज़रूरी है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
बिल्डिंग का बिल्ड इवेंट अपलोड करने के बाद, Bazel को ज़्यादा से ज़्यादा इतनी बार फिर से कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
: "1s"-
बीईपी अपलोड न होने पर, एक्स्पोनेंशियल बैकऑफ़ फिर से कोशिश करने की अवधि कम से कम. (घातांक: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
इसमें यह चुना जाता है कि बिल्ड इवेंट के प्रोटोकॉल में, आर्टफ़ैक्ट को कैसे अपलोड किया जाए.
टैग:affects_outputs
--experimental_profile_additional_tasks=<phase, action, action_check, action_lock, action_release, action_update, action_complete, info, create_package, remote_execution, local_execution, scanner, local_parse, upload_time, process_time, remote_queue, remote_setup, fetch, vfs_stat, vfs_dir, vfs_readlink, vfs_md5, vfs_xattr, vfs_delete, vfs_open, vfs_read, vfs_write, vfs_glob, vfs_vmfs_stat, vfs_vmfs_dir, vfs_vmfs_read, wait, thread_name, thread_sort_index, skyframe_eval, skyfunction, critical_path, critical_path_component, handle_gc_notification, action_counts, local_cpu_usage, system_cpu_usage, 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 or unknown>
बार कई इस्तेमाल किए गए-
प्रोफ़ाइल में शामिल किए जाने वाले अतिरिक्त प्रोफ़ाइल टास्क के बारे में बताता है.
टैग:affects_outputs
,bazel_monitoring
--[no]experimental_profile_include_primary_output
डिफ़ॉल्ट: "गलत"-
कार्रवाई वाले ऐसे दूसरे इवेंट में "out" एट्रिब्यूट शामिल होता है जिनमें कार्रवाई के प्राइमरी आउटपुट का एक्ज़ीक्यूट पाथ शामिल होता है.
टैग:affects_outputs
,bazel_monitoring
--[no]experimental_profile_include_target_label
डिफ़ॉल्ट: "गलत"-
कार्रवाई इवेंट के JSON प्रोफ़ाइल डेटा में टारगेट लेबल शामिल होता है.
टैग:affects_outputs
,bazel_monitoring
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "गलत"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग:affects_outputs
--experimental_workspace_rules_log_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- इस फ़ाइल में Workspace के कुछ नियम इवेंट को अलग-अलग व्यवस्थित डेटा के तौर पर लॉग करें.
--[no]generate_json_trace_profile
डिफ़ॉल्ट: "अपने-आप"-
चालू होने पर, Bazel बिल्ड की प्रोफ़ाइल बनाता है और आउटपुट फ़ॉर्मैट में फ़ाइल में, JSON-फ़ॉर्मैट की प्रोफ़ाइल बनाता है. chrome://ttracking में लोड करके प्रोफ़ाइल देखें. डिफ़ॉल्ट रूप से, बेज़ल प्रोफ़ाइल जैसे सभी बिल्ड जैसे निर्देशों और क्वेरी के लिए प्रोफ़ाइल लिखते हैं.
टैग:affects_outputs
,bazel_monitoring
--[no]heap_dump_on_oom
डिफ़ॉल्ट: "गलत"-
अगर ओओएम का इस्तेमाल किया जाता है, तो इसे मैन्युअल रूप से हीप डंप आउटपुट करना चाहिए (इसमें {experimental_oom_more_eagerly_threshold के साथ ओओएम शामिल है). डंप को <output_base>/<invotion_id>.heapdump.hprof पर लिखा जाएगा. यह विकल्प -XX:+ HeapDumpOnOutOfMemoryError को बदल देता है, जिसका कोई असर नहीं होता है, क्योंकि OOM पकड़ा जाता है और रनटाइम#halt पर रीडायरेक्ट किया जाता है.
टैग:bazel_monitoring
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
इसे इस्तेमाल करके, Targetcomplete इवेंट में लेगसी Key_outputs फ़ील्ड जनरेट होने से रोकने के लिए. Bazel से ResultStore के इंटिग्रेशन के लिए, राजनैतिक आउटपुट डालना ज़रूरी है.
टैग:affects_outputs
--logging=<0 <= an integer <= 6>
डिफ़ॉल्ट: "3"-
लॉगिन लेवल.
टैग:affects_outputs
--memory_profile=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर इस नीति को सेट किया जाता है, तो तय की गई फ़ाइल के लिए, मेमोरी के इस्तेमाल से जुड़ा डेटा, आखिरी चरण में लिखें. साथ ही, बिल्ड के आखिर में लॉग को मास्टर करने के लिए, हीप को लिखें.
टैग:affects_outputs
,bazel_monitoring
--memory_profile_stable_heap_parameters=<integers, separated by a comma expected in pairs>
डिफ़ॉल्ट: "1,0"-
बिल्ड खत्म होने के बाद, अच्छी तरह से काम करने वाले हीप की गिनती करें. पूर्णांकों की संख्या और उनके बीच में कॉमा की संख्या भी होनी चाहिए. हर पेयर में पहला इंटेजर परफ़ॉर्म करने के लिए जीसी की संख्या होती है. हर जोड़े में दूसरा पूर्णांक GC के बीच इंतज़ार करने के लिए सेकंड की संख्या होती है. उदाहरण: 2,4,4,0, 2 GC के साथ 4 सेकंड के पॉज़ के साथ, 4 GC के साथ शून्य सेकंड के पॉज़ के साथ
टैग:bazel_monitoring
--profile=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर यह सेट है, तो Bazel की प्रोफ़ाइल बनाएं और बताई गई फ़ाइल में डेटा लिखें. प्रोफ़ाइल का विश्लेषण करने के लिए 'बेज़ल विश्लेषण' प्रोफ़ाइल का इस्तेमाल करें.
टैग:affects_outputs
,bazel_monitoring
--[no]slim_profile
डिफ़ॉल्ट: "सही"-
प्रोफ़ाइल बहुत बड़ी होने पर, JSON प्रोफ़ाइल को छोटा करके इवेंट को मर्ज करें.
टैग:affects_outputs
,bazel_monitoring
--starlark_cpu_profile=<a string>
डिफ़ॉल्ट: ""-
बताई गई फ़ाइल में, Starstark के सभी थ्रेड में सीपीयू के इस्तेमाल की pprof प्रोफ़ाइल लिखता है.
टैग:bazel_monitoring
--tool_tag=<a string>
डिफ़ॉल्ट: ""-
टूल के इस नाम को Bazel के इस वर्शन को एट्रिब्यूट करने के लिए दिया गया है.
टैग:affects_outputs
,bazel_monitoring
--ui_event_filters=<Convert list of comma separated event kind to list of filters>
बार कई इस्तेमाल किए गए-
तय करता है कि यूज़र इंटरफ़ेस (यूआई) में कौनसे इवेंट दिखाने हैं. लीडिंग +/- का इस्तेमाल करके, डिफ़ॉल्ट इवेंट में इवेंट जोड़े या हटाए जा सकते हैं या डायरेक्ट असाइनमेंट का इस्तेमाल करके डिफ़ॉल्ट सेट को पूरी तरह से बदला जा सकता है. इन इवेंट टाइप में INFO, DEBUG, ERROR वगैरह शामिल हैं.
टैग:terminal_output
- अलग-अलग कैटगरी में नहीं, बल्कि कैटगरी के विकल्प.:
--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>
डिफ़ॉल्ट: "अपने-आप"- स्क्रोल करने का आउटपुट कम करने के लिए, टर्मिनल कर्सर के कंट्रोल का इस्तेमाल करें.
--[no]enable_platform_specific_config
डिफ़ॉल्ट: "गलत"- अगर यह सही है, तो Bazel, bazelrc फ़ाइलों से होस्ट-ओएस की खास कॉन्फ़िगरेशन लाइनों को चुनता है. उदाहरण के लिए, अगर होस्ट ओएस Linux है और आप bazel build. ओएस आइडेंटिफ़ायर हैं: linux, macos, window, freebsd, और Openbsd. इस फ़्लैग को चालू करना, Linux पर --config=linux, Windows पर --config=Windows वगैरह इस्तेमाल करने के बराबर है.
--experimental_credential_helper=<An (unresolved) path to a credential helper for a scope.>
बार कई इस्तेमाल किए गए- क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि वह इस्तेमाल किए गए दायरे (डोमेन) के क्रेडेंशियल की जानकारी हासिल कर सके. क्रेडेंशियल हेल्पर के क्रेडेंशियल को <code>--google_default_क्रेडेंशियल</code>, `--google_क्रेडेंशियल` या <code>.netrc</code> के क्रेडेंशियल से ज़्यादा प्राथमिकता दी जाती है. https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-क्रेडेंशियल-helpers.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मीटर"- वह अवधि कॉन्फ़िगर करती है जिसके लिए क्रेडेंशियल हेल्पर के क्रेडेंशियल कैश किए जाते हैं. किसी अलग वैल्यू के साथ शुरू करने से, पहले से मौजूद एंट्री के लाइफ़टाइम में बदलाव होगा; कैश मेमोरी मिटाने के लिए, शून्य डालें. एक साफ़ निर्देश, हमेशा कैश मेमोरी को खाली करता है. भले ही, इस फ़्लैग पर ध्यान न दिया गया हो.
--experimental_credential_helper_timeout=<An immutable length of time.>
: "5s"- क्रेडेंशियल हेल्पर के लिए, टाइम आउट कॉन्फ़िगर करता है. इस टाइम आउट में जवाब देने में विफल रहने वाले क्रेडेंशियल हेल्पर निरस्त किए जाएंगे.
--[no]experimental_skymeld_ui
डिफ़ॉल्ट: "गलत"-
एक साथ चलने पर, विश्लेषण और एक्ज़ीक्यूशन के चरण, दोनों की प्रोग्रेस को दिखाता है.
टैग: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 कनेक्शन के लिए, Keep-alive पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो कनेक्शन पर कोई रीड ऑपरेशन न करने के काफ़ी समय बाद Bazel पिंग भेजता है, लेकिन केवल तभी जब gRPC कॉल कम से कम एक लंबित हो. समय को दूसरे विवरण के स्तर के रूप में देखा जाता है; एक सेकंड से कम के मान को सेट करने में गड़बड़ी होती है. डिफ़ॉल्ट रूप से, कीप-अलाइव के लिए पिंग बंद होते हैं. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक के साथ मिलकर काम करना चाहिए. उदाहरण के लिए, इस फ़्लैग को 30 सेकंड की वैल्यू सेट करने के लिए, यह इस तरह करना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "20 सेकंड"- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव टाइम आउट कॉन्फ़िगर करता है. अगर --grpc_keepalive_time के साथ कीप-अलाइव पिंग की सुविधा चालू है, तो तय समय के बाद, अगर पिंग करने पर जवाब नहीं मिलता है, तो बाज़ेल के कनेक्शन का टाइम आउट हो जाता है. समय को दूसरे विवरण के स्तर के रूप में देखा जाता है; एक सेकंड से कम के मान को सेट करने में गड़बड़ी होती है. अगर कीप-लाइव पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.
--[no]incompatible_disallow_symlink_file_to_dir
डिफ़ॉल्ट: "सही"-
अगर इस नीति को 'सही है' पर सेट किया गया है, तो `ctx.action.symlink` फ़ाइल को किसी डायरेक्ट्री में सिमलिंक करने की अनुमति नहीं देगा.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_remove_rule_name_parameter
डिफ़ॉल्ट: "सही"-
अगर यह नीति 'सही है' पर सेट है, तो `name` पैरामीटर से `rule` को कॉल नहीं किया जा सकता.
टैग: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 के साथ मैप किया जाता है.
टैग:terminal_output
--[no]watchfs
डिफ़ॉल्ट: "गलत"- Linux/macOS पर: अगर सही है, तो बेजल बदलाव के लिए हर फ़ाइल को स्कैन करने के बजाय, लोकल बदलावों के लिए ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करता है. Windows पर: फ़िलहाल, यह फ़्लैग गैर-ऑप होता है. हालांकि, इसे --experimental_window_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
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया गया है, तो बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं है.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
किसी डाउनलोड गड़बड़ी के लिए फिर से प्रयास करने की अधिकतम संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने की जगह के नियमों में, सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड बदले बिना, ऐसी मशीन पर बाहरी डेटा स्टोर करने की जगहें बनाई जा सकती हैं जो नियम के लेखक से धीमी हैं
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
http डाउनलोड से जुड़े सभी टाइम आउट, दिए गए फ़ैक्टर के आधार पर बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति बाहरी वैल्यू का डेटा फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी में सेव की गई जगह की जानकारी देती है. एक खाली स्ट्रिंग, जिसमें कैश मेमोरी को बंद करने का अनुरोध किया गया हो.
टैग:bazel_internal_configuration
- वे सेटिंग जो इस बात पर असर डालती हैं कि Bazel, मान्य बिल्ड इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह फ़ील्ड खाली न हो, तो इसमें ऐसी फ़ाइल की जानकारी होती है जिसका समाधान हो चुका हो. इसके लिए, रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--experimental_verify_repository_rules=<a string>
बार कई इस्तेमाल किए गए-
अगर उन रिपॉज़िटरी नियमों की सूची जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी है, तब फ़ाइल --experimental_repository_sha_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>` के तौर पर तय करें. इसका समाधान, समाधान किए गए डिपेंडेंसी ग्राफ़ में होगा. भले ही, उनका नाम रजिस्ट्री में यांकी पर बताया गया हो (अगर वह किसी रजिस्ट्री में नहीं आ रहा है). ऐसा न करने पर, याक किए गए वर्शन से रिज़ॉल्यूशन हट जाएगा. आप `BZLMOD_ALLOW_YANKED_वर्शनS` एनवायरमेंट वैरिएबल से, मंज़ूर किया गया यांक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (हम इसका सुझाव नहीं देते).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Bazel मॉड्यूल के साथ काम करने वाले वर्शन के बारे में जानें. मान्य वैल्यू को `गड़बड़ी` के तौर पर मार्क किया जाता है, ताकि समस्या का समाधान न हो पाने पर, उसे बंद किया जा सके. जांच बंद करने के लिए `गड़बड़ी` या मेल न खाने की स्थिति का पता लगने पर, चेतावनी वाली चेतावनी को प्रिंट किया जा सकता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
जांचें कि क्या रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच की सुविधा को बंद करने के लिए, `वैल्यू` को बंद कर दिया जाता है. मेल न खाने पर, चेतावनी को प्रिंट करने के लिए `चेतावनी` या समाधान से जुड़ी गड़बड़ी की सूचना देने के लिए `गड़बड़ी`.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को `dev_dependency` के रूप में अनदेखा कर देता है. ध्यान दें कि अगर इस फ़्लैग की वैल्यू कुछ भी हो, तब भी MODULE.bazel में उन डेवलपर डिपेंडेंसी को नज़रअंदाज़ किया जाता है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई इस्तेमाल किए गए- किसी मॉड्यूल को स्थानीय डायरेक्ट्री से बदल देता है.
--registry=<a string>
बार कई इस्तेमाल किए गए-
यह रजिस्ट्री को बताता है कि Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किन रजिस्ट्री का इस्तेमाल किया जाए. ऑर्डर ज़रूरी है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा. बाद में, सिर्फ़ रजिस्ट्री में वापस आएंगी.
टैग:changes_inputs
- वे विकल्प जिनसे लॉग की भाषा, फ़ॉर्मैट या जगह पर असर पड़ता है:
--dump=<text or raw>
[-d
] डिफ़ॉल्ट: ब्यौरा देखें-
पूरी प्रोफ़ाइल का डेटा, 'टेक्स्ट' या स्क्रिप्ट 'रॉ' फ़ॉर्मैट में डालें.
टैग:affects_outputs
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 वर्णों के हिसाब से तय होती है. साथ ही, कार्रवाई करने के लिए, सबसे ज़्यादा संख्या ही इस्तेमाल की जा सकती है. यह विकल्प सेट करने पर, सभी नियमों के हिसाब से आंकड़े लिखे जाएंगे.
- किसी जेनरिक इनपुट के बारे में बताने या उसमें बदलाव करने के विकल्प जो किसी अन्य कैटगरी में नहीं आते.
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर WORKSPACE फ़ाइल के बजाय समाधान नहीं की गई फ़ाइल पढ़ी जाती है, तो उसे नहीं पढ़ें
टैग:changes_inputs
- रिमोट कैशिंग और एक्ज़ीक्यूशन के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होता है, जिसके बाद एक होस्ट नाम (`allow` और `block`) या दो पैटर्न होते हैं, एक मिलान करता है, और एक वैकल्पिक यूआरएल के रूप में इस्तेमाल करता है, जिसमें `1` से शुरू होने वाली बैक-रेफ़रंस होती हैं. एक ही यूआरएल देने के लिए, कई `rewrite` निर्देशों के लिए संभव है और इस मामले में एक से ज़्यादा यूआरएल मिलेंगे.
- अन्य विकल्प, लेकिन इनकी श्रेणी नहीं तय की गई है.:
--override_repository=<an equals-separated mapping of repository name to path>
बार कई इस्तेमाल किए गए- डेटा स्टोर करने की जगह को स्थानीय डायरेक्ट्री से बदल देता है.
क्वेरी के विकल्प
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
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया गया है, तो बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं है.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
किसी डाउनलोड गड़बड़ी के लिए फिर से प्रयास करने की अधिकतम संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने की जगह के नियमों में, सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड बदले बिना, ऐसी मशीन पर बाहरी डेटा स्टोर करने की जगहें बनाई जा सकती हैं जो नियम के लेखक से धीमी हैं
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
http डाउनलोड से जुड़े सभी टाइम आउट, दिए गए फ़ैक्टर के आधार पर बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति बाहरी वैल्यू का डेटा फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी में सेव की गई जगह की जानकारी देती है. एक खाली स्ट्रिंग, जिसमें कैश मेमोरी को बंद करने का अनुरोध किया गया हो.
टैग:bazel_internal_configuration
- वे सेटिंग जो इस बात पर असर डालती हैं कि Bazel, मान्य बिल्ड इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह फ़ील्ड खाली न हो, तो इसमें ऐसी फ़ाइल की जानकारी होती है जिसका समाधान हो चुका हो. इसके लिए, रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--experimental_verify_repository_rules=<a string>
बार कई इस्तेमाल किए गए-
अगर उन रिपॉज़िटरी नियमों की सूची जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी है, तब फ़ाइल --experimental_repository_sha_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} में से कोई एक हो. 'off' का मतलब है कि कोई भी डिपेंडेंसी हल नहीं की गई है, 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि सभी डिपेंडेंट डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के नियम की कैटगरी दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलू जोड़े जाएंगे जो शायद डायरेक्ट डिपेंडेंसी के रूल क्लास के लिए चालू हों. ध्यान दें कि सटीक मोड के लिए किसी एक टारगेट का मूल्यांकन करने के लिए दूसरे पैकेज लोड करने की ज़रूरत होती है, जिससे यह दूसरे मोड की तुलना में धीमा हो जाता है. यह भी ध्यान दें कि सटीक मोड पूरी तरह से सटीक नहीं है: किसी पहलू की गणना का फ़ैसला, विश्लेषण के चरण में लिया जाता है या नहीं. यह 'बेज़ल क्वेरी' के दौरान नहीं चलता.
टैग:build_file_semantics
--[no]deduplicate_depsets
डिफ़ॉल्ट: "सही"-
आखिरी प्रोटो/textproto/json आउटपुट में, dep_set_of_files के नॉन-लीफ़ बच्चों के डुप्लीकेट बनाएं. इससे, उन डुप्लीकेट दस्तावेज़ों का डुप्लीकेट वर्शन नहीं हटता जिनका इस्तेमाल तुरंत किया जाता हो. इसका असर कार्रवाइयों के इनपुट से जुड़े आर्टफ़ैक्ट की सूची पर नहीं पड़ता.
टैग:terminal_output
--[no]graph:factored
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो ग्राफ़ 'फ़ैक्टर किया गया' दिखेगा. इसका मतलब है कि टोपिक वैल्यू वाले नोड को एक साथ मर्ज किया जाएगा और उनके लेबल जोड़े गए. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--graph:node_limit=<an integer>
डिफ़ॉल्ट: "512"-
आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल को छोटा कर दिया जाएगा; -1 का मतलब है कि काट-छांट नहीं की जाएगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--[no]implicit_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, इंडिपेंडेंट डिपेंडेंसी उस डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी जिस पर क्वेरी ऑपरेट की जाती है. इंप्लिसिट डिपेंडेंसी, BUILD फ़ाइल में साफ़ तौर पर नहीं बताई जाती है, लेकिन bazel में जोड़ी जाती है. कुकी के लिए, यह विकल्प समाधान किए गए टूलचेन को फ़िल्टर करना नियंत्रित करता है.
टैग:build_file_semantics
--[no]include_artifacts
डिफ़ॉल्ट: "सही"-
इसमें आउटपुट में कार्रवाई के इनपुट और आउटपुट के नाम शामिल होते हैं.
टैग:terminal_output
--[no]include_aspects
डिफ़ॉल्ट: "सही"- क्वेरी, क्वेरी: आउटपुट में पक्ष से जनरेट की गई कार्रवाइयों को शामिल करें या नहीं. क्वेरी: 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
डिफ़ॉल्ट: "सही"-
डिफ़ॉल्ट रूप से, यह सोर्स फ़ाइल का टारगेट दिखाता है. सही होने पर, यह जगह के आउटपुट में स्रोत फ़ाइलों की पहली लाइन की जगह दिखाता है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग:terminal_output
,incompatible_change
--[no]incompatible_package_group_includes_double_slash
डिफ़ॉल्ट: "सही"-
अगर यह चालू है, तो package_group के `packages` एट्रिब्यूट के आउटपुट के तौर पर, पहले वाले // // को नहीं मिटाया जाएगा.
टैग:terminal_output
,incompatible_change
--[no]infer_universe_scope
डिफ़ॉल्ट: "गलत"-
अगर इस सेटिंग को सेट किया जाता है और इसे यूनिवर्सल यूनिस्कोप के ज़रिए सेट नहीं किया जाता है, तो क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर --universe_scope की वैल्यू का पता लगाया जाएगा. ध्यान दें कि यूनिवर्स के दायरे वाले फ़ंक्शन (जैसे कि `allrdeps`) का इस्तेमाल करने वाली क्वेरी एक्सप्रेशन के लिए अनुमानित --universa_scope वैल्यू, आपकी पसंद की वैल्यू नहीं हो सकती है. इसलिए, आपको इस विकल्प का इस्तेमाल सिर्फ़ तभी करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/query/language#sky-query देखें. अगर --universe_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, jsonproto.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो BUILD फ़ाइल में साफ़ तौर पर वैल्यू न बताने वाले एट्रिब्यूट शामिल किए जाते हैं. ऐसा न करने पर, उन्हें हटा दिया जाता है. यह विकल्प --आउटपुट=प्रोटो
टैग पर लागू होता है:terminal_output
--[no]proto:definition_stack
डिफ़ॉल्ट: "गलत"-
Definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह नियम के क्लास की जानकारी दिए जाने के समय, हर नियम के इंस्टेंस से जुड़े Starlark कॉल स्टैक को रिकॉर्ड करता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, चुने गए एट्रिब्यूट की मदद से बनाए जा सकने वाले एट्रिब्यूट फ़्लैट हो जाते हैं. सूची के तौर पर फ़्लैट फ़्लैट करने से जुड़ी सूची, चुने गए मैप की हर वैल्यू को एक बार ही शामिल करती है. स्केलर प्रकार शून्य हो गए हैं.
टैग:build_file_semantics
--[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
डिफ़ॉल्ट: "सही"-
क्वेरी: बंद होने पर, 'होस्ट कॉन्फ़िगरेशन' या 'एक्ज़ीक्यूशन' टारगेट पर निर्भरता को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाएगा जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी का किनारा, आम तौर पर बिल्ड के दौरान लागू होने वाले टूल पर ले जाता है. जैसे, 'प्रोटो_लाइब्रेरी' नियम से लेकर प्रोटोकॉल कंपाइलर तक.
क्वेरी: अगर यह बंद है, तो कॉन्फ़िगर किए गए सभी टारगेट को फ़िल्टर करके हटा देता है जो होस्ट या एक्ज़ीक्यूशन के ट्रांज़िशन को, कॉन्फ़िगर किए गए इस टारगेट का पता लगाने वाले टॉप-लेवल टारगेट से क्रॉस करते हैं. इसका मतलब यह है कि अगर टॉप-लेवल टारगेट टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट भी टारगेट कॉन्फ़िगरेशन में दिखेंगे. अगर टॉप-लेवल टारगेट होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट किए गए टारगेट ही लौटाए जाएंगे. यह विकल्प, हल किए गए टूलचेन को बाहर नहीं रखेगा.
टैग:build_file_semantics
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ या घटा). खास लक्ष्यों के लिए, ट्रांज़िट समय में तय की गई यूनिवर्स में क्वेरी की जा सकती है. इस विकल्प का इस्तेमाल क्वेरी और cquery कमांड के लिए किया जाता है.
क्वेरी के लिए, इस विकल्प का इनपुट सभी टारगेट को टारगेट करने के लिए है. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं बताया गया है, तो यह माना जाएगा कि टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किया गया टारगेट कहा गया है. ध्यान दें: cquery के लिए, यह विकल्प तय न करने से बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से टारगेट किए गए टारगेट, टॉप लेवल के विकल्पों के साथ बनाए नहीं जा सकते.
टैग:loading_and_analysis
- Bzlmod आउटपुट और सिमेंटिक से जुड़े विकल्प:
--allow_yanked_versions=<a string>
बार कई इस्तेमाल किए गए-
मॉड्यूल वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय करें. इसका समाधान, समाधान किए गए डिपेंडेंसी ग्राफ़ में होगा. भले ही, उनका नाम रजिस्ट्री में यांकी पर बताया गया हो (अगर वह किसी रजिस्ट्री में नहीं आ रहा है). ऐसा न करने पर, याक किए गए वर्शन से रिज़ॉल्यूशन हट जाएगा. आप `BZLMOD_ALLOW_YANKED_वर्शनS` एनवायरमेंट वैरिएबल से, मंज़ूर किया गया यांक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (हम इसका सुझाव नहीं देते).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Bazel मॉड्यूल के साथ काम करने वाले वर्शन के बारे में जानें. मान्य वैल्यू को `गड़बड़ी` के तौर पर मार्क किया जाता है, ताकि समस्या का समाधान न हो पाने पर, उसे बंद किया जा सके. जांच बंद करने के लिए `गड़बड़ी` या मेल न खाने की स्थिति का पता लगने पर, चेतावनी वाली चेतावनी को प्रिंट किया जा सकता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
जांचें कि क्या रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच की सुविधा को बंद करने के लिए, `वैल्यू` को बंद कर दिया जाता है. मेल न खाने पर, चेतावनी को प्रिंट करने के लिए `चेतावनी` या समाधान से जुड़ी गड़बड़ी की सूचना देने के लिए `गड़बड़ी`.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को `dev_dependency` के रूप में अनदेखा कर देता है. ध्यान दें कि अगर इस फ़्लैग की वैल्यू कुछ भी हो, तब भी MODULE.bazel में उन डेवलपर डिपेंडेंसी को नज़रअंदाज़ किया जाता है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई इस्तेमाल किए गए- किसी मॉड्यूल को स्थानीय डायरेक्ट्री से बदल देता है.
--registry=<a string>
बार कई इस्तेमाल किए गए-
यह रजिस्ट्री को बताता है कि Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किन रजिस्ट्री का इस्तेमाल किया जाए. ऑर्डर ज़रूरी है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा. बाद में, सिर्फ़ रजिस्ट्री में वापस आएंगी.
टैग:changes_inputs
- वे विकल्प जिनसे लॉग की भाषा, फ़ॉर्मैट या जगह पर असर पड़ता है:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 वर्णों के हिसाब से तय होती है. साथ ही, कार्रवाई करने के लिए, सबसे ज़्यादा संख्या ही इस्तेमाल की जा सकती है. यह विकल्प सेट करने पर, सभी नियमों के हिसाब से आंकड़े लिखे जाएंगे.
- किसी जेनरिक इनपुट के बारे में बताने या उसमें बदलाव करने के विकल्प जो किसी अन्य कैटगरी में नहीं आते.
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर WORKSPACE फ़ाइल के बजाय समाधान नहीं की गई फ़ाइल पढ़ी जाती है, तो उसे नहीं पढ़ें
टैग:changes_inputs
- रिमोट कैशिंग और एक्ज़ीक्यूशन के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होता है, जिसके बाद एक होस्ट नाम (`allow` और `block`) या दो पैटर्न होते हैं, एक मिलान करता है, और एक वैकल्पिक यूआरएल के रूप में इस्तेमाल करता है, जिसमें `1` से शुरू होने वाली बैक-रेफ़रंस होती हैं. एक ही यूआरएल देने के लिए, कई `rewrite` निर्देशों के लिए संभव है और इस मामले में एक से ज़्यादा यूआरएल मिलेंगे.
- अन्य विकल्प, लेकिन इनकी श्रेणी नहीं तय की गई है.:
--override_repository=<an equals-separated mapping of repository name to path>
बार कई इस्तेमाल किए गए- डेटा स्टोर करने की जगह को स्थानीय डायरेक्ट्री से बदल देता है.
- बिल्डिंग को एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:
--[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
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो फिर बेज़ल नए स्पॉन में टेस्ट के लिए कवरेज को प्रोसेस करेगा.
टैग: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', सभी Genरूल कार्रवाइयों के लिए, कार्रवाई करने की जानकारी में 'Requires-x' जोड़ता है.
'(?!Genrule).*=-requires-x', उन सभी कार्रवाइयों के लिए निष्पादन जानकारी से 'Requires-x' हटा देता है, जो सामान्य नहीं हैं.
टैग:execution
,affects_outputs
,loading_and_analysis
--persistent_android_dex_desugar
-
कर्मचारियों का इस्तेमाल करके, Android के लिए Dex और काम करने की डिफ़ॉल्ट कार्रवाइयों को चालू करें.
इसमें शामिल है:
--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
{11/--strategy=ManifestMerger=worker
{
}
--persistent_multiplex_android_dex_desugar
-
कर्मचारियों की मदद से, मल्टीप्लेक्स किए गए Android Dex और Desgar ऐक्शन चालू करें.
इसमें शामिल है:
--persistent_android_dex_desugar
--modify_execution_info=Desugar=+supports-multiplex-workers
--modify_execution_info=DexBuilder=+supports-multiplex-workers
टैग:host_machine_resource_optimizations
,execution
--persistent_multiplex_android_resource_processor
-
कर्मियों का उपयोग करके मल्टीप्लेक्स किए गए Android संसाधन प्रोसेसर को चालू करें.
इसमें शामिल है:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
{11/--modify_execution_info=ManifestMerger=+supports-multiplex-workers
{
}
--persistent_multiplex_android_tools
-
Android के लिए, लगातार और मल्टीप्लेक्स किए गए टूल चालू करें. इन टूल की मदद से डीक्सिंग, डीजर्जिंग, और संसाधन की प्रोसेसिंग की जा सकती है.
इसमें शामिल है:
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
- कार्रवाई करने के लिए इस्तेमाल होने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:
--android_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट कंपाइलर.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_crosstool_top=<a build target label>
डिफ़ॉल्ट: "//external:android/crosstool"-
Android बिल्ड के लिए इस्तेमाल होने वाले C++ कंपाइलर की लोकेशन.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_manifest_merger=<legacy, android or force_android>
डिफ़ॉल्ट: "android"-
Android_binary नियमों के लिए मेनिफ़ेस्ट मर्जर को चुनता है. फ़्लैग करें, ताकि Android मर्जर के लेगसी मर्जर से ट्रांज़िशन किया जा सके.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_platforms=<a build target label>
डिफ़ॉल्ट: ""-
उन प्लैटफ़ॉर्म को सेट करता है, जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म दिए गए हैं, तो बाइनरी एक फ़ैट 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-बीटा).
टैग: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_Merger"-
उस बाइनरी की जगह जिसका इस्तेमाल, रॉ कवरेज रिपोर्ट को प्रोसेस करने के लिए किया जाता है. यह वर्तमान में एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcov_Merger'.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_report_generator=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_report_generator"-
कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. यह वर्तमान में एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट '//tools/test:coverage_report_generator'.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_support=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_support"-
सहायता कवरेज की ऐसी फ़ाइलें जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई की जानकारी में मौजूद होती हैं. डिफ़ॉल्ट वैल्यू '//tools/test/coverage_support'.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--crosstool_top=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"-
C++ कोड को कंपाइल करने में इस्तेमाल होने वाले क्रॉसटूल पैकेज का लेबल.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--custom_malloc=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कस्टम मैलक को लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड नियमों में मैलक एट्रिब्यूट को बदल देती है.
टैग:changes_inputs
,affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment>
बार कई इस्तेमाल किए गए-
कॉमा-सेपरेटेड रेगुलर एक्सप्रेशन की सूची, हर वैकल्पिक रूप से - (नेगेटिव एक्सप्रेशन) से शुरू होती है, कॉमा-सेपरेटेड कंस्ट्रेंट टारगेट टारगेट की सूची को (=) असाइन की जाती है. अगर कोई टारगेट, किसी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन है, तो इसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा मानो यह कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर बताता हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64, //x के अंतर्गत किसी भी लक्ष्य में 'x86_64' जोड़ देगा, उन लोगों को छोड़कर जिनके नाम में 'test' है.
टैग:loading_and_analysis
--[no]experimental_enable_objc_cc_deps
डिफ़ॉल्ट: "सही"-
ob_c_* नियमों को cc_library पर निर्भर होने देता है और किसी भी objc निर्भरता को बनाने के साथ-साथ --ios_<--ios_cpu>" को -ios_multi_cpu में किसी भी मान के लिए सेट करें.
टैग:loading_and_analysis
,incompatible_change
--[no]experimental_include_xcode_execution_requirements
डिफ़ॉल्ट: "गलत"-
अगर यह सेट है, तो हर Xcode ऐक्शन में, "Requires-xcode:{version}" लागू करने की शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न किया गया लेबल है, तो "ज़रूरी है-xcode-label:{version_label}" लागू करने की ज़रूरी शर्त भी जोड़ें.
टैग:loses_incremental_state
,loading_and_analysis
,execution
--[no]experimental_prefer_mutual_xcode
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो सबसे हाल के Xcode का इस्तेमाल करें. यह स्थानीय तौर पर और कहीं से भी उपलब्ध होता है. अगर गलत है या एक साथ कई वर्शन उपलब्ध नहीं हैं, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग:loses_incremental_state
--extra_execution_platforms=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
वे प्लैटफ़ॉर्म जो एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर काम करते हैं. प्लैटफ़ॉर्म सटीक टारगेट या टारगेट पैटर्न के रूप में बताए जा सकते हैं. रजिस्टर किए गए प्लैटफ़ॉर्म से पहले इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इसके लिए, रजिस्टर करें_execution_platforms() का इस्तेमाल करें.
टैग:execution
--extra_toolchains=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
टूलचेन नियमों के दौरान ध्यान दिए जाने वाले टूलचेन नियम. टूलचेन सटीक रूप से या टारगेट पैटर्न के रूप में तय किए जा सकते हैं. ये टूलटिप, WORKSPACE फ़ाइल में रजिस्टर किए गए टूल से पहले की जाती हैं. इसके लिए, रजिस्टर किए गए टूल टूल का इस्तेमाल किया जाता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
चेक की गई लाइब्रेरी की लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन से चुनी जाती है और आपको इसे कभी भी बदलने की ज़रूरत नहीं होती.
टैग:action_command_lines
,affects_outputs
--host_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
C++ कंपाइलर का इस्तेमाल होस्ट कंपाइलेशन के लिए किया जाता है. अगर --host_crosstool_top सेट नहीं है, तो इसे अनदेखा कर दिया जाता है.
टैग:loading_and_analysis
,execution
--host_crosstool_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
डिफ़ॉल्ट रूप से, होस्ट कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler विकल्प का भी इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया गया है, तो Bazel दिए गए क्रॉस-टूल_टॉप के लिए डिफ़ॉल्ट libc और कंपाइलर इस्तेमाल करता है.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--host_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
तय किए जाने पर, यह सेटिंग, होस्ट कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग:action_command_lines
,affects_outputs
--host_platform=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट के सिस्टम के बारे में बताता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--[no]incompatible_disable_expand_if_all_available_in_flag_set
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, एक्सपैंशन_if_all_available को फ़्लैग_सेट में दिखाने की अनुमति नहीं देगा(माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7008 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो b+ c++ टूलटिप में 'host' और 'nonhost' सुविधाएं चालू नहीं होंगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 पर जाएं.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_android_toolchain_resolution
डिफ़ॉल्ट: "गलत"-
Android के नियमों (Starlark और नेटिव) के लिए Android SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution
डिफ़ॉल्ट: "गलत"-
सेब के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल 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
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल आपकी लाइब्रेरी डिपेंडेंसी को डिफ़ॉल्ट तौर पर पूरे संग्रह के तौर पर लिंक नहीं करेगा (माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_require_ctx_in_configure_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो cc_normal.configure_features में ज़्यादा जानकारी के लिए बेज़ल को 'ctx' पैरामीटर की ज़रूरत होगी (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7793 देखें).
टैग:loading_and_analysis
,incompatible_change
-
टूलचेन की सुविधा होने पर इंटरफ़ेस के साथ शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, इस सुविधा के साथ सभी ELF टूल चेन काम करती हैं.
टैग:loading_and_analysis
,affects_outputs
,affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में बताता है. अगर यह तय नहीं है, तो 'xcode_version' से डिफ़ॉल्ट iOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
macOS ऐप्लिकेशन के बिल्ड का इस्तेमाल करने के लिए, macOS SDK का वर्शन बताता है. अगर कुछ भी न बताया गया हो, तो 'xcode_version' से मिले डिफ़ॉल्ट macOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--minimum_os_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
आपका ओएस का वह सबसे छोटा वर्शन जिसे टारगेट किया गया है.
टैग:loading_and_analysis
,affects_outputs
--platform_mappings=<a relative path>
डिफ़ॉल्ट: ""-
मैपिंग फ़ाइल की जगह, जो बताती है कि कोई प्लैटफ़ॉर्म सेट नहीं करने पर, कौनसा प्लैटफ़ॉर्म इस्तेमाल करना चाहिए या प्लैटफ़ॉर्म के पहले से मौजूद होने पर क्या फ़्लैग किया जाना चाहिए. फ़ाइल फ़ोल्डर का मुख्य रूट होना चाहिए. डिफ़ॉल्ट रूप से 'platform_mappings' (फ़ाइल फ़ोल्डर के रूट के ठीक नीचे वाली फ़ाइल).
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--platforms=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म नियमों के लेबल से मौजूदा निर्देश के लिए टारगेट प्लैटफ़ॉर्म के बारे में पता चलता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--python2_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
बिना समर्थन वाले टैग, अमान्य. `--insupported_use_python_toolchains` ने बंद कर दिया.
टैग:no_op
,deprecated
--python3_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
बिना समर्थन वाले टैग, अमान्य. `--insupported_use_python_toolchains` ने बंद कर दिया.
टैग:no_op
,deprecated
--python_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
'Python' टारगेट का इस्तेमाल करके, Python टारगेट को टारगेट प्लैटफ़ॉर्म पर चलाया जाता है. बहिष्कृत; --insupported_use_python_toolchains ने बंद किया.
टैग:loading_and_analysis
,affects_outputs
--python_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
Python को टारगेट करने वाले Python टारगेट को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. बहिष्कृत; --insupported_use_python_toolchains ने बंद किया.
टैग:loading_and_analysis
,affects_outputs
--target_platform_fallback=<a build target label>
डिफ़ॉल्ट: "@local_config_platform//:host"-
प्लैटफ़ॉर्म के नियम का लेबल, जिसे तब इस्तेमाल किया जाना चाहिए, जब कोई टारगेट प्लैटफ़ॉर्म सेट न हो और कोई भी प्लैटफ़ॉर्म मैपिंग, फ़्लैग के मौजूदा सेट से मेल न खाता हो.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
इससे यह पता चलता है कि TOS ऐप्लिकेशन का इस्तेमाल करने के लिए, TOS SDK का कौनसा वर्शन इस्तेमाल किया जा रहा है. अगर कुछ भी तय नहीं किया गया है, तो 'xcode_version' से डिफ़ॉल्ट tvOS SDK वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
इस नीति से, WatchOS SDK के उस वर्शन की जानकारी मिलती है जिसका इस्तेमाल स्मार्टवॉच के ऐप्लिकेशन बनाने के लिए किया जाता है. अगर यह तय नहीं है, तो 'xcode_version' से डिफ़ॉल्ट WatchOS SDK वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xcode_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताए गए वर्शन के लिए, बिल्ड से जुड़ी कार्रवाइयों के लिए Xcode का इस्तेमाल किया जाता है. अगर जानकारी नहीं दी गई है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल करें.
टैग:loses_incremental_state
--xcode_version_config=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"-
बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए, xcode_config नियम का लेबल.
टैग:loses_incremental_state
,loading_and_analysis
- विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:
--[no]apple_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 list of options>
डिफ़ॉल्ट: ".pb.h"-
उन हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है जिन्हें cc_proto_library बनाता है.
टैग:affects_outputs
,loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated list of options>
डिफ़ॉल्ट: ".pb.cc"-
उन स्रोत फ़ाइलों के प्रीफ़िक्स सेट करता है जिन्हें cc_proto_library बनाता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info
डिफ़ॉल्ट: "गलत"-
प्रोटो_लाइब्रेरी में अन्य Java एपीआई वर्शन के लिए, ज़्यादा कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_proto_extra_actions
डिफ़ॉल्ट: "गलत"-
प्रोटो_लाइब्रेरी में अन्य 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' का कोई भी संयोजन हो सकता है और सभी मोड को अक्षम करने के लिए 'no' हो सकता है.
टैग:loading_and_analysis
,action_command_lines
,affects_outputs
--[no]incompatible_always_include_files_in_data
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो नेटिव नियम अपनी रन फ़ाइल में डेटा डिपेंडेंसी के लिए <code>DefaultInfo.files</code> जोड़ते हैं. ऐसा करना, Starlark नियमों (https://bazel.build/extending/rule#runfiles_features_to_aallow) के लिए सुझाए गए तरीके से मेल खाता है.
टैग:affects_outputs
,incompatible_change
--[no]legacy_external_runfiles
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो .runfiles/wsname/external/repo में .runfiles/wsname/external/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
डिफ़ॉल्ट: "गलत"-
इससे, ऐसे android_binary APK के लिए संसाधन को छोटा करने की सुविधा चालू होती है जो ProGuard का इस्तेमाल करते हैं.
टैग:affects_outputs
,loading_and_analysis
--apple_bitcode=<'mode' or 'platform=mode', where 'mode' is none, embedded_markers or embedded, and 'platform' is ios, watchos, tvos, macos or catalyst>
बार कई इस्तेमाल किए गए-
डिवाइस आर्किटेक्चर को टारगेट करने वाले चरणों को कंपाइल करने के लिए, Apple बिटकोड मोड तय करें. वैल्यू '[platform=]mode' में होती हैं. यहां प्लैटफ़ॉर्म (जो 'ios', 'macos', 'tvos' या 'watchos' होना चाहिए) ज़रूरी नहीं है. अगर दिया गया हो, तो बिट कोड खास तौर पर उस प्लैटफ़ॉर्म के लिए लागू किया जाता है; अगर छोड़ा जाता है, तो यह सभी प्लैटफ़ॉर्म पर लागू होता है. मोड का नाम 'कोई नहीं', 'एम्बेड किए गए मार्कर' या 'एम्बेड किया गया' होना चाहिए. यह विकल्प कई बार दिया जा सकता है.
टैग:loses_incremental_state
--[no]build_python_zip
डिफ़ॉल्ट: "अपने-आप"-
Python की एक्ज़ीक्यूटेबल ज़िप बनाना; Windows पर, दूसरे प्लैटफ़ॉर्म पर बंद करें
टैग:affects_outputs
--catalyst_cpus=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
उन आर्किटेक्चर की सूची जिन्हें कॉमा लगाकर अलग किया गया है और जिनके लिए Apple Catalyst बाइनरी बनाई जा रही हैं.
टैग:loses_incremental_state
,loading_and_analysis
--[no]collect_code_coverage
डिफ़ॉल्ट: "गलत"-
अगर तय किया गया है, तो Bazel कोड का इस्तेमाल करेगा (जहां संभव हो, ऑफ़लाइन इंस्ट्रुमेंट का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. केवल -- खर्चों के मिलान वाले टारगेट पर असर होगा. आम तौर पर, यह विकल्प सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'बेज़ल कवरेज' निर्देश का इस्तेमाल करें.
टैग: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 की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल वाली रॉ फ़ाइल का पूरा पाथ नाम, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल की फ़ाइल.
टैग:affects_outputs
--cs_fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
संदर्भ एफ़डीओ के संदर्भ वाले बाइनरी टूल जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान डंप किया जाएगा.
टैग:affects_outputs
--cs_fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली CS_fdo_profile, संदर्भ के हिसाब से संवेदनशील प्रोफ़ाइल दिखाती है.
टैग:affects_outputs
--cxxopt=<a string>
बार कई इस्तेमाल किए गए-
C++ स्रोत फ़ाइलें कंपाइल करते समय gcc में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--define=<a 'name=value' assignment>
बार कई इस्तेमाल किए गए-
हर --define विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है.
टैग:changes_inputs
,affects_outputs
--dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
यह तय करता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel डाइनैमिक तौर पर लिंक करने का विकल्प चुनेगा. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक रूप से लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:loading_and_analysis
,affects_outputs
--[no]enable_fdo_profile_absolute_path
डिफ़ॉल्ट: "सही"-
अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने से गड़बड़ी पैदा होगी.
टैग:affects_outputs
--[no]enable_runfiles
डिफ़ॉल्ट: "अपने-आप"-
रनफ़ाइल सिमलिंक ट्री चालू करें. डिफ़ॉल्ट रूप से, यह Windows पर, अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग:affects_outputs
--experimental_action_listener=<a build target label>
बार कई इस्तेमाल किए गए-
पक्षों के पक्ष में रोक लगा दी गई. बिल्ड की मौजूदा कार्रवाइयों के साथ बाहर की गई किसी कार्रवाई को अटैच करने के लिए 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
डिफ़ॉल्ट: "गलत"-
इससे, ऐसे android_binary APK के लिए संसाधन को छोटा करने की सुविधा चालू होती है जो ProGuard का इस्तेमाल करते हैं.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_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
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो स्टैक अनवाइंड करने के लिए, libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-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 कवरेज मैप की जानकारी जनरेट करेगा. ऐसा तब होगा, जब collection_code_coverage चालू की गई हो.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
,experimental
--fat_apk_cpu=<comma-separated list of options>
डिफ़ॉल्ट: "armeabi-v7a"-
इस विकल्प को सेट करने पर, फैट APK चालू हो जाते हैं.इनमें तय किए गए सभी टारगेट आर्किटेक्चर के लिए, नेटिव बाइनरी का इस्तेमाल किया जाता है. उदाहरण के लिए, --fat_apk_cpu=x86,armeabi-v7a. अगर इस फ़्लैग के बारे में बताया गया है, तो android_binu नियमों की निर्भरता के आधार पर --android_cpu को अनदेखा कर दिया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]fat_apk_hwasan
डिफ़ॉल्ट: "गलत"-
WWASAN स्प्लिट बनाना है या नहीं.
टैग: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> तय करने से सुविधा पूरी दुनिया में बंद हो जाएगी. नेगेटिव सुविधाएं हमेशा पॉज़िटिव सुविधाओं को बदल देती हैं. इस फ़्लैग का इस्तेमाल बेज़ल रिलीज़ किए बिना सुविधा में हुए डिफ़ॉल्ट बदलावों को रोल आउट करने के लिए किया जाता है.
टैग: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>
बार कई इस्तेमाल किए गए-
होस्ट या एक्ज़ीक्यूशन कॉन्फ़िगरेशन में बने टूल के लिए, सी कंपाइलर को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_cpu=<a string>
डिफ़ॉल्ट: ""-
होस्ट सीपीयू.
टैग:changes_inputs
,affects_outputs
--host_cxxopt=<a string>
बार कई इस्तेमाल किए गए-
होस्ट या निष्पादन कॉन्फ़िगरेशन में बनाए गए टूल के लिए C++ कंपाइलर को पास करने के अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_force_python=<PY2 or PY3>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट कॉन्फ़िगरेशन के लिए Python वर्शन को बदलें. यह "PY2" या "PY3" हो सकता है.
टैग:loading_and_analysis
,affects_outputs
--host_linkopt=<a string>
बार कई इस्तेमाल किए गए-
होस्ट या निष्पादन कॉन्फ़िगरेशन में टूल लिंक करते समय लिंकर को पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट टारगेट के लिए macOS का कम से कम वर्शन. अगर कोई भी अंक सेट न किया गया हो, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई इस्तेमाल किए गए-
होस्ट या एक्ज़ीक्यूशन कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, चुनिंदा रूप से C/C++ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प. यह विकल्प एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, शामिल किए गए रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर करने की सूची के लिए है (साथ ही, -platformation_filter भी देखें). विकल्प_1 को विकल्प_1 के तौर पर, आर्बिट्रेरी कमांड लाइन के विकल्पों के लिए इस्तेमाल किया जा सकता है. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में.cc/ को छोड़कर सभी cc फ़ाइलों की कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
--host_swiftcopt=<a string>
बार कई इस्तेमाल किए गए-
होस्ट टूल के लिए swiftc में पास करने के लिए अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--[no]incompatible_avoid_conflict_dlls
डिफ़ॉल्ट: "सही"-
अगर यह सेटिंग चालू है, तो Windows पर cc_library से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (DLL) का नाम बदलकर name_{sha}.dll कर दिया जाएगा. हैश का हिसाब RepositoryName और DLL के पैकेज पाथ के आधार पर लगाया जाता है. यह विकल्प तब फ़ायदेमंद होता है, जब आपके पास एक ही पैकेज वाली कई cc_library पर निर्भर करता है (उदाहरण के लिए, //foo/bar1:utils और //foo/bar2:utils).
टैग:loading_and_analysis
,affects_outputs
,incompatible_change
--[no]incompatible_merge_genfiles_directory
डिफ़ॉल्ट: "सही"-
सही होने पर, जेनफ़ाइल डायरेक्ट्री बिन डायरेक्ट्री में फ़ोल्ड हो जाती है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_use_platforms_repo_for_constraints
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो @bazel_tools की कंस्ट्रेंट सेटिंग हटा दी जाती हैं.
टैग:affects_outputs
,incompatible_change
--[no]instrument_test_targets
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो तय करें कि टेस्ट के नियमों को लागू करना है या नहीं. अगर सेट किया जाता है, तो --उदाहरण के तौर पर, इंस्ट्रूमेंटेशन_फ़िल्टर से जुड़े टेस्ट के नियमों को लागू किया जाता है. नहीं तो, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग:affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-/javatest[/],-/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 नियमों के लिए पूरा-संग्रह का उपयोग करें, जिनमें linkshare=True और linkstatic=True या '-static' है. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर, हमेशा link=1 का इस्तेमाल करना एक बेहतर विकल्प है.
टैग:action_command_lines
,affects_outputs
,deprecated
--linkopt=<a string>
बार कई इस्तेमाल किए गए-
लिंक करने के दौरान gcc में पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--ltobackendopt=<a string>
बार कई इस्तेमाल किए गए-
एलटीओ बैकएंड चरण में जाने के लिए अन्य विकल्प (-features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
--ltoindexopt=<a string>
बार कई इस्तेमाल किए गए-
एलटीओ इंडेक्सिंग चरण में पास होने के लिए अन्य विकल्प (-features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
--macos_cpus=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
उन आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट जिनके लिए Apple macOS बाइनरी बनाएं.
टैग:loses_incremental_state
,loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट के लिए, कम से कम इस तरह का macOS वर्शन होना चाहिए. अगर कोई भी अंक सेट न किया गया हो, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--[no]objc_debug_with_GLIBCXX
डिफ़ॉल्ट: "गलत"-
अगर सेट किया गया है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC और GLIBCPP_CONCEPT_CheckS को तय करें.
टैग:action_command_lines
--[no]objc_enable_binary_stripping
डिफ़ॉल्ट: "गलत"-
लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt दोनों मौजूद हों, तो बाइनरी स्ट्रिपिंग का इस्तेमाल किया जाएगा.
टैग:action_command_lines
--objccopt=<a string>
बार कई इस्तेमाल किए गए-
Objective-C/C++ स्रोत फ़ाइलें कंपाइल करते समय gcc में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई इस्तेमाल किए गए-
कुछ फ़ाइलों को कंपाइल करते समय, gcc को पास करने के कुछ और विकल्प. यह विकल्प एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, शामिल किए गए रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर करने की सूची के लिए है (साथ ही, -platformation_filter भी देखें). विकल्प_1 को विकल्प_1 के तौर पर, आर्बिट्रेरी कमांड लाइन के विकल्पों के लिए इस्तेमाल किया जा सकता है. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में cc की छोड़ दी गई सभी cc फ़ाइलों की कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई इस्तेमाल किए गए- कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड (-feature=thin_lto के तहत) को चुनिंदा तरीके से पास करने के अन्य विकल्प. यह विकल्प एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और शामिल न करने की सूची के लिए है, विकल्प_1 से विकल्प_n का मतलब है आर्बिट्रेरी कमांड लाइन विकल्प. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\o.,-//foo/bar\.o@-O0, o.O.
--platform_suffix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग:loses_incremental_state
,affects_outputs
,loading_and_analysis
--propeller_optimize=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propler प्रोफ़ाइल की जानकारी का इस्तेमाल करें.प्रोपेलर प्रोफ़ाइल में, कम से कम एक फ़ाइल, एक cc प्रोफ़ाइल और एक ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग बिल्ड लेबल को स्वीकार करता है. यह प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, B/LD फ़ाइल जो a/b/BUILD:prolender_optimize( name = "pro), इस विकल्प का इस्तेमाल इस तरीके से किया जाना चाहिए: --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 का इस्तेमाल करके". 'कभी-कभी' के डिफ़ॉल्ट मान का मतलब Strip iff --compilation_mode=fastbuild में होता है.
टैग:affects_outputs
--stripopt=<a string>
बार कई इस्तेमाल किए गए-
'<name>.striped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के दूसरे विकल्प.
टैग:action_command_lines
,affects_outputs
--swiftcopt=<a string>
बार कई इस्तेमाल किए गए-
Swift कंपाइलेशन में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
--tvos_cpus=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
उन आर्किटेक्चर की सूची जिन्हें कॉमा से अलग किया गया है. ये आर्किटेक्चर Apple tvOS बाइनरी बनाते हैं.
टैग:loses_incremental_state
,loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम tvOS वर्शन जो काम करता हो. अगर कोई वैल्यू न बताई गई हो, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--watchos_cpus=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
उन आर्किटेक्चर की सूची जिन्हें कॉमा से अलग किया गया है. ये आर्किटेक्चर Apple WatchOS बाइनरी बनाते हैं.
टैग:loses_incremental_state
,loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए, कम से कम सुविधाओं वाला WatchOS वर्शन. अगर कोई भी अंक न बताया गया हो, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xbinary_fdo=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम डालें. जब विकल्प के साथ इस विकल्प का इस्तेमाल किया जाता है --fdo_documentation/--fdo_optimize/--fdo_profile, तो ऐसे विकल्प हमेशा बने रहेंगे जैसे कि xbinary_fdo कभी तय नहीं किया गया है.
टैग:affects_outputs
- वे विकल्प जो यह तय करते हैं कि Bazel, बिल्ड के मान्य इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--auto_cpu_environment_group=<a build target label>
डिफ़ॉल्ट: ""-
cp_value वैल्यू को अपने-आप मैप करने के लिए,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
डिफ़ॉल्ट: "गलत"-
जिन डिवाइसों में Deps के साथ, बिना srcs वाले 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_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 एपीआई में हेडर की सख्त जांच करें:
टैग:loading_and_analysis
,changes_inputs
,incompatible_change
--[no]incompatible_validate_top_level_header_inclusions
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल टॉप लेवल डायरेक्ट्री हेडर को शामिल करने की पुष्टि भी करेगा (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/10047 पर जाएं).
टैग:loading_and_analysis
,incompatible_change
--[no]strict_filesets
डिफ़ॉल्ट: "गलत"-
अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलें, गड़बड़ियों के तौर पर रिपोर्ट की जाती हैं. यह test_fileset_dependencies_recursively को बंद करने पर काम नहीं करता.
टैग: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>
डिफ़ॉल्ट: "बंद"-
जब तक यह बंद नहीं हो जाता, तब तक यह जांच नहीं की जाती कि एक Proto_library टारगेट, 'सार्वजनिक तौर पर इंपोर्ट करें' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट किए गए के रूप में बताता है या नहीं.
टैग:build_file_semantics
,eagerness_to_exit
,incompatible_change
--[no]strict_system_includes
डिफ़ॉल्ट: "गलत"-
सही होने पर, सिस्टम के ज़रिए पाए गए हेडर में पाथ (-isystem) शामिल किए जाने की भी ज़रूरत होती है.
टैग:loading_and_analysis
,eagerness_to_exit
--target_environment=<a build target label>
बार कई इस्तेमाल किए गए-
इस बिल्ड के टारगेट एनवायरमेंट के बारे में एलान करता है. लेबल को "परिवेश" नियम का रेफ़रंस होना चाहिए. अगर बताया गया हो, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने वाले होने चाहिए.
टैग:changes_inputs
- ऐसे विकल्प जो किसी बिल्ड के साइनिंग आउटपुट पर असर डालते हैं:
--apk_signing_method=<v1, v2, v1_v2 or v4>
डिफ़ॉल्ट: "v1_v2"-
APK साइन करने के लिए इस्तेमाल किया जाना
टैग:action_command_lines
,affects_outputs
,loading_and_analysis
--[no]device_debug_entitlements
डिफ़ॉल्ट: "सही"-
अगर सेट किया गया है और कंपाइलेशन मोड 'ऑप्ट' नहीं किया गया है, तो 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]allow_analysis_failures
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो किसी नियम के टारगेट में विश्लेषण में हुई गड़बड़ी की वजह से, TargetFailureInfo का इंस्टेंस बनता है जिसमें गड़बड़ी का ब्यौरा शामिल होता है. इससे, बिल्ड में गड़बड़ी होती है.
टैग: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 devicetypes' चलाकर डिवाइस की सूची मिल सकती है.
टैग:test_runner
--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
रन करने या टेस्ट करने के दौरान, सिम्युलेटर पर चलने वाला iOS वर्शन. अगर इस नियम में टारगेट डिवाइस की जानकारी दी गई है, तो ios_test नियमों को नज़रअंदाज़ कर दिया जाएगा.
टैग:test_runner
--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once>
बार कई इस्तेमाल किए गए- यह दिखाता है कि हर जांच को कितनी बार चलाया जाता है. अगर इनमें से कोई भी कोशिश किसी भी वजह से नाकाम होती है, तो पूरी जांच को फ़ेल मान लिया जाता है. आम तौर पर, बताई गई वैल्यू सिर्फ़ पूर्णांक होती है. उदाहरण: --runs_per_test=3 सभी परीक्षण 3 बार चलाएगा. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. जहां Run_per_test पूर्णांक मान है और regex_filter, शामिल करें और रेगुलर एक्सप्रेशन पैटर्न को शामिल न करें की सूची के लिए है (यह भी देखें -- इंस्ट्रुमेंट_फ़िल्टर). उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3 //foo/ में सभी बार जांच करता है, सिवाय foo/bar के तहत आने वाले तीन बार. यह विकल्प एक से ज़्यादा बार पास किया जा सकता है. मेल खाने वाले सबसे हाल के तर्क को प्राथमिकता दी जाती है. अगर कुछ भी मैच नहीं करता है, तो टेस्ट सिर्फ़ एक बार किया जाता है.
--test_env=<a 'name=value' assignment with an optional value part>
बार कई इस्तेमाल किए गए-
टेस्ट रनर एनवायरमेंट में इंजेक्ट करने के लिए, और एनवायरमेंट वैरिएबल तय करता है. वैरिएबल, नाम के हिसाब से तय किए जा सकते हैं. ऐसा होने पर, उसकी वैल्यू बेज़ल क्लाइंट के एनवायरमेंट या नाम=वैल्यू पेयर से पढ़ी जाएगी. इस विकल्प का इस्तेमाल, कई वैरिएबल बताने के लिए कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'बेज़ल टेस्ट' निर्देश के ज़रिए किया जाता है.
टैग:test_runner
--test_timeout=<a single integer or comma-separated list of 4 integers>
डिफ़ॉल्ट: "-1"- जांच के टाइम आउट के लिए, जांच के टाइम आउट की डिफ़ॉल्ट वैल्यू को बदलें (सेकंड में). अगर सिर्फ़ एक पूर्णांक संख्या दी जाती है, तो वह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए गए हैं, तो वे छोटे, मध्यम, लंबे, और हमेशा के लिए, टाइम आउट को बदल देंगे (इसी क्रम में). दोनों में से किसी भी रूप में, -1 का मान तय करता है कि ब्लेज़ उस श्रेणी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करेगा.
--tvos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में tvOS ऐप्लिकेशन चलाते समय सिम्युलेट करने वाला डिवाइस. उदाहरण के लिए, 'Apple TV 1080p'. जिस डिवाइस पर सिम्युलेटर चलेगा उस पर 'xcrun simctl list devicetypes' चलाकर डिवाइस की सूची मिल सकती है.
टैग:test_runner
--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
रन करने या टेस्ट करने के दौरान, सिम्युलेटर पर tvOS का वर्शन.
टैग:test_runner
--watchos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में स्मार्टवॉच का ऐप्लिकेशन चलाने पर, सिम्युलेट करने वाला डिवाइस. उदाहरण के लिए, 'Apple Watch - 38 मि॰मी॰'. जिस डिवाइस पर सिम्युलेटर चलेगा उस पर 'xcrun simctl list devicetypes' चलाकर डिवाइस की सूची मिल सकती है.
टैग:test_runner
--watchos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
रन करने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला WatchOS का वर्शन.
टैग:test_runner
--[no]zip_undeclared_test_outputs
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो जिन जांच के एलान का एलान नहीं किया गया है उन्हें zip फ़ाइल में स्टोर किया जाएगा.
टैग:test_runner
- क्वेरी आउटपुट और सिमैंटिक से जुड़े विकल्प:
--aspect_deps=<off, conservative or precise>
डिफ़ॉल्ट: "परंपरागत"-
आउटपुट डिपेंडेंसी का समाधान कैसे करें, जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो. 'off' का मतलब है कि कोई भी डिपेंडेंसी हल नहीं की गई है, 'कंज़र्वेटिव' (डिफ़ॉल्ट) का मतलब है कि सभी डिपेंडेंट डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें डायरेक्ट डिपेंडेंसी के नियम की कैटगरी दी गई हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ वही पहलू जोड़े जाएंगे जो शायद डायरेक्ट डिपेंडेंसी के रूल क्लास के लिए चालू हों. ध्यान दें कि सटीक मोड के लिए किसी एक टारगेट का मूल्यांकन करने के लिए दूसरे पैकेज लोड करने की ज़रूरत होती है, जिससे यह दूसरे मोड की तुलना में धीमा हो जाता है. यह भी ध्यान दें कि सटीक मोड पूरी तरह से सटीक नहीं है: किसी पहलू की गणना का फ़ैसला, विश्लेषण के चरण में लिया जाता है या नहीं. यह 'बेज़ल क्वेरी' के दौरान नहीं चलता.
टैग:build_file_semantics
--[no]deduplicate_depsets
डिफ़ॉल्ट: "सही"-
आखिरी प्रोटो/textproto/json आउटपुट में, dep_set_of_files के नॉन-लीफ़ बच्चों के डुप्लीकेट बनाएं. इससे, उन डुप्लीकेट दस्तावेज़ों का डुप्लीकेट वर्शन नहीं हटता जिनका इस्तेमाल तुरंत किया जाता हो. इसका असर कार्रवाइयों के इनपुट से जुड़े आर्टफ़ैक्ट की सूची पर नहीं पड़ता.
टैग:terminal_output
--[no]graph:factored
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो ग्राफ़ 'फ़ैक्टर किया गया' दिखेगा. इसका मतलब है कि टोपिक वैल्यू वाले नोड को एक साथ मर्ज किया जाएगा और उनके लेबल जोड़े गए. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--graph:node_limit=<an integer>
डिफ़ॉल्ट: "512"-
आउटपुट में ग्राफ़ नोड के लिए लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. लंबे लेबल को छोटा कर दिया जाएगा; -1 का मतलब है कि काट-छांट नहीं की जाएगी. यह विकल्प सिर्फ़ --आउटपुट=ग्राफ़ पर लागू होता है.
टैग:terminal_output
--[no]implicit_deps
डिफ़ॉल्ट: "सही"-
चालू होने पर, इंडिपेंडेंट डिपेंडेंसी उस डिपेंडेंसी ग्राफ़ में शामिल की जाएंगी जिस पर क्वेरी ऑपरेट की जाती है. इंप्लिसिट डिपेंडेंसी, BUILD फ़ाइल में साफ़ तौर पर नहीं बताई जाती है, लेकिन bazel में जोड़ी जाती है. कुकी के लिए, यह विकल्प समाधान किए गए टूलचेन को फ़िल्टर करना नियंत्रित करता है.
टैग:build_file_semantics
--[no]include_artifacts
डिफ़ॉल्ट: "सही"-
इसमें आउटपुट में कार्रवाई के इनपुट और आउटपुट के नाम शामिल होते हैं.
टैग:terminal_output
--[no]include_aspects
डिफ़ॉल्ट: "सही"- क्वेरी, क्वेरी: आउटपुट में पक्ष से जनरेट की गई कार्रवाइयों को शामिल करें या नहीं. क्वेरी: 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
डिफ़ॉल्ट: "सही"-
डिफ़ॉल्ट रूप से, यह सोर्स फ़ाइल का टारगेट दिखाता है. सही होने पर, यह जगह के आउटपुट में स्रोत फ़ाइलों की पहली लाइन की जगह दिखाता है. यह फ़्लैग सिर्फ़ माइग्रेशन के लिए मौजूद है.
टैग:terminal_output
,incompatible_change
--[no]incompatible_package_group_includes_double_slash
डिफ़ॉल्ट: "सही"-
अगर यह चालू है, तो package_group के `packages` एट्रिब्यूट के आउटपुट के तौर पर, पहले वाले // // को नहीं मिटाया जाएगा.
टैग:terminal_output
,incompatible_change
--[no]infer_universe_scope
डिफ़ॉल्ट: "गलत"-
अगर इस सेटिंग को सेट किया जाता है और इसे यूनिवर्सल यूनिस्कोप के ज़रिए सेट नहीं किया जाता है, तो क्वेरी एक्सप्रेशन में यूनीक टारगेट पैटर्न की सूची के तौर पर --universe_scope की वैल्यू का पता लगाया जाएगा. ध्यान दें कि यूनिवर्स के दायरे वाले फ़ंक्शन (जैसे कि `allrdeps`) का इस्तेमाल करने वाली क्वेरी एक्सप्रेशन के लिए अनुमानित --universa_scope वैल्यू, आपकी पसंद की वैल्यू नहीं हो सकती है. इसलिए, आपको इस विकल्प का इस्तेमाल सिर्फ़ तभी करना चाहिए, जब आपको पता हो कि आप क्या कर रहे हैं. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/query/language#sky-query देखें. अगर --universe_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, jsonproto.
टैग:terminal_output
--[no]proto:default_values
डिफ़ॉल्ट: "सही"-
अगर सही है, तो BUILD फ़ाइल में साफ़ तौर पर वैल्यू न बताने वाले एट्रिब्यूट शामिल किए जाते हैं. ऐसा न करने पर, उन्हें हटा दिया जाता है. यह विकल्प --आउटपुट=प्रोटो
टैग पर लागू होता है:terminal_output
--[no]proto:definition_stack
डिफ़ॉल्ट: "गलत"-
Definition_stack प्रोटो फ़ील्ड को पॉप्युलेट करें. यह नियम के क्लास की जानकारी दिए जाने के समय, हर नियम के इंस्टेंस से जुड़े Starlark कॉल स्टैक को रिकॉर्ड करता है.
टैग:terminal_output
--[no]proto:flatten_selects
डिफ़ॉल्ट: "सही"-
चालू होने पर, चुने गए एट्रिब्यूट की मदद से बनाए जा सकने वाले एट्रिब्यूट फ़्लैट हो जाते हैं. सूची के तौर पर फ़्लैट फ़्लैट करने से जुड़ी सूची, चुने गए मैप की हर वैल्यू को एक बार ही शामिल करती है. स्केलर प्रकार शून्य हो गए हैं.
टैग:build_file_semantics
--[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
डिफ़ॉल्ट: "सही"-
क्वेरी: बंद होने पर, 'होस्ट कॉन्फ़िगरेशन' या 'एक्ज़ीक्यूशन' टारगेट पर निर्भरता को उस डिपेंडेंसी ग्राफ़ में शामिल नहीं किया जाएगा जिस पर क्वेरी काम करती है. 'होस्ट कॉन्फ़िगरेशन' डिपेंडेंसी का किनारा, आम तौर पर बिल्ड के दौरान लागू होने वाले टूल पर ले जाता है. जैसे, 'प्रोटो_लाइब्रेरी' नियम से लेकर प्रोटोकॉल कंपाइलर तक.
क्वेरी: अगर यह बंद है, तो कॉन्फ़िगर किए गए सभी टारगेट को फ़िल्टर करके हटा देता है जो होस्ट या एक्ज़ीक्यूशन के ट्रांज़िशन को, कॉन्फ़िगर किए गए इस टारगेट का पता लगाने वाले टॉप-लेवल टारगेट से क्रॉस करते हैं. इसका मतलब यह है कि अगर टॉप-लेवल टारगेट टारगेट कॉन्फ़िगरेशन में है, तो सिर्फ़ कॉन्फ़िगर किए गए टारगेट भी टारगेट कॉन्फ़िगरेशन में दिखेंगे. अगर टॉप-लेवल टारगेट होस्ट कॉन्फ़िगरेशन में है, तो सिर्फ़ होस्ट किए गए टारगेट ही लौटाए जाएंगे. यह विकल्प, हल किए गए टूलचेन को बाहर नहीं रखेगा.
टैग:build_file_semantics
--universe_scope=<comma-separated list of options>
डिफ़ॉल्ट: ""-
टारगेट पैटर्न का कॉमा-सेपरेटेड सेट (जोड़ या घटा). खास लक्ष्यों के लिए, ट्रांज़िट समय में तय की गई यूनिवर्स में क्वेरी की जा सकती है. इस विकल्प का इस्तेमाल क्वेरी और cquery कमांड के लिए किया जाता है.
क्वेरी के लिए, इस विकल्प का इनपुट सभी टारगेट को टारगेट करने के लिए है. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर यह विकल्प नहीं बताया गया है, तो यह माना जाएगा कि टॉप-लेवल टारगेट को क्वेरी एक्सप्रेशन से पार्स किया गया टारगेट कहा गया है. ध्यान दें: cquery के लिए, यह विकल्प तय न करने से बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से टारगेट किए गए टारगेट, टॉप लेवल के विकल्पों के साथ बनाए नहीं जा सकते.
टैग:loading_and_analysis
- बिल्ड टाइम को ऑप्टिमाइज़ करने के लिए ट्रिगर करने वाले विकल्प:
--[no]collapse_duplicate_defines
डिफ़ॉल्ट: "सही"-
चालू होने पर, ग़ैर-ज़रूरी --विज्ञापन की जानकारी, बिल्ड की शुरुआत में ही हट जाएगी. इससे कुछ खास तरह के बिल्ड के लिए, विश्लेषण कैश मेमोरी में होने वाले गैर-ज़रूरी नुकसान से बचा जा सकता है.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_filter_library_jar_with_program_jar
डिफ़ॉल्ट: "गलत"-
LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग:action_command_lines
--[no]experimental_inmemory_dotd_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, C++ .d फ़ाइलों को मेमोरी में भेज दिया जाएगा. उन्हें डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से भेजा जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_inmemory_jdeps_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलें, मेमोरी में डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से पास होंगी.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_objc_include_scanning
डिफ़ॉल्ट: "गलत"-
क्या आपको C/C++ के मकसद को स्कैन करना है?
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]experimental_parse_headers_skipped_if_corresponding_srcs_found
डिफ़ॉल्ट: "गलत"-
चालू होने पर, अगर एक ही टारगेट नाम वाला सोर्स एक ही टारगेट में मिलता है, तो parse_headers फ़ीचर, अलग से कंपाइल करने वाली अलग से कार्रवाई नहीं बनाता है.
टैग:loading_and_analysis
,affects_outputs
--[no]experimental_retain_test_configuration_across_testonly
डिफ़ॉल्ट: "गलत"-
चालू होने पर, --trim_test_Configuration, 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
डिफ़ॉल्ट: "गलत"-
इनपुट फ़ाइलों से #इनक्लूड लाइनों को पार्स करके, C/C++ कंपाइलेशन में इनपुट कम करें. यह कंपोज़िशन इनपुट ट्री के साइज़ को कम करके, परफ़ॉर्मेंस और इंक्रीमेंटल को बेहतर बना सकता है. हालांकि, यह बिल्ड को तोड़ भी सकता है क्योंकि शामिल करें स्कैनर C प्रीप्रोसेसर सिमेंटिक को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डायनैमिक #इन्क्लूड डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर कंडीशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. शिकायत किए गए फ़्लैग से जुड़ी कोई भी समस्या बंद हो जाएगी.
टैग: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>
बार कई इस्तेमाल किए गए-
किसी Starlark फ़्लैग के लिए शॉर्टहैंड नाम सेट करता है. यह "<key>=<value>" के रूप में एक सिंगल की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग:changes_inputs
--[no]incompatible_default_to_explicit_init_py
डिफ़ॉल्ट: "गलत"-
यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि _init__.py फ़ाइलें Python टारगेट की रन फ़ाइल में अपने-आप न बन जाएं. सटीक रूप से, जब py_binary या py_test टारगेट लेगसी_create_init को "अपने-आप" (डिफ़ॉल्ट) पर सेट करते हैं, तो इसे गलत माना जाता है. ऐसा तब होता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py2_outputs_are_suffixed
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो Python 2 के कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे जिसमें सफ़िक्स '-py2' शामिल होता है. हालांकि, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं शामिल होता. इसका मतलब है कि `bazel-bin` सुविधा सिमलिंक Python 2 के बजाय Python 3 के टारगेट पर ले जाएगा. अगर आप इस विकल्प को चालू करते हैं, तो `--insupported_py3_is_default` को चालू करने का सुझाव भी दिया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py3_is_default
डिफ़ॉल्ट: "सही"-
अगर सही है, तो `py_binary` और `py_test` टारगेट जो अपनी `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते हैं, वे PY2 के बजाय डिफ़ॉल्ट रूप से PY3 पर सेट हो जाएंगे. अगर आप इस फ़्लैग को सेट करते हैं, तो `--insupported_py2_outputs_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
] डिफ़ॉल्ट: "अपने-आप"- अगर 'ऑटो' पर सेट है, तो Bazel फिर से जांच करता है. ऐसा तब होता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलाव का पता चलता है. (2) टेस्ट को बाहरी के तौर पर मार्क किया जाता है, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया जाता है या(4) जांच पहले ही पूरी नहीं हो सकी. अगर 'हां' पर सेट किया जाता है, तो Bazel, बाहरी जांच के नतीजों को छोड़कर बाकी सभी जांच के नतीजों को कैश मेमोरी में सेव करता है. अगर 'नहीं' पर सेट किया जाता है, तो 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 की जानकारी एक एलसीओवी रिपोर्ट जनरेट करेगी.
टैग: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
डिफ़ॉल्ट: "गलत"- टेस्ट रनर के डिप से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest के लिए साफ़ तौर पर एक डिपेंडेंसी बताएं. फ़िलहाल, यह सिर्फ़ बज़ल के लिए काम करता है.
--host_java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- बिल्डर के दौरान एक्ज़ीक्यूट होने वाले टूल के ज़रिए इस्तेमाल किया जाने वाला Java लॉन्चर.
--host_javacopt=<a string>
बार कई इस्तेमाल किए गए- किसी बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय javac को पास करने के लिए अतिरिक्त विकल्प.
--host_jvmopt=<a string>
बार कई इस्तेमाल किए गए- बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, Java वीएम में पास करने के लिए अतिरिक्त विकल्प. ये विकल्प हर java_binary टारगेट के वर्चुअल मशीन (वीएम) स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_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
-
इससे, Java की वर्चुअल मशीन की जांच शुरू होने से पहले, JDWP के हिसाब से काम करने वाले डीबगर (जैसे कि jdb) के कनेक्शन का इंतज़ार हो जाता है. इंप्रेशन -test_output=streamed.
इसमें शामिल है:
--test_arg=--wrapper_script_flag=--debug
--test_output=streamed
--test_strategy=exclusive
--test_timeout=9999
--nocache_test_results
--[no]java_deps
डिफ़ॉल्ट: "सही"- हर Java टारगेट के हिसाब से, डिपेंडेंसी की जानकारी जनरेट करें (अब कंपाइल-टाइम क्लासपाथ).
--[no]java_header_compilation
डिफ़ॉल्ट: "सही"- सोर्स रिपोर्ट में, सीधे स्रोत से डेटा इकट्ठा करें.
--java_language_version=<a string>
डिफ़ॉल्ट: ""- Java का भाषा वर्शन
--java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर इस्तेमाल किया जाता है. "लॉन्चर" विशेषता इस फ़्लैग को ओवरराइड करती है.
--java_runtime_version=<a string>
: "local_jdk" डिफ़ॉल्ट- Java रनटाइम वर्शन
--javacopt=<a string>
बार कई इस्तेमाल किए गए- javac में पास करने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string>
बार कई इस्तेमाल किए गए- Java VM को पास करने के लिए और विकल्प. ये विकल्प हर java_binary टारगेट के वर्चुअल मशीन (वीएम) स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- लेगसी मल्टीडेक्स को कंपाइल करते समय, उन क्लास की सूची जनरेट करने के लिए, बाइनरी फ़ाइल का इस्तेमाल किया जाता है जो मुख्य डेक में होनी चाहिए.
--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:प्रोटोक"-
प्रोटो-कंपाइलर का लेबल.
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_cc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain"-
Cto++ प्रोटोल को कंपाइल करने के तरीके के बारे में बताने वाला proto_lang_toolchain() का लेबल
टैग: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 सर्वर को शुरू करता है), तो 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 एट्रिब्यूट मौजूद हो. 'बंद है' का इस्तेमाल करें. 'sforce_count' BUILD विशेषता पर ध्यान दिए बिना, परीक्षण के लिए 'k' शार्ड लागू करने के लिए 'forced=k'.
--tool_java_language_version=<a string>
डिफ़ॉल्ट: ""- बिल्डर के दौरान ज़रूरी टूल एक्ज़ीक्यूट करने के लिए इस्तेमाल किया जाने वाला Java लैंग्वेज वर्शन
--tool_java_runtime_version=<a string>
डिफ़ॉल्ट: "remotejdk_11"- बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन
--[no]use_ijars
डिफ़ॉल्ट: "सही"- चालू होने पर, इस विकल्प की वजह से Java कंपाइलेशन, इंटरफ़ेस जार का इस्तेमाल करेगा. इससे तेज़ी से बढ़ता हुआ कंपाइलेशन हो सकता है, लेकिन गड़बड़ी वाले मैसेज अलग हो सकते हैं.
बिल्ड के विकल्प
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने पार्स किए हैं:
--distdir=<a path>
बार कई इस्तेमाल किए गए-
संग्रह को डाउनलोड करने के लिए नेटवर्क को ऐक्सेस करने से पहले उन्हें ढूंढने के लिए अतिरिक्त स्थान.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "गलत"-
अगर यह नीति सेट की जाती है, तो कैश मेमोरी में सेव होने पर कैश मेमोरी में सेव होने की स्थिति में, डेटा को रिपॉज़िटरी कैश मेमोरी में सेव कर दिया जाएगा. इसका इस्तेमाल डिस्क में जगह बचाने के लिए किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो डेटा डाउनलोड करने के लिए दिए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल यूआरएल के तौर पर करें. अगर इसकी जानकारी नहीं है, तो कैननिकल यूआरएल के तौर पर इसका इस्तेमाल करें. ऐसा इसलिए होता है, क्योंकि यूआरएल में बदलाव करने से, पेज को फिर से डाउनलोड किया जाता है. भले ही, कैश मेमोरी में एक जैसा हैश वाला डाउनलोड हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव की वजह से, डेटा स्टोर करने की जगह में कैश मेमोरी को मास्क नहीं किया जाता.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया गया है, तो बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं है.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
किसी डाउनलोड गड़बड़ी के लिए फिर से प्रयास करने की अधिकतम संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने की जगह के नियमों में, सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड बदले बिना, ऐसी मशीन पर बाहरी डेटा स्टोर करने की जगहें बनाई जा सकती हैं जो नियम के लेखक से धीमी हैं
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
http डाउनलोड से जुड़े सभी टाइम आउट, दिए गए फ़ैक्टर के आधार पर बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति बाहरी वैल्यू का डेटा फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी में सेव की गई जगह की जानकारी देती है. एक खाली स्ट्रिंग, जिसमें कैश मेमोरी को बंद करने का अनुरोध किया गया हो.
टैग: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>
बार कई इस्तेमाल किए गए-
इस नीति को बनाए रखने के लिए, स्थानीय रणनीतियों का इस्तेमाल करना. पासवर्ड के तौर पर 'स्थानीय' पास करने से, जो लोग नीति के मुताबिक काम करते हैं उनके लिए डिफ़ॉल्ट वैल्यू सेट की जाती है. [mnemonic=]local_stratepy[,local_stratepy,...] लेता है
टैग:execution
,host_machine_resource_optimizations
--dynamic_remote_strategy=<a '[name=]value1[,..,valueN]' assignment>
बार कई इस्तेमाल किए गए-
इस मॉनमोनिक सुविधा को रिमोट तरीके से इस्तेमाल करें. निमोनिक के तौर पर 'रिमोट' को पास करने से, उन वाक्यांशों के लिए डिफ़ॉल्ट वैल्यू सेट की जाती है जिनके बारे में याद नहीं रखा जाता. यह ज़रूरी है [mnemonic=]remote_stratepy[,remote_stratepy,...]
टैग:execution
,host_machine_resource_optimizations
--experimental_docker_image=<a string>
डिफ़ॉल्ट: ""-
डॉकर इमेज का नाम बताएं (उदाहरण के लिए, "ubuntu:new") जिसका इस्तेमाल डॉक करने की रणनीति का इस्तेमाल करते समय, सैंडबॉक्स की गई कार्रवाई को करने के लिए किया जाना चाहिए. साथ ही, प्लैटफ़ॉर्म के ब्यौरे में मौजूद Remote_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_sandbox_async_tree_delete_idle_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "0"-
अगर यह 0 है, तो कार्रवाई पूरा होते ही सैंडबॉक्स ट्री मिटा दें (इससे कार्रवाई पूरी होने में देरी हो सकती है). अगर शून्य से ज़्यादा हो, तो एसिंक्रोनस थ्रेड पूल पर ऐसे तीन नियमों को मिटाएं. साथ ही, जब बिल्ड चल रहा हो, तब उसका साइज़ 1 हो और सर्वर के कुछ समय से इस्तेमाल में न होने पर, इस फ़्लैग के बताए गए साइज़ तक बढ़ जाए.
टैग:host_machine_resource_optimizations
,execution
--experimental_sandbox_memory_limit=<an integer>
डिफ़ॉल्ट: "0"-
अगर 'सही है' पर सेट किया जाता है, तो हर Linux सैंडबॉक्स को मेमोरी में तय संख्या तक सीमित किया जाएगा. cgroups dir2 के लिए cgroups v2 और अनुमतियां ज़रूरी हैं.
टैग:execution
--experimental_sandboxfs_path=<a string>
डिफ़ॉल्ट: "sandboxfs"-
--experimental_use_sandboxfs के सही होने पर, सैंडबॉक्स फ़ाइल के बाइनरी पाथ का पाथ. अगर कोई नाम है, तो PATH में पाए गए नाम की पहली बाइनरी का उपयोग करें.
टैग:host_machine_resource_optimizations
,execution
--[no]experimental_split_xml_generation
डिफ़ॉल्ट: "सही"-
अगर यह फ़्लैग सेट है और टेस्ट कार्रवाई से test.xml फ़ाइल जनरेट नहीं होती, तो टेस्ट लॉग वाली डमी test.xml फ़ाइल जनरेट करने के लिए, Bazel एक अलग कार्रवाई का इस्तेमाल करता है. नहीं तो, बैज़ल, टेस्ट कार्रवाई के हिस्से के तौर पर एक test.xml जनरेट करता है.
टैग:execution
--experimental_total_worker_memory_limit_mb=<an integer, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "0"-
अगर सभी कर्मचारियों का कुल मेमोरी इस्तेमाल, तय सीमा से ज़्यादा हो जाता है, तो इस्तेमाल में न होने वाली यह संख्या शून्य से ज़्यादा हो जाएगी.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_use_hermetic_linux_sandbox
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो रूट को माउंट न करें. सिर्फ़ वही माउंट करें जो sandbox_add_माउंट_पेयर के साथ दिया गया है. इनपुट फ़ाइलें सैंडबॉक्स से सिमलिंक करने के बजाय सैंडबॉक्स से हार्डलिंक की जाएंगी. अगर कार्रवाई इनपुट फ़ाइलें सैंडबॉक्स से अलग एक फ़ाइल सिस्टम पर मौजूद हैं, तो इनपुट फ़ाइलों को कॉपी किया जाएगा.
टैग:execution
--[no]experimental_use_sandboxfs
डिफ़ॉल्ट: "गलत"-
सिमलिंक ट्री बनाने के बजाय, exefot डायरेक्ट्री बनाने के लिए सैंडबॉक्सf का इस्तेमाल करें. अगर "yes", --experimental_sandboxfs_path की ओर से दिया गया बाइनरी मान्य होना चाहिए और वह सैंडबॉक्सf के समर्थित वर्शन के मुताबिक होना चाहिए. अगर "ऑटो", तो बाइनरी मौजूद नहीं होगी या साथ में काम नहीं करेगी.
टैग:host_machine_resource_optimizations
,execution
--[no]experimental_use_windows_sandbox
डिफ़ॉल्ट: "गलत"- कार्रवाइयां चलाने के लिए, Windows सैंडबॉक्स का इस्तेमाल करें. अगर "yes", --experimental_window_sandbox_path की ओर से दिया गया बाइनरी मान्य होना चाहिए और वह सैंडबॉक्स fs के साथ काम करने वाले वर्शन से मेल खाना चाहिए. अगर "ऑटो", तो बाइनरी मौजूद नहीं होगी या साथ में काम नहीं करेगी.
--experimental_windows_sandbox_path=<a string>
डिफ़ॉल्ट: "BazelSandbox.exe"- --experimental_use_window_sandbox, सही होने पर इस्तेमाल करने के लिए Windows सैंडबॉक्स बाइनरी का पाथ. अगर कोई नाम है, तो PATH में पाए गए नाम की पहली बाइनरी का उपयोग करें.
--[no]experimental_worker_as_resource
डिफ़ॉल्ट: "सही"-
चालू होने पर, वर्कर को ResourceManager से संसाधन के तौर पर हासिल किया जाता है.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_worker_cancellation
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो बेज़ल रद्द करने वाले लोगों को अनुरोध भेज सकता है.
टैग:execution
--[no]experimental_worker_multiplex
डिफ़ॉल्ट: "सही"-
अगर इस सुविधा को चालू किया गया है, तो जो मल्टीप्लेक्सिंग मल्टीप्लेक्सिंग सुविधा के साथ काम करेंगे वे उस सुविधा का इस्तेमाल करेंगे.
टैग:execution
,host_machine_resource_optimizations
--[no]experimental_worker_multiplex_sandboxing
डिफ़ॉल्ट: "गलत"-
चालू होने पर, मल्टीप्लेक्स वर्कर सैंडबॉक्स कर पाएंगे. हर टास्क अनुरोध के लिए, उन्हें एक अलग सैंडबॉक्स डायरेक्ट्री का इस्तेमाल करना होगा. सिर्फ़ उन वर्कर को सैंडबॉक्स किया जाएगा जिनके लिए 'support-multiplex-sandboxing' लागू करने की ज़रूरत है.
टैग:execution
--[no]experimental_worker_strict_flagfiles
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को 'चालू है' पर सेट किया जाता है, तो ऐसे वर्कर के लिए ऐक्शन आर्ग्युमेंट में गड़बड़ी होती है जो वर्कर के लिए तय की गई ज़रूरी शर्तों को पूरा नहीं करते हैं. वर्कर आर्ग्युमेंट में, आर्ग्युमेंट की आखिरी सूची के तौर पर सिर्फ़ एक @flagfile आर्ग्युमेंट होना चाहिए.
टैग:execution
--genrule_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
सामान्य नियम इस्तेमाल करने का तरीका बताएं. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_stratepy=<value> या सिर्फ़ genrule को कंट्रोल करने के लिए --stratepy=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
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो हर Linux सैंडबॉक्स के पास अलग से एक खाली डायरेक्ट्री होगी, जिसे होस्ट फ़ाइल सिस्टम के साथ /tmp शेयर करने के बजाय, /tmp के तौर पर माउंट किया जाता है. सभी सैंडबॉक्स में होस्ट का/tmp देखते रहने के लिए --sandbox_add_माउंट_पेयर=/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
] डिफ़ॉल्ट: "अपने-आप"-
एक साथ चलने वाली नौकरियों की संख्या. कोई पूर्णांक या कीवर्ड ("अपने-आप", "Host_CPUS," PAS_RAM") का इस्तेमाल करता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जाता है. जैसे, "अपने-आप", "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">
डिफ़ॉल्ट: "अपने-आप"-
लोड करने/विश्लेषण के चरण के लिए इस्तेमाल होने वाले पैरलल थ्रेड की संख्या. इसमें एक पूर्णांक या कीवर्ड ("ऑटो", "POST_CPUS", "PARTNER_RAM") होता है. इसके बाद, वैकल्पिक रूप से किसी कार्रवाई ([-|*]<float>) का इस्तेमाल किया जाता है. "अपने-आप", "Host_CPUS*.5". "ऑटो", होस्ट संसाधनों के आधार पर एक उचित डिफ़ॉल्ट सेट करता है. कम से कम 1 होना चाहिए.
टैग:bazel_internal_configuration
--[no]reuse_sandbox_directories
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो सैंडबॉक्स न होने वाली कार्रवाइयों के लिए इस्तेमाल की जाने वाली डायरेक्ट्री को फिर से इस्तेमाल किया जा सकता है, ताकि सेट अप के लिए लगने वाली बेवजह की लागत से बचा जा सके.
टैग:host_machine_resource_optimizations
,execution
--sandbox_base=<a string>
डिफ़ॉल्ट: ""-
सैंडबॉक्स की मदद से, इस पाथ के नीचे सैंडबॉक्स डायरेक्ट्री बनाएं. आपके बिल्ड /टेस्ट में कई इनपुट फ़ाइलें होने पर परफ़ॉर्मेंस को बेहतर बनाने के लिए, tmpf पर कोई पाथ डालें (जैसे कि/run / smm). नोट: आपको रनिंग ऐक्शन से जनरेट की गई आउटपुट और इंटरमीडिएट फ़ाइलों को होल्ड करने के लिए tmpfs में काफ़ी रैम और खाली जगह चाहिए.
टैग:host_machine_resource_optimizations
,execution
--[no]sandbox_explicit_pseudoterminal
डिफ़ॉल्ट: "गलत"-
सैंडबॉक्स की गई कार्रवाइयों की सुविधा के लिए, स्यूडोटर्मिनल बनाने की सुविधा साफ़ तौर पर चालू करें. कुछ linux डिस्ट्रिब्यूशन के लिए, सैंडबॉक्स में प्रोसेस का ग्रुप आईडी 'tty' सेट करना ज़रूरी होता है. अगर इससे समस्याएं आ रही हैं, तो इस फ़्लैग को बंद किया जा सकता है, ताकि दूसरे ग्रुप का इस्तेमाल किया जा सके.
टैग:execution
--sandbox_tmpfs_path=<an absolute path>
बार कई इस्तेमाल किए गए-
सैंडबॉक्स की गई कार्रवाइयों के लिए, इस पूरे पाथ पर एक खाली, लिखने लायक डायरेक्ट्री माउंट करें (अगर सैंडबॉक्स करने की सुविधा लागू है, तो इसे अनदेखा कर दें).
टैग:host_machine_resource_optimizations
,execution
--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_stratesy (और --genrule_genrate. ज़्यादा जानकारी पाने के लिए, 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.*\ उदाहरण: --stratepy_regexp='CompLING.*/bar=local --stratepy_regexp=CompLING=sandboxed 'local' रणनीति के साथ '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">
बार कई इस्तेमाल किए गए-
अगर आप 'वर्कर' रणनीति का इस्तेमाल करते हैं, तो किसी वर्कर प्रोसेस (जैसे कि लगातार Java कंपाइलर) के कितने इंस्टेंस लॉन्च किए जा सकते हैं. इसे हर नाम के वर्कर के लिए अलग-अलग वैल्यू देने के लिए, [name=value] के तौर पर तय किया जा सकता है. कोई पूर्णांक या कीवर्ड ("अपने-आप", "Host_CPUS," PAS_RAM") का इस्तेमाल करता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जाता है. जैसे, "अपने-आप", "Host_CPUS*.5". 'ऑटो', मशीन की क्षमता के आधार पर उचित डिफ़ॉल्ट की गणना करता है. "=value", तय नहीं किए गए वाक्यांशों के लिए डिफ़ॉल्ट वैल्यू सेट करता है.
टैग:execution
,host_machine_resource_optimizations
--worker_max_multiplex_instances=<[name=]value, where value is an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
बार कई इस्तेमाल किए गए-
अगर मल्टीप्लेक्स वर्कर प्रोसेस को --experimental_worker_multiplex के साथ 'वर्कर' रणनीति का इस्तेमाल किया जाता है, तो ऐसे में एक साथ कई मल्टीप्लेक्स वर्कर प्रोसेस मिल सकती है. इसे हर नाम के वर्कर के लिए अलग-अलग वैल्यू देने के लिए, [name=value] के तौर पर तय किया जा सकता है. कोई पूर्णांक या कीवर्ड ("अपने-आप", "Host_CPUS," PAS_RAM") का इस्तेमाल करता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जाता है. जैसे, "अपने-आप", "Host_CPUS*.5". 'ऑटो', मशीन की क्षमता के आधार पर उचित डिफ़ॉल्ट की गणना करता है. "=value", तय नहीं किए गए वाक्यांशों के लिए डिफ़ॉल्ट वैल्यू सेट करता है.
टैग: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
- ऐसे विकल्प जो निर्देशों के आउटपुट को कंट्रोल करते हैं:
--[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>
बार कई इस्तेमाल किए गए-
कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. हर ग्रुप के आगे वैकल्पिक रूप से + या - का निशान होता है. आउटपुट ग्रुप के डिफ़ॉल्ट सेट में + अगर कम से कम एक ग्रुप प्रीफ़िक्स नहीं है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट छूट जाएगा. उदाहरण के लिए, --आउटपुट_ग्रुप=+foo,+बार, डिफ़ॉल्ट सेट, foo, और बार को जोड़ता है, जबकि -- आउटपुट_ग्रुप=foo, बार डिफ़ॉल्ट सेट को बदल देता है, ताकि सिर्फ़ foo और Bar बनाया जा सके.
टैग:execution
,affects_outputs
--[no]run_validations
डिफ़ॉल्ट: "सही"-
बिल्ड के हिस्से के तौर पर पुष्टि करने की कार्रवाइयां करनी हैं या नहीं. https://bazel.build/extending/rule#invalidation_action देखें
टैग:execution
,affects_outputs
- ऐसे विकल्प जो उपयोगकर्ता को उसके आउटपुट के बजाय, सही आउटपुट को कॉन्फ़िगर करने देते हैं, जिससे उसकी वैल्यू पर असर पड़ता है:
--aspects=<comma-separated list of options>
बार कई इस्तेमाल किए गए- टॉप-लेवल टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा-सेपरेटेड लिस्ट. अगर सूची में, part_aspect ज़रूरी आसपेक्ट रेशियो (चौड़ाई-ऊंचाई का अनुपात) सेवा देने वाली कंपनियों के ज़रिए ज़रूरी_सेवा का नाम देता है, तो सूची में मौजूद आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के पहले, हर आसपेक्ट के बाद {0}_aspect चलेगा. जिसके विज्ञापन देने वाले, कुछ आसपेक्ट रेशियो (लंबाई-चौड़ाई का डेटा) उपलब्ध कराते हैं. इसके अलावा,Some_aspect तब लागू होगा, जब एट्रिब्यूट के लिए तय किए गए सभी ज़रूरी पहलुओं को एट्रिब्यूट के तौर पर तय कर लिया जाएगा. any_aspect को, उन आसपेक्ट प्रोवाइडर के वैल्यू का ऐक्सेस मिल जाएगा. <bzl-file-label>%<aspect_name>, उदाहरण के लिए '//tools:my_def.bzl%my_aspect', जिसमें 'my_aspect', किसी फ़ाइल टूल/my_def.bzl की टॉप-लेवल वैल्यू है
--bep_maximum_open_remote_upload_files=<an integer>
डिफ़ॉल्ट: "-1"-
BEP आर्टफ़ैक्ट अपलोड करते समय, ज़्यादा से ज़्यादा खुली हुई फ़ाइलों की संख्या.
टैग:affects_outputs
--[no]experimental_convenience_symlinks
डिफ़ॉल्ट: "सामान्य"-
यह फ़्लैग कंट्रोल करता है कि सुविधा के सिमलिंक कैसे बनाए जाएंगे (बिल्ड के बाद, फ़ाइल फ़ोल्डर में सिमलिंक दिखेंगे). संभावित वैल्यू:
सामान्य (डिफ़ॉल्ट): बिल्ड के आधार पर, हर तरह का सुविधा सिमलिंक बनाया या मिटाया जाएगा.
साफ़: सभी सिमलिंक बिना किसी शर्त के मिटा दिए जाएंगे.
अनदेखा करें: सिमलिंक अकेले रह जाएंगे.
log_only: लॉग संदेश इस तरह जनरेट करें जैसे कि 'सामान्य' पास किया गया हो, लेकिन वास्तव में कोई फ़ाइल सिस्टम कार्रवाई नहीं करते हैं (टूल के लिए उपयोगी).
ध्यान दें कि सिर्फ़ वही सिमलिंक इस्तेमाल किए जा सकते हैं जिनके नाम --symlink_prefix:
टैग:affects_outputs
--[no]experimental_convenience_symlinks_bep_event
डिफ़ॉल्ट: "गलत"-
यह फ़्लैग कंट्रोल करता है कि हम buildEventServiceSymlinksIdentify को BuildEventProtocol में पोस्ट करेंगे या नहीं. अगर मान सही पर सेट है, तो BuildEventProtocol में][=SymlinksIdentified के लिए एक एंट्री होगी, जिसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक होंगे. गलत होने पर, BuildEventProtocol में मौजूद UtilitySymlinksIdentify किया गया एंट्री खाली हो जाएगा.
टैग:affects_outputs
--experimental_multi_cpu=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
उपलब्ध नहीं है. नहीं.
टैग:affects_outputs
,experimental
--remote_download_minimal
-
स्थानीय मशीन में रिमोट बिल्ड का कोई आउटपुट डाउनलोड नहीं करता. यह फ़्लैग, फ़्लैग किए गए ऐप्लिकेशन के लिए शॉर्टकट है: --experimental_inमेमोरी_jdeps_files, --experimental_inमेमोरी_डॉट_फ़ाइलें, --experimental_action_cache_store_output_metadata and --remote_download_outputs=minimal.
इसमें शामिल है:
--nobuild_runfile_links
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=minimal
टैग:affects_outputs
--remote_download_outputs=<all, minimal or toplevel>
डिफ़ॉल्ट: "सभी"-
अगर 'कम से कम' पर सेट किया जाता है, तो लोकल बिल्ड आउटपुट को डाउनलोड नहीं किया जाता. हालांकि, लोकल ऐक्शन के लिए यह ज़रूरी नहीं है. अगर 'टॉप लेवल' पर सेट किया जाता है, तो यह 'कम से कम' की तरह काम करता है. हालांकि, इसमें स्थानीय मशीन पर, टॉप लेवल के टारगेट के आउटपुट भी डाउनलोड होते हैं. अगर नेटवर्क बैंडविड्थ बहुत मुश्किल है, तो दोनों ही विकल्प बिल्ड के समय को काफ़ी कम कर सकते हैं.
टैग:affects_outputs
--remote_download_symlink_template=<a string>
डिफ़ॉल्ट: ""-
रिमोट बिल्ड आउटपुट को स्थानीय मशीन पर डाउनलोड करने के बजाय, सिंबॉलिक लिंक बनाएं. सांकेतिक लिंक का लक्ष्य टेम्प्लेट स्ट्रिंग के रूप में बताया जा सकता है. इस टेंप्लेट स्ट्रिंग में {ash} और {size_bytes} हो सकती हैं, जो ऑब्जेक्ट के हैश और बाइट में साइज़ तक बढ़ जाती है. उदाहरण के लिए, ये प्रतीकात्मक लिंक FUSE फ़ाइल सिस्टम पर ले जाते हैं, जो मांग पर CAS से ऑब्जेक्ट लोड करता है.
टैग:affects_outputs
--remote_download_toplevel
-
स्थानीय मशीन पर सिर्फ़ टॉप लेवल टारगेट के रिमोट आउटपुट डाउनलोड करता है. यह फ़्लैग, फ़्लैग किए गए ऐप्लिकेशन के लिए शॉर्टकट है: --experimental_inquery_jdeps_files, --experimental_inमेमोरी_डॉट_फ़ाइलें, --experimental_action_cache_store_output_metadata and --remote_download_outputs=toplevel.
इसमें शामिल है:
--experimental_inmemory_jdeps_files
--experimental_inmemory_dotd_files
--experimental_action_cache_store_output_metadata
--remote_download_outputs=toplevel
टैग:affects_outputs
--symlink_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
ऐसा प्रीफ़िक्स जो बिल्ड के बाद बनाए जाने वाले किसी भी सुविधा सिमलिंक से पहले जोड़ा जाता है. अगर इसे नहीं छोड़ा जाता, तो डिफ़ॉल्ट वैल्यू, बिल्ड टूल के नाम के बाद हाइफ़न होती है. अगर '/' पास किया जाता है, तो कोई सिमलिंक नहीं बनाए जाते और कोई चेतावनी नहीं दी जाती. चेतावनी: '/' के लिए खास फ़ंक्शन को जल्द ही हटा दिया जाएगा; इसके बजाय --experimental_convenience_symlinks=ignore का इस्तेमाल करें.
टैग:affects_outputs
- वे विकल्प जो यह तय करते हैं कि Bazel, बिल्ड के मान्य इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--[no]experimental_docker_privileged
डिफ़ॉल्ट: "गलत"-
अगर यह चालू है, तो बेज़ल कार्रवाई करते समय 'डॉकर रन' को -- खास अधिकार वाले फ़्लैग को पास कर देगा. यह आपके बिल्ड के लिए ज़रूरी हो सकता है, लेकिन इससे एक जैसा अनुभव भी कम हो सकता है.
टैग: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_sha_file के ज़रिए दी गई है.
टैग:affects_outputs
,experimental
--[no]incompatible_legacy_local_fallback
डिफ़ॉल्ट: "गलत"-
अगर यह नीति 'सही है' पर सेट है, तो सैंडबॉक्स की मदद से, स्थानीय रणनीति में बदला जा सकता है. यह फ़्लैग आखिर में डिफ़ॉल्ट रूप से 'गलत' पर सेट हो जाएगा और 'नहीं' विकल्प बन जाएगा. इसके बजाय - फ़ॉलबैक, --spawn_stratege या --Dynamic_local_stratege का इस्तेमाल करें.
टैग: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
डिफ़ॉल्ट: "गलत"-
अगर काम नहीं करता, तो यह noop. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने वाली विशेषता के बिना कोई config_setting //visible:public है. अगर इस फ़्लैग को 'सही' पर सेट किया जाता है, तो config_setting उसी लॉजिक का पालन करता है जो अन्य सभी नियमों को फ़ॉलो करता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो config_setting विज़िबिलिटी से जुड़ी पाबंदियां लागू करें. अगर गलत हो, तो हर config_setting हर टारगेट को दिखाई देता है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:
--[no]check_tests_up_to_date
डिफ़ॉल्ट: "गलत"-
जांच न करें, बस यह देखें कि वे अप-टू-डेट हैं या नहीं. अगर जांच के सभी नतीजे अप-टू-डेट हैं, तो जांच पूरी हो जाती है. अगर किसी जांच को बनाने या लागू करने की ज़रूरत होती है, तो गड़बड़ी की रिपोर्ट की जाती है और जांच नहीं हो पाती. यह विकल्प दिखाता है --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 बार की जाएंगी. अगर 'डिफ़ॉल्ट' है, तो नियमित जांचों के लिए सिर्फ़ एक टेस्ट किया जाएगा और तीन टेस्ट के लिए, साफ़ तौर पर 'फ़्लैकी' के तौर पर मार्क किए गए टेस्ट के लिए किया जाएगा. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. जहां flaky_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">
डिफ़ॉल्ट: "अपने-आप"-
एक साथ काम करने वाले लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. कोई पूर्णांक या कीवर्ड ("अपने-आप", "Host_CPUS," PAS_RAM") का इस्तेमाल करता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जाता है. जैसे, "अपने-आप", "Host_CPUS*.5". 0 का मतलब है कि स्थानीय संसाधन, एक साथ चलाने के बजाय स्थानीय टेस्ट जॉब की संख्या को सीमित कर देंगे. इसे --नौकरी के लिए ज़्यादा महत्व देने से कोई असर नहीं पड़ता.
टैग:execution
--[no]test_keep_going
डिफ़ॉल्ट: "सही"-
अगर यह जांच नहीं की जाती है, तो पास न होने पर, पूरा बिल्ड बंद हो जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट किए जाते हैं. भले ही, कुछ टेस्ट पास न हुए हों.
टैग:execution
--test_strategy=<a string>
डिफ़ॉल्ट: ""-
यह बताता है कि जांच करते समय किस रणनीति का इस्तेमाल करना चाहिए.
टैग:execution
--test_tmpdir=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- यह 'bazel test' के लिए बुनियादी अस्थायी डायरेक्ट्री के बारे में बताता है.
- Bzlmod आउटपुट और सिमेंटिक से जुड़े विकल्प:
--allow_yanked_versions=<a string>
बार कई इस्तेमाल किए गए-
मॉड्यूल वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय करें. इसका समाधान, समाधान किए गए डिपेंडेंसी ग्राफ़ में होगा. भले ही, उनका नाम रजिस्ट्री में यांकी पर बताया गया हो (अगर वह किसी रजिस्ट्री में नहीं आ रहा है). ऐसा न करने पर, याक किए गए वर्शन से रिज़ॉल्यूशन हट जाएगा. आप `BZLMOD_ALLOW_YANKED_वर्शनS` एनवायरमेंट वैरिएबल से, मंज़ूर किया गया यांक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (हम इसका सुझाव नहीं देते).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Bazel मॉड्यूल के साथ काम करने वाले वर्शन के बारे में जानें. मान्य वैल्यू को `गड़बड़ी` के तौर पर मार्क किया जाता है, ताकि समस्या का समाधान न हो पाने पर, उसे बंद किया जा सके. जांच बंद करने के लिए `गड़बड़ी` या मेल न खाने की स्थिति का पता लगने पर, चेतावनी वाली चेतावनी को प्रिंट किया जा सकता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
जांचें कि क्या रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच की सुविधा को बंद करने के लिए, `वैल्यू` को बंद कर दिया जाता है. मेल न खाने पर, चेतावनी को प्रिंट करने के लिए `चेतावनी` या समाधान से जुड़ी गड़बड़ी की सूचना देने के लिए `गड़बड़ी`.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को `dev_dependency` के रूप में अनदेखा कर देता है. ध्यान दें कि अगर इस फ़्लैग की वैल्यू कुछ भी हो, तब भी MODULE.bazel में उन डेवलपर डिपेंडेंसी को नज़रअंदाज़ किया जाता है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई इस्तेमाल किए गए- किसी मॉड्यूल को स्थानीय डायरेक्ट्री से बदल देता है.
--registry=<a string>
बार कई इस्तेमाल किए गए-
यह रजिस्ट्री को बताता है कि Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किन रजिस्ट्री का इस्तेमाल किया जाए. ऑर्डर ज़रूरी है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा. बाद में, सिर्फ़ रजिस्ट्री में वापस आएंगी.
टैग:changes_inputs
- वे विकल्प जिनसे लॉग की भाषा, फ़ॉर्मैट या जगह पर असर पड़ता है:
--[no]announce
डिफ़ॉल्ट: "गलत"-
उपलब्ध नहीं है. नहीं.
टैग:affects_outputs
--[no]debug_spawn_scheduler
डिफ़ॉल्ट: "गलत"--[no]experimental_bep_target_summary
डिफ़ॉल्ट: "गलत"- टारगेट की खास जानकारी वाले इवेंट को प्रकाशित करना है या नहीं.
--[no]experimental_build_event_expand_filesets
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो आउटपुट फ़ाइलों को दिखाते समय, BEP में Fileset को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो आउटपुट फ़ाइलों को दिखाते समय, BEP में रिलेटिव फ़ाइलसेट सिमलिंक को ठीक करें. --experimental_build_event_expand_filesets ज़रूरी है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
बिल्डिंग का बिल्ड इवेंट अपलोड करने के बाद, Bazel को ज़्यादा से ज़्यादा इतनी बार फिर से कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
: "1s"-
बीईपी अपलोड न होने पर, एक्स्पोनेंशियल बैकऑफ़ फिर से कोशिश करने की अवधि कम से कम. (घातांक: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
इसमें यह चुना जाता है कि बिल्ड इवेंट के प्रोटोकॉल में, आर्टफ़ैक्ट को कैसे अपलोड किया जाए.
टैग:affects_outputs
--[no]experimental_collect_local_sandbox_action_metrics
डिफ़ॉल्ट: "सही"-
चालू होने पर, सैंडबॉक्स करने की सुविधा का इस्तेमाल करने वाली स्थानीय कार्रवाइयों के लिए, परफ़ॉर्मेंस से जुड़े आंकड़े (जैसे कि उपयोगकर्ता और सिस्टम का समय) रिकॉर्ड किए जाते हैं
टैग:execution
--[no]experimental_docker_verbose
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो बेज़ल डॉक करने वाले सैंडबॉक्स की रणनीति के बारे में ज़्यादा जानकारी वाले मैसेज प्रिंट करेगा.
टैग:execution
--[no]experimental_materialize_param_files_directly
डिफ़ॉल्ट: "गलत"-
अगर पैरामीटर फ़ाइलों को मटीरियल किया जा रहा है, तो सीधे डिस्क पर लिखें.
टैग:execution
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 वर्णों के हिसाब से तय होती है. साथ ही, कार्रवाई करने के लिए, सबसे ज़्यादा संख्या ही इस्तेमाल की जा सकती है. यह विकल्प सेट करने पर, सभी नियमों के हिसाब से आंकड़े लिखे जाएंगे.
--experimental_repository_resolved_file=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो Starlark के डेटा स्टोर करने के उन सभी नियमों की पूरी जानकारी के साथ Starlark की वैल्यू लिखें जिन्हें लागू किया गया है.
टैग:affects_outputs
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "गलत"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग:affects_outputs
--explain=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
इससे, बिल्ड सिस्टम, बिल्ड के हर चरण की जानकारी देता है. जानकारी, बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग:affects_outputs
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
इसे इस्तेमाल करके, Targetcomplete इवेंट में लेगसी Key_outputs फ़ील्ड जनरेट होने से रोकने के लिए. Bazel से ResultStore के इंटिग्रेशन के लिए, राजनैतिक आउटपुट डालना ज़रूरी है.
टैग: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_output, 'गड़बड़ी' या 'सभी' हो. यह शोर वाले टेस्ट आउटपुट के बहुत ज़्यादा शोर से बचने के लिए उपयोगी है. लॉग हेडर में टेस्ट हेडर शामिल होता है. नकारात्मक मानों की कोई सीमा नहीं होती. आउटपुट पूरा या कुछ नहीं है.
टैग:test_runner
,terminal_output
,execution
--output_filter=<a valid Java regular expression>
डिफ़ॉल्ट: ब्यौरा देखें-
सिर्फ़ उन नियमों के लिए चेतावनियां दिखाता है जिनके नाम से, दिए गए रेगुलर एक्सप्रेशन का नाम मैच होता है.
टैग:affects_outputs
--progress_report_interval=<an integer in 0-3600 range>
डिफ़ॉल्ट: "0"-
अभी भी चल रही नौकरियों की रिपोर्ट के बीच लगने वाले सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड प्रिंट की जाएगी. इसके बाद, हर मिनट एक बार रिपोर्ट को रिपोर्ट किया जाएगा. --कर्सर की सुविधा चालू होने पर, हर सेकंड की प्रोग्रेस रिपोर्ट की जाती है.
टैग:affects_outputs
--remote_print_execution_messages=<failure, success or all>
डिफ़ॉल्ट: "असफलता"-
चुनें कि रिमोट कंट्रोल से जुड़े मैसेज कब प्रिंट करने हैं. वैल्यू के तौर पर, ` असफलता` का मतलब सिर्फ़ फ़ेल होने पर प्रिंट करना, कामयाबियों पर सिर्फ़ 'सफलता', और 'हमेशा' के तौर पर प्रिंट करने के लिए 'सभी' वैल्यू हैं.
टैग:terminal_output
--[no]sandbox_debug
डिफ़ॉल्ट: "गलत"-
सैंडबॉक्स करने की सुविधा के लिए डीबग करने की सुविधाएं चालू करता है. इसमें दो चीज़ें शामिल हैं: पहला, सैंडबॉक्स रूट सामग्री को एक बिल्ड के बाद अछूता छोड़ दिया जाता है (और अगर sandboxf का उपयोग किया जा रहा है, तो फ़ाइल सिस्टम माउंट रखा जाता है); और दूसरा, निष्पादन पर अतिरिक्त डीबगिंग जानकारी प्रिंट करता है. इससे 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_stratege वैल्यू के बिना, सभी जांचों को एक-एक करके लागू किया जा सकता है.
टैग:test_runner
,terminal_output
,execution
--test_summary=<short, terse, detailed, none or testcase>
डिफ़ॉल्ट: "छोटा"-
यह जांच करने से जुड़ी खास जानकारी के फ़ॉर्मैट के बारे में बताता है. मान्य वैल्यू, सिर्फ़ उन जांचों से जुड़ी जानकारी को प्रिंट करने के लिए 'छोटी' होती हैं जिन्हें रन किया गया था, 'ters', सिर्फ़ उन जांचों के बारे में जानकारी प्रिंट करने के लिए जिन्हें चलाया गया था. 'पूरी जानकारी', फ़ेल हो चुकी जांच के बारे में ज़्यादा जानकारी को प्रिंट करने के लिए, 'testcase' को टेस्ट केस के रिज़ॉल्यूशन में प्रिंट करने के लिए, 'जांच न हो पाए' के बारे में पूरी जानकारी प्रिंट करने के लिए और खास जानकारी को शामिल न करने के लिए 'कोई भी नहीं'.
टैग:terminal_output
--[no]verbose_explanations
डिफ़ॉल्ट: "गलत"-
--एक्सप्लेनेशन की सुविधा चालू होने पर, एक्सप्लेनेशंस की सुविधा ज़्यादा शब्दों में जानकारी देती है. इसका कोई असर नहीं पड़ता, अगर --पूरी जानकारी वाली सेटिंग चालू नहीं है.
टैग:affects_outputs
--[no]verbose_failures
डिफ़ॉल्ट: "गलत"-
अगर कोई निर्देश पूरा नहीं हो पाता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग:terminal_output
- सामान्य इनपुट के बारे में बताने या इसमें बदलाव करने वाले विकल्प, जो बेज़ेल कमांड से जुड़े होते हैं और किसी और कैटगरी में नहीं आते.:
--aspects_parameters=<a 'name=value' assignment>
बार कई इस्तेमाल किए गए-
कमांड-लाइन आसपेक्ट पैरामीटर की वैल्यू के बारे में बताता है. हर पैरामीटर की वैल्यू <param_name>=<param_value> से तय की जाती है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param' पैरामीटर - aspect सूची में कुछ पहलू का पैरामीटर है या सूची के किसी पहलू के लिए ज़रूरी है. इस विकल्प को कई बार इस्तेमाल किया जा सकता है. हालांकि, किसी एक पैरामीटर को एक से ज़्यादा बार वैल्यू असाइन नहीं की जा सकती.
टैग:loading_and_analysis
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय रिज़ॉल्व की गई फ़ाइल को पढ़ें
टैग:changes_inputs
--target_pattern_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह सेट है, तो बिल्ड यहां कमांड लाइन के बजाय, नाम वाली फ़ाइल के पैटर्न को पढ़ेगा. यहां किसी फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न बताने में गड़बड़ी हुई.
टैग:changes_inputs
- रिमोट कैश मेमोरी और एक्ज़ीक्यूशन के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होता है, जिसके बाद एक होस्ट नाम (`allow` और `block`) या दो पैटर्न होते हैं, एक मिलान करता है, और एक वैकल्पिक यूआरएल के रूप में इस्तेमाल करता है, जिसमें `1` से शुरू होने वाली बैक-रेफ़रंस होती हैं. एक ही यूआरएल देने के लिए, कई `rewrite` निर्देशों के लिए संभव है और इस मामले में एक से ज़्यादा यूआरएल मिलेंगे.
--[no]experimental_guard_against_concurrent_changes
डिफ़ॉल्ट: "गलत"- इसे किसी रिमोट कैश फ़ाइल में अपलोड करने से पहले, इनपुट फ़ाइलों के समय की जांच करने के लिए बंद करें. ऐसे कुछ मामले हो सकते हैं जिनमें Linux कर्नेल को फ़ाइलें लिखने में देरी होती है. इस वजह से, गलत नतीजे मिल सकते हैं.
--experimental_remote_build_event_upload=<all or minimal>
डिफ़ॉल्ट: "सभी"- अगर यह 'सभी' पर सेट है, तो BEP से जुड़े सभी लोकल आउटपुट, रिमोट कैश में अपलोड किए जाते हैं. अगर यह 'कम से कम' पर सेट है, तो BEP से रेफ़र किए गए लोकल आउटपुट, रिमोट कैश में अपलोड नहीं किए जाते. हालांकि, BEP के उपभोक्ताओं के लिए ज़रूरी फ़ाइलों को छोड़कर (उदाहरण के लिए, टेस्ट लॉग और टाइमिंग प्रोफ़ाइल). file:// स्कीम का इस्तेमाल, स्थानीय फ़ाइलों के पाथ के लिए किया जाता है और bytestream:// स्कीम का इस्तेमाल, पहले से अपलोड की गई फ़ाइलों के पाथ के लिए किया जाता है. डिफ़ॉल्ट रूप से 'सभी'.
--[no]experimental_remote_cache_async
डिफ़ॉल्ट: "गलत"- अगर सही है, तो रिमोट कैश I/O, जनरेट करने के बजाय बैकग्राउंड में होगा.
--[no]experimental_remote_cache_compression
डिफ़ॉल्ट: "गलत"- अगर यह चालू है, तो कैश ब्लॉब को zstd से कंप्रेस/डिकंप्रेस करें.
--experimental_remote_capture_corrupted_outputs=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- उस डायरेक्ट्री का पाथ जिसमें खराब आउटपुट कैप्चर किए जाएंगे.
--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_grpc_log=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- अगर खास तौर पर बताया गया है, तो फ़ाइल का पाथ, जीआरपीसी कॉल से जुड़ी जानकारी लॉग करने के लिए होता है. इस लॉग में क्रम से चलने वाले com.google.devtools.build.lib.remote.logging का क्रम होता है.RemoteExecutionLog.LogEntry protobufs नीचे दिए गए क्रम में लगे प्रोटोबफ़ मैसेज के आकार को दर्शाते हुए एक क्रम में आगे बढ़ें.
--[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 पर सेट की जाती है, तो कैश का साइज़ अनलिमिटेड होता है. प्रोजेक्ट के साइज़ के हिसाब से, सबसे कम वैल्यू होती है. इसे डिफ़ॉल्ट तौर पर 1,000 पर सेट किया जाता है.
--[no]incompatible_remote_build_event_upload_respect_no_cache
डिफ़ॉल्ट: "गलत"- अगर 'सही है' पर सेट किया गया है, तो जनरेट की गई कार्रवाई को कहीं से भी कैश मेमोरी में सेव करने की सुविधा नहीं होगी. इसके लिए, BEP से रेफ़र किए गए आउटपुट, रिमोट कैश मेमोरी में अपलोड नहीं किए जाते.
--[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_save_cached डिस्क डिस्क पर लागू नहीं होंगे. अगर मिली-जुली कैश मेमोरी का इस्तेमाल किया जाता है, तो:
-noremote_upload_local_results के नतीजे डिस्क कैश पर लिखे जाएंगे, लेकिन रिमोट कैश पर अपलोड नहीं होंगे.
--noremote_save_cached किए जाने के बाद Bazel डिस्क कैश में नतीजों की जांच करेगा, लेकिन रिमोट कैश में नहीं.
कोई-रिमोट-एक्ज़ीक्यूट कार्रवाई डिस्क कैश पर असर नहीं डाल सकती.
ज़्यादा जानकारी के लिए, #8216 पर जाएं.
टैग:incompatible_change
--[no]remote_accept_cached
डिफ़ॉल्ट: "सही"- कैश मेमोरी में सेव किए गए, ऐक्शन से जुड़े नतीजों को स्वीकार करना है या नहीं.
--remote_bytestream_uri_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- बाइटस्ट्रीम:// यूआरआई में इस्तेमाल किया जाने वाला होस्टनेम और इंस्टेंस का नाम, जो बिल्ड इवेंट स्ट्रीम में लिखे जाते हैं. यह विकल्प तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड बनाए जाते हैं. इसकी वजह से --remote_executor और --remote_instance_name, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाता. सेट न होने पर, यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.
--remote_cache=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- कैश मेमोरी में सेव होने वाले एंडपॉइंट का यूआरआई. समर्थित स्कीमा हैं http, https, grpc, grpcs (TLS के साथ grpc) और Unix (स्थानीय UNIX सॉकेट). अगर कोई स्कीमा उपलब्ध नहीं कराया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs पर सेट हो जाएगा. grpc://, http:// या unix: TLS को अक्षम करने वाला स्कीमा तय करें. https://bazel.build/remote/cacher देखें
--remote_cache_header=<a 'name=value' assignment>
बार कई इस्तेमाल किए गए- ऐसा हेडर डालें जिसे कैश अनुरोधों में शामिल किया जाएगा: --remote_cache_header=Name=Value. फ़्लैग को एक से ज़्यादा बार बताकर, कई हेडर पास किए जा सकते हैं. एक ही नाम की एक से ज़्यादा वैल्यू को, कॉमा लगाकर अलग की गई सूची में बदला जाएगा.
--remote_default_exec_properties=<a 'name=value' assignment>
बार कई इस्तेमाल किए गए-
अगर एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_Properties सेट नहीं है, तो डिफ़ॉल्ट exec प्रॉपर्टी को रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल करने के लिए सेट करें.
टैग:affects_outputs
--remote_default_platform_properties=<a string>
डिफ़ॉल्ट: ""- अगर लागू करने वाला प्लैटफ़ॉर्म पहले से Remote_execution_property सेट नहीं करता है, तो डिफ़ॉल्ट तौर पर सेट की गई प्रॉपर्टी को रिमोट एपीआई के लिए सेट करें. अगर होस्ट प्लैटफ़ॉर्म को, एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर रिमोट तरीके से एक्ज़ीक्यूट करने के लिए चुना जाता है, तो भी इस वैल्यू का इस्तेमाल किया जाएगा.
--remote_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 पर सेट हो जाएगा. grpc:// या Unix दर्ज करें: TLS को बंद करने वाला स्कीमा.
--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_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "60 सेकंड"- रिमोट एक्ज़ीक्यूशन और कैश कॉल का इंतज़ार करने के लिए ज़्यादा से ज़्यादा समय. REST कैश मेमोरी के लिए, यह कनेक्ट और रीड टाइम आउट, दोनों होता है. इन इकाइयों का इस्तेमाल किया जा सकता है: दिन (d), घंटे (h), मिनट (m), सेकंड (s), और मिलीसेकंड (मिलीसेकंड). अगर इकाई को छोड़ दिया जाता है, तो मान को सेकंड माना जाता है.
--[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' निर्देश के साथ किए जाने वाले टेस्ट के सेट पर असर नहीं डालता. ये फ़िल्टर, जांच के फ़िल्टर करने के विकल्पों से कंट्रोल होते हैं, जैसे कि '--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>
डिफ़ॉल्ट: ब्यौरा देखें- डायरेक्ट्री का पाथ, जहां Bazel, कार्रवाइयों और ऐक्शन आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.
--embed_label=<a one-line string>
डिफ़ॉल्ट: ""- बाइनरी नियंत्रण में स्रोत नियंत्रण संशोधन या रिलीज़ लेबल एम्बेड करें
--execution_log_binary_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में इस्तेमाल किए गए स्पॉन को सीमांकित स्पॉन प्रोटोस के तौर पर लॉग करें. लॉग को सबसे पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, उसे शुरू करने के आखिर में, एक स्थिर क्रम में लगाया जाता है. इसमें सीपीयू और मेमोरी का इस्तेमाल किया जा सकता है. मिलते-जुलते फ़्लैग: --execution_log_json_file (ऑर्डर किया गया टेक्स्ट json फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम वाला बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमंड दिखाने के लिए).
--execution_log_json_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में इस्तेमाल किए गए स्पॉन्स को लॉग इन करें. इनमें, इस्तेमाल किए गए स्पॉन प्रोटोस को JSON के तौर पर दिखाएं. लॉग को सबसे पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, उसे शुरू करने के आखिर में, एक स्थिर क्रम में लगाया जाता है. इसमें सीपीयू और मेमोरी का इस्तेमाल किया जा सकता है. मिलते-जुलते फ़्लैग: मिलते-जुलते फ़्लैग: --execution_log_binary_file (ऑर्डर किया गया बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम वाला बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमंड दिखाने के लिए).
--[no]expand_test_suites
डिफ़ॉल्ट: "सही"-
विश्लेषण करने से पहले, test_suite टारगेट को अपने मूल टेस्ट में शामिल करें. जब यह फ़्लैग चालू (डिफ़ॉल्ट) हो, तो टेस्ट सुइट से जुड़े टेस्ट पर नेगेटिव टारगेट पैटर्न लागू होगा, नहीं तो ऐसा होगा. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड-लेवल के टॉप-लेवल आसपेक्ट लागू किए जाते हैं. इसके बाद, वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग:loading_and_analysis
--experimental_credential_helper=<An (unresolved) path to a credential helper for a scope.>
बार कई इस्तेमाल किए गए- क्रेडेंशियल हेल्पर को कॉन्फ़िगर करता है, ताकि वह इस्तेमाल किए गए दायरे (डोमेन) के क्रेडेंशियल की जानकारी हासिल कर सके. क्रेडेंशियल हेल्पर के क्रेडेंशियल को <code>--google_default_क्रेडेंशियल</code>, `--google_क्रेडेंशियल` या <code>.netrc</code> के क्रेडेंशियल से ज़्यादा प्राथमिकता दी जाती है. https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-क्रेडेंशियल-helpers.
--experimental_credential_helper_cache_duration=<An immutable length of time.>
डिफ़ॉल्ट: "30 मीटर"- वह अवधि कॉन्फ़िगर करती है जिसके लिए क्रेडेंशियल हेल्पर के क्रेडेंशियल कैश किए जाते हैं. किसी अलग वैल्यू के साथ शुरू करने से, पहले से मौजूद एंट्री के लाइफ़टाइम में बदलाव होगा; कैश मेमोरी मिटाने के लिए, शून्य डालें. एक साफ़ निर्देश, हमेशा कैश मेमोरी को खाली करता है. भले ही, इस फ़्लैग पर ध्यान न दिया गया हो.
--experimental_credential_helper_timeout=<An immutable length of time.>
: "5s"- क्रेडेंशियल हेल्पर के लिए, टाइम आउट कॉन्फ़िगर करता है. इस टाइम आउट में जवाब देने में विफल रहने वाले क्रेडेंशियल हेल्पर निरस्त किए जाएंगे.
--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>
डिफ़ॉल्ट: ""- पक्षों के पक्ष में रोक लगा दी गई. फ़िल्टर उन टारगेट का सेट है जिनके लिए Additional_action शेड्यूल करना है.
--[no]experimental_extra_action_top_level_only
डिफ़ॉल्ट: "गलत"- पक्षों के पक्ष में रोक लगा दी गई. सिर्फ़ टॉप लेवल के टारगेट के लिए additional_action शेड्यूल करता है.
--[no]experimental_prioritize_local_actions
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है, तो जो कार्रवाइयां सिर्फ़ स्थानीय तौर पर हो सकती हैं उन्हें रिसॉर्स हासिल करने का पहला मौका मिलता है. साथ ही, डाइनैमिक तौर पर काम करने वाले कर्मचारियों को दूसरा मौका मिलता है. साथ ही, डाइनैमिक तौर पर चलाई जाने वाली कार्रवाइयां, आखिरी होती हैं.
टैग:execution
--experimental_spawn_scheduler
-
स्थानीय रूप से और कहीं से भी साथ-साथ कार्रवाइयां करके, डाइनैमिक एक्ज़ीक्यूशन चालू करें. बेज़ल हर कार्रवाई को स्थानीय तौर पर और दूर से ही करता है और सबसे पहले पूरा होने वाली कार्रवाई चुनता है. अगर कोई कार्रवाई वर्कर पर काम करती है, तो लोकल ऐक्शन को स्थायी वर्कर मोड में चलाया जाएगा. किसी खास ऐक्शन ऐक्शन के लिए डाइनैमिक एक्ज़ीक्यूशन चालू करने के लिए, `--internal_spawn_Scheduler` और `--stratepy=<mnemonic>=Dynamic` फ़्लैग का इस्तेमाल करें.
इसमें शामिल है:
--internal_spawn_scheduler
--spawn_strategy=dynamic
--[no]experimental_worker_sandbox_hardening
डिफ़ॉल्ट: "गलत"-
अगर इसे चालू किया जाता है, तो वर्कर एक सख्त सैंडबॉक्स में चलेंगे, अगर इसे लागू करने की अनुमति होगी.
टैग:execution
--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 कनेक्शन के लिए, Keep-alive पिंग कॉन्फ़िगर करता है. अगर यह सेट है, तो कनेक्शन पर कोई रीड ऑपरेशन न करने के काफ़ी समय बाद Bazel पिंग भेजता है, लेकिन केवल तभी जब gRPC कॉल कम से कम एक लंबित हो. समय को दूसरे विवरण के स्तर के रूप में देखा जाता है; एक सेकंड से कम के मान को सेट करने में गड़बड़ी होती है. डिफ़ॉल्ट रूप से, कीप-अलाइव के लिए पिंग बंद होते हैं. इस सेटिंग को चालू करने से पहले, आपको सेवा के मालिक के साथ मिलकर काम करना चाहिए. उदाहरण के लिए, इस फ़्लैग को 30 सेकंड की वैल्यू सेट करने के लिए, यह इस तरह करना चाहिए --grpc_keepalive_time=30s
--grpc_keepalive_timeout=<An immutable length of time.>
डिफ़ॉल्ट: "20 सेकंड"- आउटगोइंग gRPC कनेक्शन के लिए, कीप-अलाइव टाइम आउट कॉन्फ़िगर करता है. अगर --grpc_keepalive_time के साथ कीप-अलाइव पिंग की सुविधा चालू है, तो तय समय के बाद, अगर पिंग करने पर जवाब नहीं मिलता है, तो बाज़ेल के कनेक्शन का टाइम आउट हो जाता है. समय को दूसरे विवरण के स्तर के रूप में देखा जाता है; एक सेकंड से कम के मान को सेट करने में गड़बड़ी होती है. अगर कीप-लाइव पिंग बंद हैं, तो इस सेटिंग को अनदेखा कर दिया जाता है.
--[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"- Bela के लिए उपलब्ध लोकल सीपीयू कोर की कुल संख्या को साफ़ तौर पर सेट करें, ताकि बिल्ड से जुड़ी कार्रवाइयों को स्थानीय तौर पर किया जा सके. एक पूर्णांक या "होस्ट_CPUS" लेता है, जिसके बाद [-|*]<float> आता है (उदाहरण के लिए, उपलब्ध CPU कोर का इस्तेमाल करने के लिए PAS_CPUS*.5. डिफ़ॉल्ट रूप से, Bazel सिस्टम कॉन्फ़िगरेशन की क्वेरी करके उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाएगा.
--local_ram_resources=<an integer, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "Host_RAM*.67"- स्थानीय रूप से बनाई गई बिल्ड कार्रवाइयों पर खर्च करने के लिए, Bazel को उपलब्ध लोकल होस्ट रैम (MB में) की कुल संख्या को साफ़ तौर पर सेट करें. पूरा अंक लेता है या "होस्ट_रैम" लेता है. इसके बाद, [-|*]<float> डालें होस्ट_रैम*.5 (इसके लिए, फ़ोन की रैम का आधा हिस्सा इस्तेमाल किया जाता है). डिफ़ॉल्ट रूप से, Bazel, सिस्टम कॉन्फ़िगरेशन की क्वेरी करके, रैम की उपलब्ध मेमोरी का अनुमान लगाता है. इस तरह, रैम का 67% इस्तेमाल किया जाता है.
--local_termination_grace_seconds=<an integer>
डिफ़ॉल्ट: "15"- टाइम आउट की वजह से, किसी लोकल प्रोसेस को बंद करने और उसे ज़बरदस्ती बंद करने के बीच इंतज़ार करना.
--override_repository=<an equals-separated mapping of repository name to path>
बार कई इस्तेमाल किए गए- डेटा स्टोर करने की जगह को स्थानीय डायरेक्ट्री से बदल देता है.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- इसमें, पैकेजन को अलग करने की सूची है. इसमें, पैकेज की तलाश कहां की गई है. '%workspace%' से शुरू होने वाले एलिमेंट, आस-पास के फ़ाइल फ़ोल्डर के हिसाब से होते हैं. शामिल न करने या खाली छोड़ने पर, डिफ़ॉल्ट रूप से 'बेज़ल की जानकारी के लिए डिफ़ॉल्ट पैकेज पाथ' डाला जाता है.
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर यह चालू है, तो बेज़ल "पैकेज लोड हो रहा है:" मैसेज प्रिंट कर लेता है.
--test_lang_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- टेस्ट भाषाओं की कॉमा-सेपरेटेड लिस्ट तय करता है. निकाली गई भाषाओं को तय करने के लिए हर भाषा को वैकल्पिक रूप से '-' से पहले जोड़ा जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जो तय भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया जाने वाला नाम, *_test नियम के लिए भाषा के प्रीफ़िक्स से मेल खाना चाहिए. उदाहरण के लिए, 'cc', 'java', 'py' वगैरह में से कोई एक विकल्प. यह विकल्प --build_tests_only व्यवहार और जांच कमांड पर असर डालता है.
--test_size_filters=<comma-separated list of values: small, medium, large or enormous>
डिफ़ॉल्ट: ""- इससे, टेस्ट साइज़ की कॉमा-सेपरेटेड लिस्ट बनती है. शामिल न किए जाने वाले साइज़ को तय करने के लिए, हर साइज़ को पहले '-' से पहले रखा जा सकता है. सिर्फ़ वे टेस्ट टारगेट ही मिलेंगे जिनमें कम से कम एक शामिल किया गया साइज़ हो और बाहर रखा गया कोई साइज़ न हो. यह विकल्प --build_tests_only व्यवहार और परीक्षण आदेश को प्रभावित करता है.
--test_tag_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- टेस्ट टैग की कॉमा-सेपरेटेड लिस्ट तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए हर टैग के आगे वैकल्पिक रूप से '-' हो सकता है. सिर्फ़ वे टेस्ट टारगेट ही मिलेंगे जिनमें कम से कम एक शामिल किया गया टैग होता है और बाहर निकाला गया कोई भी टैग नहीं होता है. यह विकल्प --build_tests_only व्यवहार और परीक्षण आदेश को प्रभावित करता है.
--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal>
डिफ़ॉल्ट: ""- यह जांच करने के टाइम आउट की ऐसी सूची है जिसमें कॉमा लगाकर अलग किए गए हैं. शामिल न करने के टाइम आउट तय करने के लिए, हर टाइम आउट को वैकल्पिक रूप से '-' से पहले रखा जा सकता है. सिर्फ़ वे टेस्ट टारगेट ही मिलेंगे जिनमें टारगेट किए गए टाइम आउट में से, कम से कम एक टाइम आउट शामिल हो. साथ ही, इनमें ऐसे सभी टाइम आउट (टाइम आउट) शामिल नहीं होने चाहिए जो बाहर रखे गए हैं. यह विकल्प --build_tests_only व्यवहार और परीक्षण आदेश को प्रभावित करता है.
--tls_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- किसी ऐसे TLS सर्टिफ़िकेट के पाथ की जानकारी दें जिस पर, सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.
--tls_client_certificate=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए TLS क्लाइंट सर्टिफ़िकेट बताएं; क्लाइंट की पुष्टि करने की सुविधा चालू करने के लिए, आपको क्लाइंट कुंजी भी देनी होगी.
--tls_client_key=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- इस्तेमाल करने के लिए, TLS क्लाइंट कुंजी तय करें. क्लाइंट सर्टिफ़िकेट की सुविधा चालू करने के लिए, आपको क्लाइंट सर्टिफ़िकेट भी देना होगा.
--workspace_status_command=<path>
डिफ़ॉल्ट: ""- बिल्ड की शुरुआत में, कुंजी/वैल्यू पेयर के तौर पर फ़ाइल फ़ोल्डर की स्थिति की जानकारी देने वाला एक निर्देश दिया गया. पूरी जानकारी के लिए, उपयोगकर्ता मैन्युअल पढ़ें. उदाहरण के लिए, टूल/buildstamp/get_workspace_status भी देखें.
- बिल्डिंग को एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:
--[no]check_up_to_date
डिफ़ॉल्ट: "गलत"-
बिल्ड न करें, बस देखें कि वह अप-टू-डेट है या नहीं. अगर सभी टारगेट अप-टू-डेट हैं, तो बिल्ड सही तरीके से पूरा हो जाता है. अगर किसी भी चरण को पूरा करने की ज़रूरत है, तो गड़बड़ी की शिकायत की जाती है और बिल्ड काम नहीं करता.
टैग: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
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो फिर बेज़ल नए स्पॉन में टेस्ट के लिए कवरेज को प्रोसेस करेगा.
टैग:execution
--[no]experimental_split_xml_generation
डिफ़ॉल्ट: "सही"-
अगर यह फ़्लैग सेट है और टेस्ट कार्रवाई से test.xml फ़ाइल जनरेट नहीं होती, तो टेस्ट लॉग वाली डमी test.xml फ़ाइल जनरेट करने के लिए, Bazel एक अलग कार्रवाई का इस्तेमाल करता है. नहीं तो, बैज़ल, टेस्ट कार्रवाई के हिस्से के तौर पर एक test.xml जनरेट करता है.
टैग:execution
--[no]experimental_strict_fileset_output
डिफ़ॉल्ट: "गलत"-
अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलें मानेंगे. न तो ये डायरेक्ट्री को पार करेंगे और न ही सिमलिंक के लिए संवेदनशील बनेंगे.
टैग:execution
--genrule_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
सामान्य नियम इस्तेमाल करने का तरीका बताएं. इस फ़्लैग को हटा दिया जाएगा. इसके बजाय, सभी कार्रवाइयों को कंट्रोल करने के लिए --spawn_stratepy=<value> या सिर्फ़ genrule को कंट्रोल करने के लिए --stratepy=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
] डिफ़ॉल्ट: "अपने-आप"-
एक साथ चलने वाली नौकरियों की संख्या. कोई पूर्णांक या कीवर्ड ("अपने-आप", "Host_CPUS," PAS_RAM") का इस्तेमाल करता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जाता है. जैसे, "अपने-आप", "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">
डिफ़ॉल्ट: "अपने-आप"-
लोड करने/विश्लेषण के चरण के लिए इस्तेमाल होने वाले पैरलल थ्रेड की संख्या. इसमें एक पूर्णांक या कीवर्ड ("ऑटो", "POST_CPUS", "PARTNER_RAM") होता है. इसके बाद, वैकल्पिक रूप से किसी कार्रवाई ([-|*]<float>) का इस्तेमाल किया जाता है. "अपने-आप", "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', सभी Genरूल कार्रवाइयों के लिए, कार्रवाई करने की जानकारी में 'Requires-x' जोड़ता है.
'(?!Genrule).*=-requires-x', उन सभी कार्रवाइयों के लिए निष्पादन जानकारी से 'Requires-x' हटा देता है, जो सामान्य नहीं हैं.
टैग:execution
,affects_outputs
,loading_and_analysis
--persistent_android_dex_desugar
-
कर्मचारियों का इस्तेमाल करके, Android के लिए Dex और काम करने की डिफ़ॉल्ट कार्रवाइयों को चालू करें.
इसमें शामिल है:
--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
{11/--strategy=ManifestMerger=worker
{
}
--persistent_multiplex_android_dex_desugar
-
कर्मचारियों की मदद से, मल्टीप्लेक्स किए गए Android Dex और Desgar ऐक्शन चालू करें.
इसमें शामिल है:
--persistent_android_dex_desugar
--modify_execution_info=Desugar=+supports-multiplex-workers
--modify_execution_info=DexBuilder=+supports-multiplex-workers
टैग:host_machine_resource_optimizations
,execution
--persistent_multiplex_android_resource_processor
-
कर्मियों का उपयोग करके मल्टीप्लेक्स किए गए Android संसाधन प्रोसेसर को चालू करें.
इसमें शामिल है:
--persistent_android_resource_processor
--modify_execution_info=AaptPackage=+supports-multiplex-workers
--modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
--modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
--modify_execution_info=RClassGenerator=+supports-multiplex-workers
--modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
--modify_execution_info=AndroidAapt2=+supports-multiplex-workers
--modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
--modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
--modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
--modify_execution_info=ManifestMerger=+supports-multiplex-workers
--modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
{11/--modify_execution_info=ManifestMerger=+supports-multiplex-workers
{1
}} --persistent_multiplex_android_tools
-
Android के लिए, लगातार और मल्टीप्लेक्स किए गए टूल चालू करें. इन टूल की मदद से डीक्सिंग, डीजर्जिंग, और संसाधन की प्रोसेसिंग की जा सकती है.
इसमें शामिल है:
--persistent_multiplex_android_resource_processor
--persistent_multiplex_android_dex_desugar
टैग:host_machine_resource_optimizations
,execution
--spawn_strategy=<comma-separated list of options>
डिफ़ॉल्ट: ""-
तय करें कि स्पॉन ऐक्शन डिफ़ॉल्ट तौर पर कैसे किए जाते हैं. सबसे ज़्यादा से सबसे कम प्राथमिकता वाली रणनीतियों की कॉमा-सेपरेटेड लिस्ट को स्वीकार किया जाता है. हर कार्रवाई के लिए, बेज़ल रणनीति को सबसे ज़्यादा प्राथमिकता देने वाली रणनीति चुनते हैं. डिफ़ॉल्ट वैल्यू "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_stratesy (और --genrule_genrate. ज़्यादा जानकारी पाने के लिए, 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.*\ उदाहरण: --stratepy_regexp='CompLING.*/bar=local --stratepy_regexp=CompLING=sandboxed 'local' रणनीति के साथ 'CompLING //foo/bar/baz' चलाएगा, लेकिन क्रम को उलटा करने पर यह 'सैंडबॉक्स' के साथ चलेगा.
टैग:execution
- कार्रवाई चलाने के लिए इस्तेमाल होने वाले टूलचेन को कॉन्फ़िगर करने वाले विकल्प:
--android_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट कंपाइलर.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_crosstool_top=<a build target label>
डिफ़ॉल्ट: "//external:android/crosstool"-
Android बिल्ड के लिए इस्तेमाल होने वाले C++ कंपाइलर की लोकेशन.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
Android टारगेट grte_top.
टैग:changes_inputs
,loading_and_analysis
,loses_incremental_state
--android_manifest_merger=<legacy, android or force_android>
डिफ़ॉल्ट: "android"-
Android_binary नियमों के लिए मेनिफ़ेस्ट मर्जर को चुनता है. फ़्लैग करें, ताकि Android मर्जर के लेगसी मर्जर से ट्रांज़िशन किया जा सके.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--android_platforms=<a build target label>
डिफ़ॉल्ट: ""-
उन प्लैटफ़ॉर्म को सेट करता है, जिनका इस्तेमाल android_binary टारगेट करता है. अगर एक से ज़्यादा प्लैटफ़ॉर्म दिए गए हैं, तो बाइनरी एक फ़ैट 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-बीटा).
टैग: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_Merger"-
उस बाइनरी की जगह जिसका इस्तेमाल, रॉ कवरेज रिपोर्ट को प्रोसेस करने के लिए किया जाता है. यह वर्तमान में एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट रूप से '//tools/test:lcov_Merger'.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_report_generator=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_report_generator"-
कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल की जाने वाली बाइनरी की जगह. यह वर्तमान में एक ऐसा फ़ाइल ग्रुप होना चाहिए जिसमें एक फ़ाइल, बाइनरी हो. डिफ़ॉल्ट '//tools/test:coverage_report_generator'.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--coverage_support=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/test:coverage_support"-
सहायता कवरेज की ऐसी फ़ाइलें जो कोड कवरेज इकट्ठा करने वाली हर जांच कार्रवाई की जानकारी में मौजूद होती हैं. डिफ़ॉल्ट वैल्यू '//tools/test/coverage_support'.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
--crosstool_top=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:toolchain"-
C++ कोड को कंपाइल करने में इस्तेमाल होने वाले क्रॉसटूल पैकेज का लेबल.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--custom_malloc=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कस्टम मैलक को लागू करने के बारे में बताता है. यह सेटिंग, बिल्ड नियमों में मैलक एट्रिब्यूट को बदल देती है.
टैग:changes_inputs
,affects_outputs
--experimental_add_exec_constraints_to_targets=<a '<RegexFilter>=<label1>[,<label2>,...]' assignment>
बार कई इस्तेमाल किए गए-
कॉमा-सेपरेटेड रेगुलर एक्सप्रेशन की सूची, हर वैकल्पिक रूप से - (नेगेटिव एक्सप्रेशन) से शुरू होती है, कॉमा-सेपरेटेड कंस्ट्रेंट टारगेट टारगेट की सूची को (=) असाइन की जाती है. अगर कोई टारगेट, किसी नेगेटिव एक्सप्रेशन से मेल नहीं खाता है और कम से कम एक पॉज़िटिव एक्सप्रेशन है, तो इसका टूलचेन रिज़ॉल्यूशन इस तरह से किया जाएगा मानो यह कंस्ट्रेंट वैल्यू को एक्ज़ीक्यूशन कंस्ट्रेंट के तौर पर बताता हो. उदाहरण: //demo,-test=@platforms//cpus:x86_64, //x के अंतर्गत किसी भी लक्ष्य में 'x86_64' जोड़ देगा, उन लोगों को छोड़कर जिनके नाम में 'test' है.
टैग:loading_and_analysis
--[no]experimental_enable_objc_cc_deps
डिफ़ॉल्ट: "सही"-
ob_c_* नियमों को cc_library पर निर्भर होने देता है और किसी भी objc निर्भरता को बनाने के साथ-साथ --ios_<--ios_cpu>" को -ios_multi_cpu में किसी भी मान के लिए सेट करें.
टैग:loading_and_analysis
,incompatible_change
--[no]experimental_include_xcode_execution_requirements
डिफ़ॉल्ट: "गलत"-
अगर यह सेट है, तो हर Xcode ऐक्शन में, "Requires-xcode:{version}" लागू करने की शर्त जोड़ें. अगर xcode वर्शन में हाइफ़न किया गया लेबल है, तो "ज़रूरी है-xcode-label:{version_label}" लागू करने की ज़रूरी शर्त भी जोड़ें.
टैग:loses_incremental_state
,loading_and_analysis
,execution
--[no]experimental_prefer_mutual_xcode
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो सबसे हाल के Xcode का इस्तेमाल करें. यह स्थानीय तौर पर और कहीं से भी उपलब्ध होता है. अगर गलत है या एक साथ कई वर्शन उपलब्ध नहीं हैं, तो xcode-select के ज़रिए चुने गए स्थानीय Xcode वर्शन का इस्तेमाल करें.
टैग:loses_incremental_state
--extra_execution_platforms=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
वे प्लैटफ़ॉर्म जो एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर काम करते हैं. प्लैटफ़ॉर्म सटीक टारगेट या टारगेट पैटर्न के रूप में बताए जा सकते हैं. रजिस्टर किए गए प्लैटफ़ॉर्म से पहले इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इसके लिए, रजिस्टर करें_execution_platforms() का इस्तेमाल करें.
टैग:execution
--extra_toolchains=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
टूलचेन नियमों के दौरान ध्यान दिए जाने वाले टूलचेन नियम. टूलचेन सटीक रूप से या टारगेट पैटर्न के रूप में तय किए जा सकते हैं. ये टूलटिप, WORKSPACE फ़ाइल में रजिस्टर किए गए टूल से पहले की जाती हैं. इसके लिए, रजिस्टर किए गए टूल टूल का इस्तेमाल किया जाता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
चेक की गई लाइब्रेरी की लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू, क्रॉसटूल टूलचेन से चुनी जाती है और आपको इसे कभी भी बदलने की ज़रूरत नहीं होती.
टैग:action_command_lines
,affects_outputs
--host_compiler=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
C++ कंपाइलर का इस्तेमाल होस्ट कंपाइलेशन के लिए किया जाता है. अगर --host_crosstool_top सेट नहीं है, तो इसे अनदेखा कर दिया जाता है.
टैग:loading_and_analysis
,execution
--host_crosstool_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
डिफ़ॉल्ट रूप से, होस्ट कॉन्फ़िगरेशन के लिए --crosstool_top और --compiler विकल्प का भी इस्तेमाल किया जाता है. अगर यह फ़्लैग दिया गया है, तो Bazel दिए गए क्रॉस-टूल_टॉप के लिए डिफ़ॉल्ट libc और कंपाइलर इस्तेमाल करता है.
टैग:loading_and_analysis
,changes_inputs
,affects_outputs
--host_grte_top=<a label>
डिफ़ॉल्ट: ब्यौरा देखें-
तय किए जाने पर, यह सेटिंग, होस्ट कॉन्फ़िगरेशन के लिए libc की टॉप लेवल डायरेक्ट्री (--grte_top) को बदल देती है.
टैग:action_command_lines
,affects_outputs
--host_platform=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म के नियम का लेबल, जो होस्ट के सिस्टम के बारे में बताता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--[no]incompatible_disable_expand_if_all_available_in_flag_set
डिफ़ॉल्ट: "सही"-
अगर सही है, तो Bazel, एक्सपैंशन_if_all_available को फ़्लैग_सेट में दिखाने की अनुमति नहीं देगा(माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7008 देखें).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_dont_enable_host_nonhost_crosstool_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो b+ c++ टूलटिप में 'host' और 'nonhost' सुविधाएं चालू नहीं होंगी. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 पर जाएं.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_android_toolchain_resolution
डिफ़ॉल्ट: "गलत"-
Android के नियमों (Starlark और नेटिव) के लिए Android SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enable_apple_toolchain_resolution
डिफ़ॉल्ट: "गलत"-
सेब के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_make_thinlto_command_lines_standalone
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल 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
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल आपकी लाइब्रेरी डिपेंडेंसी को डिफ़ॉल्ट तौर पर पूरे संग्रह के तौर पर लिंक नहीं करेगा (माइग्रेशन से जुड़े निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं).
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_require_ctx_in_configure_features
डिफ़ॉल्ट: "सही"-
अगर सही है, तो cc_normal.configure_features में ज़्यादा जानकारी के लिए बेज़ल को 'ctx' पैरामीटर की ज़रूरत होगी (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/7793 देखें).
टैग:loading_and_analysis
,incompatible_change
-
टूलचेन की सुविधा होने पर इंटरफ़ेस के साथ शेयर किए गए ऑब्जेक्ट का इस्तेमाल करें. फ़िलहाल, इस सुविधा के साथ सभी ELF टूल चेन काम करती हैं.
टैग:loading_and_analysis
,affects_outputs
,affects_outputs
--ios_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
iOS ऐप्लिकेशन बनाने के लिए, iOS SDK के वर्शन के बारे में बताता है. अगर यह तय नहीं है, तो 'xcode_version' से डिफ़ॉल्ट iOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--macos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
macOS ऐप्लिकेशन के बिल्ड का इस्तेमाल करने के लिए, macOS SDK का वर्शन बताता है. अगर कुछ भी न बताया गया हो, तो 'xcode_version' से मिले डिफ़ॉल्ट macOS SDK वर्शन का इस्तेमाल करता है.
टैग:loses_incremental_state
--minimum_os_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
आपका ओएस का वह सबसे छोटा वर्शन जिसे टारगेट किया गया है.
टैग:loading_and_analysis
,affects_outputs
--platform_mappings=<a relative path>
डिफ़ॉल्ट: ""-
मैपिंग फ़ाइल की जगह, जो बताती है कि कोई प्लैटफ़ॉर्म सेट नहीं करने पर, कौनसा प्लैटफ़ॉर्म इस्तेमाल करना चाहिए या प्लैटफ़ॉर्म के पहले से मौजूद होने पर क्या फ़्लैग किया जाना चाहिए. फ़ाइल फ़ोल्डर का मुख्य रूट होना चाहिए. डिफ़ॉल्ट रूप से 'platform_mappings' (फ़ाइल फ़ोल्डर के रूट के ठीक नीचे वाली फ़ाइल).
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--platforms=<a build target label>
डिफ़ॉल्ट: ""-
प्लैटफ़ॉर्म नियमों के लेबल से मौजूदा निर्देश के लिए टारगेट प्लैटफ़ॉर्म के बारे में पता चलता है.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--python2_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
बिना समर्थन वाले टैग, अमान्य. `--insupported_use_python_toolchains` ने बंद कर दिया.
टैग:no_op
,deprecated
--python3_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
बिना समर्थन वाले टैग, अमान्य. `--insupported_use_python_toolchains` ने बंद कर दिया.
टैग:no_op
,deprecated
--python_path=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
'Python' टारगेट का इस्तेमाल करके, Python टारगेट को टारगेट प्लैटफ़ॉर्म पर चलाया जाता है. बहिष्कृत; --insupported_use_python_toolchains ने बंद किया.
टैग:loading_and_analysis
,affects_outputs
--python_top=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
Python को टारगेट करने वाले Python टारगेट को दिखाने वाले py_runtime का लेबल, टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए शुरू किया गया. बहिष्कृत; --insupported_use_python_toolchains ने बंद किया.
टैग:loading_and_analysis
,affects_outputs
--target_platform_fallback=<a build target label>
डिफ़ॉल्ट: "@local_config_platform//:host"-
प्लैटफ़ॉर्म के नियम का लेबल, जिसे तब इस्तेमाल किया जाना चाहिए, जब कोई टारगेट प्लैटफ़ॉर्म सेट न हो और कोई भी प्लैटफ़ॉर्म मैपिंग, फ़्लैग के मौजूदा सेट से मेल न खाता हो.
टैग:affects_outputs
,changes_inputs
,loading_and_analysis
--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
इससे यह पता चलता है कि TOS ऐप्लिकेशन का इस्तेमाल करने के लिए, TOS SDK का कौनसा वर्शन इस्तेमाल किया जा रहा है. अगर कुछ भी तय नहीं किया गया है, तो 'xcode_version' से डिफ़ॉल्ट tvOS SDK वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
इस नीति से, WatchOS SDK के उस वर्शन की जानकारी मिलती है जिसका इस्तेमाल स्मार्टवॉच के ऐप्लिकेशन बनाने के लिए किया जाता है. अगर यह तय नहीं है, तो 'xcode_version' से डिफ़ॉल्ट WatchOS SDK वर्शन का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xcode_version=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
अगर बताए गए वर्शन के लिए, बिल्ड से जुड़ी कार्रवाइयों के लिए Xcode का इस्तेमाल किया जाता है. अगर जानकारी नहीं दी गई है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल करें.
टैग:loses_incremental_state
--xcode_version_config=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/cpp:host_xcodes"-
बिल्ड कॉन्फ़िगरेशन में Xcode वर्शन चुनने के लिए, xcode_config नियम का लेबल.
टैग:loses_incremental_state
,loading_and_analysis
- विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:
--[no]apple_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 list of options>
डिफ़ॉल्ट: ".pb.h"-
उन हेडर फ़ाइलों के प्रीफ़िक्स सेट करता है जिन्हें cc_proto_library बनाता है.
टैग:affects_outputs
,loading_and_analysis
--cc_proto_library_source_suffixes=<comma-separated list of options>
डिफ़ॉल्ट: ".pb.cc"-
उन स्रोत फ़ाइलों के प्रीफ़िक्स सेट करता है जिन्हें cc_proto_library बनाता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_proto_descriptor_sets_include_source_info
डिफ़ॉल्ट: "गलत"-
प्रोटो_लाइब्रेरी में अन्य Java एपीआई वर्शन के लिए, ज़्यादा कार्रवाइयां करें.
टैग:affects_outputs
,loading_and_analysis
,experimental
--[no]experimental_proto_extra_actions
डिफ़ॉल्ट: "गलत"-
प्रोटो_लाइब्रेरी में अन्य 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' का कोई भी संयोजन हो सकता है और सभी मोड को अक्षम करने के लिए 'no' हो सकता है.
टैग:loading_and_analysis
,action_command_lines
,affects_outputs
--[no]incompatible_always_include_files_in_data
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो नेटिव नियम अपनी रन फ़ाइल में डेटा डिपेंडेंसी के लिए <code>DefaultInfo.files</code> जोड़ते हैं. ऐसा करना, Starlark नियमों (https://bazel.build/extending/rule#runfiles_features_to_aallow) के लिए सुझाए गए तरीके से मेल खाता है.
टैग:affects_outputs
,incompatible_change
--[no]legacy_external_runfiles
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो .runfiles/wsname/external/repo में .runfiles/wsname/external/repo के तहत रनफ़ाइल सिमलिंक जंगल बनाएं.
टैग:affects_outputs
--[no]objc_generate_linkmap
डिफ़ॉल्ट: "गलत"-
यह बताता है कि लिंक मैप फ़ाइल जनरेट करनी है या नहीं.
टैग:affects_outputs
--output_groups=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. हर ग्रुप के आगे वैकल्पिक रूप से + या - का निशान होता है. आउटपुट ग्रुप के डिफ़ॉल्ट सेट में + अगर कम से कम एक ग्रुप प्रीफ़िक्स नहीं है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट छूट जाएगा. उदाहरण के लिए, --आउटपुट_ग्रुप=+foo,+बार, डिफ़ॉल्ट सेट, foo, और बार को जोड़ता है, जबकि -- आउटपुट_ग्रुप=foo, बार डिफ़ॉल्ट सेट को बदल देता है, ताकि सिर्फ़ foo और Bar बनाया जा सके.
टैग:execution
,affects_outputs
--[no]run_validations
डिफ़ॉल्ट: "सही"-
बिल्ड के हिस्से के तौर पर पुष्टि करने की कार्रवाइयां करनी हैं या नहीं. https://bazel.build/extending/rule#validatoration_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
डिफ़ॉल्ट: "गलत"-
इससे, ऐसे android_binary APK के लिए संसाधन को छोटा करने की सुविधा चालू होती है जो ProGuard का इस्तेमाल करते हैं.
टैग:affects_outputs
,loading_and_analysis
--apple_bitcode=<'mode' or 'platform=mode', where 'mode' is none, embedded_markers or embedded, and 'platform' is ios, watchos, tvos, macos or catalyst>
बार कई इस्तेमाल किए गए-
डिवाइस आर्किटेक्चर को टारगेट करने वाले चरणों को कंपाइल करने के लिए, Apple बिटकोड मोड तय करें. वैल्यू '[platform=]mode' में होती हैं. यहां प्लैटफ़ॉर्म (जो 'ios', 'macos', 'tvos' या 'watchos' होना चाहिए) ज़रूरी नहीं है. अगर दिया गया हो, तो बिट कोड खास तौर पर उस प्लैटफ़ॉर्म के लिए लागू किया जाता है; अगर छोड़ा जाता है, तो यह सभी प्लैटफ़ॉर्म पर लागू होता है. मोड का नाम 'कोई नहीं', 'एम्बेड किए गए मार्कर' या 'एम्बेड किया गया' होना चाहिए. यह विकल्प कई बार दिया जा सकता है.
टैग:loses_incremental_state
--aspects=<comma-separated list of options>
बार कई इस्तेमाल किए गए- टॉप-लेवल टारगेट पर लागू किए जाने वाले पहलुओं की कॉमा-सेपरेटेड लिस्ट. अगर सूची में, part_aspect ज़रूरी आसपेक्ट रेशियो (चौड़ाई-ऊंचाई का अनुपात) सेवा देने वाली कंपनियों के ज़रिए ज़रूरी_सेवा का नाम देता है, तो सूची में मौजूद आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के पहले, हर आसपेक्ट के बाद {0}_aspect चलेगा. जिसके विज्ञापन देने वाले, कुछ आसपेक्ट रेशियो (लंबाई-चौड़ाई का डेटा) उपलब्ध कराते हैं. इसके अलावा,Some_aspect तब लागू होगा, जब एट्रिब्यूट के लिए तय किए गए सभी ज़रूरी पहलुओं को एट्रिब्यूट के तौर पर तय कर लिया जाएगा. any_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
डिफ़ॉल्ट: "गलत"-
अगर तय किया गया है, तो Bazel कोड का इस्तेमाल करेगा (जहां संभव हो, ऑफ़लाइन इंस्ट्रुमेंट का इस्तेमाल करके) और टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. केवल -- खर्चों के मिलान वाले टारगेट पर असर होगा. आम तौर पर, यह विकल्प सीधे तौर पर नहीं बताया जाना चाहिए. इसके बजाय, 'बेज़ल कवरेज' निर्देश का इस्तेमाल करें.
टैग: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 की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल वाली रॉ फ़ाइल का पूरा पाथ नाम, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल की फ़ाइल.
टैग:affects_outputs
--cs_fdo_instrument=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
संदर्भ एफ़डीओ के संदर्भ वाले बाइनरी टूल जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसके तहत रॉ प्रोफ़ाइल फ़ाइल(फ़ाइलों) को रनटाइम के दौरान डंप किया जाएगा.
टैग:affects_outputs
--cs_fdo_profile=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
ऑप्टिमाइज़ेशन के लिए इस्तेमाल की जाने वाली CS_fdo_profile, संदर्भ के हिसाब से संवेदनशील प्रोफ़ाइल दिखाती है.
टैग:affects_outputs
--cxxopt=<a string>
बार कई इस्तेमाल किए गए-
C++ स्रोत फ़ाइलें कंपाइल करते समय gcc में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--define=<a 'name=value' assignment>
बार कई इस्तेमाल किए गए-
हर --define विकल्प, बिल्ड वैरिएबल के लिए एक असाइनमेंट तय करता है.
टैग:changes_inputs
,affects_outputs
--dynamic_mode=<off, default or fully>
डिफ़ॉल्ट: "डिफ़ॉल्ट"-
यह तय करता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'डिफ़ॉल्ट' का मतलब है कि Bazel डाइनैमिक तौर पर लिंक करने का विकल्प चुनेगा. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक रूप से लिंक की जाएंगी. 'बंद' का मतलब है कि सभी लाइब्रेरी ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.
टैग:loading_and_analysis
,affects_outputs
--[no]enable_fdo_profile_absolute_path
डिफ़ॉल्ट: "सही"-
अगर यह सेट है, तो fdo_absolute_profile_path का इस्तेमाल करने से गड़बड़ी पैदा होगी.
टैग:affects_outputs
--[no]enable_runfiles
डिफ़ॉल्ट: "अपने-आप"-
रनफ़ाइल सिमलिंक ट्री चालू करें. डिफ़ॉल्ट रूप से, यह Windows पर, अन्य प्लैटफ़ॉर्म पर बंद रहता है.
टैग:affects_outputs
--experimental_action_listener=<a build target label>
बार कई इस्तेमाल किए गए-
पक्षों के पक्ष में रोक लगा दी गई. बिल्ड की मौजूदा कार्रवाइयों के साथ बाहर की गई किसी कार्रवाई को अटैच करने के लिए 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
डिफ़ॉल्ट: "गलत"-
इससे, ऐसे android_binary APK के लिए संसाधन को छोटा करने की सुविधा चालू होती है जो ProGuard का इस्तेमाल करते हैं.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_android_rewrite_dexes_with_rex
डिफ़ॉल्ट: "गलत"-
डेक्स फ़ाइलों को फिर से लिखने के लिए, हेक्स टूल का इस्तेमाल करें
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
,experimental
--[no]experimental_convenience_symlinks
डिफ़ॉल्ट: "सामान्य"-
यह फ़्लैग कंट्रोल करता है कि सुविधा के सिमलिंक कैसे बनाए जाएंगे (बिल्ड के बाद, फ़ाइल फ़ोल्डर में सिमलिंक दिखेंगे). संभावित वैल्यू:
सामान्य (डिफ़ॉल्ट): बिल्ड के आधार पर, हर तरह का सुविधा सिमलिंक बनाया या मिटाया जाएगा.
साफ़: सभी सिमलिंक बिना किसी शर्त के मिटा दिए जाएंगे.
अनदेखा करें: सिमलिंक अकेले रह जाएंगे.
log_only: लॉग संदेश इस तरह जनरेट करें जैसे कि 'सामान्य' पास किया गया हो, लेकिन वास्तव में कोई फ़ाइल सिस्टम कार्रवाई नहीं करते हैं (टूल के लिए उपयोगी).
ध्यान दें कि सिर्फ़ वही सिमलिंक इस्तेमाल किए जा सकते हैं जिनके नाम --symlink_prefix:
टैग:affects_outputs
--[no]experimental_convenience_symlinks_bep_event
डिफ़ॉल्ट: "गलत"-
यह फ़्लैग कंट्रोल करता है कि हम buildEventServiceSymlinksIdentify को BuildEventProtocol में पोस्ट करेंगे या नहीं. अगर मान सही पर सेट है, तो BuildEventProtocol में][=SymlinksIdentified के लिए एक एंट्री होगी, जिसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा सिमलिंक होंगे. गलत होने पर, BuildEventProtocol में मौजूद UtilitySymlinksIdentify किया गया एंट्री खाली हो जाएगा.
टैग: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
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो स्टैक अनवाइंड करने के लिए, libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-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 कवरेज मैप की जानकारी जनरेट करेगा. ऐसा तब होगा, जब collection_code_coverage चालू की गई हो.
टैग:changes_inputs
,affects_outputs
,loading_and_analysis
,experimental
--fat_apk_cpu=<comma-separated list of options>
डिफ़ॉल्ट: "armeabi-v7a"-
इस विकल्प को सेट करने पर, फैट APK चालू हो जाते हैं.इनमें तय किए गए सभी टारगेट आर्किटेक्चर के लिए, नेटिव बाइनरी का इस्तेमाल किया जाता है. उदाहरण के लिए, --fat_apk_cpu=x86,armeabi-v7a. अगर इस फ़्लैग के बारे में बताया गया है, तो android_binu नियमों की निर्भरता के आधार पर --android_cpu को अनदेखा कर दिया जाता है.
टैग:affects_outputs
,loading_and_analysis
,loses_incremental_state
--[no]fat_apk_hwasan
डिफ़ॉल्ट: "गलत"-
WWASAN स्प्लिट बनाना है या नहीं.
टैग: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> तय करने से सुविधा पूरी दुनिया में बंद हो जाएगी. नेगेटिव सुविधाएं हमेशा पॉज़िटिव सुविधाओं को बदल देती हैं. इस फ़्लैग का इस्तेमाल बेज़ल रिलीज़ किए बिना सुविधा में हुए डिफ़ॉल्ट बदलावों को रोल आउट करने के लिए किया जाता है.
टैग: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>
बार कई इस्तेमाल किए गए-
होस्ट या एक्ज़ीक्यूशन कॉन्फ़िगरेशन में बने टूल के लिए, सी कंपाइलर को पास करने के अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--host_cpu=<a string>
डिफ़ॉल्ट: ""-
होस्ट सीपीयू.
टैग:changes_inputs
,affects_outputs
--host_cxxopt=<a string>
बार कई इस्तेमाल किए गए-
होस्ट या निष्पादन कॉन्फ़िगरेशन में बनाए गए टूल के लिए C++ कंपाइलर को पास करने के अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_force_python=<PY2 or PY3>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट कॉन्फ़िगरेशन के लिए Python वर्शन को बदलें. यह "PY2" या "PY3" हो सकता है.
टैग:loading_and_analysis
,affects_outputs
--host_linkopt=<a string>
बार कई इस्तेमाल किए गए-
होस्ट या निष्पादन कॉन्फ़िगरेशन में टूल लिंक करते समय लिंकर को पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
होस्ट टारगेट के लिए macOS का कम से कम वर्शन. अगर कोई भी अंक सेट न किया गया हो, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई इस्तेमाल किए गए-
होस्ट या एक्ज़ीक्यूशन कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, चुनिंदा रूप से C/C++ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प. यह विकल्प एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, शामिल किए गए रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर करने की सूची के लिए है (साथ ही, -platformation_filter भी देखें). विकल्प_1 को विकल्प_1 के तौर पर, आर्बिट्रेरी कमांड लाइन के विकल्पों के लिए इस्तेमाल किया जा सकता है. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में.cc/ को छोड़कर सभी cc फ़ाइलों की कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
--host_swiftcopt=<a string>
बार कई इस्तेमाल किए गए-
होस्ट टूल के लिए swiftc में पास करने के लिए अन्य विकल्प.
टैग:action_command_lines
,affects_outputs
--[no]incompatible_avoid_conflict_dlls
डिफ़ॉल्ट: "सही"-
अगर यह सेटिंग चालू है, तो Windows पर cc_library से जनरेट की गई सभी C++ डाइनैमिक लिंक की गई लाइब्रेरी (DLL) का नाम बदलकर name_{sha}.dll कर दिया जाएगा. हैश का हिसाब RepositoryName और DLL के पैकेज पाथ के आधार पर लगाया जाता है. यह विकल्प तब फ़ायदेमंद होता है, जब आपके पास एक ही पैकेज वाली कई cc_library पर निर्भर करता है (उदाहरण के लिए, //foo/bar1:utils और //foo/bar2:utils).
टैग:loading_and_analysis
,affects_outputs
,incompatible_change
--[no]incompatible_merge_genfiles_directory
डिफ़ॉल्ट: "सही"-
सही होने पर, जेनफ़ाइल डायरेक्ट्री बिन डायरेक्ट्री में फ़ोल्ड हो जाती है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_use_platforms_repo_for_constraints
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो @bazel_tools की कंस्ट्रेंट सेटिंग हटा दी जाती हैं.
टैग:affects_outputs
,incompatible_change
--[no]instrument_test_targets
डिफ़ॉल्ट: "गलत"-
अगर यह सुविधा चालू है, तो तय करें कि टेस्ट के नियमों को लागू करना है या नहीं. अगर सेट किया जाता है, तो --उदाहरण के तौर पर, इंस्ट्रूमेंटेशन_फ़िल्टर से जुड़े टेस्ट के नियमों को लागू किया जाता है. नहीं तो, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.
टैग:affects_outputs
--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-/javatest[/],-/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 नियमों के लिए पूरा-संग्रह का उपयोग करें, जिनमें linkshare=True और linkstatic=True या '-static' है. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. ज़रूरत पड़ने पर, हमेशा link=1 का इस्तेमाल करना एक बेहतर विकल्प है.
टैग:action_command_lines
,affects_outputs
,deprecated
--linkopt=<a string>
बार कई इस्तेमाल किए गए-
लिंक करने के दौरान gcc में पास करने का अतिरिक्त विकल्प.
टैग:action_command_lines
,affects_outputs
--ltobackendopt=<a string>
बार कई इस्तेमाल किए गए-
एलटीओ बैकएंड चरण में जाने के लिए अन्य विकल्प (-features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
--ltoindexopt=<a string>
बार कई इस्तेमाल किए गए-
एलटीओ इंडेक्सिंग चरण में पास होने के लिए अन्य विकल्प (-features=thin_lto के तहत).
टैग:action_command_lines
,affects_outputs
--macos_cpus=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
उन आर्किटेक्चर की कॉमा-सेपरेटेड लिस्ट जिनके लिए Apple macOS बाइनरी बनाएं.
टैग:loses_incremental_state
,loading_and_analysis
--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट के लिए, कम से कम इस तरह का macOS वर्शन होना चाहिए. अगर कोई भी अंक सेट न किया गया हो, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--[no]objc_debug_with_GLIBCXX
डिफ़ॉल्ट: "गलत"-
अगर सेट किया गया है और कंपाइलेशन मोड 'dbg' पर सेट है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC और GLIBCPP_CONCEPT_CheckS को तय करें.
टैग:action_command_lines
--[no]objc_enable_binary_stripping
डिफ़ॉल्ट: "गलत"-
लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग करनी है या नहीं. अगर यह फ़्लैग और --compilation_mode=opt दोनों मौजूद हों, तो बाइनरी स्ट्रिपिंग का इस्तेमाल किया जाएगा.
टैग:action_command_lines
--objccopt=<a string>
बार कई इस्तेमाल किए गए-
Objective-C/C++ स्रोत फ़ाइलें कंपाइल करते समय gcc में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई इस्तेमाल किए गए-
कुछ फ़ाइलों को कंपाइल करते समय, gcc को पास करने के कुछ और विकल्प. यह विकल्प एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, शामिल किए गए रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और बाहर करने की सूची के लिए है (साथ ही, -platformation_filter भी देखें). विकल्प_1 को विकल्प_1 के तौर पर, आर्बिट्रेरी कमांड लाइन के विकल्पों के लिए इस्तेमाल किया जा सकता है. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*\.cc,-//foo/bar\.cc@-O0, //foo/ में cc की छोड़ दी गई सभी cc फ़ाइलों की कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.
टैग:action_command_lines
,affects_outputs
--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options>
बार कई इस्तेमाल किए गए- कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, एलटीओ बैकएंड (-feature=thin_lto के तहत) को चुनिंदा तरीके से पास करने के अन्य विकल्प. यह विकल्प एक से ज़्यादा बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. जहां regex_filter, रेगुलर एक्सप्रेशन पैटर्न को शामिल करने और शामिल न करने की सूची के लिए है, विकल्प_1 से विकल्प_n का मतलब है आर्बिट्रेरी कमांड लाइन विकल्प. अगर किसी विकल्प में कॉमा मौजूद है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ हो सकता है. स्ट्रिंग को बांटने के लिए सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*\o.,-//foo/bar\.o@-O0, o.O.
--platform_suffix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
यह कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में बताता है.
टैग:loses_incremental_state
,affects_outputs
,loading_and_analysis
--propeller_optimize=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propler प्रोफ़ाइल की जानकारी का इस्तेमाल करें.प्रोपेलर प्रोफ़ाइल में, कम से कम एक फ़ाइल, एक cc प्रोफ़ाइल और एक ld प्रोफ़ाइल होनी चाहिए. यह फ़्लैग बिल्ड लेबल को स्वीकार करता है. यह प्रोपेलर प्रोफ़ाइल की इनपुट फ़ाइलों से जुड़ा होना चाहिए. उदाहरण के लिए, B/LD फ़ाइल जो a/b/BUILD:prolender_optimize( name = "pro), इस विकल्प का इस्तेमाल इस तरीके से किया जाना चाहिए: --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 का इस्तेमाल करके". 'कभी-कभी' के डिफ़ॉल्ट मान का मतलब Strip iff --compilation_mode=fastbuild में होता है.
टैग:affects_outputs
--stripopt=<a string>
बार कई इस्तेमाल किए गए-
'<name>.striped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के दूसरे विकल्प.
टैग:action_command_lines
,affects_outputs
--swiftcopt=<a string>
बार कई इस्तेमाल किए गए-
Swift कंपाइलेशन में पास करने के लिए अतिरिक्त विकल्प.
टैग:action_command_lines
--symlink_prefix=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
ऐसा प्रीफ़िक्स जो बिल्ड के बाद बनाए जाने वाले किसी भी सुविधा सिमलिंक से पहले जोड़ा जाता है. अगर इसे नहीं छोड़ा जाता, तो डिफ़ॉल्ट वैल्यू, बिल्ड टूल के नाम के बाद हाइफ़न होती है. अगर '/' पास किया जाता है, तो कोई सिमलिंक नहीं बनाए जाते और कोई चेतावनी नहीं दी जाती. चेतावनी: '/' के लिए खास फ़ंक्शन को जल्द ही हटा दिया जाएगा; इसके बजाय --experimental_convenience_symlinks=ignore का इस्तेमाल करें.
टैग:affects_outputs
--tvos_cpus=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
उन आर्किटेक्चर की सूची जिन्हें कॉमा से अलग किया गया है. ये आर्किटेक्चर Apple tvOS बाइनरी बनाते हैं.
टैग:loses_incremental_state
,loading_and_analysis
--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए कम से कम tvOS वर्शन जो काम करता हो. अगर कोई वैल्यू न बताई गई हो, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--watchos_cpus=<comma-separated list of options>
बार कई इस्तेमाल किए गए-
उन आर्किटेक्चर की सूची जिन्हें कॉमा से अलग किया गया है. ये आर्किटेक्चर Apple WatchOS बाइनरी बनाते हैं.
टैग:loses_incremental_state
,loading_and_analysis
--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
टारगेट सिम्युलेटर और डिवाइसों के लिए, कम से कम सुविधाओं वाला WatchOS वर्शन. अगर कोई भी अंक न बताया गया हो, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.
टैग:loses_incremental_state
--xbinary_fdo=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें-
कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम डालें. जब विकल्प के साथ इस विकल्प का इस्तेमाल किया जाता है --fdo_documentation/--fdo_optimize/--fdo_profile, तो ऐसे विकल्प हमेशा बने रहेंगे जैसे कि xbinary_fdo कभी तय नहीं किया गया है.
टैग:affects_outputs
- वे विकल्प जो यह तय करते हैं कि Bazel, बिल्ड के मान्य इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--auto_cpu_environment_group=<a build target label>
डिफ़ॉल्ट: ""-
cp_value वैल्यू को अपने-आप मैप करने के लिए,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
डिफ़ॉल्ट: "गलत"-
जिन डिवाइसों में Deps के साथ, बिना srcs वाले 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_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 एपीआई में हेडर की सख्त जांच करें:
टैग:loading_and_analysis
,changes_inputs
,incompatible_change
--[no]incompatible_validate_top_level_header_inclusions
डिफ़ॉल्ट: "सही"-
अगर सही है, तो बेज़ल टॉप लेवल डायरेक्ट्री हेडर को शामिल करने की पुष्टि भी करेगा (ज़्यादा जानकारी के लिए https://github.com/bazelbuild/bazel/issues/10047 पर जाएं).
टैग:loading_and_analysis
,incompatible_change
--[no]strict_filesets
डिफ़ॉल्ट: "गलत"-
अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाली फ़ाइलें, गड़बड़ियों के तौर पर रिपोर्ट की जाती हैं. यह test_fileset_dependencies_recursively को बंद करने पर काम नहीं करता.
टैग: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>
डिफ़ॉल्ट: "बंद"-
जब तक यह बंद नहीं हो जाता, तब तक यह जांच नहीं की जाती कि एक Proto_library टारगेट, 'सार्वजनिक तौर पर इंपोर्ट करें' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट किए गए के रूप में बताता है या नहीं.
टैग:build_file_semantics
,eagerness_to_exit
,incompatible_change
--[no]strict_system_includes
डिफ़ॉल्ट: "गलत"-
सही होने पर, सिस्टम के ज़रिए पाए गए हेडर में पाथ (-isystem) शामिल किए जाने की भी ज़रूरत होती है.
टैग:loading_and_analysis
,eagerness_to_exit
--target_environment=<a build target label>
बार कई इस्तेमाल किए गए-
इस बिल्ड के टारगेट एनवायरमेंट के बारे में एलान करता है. लेबल को "परिवेश" नियम का रेफ़रंस होना चाहिए. अगर बताया गया हो, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने वाले होने चाहिए.
टैग:changes_inputs
- ऐसे विकल्प जो किसी बिल्ड के साइनिंग आउटपुट पर असर डालते हैं:
--apk_signing_method=<v1, v2, v1_v2 or v4>
डिफ़ॉल्ट: "v1_v2"-
APK साइन करने के लिए इस्तेमाल किया जाना
टैग:action_command_lines
,affects_outputs
,loading_and_analysis
--[no]device_debug_entitlements
डिफ़ॉल्ट: "सही"-
अगर सेट किया गया है और कंपाइलेशन मोड 'ऑप्ट' नहीं किया गया है, तो 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
डिफ़ॉल्ट: "गलत"-
अगर काम नहीं करता, तो यह noop. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने वाली विशेषता के बिना कोई config_setting //visible:public है. अगर इस फ़्लैग को 'सही' पर सेट किया जाता है, तो config_setting उसी लॉजिक का पालन करता है जो अन्य सभी नियमों को फ़ॉलो करता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_disallow_legacy_py_provider
डिफ़ॉल्ट: "सही"-
नहीं, नहीं, जल्द ही हटा दिया जाएगा.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो config_setting विज़िबिलिटी से जुड़ी पाबंदियां लागू करें. अगर गलत हो, तो हर config_setting हर टारगेट को दिखाई देता है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:
--[no]allow_analysis_failures
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो किसी नियम के टारगेट में विश्लेषण में हुई गड़बड़ी की वजह से, TargetFailureInfo का इंस्टेंस बनता है जिसमें गड़बड़ी का ब्यौरा शामिल होता है. इससे, बिल्ड में गड़बड़ी होती है.
टैग: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 बार की जाएंगी. अगर 'डिफ़ॉल्ट' है, तो नियमित जांचों के लिए सिर्फ़ एक टेस्ट किया जाएगा और तीन टेस्ट के लिए, साफ़ तौर पर 'फ़्लैकी' के तौर पर मार्क किए गए टेस्ट के लिए किया जाएगा. वैकल्पिक सिंटैक्स: regex_filter@flaky_test_attempts. जहां flaky_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 devicetypes' चलाकर डिवाइस की सूची मिल सकती है.
टैग:test_runner
--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
रन करने या टेस्ट करने के दौरान, सिम्युलेटर पर चलने वाला iOS वर्शन. अगर इस नियम में टारगेट डिवाइस की जानकारी दी गई है, तो ios_test नियमों को नज़रअंदाज़ कर दिया जाएगा.
टैग:test_runner
--local_test_jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5">
डिफ़ॉल्ट: "अपने-आप"-
एक साथ काम करने वाले लोकल टेस्ट जॉब की ज़्यादा से ज़्यादा संख्या. कोई पूर्णांक या कीवर्ड ("अपने-आप", "Host_CPUS," PAS_RAM") का इस्तेमाल करता है. इसके बाद, ऑपरेशन ([-|*]<float>) का इस्तेमाल किया जाता है. जैसे, "अपने-आप", "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 सभी परीक्षण 3 बार चलाएगा. वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. जहां Run_per_test पूर्णांक मान है और regex_filter, शामिल करें और रेगुलर एक्सप्रेशन पैटर्न को शामिल न करें की सूची के लिए है (यह भी देखें -- इंस्ट्रुमेंट_फ़िल्टर). उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3 //foo/ में सभी बार जांच करता है, सिवाय foo/bar के तहत आने वाले तीन बार. यह विकल्प एक से ज़्यादा बार पास किया जा सकता है. मेल खाने वाले सबसे हाल के तर्क को प्राथमिकता दी जाती है. अगर कुछ भी मैच नहीं करता है, तो टेस्ट सिर्फ़ एक बार किया जाता है.
--test_env=<a 'name=value' assignment with an optional value part>
बार कई इस्तेमाल किए गए-
टेस्ट रनर एनवायरमेंट में इंजेक्ट करने के लिए, और एनवायरमेंट वैरिएबल तय करता है. वैरिएबल, नाम के हिसाब से तय किए जा सकते हैं. ऐसा होने पर, उसकी वैल्यू बेज़ल क्लाइंट के एनवायरमेंट या नाम=वैल्यू पेयर से पढ़ी जाएगी. इस विकल्प का इस्तेमाल, कई वैरिएबल बताने के लिए कई बार किया जा सकता है. इसका इस्तेमाल सिर्फ़ 'बेज़ल टेस्ट' निर्देश के ज़रिए किया जाता है.
टैग:test_runner
--[no]test_keep_going
डिफ़ॉल्ट: "सही"-
अगर यह जांच नहीं की जाती है, तो पास न होने पर, पूरा बिल्ड बंद हो जाएगा. डिफ़ॉल्ट रूप से, सभी टेस्ट किए जाते हैं. भले ही, कुछ टेस्ट पास न हुए हों.
टैग:execution
--test_strategy=<a string>
डिफ़ॉल्ट: ""-
यह बताता है कि जांच करते समय किस रणनीति का इस्तेमाल करना चाहिए.
टैग:execution
--test_timeout=<a single integer or comma-separated list of 4 integers>
डिफ़ॉल्ट: "-1"- जांच के टाइम आउट के लिए, जांच के टाइम आउट की डिफ़ॉल्ट वैल्यू को बदलें (सेकंड में). अगर सिर्फ़ एक पूर्णांक संख्या दी जाती है, तो वह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए गए हैं, तो वे छोटे, मध्यम, लंबे, और हमेशा के लिए, टाइम आउट को बदल देंगे (इसी क्रम में). दोनों में से किसी भी रूप में, -1 का मान तय करता है कि ब्लेज़ उस श्रेणी के लिए डिफ़ॉल्ट टाइम आउट का इस्तेमाल करेगा.
--test_tmpdir=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- यह 'bazel test' के लिए बुनियादी अस्थायी डायरेक्ट्री के बारे में बताता है.
--tvos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में tvOS ऐप्लिकेशन चलाते समय सिम्युलेट करने वाला डिवाइस. उदाहरण के लिए, 'Apple TV 1080p'. जिस डिवाइस पर सिम्युलेटर चलेगा उस पर 'xcrun simctl list devicetypes' चलाकर डिवाइस की सूची मिल सकती है.
टैग:test_runner
--tvos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
रन करने या टेस्ट करने के दौरान, सिम्युलेटर पर tvOS का वर्शन.
टैग:test_runner
--watchos_simulator_device=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
सिम्युलेटर में स्मार्टवॉच का ऐप्लिकेशन चलाने पर, सिम्युलेट करने वाला डिवाइस. उदाहरण के लिए, 'Apple Watch - 38 मि॰मी॰'. जिस डिवाइस पर सिम्युलेटर चलेगा उस पर 'xcrun simctl list devicetypes' चलाकर डिवाइस की सूची मिल सकती है.
टैग:test_runner
--watchos_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')>
डिफ़ॉल्ट: ब्यौरा देखें-
रन करने या टेस्ट करने के दौरान, सिम्युलेटर पर चलाया जाने वाला WatchOS का वर्शन.
टैग:test_runner
--[no]zip_undeclared_test_outputs
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो जिन जांच के एलान का एलान नहीं किया गया है उन्हें zip फ़ाइल में स्टोर किया जाएगा.
टैग:test_runner
- ऐसे विकल्प जो बिल्ड टाइम के ऑप्टिमाइज़ेशन को ट्रिगर करते हैं:
--[no]collapse_duplicate_defines
डिफ़ॉल्ट: "सही"-
चालू होने पर, ग़ैर-ज़रूरी --विज्ञापन की जानकारी, बिल्ड की शुरुआत में ही हट जाएगी. इससे कुछ खास तरह के बिल्ड के लिए, विश्लेषण कैश मेमोरी में होने वाले गैर-ज़रूरी नुकसान से बचा जा सकता है.
टैग:loading_and_analysis
,loses_incremental_state
--[no]experimental_filter_library_jar_with_program_jar
डिफ़ॉल्ट: "गलत"-
LibraryJar में मौजूद किसी भी क्लास को हटाने के लिए, ProGuard ProgramJar को फ़िल्टर करें.
टैग:action_command_lines
--[no]experimental_inmemory_dotd_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, C++ .d फ़ाइलों को मेमोरी में भेज दिया जाएगा. उन्हें डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से भेजा जाएगा.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_inmemory_jdeps_files
डिफ़ॉल्ट: "सही"-
चालू होने पर, Java कंपाइलेशन से जनरेट की गई डिपेंडेंसी (.jdeps) फ़ाइलें, मेमोरी में डिस्क पर लिखने के बजाय, सीधे रिमोट बिल्ड नोड से पास होंगी.
टैग:loading_and_analysis
,execution
,affects_outputs
,experimental
--[no]experimental_objc_include_scanning
डिफ़ॉल्ट: "गलत"-
क्या आपको C/C++ के मकसद को स्कैन करना है?
टैग:loading_and_analysis
,execution
,changes_inputs
--[no]experimental_parse_headers_skipped_if_corresponding_srcs_found
डिफ़ॉल्ट: "गलत"-
चालू होने पर, अगर एक ही टारगेट नाम वाला सोर्स एक ही टारगेट में मिलता है, तो parse_headers फ़ीचर, अलग से कंपाइल करने वाली अलग से कार्रवाई नहीं बनाता है.
टैग:loading_and_analysis
,affects_outputs
--[no]experimental_retain_test_configuration_across_testonly
डिफ़ॉल्ट: "गलत"-
चालू होने पर, --trim_test_Configuration, 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
डिफ़ॉल्ट: "गलत"-
इनपुट फ़ाइलों से #इनक्लूड लाइनों को पार्स करके, C/C++ कंपाइलेशन में इनपुट कम करें. यह कंपोज़िशन इनपुट ट्री के साइज़ को कम करके, परफ़ॉर्मेंस और इंक्रीमेंटल को बेहतर बना सकता है. हालांकि, यह बिल्ड को तोड़ भी सकता है क्योंकि शामिल करें स्कैनर C प्रीप्रोसेसर सिमेंटिक को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डायनैमिक #इन्क्लूड डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर कंडीशनल लॉजिक को अनदेखा करता है. अपने जोखिम पर इस्तेमाल करें. शिकायत किए गए फ़्लैग से जुड़ी कोई भी समस्या बंद हो जाएगी.
टैग: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
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो आउटपुट फ़ाइलों को दिखाते समय, BEP में Fileset को बड़ा करें.
टैग:affects_outputs
--[no]experimental_build_event_fully_resolve_fileset_symlinks
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो आउटपुट फ़ाइलों को दिखाते समय, BEP में रिलेटिव फ़ाइलसेट सिमलिंक को ठीक करें. --experimental_build_event_expand_filesets ज़रूरी है.
टैग:affects_outputs
--experimental_build_event_upload_max_retries=<an integer>
डिफ़ॉल्ट: "4"-
बिल्डिंग का बिल्ड इवेंट अपलोड करने के बाद, Bazel को ज़्यादा से ज़्यादा इतनी बार फिर से कोशिश करनी चाहिए.
टैग:bazel_internal_configuration
--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.>
: "1s"-
बीईपी अपलोड न होने पर, एक्स्पोनेंशियल बैकऑफ़ फिर से कोशिश करने की अवधि कम से कम. (घातांक: 1.6)
टैग:bazel_internal_configuration
--experimental_build_event_upload_strategy=<a string>
डिफ़ॉल्ट: ब्यौरा देखें-
इसमें यह चुना जाता है कि बिल्ड इवेंट के प्रोटोकॉल में, आर्टफ़ैक्ट को कैसे अपलोड किया जाए.
टैग:affects_outputs
--[no]experimental_materialize_param_files_directly
डिफ़ॉल्ट: "गलत"-
अगर पैरामीटर फ़ाइलों को मटीरियल किया जा रहा है, तो सीधे डिस्क पर लिखें.
टैग:execution
--[no]experimental_stream_log_file_uploads
डिफ़ॉल्ट: "गलत"-
लॉग फ़ाइल को डिस्क पर लिखने के बजाय, सीधे रिमोट स्टोरेज पर अपलोड करें.
टैग:affects_outputs
--explain=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
इससे, बिल्ड सिस्टम, बिल्ड के हर चरण की जानकारी देता है. जानकारी, बताई गई लॉग फ़ाइल में लिखी जाती है.
टैग:affects_outputs
--[no]legacy_important_outputs
डिफ़ॉल्ट: "सही"-
इसे इस्तेमाल करके, Targetcomplete इवेंट में लेगसी Key_outputs फ़ील्ड जनरेट होने से रोकने के लिए. Bazel से ResultStore के इंटिग्रेशन के लिए, राजनैतिक आउटपुट डालना ज़रूरी है.
टैग: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_output, 'गड़बड़ी' या 'सभी' हो. यह शोर वाले टेस्ट आउटपुट के बहुत ज़्यादा शोर से बचने के लिए उपयोगी है. लॉग हेडर में टेस्ट हेडर शामिल होता है. नकारात्मक मानों की कोई सीमा नहीं होती. आउटपुट पूरा या कुछ नहीं है.
टैग:test_runner
,terminal_output
,execution
--output_filter=<a valid Java regular expression>
डिफ़ॉल्ट: ब्यौरा देखें-
सिर्फ़ उन नियमों के लिए चेतावनियां दिखाता है जिनके नाम से, दिए गए रेगुलर एक्सप्रेशन का नाम मैच होता है.
टैग:affects_outputs
--progress_report_interval=<an integer in 0-3600 range>
डिफ़ॉल्ट: "0"-
अभी भी चल रही नौकरियों की रिपोर्ट के बीच लगने वाले सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड प्रिंट की जाएगी. इसके बाद, हर मिनट एक बार रिपोर्ट को रिपोर्ट किया जाएगा. --कर्सर की सुविधा चालू होने पर, हर सेकंड की प्रोग्रेस रिपोर्ट की जाती है.
टैग:affects_outputs
--show_result=<an integer>
डिफ़ॉल्ट: "1"-
बिल्ड के नतीजे दिखाएं. हर टारगेट के लिए, बताएं कि उसे अप-टू-डेट रखा गया था या नहीं. अगर हां, तो बनाई गई आउटपुट फ़ाइलों की सूची. प्रिंट की गई फ़ाइलें शेल की कॉपी+पेस्ट के लिए सुविधाजनक स्ट्रिंग होती हैं.
इस विकल्प के लिए एक पूर्णांक तर्क की ज़रूरत होती है, जो उन नतीजों की सीमा है जिनके ऊपर नतीजे की जानकारी प्रिंट नहीं की जाती. इसलिए, शून्य की वजह से मैसेज छिप जाता है. साथ ही, MAX_INT की वजह से नतीजे को हमेशा प्रिंट किया जाता है. डिफ़ॉल्ट सेटिंग एक होती है.
टैग:affects_outputs
--[no]subcommands
[-s
] डिफ़ॉल्ट: "गलत"-
बिल्ड के दौरान एक्ज़ीक्यूट किए गए कमांडडाउन दिखाएं. मिलते-जुलते फ़्लैग: --execution_log_json_file, --execution_log_binary_file (टूल के फ़ॉर्मैट के हिसाब से, फ़ाइल में सबकॉमैंड को लॉग करने के लिए).
टैग:terminal_output
--test_output=<summary, errors, all or streamed>
डिफ़ॉल्ट: "खास जानकारी"-
इस मॉडल से, आउटपुट मोड की जानकारी मिलती है. मान्य वैल्यू, सिर्फ़ जांच की स्थिति की खास जानकारी के लिए 'खास जानकारी', फ़ेल हो चुकी जांचों के टेस्ट लॉग को प्रिंट करने के लिए 'गड़बड़ी', सभी टेस्ट के लिए लॉग प्रिंट करने के लिए 'सभी', रीयल टाइम में सभी टेस्ट के आउटपुट लॉग में 'स्ट्रीम' की जाती हैं. इससे --test_stratege वैल्यू के बिना, सभी जांचों को एक-एक करके लागू किया जा सकता है.
टैग:test_runner
,terminal_output
,execution
--test_summary=<short, terse, detailed, none or testcase>
डिफ़ॉल्ट: "छोटा"-
यह जांच करने से जुड़ी खास जानकारी के फ़ॉर्मैट के बारे में बताता है. मान्य वैल्यू, सिर्फ़ उन जांचों से जुड़ी जानकारी को प्रिंट करने के लिए 'छोटी' होती हैं जिन्हें रन किया गया था, 'ters', सिर्फ़ उन जांचों के बारे में जानकारी प्रिंट करने के लिए जिन्हें चलाया गया था. 'पूरी जानकारी', फ़ेल हो चुकी जांच के बारे में ज़्यादा जानकारी को प्रिंट करने के लिए, 'testcase' को टेस्ट केस के रिज़ॉल्यूशन में प्रिंट करने के लिए, 'जांच न हो पाए' के बारे में पूरी जानकारी प्रिंट करने के लिए और खास जानकारी को शामिल न करने के लिए 'कोई भी नहीं'.
टैग:terminal_output
--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths>
डिफ़ॉल्ट: "-.*"-
टूलचेन समाधान के दौरान डीबग जानकारी प्रिंट करें. फ़्लैग एक रेगुलर एक्सप्रेशन लेता है. इसकी जांच, टूलचेन टाइप और खास टारगेट के लिए की जाती है, ताकि देखा जा सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा से अलग किया जा सकता है. साथ ही, हर रेगुलर एक्सप्रेशन की अलग से जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल है और यह संभावित रूप से टूलचेन रिज़ॉल्यूशन के विशेषज्ञों के लिए उपयोगी होगा.
टैग:terminal_output
--[no]verbose_explanations
डिफ़ॉल्ट: "गलत"-
--एक्सप्लेनेशन की सुविधा चालू होने पर, एक्सप्लेनेशंस की सुविधा ज़्यादा शब्दों में जानकारी देती है. इसका कोई असर नहीं पड़ता, अगर --पूरी जानकारी वाली सेटिंग चालू नहीं है.
टैग:affects_outputs
--[no]verbose_failures
डिफ़ॉल्ट: "गलत"-
अगर कोई निर्देश पूरा नहीं हो पाता है, तो पूरी कमांड लाइन प्रिंट करें.
टैग:terminal_output
- सामान्य इनपुट के बारे में बताने या इसमें बदलाव करने वाले विकल्प, जो बेज़ेल कमांड से जुड़े होते हैं और किसी और कैटगरी में नहीं आते.:
--aspects_parameters=<a 'name=value' assignment>
बार कई इस्तेमाल किए गए-
कमांड-लाइन आसपेक्ट पैरामीटर की वैल्यू के बारे में बताता है. हर पैरामीटर की वैल्यू <param_name>=<param_value> से तय की जाती है. उदाहरण के लिए, 'my_param=my_val', जहां 'my_param' पैरामीटर - aspect सूची में कुछ पहलू का पैरामीटर है या सूची के किसी पहलू के लिए ज़रूरी है. इस विकल्प को कई बार इस्तेमाल किया जा सकता है. हालांकि, किसी एक पैरामीटर को एक से ज़्यादा बार वैल्यू असाइन नहीं की जा सकती.
टैग:loading_and_analysis
--flag_alias=<a 'name=value' flag alias>
बार कई इस्तेमाल किए गए-
किसी Starlark फ़्लैग के लिए शॉर्टहैंड नाम सेट करता है. यह "<key>=<value>" के रूप में एक सिंगल की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.
टैग:changes_inputs
--[no]incompatible_default_to_explicit_init_py
डिफ़ॉल्ट: "गलत"-
यह फ़्लैग डिफ़ॉल्ट व्यवहार को बदल देता है, ताकि _init__.py फ़ाइलें Python टारगेट की रन फ़ाइल में अपने-आप न बन जाएं. सटीक रूप से, जब py_binary या py_test टारगेट लेगसी_create_init को "अपने-आप" (डिफ़ॉल्ट) पर सेट करते हैं, तो इसे गलत माना जाता है. ऐसा तब होता है, जब यह फ़्लैग सेट हो. https://github.com/bazelbuild/bazel/issues/10076 देखें.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py2_outputs_are_suffixed
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो Python 2 के कॉन्फ़िगरेशन में बनाए गए टारगेट, आउटपुट रूट में दिखेंगे जिसमें सफ़िक्स '-py2' शामिल होता है. हालांकि, Python 3 के लिए बनाए गए टारगेट, ऐसे रूट में दिखेंगे जिसमें Python से जुड़ा कोई सफ़िक्स नहीं शामिल होता. इसका मतलब है कि `bazel-bin` सुविधा सिमलिंक Python 2 के बजाय Python 3 के टारगेट पर ले जाएगा. अगर आप इस विकल्प को चालू करते हैं, तो `--insupported_py3_is_default` को चालू करने का सुझाव भी दिया जाता है.
टैग:affects_outputs
,incompatible_change
--[no]incompatible_py3_is_default
डिफ़ॉल्ट: "सही"-
अगर सही है, तो `py_binary` और `py_test` टारगेट जो अपनी `python_version` (या `default_python_version`) एट्रिब्यूट को सेट नहीं करते हैं, वे PY2 के बजाय डिफ़ॉल्ट रूप से PY3 पर सेट हो जाएंगे. अगर आप इस फ़्लैग को सेट करते हैं, तो `--insupported_py2_outputs_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
--target_pattern_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह सेट है, तो बिल्ड यहां कमांड लाइन के बजाय, नाम वाली फ़ाइल के पैटर्न को पढ़ेगा. यहां किसी फ़ाइल के साथ-साथ कमांड-लाइन पैटर्न बताने में गड़बड़ी हुई.
टैग:changes_inputs
- अलग-अलग कैटगरी में नहीं, बल्कि कैटगरी के विकल्प.:
--[no]build_manual_tests
डिफ़ॉल्ट: "गलत"- टेस्ट टारगेट को 'मैन्युअल' टैग किए जाने के लिए बनाया गया है. 'मैन्युअल' टेस्ट को प्रोसेस नहीं किया जा सकता. इस विकल्प की वजह से, इन्हें बनाया जा सकता है, लेकिन इन्हें लागू नहीं किया जा सकता.
--build_tag_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- इसमें कॉमा से अलग किए गए टैग की सूची होती है. बाहर रखे गए टैग की जानकारी देने के लिए हर टैग के आगे वैकल्पिक रूप से '-' हो सकता है. केवल वे लक्ष्य बनाए जाएंगे, जिनमें कम से कम एक शामिल किया गया टैग शामिल हो और जिनमें कोई भी निकाला गया टैग शामिल न हो. यह विकल्प 'test' निर्देश के साथ किए जाने वाले टेस्ट के सेट पर असर नहीं डालता. ये फ़िल्टर, जांच के फ़िल्टर करने के विकल्पों से कंट्रोल होते हैं, जैसे कि '--test_tag_filters'
--[no]build_tests_only
डिफ़ॉल्ट: "गलत"- तय किए जाने पर, सिर्फ़ *_test और test_suite के नियम बनाए जाएंगे और कमांड लाइन पर तय किए गए अन्य टारगेट को अनदेखा किया जाएगा. डिफ़ॉल्ट रूप से, अनुरोधित सभी चीज़ें बनाई जाएंगी.
--[no]cache_test_results
[-t
] डिफ़ॉल्ट: "अपने-आप"- अगर 'ऑटो' पर सेट है, तो Bazel फिर से जांच करता है. ऐसा तब होता है, जब: (1) Bazel को टेस्ट या उसकी डिपेंडेंसी में बदलाव का पता चलता है. (2) टेस्ट को बाहरी के तौर पर मार्क किया जाता है, (3) --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया जाता है या(4) जांच पहले ही पूरी नहीं हो सकी. अगर 'हां' पर सेट किया जाता है, तो Bazel, बाहरी जांच के नतीजों को छोड़कर बाकी सभी जांच के नतीजों को कैश मेमोरी में सेव करता है. अगर 'नहीं' पर सेट किया जाता है, तो Bazel किसी भी जांच के नतीजे को कैश मेमोरी में सेव नहीं करता.
--[no]compile_one_dependency
डिफ़ॉल्ट: "गलत"- आर्ग्युमेंट फ़ाइलों को एक डिपेंडेंसी के लिए इस्तेमाल करें. यह आईडीई में, स्रोत फ़ाइलों पर आधारित सिंटैक्स फ़ाइलों की जांच के लिए फ़ायदेमंद है. उदाहरण के लिए, सोर्स फ़ाइल पर निर्भर एक टारगेट को फिर से बनाकर, बदलाव/बिल्ड/टेस्ट साइकल में गड़बड़ियों का जल्द से जल्द पता लगाया जा सकता है. यह आर्ग्युमेंट, सभी बिना फ़्लैग वाले आर्ग्युमेंट के जिस तरीके को दिखाता है उस पर असर डालता है. हालांकि, इस तरह के आर्ग्युमेंट को सोर्स फ़ाइल के नाम के तौर पर नहीं बनाया जाता. हर सोर्स फ़ाइल नाम के लिए एक आर्बिट्रेरी टारगेट बनाया जाएगा, जो इस पर निर्भर होगा.
--deleted_packages=<comma-separated list of package names>
बार कई इस्तेमाल किए गए- कॉमा लगाकर अलग किए गए उन पैकेज की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं है, भले ही वे पैकेज पाथ पर कहीं भी दिखते हों. मौजूदा पैकेज 'x' का सब-पैकेज 'x/y' मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर यह अब भी किसी दूसरी package_path एंट्री से मिलता है, तो बिल्ड सिस्टम शिकायत कर सकता है कि इसे '//x:y/z' लेबल मिलता है या नहीं. --delete_packages x/y तय करना इस समस्या से बचाता है.
--[no]discard_analysis_cache
डिफ़ॉल्ट: "गलत"- विश्लेषण का चरण पूरा होने के तुरंत बाद, विश्लेषण को खारिज करें. मेमोरी उपयोग को ~10% तक कम करता है, लेकिन आगे बढ़ने के धीमा बनाता है.
--execution_log_binary_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में इस्तेमाल किए गए स्पॉन को सीमांकित स्पॉन प्रोटोस के तौर पर लॉग करें. लॉग को सबसे पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, उसे शुरू करने के आखिर में, एक स्थिर क्रम में लगाया जाता है. इसमें सीपीयू और मेमोरी का इस्तेमाल किया जा सकता है. मिलते-जुलते फ़्लैग: --execution_log_json_file (ऑर्डर किया गया टेक्स्ट json फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम वाला बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमंड दिखाने के लिए).
--execution_log_json_file=<a path>
डिफ़ॉल्ट: ब्यौरा देखें- src/main/protobuf/spawn.proto के मुताबिक, इस फ़ाइल में इस्तेमाल किए गए स्पॉन्स को लॉग इन करें. इनमें, इस्तेमाल किए गए स्पॉन प्रोटोस को JSON के तौर पर दिखाएं. लॉग को सबसे पहले बिना किसी क्रम के लिखा जाता है. इसके बाद, उसे शुरू करने के आखिर में, एक स्थिर क्रम में लगाया जाता है. इसमें सीपीयू और मेमोरी का इस्तेमाल किया जा सकता है. मिलते-जुलते फ़्लैग: मिलते-जुलते फ़्लैग: --execution_log_binary_file (ऑर्डर किया गया बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --experimental_execution_log_file (बिना क्रम वाला बाइनरी प्रोटोबफ़ फ़ॉर्मैट), --subcommands (टर्मिनल आउटपुट में सबकमंड दिखाने के लिए).
--[no]expand_test_suites
डिफ़ॉल्ट: "सही"-
विश्लेषण करने से पहले, test_suite टारगेट को अपने मूल टेस्ट में शामिल करें. जब यह फ़्लैग चालू (डिफ़ॉल्ट) हो, तो टेस्ट सुइट से जुड़े टेस्ट पर नेगेटिव टारगेट पैटर्न लागू होगा, नहीं तो ऐसा होगा. इस फ़्लैग को बंद करना तब फ़ायदेमंद होता है, जब कमांड-लेवल के टॉप-लेवल आसपेक्ट लागू किए जाते हैं. इसके बाद, वे test_suite टारगेट का विश्लेषण कर सकते हैं.
टैग:loading_and_analysis
--[no]experimental_cancel_concurrent_tests
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो ब्लेज़ पहली बार में सही तरीके से चलाए जाने पर, एक साथ चलने वाले टेस्ट को रद्द कर देगा. यह केवल --runs_per_test_detects_flakes के साथ संयोजन में उपयोगी है.
टैग:affects_outputs
,loading_and_analysis
--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>
डिफ़ॉल्ट: ""- पक्षों के पक्ष में रोक लगा दी गई. फ़िल्टर उन टारगेट का सेट है जिनके लिए Additional_action शेड्यूल करना है.
--[no]experimental_extra_action_top_level_only
डिफ़ॉल्ट: "गलत"- पक्षों के पक्ष में रोक लगा दी गई. सिर्फ़ टॉप लेवल के टारगेट के लिए additional_action शेड्यूल करता है.
--[no]experimental_fetch_all_coverage_outputs
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो Bazel, कवरेज के दौरान हर जांच के लिए, कवरेज की पूरी डेटा डायरेक्ट्री को फ़ेच करता है.
टैग:affects_outputs
,loading_and_analysis
--[no]experimental_generate_llvm_lcov
डिफ़ॉल्ट: "गलत"-
अगर सही है, तो Clang की जानकारी एक एलसीओवी रिपोर्ट जनरेट करेगी.
टैग: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_prioritize_local_actions
डिफ़ॉल्ट: "सही"-
अगर इस नीति को सेट किया जाता है, तो जो कार्रवाइयां सिर्फ़ स्थानीय तौर पर हो सकती हैं उन्हें रिसॉर्स हासिल करने का पहला मौका मिलता है. साथ ही, डाइनैमिक तौर पर काम करने वाले कर्मचारियों को दूसरा मौका मिलता है. साथ ही, डाइनैमिक तौर पर चलाई जाने वाली कार्रवाइयां, आखिरी होती हैं.
टैग:execution
--[no]experimental_run_android_lint_on_java_rules
डिफ़ॉल्ट: "गलत"-
java_* स्रोतों को सत्यापित करना है या नहीं.
टैग:affects_outputs
--[no]explicit_java_test_deps
डिफ़ॉल्ट: "गलत"- टेस्ट रनर के डिप से गलती से मिलने के बजाय, java_test में JUnit या Hamcrest के लिए साफ़ तौर पर एक डिपेंडेंसी बताएं. फ़िलहाल, यह सिर्फ़ बज़ल के लिए काम करता है.
--host_java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- बिल्डर के दौरान एक्ज़ीक्यूट होने वाले टूल के ज़रिए इस्तेमाल किया जाने वाला Java लॉन्चर.
--host_javacopt=<a string>
बार कई इस्तेमाल किए गए- किसी बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय javac को पास करने के लिए अतिरिक्त विकल्प.
--host_jvmopt=<a string>
बार कई इस्तेमाल किए गए- बिल्ड के दौरान एक्ज़ीक्यूट होने वाले टूल बनाते समय, Java वीएम में पास करने के लिए अतिरिक्त विकल्प. ये विकल्प हर java_binary टारगेट के वर्चुअल मशीन (वीएम) स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--[no]incompatible_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
-
इससे, Java की वर्चुअल मशीन की जांच शुरू होने से पहले, JDWP के हिसाब से काम करने वाले डीबगर (जैसे कि jdb) के कनेक्शन का इंतज़ार हो जाता है. इंप्रेशन -test_output=streamed.
इसमें शामिल है:
--test_arg=--wrapper_script_flag=--debug
--test_output=streamed
--test_strategy=exclusive
--test_timeout=9999
--nocache_test_results
--[no]java_deps
डिफ़ॉल्ट: "सही"- हर Java टारगेट के हिसाब से, डिपेंडेंसी की जानकारी जनरेट करें (अब कंपाइल-टाइम क्लासपाथ).
--[no]java_header_compilation
डिफ़ॉल्ट: "सही"- सोर्स रिपोर्ट में, सीधे स्रोत से डेटा इकट्ठा करें.
--java_language_version=<a string>
डिफ़ॉल्ट: ""- Java का भाषा वर्शन
--java_launcher=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर इस्तेमाल किया जाता है. "लॉन्चर" विशेषता इस फ़्लैग को ओवरराइड करती है.
--java_runtime_version=<a string>
: "local_jdk" डिफ़ॉल्ट- Java रनटाइम वर्शन
--javacopt=<a string>
बार कई इस्तेमाल किए गए- javac में पास करने के लिए अतिरिक्त विकल्प.
--jvmopt=<a string>
बार कई इस्तेमाल किए गए- Java VM को पास करने के लिए और विकल्प. ये विकल्प हर java_binary टारगेट के वर्चुअल मशीन (वीएम) स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.
--legacy_main_dex_list_generator=<a build target label>
डिफ़ॉल्ट: ब्यौरा देखें- लेगसी मल्टीडेक्स को कंपाइल करते समय, उन क्लास की सूची जनरेट करने के लिए, बाइनरी फ़ाइल का इस्तेमाल किया जाता है जो मुख्य डेक में होनी चाहिए.
--local_cpu_resources=<an integer, or "HOST_CPUS", optionally followed by [-|*]<float>.>
की डिफ़ॉल्ट वैल्यू: "Host_CPUS"- Bela के लिए उपलब्ध लोकल सीपीयू कोर की कुल संख्या को साफ़ तौर पर सेट करें, ताकि बिल्ड से जुड़ी कार्रवाइयों को स्थानीय तौर पर किया जा सके. एक पूर्णांक या "होस्ट_CPUS" लेता है, जिसके बाद [-|*]<float> आता है (उदाहरण के लिए, उपलब्ध CPU कोर का इस्तेमाल करने के लिए PAS_CPUS*.5. डिफ़ॉल्ट रूप से, Bazel सिस्टम कॉन्फ़िगरेशन की क्वेरी करके उपलब्ध सीपीयू कोर की संख्या का अनुमान लगाएगा.
--local_ram_resources=<an integer, or "HOST_RAM", optionally followed by [-|*]<float>.>
डिफ़ॉल्ट: "Host_RAM*.67"- स्थानीय रूप से बनाई गई बिल्ड कार्रवाइयों पर खर्च करने के लिए, Bazel को उपलब्ध लोकल होस्ट रैम (MB में) की कुल संख्या को साफ़ तौर पर सेट करें. पूरा अंक लेता है या "होस्ट_रैम" लेता है. इसके बाद, [-|*]<float> डालें होस्ट_रैम*.5 (इसके लिए, फ़ोन की रैम का आधा हिस्सा इस्तेमाल किया जाता है). डिफ़ॉल्ट रूप से, Bazel, सिस्टम कॉन्फ़िगरेशन की क्वेरी करके, रैम की उपलब्ध मेमोरी का अनुमान लगाता है. इस तरह, रैम का 67% इस्तेमाल किया जाता है.
--local_termination_grace_seconds=<an integer>
डिफ़ॉल्ट: "15"- टाइम आउट की वजह से, किसी लोकल प्रोसेस को बंद करने और उसे ज़बरदस्ती बंद करने के बीच इंतज़ार करना.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- इसमें, पैकेजन को अलग करने की सूची है. इसमें, पैकेज की तलाश कहां की गई है. '%workspace%' से शुरू होने वाले एलिमेंट, आस-पास के फ़ाइल फ़ोल्डर के हिसाब से होते हैं. शामिल न करने या खाली छोड़ने पर, डिफ़ॉल्ट रूप से 'बेज़ल की जानकारी के लिए डिफ़ॉल्ट पैकेज पाथ' डाला जाता है.
--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:प्रोटोक"-
प्रोटो-कंपाइलर का लेबल.
टैग:affects_outputs
,loading_and_analysis
--proto_toolchain_for_cc=<a build target label>
डिफ़ॉल्ट: "@bazel_tools//tools/proto:cc_toolchain"-
Cto++ प्रोटोल को कंपाइल करने के तरीके के बारे में बताने वाला proto_lang_toolchain() का लेबल
टैग: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 सर्वर को शुरू करता है), तो Bazel उसका इस्तेमाल करता है. अगर दोनों में से किसी को भी सेट नहीं किया जाता है, तो Bazel हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है. यह उसके ऑपरेटिंग सिस्टम पर निर्भर करता है (Windows: c:/tools/msys64/usr/bin/bash.exe, FreeBSD: /usr/local/bin/bash, बाकी सभी: /bin/bash). ध्यान दें कि ऐसे शेल का इस्तेमाल करना जो बैश के साथ काम नहीं करता है, जनरेट की गई बाइनरी के काम नहीं करने या रनटाइम के काम न करने की वजह बन सकता है.
टैग:loading_and_analysis
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर यह चालू है, तो बेज़ल "पैकेज लोड हो रहा है:" मैसेज प्रिंट कर लेता है.
--test_arg=<a string>
बार कई इस्तेमाल किए गए- इस नीति से, एक्ज़ीक्यूटेबल पर पास किए जाने वाले अन्य विकल्प और आर्ग्युमेंट के बारे में पता चलता है. कई आर्ग्युमेंट के बारे में बताने के लिए, कई बार इस्तेमाल किया जा सकता है. अगर एक से ज़्यादा जांच एक्ज़ीक्यूट की जाती हैं, तो हर टेस्ट को एक जैसा तर्क मिलेगा. इसका इस्तेमाल सिर्फ़ 'बेज़ल टेस्ट' निर्देश के ज़रिए किया जाता है.
--test_filter=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- टेस्ट फ़्रेमवर्क में आगे बढ़ने के लिए फ़िल्टर तय करता है. इसका इस्तेमाल, चल रहे टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बने हैं.
--test_lang_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- टेस्ट भाषाओं की कॉमा-सेपरेटेड लिस्ट तय करता है. निकाली गई भाषाओं को तय करने के लिए हर भाषा को वैकल्पिक रूप से '-' से पहले जोड़ा जा सकता है. सिर्फ़ वे टेस्ट टारगेट मिलेंगे जो तय भाषाओं में लिखे गए हैं. हर भाषा के लिए इस्तेमाल किया जाने वाला नाम, *_test नियम के लिए भाषा के प्रीफ़िक्स से मेल खाना चाहिए. उदाहरण के लिए, 'cc', 'java', 'py' वगैरह में से कोई एक विकल्प. यह विकल्प --build_tests_only व्यवहार और जांच कमांड पर असर डालता है.
--test_result_expiration=<an integer>
डिफ़ॉल्ट: "-1"- इस विकल्प के इस्तेमाल पर रोक लगा दी गई है और इसका कोई असर नहीं है.
--[no]test_runner_fail_fast
डिफ़ॉल्ट: "गलत"- फ़ॉरवर्ड करने की सुविधा, टेस्ट रनर के पास जल्दी नहीं जाती. पहली बार विफल होने पर टेस्ट रनर को एक्ज़ीक्यूशन बंद कर देना चाहिए.
--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce>
डिफ़ॉल्ट: "अश्लील"- टेस्ट शार्डिंग के लिए रणनीति तय करें: 'अश्लील' टेक्स्ट, सिर्फ़ तब, जब 'shar_count' BUILD एट्रिब्यूट मौजूद हो. 'बंद है' का इस्तेमाल करें. 'sforce_count' BUILD विशेषता पर ध्यान दिए बिना, परीक्षण के लिए 'k' शार्ड लागू करने के लिए 'forced=k'.
--test_size_filters=<comma-separated list of values: small, medium, large or enormous>
डिफ़ॉल्ट: ""- इससे, टेस्ट साइज़ की कॉमा-सेपरेटेड लिस्ट बनती है. शामिल न किए जाने वाले साइज़ को तय करने के लिए, हर साइज़ को पहले '-' से पहले रखा जा सकता है. सिर्फ़ वे टेस्ट टारगेट ही मिलेंगे जिनमें कम से कम एक शामिल किया गया साइज़ हो और बाहर रखा गया कोई साइज़ न हो. यह विकल्प --build_tests_only व्यवहार और परीक्षण आदेश को प्रभावित करता है.
--test_tag_filters=<comma-separated list of options>
डिफ़ॉल्ट: ""- टेस्ट टैग की कॉमा-सेपरेटेड लिस्ट तय करता है. बाहर रखे गए टैग की जानकारी देने के लिए हर टैग के आगे वैकल्पिक रूप से '-' हो सकता है. सिर्फ़ वे टेस्ट टारगेट ही मिलेंगे जिनमें कम से कम एक शामिल किया गया टैग होता है और बाहर निकाला गया कोई भी टैग नहीं होता है. यह विकल्प --build_tests_only व्यवहार और परीक्षण आदेश को प्रभावित करता है.
--test_timeout_filters=<comma-separated list of values: short, moderate, long or eternal>
डिफ़ॉल्ट: ""- यह जांच करने के टाइम आउट की ऐसी सूची है जिसमें कॉमा लगाकर अलग किए गए हैं. शामिल न करने के टाइम आउट तय करने के लिए, हर टाइम आउट को वैकल्पिक रूप से '-' से पहले रखा जा सकता है. सिर्फ़ वे टेस्ट टारगेट ही मिलेंगे जिनमें टारगेट किए गए टाइम आउट में से, कम से कम एक टाइम आउट शामिल हो. साथ ही, इनमें ऐसे सभी टाइम आउट (टाइम आउट) शामिल नहीं होने चाहिए जो बाहर रखे गए हैं. यह विकल्प --build_tests_only व्यवहार और परीक्षण आदेश को प्रभावित करता है.
--tool_java_language_version=<a string>
डिफ़ॉल्ट: ""- बिल्डर के दौरान ज़रूरी टूल एक्ज़ीक्यूट करने के लिए इस्तेमाल किया जाने वाला Java लैंग्वेज वर्शन
--tool_java_runtime_version=<a string>
डिफ़ॉल्ट: "remotejdk_11"- बिल्ड के दौरान टूल चलाने के लिए इस्तेमाल किया जाने वाला Java रनटाइम वर्शन
--[no]use_ijars
डिफ़ॉल्ट: "सही"- चालू होने पर, इस विकल्प की वजह से Java कंपाइलेशन, इंटरफ़ेस जार का इस्तेमाल करेगा. इससे तेज़ी से बढ़ता हुआ कंपाइलेशन हो सकता है, लेकिन गड़बड़ी वाले मैसेज अलग हो सकते हैं.
कैननिकल के फ़्लैग करने के विकल्प
build से सभी विकल्प इनहेरिट करता है.
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने पार्स किए हैं:
--distdir=<a path>
बार कई इस्तेमाल किए गए-
संग्रह को डाउनलोड करने के लिए नेटवर्क को ऐक्सेस करने से पहले उन्हें ढूंढने के लिए अतिरिक्त स्थान.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "गलत"-
अगर यह नीति सेट की जाती है, तो कैश मेमोरी में सेव होने पर कैश मेमोरी में सेव होने की स्थिति में, डेटा को रिपॉज़िटरी कैश मेमोरी में सेव कर दिया जाएगा. इसका इस्तेमाल डिस्क में जगह बचाने के लिए किया जाता है.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_urls_as_default_canonical_id
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो डेटा डाउनलोड करने के लिए दिए गए यूआरएल से मिली स्ट्रिंग का इस्तेमाल कैननिकल यूआरएल के तौर पर करें. अगर इसकी जानकारी नहीं है, तो कैननिकल यूआरएल के तौर पर इसका इस्तेमाल करें. ऐसा इसलिए होता है, क्योंकि यूआरएल में बदलाव करने से, पेज को फिर से डाउनलोड किया जाता है. भले ही, कैश मेमोरी में एक जैसा हैश वाला डाउनलोड हो. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि यूआरएल में बदलाव की वजह से, डेटा स्टोर करने की जगह में कैश मेमोरी को मास्क नहीं किया जाता.
टैग:loading_and_analysis
,experimental
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया गया है, तो बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं है.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
किसी डाउनलोड गड़बड़ी के लिए फिर से प्रयास करने की अधिकतम संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने की जगह के नियमों में, सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड बदले बिना, ऐसी मशीन पर बाहरी डेटा स्टोर करने की जगहें बनाई जा सकती हैं जो नियम के लेखक से धीमी हैं
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
http डाउनलोड से जुड़े सभी टाइम आउट, दिए गए फ़ैक्टर के आधार पर बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति बाहरी वैल्यू का डेटा फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी में सेव की गई जगह की जानकारी देती है. एक खाली स्ट्रिंग, जिसमें कैश मेमोरी को बंद करने का अनुरोध किया गया हो.
टैग:bazel_internal_configuration
- विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:
--[no]canonicalize_policy
डिफ़ॉल्ट: "गलत"-
एक्सपैंशन और फ़िल्टर लागू करने के बाद, कैननिकल नीति के बारे में बताएं. आउटपुट को साफ़ बनाए रखने के लिए, इस विकल्प को 'सही है' पर सेट करने पर, कैननिकल कमांड के तर्क नहीं दिखाए जाएंगे. ध्यान दें कि --for_command ने जो निर्देश बताया है वह फ़िल्टर की गई नीति पर असर डालता है. अगर कोई निर्देश नहीं दिया गया है, तो डिफ़ॉल्ट निर्देश 'build' होता है.
टैग:affects_outputs
,terminal_output
--[no]show_warnings
डिफ़ॉल्ट: "गलत"-
स्टैंडर्ड गड़बड़ी (उदाहरण के लिए, अलग-अलग फ़्लैग करने के विकल्पों के लिए) के लिए पार्सर की चेतावनी.
टैग:affects_outputs
,terminal_output
- वे विकल्प जो यह तय करते हैं कि Bazel का इस्तेमाल करके, मान्य बिल्ड इनपुट को कैसे लागू किया जाता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह फ़ील्ड खाली न हो, तो इसमें ऐसी फ़ाइल की जानकारी होती है जिसका समाधान हो चुका हो. इसके लिए, रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--experimental_verify_repository_rules=<a string>
बार कई इस्तेमाल किए गए-
अगर उन रिपॉज़िटरी नियमों की सूची जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी है, तब फ़ाइल --experimental_repository_sha_file के ज़रिए दी गई है.
टैग:affects_outputs
,experimental
- यह विकल्प Starlark की भाषा के सिमेंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE की फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर डालता है.
--[no]experimental_allow_top_level_aspects_parameters
डिफ़ॉल्ट: "सही"-
नहीं-नहीं
टैग:no_op
,deprecated
,experimental
--[no]incompatible_config_setting_private_default_visibility
डिफ़ॉल्ट: "गलत"-
अगर काम नहीं करता, तो यह noop. अगर यह फ़्लैग गलत है, तो साफ़ तौर पर दिखने वाली विशेषता के बिना कोई config_setting //visible:public है. अगर इस फ़्लैग को 'सही' पर सेट किया जाता है, तो config_setting उसी लॉजिक का पालन करता है जो अन्य सभी नियमों को फ़ॉलो करता है. https://github.com/bazelbuild/bazel/issues/12933 देखें.
टैग:loading_and_analysis
,incompatible_change
--[no]incompatible_enforce_config_setting_visibility
डिफ़ॉल्ट: "सही"-
अगर यह सही है, तो config_setting विज़िबिलिटी से जुड़ी पाबंदियां लागू करें. अगर गलत हो, तो हर config_setting हर टारगेट को दिखाई देता है. https://github.com/bazelbuild/bazel/issues/12932 देखें.
टैग:loading_and_analysis
,incompatible_change
- Bzlmod आउटपुट और सिमैंटिक से जुड़े विकल्प:
--allow_yanked_versions=<a string>
बार कई इस्तेमाल किए गए-
मॉड्यूल वर्शन को `<module1>@<version1>,<module2>@<version2>` के तौर पर तय करें. इसका समाधान, समाधान किए गए डिपेंडेंसी ग्राफ़ में होगा. भले ही, उनका नाम रजिस्ट्री में यांकी पर बताया गया हो (अगर वह किसी रजिस्ट्री में नहीं आ रहा है). ऐसा न करने पर, याक किए गए वर्शन से रिज़ॉल्यूशन हट जाएगा. आप `BZLMOD_ALLOW_YANKED_वर्शनS` एनवायरमेंट वैरिएबल से, मंज़ूर किया गया यांक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (हम इसका सुझाव नहीं देते).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Bazel मॉड्यूल के साथ काम करने वाले वर्शन के बारे में जानें. मान्य वैल्यू को `गड़बड़ी` के तौर पर मार्क किया जाता है, ताकि समस्या का समाधान न हो पाने पर, उसे बंद किया जा सके. जांच बंद करने के लिए `गड़बड़ी` या मेल न खाने की स्थिति का पता लगने पर, चेतावनी वाली चेतावनी को प्रिंट किया जा सकता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
जांचें कि क्या रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच की सुविधा को बंद करने के लिए, `वैल्यू` को बंद कर दिया जाता है. मेल न खाने पर, चेतावनी को प्रिंट करने के लिए `चेतावनी` या समाधान से जुड़ी गड़बड़ी की सूचना देने के लिए `गड़बड़ी`.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को `dev_dependency` के रूप में अनदेखा कर देता है. ध्यान दें कि अगर इस फ़्लैग की वैल्यू कुछ भी हो, तब भी MODULE.bazel में उन डेवलपर डिपेंडेंसी को नज़रअंदाज़ किया जाता है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई इस्तेमाल किए गए- किसी मॉड्यूल को स्थानीय डायरेक्ट्री से बदल देता है.
--registry=<a string>
बार कई इस्तेमाल किए गए-
यह रजिस्ट्री को बताता है कि Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किन रजिस्ट्री का इस्तेमाल किया जाए. ऑर्डर ज़रूरी है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा. बाद में, सिर्फ़ रजिस्ट्री में वापस आएंगी.
टैग:changes_inputs
- वे विकल्प जिनसे लॉग की भाषा, फ़ॉर्मैट या जगह पर असर पड़ता है:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 वर्णों के हिसाब से तय होती है. साथ ही, कार्रवाई करने के लिए, सबसे ज़्यादा संख्या ही इस्तेमाल की जा सकती है. यह विकल्प सेट करने पर, सभी नियमों के हिसाब से आंकड़े लिखे जाएंगे.
- किसी जेनरिक इनपुट के बारे में बताने या उसमें बदलाव करने के विकल्प जो किसी अन्य कैटगरी में नहीं आते.
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर खाली नहीं है, तो WORKSPACE फ़ाइल के बजाय रिज़ॉल्व की गई फ़ाइल को पढ़ें
टैग:changes_inputs
--for_command=<a string>
डिफ़ॉल्ट: "बनाएं"-
वह निर्देश जिसके लिए विकल्पों को कैननिकल किया जाना चाहिए.
टैग:affects_outputs
,terminal_output
--invocation_policy=<a string>
डिफ़ॉल्ट: ""-
यूआरएल के कैननिकल होने की जांच करने वाली नीति, कैननिकल यूआरएल के विकल्पों में लागू होती है.
टैग:affects_outputs
,terminal_output
- रिमोट कैश मेमोरी और एक्ज़ीक्यूशन के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होता है, जिसके बाद एक होस्ट नाम (`allow` और `block`) या दो पैटर्न होते हैं, एक मिलान करता है, और एक वैकल्पिक यूआरएल के रूप में इस्तेमाल करता है, जिसमें `1` से शुरू होने वाली बैक-रेफ़रंस होती हैं. एक ही यूआरएल देने के लिए, कई `rewrite` निर्देशों के लिए संभव है और इस मामले में एक से ज़्यादा यूआरएल मिलेंगे.
- अन्य विकल्प, लेकिन इनकी श्रेणी नहीं तय की गई है.:
--deleted_packages=<comma-separated list of package names>
बार कई इस्तेमाल किए गए- कॉमा लगाकर अलग किए गए उन पैकेज की सूची जिन्हें बिल्ड सिस्टम मौजूद नहीं है, भले ही वे पैकेज पाथ पर कहीं भी दिखते हों. मौजूदा पैकेज 'x' का सब-पैकेज 'x/y' मिटाते समय इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपने क्लाइंट में x/y/BUILD मिटाने के बाद, अगर यह अब भी किसी दूसरी package_path एंट्री से मिलता है, तो बिल्ड सिस्टम शिकायत कर सकता है कि इसे '//x:y/z' लेबल मिलता है या नहीं. --delete_packages x/y तय करना इस समस्या से बचाता है.
--override_repository=<an equals-separated mapping of repository name to path>
बार कई इस्तेमाल किए गए- डेटा स्टोर करने की जगह को स्थानीय डायरेक्ट्री से बदल देता है.
--package_path=<colon-separated list of options>
डिफ़ॉल्ट: "%workspace%"- इसमें, पैकेजन को अलग करने की सूची है. इसमें, पैकेज की तलाश कहां की गई है. '%workspace%' से शुरू होने वाले एलिमेंट, आस-पास के फ़ाइल फ़ोल्डर के हिसाब से होते हैं. शामिल न करने या खाली छोड़ने पर, डिफ़ॉल्ट रूप से 'बेज़ल की जानकारी के लिए डिफ़ॉल्ट पैकेज पाथ' डाला जाता है.
--[no]show_loading_progress
डिफ़ॉल्ट: "सही"- अगर यह चालू है, तो बेज़ल "पैकेज लोड हो रहा है:" मैसेज प्रिंट कर लेता है.
साफ़ विकल्प
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
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया गया है, तो बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं है.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
किसी डाउनलोड गड़बड़ी के लिए फिर से प्रयास करने की अधिकतम संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने की जगह के नियमों में, सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड बदले बिना, ऐसी मशीन पर बाहरी डेटा स्टोर करने की जगहें बनाई जा सकती हैं जो नियम के लेखक से धीमी हैं
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
http डाउनलोड से जुड़े सभी टाइम आउट, दिए गए फ़ैक्टर के आधार पर बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति बाहरी वैल्यू का डेटा फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी में सेव की गई जगह की जानकारी देती है. एक खाली स्ट्रिंग, जिसमें कैश मेमोरी को बंद करने का अनुरोध किया गया हो.
टैग:bazel_internal_configuration
- विकल्प जो कमांड के आउटपुट को कंट्रोल करते हैं:
--[no]async
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो आउटपुट साफ़ नहीं होता. जब यह निर्देश पूरा हो जाएगा, तो उसी क्लाइंट में नए निर्देश लागू करना सुरक्षित रहेगा, भले ही उसे मिटाने का काम बैकग्राउंड में जारी रह सकता है.
टैग:host_machine_resource_optimizations
--[no]expunge
डिफ़ॉल्ट: "गलत"-
अगर यह वैल्यू 'सही है' पर सेट है, तो साफ़ करने पर, इस बेज़ल इंस्टेंस के लिए, काम कर रहे पूरे ट्री को हटा दिया जाता है. इसमें, bazel से बनाए गए सभी अस्थायी आउटपुट और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. अगर यह चलता है, तो bazel सर्वर बंद हो जाएगा.
टैग:host_machine_resource_optimizations
--expunge_async
-
अगर नीति को तय किया गया है, तो एसिंक्रोनस तरीके से, सिंक करने का यह तरीका, बेज़ल के इस इंस्टेंस के लिए काम कर रहे पूरे पेड़ को हटा देता है. इसमें बेज़ल से बनी सभी अस्थायी फ़ाइलें और आउटपुट फ़ाइलें शामिल हैं. अगर यह चालू है, तो बेज़ल सर्वर काम करना बंद कर देता है. जब यह निर्देश पूरा हो जाएगा, तो उसी क्लाइंट में नए निर्देश लागू करना सुरक्षित रहेगा, भले ही उसे मिटाने का काम बैकग्राउंड में जारी रह सकता है.
इसमें शामिल है:
--expunge
--async
टैग:host_machine_resource_optimizations
--[no]remove_all_convenience_symlinks
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो symlink_prefix से जुड़े फ़ाइल फ़ोल्डर में सभी सिमलिंक मिटा दिए जाएंगे. इस फ़्लैग के बिना, पहले से तय किए गए सफ़िक्स के सिमलिंक ही हटा दिए जाते हैं.
टैग:affects_outputs
- वे सेटिंग जो इस बात पर असर डालती हैं कि Bazel, बिल्ड के मान्य इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह फ़ील्ड खाली न हो, तो इसमें ऐसी फ़ाइल की जानकारी होती है जिसका समाधान हो चुका हो. इसके लिए, रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--experimental_verify_repository_rules=<a string>
बार कई इस्तेमाल किए गए-
अगर उन रिपॉज़िटरी नियमों की सूची जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी है, तब फ़ाइल --experimental_repository_sha_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>` के तौर पर तय करें. इसका समाधान, समाधान किए गए डिपेंडेंसी ग्राफ़ में होगा. भले ही, उनका नाम रजिस्ट्री में यांकी पर बताया गया हो (अगर वह किसी रजिस्ट्री में नहीं आ रहा है). ऐसा न करने पर, याक किए गए वर्शन से रिज़ॉल्यूशन हट जाएगा. आप `BZLMOD_ALLOW_YANKED_वर्शनS` एनवायरमेंट वैरिएबल से, मंज़ूर किया गया यांक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (हम इसका सुझाव नहीं देते).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Bazel मॉड्यूल के साथ काम करने वाले वर्शन के बारे में जानें. मान्य वैल्यू को `गड़बड़ी` के तौर पर मार्क किया जाता है, ताकि समस्या का समाधान न हो पाने पर, उसे बंद किया जा सके. जांच बंद करने के लिए `गड़बड़ी` या मेल न खाने की स्थिति का पता लगने पर, चेतावनी वाली चेतावनी को प्रिंट किया जा सकता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
जांचें कि क्या रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच की सुविधा को बंद करने के लिए, `वैल्यू` को बंद कर दिया जाता है. मेल न खाने पर, चेतावनी को प्रिंट करने के लिए `चेतावनी` या समाधान से जुड़ी गड़बड़ी की सूचना देने के लिए `गड़बड़ी`.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को `dev_dependency` के रूप में अनदेखा कर देता है. ध्यान दें कि अगर इस फ़्लैग की वैल्यू कुछ भी हो, तब भी MODULE.bazel में उन डेवलपर डिपेंडेंसी को नज़रअंदाज़ किया जाता है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई इस्तेमाल किए गए- किसी मॉड्यूल को स्थानीय डायरेक्ट्री से बदल देता है.
--registry=<a string>
बार कई इस्तेमाल किए गए-
यह रजिस्ट्री को बताता है कि Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किन रजिस्ट्री का इस्तेमाल किया जाए. ऑर्डर ज़रूरी है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा. बाद में, सिर्फ़ रजिस्ट्री में वापस आएंगी.
टैग:changes_inputs
- वे विकल्प जिनसे लॉग की भाषा, फ़ॉर्मैट या जगह पर असर पड़ता है:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 वर्णों के हिसाब से तय होती है. साथ ही, कार्रवाई करने के लिए, सबसे ज़्यादा संख्या ही इस्तेमाल की जा सकती है. यह विकल्प सेट करने पर, सभी नियमों के हिसाब से आंकड़े लिखे जाएंगे.
- किसी जेनरिक इनपुट के बारे में बताने या उसमें बदलाव करने के विकल्प जो किसी अन्य कैटगरी में नहीं आते.
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर WORKSPACE फ़ाइल के बजाय समाधान नहीं की गई फ़ाइल पढ़ी जाती है, तो उसे नहीं पढ़ें
टैग:changes_inputs
- रिमोट कैशिंग और एक्ज़ीक्यूशन के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होता है, जिसके बाद एक होस्ट नाम (`allow` और `block`) या दो पैटर्न होते हैं, एक मिलान करता है, और एक वैकल्पिक यूआरएल के रूप में इस्तेमाल करता है, जिसमें `1` से शुरू होने वाली बैक-रेफ़रंस होती हैं. एक ही यूआरएल देने के लिए, कई `rewrite` निर्देशों के लिए संभव है और इस मामले में एक से ज़्यादा यूआरएल मिलेंगे.
- अन्य विकल्प, लेकिन इनकी श्रेणी नहीं तय की गई है.:
--override_repository=<an equals-separated mapping of repository name to path>
बार कई इस्तेमाल किए गए- डेटा स्टोर करने की जगह को स्थानीय डायरेक्ट्री से बदल देता है.
कॉन्फ़िगरेशन के विकल्प
कवरेज के विकल्प
test से सभी विकल्पों को इनहेरिट करता है.
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने पार्स किए हैं:
--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
--[no]experimental_repository_disable_download
डिफ़ॉल्ट: "गलत"-
अगर इस नीति को सेट किया गया है, तो बाहरी डेटा स्टोर करने की जगह को डाउनलोड करने की अनुमति नहीं है.
टैग:experimental
--experimental_repository_downloader_retries=<an integer>
डिफ़ॉल्ट: "0"-
किसी डाउनलोड गड़बड़ी के लिए फिर से प्रयास करने की अधिकतम संख्या. अगर इस नीति को 0 पर सेट किया जाता है, तो फिर से कोशिश करने की सुविधा बंद हो जाती है.
टैग:experimental
--experimental_scale_timeouts=<a double>
डिफ़ॉल्ट: "1.0"-
इस फ़ैक्टर के हिसाब से, Starlark के डेटा स्टोर करने की जगह के नियमों में, सभी टाइम आउट बढ़ाएं. इस तरह, सोर्स कोड बदले बिना, ऐसी मशीन पर बाहरी डेटा स्टोर करने की जगहें बनाई जा सकती हैं जो नियम के लेखक से धीमी हैं
टैग:bazel_internal_configuration
,experimental
--http_timeout_scaling=<a double>
डिफ़ॉल्ट: "1.0"-
http डाउनलोड से जुड़े सभी टाइम आउट, दिए गए फ़ैक्टर के आधार पर बढ़ाएं
टैग:bazel_internal_configuration
--repository_cache=<a path>
डिफ़ॉल्ट: ब्यौरा देखें-
यह नीति बाहरी वैल्यू का डेटा फ़ेच करने के दौरान, डाउनलोड की गई वैल्यू की कैश मेमोरी में सेव की गई जगह की जानकारी देती है. एक खाली स्ट्रिंग, जिसमें कैश मेमोरी को बंद करने का अनुरोध किया गया हो.
टैग:bazel_internal_configuration
- वे सेटिंग जो इस बात पर असर डालती हैं कि Bazel, मान्य बिल्ड इनपुट को कैसे लागू करता है (नियम की परिभाषाएं, फ़्लैग के कॉम्बिनेशन वगैरह):
--experimental_repository_hash_file=<a string>
डिफ़ॉल्ट: ""-
अगर यह फ़ील्ड खाली न हो, तो इसमें ऐसी फ़ाइल की जानकारी होती है जिसका समाधान हो चुका हो. इसके लिए, रिपॉज़िटरी डायरेक्ट्री के हैश की पुष्टि की जानी चाहिए
टैग:affects_outputs
,experimental
--experimental_verify_repository_rules=<a string>
बार कई इस्तेमाल किए गए-
अगर उन रिपॉज़िटरी नियमों की सूची जिनके लिए आउटपुट डायरेक्ट्री के हैश की पुष्टि की जानी है, तब फ़ाइल --experimental_repository_sha_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>` के तौर पर तय करें. इसका समाधान, समाधान किए गए डिपेंडेंसी ग्राफ़ में होगा. भले ही, उनका नाम रजिस्ट्री में यांकी पर बताया गया हो (अगर वह किसी रजिस्ट्री में नहीं आ रहा है). ऐसा न करने पर, याक किए गए वर्शन से रिज़ॉल्यूशन हट जाएगा. आप `BZLMOD_ALLOW_YANKED_वर्शनS` एनवायरमेंट वैरिएबल से, मंज़ूर किया गया यांक किया गया वर्शन भी तय कर सकते हैं. 'सभी' कीवर्ड का इस्तेमाल करके इस जांच को बंद किया जा सकता है (हम इसका सुझाव नहीं देते).
टैग:loading_and_analysis
--check_bazel_compatibility=<error, warning or off>
डिफ़ॉल्ट: "गड़बड़ी"-
Bazel मॉड्यूल के साथ काम करने वाले वर्शन के बारे में जानें. मान्य वैल्यू को `गड़बड़ी` के तौर पर मार्क किया जाता है, ताकि समस्या का समाधान न हो पाने पर, उसे बंद किया जा सके. जांच बंद करने के लिए `गड़बड़ी` या मेल न खाने की स्थिति का पता लगने पर, चेतावनी वाली चेतावनी को प्रिंट किया जा सकता है.
टैग:loading_and_analysis
--check_direct_dependencies=<off, warning or error>
डिफ़ॉल्ट: "चेतावनी"-
जांचें कि क्या रूट मॉड्यूल में बताई गई डायरेक्ट `bazel_dep` डिपेंडेंसी वही वर्शन हैं जो आपको रिज़ॉल्व किए गए डिपेंडेंसी ग्राफ़ में मिलते हैं. जांच की सुविधा को बंद करने के लिए, `वैल्यू` को बंद कर दिया जाता है. मेल न खाने पर, चेतावनी को प्रिंट करने के लिए `चेतावनी` या समाधान से जुड़ी गड़बड़ी की सूचना देने के लिए `गड़बड़ी`.
टैग:loading_and_analysis
--[no]ignore_dev_dependency
डिफ़ॉल्ट: "गलत"-
अगर यह सही है, तो Bazel, रूट मॉड्यूल के MODULE.bazel में `bazel_dep` और `use_extension` को `dev_dependency` के रूप में अनदेखा कर देता है. ध्यान दें कि अगर इस फ़्लैग की वैल्यू कुछ भी हो, तब भी MODULE.bazel में उन डेवलपर डिपेंडेंसी को नज़रअंदाज़ किया जाता है.
टैग:loading_and_analysis
--override_module=<an equals-separated mapping of module name to path>
बार कई इस्तेमाल किए गए- किसी मॉड्यूल को स्थानीय डायरेक्ट्री से बदल देता है.
--registry=<a string>
बार कई इस्तेमाल किए गए-
यह रजिस्ट्री को बताता है कि Bazel मॉड्यूल की डिपेंडेंसी का पता लगाने के लिए किन रजिस्ट्री का इस्तेमाल किया जाए. ऑर्डर ज़रूरी है: मॉड्यूल को पहले की रजिस्ट्री में देखा जाएगा. बाद में, सिर्फ़ रजिस्ट्री में वापस आएंगी.
टैग:changes_inputs
- वे विकल्प जिनसे लॉग की भाषा, फ़ॉर्मैट या जगह पर असर पड़ता है:
--[no]experimental_record_metrics_for_all_mnemonics
डिफ़ॉल्ट: "गलत"- डिफ़ॉल्ट रूप से, कार्रवाई के टाइप की संख्या 20 वर्णों के हिसाब से तय होती है. साथ ही, कार्रवाई करने के लिए, सबसे ज़्यादा संख्या ही इस्तेमाल की जा सकती है. यह विकल्प सेट करने पर, सभी नियमों के हिसाब से आंकड़े लिखे जाएंगे.
- किसी जेनरिक इनपुट के बारे में बताने या उसमें बदलाव करने के विकल्प जो किसी अन्य कैटगरी में नहीं आते.
--experimental_resolved_file_instead_of_workspace=<a string>
डिफ़ॉल्ट: ""-
अगर WORKSPACE फ़ाइल के बजाय समाधान नहीं की गई फ़ाइल पढ़ी जाती है, तो उसे नहीं पढ़ें
टैग:changes_inputs
- रिमोट कैशिंग और एक्ज़ीक्यूशन के विकल्प:
--experimental_downloader_config=<a string>
डिफ़ॉल्ट: ब्यौरा देखें- रिमोट डाउनलोडर को कॉन्फ़िगर करने के लिए कोई फ़ाइल तय करें. इस फ़ाइल में पंक्तियां हैं, जिनमें से हर एक डायरेक्टिव (`allow`, `block` या `rewrite`) से शुरू होता है, जिसके बाद एक होस्ट नाम (`allow` और `block`) या दो पैटर्न होते हैं, एक मिलान करता है, और एक वैकल्पिक यूआरएल के रूप में इस्तेमाल करता है, जिसमें `1` से शुरू होने वाली बैक-रेफ़रंस होती हैं. एक ही यूआरएल देने के लिए, कई `rewrite` निर्देशों के लिए संभव है और इस मामले में एक से ज़्यादा यूआरएल मिलेंगे.
- अन्य विकल्प, लेकिन इनकी श्रेणी नहीं तय की गई है.:
--override_repository=<an equals-separated mapping of repository name to path>
बार कई इस्तेमाल किए गए- डेटा स्टोर करने की जगह को स्थानीय डायरेक्ट्री से बदल देता है.
क्वेरी के विकल्प
test से सभी विकल्पों को इनहेरिट करता है.
- ऐसे विकल्प जो कमांड से पहले दिखते हैं और क्लाइंट ने पार्स किए हैं:
--distdir=<a path>
बार कई इस्तेमाल किए गए-
संग्रह को डाउनलोड करने के लिए नेटवर्क को ऐक्सेस करने से पहले उन्हें ढूंढने के लिए अतिरिक्त स्थान.
टैग:bazel_internal_configuration
--[no]experimental_repository_cache_hardlinks
डिफ़ॉल्ट: "गलत"- अगर यह नीति सेट की जाती है, तो कैश मेमोरी में सेव होने पर कैश मेमोरी में सेव होने की स्थिति में, ड