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

समस्या की शिकायत करें सोर्स देखें

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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]

निर्देश

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

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

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

--[no]autodetect_server_javabase default: "true"

जब --noautodetect_server_javabase पास किया जाता है, तो Bazel, bazel सर्वर को चलाने के लिए लोकल JDK पर वापस नहीं आता. इसके बजाय, यह बंद हो जाता है.

टैग: affects_outputs, loses_incremental_state

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

अगर इस विकल्प को सेट किया जाता है, तो Bazel को सर्वर के बिना सिर्फ़ क्लाइंट प्रोसेस के तौर पर चलाया जाएगा. ऐसा स्टैंडर्ड क्लाइंट/सर्वर मोड में चलाने के बजाय किया जाएगा. यह सुविधा अब काम नहीं करती और इसे हटा दिया जाएगा. अगर आपको सर्वर को बंद करने में समस्या आ रही है, तो कृपया सर्वर को बंद करने के लिए इस तरीके का इस्तेमाल करें.

टैग: loses_incremental_state, bazel_internal_configuration, deprecated

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

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

टैग: host_machine_resource_optimizations

--bazelrc=<path> कई बार इस्तेमाल किया गया हो

उपयोगकर्ता की .bazelrc फ़ाइल की जगह. इसमें Bazel के विकल्पों की डिफ़ॉल्ट वैल्यू होती हैं. /dev/null से पता चलता है कि आगे के सभी --bazelrc को अनदेखा किया जाएगा.यह उपयोगकर्ता की rc फ़ाइल की खोज को बंद करने के लिए उपयोगी है. उदाहरण के लिए, रिलीज़ बिल्ड में.

इस विकल्प को एक से ज़्यादा बार भी तय किया जा सकता है. उदाहरण के लिए, --bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc के साथ.

1. x.rc और y.rc को पढ़ा जाता है.
2. /dev/null की वजह से, z.rc को अनदेखा कर दिया गया है. अगर यह जानकारी नहीं दी गई है, तो Bazel, इन दो जगहों पर मिली पहली .bazelrc फ़ाइल का इस्तेमाल करता है: वर्कस्पेस डायरेक्ट्री और फिर उपयोगकर्ता की होम डायरेक्ट्री.

ध्यान दें: कमांड लाइन के विकल्प, हमेशा bazelrc में मौजूद किसी भी विकल्प से ज़्यादा प्राथमिकता वाले होते हैं.

टैग: changes_inputs

--[no]block_for_lock default: "true"

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

टैग: eagerness_to_exit

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

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

टैग: affects_outputs, bazel_monitoring

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

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

टैग: bazel_internal_configuration

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

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

टैग: loses_incremental_state, bazel_internal_configuration

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

वह cgroup जहां Bazel सर्वर को ऐब्सलूट पाथ के तौर पर शुरू करना है. सर्वर प्रोसेस, हर उस कंट्रोलर के लिए तय किए गए cgroup में शुरू की जाएगी जिसके लिए यह सुविधा उपलब्ध है. उदाहरण के लिए, अगर इस फ़्लैग की वैल्यू /build/bazel है और सीपीयू और मेमोरी कंट्रोलर को क्रमशः /sys/fs/cgroup/cpu और /sys/fs/cgroup/memory पर माउंट किया गया है, तो सर्वर को cgroups /sys/fs/cgroup/cpu/build/bazel और /sys/fs/cgroup/memory/build/bazel में शुरू किया जाएगा.अगर बताया गया cgroup, एक या उससे ज़्यादा कंट्रोलर के लिए लिखने लायक नहीं है, तो यह गड़बड़ी नहीं है. इस विकल्प का उन प्लैटफ़ॉर्म पर कोई असर नहीं पड़ता जिन पर cgroup काम नहीं करते.

टैग: bazel_monitoring, execution

--[no]experimental_run_in_user_cgroup डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो Bazel सर्वर को systemd-run के साथ चलाया जाएगा. साथ ही, उपयोगकर्ता के पास cgroup का मालिकाना हक होगा. इस फ़्लैग का असर सिर्फ़ Linux पर पड़ता है.

टैग: bazel_monitoring, execution

--extra_classpath=<a string> default: ""

Bazel सर्वर के क्लासपाथ में जोड़ने के लिए, कोलन से अलग की गई क्लासपाथ एंट्री की सूची.

टैग: bazel_internal_configuration

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

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

टैग: affects_outputs, loses_incremental_state

--[no]home_rc default: "true"

$HOME/.bazelrc पर मौजूद होम bazelrc फ़ाइल को खोजना है या नहीं

टैग: changes_inputs

--[no]idle_server_tasks default: "true"

सर्वर का इस्तेमाल न होने पर, System.gc() चलाएं

टैग: loses_incremental_state, host_machine_resource_optimizations

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

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

टैग: changes_inputs

--io_nice_level={-1,0,1,2,3,4,5,6,7} default: "-1"

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

टैग: host_machine_resource_optimizations

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

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

टैग: bazel_internal_configuration

--macos_qos_class=<a string> default: "default"

macOS पर Bazel सर्वर चलाने पर, यह विकल्प QoS सेवा क्लास सेट करता है. इस फ़्लैग का असर अन्य सभी प्लैटफ़ॉर्म पर नहीं पड़ता. हालांकि, इसे इसलिए इस्तेमाल किया जाता है, ताकि यह पक्का किया जा सके कि rc फ़ाइलों को बिना किसी बदलाव के इन प्लैटफ़ॉर्म के बीच शेयर किया जा सके. संभावित वैल्यू ये हैं: user-interactive, user-initiated, default, utility, और background.

टैग: host_machine_resource_optimizations

--max_idle_secs=<integer> default: "10800"

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

टैग: eagerness_to_exit, loses_incremental_state

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

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

टैग: affects_outputs, loses_incremental_state

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

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

टैग: affects_outputs, loses_incremental_state

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

अगर यह वैल्यू सही है, तो कोई दूसरी कमांड शुरू होने पर, इस कमांड को रोका जा सकता है.

टैग: eagerness_to_exit

--[no]quiet डिफ़ॉल्ट: "false"

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

टैग: affects_outputs, bazel_monitoring

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

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

टैग: affects_outputs, loses_incremental_state

--[no]shutdown_on_low_sys_mem डिफ़ॉल्ट: "false"

अगर max_idle_secs सेट है और बिल्ड सर्वर कुछ समय से इस्तेमाल नहीं किया जा रहा है, तो सिस्टम में खाली रैम कम होने पर सर्वर को बंद कर दें. सिर्फ़ Linux और MacOS पर उपलब्ध है.

टैग: eagerness_to_exit, loses_incremental_state

--[no]system_rc default: "true"

सिस्टम-वाइड bazelrc फ़ाइल को खोजना है या नहीं.

टैग: changes_inputs

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

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

टैग: bazel_internal_configuration

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

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

टैग: bazel_internal_configuration

--[no]workspace_rc default: "true"

$workspace/.bazelrc पर मौजूद, workspace की bazelrc फ़ाइल को ढूंढना है या नहीं

टैग: changes_inputs

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

--[no]experimental_remote_repo_contents_cache डिफ़ॉल्ट: "false"

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

टैग: loading_and_analysis

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

--host_jvm_args=<jvm_arg> कई बार इस्तेमाल किया गया हो

Blaze को चलाने वाले JVM को पास किए जाने वाले फ़्लैग.

--host_jvm_debug

कुछ अतिरिक्त JVM स्टार्टअप फ़्लैग जोड़ने का आसान विकल्प. इससे स्टार्टअप के दौरान JVM तब तक इंतज़ार करता है, जब तक आप JDWP के साथ काम करने वाले डीबगर (जैसे, Eclipse) से पोर्ट 5005 से कनेक्ट नहीं हो जाते.

बढ़ाकर:
  --host_jvm_args=-agentlib:jdwp=transport=dt_socket,server=y,address=5005

--server_javabase=<jvm path> default: ""

Bazel को चलाने के लिए इस्तेमाल किए गए JVM का पाथ.

सभी निर्देशों के लिए उपलब्ध विकल्प

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

--distdir=<a path> कई बार इस्तेमाल किया गया हो

नेटवर्क से डाउनलोड करने से पहले, संग्रहों को खोजने के लिए अन्य जगहें.

टैग: bazel_internal_configuration

--[no]experimental_repository_cache_hardlinks डिफ़ॉल्ट: "false"

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

टैग: bazel_internal_configuration

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

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

टैग: experimental

--experimental_scale_timeouts=<a double> default: "1.0"

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

टैग: bazel_internal_configuration, experimental

--http_connector_attempts=<an integer> default: "8"

एचटीटीपी डाउनलोड के लिए, कोशिशों की ज़्यादा से ज़्यादा संख्या.

टैग: bazel_internal_configuration

--http_connector_retry_max_timeout=<An immutable length of time.> default: "0s"

http डाउनलोड करने की कोशिशों के लिए ज़्यादा से ज़्यादा समयसीमा. वैल्यू 0 होने पर, ज़्यादा से ज़्यादा समयसीमा तय नहीं की जाती.

टैग: bazel_internal_configuration

--http_max_parallel_downloads=<an integer> default: "8"

साथ-साथ डाउनलोड होने वाली एचटीटीपी फ़ाइलों की ज़्यादा से ज़्यादा संख्या.

टैग: bazel_internal_configuration

--http_timeout_scaling=<a double> default: "1.0"

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

टैग: bazel_internal_configuration

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

यह विकल्प, रेपो के कॉन्टेंट की कैश मेमोरी की जगह के बारे में बताता है. इसमें फ़ेच की गई रेपो डायरेक्ट्री होती हैं, जिन्हें सभी वर्कस्पेस के साथ शेयर किया जा सकता है. आर्गुमेंट के तौर पर खाली स्ट्रिंग का इस्तेमाल करने से, repo contents कैश मेमोरी को बंद करने का अनुरोध किया जाता है. ऐसा न करने पर, {--repository_cache}/contents के डिफ़ॉल्ट मान का इस्तेमाल किया जाता है. ध्यान दें कि इसका मतलब है कि --repository_cache= को सेट करने पर, रिपॉज़िटरी के कॉन्टेंट की कैश मेमोरी भी डिफ़ॉल्ट रूप से बंद हो जाएगी. ऐसा तब तक होगा, जब तक --repo_contents_cache={some_path} को भी सेट नहीं किया जाता.

टैग: bazel_internal_configuration

--repo_contents_cache_gc_idle_delay=<An immutable length of time.> default: "5m"

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

टैग: bazel_internal_configuration

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

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

टैग: bazel_internal_configuration

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

यह डाउनलोड की गई वैल्यू की कैश मेमोरी की जगह के बारे में बताता है. ये वैल्यू, बाहरी रिपॉज़िटरी से फ़ेच की जाती हैं. आर्ग्युमेंट के तौर पर खाली स्ट्रिंग का इस्तेमाल करने से, कैश मेमोरी बंद करने का अनुरोध किया जाता है. ऐसा न करने पर, {--output_user_root}/cache/repos/v1 का डिफ़ॉल्ट मान इस्तेमाल किया जाता है.

टैग: bazel_internal_configuration

--[no]repository_disable_download डिफ़ॉल्ट: "false"

अगर यह सेट है, तो रिपॉज़िटरी फ़ेच करने के दौरान, ctx.download{,_and_extract} का इस्तेमाल करके डाउनलोड करने की अनुमति नहीं है. ध्यान दें कि नेटवर्क ऐक्सेस पूरी तरह से बंद नहीं किया गया है. ctx.execute अब भी किसी ऐसे एक्ज़ीक्यूटेबल को चला सकता है जो इंटरनेट ऐक्सेस करता है.

टैग: bazel_internal_configuration

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

--experimental_ui_max_stdouterr_bytes=<an integer in (-1)-1073741819 range> default: "1048576"

stdout / stderr फ़ाइलों का ज़्यादा से ज़्यादा साइज़, जिसे कंसोल पर प्रिंट किया जाएगा. -1 का मतलब है कि कोई सीमा नहीं है.

टैग: execution

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

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

टैग: host_machine_resource_optimizations

--gc_churning_threshold_if_multiple_top_level_targets=<an integer> default: "-1"

अगर इसकी वैल्यू [0, 100] के बीच सेट की गई है और यह टॉप-लेवल टारगेट (जैसे, क्वेरी के बजाय बिल्ड) का इस्तेमाल करने वाला कमांड है और ऐसे कई टॉप-लेवल टारगेट मौजूद हैं, तो यह --gc_churning_threshold को बदल देता है. जब कई टॉप-लेवल टारगेट होते हैं, तो यह ज़्यादा बेहतर तरीके से ओओएमिंग को कॉन्फ़िगर करने के लिए काम आता है. जैसे, --gc_churning_threshold से कम वैल्यू. इससे Bazel को कॉल करने वाला व्यक्ति, टारगेट को बांटकर फिर से कोशिश कर सकता है. साथ ही, जब एक टॉप-लेवल टारगेट होता है, तब भी ओओएमिंग को बेहतर तरीके से कॉन्फ़िगर किया जा सकता है.

टैग: host_machine_resource_optimizations

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

यह प्रतिशत, इस्तेमाल की गई मेमोरी का होता है. इसकी वैल्यू 0 से 100 के बीच होती है. इस वैल्यू से ज़्यादा होने पर, GcThrashingDetector, मेमोरी पर दबाव डालने वाले इवेंट को अपनी सीमाओं (--gc_thrashing_limits) के हिसाब से मानता है. अगर इसे 100 पर सेट किया जाता है, तो GcThrashingDetector बंद हो जाता है.

टैग: host_machine_resource_optimizations

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

--[no]incompatible_enable_proto_toolchain_resolution default: "true"

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

टैग: loading_and_analysis, incompatible_change

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

--bep_maximum_open_remote_upload_files=<an integer> default: "-1"

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

टैग: affects_outputs

--[no]experimental_strict_repo_env डिफ़ॉल्ट: "false"

सही होने पर, रिपॉज़िटरी के नियम और मॉड्यूल एक्सटेंशन सिर्फ़ PATH, PATHEXT (Windows पर), और --repo_env के ज़रिए साफ़ तौर पर बताए गए एनवायरमेंट वैरिएबल को इनहेरिट करेंगे.

ध्यान दें कि --incompatible_repo_env_ignores_action_env की वैल्यू 'सही' पर सेट न होने पर, --action_env=NAME=VALUE भी शामिल किया जाएगा.

टैग: loading_and_analysis, experimental

--[no]incompatible_repo_env_ignores_action_env default: "true"

अगर यह वैल्यू सही है, तो <code>--action_env=NAME=VALUE</code> का असर, रिपॉज़िटरी के नियम और मॉड्यूल एक्सटेंशन एनवायरमेंट पर नहीं पड़ेगा.

टैग: loading_and_analysis, incompatible_change

--remote_download_all

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

बढ़ाकर:
  --remote_download_outputs=all

टैग: affects_outputs

--remote_download_minimal

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

बढ़ाकर:
  --remote_download_outputs=minimal

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> default: "toplevel"

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

टैग: affects_outputs

--remote_download_symlink_template=<a string> default: ""

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

टैग: affects_outputs

--remote_download_toplevel

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

बढ़ाकर:
  --remote_download_outputs=toplevel

टैग: affects_outputs

--repo_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह सिर्फ़ रिपॉज़िटरी के नियमों के लिए उपलब्ध अतिरिक्त एनवायरमेंट वैरिएबल तय करता है. ध्यान दें कि रिपॉज़िटरी के नियमों में पूरे एनवायरमेंट को देखा जाता है. हालांकि, इस तरीके से वैरिएबल को कमांड-लाइन फ़्लैग और <code>.bazelrc</code> एंट्री के ज़रिए सेट किया जा सकता है. वैरिएबल को साफ़ तौर पर अनसेट करने के लिए, खास सिंटैक्स <code>=NAME</code> का इस्तेमाल किया जा सकता है. किसी वैल्यू में मौजूद स्ट्रिंग <code>%bazel_workspace%</code> को, <code>bazel info workspace</code> से प्रिंट किए गए फ़ाइल फ़ोल्डर के पूरे पाथ से बदल दिया जाएगा.

टैग: action_command_lines

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

--[no]allow_experimental_loads डिफ़ॉल्ट: "false"

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

टैग: build_file_semantics

--[no]check_bzl_visibility default: "true"

अगर यह सुविधा बंद है, तो .bzl फ़ाइल लोड करने से जुड़ी गड़बड़ियों को चेतावनियों में बदल दिया जाता है.

टैग: build_file_semantics

--[no]incompatible_enforce_starlark_utf8 डिफ़ॉल्ट: "warning"

अगर यह सेटिंग चालू है या इसे 'error' पर सेट किया गया है, तो Starlark फ़ाइलों के UTF-8 में एन्कोड न होने पर, यह सेटिंग काम नहीं करेगी. अगर इसे 'warning' पर सेट किया जाता है, तो इसके बजाय चेतावनी जारी करें. अगर इसे 'off' पर सेट किया जाता है, तो Bazel यह मान लेता है कि Starlark फ़ाइलें UTF-8 में एन्कोड की गई हैं. हालांकि, वह इस बात की पुष्टि नहीं करता है. ध्यान दें कि UTF-8 में एन्कोड नहीं की गई Starlark फ़ाइलों की वजह से, Bazel ठीक से काम नहीं कर सकता.

टैग: loading_and_analysis, incompatible_change

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

--[no]experimental_bzl_visibility default: "true"

यह विकल्प चालू होने पर, visibility() फ़ंक्शन जुड़ जाता है. .bzl फ़ाइलें, टॉप-लेवल के आकलन के दौरान इस फ़ंक्शन को कॉल कर सकती हैं. इससे load() स्टेटमेंट के लिए, फ़ाइलों की विज़िबिलिटी सेट की जा सकती है.

टैग: loading_and_analysis, experimental

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

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

टैग: build_file_semantics, loading_and_analysis, experimental

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

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

टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_dormant_deps डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो attr.label(materializer=), attr(for_dependency_resolution=), attr.dormant_label(), attr.dormant_label_list() और rule(for_dependency_resolution=) का इस्तेमाल किया जा सकता है.

टैग: build_file_semantics, experimental

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

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

टैग: build_file_semantics

--[no]experimental_enable_first_class_macros default: "true"

अगर इसे 'सही है' पर सेट किया जाता है, तो सिंबॉलिक मैक्रो तय करने के लिए macro() कंस्ट्रक्ट चालू हो जाता है.

टैग: build_file_semantics

--[no]experimental_enable_scl_dialect default: "true"

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

टैग: build_file_semantics

--[no]experimental_enable_starlark_set default: "true"

अगर यह सही है, तो Starlark में सेट डेटा टाइप और set() कंस्ट्रक्टर को चालू करें.

टैग: build_file_semantics, experimental

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

इसे सही पर सेट करने पर, Google के लेगसी कोड से जुड़े Starlark Build API के कई एक्सपेरिमेंटल कॉम्पोनेंट दिखते हैं.

टैग: loading_and_analysis, experimental

--[no]experimental_isolated_extension_usages डिफ़ॉल्ट: "false"

अगर यह सही है, तो <a href="https://bazel.build/rules/lib/globals/module#use_extension"><code>use_extension</code></a> फ़ंक्शन में<code>isolate</code> पैरामीटर चालू हो जाता है.

टैग: loading_and_analysis

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

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

टैग: loading_and_analysis, experimental

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

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

टैग: build_file_semantics, loading_and_analysis, experimental

--[no]experimental_repository_ctx_execute_wasm डिफ़ॉल्ट: "false"

अगर सही है, तो repository_ctx load_wasm और execute_wasm तरीके चालू करता है.

टैग: loading_and_analysis, experimental

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

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

टैग: action_command_lines, bazel_internal_configuration, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_single_package_toolchain_binding डिफ़ॉल्ट: "false"

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

टैग: loading_and_analysis, incompatible_change

--[no]experimental_starlark_type_checking डिफ़ॉल्ट: "false"

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

टैग: loading_and_analysis, experimental

--[no]experimental_starlark_type_syntax default: "true"

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

टैग: loading_and_analysis, experimental

--experimental_starlark_types_allowed_paths=<comma-separated list of options> default: ""

कैननिकल लेबल प्रीफ़िक्स की सूची, जिनके तहत Starlark टाइप के एनोटेशन की अनुमति है.

टैग: loading_and_analysis, experimental

--[no]force_starlark_stack_trace डिफ़ॉल्ट: "false"

अगर --force_starlark_stack_trace=true है, तो Starlark स्टैक ट्रेस हमेशा fail() के कॉल से प्रिंट किए जाएंगे. इनमें वे कॉल भी शामिल हैं जिन्हें आम तौर पर fail(..., stack_trace = False) से दबा दिया जाता है

टैग: loading_and_analysis

--[no]incompatible_allow_tags_propagation default: "true"

अगर इसे सही पर सेट किया जाता है, तो टैग को टारगेट से लेकर कार्रवाइयों को पूरा करने की ज़रूरी शर्तों तक भेजा जाएगा. ऐसा न करने पर, टैग नहीं भेजे जाएंगे. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/8830 पर जाएं.

टैग: build_file_semantics, experimental

--[no]incompatible_always_check_depset_elements default: "true"

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

टैग: build_file_semantics, incompatible_change

--incompatible_autoload_externally=<comma-separated set of options> default: ""

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

टैग: loses_incremental_state, build_file_semantics, incompatible_change

--[no]incompatible_check_external_repo_source_dir_package_boundary डिफ़ॉल्ट: "false"

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

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disable_autoloads_in_main_repo default: "true"

यह विकल्प कंट्रोल करता है कि मुख्य रिपॉज़िटरी में, --incompatible_autoload_externally से सेट किए गए ऑटोलोड चालू हैं या नहीं. इस सुविधा को चालू करने पर, Bazel में पहले से मौजूद नियमों (या अन्य सिंबल) में लोड स्टेटमेंट होने चाहिए. उन्हें जोड़ने के लिए, buildifier का इस्तेमाल करें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disable_objc_library_transition default: "true"

objc_library के कस्टम ट्रांज़िशन को बंद करें और इसके बजाय टॉप लेवल के टारगेट से इनहेरिट करें (Bazel में कोई कार्रवाई नहीं)

टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_starlark_host_transitions डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो नियम एट्रिब्यूट 'cfg = "host"' सेट नहीं कर सकते. नियमों को इसके बजाय, 'cfg = "exec"' सेट करना चाहिए.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disable_target_default_provider_fields डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो फ़ील्ड सिंटैक्स के ज़रिए डिफ़ॉल्ट प्रोवाइडर का इस्तेमाल करने की सुविधा बंद हो जाती है. इसके बजाय, provider-key सिंटैक्स का इस्तेमाल करें. उदाहरण के लिए, files को ऐक्सेस करने के लिए ctx.attr.dep.files का इस्तेमाल करने के बजाय, `ctx.attr.dep[DefaultInfo].files का इस्तेमाल करें. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/9014 पर जाएं.

टैग: build_file_semantics, incompatible_change

--incompatible_disable_transitions_on=<comma-separated set of options> default: ""

कॉमा लगाकर अलग किए गए फ़्लैग की ऐसी सूची जिनका इस्तेमाल ट्रांज़िशन के इनपुट या आउटपुट में नहीं किया जा सकता.

टैग: loading_and_analysis, incompatible_change, non_configurable

--[no]incompatible_disallow_ctx_resolve_tools default: "true"

अगर इसे 'सही है' पर सेट किया जाता है, तो ctx.resolve_tools API को कॉल करने पर हमेशा गड़बड़ी होती है. इस एपीआई के इस्तेमाल को, ctx.actions.run या ctx.actions.run_shell के लिए, एक्ज़ीक्यूटेबल या टूल आर्ग्युमेंट से बदला जाना चाहिए.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_disallow_empty_glob default: "true"

अगर इसे सही पर सेट किया जाता है, तो glob() के allow_empty आर्ग्युमेंट की डिफ़ॉल्ट वैल्यू गलत होती है.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_enable_deprecated_label_apis default: "true"

अगर यह सेटिंग चालू है, तो हटाए गए कुछ एपीआई (native.repository_name, Label.workspace_name, Label.relative) का इस्तेमाल किया जा सकता है.

टैग: loading_and_analysis

--[no]incompatible_fail_on_unknown_attributes default: "true"

अगर यह सुविधा चालू है, तो उन टारगेट को मंज़ूरी नहीं मिलती है जिनके लिए, 'कोई नहीं' पर सेट किए गए एट्रिब्यूट की वैल्यू 'अज्ञात' है.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_fix_package_group_reporoot_syntax default: "true"

package_group's packages एट्रिब्यूट में, "//..." वैल्यू का मतलब बदल जाता है. अब इसका मतलब किसी भी रिपॉज़िटरी के सभी पैकेज के बजाय, मौजूदा रिपॉज़िटरी के सभी पैकेज होता है. पुराने तरीके से काम करने के लिए, "//..." की जगह "public" वैल्यू का इस्तेमाल किया जा सकता है. इस फ़्लैग के लिए, --incompatible_package_group_has_public_syntax फ़्लैग भी चालू होना चाहिए.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_locations_prefers_executable default: "true"

अगर फ़ाइलों की संख्या एक से ज़्यादा है, तो क्या एक्ज़ीक्यूटेबल उपलब्ध कराने वाला टारगेट, $(locations ...) एक्सपैंशन के तहत <code>DefaultInfo.files</code> में मौजूद फ़ाइलों के बजाय एक्ज़ीक्यूटेबल में बदल जाता है.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_no_attr_license default: "true"

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

टैग: build_file_semantics, incompatible_change

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

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

टैग: build_file_semantics, incompatible_change

--[no]incompatible_no_implicit_watch_label default: "true"

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

टैग: loading_and_analysis, incompatible_change

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

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

टैग: build_file_semantics, incompatible_change

--[no]incompatible_package_group_has_public_syntax default: "true"

package_group एट्रिब्यूट packages में, सभी पैकेज या किसी भी पैकेज को रेफ़र करने के लिए, "public" या "private" लिखने की अनुमति देता है.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_resolve_select_keys_eagerly डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो .bzl फ़ाइलों में select() को पास की गई डिक्शनरी में मौजूद स्ट्रिंग कुंजियों को तुरंत फ़ाइल के हिसाब से लेबल में बदल दिया जाता है. ऐसा इसलिए किया जाता है, ताकि उन्हें BUILD फ़ाइल के हिसाब से न समझा जाए.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_run_shell_command_string default: "true"

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

टैग: build_file_semantics, incompatible_change

--[no]incompatible_simplify_unconditional_selects_in_rule_attrs default: "true"

अगर यह वैल्यू सही है, तो कॉन्फ़िगर किए जा सकने वाले उन एट्रिब्यूट के नियमों को आसान बनाएं जिनमें सिर्फ़ बिना शर्त वाले विकल्प शामिल हैं. उदाहरण के लिए, अगर किसी नियम के एट्रिब्यूट को ["a"] + select("//conditions:default", ["b"]) असाइन किया जाता है, तो इसे ["a", "b"] के तौर पर सेव किया जाता है. इस विकल्प से, सिंबॉलिक मैक्रो या एट्रिब्यूट की डिफ़ॉल्ट वैल्यू के एट्रिब्यूट पर कोई असर नहीं पड़ता.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_stop_exporting_build_file_path डिफ़ॉल्ट: "false"

अगर इसे 'सही है' पर सेट किया जाता है, तो ctx.build_file_path उपलब्ध नहीं होगा. इसके बजाय, ctx.label.package + '/BUILD' का इस्तेमाल किया जा सकता है.

टैग: loading_and_analysis, incompatible_change

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

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

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_unambiguous_label_stringification default: "true"

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

टैग: loading_and_analysis, incompatible_change

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

इस विकल्प को सही पर सेट करने पर, Bazel @bazel_tools से cc_configure का इस्तेमाल करने की अनुमति नहीं देगा. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, कृपया https://github.com/bazelbuild/bazel/issues/10134 देखें.

टैग: loading_and_analysis, incompatible_change

--max_computation_steps=<a long integer> default: "0"

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

टैग: build_file_semantics

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

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

टैग: loading_and_analysis

--repositories_without_autoloads=<comma-separated set of options> default: ""

अतिरिक्त रिपॉज़िटरी की सूची (Bazel को पहले से पता है कि किन रिपॉज़िटरी में ऑटोलोड नहीं जोड़े जाने हैं). इसमें आम तौर पर ऐसी रिपॉज़िटरी शामिल होनी चाहिए जिन पर ऐसी रिपॉज़िटरी निर्भर करती है जो अपने-आप लोड हो सकती है. इसलिए, इससे साइकल बन सकता है.

टैग: loses_incremental_state, build_file_semantics, incompatible_change

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

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

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

टैग: loading_and_analysis

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

Bazel मॉड्यूल के Bazel वर्शन के साथ काम करने की क्षमता की जांच करें. मान्य वैल्यू ये हैं: error, ताकि इसे समाधान न हो पाने की समस्या के तौर पर बढ़ाया जा सके; off, ताकि जांच बंद की जा सके; या warning, ताकि मेल न खाने पर चेतावनी प्रिंट की जा सके.

टैग: loading_and_analysis

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

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

टैग: loading_and_analysis

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

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

टैग: loading_and_analysis

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

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

टैग: loading_and_analysis

--module_mirrors=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो

इस विकल्प का इस्तेमाल करके, उन यूआरएल के बारे में बताया जाता है जहां Bazel मॉड्यूल के सोर्स यूआरएल मिल सकते हैं. ये यूआरएल, रजिस्ट्री के दिए गए मिरर यूआरएल के अलावा होते हैं और इन्हें प्राथमिकता दी जाती है.इस फ़्लैग को हर रजिस्ट्री के लिए, --module_mirrors=<registry>=<mirror1>[,<mirror2>,...] सिंटैक्स का इस्तेमाल करके सेट किया जा सकता है. उदाहरण के लिए, --module_mirrors=https://bcr.bazel.build=https://mirror.example.com. इसे मिरर यूआरएल की कॉमा लगाकर अलग की गई सूची के तौर पर भी सेट किया जा सकता है.यह सूची उन सभी रजिस्ट्री पर लागू होती है जिनके पास कोई सूची नहीं है. उदाहरण के लिए, --module_mirrors=https://mirror1,https://mirror2. रजिस्ट्री की ओर से तय किए गए मिरर यूआरएल का इस्तेमाल बंद करने के लिए, इसे खाली वैल्यू पर सेट करें. इस फ़्लैग का बाद में इस्तेमाल करने पर, पहले इस्तेमाल किए गए फ़्लैग की सेटिंग बदल जाती है. ऐसा तब होता है, जब दोनों फ़्लैग के लिए एक ही रजिस्ट्री का इस्तेमाल किया गया हो या किसी भी रजिस्ट्री का इस्तेमाल न किया गया हो. समय के साथ, मिरर के डिफ़ॉल्ट सेट में बदलाव हो सकता है. हालांकि, मिरर से किए गए सभी डाउनलोड की पुष्टि, रजिस्ट्री में सेव किए गए हैश से की जाती है. इसलिए, इन्हें लॉकफ़ाइल से पिन किया जाता है.

टैग: loading_and_analysis

--override_module=<an equals-separated mapping of module name to path> कई बार इस्तेमाल किया गया हो

{module name}={path} के तौर पर लोकल पाथ का इस्तेमाल करके, किसी मॉड्यूल को बदलें. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ %workspace% से शुरू होता है, तो यह Workspace के रूट के हिसाब से होता है. Workspace का रूट, bazel info workspace का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पिछले सभी ओवरराइड हटा दें.

--registry=<a string> कई बार इस्तेमाल किया गया हो

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

टैग: changes_inputs

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

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

टैग: loading_and_analysis

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

--gc_thrashing_limits=<comma separated pairs of <period>:<count>> default: "1s:2,20s:3,1m:5"

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

टैग: host_machine_resource_optimizations

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

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो Blaze, FileState और DirectoryListingState नोड को हटा देगा. ऐसा, मेमोरी बचाने के लिए किया जाएगा. इसके बाद, File और DirectoryListing नोड को पूरा कर दिया जाएगा. हमें उम्मीद है कि इन नोड की ज़रूरत दोबारा नहीं पड़ेगी. अगर ऐसा होता है, तो प्रोग्राम उनकी फिर से समीक्षा करेगा.

टैग: loses_incremental_state

--[no]incompatible_do_not_split_linking_cmdline default: "true"

इस विकल्प को सही पर सेट करने पर, Bazel लिंकिंग के लिए इस्तेमाल किए गए कमांड लाइन फ़्लैग में बदलाव नहीं करता. साथ ही, यह भी तय नहीं करता कि कौनसे फ़्लैग पैरामीटर फ़ाइल में जाएंगे और कौनसे नहीं. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7670 पर जाएं.

टैग: loading_and_analysis, incompatible_change

--[no]keep_state_after_build default: "true"

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

टैग: loses_incremental_state

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

Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट किए गए थ्रेशोल्ड से ज़्यादा है, तो फ़ुल जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट वैल्यू 10 होती है. शून्य का मतलब है कि फ़ुल GC इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो फ़ुल GC इवेंट होने पर Skyframe की स्थिति को अब नहीं हटाया जाएगा. साथ ही, बनाए रखी गई ढेर मेमोरी के थ्रेशोल्ड का प्रतिशत भी इससे ज़्यादा नहीं होगा.

टैग: host_machine_resource_optimizations

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

Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि बनाए रखा गया हीप मेमोरी का इस्तेमाल, --skyframe_high_water_mark_threshold से सेट की गई सीमा से ज़्यादा है, तो माइनर जीसी इवेंट होने पर, यह गैर-ज़रूरी अस्थायी Skyframe स्टेट को हटा देगा. ऐसा हर बार ज़्यादा से ज़्यादा इतनी बार किया जाएगा. डिफ़ॉल्ट वैल्यू 10 होती है. शून्य का मतलब है कि माइनर जीसी इवेंट कभी भी ड्रॉप को ट्रिगर नहीं करेंगे. अगर सीमा पूरी हो जाती है, तो माइनर जीसी इवेंट होने पर Skyframe की स्थिति अब नहीं बदलेगी. साथ ही, बनाए रखे गए हीप के प्रतिशत का थ्रेशोल्ड भी पार नहीं किया जाएगा.

टैग: host_machine_resource_optimizations

--skyframe_high_water_mark_threshold=<an integer> default: "85"

Bazel के इंटरनल Skyframe इंजन के ऐडवांस कॉन्फ़िगरेशन के लिए फ़्लैग. अगर Bazel को पता चलता है कि इस्तेमाल किया गया हीप का प्रतिशत कम से कम इस थ्रेशोल्ड पर है, तो वह Skyframe की गैर-ज़रूरी अस्थायी स्थिति को हटा देगा. इसमें बदलाव करने से, GC थ्रैशिंग की वजह से लगने वाले समय पर असर पड़ सकता है. ऐसा तब होता है, जब GC थ्रैशिंग (i) इस अस्थायी स्थिति में मेमोरी के इस्तेमाल की वजह से होती है और (ii) जब इसकी ज़रूरत होती है, तब स्थिति को फिर से बनाने की तुलना में ज़्यादा महंगा होता है.

टैग: host_machine_resource_optimizations

--[no]track_incremental_state default: "true"

अगर यह विकल्प 'गलत है' पर सेट है, तो Blaze ऐसे डेटा को सेव नहीं करेगा जिससे इंक्रीमेंटल बिल्ड पर अमान्य करने और फिर से आकलन करने की अनुमति मिलती है. ऐसा इसलिए किया जाता है, ताकि इस बिल्ड पर मेमोरी को बचाया जा सके. इसके बाद के बिल्ड में, इस बिल्ड के मुकाबले कोई बढ़ोतरी नहीं होगी. आम तौर पर, इस विकल्प को false पर सेट करते समय --batch को सेट करना होता है.

टैग: loses_incremental_state

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

--[no]announce_rc डिफ़ॉल्ट: "false"

rc विकल्पों का एलान करना है या नहीं.

टैग: affects_outputs

--[no]attempt_to_print_relative_paths डिफ़ॉल्ट: "false"

मैसेज के लोकेशन वाले हिस्से को प्रिंट करते समय, वर्कस्पेस डायरेक्ट्री या --package_path से तय की गई डायरेक्ट्री में से किसी एक के हिसाब से पाथ का इस्तेमाल करने की कोशिश करें.

टैग: terminal_output

--bes_backend=<a string> default: ""

यह [SCHEME://]HOST[:PORT] के तौर पर, बिल्ड इवेंट सर्विस (बीईएस) के बैकएंड एंडपॉइंट के बारे में बताता है. डिफ़ॉल्ट रूप से, BES पर अपलोड करने की सुविधा बंद होती है. इसके साथ काम करने वाले स्कीमा grpc और grpcs (टीएलएस की सुविधा के साथ grpc) हैं. अगर कोई स्कीम नहीं दी गई है, तो Bazel grpcs को डिफ़ॉल्ट स्कीम मान लेता है.

टैग: affects_outputs

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

यह check_preceding_lifecycle_events_present फ़ील्ड को PublishBuildToolEventStreamRequest पर सेट करता है. इससे BES को यह पता चलता है कि क्या उसे पहले InvocationAttemptStarted और BuildEnqueued इवेंट मिले थे जो मौजूदा टूल इवेंट से मेल खाते हैं.

टैग: affects_outputs

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

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

टैग: affects_outputs

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

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

टैग: affects_outputs

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

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

टैग: affects_outputs

--[no]bes_lifecycle_events default: "true"

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

टैग: affects_outputs

--bes_oom_finish_upload_timeout=<An immutable length of time.> default: "10m"

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

टैग: bazel_monitoring

--bes_outerr_buffer_size=<an integer> default: "10240"

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

टैग: affects_outputs

--bes_outerr_chunk_size=<an integer> default: "1048576"

इससे यह तय होता है कि एक मैसेज में, stdout या stderr का ज़्यादा से ज़्यादा कितना साइज़ BEP को भेजा जा सकता है.

टैग: affects_outputs

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

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

--bes_results_url=<a string> default: ""

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

टैग: terminal_output

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

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

टैग: affects_outputs

--bes_timeout=<An immutable length of time.> default: "0s"

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

टैग: affects_outputs

--bes_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> default: "wait_for_upload_complete"

इससे यह तय होता है कि Build Event Service के अपलोड होने से, बिल्ड पूरा होने में रुकावट आनी चाहिए या नहीं. इसके अलावा, इससे यह भी तय होता है कि अपलोड होने की प्रोसेस तुरंत बंद हो जानी चाहिए और बैकग्राउंड में अपलोड पूरा होना चाहिए या नहीं.

• wait_for_upload_complete: यह मौजूदा इनवोकेशन के खत्म होने तक ब्लॉक करता है. ऐसा तब तक होता है, जब तक सभी इवेंट (अगर लागू हो, तो लाइफ़साइकल इवेंट भी शामिल हैं) अपलोड नहीं हो जाते और बैकएंड से उनकी पुष्टि नहीं हो जाती.
• nowait_for_upload_complete: यह अगले इनवोकेशन की शुरुआत में ब्लॉक करता है. ऐसा तब तक होता है, जब तक सभी इवेंट (अगर लागू हो, तो लाइफ़साइकल इवेंट भी शामिल हैं) अपलोड नहीं हो जाते और बैकएंड से उनकी पुष्टि नहीं हो जाती.
• fully_async: यह अगले इनवोकेशन की शुरुआत में तब तक ब्लॉक करता है, जब तक सभी इवेंट अपलोड नहीं हो जाते. हालांकि, यह पुष्टि होने का इंतज़ार नहीं करता. ऐसा हो सकता है कि कुछ समय के लिए होने वाली गड़बड़ियों की वजह से इवेंट का डेटा न मिले. साथ ही, बैकएंड इस मोड में स्ट्रीम को अधूरा बता सकते हैं. इस बात की कोई गारंटी नहीं है कि FinishInvocationAttempt या FinishBuild लाइफ़साइकल इवेंट भेजे जाएंगे.

टैग: eagerness_to_exit

--build_event_binary_file=<a string> default: ""

अगर यह फ़ाइल खाली नहीं है, तो build event protocol के वैरिएंट को उस फ़ाइल में लिखें. इस विकल्प का मतलब है कि --bes_upload_mode=wait_for_upload_complete.

टैग: affects_outputs

--[no]build_event_binary_file_path_conversion default: "true"

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

टैग: affects_outputs

--build_event_binary_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> default: "wait_for_upload_complete"

इससे यह तय होता है कि --build_event_binary_file के लिए Build Event Service का अपलोड, बिल्ड पूरा होने को ब्लॉक करेगा या कॉल को तुरंत खत्म कर देगा और बैकग्राउंड में अपलोड पूरा करेगा. wait_for_upload_complete (डिफ़ॉल्ट), nowait_for_upload_complete या fully_async में से कोई एक.

टैग: eagerness_to_exit

--build_event_json_file=<a string> default: ""

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

टैग: affects_outputs

--[no]build_event_json_file_path_conversion default: "true"

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

टैग: affects_outputs

--build_event_json_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> default: "wait_for_upload_complete"

इससे यह तय होता है कि --build_event_json_file के लिए Build Event Service का अपलोड, बिल्ड पूरा होने को ब्लॉक करेगा या कॉल को तुरंत खत्म कर देगा और बैकग्राउंड में अपलोड पूरा करेगा. wait_for_upload_complete (डिफ़ॉल्ट), nowait_for_upload_complete या fully_async में से कोई एक.

टैग: eagerness_to_exit

--build_event_max_named_set_of_file_entries=<an integer> default: "5000"

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

टैग: affects_outputs

--[no]build_event_publish_all_actions डिफ़ॉल्ट: "false"

क्या सभी कार्रवाइयों को पब्लिश किया जाना चाहिए.

टैग: affects_outputs

--build_event_text_file=<a string> default: ""

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

टैग: affects_outputs

--[no]build_event_text_file_path_conversion default: "true"

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

टैग: affects_outputs

--build_event_text_file_upload_mode=<wait_for_upload_complete, nowait_for_upload_complete or fully_async> default: "wait_for_upload_complete"

इससे यह तय होता है कि --build_event_text_file के लिए Build Event Service का अपलोड, बिल्ड पूरा होने को ब्लॉक करेगा या कॉल को तुरंत खत्म कर देगा और बैकग्राउंड में अपलोड पूरा करेगा. wait_for_upload_complete (डिफ़ॉल्ट), nowait_for_upload_complete या fully_async में से कोई एक.

टैग: eagerness_to_exit

--build_event_upload_max_retries=<an integer> default: "4"

Bazel को, बिल्ड इवेंट को अपलोड करने की कोशिश ज़्यादा से ज़्यादा कितनी बार करनी चाहिए.

टैग: bazel_internal_configuration

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

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

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

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

टैग: affects_outputs

--experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both> कई बार इस्तेमाल किया गया हो

यह तय करें कि आउटपुट ग्रुप की फ़ाइलों को TargetComplete/AspectComplete बीईपी इवेंट में कैसे दिखाया जाएगा. वैल्यू, आउटपुट ग्रुप के नाम को NAMED_SET_OF_FILES_ONLY, INLINE_ONLY या BOTH में से किसी एक को असाइन की जाती है. डिफ़ॉल्ट वैल्यू NAMED_SET_OF_FILES_ONLY है. अगर किसी आउटपुट ग्रुप को दोहराया जाता है, तो दिखने वाली फ़ाइनल वैल्यू का इस्तेमाल किया जाता है. डिफ़ॉल्ट वैल्यू, कवरेज आर्टफ़ैक्ट के लिए मोड को BOTH पर सेट करती है: --experimental_build_event_output_group_mode=baseline.lcov=both

टैग: affects_outputs

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> default: "1s"

बीईपी अपलोड करने में गड़बड़ी होने पर, एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने के लिए, शुरुआती और कम से कम देरी. (exponent: 1.6)

टैग: bazel_internal_configuration

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

यह विकल्प चुनता है कि बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को कैसे अपलोड किया जाए. Bazel में, मान्य विकल्पों में local और remote शामिल हैं. डिफ़ॉल्ट वैल्यू local है.

टैग: affects_outputs

--[no]experimental_collect_load_average_in_profiler default: "true"

अगर यह सुविधा चालू है, तो प्रोफ़ाइलर, सिस्टम के कुल लोड का औसत इकट्ठा करता है.

टैग: bazel_monitoring

--[no]experimental_collect_pressure_stall_indicators डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो प्रोफ़ाइलर Linux PSI डेटा इकट्ठा करता है.

टैग: bazel_monitoring

--[no]experimental_collect_resource_estimation डिफ़ॉल्ट: "false"

इस विकल्प को चालू करने पर, प्रोफ़ाइलर, स्थानीय कार्रवाइयों के लिए सीपीयू और मेमोरी के इस्तेमाल का अनुमान इकट्ठा करता है.

टैग: bazel_monitoring

--[no]experimental_collect_skyframe_counts_in_profiler डिफ़ॉल्ट: "false"

इस विकल्प को चालू करने पर, प्रोफ़ाइलर समय के साथ Skyframe ग्राफ़ में SkyFunction की संख्या इकट्ठा करता है. यह संख्या, कॉन्फ़िगर किए गए टारगेट और कार्रवाई के एक्ज़ीक्यूशन जैसे मुख्य फ़ंक्शन टाइप के लिए होती है. इससे परफ़ॉर्मेंस पर असर पड़ सकता है, क्योंकि यह हर प्रोफ़ाइलिंग टाइम यूनिट पर पूरे Skyframe ग्राफ़ पर जाता है. परफ़ॉर्मेंस के लिए ज़रूरी मेज़रमेंट के साथ इस फ़्लैग का इस्तेमाल न करें.

टैग: bazel_monitoring

--[no]experimental_collect_system_network_usage default: "true"

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

टैग: bazel_monitoring

--[no]experimental_collect_worker_data_in_profiler default: "true"

चालू होने पर, प्रोफ़ाइलर वर्कर के एग्रीगेट किए गए संसाधन डेटा को इकट्ठा करता है.

टैग: bazel_monitoring

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

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

--experimental_profile_additional_tasks=<phase, action, discover_inputs, action_check, action_lock, action_update, action_complete, action_rewinding, bzlmod, info, create_package, remote_execution, local_execution, scanner, local_parse, upload_time, remote_process_time, remote_queue, remote_setup, fetch, local_process_time, vfs_stat, vfs_dir, vfs_readlink, vfs_md5, vfs_xattr, vfs_delete, vfs_open, vfs_read, vfs_write, vfs_glob, vfs_vmfs_stat, vfs_vmfs_dir, vfs_vmfs_read, wait, thread_name, thread_sort_index, skyframe_eval, skyfunction, critical_path, critical_path_component, handle_gc_notification, local_action_counts, starlark_parser, starlark_user_fn, starlark_builtin_fn, starlark_user_compiled_fn, starlark_repository_fn, starlark_thread_context, 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, conflict_check, dynamic_lock, repository_fetch, repository_vendor, repo_cache_gc_wait, spawn_log, rpc, skycache, wasm_load, wasm_exec or unknown> कई बार इस्तेमाल किया गया हो

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

टैग: bazel_monitoring

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

कार्रवाई के इवेंट में "out" एट्रिब्यूट शामिल करता है. इसमें कार्रवाई के मुख्य आउटपुट का एक्ज़ेक पाथ होता है.

टैग: bazel_monitoring

--[no]experimental_profile_include_target_configuration डिफ़ॉल्ट: "false"

इसमें कार्रवाई के इवेंट के JSON प्रोफ़ाइल डेटा में टारगेट कॉन्फ़िगरेशन हैश शामिल होता है.

टैग: bazel_monitoring

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

इसमें कार्रवाई के इवेंट के JSON प्रोफ़ाइल डेटा में टारगेट लेबल शामिल होता है.

टैग: bazel_monitoring

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

यह BEP ActionSummary और BuildGraphMetrics के आउटपुट को कंट्रोल करता है. साथ ही, ActionData में मौजूद निमोनिक की संख्या और BuildGraphMetrics.AspectCount/RuleClassCount में रिपोर्ट की गई एंट्री की संख्या को सीमित करता है. डिफ़ॉल्ट रूप से, टाइप की संख्या को टॉप 20 तक सीमित किया जाता है. यह संख्या, ActionData के लिए की गई कार्रवाइयों की संख्या और RuleClass और Asepcts के लिए इंस्टेंस की संख्या के हिसाब से तय की जाती है. इस विकल्प को सेट करने पर, सभी निमोनिक, नियम क्लास, और पहलुओं के लिए आंकड़े लिखे जाएंगे.

--[no]experimental_record_skyframe_metrics डिफ़ॉल्ट: "false"

यह BEP BuildGraphMetrics के आउटपुट को कंट्रोल करता है. इसमें Skykeys, RuleClasses, और Aspects के बारे में Skyframe मेट्रिक को कंप्यूट करने में लगने वाला समय शामिल है. इस फ़्लैग को false पर सेट करने पर, BEP में BuildGraphMetrics.rule_count और aspectfields नहीं भरे जाएंगे.

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

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

टैग: affects_outputs

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

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

टैग: affects_outputs

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

Workspace Rules के कुछ इवेंट को इस फ़ाइल में, WorkspaceEvent protos के तौर पर लॉग करें.

--[no]generate_json_trace_profile default: "auto"

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

टैग: bazel_monitoring

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

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

टैग: bazel_monitoring

--jvm_heap_histogram_internal_object_pattern=<a valid Java regular expression> डिफ़ॉल्ट: "jdk\.internal\.vm\.Filler.+"

JDK21+ JVM हीप मेमोरी कलेक्शन के लिए, मैचिंग लॉजिक को बदलने वाला रेगुलर एक्सप्रेशन. हम मेमोरी के इस्तेमाल से जुड़ी सटीक मेट्रिक पाने के लिए, G1 GC के इंटरनल इंप्लीमेंटेशन की ऐसी जानकारी पर भरोसा कर रहे हैं जो समय के साथ बदलती रहती है. इस विकल्प की मदद से, हम इंटरनल इंप्लीमेंटेशन में होने वाले बदलावों के हिसाब से खुद को ढाल सकते हैं. इसके लिए, हमें बाइनरी रिलीज़ का इंतज़ार नहीं करना पड़ता. Passed to JDK Matcher.find()

--[no]legacy_important_outputs डिफ़ॉल्ट: "false"

इसका इस्तेमाल, TargetComplete इवेंट में लेगसी important_outputs फ़ील्ड को जनरेट होने से रोकने के लिए करें. important_outputs, Bazel को ResultStore/BTX के साथ इंटिग्रेट करने के लिए ज़रूरी हैं.

टैग: affects_outputs

--logging=<0 <= an integer <= 6> default: "3"

लॉगिंग लेवल.

टैग: affects_outputs

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

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

टैग: bazel_monitoring

--memory_profile_stable_heap_parameters=<integers, separated by a comma expected in pairs> default: "1,0"

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

टैग: bazel_monitoring

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

अगर यह विकल्प सेट है, तो Bazel की प्रोफ़ाइल बनाएं और डेटा को तय की गई फ़ाइल में लिखें. ज़्यादा जानकारी के लिए, https://bazel.build/advanced/performance/json-trace-profile देखें.

टैग: bazel_monitoring

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

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

टैग: bazel_monitoring

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

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

टैग: bazel_monitoring

--[no]redirect_local_instrumentation_output_writes डिफ़ॉल्ट: "false"

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

टैग: bazel_monitoring

--remote_print_execution_messages=<failure, success or all> default: "failure"

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

टैग: terminal_output

--[no]slim_profile default: "true"

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

टैग: bazel_monitoring

--starlark_cpu_profile=<a string> default: ""

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

टैग: bazel_monitoring

--tool_tag=<a string> default: ""

टूल का नाम, जिससे इस Bazel इनवोकेशन को एट्रिब्यूट किया जा सके.

टैग: affects_outputs, bazel_monitoring

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

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

टैग: terminal_output

--[no]write_command_log डिफ़ॉल्ट: "false"

command.log फ़ाइल लिखी जाए या नहीं

टैग: bazel_monitoring

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

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

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

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

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

टैग: execution

--[no]experimental_remote_cache_chunking डिफ़ॉल्ट: "false"

यह सुविधा चालू होने पर, बड़े ब्लब को FastCDC 2020 का इस्तेमाल करके, कॉन्टेंट के हिसाब से तय किए गए हिस्सों में बांटा जाता है. इसके बाद, इन हिस्सों को अपलोड/डाउनलोड किया जाता है. इससे सभी ब्लब में डुप्लीकेट डेटा को हटाने में मदद मिलती है. सर्वर को अपनी क्षमताओं में SplitBlob/SpliceBlob RPC और FastCDC 2020 पैरामीटर के बारे में बताना होगा.

टैग: experimental

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

zstd का इस्तेमाल करके कंप्रेस/डीकंप्रेस करने के लिए, कम से कम ब्लोब साइज़ ज़रूरी है. जब तक --remote_cache_compression सेट नहीं किया जाता, तब तक यह विकल्प काम नहीं करता.

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

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

--experimental_remote_cache_ttl=<An immutable length of time.> default: "3h"

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

टैग: execution

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

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

--[no]experimental_remote_discard_merkle_trees default: "true"

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

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

रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाना है. grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. इस लिंक पर जानकारी पाएं: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

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

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

--[no]experimental_remote_downloader_propagate_credentials डिफ़ॉल्ट: "false"

यह तय करता है कि netrc और क्रेडेंशियल हेल्पर से क्रेडेंशियल को रिमोट डाउनलोडर सर्वर पर भेजना है या नहीं. सर्वर पर लागू करने के लिए, नए http_header_url:<url-index>:<header-key> क्वालिफ़ायर का इस्तेमाल किया जाना चाहिए. इसमें <url-index>, FetchBlobRequest के uris फ़ील्ड में मौजूद यूआरएल की 0 से शुरू होने वाली पोज़िशन होती है. यूआरएल के हिसाब से तय किए गए हेडर को ग्लोबल हेडर से ज़्यादा प्राथमिकता दी जानी चाहिए.

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

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

टैग: execution

--experimental_remote_failure_window_interval=<An immutable length of time.> default: "60s"

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

टैग: execution

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

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

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

रिमोट आउटपुट सेवा के एंडपॉइंट का HOST या HOST:PORT. grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS बंद करने के लिए, grpc:// या unix: स्कीमा तय करें.

--experimental_remote_output_service_output_path_prefix=<a string> default: ""

यह वह पाथ है जिसके तहत, --experimental_remote_output_service मैनेज की गई आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. बिल्ड के लिए इस्तेमाल की जाने वाली आउटपुट डायरेक्ट्री, इस पाथ की डिसेंडेंट होगी. साथ ही, इसे आउटपुट सेवा तय करेगी.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "false"

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

--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: ब्यौरा देखें

यह विकल्प, दी गई कॉन्फ़िगरेशन फ़ाइल की मदद से, रिमोट कैश कुंजी को मिटाने की सुविधा चालू करता है. यह फ़ाइल, टेक्स्ट फ़ॉर्मैट में प्रोटोकॉल बफ़र होनी चाहिए. इसके बारे में ज़्यादा जानने के लिए, src/main/protobuf/remote_scrubbing.proto देखें.

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

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

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

इस सुविधा का इस्तेमाल करने के लिए, आपको --experimental_platform_in_output_dir के साथ --host_platform को कस्टम तौर पर सेट करना होगा, ताकि आउटपुट प्रीफ़िक्स को सामान्य किया जा सके.

--[no]guard_against_concurrent_changes default: "lite"

इसे 'full' पर सेट करें, ताकि रिमोट कैश में अपलोड करने से पहले, किसी कार्रवाई की सभी इनपुट फ़ाइलों के ctime की जांच की जा सके. ऐसा हो सकता है कि कुछ मामलों में Linux कर्नल, फ़ाइलों को लिखने में देरी करे. इससे फ़ॉल्स पॉज़िटिव मिल सकते हैं. डिफ़ॉल्ट रूप से, यह 'lite' पर सेट होता है. यह सिर्फ़ मुख्य रिपॉज़िटरी में मौजूद सोर्स फ़ाइलों की जांच करता है. इसे 'बंद है' पर सेट करने से, सभी जांच बंद हो जाती हैं. हमारा सुझाव है कि ऐसा न करें. ऐसा इसलिए, क्योंकि जब किसी सोर्स फ़ाइल में बदलाव किया जाता है, तब हो सकता है कि कैश मेमोरी में मौजूद डेटा खराब हो जाए. ऐसा तब होता है, जब कोई ऐसी कार्रवाई चल रही हो जिसमें उस फ़ाइल का इस्तेमाल इनपुट के तौर पर किया जा रहा हो.

टैग: execution

--[no]incompatible_remote_local_fallback_for_remote_cache डिफ़ॉल्ट: "false"

क्या --remote_local_fallback, --remote_cache पर लागू होता है.

--[no]remote_accept_cached default: "true"

दूर से कैश मेमोरी में सेव किए गए कार्रवाई के नतीजों को स्वीकार करना है या नहीं.

--remote_build_event_upload=<all or minimal> default: "minimal"

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

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

होस्टनेम और इंस्टेंस का नाम, जिसका इस्तेमाल उन bytestream:// यूआरआई में किया जाना है जिन्हें बिल्ड इवेंट स्ट्रीम में लिखा जाता है. इस विकल्प को तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इससे --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इसे सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.

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

कैशिंग एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. टीएलएस को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://bazel.build/remote/caching पर जाएं

--[no]remote_cache_async default: "true"

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

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

अगर यह विकल्प चालू है, तो कैश मेमोरी में सेव किए गए बड़े डेटा को zstd की मदद से कंप्रेस/डिकंप्रेस करें. ऐसा तब करें, जब उनका साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.

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

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

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

डिफ़ॉल्ट exec प्रॉपर्टी सेट करें, ताकि उन्हें रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल किया जा सके. ऐसा तब किया जाता है, जब एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट न करता हो.

टैग: affects_outputs

--remote_download_regex=<a valid Java regular expression> कई बार इस्तेमाल किया गया हो

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

टैग: affects_outputs

--remote_downloader_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--remote_exec_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--remote_execution_priority=<an integer> default: "0"

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

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

रिमोट एक्ज़ीक्यूशन एंडपॉइंट का HOST या HOST:PORT. grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS बंद करने के लिए, grpc:// या unix: स्कीमा तय करें.

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

अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में, क्रम से लगाए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry प्रोटोबफ़ होते हैं. हर मैसेज के पहले एक वैरिएंट होता है, जो क्रम से लगाए गए अगले प्रोटोबफ़ मैसेज के साइज़ को दिखाता है. ऐसा LogEntry.writeDelimitedTo(OutputStream) तरीके से किया जाता है.

--remote_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--remote_instance_name=<a string> default: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "false"

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

--remote_local_fallback_strategy=<a string> default: "local"

समर्थन नहीं होना या रुकना. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

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

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

टैग: host_machine_resource_optimizations

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

रिमोट कैश/एक्ज़ीक्यूटर से एक साथ कनेक्ट किए जा सकने वाले कनेक्शन की ज़्यादा से ज़्यादा संख्या को सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एक्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर 100 से ज़्यादा एक साथ किए गए अनुरोधों को हैंडल कर सकता है. इसे --remote_max_concurrency_per_connection कंट्रोल करता है. इसलिए, Bazel एक साथ करीब --remote_max_connections * 100 अनुरोध कर सकता है.

टैग: host_machine_resource_optimizations

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

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

--remote_result_cache_priority=<an integer> default: "0"

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

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

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

--remote_retry_max_delay=<An immutable length of time.> default: "5s"

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

--remote_timeout=<An immutable length of time.> default: "60s"

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

--[no]remote_upload_local_results default: "true"

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

--[no]remote_verify_downloads default: "true"

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

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

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

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

टैग: terminal_output

--color=<yes, no or auto> default: "auto"

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

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

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

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

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

सहायता करने वाले व्यक्ति के दिए गए क्रेडेंशियल को, --google_default_credentials, --google_credentials, .netrc फ़ाइल या repository_ctx.download() और repository_ctx.download_and_extract() के लिए auth पैरामीटर के ज़रिए दिए गए क्रेडेंशियल से ज़्यादा प्राथमिकता मिलती है.

एक से ज़्यादा हेल्पर सेट अप करने के लिए, इसे कई बार तय किया जा सकता है.

निर्देशों के लिए, Bazel के क्रेडेंशियल हेल्पर को कॉन्फ़िगर करना - Engflow Blog देखें.

--credential_helper_cache_duration=<An immutable length of time.> default: "30m"

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

--credential_helper_timeout=<An immutable length of time.> default: "10s"

यह विकल्प, क्रेडेंशियल हेल्पर के लिए टाइम आउट कॉन्फ़िगर करता है.

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

--curses=<yes, no or auto> default: "auto"

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

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

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

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

अगर यह सही है, तो Bazel, bazelrc फ़ाइलों से होस्ट ओएस के हिसाब से कॉन्फ़िगरेशन लाइनें चुनता है. उदाहरण के लिए, अगर होस्ट ओएस Linux है और आपने bazel build कमांड का इस्तेमाल किया है, तो Bazel, build:linux से शुरू होने वाली लाइनों को चुनता है. इस्तेमाल किए जा सकने वाले ओएस आइडेंटिफ़ायर ये हैं: linux, macos, windows, freebsd, और openbsd. इस फ़्लैग को चालू करने का मतलब है कि Linux पर --config=linux, Windows पर --config=windows वगैरह का इस्तेमाल किया जा रहा है.

--experimental_action_cache_gc_idle_delay=<An immutable length of time.> default: "5m"

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

टैग: host_machine_resource_optimizations

--experimental_action_cache_gc_max_age=<An immutable length of time.> default: "0"

अगर इसे शून्य से अलग वैल्यू पर सेट किया जाता है, तो ऐक्शन कैश को समय-समय पर गार्बेज कलेक्शन किया जाएगा, ताकि इस उम्र से पुरानी एंट्री हटाई जा सकें. सर्वर के निष्क्रिय होने के बाद, बैकग्राउंड में गार्बेज कलेक्शन होता है. सर्वर के निष्क्रिय होने का पता, --experimental_action_cache_gc_idle_delay और --experimental_action_cache_gc_threshold फ़्लैग से चलता है.

टैग: host_machine_resource_optimizations

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

गारबेज कलेक्शन को ट्रिगर करने के लिए, पुरानी ऐक्शन कैश मेमोरी की एंट्री का प्रतिशत ज़रूरी है. जब तक --experimental_action_cache_gc_max_age की वैल्यू शून्य नहीं होती, तब तक यह विकल्प काम नहीं करता.

टैग: host_machine_resource_optimizations

--experimental_disk_cache_gc_idle_delay=<An immutable length of time.> default: "5m"

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

--experimental_disk_cache_gc_max_age=<An immutable length of time.> default: "0"

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

--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier> default: "0"

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

--[no]experimental_enable_thread_dump डिफ़ॉल्ट: "false"

थ्रेड डंप चालू करने हैं या नहीं. अगर यह विकल्प चालू है, तो Bazel सभी थ्रेड (वर्चुअल थ्रेड भी शामिल हैं) की स्थिति को हर --experimental_thread_dump_interval पर एक फ़ाइल में डंप करेगा. इसके अलावा, अगर कार्रवाई --experimental_thread_dump_action_execution_inactivity_duration तक बंद रहती है, तब भी Bazel ऐसा करेगा. डंप, <output_base>/server/thread_dumps/ डायरेक्ट्री में सेव किए जाएंगे.

टैग: bazel_monitoring

--experimental_install_base_gc_max_age=<An immutable length of time.> default: "30d"

इंस्टॉल किए गए ऐप्लिकेशन को कितने समय तक इस्तेमाल न करने पर, उसे ट्रैश में भेजा जा सकता है. अगर यह वैल्यू शून्य नहीं है, तो सर्वर के पास कोई काम न होने पर, वह अन्य इंस्टॉल बेस से गार्बेज इकट्ठा करने की कोशिश करेगा.

टैग: host_machine_resource_optimizations

--[no]experimental_rule_extension_api default: "true"

एक्सपेरिमेंट के तौर पर उपलब्ध, नियम एक्सटेंशन एपीआई और सबनियम एपीआई चालू करें

टैग: loading_and_analysis, experimental

--experimental_thread_dump_action_execution_inactivity_duration=<An immutable length of time.> default: "0"

इस अवधि तक कार्रवाई पूरी न होने पर, थ्रेड डंप करें. अगर यह वैल्यू शून्य है, तो कार्रवाई के बंद होने पर कोई थ्रेड डंप नहीं लिखा जाता.

टैग: bazel_monitoring

--experimental_thread_dump_interval=<An immutable length of time.> default: "0"

थ्रेड को समय-समय पर कितनी बार डंप करना है. अगर इसकी वैल्यू शून्य है, तो थ्रेड डंप को समय-समय पर नहीं लिखा जाता.

टैग: bazel_monitoring

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

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

--google_auth_scopes=<comma-separated list of options> default: "https://www.googleapis.com/auth/cloud-platform"

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

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

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

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

पुष्टि करने के लिए, 'Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल' का इस्तेमाल करना है या नहीं. ज़्यादा जानकारी के लिए, Google पर पुष्टि करने के तरीके - Google Cloud लेख पढ़ें. यह सुविधा डिफ़ॉल्ट रूप से बंद होती है.

--grpc_keepalive_time=<An immutable length of time.> default: "60s"

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

--grpc_keepalive_timeout=<An immutable length of time.> default: "20s"

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

--[no]grpc_tcp_keepalive default: "true"

इससे यह तय किया जाता है कि आउटगोइंग gRPC कनेक्शन के लिए, टीसीपी कीप-अलाइव (SO_KEEPALIVE सॉकेट विकल्प) चालू करना है या नहीं. यह ट्रांसपोर्ट लेयर पर काम करता है. साथ ही, यह --grpc_keepalive_time के साथ कॉन्फ़िगर किए गए ऐप्लिकेशन-लेवल के कीप-अलाइव पिंग से अलग होता है. यह सुविधा चालू होने पर, कीप-अलाइव के व्यवहार को --grpc_tcp_keepalive_time, --grpc_tcp_keepalive_interval, और --grpc_tcp_keepalive_count कंट्रोल करते हैं.

--grpc_tcp_keepalive_count=<an integer> default: "3"

--grpc_tcp_keepalive चालू होने पर, कनेक्शन को बंद माना जाने से पहले, बिना जवाब वाली टीसीपी कीप-अलाइव जांचों की संख्या (TCP_KEEPCNT). अगर टीसीपी कीप-अलाइव सुविधा बंद है, तो इसका कोई असर नहीं होता.

--grpc_tcp_keepalive_interval=<An immutable length of time.> default: "10s"

--grpc_tcp_keepalive चालू होने पर, यह लगातार टीसीपी कीप-अलाइव जांच (TCP_KEEPINTVL) के बीच का समय होता है. अगर टीसीपी कीप-अलाइव सुविधा बंद है, तो इसका कोई असर नहीं होता.

--grpc_tcp_keepalive_time=<An immutable length of time.> default: "60s"

--grpc_tcp_keepalive चालू होने पर, यह gRPC कनेक्शन पर निष्क्रियता की वह अवधि होती है जिसके बाद पहला टीसीपी कीप-अलाइव जांच वाला मैसेज भेजा जाता है (TCP_KEEPIDLE). अगर टीसीपी कीप-अलाइव सुविधा बंद है, तो इसका कोई असर नहीं होता.

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

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

टैग: loading_and_analysis, incompatible_change

--inject_repository=<an equals-separated mapping of repository name to path> कई बार इस्तेमाल किया गया हो

यह {repository name}={path} के तौर पर, लोकल पाथ वाली नई रिपॉज़िटरी जोड़ता है. यह सिर्फ़ --enable_bzlmod के साथ काम करता है. साथ ही, यह use_repo_rule के ज़रिए रूट मॉड्यूल की MODULE.bazel फ़ाइल में, इससे मिलता-जुलता local_repository जोड़ने के बराबर होता है. अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ %workspace% से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, bazel info workspace का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से मौजूद किसी भी इंजेक्शन को हटाएं.

--invocation_id=<a UUID> default: ""

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

टैग: bazel_monitoring, bazel_internal_configuration

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

किसी रिपॉज़िटरी को लोकल पाथ से बदलें. इसके लिए, {repository name}={path} का इस्तेमाल करें. यहां रिपॉज़िटरी का नाम, कैननिकल नाम या मुख्य रिपॉज़िटरी के हिसाब से कोई दूसरा नाम हो सकता है.

ध्यान दें कि अगर इस फ़्लैग का इस्तेमाल किसी मॉड्यूल की रिपॉज़िटरी को ओवरराइड करने के लिए किया जाता है, तो MODULE.bazel फ़ाइल में किए गए बदलाव लागू नहीं होंगे. ऐसा तब होगा, जब मॉड्यूल को किसी रजिस्ट्री से हासिल किया गया हो. इसके बजाय, --override_module का इस्तेमाल करें.

अगर दिया गया पाथ ऐब्सलूट पाथ है, तो इसका इस्तेमाल वैसे ही किया जाएगा. अगर दिया गया पाथ रिलेटिव पाथ है, तो यह मौजूदा वर्किंग डायरेक्ट्री के हिसाब से होगा. अगर दिया गया पाथ %workspace% से शुरू होता है, तो यह वर्कस्पेस के रूट के हिसाब से होता है. वर्कस्पेस का रूट, bazel info workspace का आउटपुट होता है. अगर दिया गया पाथ खाली है, तो पहले से मौजूद किसी भी ओवरराइड को हटाएं.

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

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

--[no]show_progress default: "true"

बिल्ड के दौरान प्रोग्रेस मैसेज दिखाता है.

--show_progress_rate_limit=<a double> default: "0.2"

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

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

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

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

उस टीएलएस सर्टिफ़िकेट का पाथ तय करें जिस पर सर्वर सर्टिफ़िकेट पर हस्ताक्षर करने के लिए भरोसा किया जाता है.

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

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

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

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

--ui_actions_shown=<an integer> default: "8"

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

टैग: terminal_output

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

Linux/macOS पर: अगर यह विकल्प सही है, तो Bazel हर फ़ाइल को स्कैन करने के बजाय, स्थानीय बदलावों के लिए ऑपरेटिंग सिस्टम की फ़ाइल वॉच सेवा का इस्तेमाल करने की कोशिश करता है. Windows पर: फ़िलहाल, यह फ़्लैग काम नहीं करता है. हालांकि, इसे --experimental_windows_watchfs के साथ चालू किया जा सकता है. किसी भी ओएस पर: अगर आपका वर्कस्पेस किसी नेटवर्क फ़ाइल सिस्टम पर है और फ़ाइलों में बदलाव किसी रिमोट मशीन पर किया जाता है, तो यह तय नहीं किया जा सकता कि फ़ाइलें कैसे सेव होंगी.

Aquery के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

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

--aspect_deps=<off, conservative or precise> default: "conservative"

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

टैग: build_file_semantics

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

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

टैग: terminal_output

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

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

टैग: terminal_output

--[no]graph:factored default: "true"

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

टैग: terminal_output

--graph:node_limit=<an integer> default: "512"

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

टैग: terminal_output

--[no]implicit_deps default: "true"

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

टैग: build_file_semantics

--[no]include_artifacts default: "true"

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

टैग: terminal_output

--[no]include_aspects default: "true"

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

टैग: terminal_output

--[no]include_commandline default: "true"

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

टैग: terminal_output

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

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

टैग: terminal_output

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

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

टैग: terminal_output

--[no]include_pruned_inputs default: "true"

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

टैग: terminal_output

--[no]incompatible_package_group_includes_double_slash default: "true"

इस सेटिंग को चालू करने पर, package_group packages एट्रिब्यूट की वैल्यू देते समय, लीडिंग // को नहीं हटाया जाएगा.

टैग: terminal_output, incompatible_change

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

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

टैग: loading_and_analysis

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

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

टैग: terminal_output

--[no]nodep_deps default: "true"

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

टैग: build_file_semantics

--output=<a string> default: "text"

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

टैग: terminal_output

--output_file=<a string> default: ""

इस विकल्प को सेट करने पर, क्वेरी के नतीजे सीधे इस फ़ाइल में लिखे जाएंगे. साथ ही, Bazel के स्टैंडर्ड आउटपुट स्ट्रीम (stdout) में कुछ भी प्रिंट नहीं किया जाएगा. आम तौर पर, बेंचमार्क में यह <code>bazel query > file</code> से ज़्यादा तेज़ होता है.

टैग: terminal_output

--[no]proto:default_values default: "true"

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

टैग: terminal_output

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

definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, हर नियम इंस्टेंस के लिए Starlark कॉल स्टैक को रिकॉर्ड करता है. यह स्टैक, नियम की क्लास को तय किए जाने के समय का होता है.

टैग: terminal_output

--[no]proto:flatten_selects default: "true"

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

टैग: build_file_semantics

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

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

टैग: terminal_output

--[no]proto:include_starlark_rule_env default: "true"

जनरेट किए गए $internal_attr_hash एट्रिब्यूट की वैल्यू में, Starlark एनवायरमेंट का इस्तेमाल करें. इससे यह पक्का होता है कि स्टार्लार्क नियम की परिभाषा (और इसके ट्रांज़िटिव इंपोर्ट) इस आइडेंटिफ़ायर का हिस्सा हैं.

टैग: terminal_output

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

$internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.

टैग: terminal_output

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

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

टैग: terminal_output

--[no]proto:locations default: "true"

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

टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> default: "all"

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

टैग: terminal_output

--[no]proto:rule_classes डिफ़ॉल्ट: "false"

हर नियम के rule_class_key फ़ील्ड में वैल्यू डालें. साथ ही, दिए गए rule_class_key वाले पहले नियम के लिए, उसके rule_class_info proto फ़ील्ड में भी वैल्यू डालें. rule_class_key फ़ील्ड, नियम क्लास की खास तौर पर पहचान करता है. साथ ही, rule_class_info फ़ील्ड, Stardoc फ़ॉर्मैट में नियम क्लास की एपीआई डेफ़िनिशन है.

टैग: terminal_output

--[no]proto:rule_inputs_and_outputs default: "true"

rule_input और rule_output फ़ील्ड में वैल्यू डालनी है या नहीं.

टैग: terminal_output

--query_file=<a string> default: ""

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

टैग: changes_inputs

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

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

टैग: terminal_output

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

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

टैग: terminal_output

--[no]tool_deps default: "true"

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

टैग: build_file_semantics

--universe_scope=<comma-separated list of options> default: ""

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

टैग: loading_and_analysis

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

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false"

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.

टैग: execution, experimental

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट कार्रवाइयों को रिमोट किया जा सकता है या नहीं

टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false"

सही होने पर, Bazel टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.

टैग: execution, experimental

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

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

टैग: execution, experimental

--[no]incompatible_modify_execution_info_additive default: "true"

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

टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

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

कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई के एक्ज़ीक्यूशन की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, और TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि एक ही नेमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.

सिंटैक्स: regex=[+-]key,regex=[+-]key,....

उदाहरण:

• .*=+x,.*=-y,.*=+z सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में x और z जोड़ता है. साथ ही, y को हटाता है.
• Genrule=+requires-x, Genrule की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में requires-x जोड़ता है.
• (?!Genrule).*=-requires-x, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से requires-x हटा देता है.

टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू करें.

बढ़कर:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को लगातार चालू रखें.

बढ़कर:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार कई बार चलाने की सुविधा चालू करें.

बढ़कर:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.

इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (डेक्सिंग, डिसुगरिंग, संसाधन प्रोसेसिंग) चालू करें.

बढ़कर:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

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

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

टैग: execution

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

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

Android टारगेट कंपाइलर.

टैग: affects_outputs, 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> default: ""

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

टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--cc_output_directory_tag=<a string> default: ""

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

टैग: affects_outputs

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

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.

टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger"

उस बाइनरी का पाथ जिसका इस्तेमाल, रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:lcov_merger पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी की जगह. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:coverage_report_generator पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support"

सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, यह //tools/test:coverage_support पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

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

यह विकल्प, malloc को लागू करने का कस्टम तरीका तय करता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.

टैग: changes_inputs, affects_outputs

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "false"

अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.

टैग: loses_incremental_state, loading_and_analysis, execution, experimental

--[no]experimental_prefer_mutual_xcode default: "true"

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

टैग: loses_incremental_state, experimental

--extra_execution_platforms=<comma-separated list of options> default: ""

कार्रवाइयां करने के लिए, इन प्लैटफ़ॉर्म का इस्तेमाल किया जा सकता है. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. register_execution_platforms() की ओर से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद में, फ़्लैग की गई सेटिंग पहले की सेटिंग को बदल देंगी.

टैग: execution

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

टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() की ओर से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले माना जाएगा.

टैग: affects_outputs, changes_inputs, loading_and_analysis

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

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.

टैग: action_command_lines, affects_outputs

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

यह फ़्लैग कोई कार्रवाई नहीं करता. आने वाले समय में इसे हटा दिया जाएगा.

टैग: loading_and_analysis, execution

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

अगर यह सेटिंग तय की जाती है, तो exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.

टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform"

होस्ट सिस्टम की जानकारी देने वाले प्लैटफ़ॉर्म के नियम का लेबल.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_bazel_test_exec_run_under default: "true"

अगर यह सुविधा चालू है, तो bazel test --run_under=//:runner, exec configuration में //:runner बनाता है. अगर यह सुविधा बंद है, तो टारगेट कॉन्फ़िगरेशन में //:runner बनाया जाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे bazel run पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में --run_under=//foo बनाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_builtin_objc_strip_action default: "true"

यह तय करता है कि objc लिंकिंग के हिस्से के तौर पर स्ट्रिप ऐक्शन को चालू करना है या नहीं.

टैग: action_command_lines, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true"

अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाएं चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false"

ऐपल के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive default: "true"

अगर यह विकल्प सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "false"

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

टैग: action_command_lines, incompatible_change

--[no]interface_shared_objects default: "true"

अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल करने की सुविधा है, तो उनका इस्तेमाल करें. फ़िलहाल, सभी 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 main workspace-relative path> default: ""

मैपिंग फ़ाइल की जगह. इससे यह पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो कौनसा प्लैटफ़ॉर्म इस्तेमाल करना है या अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसा फ़्लैग सेट करना है. यह मुख्य वर्कस्पेस रूट से जुड़ा होना चाहिए. डिफ़ॉल्ट रूप से, यह platform_mappings (वर्कस्पेस रूट के ठीक नीचे मौजूद फ़ाइल) पर सेट होता है.

टैग: affects_outputs, changes_inputs, loading_and_analysis, non_configurable

--platforms=<a build target label> default: ""

प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.

टैग: affects_outputs, changes_inputs, loading_and_analysis

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

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains ने बंद कर दिया है.

टैग: loading_and_analysis, affects_outputs

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

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

टैग: loses_incremental_state

--[no]use_platforms_in_apple_crosstool_transition डिफ़ॉल्ट: "false"

इससे apple_crosstool_transition, ज़रूरत पड़ने पर लेगसी --cpu के बजाय --platforms फ़्लैग की वैल्यू का इस्तेमाल करता है.

टैग: loading_and_analysis

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

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

टैग: loses_incremental_state

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

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

टैग: loses_incremental_state

--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes"

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

टैग: loses_incremental_state, loading_and_analysis

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

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

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

टैग: affects_outputs, action_command_lines

--[no]build_runfile_links default: "true"

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

टैग: affects_outputs

--[no]build_runfile_manifests default: "true"

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

टैग: affects_outputs

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

अगर यह सुविधा चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.

टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h"

यह cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc"

यह विकल्प, cc_proto_library से बनाई गई सोर्स फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

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

proto_library में Java api के वैकल्पिक वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.

टैग: affects_outputs, loading_and_analysis, experimental

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

इस कुकी का इस्तेमाल, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को कंपाइल करने के आउटपुट के तौर पर सेव करने के लिए किया जाता है.

टैग: affects_outputs, experimental

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

इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल करने वाले कंपाइलेशन मोड कौनसे हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.

टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम अपनी रनफ़ाइल में DefaultInfo.files डेटा डिपेंडेंसी जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाती है (रनफ़ाइल की ऐसी सुविधाएं जिनका इस्तेमाल नहीं करना चाहिए).

टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest default: "true"

चालू होने पर, {binary}.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन के रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन से जनरेट होने वाले हर रेपो के लिए एक बार दिखाने के बजाय, रनफ़ाइलें योगदान करती हैं.

टैग: affects_outputs, incompatible_change

--incompatible_disable_select_on=<comma-separated set of options> default: ""

उन फ़्लैग की सूची जिनके लिए select() में इस्तेमाल करने की सुविधा बंद है.

टैग: loading_and_analysis, incompatible_change, non_configurable

--[no]incompatible_filegroup_runfiles_for_data default: "true"

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

टैग: incompatible_change

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

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

टैग: affects_outputs

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

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

टैग: affects_outputs

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

--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

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

ध्यान दें कि जब तक --incompatible_repo_env_ignores_action_env सही नहीं होता, तब तक सभी name=value जोड़े, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.

टैग: action_command_lines

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.

टैग: changes_inputs, affects_outputs

--[no]android_databinding_use_androidx default: "true"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args default: "true"

3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> default: "off"

इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तो Android नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical"

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

टैग: action_command_lines, execution

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

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis

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

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

टैग: loses_incremental_state, loading_and_analysis

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

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

टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

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

टैग: affects_outputs, action_command_lines

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

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

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

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

टैग: action_command_lines, affects_outputs

--cpu=<a string> default: ""

बंद कर दिया गया है: Blaze इस फ़्लैग का इस्तेमाल इंटरनल तौर पर नहीं करता है. हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा के लिए, लेगसी प्लैटफ़ॉर्म मैपिंग मौजूद हैं. इस फ़्लैग का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म की सही परिभाषा के साथ --platforms का इस्तेमाल करें.

टैग: changes_inputs, affects_outputs

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

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

टैग: affects_outputs

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

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

टैग: affects_outputs

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

cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.

टैग: affects_outputs

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

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

टैग: action_command_lines, affects_outputs

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

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

टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> default: "default"

इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: loading_and_analysis, affects_outputs

--[no]enable_propeller_optimize_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.

टैग: affects_outputs

--[no]enable_remaining_fdo_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी दिखेगी.

टैग: affects_outputs

--[no]enable_runfiles default: "auto"

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

टैग: affects_outputs

--exec_aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

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

टैग: loading_and_analysis

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

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

टैग: execution, experimental

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

APK में Java संसाधनों को कंप्रेस करना

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 default: "true"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "false"

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis, experimental

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

dex फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करें

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

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

अगर यह विकल्प चुना जाता है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.

टैग: affects_outputs, experimental

--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.

टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "false"

अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.

टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off or strip> default: "off"

आउटपुट ट्री में कहां पर किस मॉडल का इस्तेमाल करना है, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, GH-6526 देखें. Starlark ऐक्शन, execution_requirements डिक्शनरी में supports-path-mapping कुंजी जोड़कर, पाथ मैपिंग की सुविधा के लिए ऑप्ट-इन कर सकते हैं.

टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_platform_cpu_name=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री label=value के फ़ॉर्मैट में होनी चाहिए. इसमें लेबल का मतलब किसी प्लैटफ़ॉर्म से है. साथ ही, वैल्यू वह छोटा नाम है जिसका इस्तेमाल करके, $(TARGET_CPU) मेक वैरिएबल और आउटपुट पाथ में प्लैटफ़ॉर्म के सीपीयू के नाम को बदला जा सकता है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform या --incompatible_bep_cpu_from_platform की वैल्यू 'सही है' पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.

टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir default: "Auto"

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

1. अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है. ऐसा कभी-कभी होता है.
2. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है.
3. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर, छोटा नाम इस्तेमाल करें.
4. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.

टैग: affects_outputs, experimental

--[no]experimental_py_binaries_include_label डिफ़ॉल्ट: "false"

py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.

टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो collect_code_coverage चालू होने पर Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.

टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस अनुमानित तरीके में कुछ कमियां हैं. इसलिए, हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करने के लिए माइग्रेट करें.

टैग: affects_outputs, experimental

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

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

टैग: affects_outputs

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

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है.जैसे, //foo/bar:file.afdo - आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है. साथ ही, यह fdo_profile टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, fdo_profile नियम की जगह लागू होगा.

टैग: affects_outputs

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

कैश मेमोरी में पहले से फ़ेच करने के सुझावों का इस्तेमाल करें.

टैग: affects_outputs

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

fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.

टैग: affects_outputs

--features=<a string> कई बार इस्तेमाल किया गया हो

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं. --host_features भी देखें.

टैग: changes_inputs, affects_outputs

--[no]force_pic डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, पीआईसी प्री-बिल्ट लाइब्रेरी को नॉन-पीआईसी लाइब्रेरी के मुकाबले ज़्यादा प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.

टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

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

टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

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

टैग: affects_outputs, action_command_lines

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

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

टैग: action_command_lines, affects_outputs

--host_copt=<a string> कई बार इस्तेमाल किया गया हो

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

टैग: action_command_lines, affects_outputs

--host_cpu=<a string> default: ""

होस्ट सीपीयू.

टैग: changes_inputs, affects_outputs

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

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

टैग: action_command_lines, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

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

टैग: changes_inputs, affects_outputs

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

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

टैग: action_command_lines, affects_outputs

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

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

टैग: loses_incremental_state

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

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

टैग: action_command_lines, affects_outputs

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

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर toolchain पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, GH-17134 देखें.

टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में शामिल किया जाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_target_cpu_from_platform default: "true"

अगर टारगेट प्लैटफ़ॉर्म के सीपीयू की सीमा (@platforms//cpu:cpu) तय की गई है, तो $(TARGET_CPU) मेक वैरिएबल सेट करने के लिए इसका इस्तेमाल किया जाता है.

टैग: loading_and_analysis, incompatible_change

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

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

टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

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

टैग: affects_outputs

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

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

टैग: loses_incremental_state

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

ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें सभी आर्किटेक्चर शामिल होते हैं.

टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive default: "true"

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

टैग: action_command_lines, affects_outputs, deprecated

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

लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

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

एलटीओ बैकएंड के चरण में पास करने का अतिरिक्त विकल्प (under --features=thin_lto).

टैग: action_command_lines, affects_outputs

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

एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (--features=thin_lto के तहत).

टैग: action_command_lines, affects_outputs

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

Apple macOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

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

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

टैग: loses_incremental_state

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

memprof प्रोफ़ाइल का इस्तेमाल करें.

टैग: affects_outputs

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

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

टैग: action_command_lines

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

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

टैग: action_command_lines

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

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

टैग: action_command_lines

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

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

टैग: action_command_lines, affects_outputs

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

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

टैग: action_command_lines, affects_outputs

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

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

टैग: loses_incremental_state, affects_outputs, loading_and_analysis

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

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller की प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller की प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल के इनपुट फ़ाइलों के बारे में होना चाहिए. उदाहरण के लिए, a/b/BUILD फ़ाइल में लेबल को इस तरह से तय किया गया है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile

टैग: action_command_lines, affects_outputs

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

Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

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

Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

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

test और run कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू foo -bar है और एक्ज़ीक्यूशन कमांड लाइन test_binary -baz है, तो फ़ाइनल कमांड लाइन foo -bar test_binary -baz होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण यहां दिए गए हैं:

• valgrind
• strace
• strace -c
• valgrind --quiet --num-callers=20
• //package:target
• //package:target --options

टैग: action_command_lines

--[no]share_native_deps default: "true"

अगर यह वैल्यू सही है, तो एक जैसी सुविधा वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा

टैग: loading_and_analysis, affects_outputs

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

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

टैग: affects_outputs

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

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

टैग: affects_outputs

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

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

टैग: action_command_lines, affects_outputs

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

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

टैग: loses_incremental_state, loading_and_analysis

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

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

टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple visionOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

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

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

टैग: loses_incremental_state, loading_and_analysis

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

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

टैग: loses_incremental_state

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

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

टैग: affects_outputs

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

--[no]check_visibility default: "true"

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

टैग: build_file_semantics, non_configurable

--[no]desugar_for_android default: "true"

यह तय करता है कि Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

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

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

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints default: "true"

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

टैग: build_file_semantics

--[no]experimental_check_desugar_deps default: "true"

Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.

टैग: eagerness_to_exit, loading_and_analysis, experimental

--[no]experimental_enforce_transitive_visibility डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो package()s को transitive_visibility एट्रिब्यूट सेट करने की अनुमति दें. इससे यह तय किया जा सकेगा कि कौनसे पैकेज उन पर निर्भर हो सकते हैं.

टैग: build_file_semantics, experimental

--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है"

इस विकल्प को चालू करने पर, यह लागू किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल नहीं किए जा सकते. इस नीति के उल्लंघन की वजह से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.

टैग: loading_and_analysis

--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default"

अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "false"

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

टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false"

यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें

टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.

टैग: eagerness_to_exit, incompatible_change

--[no]one_version_enforcement_on_java_tests default: "true"

इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.

टैग: loading_and_analysis

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

--incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).

टैग: loading_and_analysis

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

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

टैग: build_file_semantics, eagerness_to_exit

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

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

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> default: "off"

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

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

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

अगर यह विकल्प चालू है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.

टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

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

--platforms भी देखें.

टैग: 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 default: "true"

अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.

टैग: changes_inputs

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

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

टैग: action_command_lines

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

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

अगर सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "false"

जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.

टैग: loading_and_analysis, incompatible_change

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

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

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

टैग: loading_and_analysis, experimental

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

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

टैग: loading_and_analysis

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

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

टैग: loading_and_analysis, experimental

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. यह {resource}={value} फ़ॉर्मैट में होना चाहिए. अगर {value} के तौर पर कोई पॉज़िटिव नंबर दिया जाता है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगा. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे small, medium, large, enormous के टेस्ट साइज़ के लिए संसाधन की रकम को बदल देंगे. वैल्यू HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]{float} (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). इस फ़्लैग के ज़रिए तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को टैग में तय किए गए संसाधनों से बदल दिया जाता है.

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

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.

टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

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

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

टैग: action_command_lines

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

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

टैग: test_runner

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

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

टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो

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

उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे.

वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू और regex_filter का मतलब, शामिल और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें.

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

--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह विकल्प, टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को name या name=value पेयर के ज़रिए तय किया जा सकता है. अगर name के ज़रिए वैरिएबल तय किया जाता है, तो उसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. पहले से सेट किए गए वैरिएबल को =name की मदद से अनसेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.

टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> default: "-1"

जांच के टाइम आउट के लिए, जांच के टाइम आउट की डिफ़ॉल्ट वैल्यू (सेकंड में) बदलें. अगर कोई एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे short, moderate, long, और eternal के लिए टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 की वैल्यू से Blaze को यह पता चलता है कि उसे उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करना है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "false"

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

टैग: test_runner

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

--[no]cc_dotd_files default: "true"

.d फ़ाइलों को जनरेट और उनका विश्लेषण करना है या नहीं.

टैग: loading_and_analysis, execution, changes_inputs

--[no]cc_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

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

ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद सभी क्लास हट जाएं.

टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files default: "true"

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

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files default: "true"

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

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly default: "true"

इस नीति के चालू होने पर, --trim_test_configuration उन नियमों के लिए टेस्ट कॉन्फ़िगरेशन को नहीं काटेगा जिन्हें testonly=1 के तौर पर मार्क किया गया है. इसका मकसद, कार्रवाई से जुड़ी उन समस्याओं को कम करना है जो तब होती हैं, जब टेस्ट के अलावा अन्य नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.

टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing default: "true"

यह हर जार फ़ाइल के लिए, अलग-अलग डेक्सिंग का ज़्यादातर काम करता है.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning default: "true"

अगर इसे सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को कम करने के लिए किया जाएगा.

टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "false"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग चालू हो.

टैग: execution

--[no]trim_test_configuration default: "true"

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

टैग: loading_and_analysis, loses_incremental_state

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

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*"

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

टैग: terminal_output

--[no]verbose_visibility_errors डिफ़ॉल्ट: "false"

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

टैग: build_file_semantics, non_configurable

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

--flag_alias=<a 'name=label' flag alias> कई बार इस्तेमाल किया गया हो

यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह {key}={value} के फ़ॉर्म में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.

टैग: changes_inputs, non_configurable

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "false"

इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में init.py फ़ाइलें अपने-आप न बन पाएं. जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तब इस फ़्लैग को सेट करने पर ही इसे फ़ॉल्स के तौर पर माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.

टैग: affects_outputs, incompatible_change

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

--[no]cache_test_results [-t] default: "auto"

अगर इसे auto पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब:

1. Bazel, टेस्ट या उसकी डिपेंडेंसी में हुए बदलावों का पता लगाता है,
2. टेस्ट को external के तौर पर मार्क किया गया हो,
3. --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या
4. यह जांच पहले पूरी नहीं हो सकी थी. अगर इसे yes पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें external के तौर पर मार्क नहीं किया गया है. अगर इसे no पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता.

--[no]experimental_cancel_concurrent_tests default: "never"

अगर on_failed या on_passed, तो Blaze उस नतीजे के साथ पहली बार सफल होने पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह नीति सिर्फ़ --runs_per_test_detects_flakes के साथ काम करेगी.

टैग: affects_outputs, loading_and_analysis, experimental

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

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

टैग: affects_outputs, loading_and_analysis, experimental

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

अगर यह विकल्प 'सही है' पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.

टैग: affects_outputs, loading_and_analysis, experimental

--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "bazel"

यह Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ को चालू करता है.

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

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

टैग: affects_outputs, experimental

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

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

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

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

--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो

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

--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो

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

--[no]incompatible_check_sharding_support default: "true"

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

टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed default: "true"

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

टैग: incompatible_change

--[no]incompatible_strict_action_env default: "true"

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

टैग: loading_and_analysis, incompatible_change

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

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

--java_debug

इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार करती है. इसके बाद ही, टेस्ट शुरू होता है. इसका मतलब है कि -test_output=streamed.

बढ़कर:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps default: "true"

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

--[no]java_header_compilation default: "true"

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

--java_language_version=<a string> default: ""

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

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

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

--java_runtime_version=<a string> default: "local_jdk"

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

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

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

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

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

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

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

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

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

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

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

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

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

--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.

टैग: affects_outputs, loading_and_analysis

--[no]proto_profile default: "true"

प्रोटो कंपाइलर को profile_path पास करना है या नहीं.

टैग: affects_outputs, loading_and_analysis

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

यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain"

proto_lang_toolchain() का लेबल, जिसमें C++ प्रोटो को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जिसमें Java protos को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जिसमें JavaLite protos को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> कई बार इस्तेमाल किया गया हो

प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.

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

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

• Windows: c:/msys64/usr/bin/bash.exe
• FreeBSD: /usr/local/bin/bash
• अन्य सभी: /bin/bash.

ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में समस्याएं आ सकती हैं.

टैग: loading_and_analysis

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

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

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

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

--test_result_expiration=<an integer> default: "-1"

इस विकल्प को बंद कर दिया गया है और इससे कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "false"

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

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit"

टेस्ट शार्डिंग के लिए रणनीति तय करें:

• explicit का इस्तेमाल सिर्फ़ तब करें, जब shard_count BUILD एट्रिब्यूट मौजूद हो.
• disabled का इस्तेमाल करके, टेस्ट शार्डिंग को कभी भी इस्तेमाल न करें.
• forced=k का इस्तेमाल करके, shard_count BUILD एट्रिब्यूट की परवाह किए बिना, टेस्टिंग के लिए k शार्ड लागू करें.

--tool_java_language_version=<a string> default: ""

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

--tool_java_runtime_version=<a string> default: "remotejdk_11"

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

--[no]use_ijars default: "true"

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

बनाने के विकल्प

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

--[no]allow_one_action_on_resource_unavailable default: "true"

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

टैग: execution

--allowed_strategies_by_exec_platform=<a '<Label>=value[,value]' assignment> कई बार इस्तेमाल किया गया हो

फ़िल्टर, ऑर्डर पर असर डाले बिना एक्ज़ीक्यूशन प्लैटफ़ॉर्म के हिसाब से रणनीतियां तय करते हैं. उदाहरण के लिए:

common --spawn_strategy=remote,sandboxed,worker,local
common --strategy=Genrule=local
common --allowed_strategies_by_exec_platform=@platforms//host:host=local,sandboxed,worker
common --allowed_strategies_by_exec_platform=//:linux_amd64=remote

ऊपर दिए गए विकल्पों के साथ;

• होस्ट प्लैटफ़ॉर्म के लिए कॉन्फ़िगर की गई कार्रवाइयों को remote,sandboxed,worker दिया जाएगा.
• //:linux_amd64 प्लैटफ़ॉर्म के लिए कॉन्फ़िगर की गई कार्रवाइयों को remote दिया जाएगा.
• //:linux_amd64 प्लैटफ़ॉर्म के लिए कॉन्फ़िगर किए गए और Genrule निमोनिक वाले ऐक्शन के लिए, कोई रणनीति नहीं दी जाएगी. साथ ही, वे शुरू नहीं हो पाएंगे.

टैग: execution

--[no]check_up_to_date डिफ़ॉल्ट: "false"

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

टैग: execution

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

अगर बिल्ड के दौरान रिमोट एक्ज़ीक्यूशन कम से कम एक बार तेज़ था, तो लोकल एक्ज़ीक्यूशन को कितने मिलीसेकंड तक डिले किया जाना चाहिए?

टैग: execution, host_machine_resource_optimizations

--dynamic_local_strategy=<a '[name=]value1[,..,valueN]' assignment> कई बार इस्तेमाल किया गया हो

दिए गए नेमोनिक के लिए, क्रम से लोकल रणनीतियां. सबसे पहले लागू होने वाली रणनीति का इस्तेमाल किया जाता है. उदाहरण के लिए, worker,sandboxed उन ऐक्शन को रन करता है जो वर्कर रणनीति का इस्तेमाल करके, परसिस्टेंट वर्कर के साथ काम करते हैं. साथ ही, यह सैंडबॉक्स वाली रणनीति का इस्तेमाल करके, अन्य सभी ऐक्शन को रन करता है. अगर कोई नेमोनिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी नेमोनिक के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची worker,sandboxed है. अगर experimental_local_lockfree_output सेट है, तो worker,sandboxed,standalone है. Takes [mnemonic=]local_strategy[,local_strategy,...]

टैग: execution, host_machine_resource_optimizations

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

दिए गए नेमोनिक के लिए, क्रम से रिमोट रणनीतियां. सबसे पहले लागू होने वाली रणनीति का इस्तेमाल किया जाता है. अगर कोई नेमोनिक नहीं दिया गया है, तो रणनीतियों की सूची का इस्तेमाल सभी नेमोनिक के लिए फ़ॉलबैक के तौर पर किया जाता है. डिफ़ॉल्ट फ़ॉलबैक सूची remote होती है. इसलिए, आम तौर पर इस फ़्लैग को साफ़ तौर पर सेट करने की ज़रूरत नहीं होती. Takes [mnemonic=]remote_strategy[,remote_strategy,...]

टैग: execution, host_machine_resource_optimizations

--[no]experimental_async_execution डिफ़ॉल्ट: "false"

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

टैग: host_machine_resource_optimizations, execution, incompatible_change

--experimental_async_execution_max_concurrent_actions=<an integer> default: "5000"

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

टैग: host_machine_resource_optimizations, execution

--experimental_docker_image=<a string> default: ""

डॉकटर इमेज का ऐसा नाम (जैसे, "ubuntu:latest") तय करें जिसका इस्तेमाल, सैंडबॉक्स किए गए ऐक्शन को एक्ज़ीक्यूट करने के लिए किया जाना चाहिए. ऐसा तब किया जाता है, जब docker रणनीति का इस्तेमाल किया जा रहा हो और ऐक्शन में, प्लैटफ़ॉर्म के ब्यौरे में मौजूद remote_execution_properties में पहले से कोई container-image एट्रिब्यूट न हो. इस फ़्लैग की वैल्यू को 'docker run' में पास किया जाता है. इसलिए, यह Docker के सिंटैक्स और मेकैनिज़्म के साथ काम करता है.

टैग: execution

--[no]experimental_docker_use_customized_images default: "true"

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

टैग: execution

--[no]experimental_dynamic_exclude_tools default: "true"

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

टैग: execution, host_machine_resource_optimizations

--experimental_dynamic_local_load_factor=<a double> default: "0"

इससे यह कंट्रोल किया जाता है कि डाइनैमिक एक्ज़ीक्यूशन से लोकल मशीन पर कितना लोड डाला जाए. यह फ़्लैग, डाइनैमिक एक्ज़ीक्यूशन में एक साथ शेड्यूल की जाने वाली कार्रवाइयों की संख्या को अडजस्ट करता है. यह इस बात पर निर्भर करता है कि Blaze के हिसाब से कितने सीपीयू उपलब्ध हैं. इसे --local_resources=cpu= फ़्लैग की मदद से कंट्रोल किया जा सकता है. अगर इस फ़्लैग की वैल्यू 0 है, तो सभी कार्रवाइयों को तुरंत स्थानीय तौर पर शेड्यूल किया जाता है. अगर वैल्यू > 0 है, तो स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या, उपलब्ध सीपीयू की संख्या के हिसाब से तय होती है. अगर यह वैल्यू < 1 है, तो लोड फ़ैक्टर का इस्तेमाल, स्थानीय तौर पर शेड्यूल की गई कार्रवाइयों की संख्या को कम करने के लिए किया जाता है. ऐसा तब किया जाता है, जब शेड्यूल की जाने वाली कार्रवाइयों की संख्या ज़्यादा हो. इससे क्लीन बिल्ड के मामले में लोकल मशीन पर लोड कम हो जाता है. इसमें लोकल मशीन का योगदान ज़्यादा नहीं होता.

टैग: execution, host_machine_resource_optimizations

--experimental_dynamic_slow_remote_time=<An immutable length of time.> default: "0"

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

टैग: execution, host_machine_resource_optimizations

--[no]experimental_enable_docker_sandbox डिफ़ॉल्ट: "false"

Docker पर आधारित सैंडबॉक्सिंग की सुविधा चालू करें. अगर Docker इंस्टॉल नहीं है, तो इस विकल्प का कोई असर नहीं पड़ता.

टैग: execution

--[no]experimental_inmemory_sandbox_stashes डिफ़ॉल्ट: "false"

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

टैग: host_machine_resource_optimizations, execution

--experimental_sandbox_async_tree_delete_idle_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "4"

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

टैग: host_machine_resource_optimizations, execution

--experimental_sandbox_enforce_resources_regexp=<a valid Java regular expression> default: ""

अगर यह वैल्यू सही पर सेट है, तो जिन कार्रवाइयों के नेमोनिक, इनपुट रेगुलर एक्सप्रेशन से मेल खाते हैं उनके संसाधन अनुरोधों पर सीमाएं लागू की जाएंगी. अगर संसाधन का टाइप इसकी अनुमति देता है, तो --experimental_sandbox_limits की वैल्यू को बदल दिया जाएगा. उदाहरण के लिए, अगर किसी टेस्ट में cpu:3 और resources:memory:10 तय किया गया है, तो वह ज़्यादा से ज़्यादा तीन सीपीयू और 10 मेगाबाइट मेमोरी के साथ चलेगा.

टैग: execution

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

अगर वैल्यू > 0 है, तो हर Linux सैंडबॉक्स को तय किए गए संसाधन के लिए, दी गई सीमा तक ही इस्तेमाल किया जा सकेगा. इसके लिए, --incompatible_use_new_cgroup_implementation फ़्लैग की ज़रूरत होती है. साथ ही, यह --experimental_sandbox_memory_limit_mb फ़्लैग को बदल देता है. इसके लिए, cgroups v1 या v2 और उपयोगकर्ताओं को cgroups डायरेक्ट्री के लिए अनुमतियों की ज़रूरत होती है.

टैग: execution

--experimental_sandbox_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0"

अगर वैल्यू > 0 है, तो हर Linux सैंडबॉक्स के लिए, मेमोरी की तय की गई सीमा (MB में) लागू होगी. इसके लिए, cgroups v1 या v2 और उपयोगकर्ताओं को cgroups डायरेक्ट्री के लिए अनुमतियों की ज़रूरत होती है.

टैग: execution

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

अगर यह सुविधा चालू है, तो वर्कर पूल छोटा हो सकता है. ऐसा तब होता है, जब वर्कर की मेमोरी पर ज़्यादा दबाव पड़ता है. यह फ़्लैग सिर्फ़ तब काम करता है, जब experimental_total_worker_memory_limit_mb फ़्लैग चालू हो.

टैग: execution, host_machine_resource_optimizations

--experimental_total_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0"

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

टैग: execution, host_machine_resource_optimizations

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

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

टैग: execution

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

कार्रवाइयां करने के लिए, Windows सैंडबॉक्स का इस्तेमाल करें. अगर "हां" चुना जाता है, तो --experimental_windows_sandbox_path से दिया गया बाइनरी मान्य होना चाहिए. साथ ही, यह sandboxfs के साथ काम करने वाले वर्शन से मेल खाना चाहिए. अगर "auto" है, तो हो सकता है कि बाइनरी मौजूद न हो या काम न करे.

टैग: execution

--experimental_windows_sandbox_path=<a string> default: "BazelSandbox.exe"

Windows सैंडबॉक्स के बाइनरी का पाथ. इसका इस्तेमाल तब किया जाता है, जब --experimental_use_windows_sandbox की वैल्यू सही होती है. अगर कोई बेयर नेम है, तो PATH में मिले उस नाम के पहले बाइनरी का इस्तेमाल करें.

टैग: execution

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

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

टैग: execution, host_machine_resource_optimizations

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

अगर यह सुविधा चालू है, तो Bazel उन वर्कर को रद्द करने के अनुरोध भेज सकता है जो इस सुविधा के साथ काम करते हैं.

टैग: execution

--experimental_worker_memory_limit_mb=<an integer number of MBs, or "HOST_RAM", optionally followed by [-|*]<float>.> default: "0"

अगर यह सीमा शून्य से ज़्यादा है, तो वर्कर की मेमोरी का इस्तेमाल सीमा से ज़्यादा होने पर, वर्कर बंद हो सकते हैं. अगर इसका इस्तेमाल डाइनैमिक एक्ज़ीक्यूशन और --experimental_dynamic_ignore_local_signals=9 के साथ नहीं किया जाता है, तो हो सकता है कि आपका बिल्ड क्रैश हो जाए.

टैग: execution, host_machine_resource_optimizations

--experimental_worker_metrics_poll_interval=<An immutable length of time.> default: "5s"

वर्कर मेट्रिक इकट्ठा करने और उन्हें हटाने की कोशिश करने के बीच का अंतराल. परफ़ॉर्मेंस की वजह से, इसे एक सेकंड से कम नहीं किया जा सकता.

टैग: execution, host_machine_resource_optimizations

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

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

टैग: execution

--[no]experimental_worker_sandbox_hardening डिफ़ॉल्ट: "false"

अगर यह सेटिंग चालू है, तो वर्कर को हार्डेंड सैंडबॉक्स में चलाया जाता है. हालांकि, ऐसा सिर्फ़ तब किया जाता है, जब लागू करने की अनुमति हो. अगर हार्डनिंग की सुविधा चालू है, तो अलग-अलग वर्कर के लिए tmp डायरेक्ट्री अलग-अलग होती हैं.

टैग: execution

--experimental_worker_sandbox_inmemory_tracking=<a string> कई बार इस्तेमाल किया गया हो

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

टैग: execution

--[no]experimental_worker_strict_flagfiles डिफ़ॉल्ट: "false"

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

टैग: execution

--genrule_strategy=<comma-separated list of options> default: ""

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

टैग: execution

--[no]incompatible_use_new_cgroup_implementation default: "true"

अगर यह सही है, तो cgroups के लिए नए तरीके का इस्तेमाल करें. पुराना तरीका सिर्फ़ मेमोरी कंट्रोलर के साथ काम करता है और --experimental_sandbox_limits की वैल्यू को अनदेखा करता है.

टैग: execution

--[no]internal_spawn_scheduler default: "true"

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

टैग: execution, host_machine_resource_optimizations

--jobs=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> [-j] default: "auto"

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

टैग: host_machine_resource_optimizations, execution

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

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

टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto"

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

टैग: bazel_internal_configuration

--[no]reuse_sandbox_directories default: "true"

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

टैग: host_machine_resource_optimizations, execution

--sandbox_base=<a string> default: ""

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

टैग: host_machine_resource_optimizations, execution

--[no]sandbox_enable_loopback_device default: "true"

अगर यह विकल्प 'सही है' पर सेट है, तो स्थानीय कार्रवाइयों के लिए, linux-sandbox नेटवर्क नेमस्पेस में एक लूपबैक डिवाइस सेट अप किया जाएगा.

टैग: execution

--[no]sandbox_explicit_pseudoterminal डिफ़ॉल्ट: "false"

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

टैग: execution

--sandbox_tmpfs_path=<an absolute path> कई बार इस्तेमाल किया गया हो

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

टैग: host_machine_resource_optimizations, execution

--[no]skip_incompatible_explicit_targets डिफ़ॉल्ट: "false"

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

टैग: loading_and_analysis

--spawn_strategy=<comma-separated list of options> default: ""

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

टैग: execution

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

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

टैग: execution

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

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

टैग: execution

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

--persistent_worker के अलावा, वर्कर प्रोसेस को पास किए जाने वाले अतिरिक्त कमांड-फ़्लैग.ये नेमोनिक के हिसाब से तय किए जाते हैं. उदाहरण के लिए, --worker_extra_flag=Javac=--debug.

टैग: execution, host_machine_resource_optimizations

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

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

टैग: execution, host_machine_resource_optimizations

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

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

टैग: execution, host_machine_resource_optimizations

--[no]worker_multiplex default: "true"

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

टैग: execution, host_machine_resource_optimizations

--[no]worker_quit_after_build डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, बिल्ड पूरा होने के बाद सभी वर्कर बंद हो जाते हैं.

टैग: execution, host_machine_resource_optimizations

--[no]worker_sandboxing डिफ़ॉल्ट: "false"

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

टैग: execution

--[no]worker_verbose डिफ़ॉल्ट: "false"

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

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

--[no]build default: "true"

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

टैग: execution, affects_outputs

--[no]experimental_use_validation_aspect डिफ़ॉल्ट: "false"

क्या पहलू का इस्तेमाल करके पुष्टि करने वाली कार्रवाइयां करनी हैं (जांच के साथ समानता के लिए).

टैग: execution, affects_outputs

--output_groups=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग किए गए आउटपुट ग्रुप के नामों की सूची. इनमें से हर नाम के पहले, + या - का इस्तेमाल किया जा सकता है. + से शुरू होने वाले ग्रुप को आउटपुट ग्रुप के डिफ़ॉल्ट सेट में जोड़ा जाता है, जबकि - से शुरू होने वाले ग्रुप को डिफ़ॉल्ट सेट से हटा दिया जाता है. अगर कम से कम एक ग्रुप में प्रीफ़िक्स नहीं लगाया गया है, तो आउटपुट ग्रुप का डिफ़ॉल्ट सेट शामिल नहीं किया जाएगा. उदाहरण के लिए, --output_groups=+foo,+bar डिफ़ॉल्ट सेट, foo, और bar का यूनीयन बनाता है. वहीं, --output_groups=foo,bar डिफ़ॉल्ट सेट को इस तरह से बदलता है कि सिर्फ़ foo और bar बनाए जाते हैं.

टैग: execution, affects_outputs

--[no]run_validations default: "true"

बिल्ड के दौरान पुष्टि करने वाली कार्रवाइयां करनी हैं या नहीं. पुष्टि करने से जुड़े ऐक्शन देखें.

टैग: execution, affects_outputs

--serialized_frontier_profile=<a string> default: ""

सीरियल किए गए फ़्रंटियर बाइट की प्रोफ़ाइल डंप करें. इससे आउटपुट पाथ के बारे में पता चलता है.

टैग: bazel_monitoring

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

--aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

सबसे ऊपर के लेवल के टारगेट पर लागू किए जाने वाले पहलुओं की सूची, जिसमें कॉमा लगाकर पहलुओं को अलग-अलग किया गया है. अगर सूची में मौजूद आसपेक्ट some_aspect, required_aspect_providers के ज़रिए ज़रूरी आसपेक्ट प्रोवाइडर तय करता है, तो some_aspect, आसपेक्ट की सूची में उससे पहले मौजूद हर उस आसपेक्ट के बाद चलेगा जिसके विज्ञापन देने वाले प्रोवाइडर, some_aspect के ज़रूरी आसपेक्ट प्रोवाइडर की शर्तों को पूरा करते हैं. इसके अलावा, some_aspect, requires एट्रिब्यूट के ज़रिए तय की गई सभी ज़रूरी शर्तों को पूरा करने के बाद ही चलेगा. इसके बाद, some_aspect को उन पहलुओं के प्रोवाइडर की वैल्यू का ऐक्सेस मिल जाएगा. {bzl-file-label}%{aspect_name}, उदाहरण के लिए //tools:my_def.bzl%my_aspect, जहां my_aspect, tools/my_def.bzl फ़ाइल की टॉप-लेवल वैल्यू है.

--bep_maximum_open_remote_upload_files=<an integer> default: "-1"

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

टैग: affects_outputs

--[no]experimental_convenience_symlinks default: "normal"

इस फ़्लैग से यह कंट्रोल किया जाता है कि सुविधा के लिए उपलब्ध सिमलंक (ऐसे सिमलंक जो बिल्ड के बाद वर्कस्पेस में दिखते हैं) कैसे मैनेज किए जाएंगे. जितनी तरह के साइटमैप हो सकते हैं उनकी जानकारी यहां दी गई है:

• normal (डिफ़ॉल्ट): बिल्ड के हिसाब से, हर तरह का सुविधा वाला सिंबल लिंक बनाया या मिटाया जाएगा.
• clean: सभी सिंबॉलिक लिंक बिना किसी शर्त के मिटा दिए जाएंगे.
• ignore: सिमलिंक नहीं बनाए जाएंगे या उन्हें हटाया नहीं जाएगा.
• log_only: लॉग मैसेज जनरेट करें, जैसे कि normal पास किया गया हो. हालांकि, फ़ाइल सिस्टम से जुड़ी कोई भी कार्रवाई न करें. यह टूल के लिए फ़ायदेमंद है.

ध्यान दें कि सिर्फ़ उन सिमलंक पर असर पड़ सकता है जिनके नाम, --symlink_prefix की मौजूदा वैल्यू से जनरेट होते हैं. अगर प्रीफ़िक्स बदलता है, तो पहले से मौजूद किसी भी सिमलंक पर कोई असर नहीं पड़ेगा.

टैग: affects_outputs

--[no]experimental_convenience_symlinks_bep_event default: "true"

इस फ़्लैग से यह कंट्रोल होता है कि हम बिल्ड इवेंट ConvenienceSymlinksIdentified को Build Event Protocol में पोस्ट करेंगे या नहीं. अगर वैल्यू सही है, तो बीईपी में convenienceSymlinksIdentified के लिए एक एंट्री होगी. इसमें आपके फ़ाइल फ़ोल्डर में बनाए गए सभी सुविधा वाले सिमलिंक की सूची होगी. अगर यह वैल्यू 'गलत है' पर सेट है, तो बीईपी में convenienceSymlinksIdentified एंट्री खाली होगी.

टैग: affects_outputs

--remote_download_all

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

बढ़ाकर:
  --remote_download_outputs=all

टैग: affects_outputs

--remote_download_minimal

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

बढ़ाकर:
  --remote_download_outputs=minimal

टैग: affects_outputs

--remote_download_outputs=<all, minimal or toplevel> default: "toplevel"

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

टैग: affects_outputs

--remote_download_symlink_template=<a string> default: ""

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

टैग: affects_outputs

--remote_download_toplevel

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

बढ़ाकर:
  --remote_download_outputs=toplevel

टैग: affects_outputs

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

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

टैग: affects_outputs

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

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

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

टैग: execution

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

No-op

टैग: host_machine_resource_optimizations, execution

--sandbox_add_mount_pair=<a single path or a 'source:target' pair> कई बार इस्तेमाल किया गया हो

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

टैग: execution

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

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

टैग: execution

--[no]sandbox_default_allow_network default: "true"

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

टैग: execution

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

सैंडबॉक्स किए गए ऐक्शन के लिए, मौजूदा होस्टनेम को 'localhost' में बदलें.

टैग: execution

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

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

टैग: execution

--sandbox_writable_path=<a string> कई बार इस्तेमाल किया गया हो

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

टैग: execution

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

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

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

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility default: "true"

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

टैग: loading_and_analysis, incompatible_change

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

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

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

टैग: execution

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

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

टैग: 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"> default: "auto"

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

टैग: execution

--[no]test_keep_going default: "true"

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

टैग: execution

--test_strategy=<a string> default: ""

यह तय करता है कि टेस्ट चलाने के दौरान किस रणनीति का इस्तेमाल करना है.

टैग: execution

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

यह विकल्प, 'bazel test' के लिए बेस टेंपररी डायरेक्ट्री तय करता है.

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

--cache_computed_file_digests=<a long integer> default: "50000"

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

--experimental_active_directories=<comma-separated list of options> default: ""

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

टैग: host_machine_resource_optimizations

--[no]experimental_cpu_load_scheduling डिफ़ॉल्ट: "false"

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

टैग: execution

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

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

टैग: execution

--[no]experimental_enable_skyfocus डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो --experimental_active_directories का इस्तेमाल चालू करें. इससे इंक्रीमेंटल बिल्ड के लिए, Bazel के मेमोरी फ़ुटप्रिंट को कम किया जा सकता है. इस सुविधा को Skyfocus कहा जाता है.

टैग: host_machine_resource_optimizations

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

Bazel के लिए उपलब्ध संसाधनों की संख्या सेट करें. यह फ़्लोट या HOST_RAM/HOST_CPUS को असाइनमेंट में लेता है. इसके बाद, [-|]<float> (उदाहरण के लिए, उपलब्ध रैम का आधा हिस्सा इस्तेमाल करने के लिए memory=HOST_RAM.5) का इस्तेमाल किया जा सकता है. इसका इस्तेमाल कई बार किया जा सकता है, ताकि अलग-अलग तरह के संसाधनों के बारे में बताया जा सके. Bazel, उपलब्ध संसाधनों और ज़रूरी संसाधनों के आधार पर, एक साथ चल रही कार्रवाइयों को सीमित करेगा. जांचें कि "resources:<resource name>:<amount>" फ़ॉर्मैट वाले टैग का इस्तेमाल करके, ज़रूरी संसाधनों की संख्या का एलान किया जा सकता है.

टैग: host_machine_resource_optimizations

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

--build_event_upload_max_retries=<an integer> default: "4"

Bazel को, बिल्ड इवेंट को अपलोड करने की कोशिश ज़्यादा से ज़्यादा कितनी बार करनी चाहिए.

टैग: bazel_internal_configuration

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

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

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

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

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

टैग: affects_outputs

--experimental_build_event_output_group_mode=<an output group name followed by an OutputGroupFileMode, e.g. default=both> कई बार इस्तेमाल किया गया हो

यह तय करें कि आउटपुट ग्रुप की फ़ाइलों को TargetComplete/AspectComplete बीईपी इवेंट में कैसे दिखाया जाएगा. वैल्यू, आउटपुट ग्रुप के नाम को NAMED_SET_OF_FILES_ONLY, INLINE_ONLY या BOTH में से किसी एक को असाइन की जाती है. डिफ़ॉल्ट वैल्यू NAMED_SET_OF_FILES_ONLY है. अगर किसी आउटपुट ग्रुप को दोहराया जाता है, तो दिखने वाली फ़ाइनल वैल्यू का इस्तेमाल किया जाता है. डिफ़ॉल्ट वैल्यू, कवरेज आर्टफ़ैक्ट के लिए मोड को BOTH पर सेट करती है: --experimental_build_event_output_group_mode=baseline.lcov=both

टैग: affects_outputs

--experimental_build_event_upload_retry_minimum_delay=<An immutable length of time.> default: "1s"

बीईपी अपलोड करने में गड़बड़ी होने पर, एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने के लिए, शुरुआती और कम से कम देरी. (exponent: 1.6)

टैग: bazel_internal_configuration

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

यह विकल्प चुनता है कि बिल्ड इवेंट प्रोटोकॉल में रेफ़र किए गए आर्टफ़ैक्ट को कैसे अपलोड किया जाए. Bazel में, मान्य विकल्पों में local और remote शामिल हैं. डिफ़ॉल्ट वैल्यू local है.

टैग: affects_outputs

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

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

टैग: execution

--experimental_frontier_violation_check=<strict, warn or disabled_for_testing> default: "strict"

ऐसी रणनीतियां जिनसे फ़्रंटियर (यानी कि ऐक्टिव डायरेक्ट्री के बाहर) में हुए बदलावों से मिली गलत जानकारी को ठीक किया जा सके

टैग: eagerness_to_exit

--[no]experimental_frontier_violation_verbose डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो Bazel, Skycache के उल्लंघन ठीक करने के निर्देश प्रिंट करेगा

टैग: terminal_output

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

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

टैग: execution

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

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

टैग: affects_outputs

--experimental_skyfocus_dump_keys=<none, count or verbose> डिफ़ॉल्ट: "none"

इस कुकी का इस्तेमाल Skyfocus को डीबग करने के लिए किया जाता है. फ़ोकस किए गए SkyKeys (रूट, पत्तियां, फ़ोकस किए गए deps, फ़ोकस किए गए rdeps) को डंप करें.

टैग: terminal_output

--[no]experimental_skyfocus_dump_post_gc_stats डिफ़ॉल्ट: "false"

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

टैग: terminal_output

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

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

टैग: affects_outputs

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

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

टैग: affects_outputs

--[no]legacy_important_outputs डिफ़ॉल्ट: "false"

इसका इस्तेमाल, TargetComplete इवेंट में लेगसी important_outputs फ़ील्ड को जनरेट होने से रोकने के लिए करें. important_outputs, Bazel को ResultStore/BTX के साथ इंटिग्रेट करने के लिए ज़रूरी हैं.

टैग: affects_outputs

--[no]materialize_param_files डिफ़ॉल्ट: "false"

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

टैग: execution

--max_config_changes_to_show=<an integer> default: "3"

बिल्ड के विकल्पों में बदलाव होने की वजह से, विश्लेषण की कैश मेमोरी को खारिज करने पर, बदले गए विकल्पों के नाम की दी गई संख्या तक दिखाता है. अगर दी गई संख्या -1 है, तो बदले गए सभी विकल्प दिखेंगे.

टैग: terminal_output

--max_test_output_bytes=<an integer> default: "-1"

यह हर टेस्ट के लॉग का ज़्यादा से ज़्यादा साइज़ तय करता है. यह साइज़ तब लागू होता है, जब --test_output की वैल्यू 'errors' या 'all' पर सेट हो. यह विकल्प, टेस्ट के बहुत ज़्यादा शोर वाले आउटपुट से आउटपुट को ज़्यादा जानकारी से भरने से बचने के लिए फ़ायदेमंद है. टेस्ट हेडर को लॉग के साइज़ में शामिल किया जाता है. नेगेटिव वैल्यू का मतलब है कि कोई सीमा नहीं है. आउटपुट पूरा या कुछ भी नहीं होता है.

टैग: test_runner, terminal_output, execution

--output_filter=<a valid Java regular expression> डिफ़ॉल्ट: ब्यौरा देखें

यह सिर्फ़ उन नियमों के लिए चेतावनियां और कार्रवाई के आउटपुट दिखाता है जिनके नाम, दिए गए रेगुलर एक्सप्रेशन से मेल खाते हैं.

टैग: affects_outputs

--progress_report_interval=<an integer in 0-3600 range> default: "0"

अब भी चल रही नौकरियों की रिपोर्ट के बीच इंतज़ार करने के लिए सेकंड की संख्या. डिफ़ॉल्ट वैल्यू 0 का मतलब है कि पहली रिपोर्ट 10 सेकंड के बाद प्रिंट की जाएगी. इसके बाद, 30 सेकंड के बाद और फिर हर मिनट में एक बार प्रोग्रेस की रिपोर्ट दी जाएगी. --curses के चालू होने पर, हर सेकंड में प्रोग्रेस की जानकारी दी जाती है.

टैग: affects_outputs

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

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

टैग: bazel_monitoring

--remote_print_execution_messages=<failure, success or all> default: "failure"

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

टैग: terminal_output

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

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

टैग: terminal_output

--show_result=<an integer> default: "1"

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

इस विकल्प के लिए, पूर्णांक आर्ग्युमेंट की ज़रूरत होती है. यह टारगेट की थ्रेशोल्ड संख्या होती है. इससे ज़्यादा टारगेट होने पर, नतीजे की जानकारी प्रिंट नहीं की जाती. इसलिए, शून्य की वजह से मैसेज नहीं दिखता है और MAX_INT की वजह से नतीजे हमेशा दिखते हैं. डिफ़ॉल्ट वैल्यू एक होती है.

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

टैग: affects_outputs

--[no]subcommands [-s] डिफ़ॉल्ट: "false"

बिल्ड के दौरान लागू की गई सब-कमांड दिखाएं. इससे जुड़े फ़्लैग: --execution_log_json_file, --execution_log_binary_file (उप-कमांड को टूल के हिसाब से फ़ॉर्मैट की गई फ़ाइल में लॉग करने के लिए).

टैग: terminal_output

--test_output=<summary, errors, all or streamed> default: "summary"

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

मान्य वैल्यू ये हैं;

• summary (डिफ़ॉल्ट) का इस्तेमाल करके, फ़ेल हुए टेस्ट की खास जानकारी प्रिंट करें,
• errors फ़ेल हो चुके टेस्ट के लिए टेस्ट लॉग भी प्रिंट करने के लिए,
• all का इस्तेमाल करके, सभी टेस्ट की खास जानकारी और लॉग प्रिंट करें
• streamed का इस्तेमाल करके, सभी टेस्ट के लॉग रीयल टाइम में आउटपुट किए जा सकते हैं. इससे टेस्ट को एक-एक करके स्थानीय तौर पर एक्ज़ीक्यूट किया जा सकेगा. भले ही, --test_strategy की वैल्यू कुछ भी हो.

टैग: test_runner, terminal_output, execution

--test_summary=<short, short_uncached, terse, detailed, detailed_uncached, none or testcase> default: "short"

इससे टेस्ट की खास जानकारी का फ़ॉर्मैट तय होता है. मान्य वैल्यू ये हैं;

• short उन सभी टेस्ट की सूची बनाने के लिए जो पूरी तरह से चले.
• short_uncached का इस्तेमाल करके, उन टेस्ट की सूची बनाएं जो पूरे हो चुके हैं. इसमें कैश मेमोरी में सेव किए गए टेस्ट शामिल नहीं किए जाते.
• terse का इस्तेमाल करके, सिर्फ़ फ़ेल हुए और फ़्लेकी टेस्ट की सूची बनाएं.
• detailed का इस्तेमाल करके, उन टेस्ट और उनके टेस्ट केस की सूची बनाएं जो पूरे हो चुके हैं.
• detailed_uncached का इस्तेमाल करके, उन टेस्ट और उनके टेस्ट केस की सूची बनाएं जो पूरे हो चुके हैं. इसमें कैश मेमोरी में सेव किए गए टेस्ट शामिल नहीं किए जाते.
• testcase का इस्तेमाल करके, टेस्ट केस के नतीजे की खास जानकारी को प्रिंट किया जा सकता है. हालांकि, इसमें फ़ेल हुए टेस्ट केस के बारे में पूरी जानकारी नहीं होती.
• खास जानकारी को शामिल न करने के लिए, none पर क्लिक करें.

टैग: terminal_output

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

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

टैग: terminal_output

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

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

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

टैग: loading_and_analysis

--target_pattern_file=<a string> default: ""

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

टैग: changes_inputs

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

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

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

टैग: execution

--[no]experimental_remote_cache_chunking डिफ़ॉल्ट: "false"

यह सुविधा चालू होने पर, बड़े ब्लब को FastCDC 2020 का इस्तेमाल करके, कॉन्टेंट के हिसाब से तय किए गए हिस्सों में बांटा जाता है. इसके बाद, इन हिस्सों को अपलोड/डाउनलोड किया जाता है. इससे सभी ब्लब में डुप्लीकेट डेटा को हटाने में मदद मिलती है. सर्वर को अपनी क्षमताओं में SplitBlob/SpliceBlob RPC और FastCDC 2020 पैरामीटर के बारे में बताना होगा.

टैग: experimental

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

zstd का इस्तेमाल करके कंप्रेस/डीकंप्रेस करने के लिए, कम से कम ब्लोब साइज़ ज़रूरी है. जब तक --remote_cache_compression सेट नहीं किया जाता, तब तक यह विकल्प काम नहीं करता.

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

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

टैग: execution

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

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

--experimental_remote_cache_ttl=<An immutable length of time.> default: "3h"

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

टैग: execution

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

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

--[no]experimental_remote_discard_merkle_trees default: "true"

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

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

रिमोट ऐसेट एपीआई एंडपॉइंट यूआरआई, जिसका इस्तेमाल रिमोट डाउनलोड प्रॉक्सी के तौर पर किया जाना है. grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. इस लिंक पर जानकारी पाएं: https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/asset/v1/remote_asset.proto

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

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

--[no]experimental_remote_downloader_propagate_credentials डिफ़ॉल्ट: "false"

यह तय करता है कि netrc और क्रेडेंशियल हेल्पर से क्रेडेंशियल को रिमोट डाउनलोडर सर्वर पर भेजना है या नहीं. सर्वर पर लागू करने के लिए, नए http_header_url:<url-index>:<header-key> क्वालिफ़ायर का इस्तेमाल किया जाना चाहिए. इसमें <url-index>, FetchBlobRequest के uris फ़ील्ड में मौजूद यूआरएल की 0 से शुरू होने वाली पोज़िशन होती है. यूआरएल के हिसाब से तय किए गए हेडर को ग्लोबल हेडर से ज़्यादा प्राथमिकता दी जानी चाहिए.

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

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

टैग: execution

--experimental_remote_failure_window_interval=<An immutable length of time.> default: "60s"

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

टैग: execution

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

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

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

रिमोट आउटपुट सेवा के एंडपॉइंट का HOST या HOST:PORT. grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS बंद करने के लिए, grpc:// या unix: स्कीमा तय करें.

--experimental_remote_output_service_output_path_prefix=<a string> default: ""

यह वह पाथ है जिसके तहत, --experimental_remote_output_service मैनेज की गई आउटपुट डायरेक्ट्री का कॉन्टेंट रखा जाता है. बिल्ड के लिए इस्तेमाल की जाने वाली आउटपुट डायरेक्ट्री, इस पाथ की डिसेंडेंट होगी. साथ ही, इसे आउटपुट सेवा तय करेगी.

--[no]experimental_remote_require_cached डिफ़ॉल्ट: "false"

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

--experimental_remote_scrubbing_config=<Converts to a Scrubber> डिफ़ॉल्ट: ब्यौरा देखें

यह विकल्प, दी गई कॉन्फ़िगरेशन फ़ाइल की मदद से, रिमोट कैश कुंजी को मिटाने की सुविधा चालू करता है. यह फ़ाइल, टेक्स्ट फ़ॉर्मैट में प्रोटोकॉल बफ़र होनी चाहिए. इसके बारे में ज़्यादा जानने के लिए, src/main/protobuf/remote_scrubbing.proto देखें.

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

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

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

इस सुविधा का इस्तेमाल करने के लिए, आपको --experimental_platform_in_output_dir के साथ --host_platform को कस्टम तौर पर सेट करना होगा, ताकि आउटपुट प्रीफ़िक्स को सामान्य किया जा सके.

--[no]guard_against_concurrent_changes default: "lite"

इसे 'full' पर सेट करें, ताकि रिमोट कैश में अपलोड करने से पहले, किसी कार्रवाई की सभी इनपुट फ़ाइलों के ctime की जांच की जा सके. ऐसा हो सकता है कि कुछ मामलों में Linux कर्नल, फ़ाइलों को लिखने में देरी करे. इससे फ़ॉल्स पॉज़िटिव मिल सकते हैं. डिफ़ॉल्ट रूप से, यह 'lite' पर सेट होता है. यह सिर्फ़ मुख्य रिपॉज़िटरी में मौजूद सोर्स फ़ाइलों की जांच करता है. इसे 'बंद है' पर सेट करने से, सभी जांच बंद हो जाती हैं. हमारा सुझाव है कि ऐसा न करें. ऐसा इसलिए, क्योंकि जब किसी सोर्स फ़ाइल में बदलाव किया जाता है, तब हो सकता है कि कैश मेमोरी में मौजूद डेटा खराब हो जाए. ऐसा तब होता है, जब कोई ऐसी कार्रवाई चल रही हो जिसमें उस फ़ाइल का इस्तेमाल इनपुट के तौर पर किया जा रहा हो.

टैग: execution

--[no]incompatible_remote_local_fallback_for_remote_cache डिफ़ॉल्ट: "false"

क्या --remote_local_fallback, --remote_cache पर लागू होता है.

--[no]remote_accept_cached default: "true"

दूर से कैश मेमोरी में सेव किए गए कार्रवाई के नतीजों को स्वीकार करना है या नहीं.

--remote_build_event_upload=<all or minimal> default: "minimal"

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

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

होस्टनेम और इंस्टेंस का नाम, जिसका इस्तेमाल उन bytestream:// यूआरआई में किया जाना है जिन्हें बिल्ड इवेंट स्ट्रीम में लिखा जाता है. इस विकल्प को तब सेट किया जा सकता है, जब प्रॉक्सी का इस्तेमाल करके बिल्ड किए जाते हैं. इससे --remote_executor और --remote_instance_name की वैल्यू, रिमोट एक्ज़ीक्यूशन सेवा के कैननिकल नाम से मेल नहीं खाती हैं. अगर इसे सेट नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से "${hostname}/${instance_name}" पर सेट हो जाएगा.

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

कैशिंग एंडपॉइंट का यूआरआई. इन स्कीमा का इस्तेमाल किया जा सकता है: http, https, grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट). अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. टीएलएस को बंद करने के लिए, grpc://, http:// या unix: स्कीमा तय करें. https://bazel.build/remote/caching पर जाएं

--[no]remote_cache_async default: "true"

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

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

अगर यह विकल्प चालू है, तो कैश मेमोरी में सेव किए गए बड़े डेटा को zstd की मदद से कंप्रेस/डिकंप्रेस करें. ऐसा तब करें, जब उनका साइज़ कम से कम --experimental_remote_cache_compression_threshold हो.

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

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

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

डिफ़ॉल्ट exec प्रॉपर्टी सेट करें, ताकि उन्हें रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर इस्तेमाल किया जा सके. ऐसा तब किया जाता है, जब एक्ज़ीक्यूशन प्लैटफ़ॉर्म पहले से exec_properties सेट न करता हो.

टैग: affects_outputs

--remote_download_regex=<a valid Java regular expression> कई बार इस्तेमाल किया गया हो

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

टैग: affects_outputs

--remote_downloader_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--remote_exec_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--remote_execution_priority=<an integer> default: "0"

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

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

रिमोट एक्ज़ीक्यूशन एंडपॉइंट का HOST या HOST:PORT. grpc, grpcs (TLS की सुविधा के साथ grpc) और unix (लोकल UNIX सॉकेट) स्कीमा का इस्तेमाल किया जा सकता है. अगर कोई स्कीमा नहीं दिया जाता है, तो Bazel डिफ़ॉल्ट रूप से grpcs का इस्तेमाल करेगा. TLS बंद करने के लिए, grpc:// या unix: स्कीमा तय करें.

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

अगर बताया गया है, तो gRPC कॉल से जुड़ी जानकारी को लॉग करने के लिए फ़ाइल का पाथ. इस लॉग में, क्रम से लगाए गए com.google.devtools.build.lib.remote.logging.RemoteExecutionLog.LogEntry प्रोटोबफ़ होते हैं. हर मैसेज के पहले एक वैरिएंट होता है, जो क्रम से लगाए गए अगले प्रोटोबफ़ मैसेज के साइज़ को दिखाता है. ऐसा LogEntry.writeDelimitedTo(OutputStream) तरीके से किया जाता है.

--remote_header=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

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

--remote_instance_name=<a string> default: ""

रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.

--[no]remote_local_fallback डिफ़ॉल्ट: "false"

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

--remote_local_fallback_strategy=<a string> default: "local"

समर्थन नहीं होना या रुकना. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7480 पर जाएं.

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

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

टैग: host_machine_resource_optimizations

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

रिमोट कैश/एक्ज़ीक्यूटर से एक साथ कनेक्ट किए जा सकने वाले कनेक्शन की ज़्यादा से ज़्यादा संख्या को सीमित करें. डिफ़ॉल्ट रूप से, इसकी वैल्यू 100 होती है. इसे 0 पर सेट करने का मतलब है कि कोई सीमा नहीं है. एचटीटीपी रिमोट कैश के लिए, एक टीसीपी कनेक्शन एक बार में एक अनुरोध को हैंडल कर सकता है. इसलिए, Bazel एक साथ --remote_max_connections अनुरोध कर सकता है. gRPC रिमोट कैश/एक्ज़ीक्यूटर के लिए, एक gRPC चैनल आम तौर पर 100 से ज़्यादा एक साथ किए गए अनुरोधों को हैंडल कर सकता है. इसे --remote_max_concurrency_per_connection कंट्रोल करता है. इसलिए, Bazel एक साथ करीब --remote_max_connections * 100 अनुरोध कर सकता है.

टैग: host_machine_resource_optimizations

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

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

--remote_result_cache_priority=<an integer> default: "0"

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

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

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

--remote_retry_max_delay=<An immutable length of time.> default: "5s"

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

--remote_timeout=<An immutable length of time.> default: "60s"

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

--[no]remote_upload_local_results default: "true"

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

--[no]remote_verify_downloads default: "true"

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

--[no]rewind_lost_inputs डिफ़ॉल्ट: "false"

यह तय करता है कि इनपुट के खो जाने पर, कार्रवाई को वापस लाने की सुविधा का इस्तेमाल करना है या नहीं.

टैग: execution

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

--[no]allow_analysis_cache_discard default: "true"

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

टैग: eagerness_to_exit

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

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

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

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

--build_tag_filters=<comma-separated list of options> default: ""

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

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

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

--combined_report=<none or lcov> default: "lcov"

इससे, कवरेज रिपोर्ट का वह टाइप तय होता है जो आपको चाहिए. फ़िलहाल, सिर्फ़ LCOV फ़ॉर्मैट इस्तेमाल किया जा सकता है.

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

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

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो

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

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

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

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

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

--embed_label=<a one-line string> default: ""

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

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

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

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

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

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

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

--[no]execution_log_sort default: "true"

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

--[no]expand_test_suites default: "true"

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

टैग: loading_and_analysis

--experimental_disk_cache_gc_idle_delay=<An immutable length of time.> default: "5m"

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

--experimental_disk_cache_gc_max_age=<An immutable length of time.> default: "0"

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

--experimental_disk_cache_gc_max_size=<a size in bytes, optionally followed by a K, M, G or T multiplier> default: "0"

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

--experimental_extra_action_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: ""

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

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

इसे पहलुओं के पक्ष में बंद कर दिया गया है. यह सिर्फ़ टॉप लेवल के टारगेट के लिए extra_actions शेड्यूल करता है.

--experimental_spawn_scheduler

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

बढ़कर:
  --internal_spawn_scheduler
  --spawn_strategy=dynamic

--[no]fetch default: "true"

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

--local_termination_grace_seconds=<an integer> default: "15"

टाइम आउट होने की वजह से किसी लोकल प्रोसेस को बंद करने और उसे ज़बरदस्ती बंद करने के बीच इंतज़ार करने का समय.

--package_path=<colon-separated list of options> default: "%workspace%"

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

--[no]show_loading_progress default: "true"

अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

--test_lang_filters=<comma-separated list of options> default: ""

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

--test_size_filters=<comma-separated list of values: small, medium, large, or enormous> default: ""

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

--test_tag_filters=<comma-separated list of options> default: ""

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

--test_timeout_filters=<comma-separated list of values: short, moderate, long, or eternal> default: ""

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

--workspace_status_command=<path> default: ""

यह एक कमांड है, जिसे बिल्ड की शुरुआत में लागू किया जाता है. इससे की/वैल्यू पेयर के तौर पर, वर्कस्पेस की स्थिति के बारे में जानकारी मिलती है. पूरी जानकारी के लिए, उपयोगकर्ता का मैन्युअल देखें. उदाहरण के लिए, tools/buildstamp/get_workspace_status भी देखें.

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

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false"

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.

टैग: execution, experimental

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट कार्रवाइयों को रिमोट किया जा सकता है या नहीं

टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false"

सही होने पर, Bazel टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.

टैग: execution, experimental

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

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

टैग: execution, experimental

--[no]incompatible_modify_execution_info_additive default: "true"

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

टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

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

कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई के एक्ज़ीक्यूशन की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, और TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि एक ही नेमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.

सिंटैक्स: regex=[+-]key,regex=[+-]key,....

उदाहरण:

• .*=+x,.*=-y,.*=+z सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में x और z जोड़ता है. साथ ही, y को हटाता है.
• Genrule=+requires-x, Genrule की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में requires-x जोड़ता है.
• (?!Genrule).*=-requires-x, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से requires-x हटा देता है.

टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू करें.

बढ़कर:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को लगातार चालू रखें.

बढ़कर:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार कई बार चलाने की सुविधा चालू करें.

बढ़कर:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.

इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (डेक्सिंग, डिसुगरिंग, संसाधन प्रोसेसिंग) चालू करें.

बढ़कर:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

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

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

टैग: execution

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

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

Android टारगेट कंपाइलर.

टैग: affects_outputs, 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> default: ""

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

टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--cc_output_directory_tag=<a string> default: ""

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

टैग: affects_outputs

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

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.

टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger"

उस बाइनरी का पाथ जिसका इस्तेमाल, रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:lcov_merger पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी की जगह. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:coverage_report_generator पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support"

सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, यह //tools/test:coverage_support पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

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

यह विकल्प, malloc को लागू करने का कस्टम तरीका तय करता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.

टैग: changes_inputs, affects_outputs

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "false"

अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.

टैग: loses_incremental_state, loading_and_analysis, execution, experimental

--[no]experimental_prefer_mutual_xcode default: "true"

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

टैग: loses_incremental_state, experimental

--extra_execution_platforms=<comma-separated list of options> default: ""

कार्रवाइयां करने के लिए, इन प्लैटफ़ॉर्म का इस्तेमाल किया जा सकता है. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. register_execution_platforms() की ओर से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद में, फ़्लैग की गई सेटिंग पहले की सेटिंग को बदल देंगी.

टैग: execution

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

टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() की ओर से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले माना जाएगा.

टैग: affects_outputs, changes_inputs, loading_and_analysis

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

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.

टैग: action_command_lines, affects_outputs

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

यह फ़्लैग कोई कार्रवाई नहीं करता. आने वाले समय में इसे हटा दिया जाएगा.

टैग: loading_and_analysis, execution

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

अगर यह सेटिंग तय की जाती है, तो exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.

टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform"

होस्ट सिस्टम की जानकारी देने वाले प्लैटफ़ॉर्म के नियम का लेबल.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_bazel_test_exec_run_under default: "true"

अगर यह सुविधा चालू है, तो bazel test --run_under=//:runner, exec configuration में //:runner बनाता है. अगर यह सुविधा बंद है, तो टारगेट कॉन्फ़िगरेशन में //:runner बनाया जाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे bazel run पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में --run_under=//foo बनाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_builtin_objc_strip_action default: "true"

यह तय करता है कि objc लिंकिंग के हिस्से के तौर पर स्ट्रिप ऐक्शन को चालू करना है या नहीं.

टैग: action_command_lines, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true"

अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाएं चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false"

ऐपल के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive default: "true"

अगर यह विकल्प सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "false"

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

टैग: action_command_lines, incompatible_change

--[no]interface_shared_objects default: "true"

अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल करने की सुविधा है, तो उनका इस्तेमाल करें. फ़िलहाल, सभी 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 main workspace-relative path> default: ""

मैपिंग फ़ाइल की जगह. इससे यह पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो कौनसा प्लैटफ़ॉर्म इस्तेमाल करना है या अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसा फ़्लैग सेट करना है. यह मुख्य वर्कस्पेस रूट से जुड़ा होना चाहिए. डिफ़ॉल्ट रूप से, यह platform_mappings (वर्कस्पेस रूट के ठीक नीचे मौजूद फ़ाइल) पर सेट होता है.

टैग: affects_outputs, changes_inputs, loading_and_analysis, non_configurable

--platforms=<a build target label> default: ""

प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.

टैग: affects_outputs, changes_inputs, loading_and_analysis

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

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains ने बंद कर दिया है.

टैग: loading_and_analysis, affects_outputs

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

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

टैग: loses_incremental_state

--[no]use_platforms_in_apple_crosstool_transition डिफ़ॉल्ट: "false"

इससे apple_crosstool_transition, ज़रूरत पड़ने पर लेगसी --cpu के बजाय --platforms फ़्लैग की वैल्यू का इस्तेमाल करता है.

टैग: loading_and_analysis

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

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

टैग: loses_incremental_state

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

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

टैग: loses_incremental_state

--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes"

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

टैग: loses_incremental_state, loading_and_analysis

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

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

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

टैग: affects_outputs, action_command_lines

--[no]build_runfile_links default: "true"

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

टैग: affects_outputs

--[no]build_runfile_manifests default: "true"

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

टैग: affects_outputs

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

अगर यह सुविधा चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.

टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h"

यह cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc"

यह विकल्प, cc_proto_library से बनाई गई सोर्स फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

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

proto_library में Java api के वैकल्पिक वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.

टैग: affects_outputs, loading_and_analysis, experimental

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

इस कुकी का इस्तेमाल, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को कंपाइल करने के आउटपुट के तौर पर सेव करने के लिए किया जाता है.

टैग: affects_outputs, experimental

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

इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल करने वाले कंपाइलेशन मोड कौनसे हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.

टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम अपनी रनफ़ाइल में DefaultInfo.files डेटा डिपेंडेंसी जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाती है (रनफ़ाइल की ऐसी सुविधाएं जिनका इस्तेमाल नहीं करना चाहिए).

टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest default: "true"

चालू होने पर, {binary}.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन के रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन से जनरेट होने वाले हर रेपो के लिए एक बार दिखाने के बजाय, रनफ़ाइलें योगदान करती हैं.

टैग: affects_outputs, incompatible_change

--incompatible_disable_select_on=<comma-separated set of options> default: ""

उन फ़्लैग की सूची जिनके लिए select() में इस्तेमाल करने की सुविधा बंद है.

टैग: loading_and_analysis, incompatible_change, non_configurable

--[no]incompatible_filegroup_runfiles_for_data default: "true"

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

टैग: incompatible_change

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

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

टैग: affects_outputs

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

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

टैग: affects_outputs

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

--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

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

ध्यान दें कि जब तक --incompatible_repo_env_ignores_action_env सही नहीं होता, तब तक सभी name=value जोड़े, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.

टैग: action_command_lines

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.

टैग: changes_inputs, affects_outputs

--[no]android_databinding_use_androidx default: "true"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args default: "true"

3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> default: "off"

इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तो Android नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical"

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

टैग: action_command_lines, execution

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

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis

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

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

टैग: loses_incremental_state, loading_and_analysis

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

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

टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

उस मोड के बारे में बताएं जिसमें बाइनरी बनाई जाएगी. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--conlyopt=<a string> कई बार इस्तेमाल किया गया हो

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--copt=<a string> कई बार इस्तेमाल किया गया हो

gcc को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--cpu=<a string> default: ""

बंद कर दिया गया है: Blaze इस फ़्लैग का इस्तेमाल इंटरनल तौर पर नहीं करता है. हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा के लिए, लेगसी प्लैटफ़ॉर्म मैपिंग मौजूद हैं. इस फ़्लैग का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म की सही परिभाषा के साथ --platforms का इस्तेमाल करें.

टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.

टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.

टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.

टैग: affects_outputs

--cxxopt=<a string> कई बार इस्तेमाल किया गया हो

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू मौजूद हैं, तो सबसे बाद में सेट की गई वैल्यू का इस्तेमाल किया जाता है.

टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> default: "default"

इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: loading_and_analysis, affects_outputs

--[no]enable_propeller_optimize_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.

टैग: affects_outputs

--[no]enable_remaining_fdo_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी दिखेगी.

टैग: affects_outputs

--[no]enable_runfiles default: "auto"

रनफ़ाइल के सिमलिंक ट्री को चालू करें. Windows पर यह डिफ़ॉल्ट रूप से बंद होता है, जबकि अन्य प्लैटफ़ॉर्म पर चालू होता है.

टैग: affects_outputs

--exec_aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन पहलुओं की सूची जिन्हें एक्ज़ीक्यूटिव के कॉन्फ़िगर किए गए टारगेट पर लागू किया जाना है. भले ही, वे टॉप-लेवल के टारगेट हों या न हों. इस सुविधा पर एक्सपेरिमेंट जारी है और इसमें बदलाव हो सकता है.

टैग: loading_and_analysis

--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो

इसे पहलुओं के पक्ष में बंद कर दिया गया है. extra_action को मौजूदा बिल्ड ऐक्शन से अटैच करने के लिए, action_listener का इस्तेमाल करें.

टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "false"

APK में Java संसाधनों को कंप्रेस करना

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 default: "true"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "false"

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "false"

dex फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करें

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.

टैग: affects_outputs, experimental

--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.

टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "false"

अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.

टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off or strip> default: "off"

आउटपुट ट्री में कहां पर किस मॉडल का इस्तेमाल करना है, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, GH-6526 देखें. Starlark ऐक्शन, execution_requirements डिक्शनरी में supports-path-mapping कुंजी जोड़कर, पाथ मैपिंग की सुविधा के लिए ऑप्ट-इन कर सकते हैं.

टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_platform_cpu_name=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री label=value के फ़ॉर्मैट में होनी चाहिए. इसमें लेबल का मतलब किसी प्लैटफ़ॉर्म से है. साथ ही, वैल्यू वह छोटा नाम है जिसका इस्तेमाल करके, $(TARGET_CPU) मेक वैरिएबल और आउटपुट पाथ में प्लैटफ़ॉर्म के सीपीयू के नाम को बदला जा सकता है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform या --incompatible_bep_cpu_from_platform की वैल्यू 'सही है' पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.

टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir default: "Auto"

अगर यह विकल्प सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है:

1. अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है. ऐसा कभी-कभी होता है.
2. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है.
3. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर, छोटा नाम इस्तेमाल करें.
4. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.

टैग: affects_outputs, experimental

--[no]experimental_py_binaries_include_label डिफ़ॉल्ट: "false"

py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.

टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो collect_code_coverage चालू होने पर Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.

टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस अनुमानित तरीके में कुछ कमियां हैं. इसलिए, हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करने के लिए माइग्रेट करें.

टैग: affects_outputs, experimental

--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.

टैग: affects_outputs

--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है.जैसे, //foo/bar:file.afdo - आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है. साथ ही, यह fdo_profile टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, fdo_profile नियम की जगह लागू होगा.

टैग: affects_outputs

--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कैश मेमोरी में पहले से फ़ेच करने के सुझावों का इस्तेमाल करें.

टैग: affects_outputs

--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.

टैग: affects_outputs

--features=<a string> कई बार इस्तेमाल किया गया हो

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं. --host_features भी देखें.

टैग: changes_inputs, affects_outputs

--[no]force_pic डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, पीआईसी प्री-बिल्ट लाइब्रेरी को नॉन-पीआईसी लाइब्रेरी के मुकाबले ज़्यादा प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.

टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह उन एनवायरमेंट वैरिएबल के सेट के बारे में बताता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को name से तय किया जा सकता है. इस मामले में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर से भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name से भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.

टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

यह तय करें कि बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो

C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C (लेकिन C++) सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है.

टैग: action_command_lines, affects_outputs

--host_copt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_cpu=<a string> default: ""

होस्ट सीपीयू.

टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं.

टैग: changes_inputs, affects_outputs

--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, macOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false"

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर toolchain पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, GH-17134 देखें.

टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में शामिल किया जाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_target_cpu_from_platform default: "true"

अगर टारगेट प्लैटफ़ॉर्म के सीपीयू की सीमा (@platforms//cpu:cpu) तय की गई है, तो $(TARGET_CPU) मेक वैरिएबल सेट करने के लिए इसका इस्तेमाल किया जाता है.

टैग: loading_and_analysis, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "false"

कवरेज की सुविधा चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल नियमों की जांच की जाती है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.

टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, तय किए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को शामिल नहीं किया जाता. ध्यान दें कि सिर्फ़ टेस्ट से जुड़े नियमों को इंस्ट्रूमेंट किया जाता है. हालांकि, अगर --instrument_test_targets चालू है, तो सभी नियमों को इंस्ट्रूमेंट किया जाता है.

टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'ios_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें सभी आर्किटेक्चर शामिल होते हैं.

टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive default: "true"

इस विकल्प का इस्तेमाल अब नहीं किया जा सकता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.

टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> कई बार इस्तेमाल किया गया हो

लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ बैकएंड के चरण में पास करने का अतिरिक्त विकल्प (under --features=thin_lto).

टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (--features=thin_lto के तहत).

टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple macOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, macOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.

टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.

टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "false"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग की जानी चाहिए या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.

टैग: action_command_lines

--objccopt=<a string> कई बार इस्तेमाल किया गया हो

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto). इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों के LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller की प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller की प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल के इनपुट फ़ाइलों के बारे में होना चाहिए. उदाहरण के लिए, a/b/BUILD फ़ाइल में लेबल को इस तरह से तय किया गया है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile

टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

test और run कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू foo -bar है और एक्ज़ीक्यूशन कमांड लाइन test_binary -baz है, तो फ़ाइनल कमांड लाइन foo -bar test_binary -baz होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण यहां दिए गए हैं:

• valgrind
• strace
• strace -c
• valgrind --quiet --num-callers=20
• //package:target
• //package:target --options

टैग: action_command_lines

--[no]share_native_deps default: "true"

अगर यह वैल्यू सही है, तो एक जैसी सुविधा वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा

टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "false"

बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.

टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

इससे यह तय किया जाता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.

टैग: affects_outputs

--stripopt=<a string> कई बार इस्तेमाल किया गया हो

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple visionOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]check_visibility default: "true"

अगर यह सुविधा बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.

टैग: build_file_semantics, non_configurable

--[no]desugar_for_android default: "true"

यह तय करता है कि Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "false"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 के साथ काम करने वाली लाइब्रेरी शामिल करनी हैं या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints default: "true"

यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की डिपेंडेंसी ऐसे एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है

टैग: build_file_semantics

--[no]experimental_check_desugar_deps default: "true"

Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.

टैग: eagerness_to_exit, loading_and_analysis, experimental

--[no]experimental_enforce_transitive_visibility डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो package()s को transitive_visibility एट्रिब्यूट सेट करने की अनुमति दें. इससे यह तय किया जा सकेगा कि कौनसे पैकेज उन पर निर्भर हो सकते हैं.

टैग: build_file_semantics, experimental

--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है"

इस विकल्प को चालू करने पर, यह लागू किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल नहीं किए जा सकते. इस नीति के उल्लंघन की वजह से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.

टैग: loading_and_analysis

--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default"

अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false"

यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें

टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.

टैग: eagerness_to_exit, incompatible_change

--[no]one_version_enforcement_on_java_tests default: "true"

इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.

टैग: loading_and_analysis

--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

--incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).

टैग: loading_and_analysis

--[no]strict_filesets डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.

टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> default: "off"

अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--[no]strict_system_includes डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.

टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

यह कुकी, इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताती है. यह environment नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.

--platforms भी देखें.

टैग: 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 default: "true"

अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.

टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें

iOS पर हस्ताक्षर करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.

टैग: action_command_lines

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "false"

जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.

टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही' पर सेट है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के लिए AnalysisFailureInfo का एक इंस्टेंस जनरेट होगा. इसमें गड़बड़ी की जानकारी शामिल होगी. ऐसा, बिल्ड पूरा न होने की वजह से होगा.

टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट के ज़रिए ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.

टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो dex2oat की कार्रवाई पूरी न होने पर, टेस्ट रनटाइम के दौरान dex2oat को लागू करने के बजाय, बिल्ड रुक जाएगा.

टैग: loading_and_analysis, experimental

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. यह {resource}={value} फ़ॉर्मैट में होना चाहिए. अगर {value} के तौर पर कोई पॉज़िटिव नंबर दिया जाता है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगा. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे small, medium, large, enormous के टेस्ट साइज़ के लिए संसाधन की रकम को बदल देंगे. वैल्यू HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]{float} (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). इस फ़्लैग के ज़रिए तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को टैग में तय किए गए संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false"

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.

टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "false"

ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.

टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. जैसे, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची पाई जा सकती है.

टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर पर चलाने या टेस्ट करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.

टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो

इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी भी वजह से, इनमें से कोई भी कोशिश पूरी नहीं हो पाती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, दी गई वैल्यू सिर्फ़ एक पूर्णांक होती है.

उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे.

वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू और regex_filter का मतलब, शामिल और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें.

उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट चलाता है. हालांकि, //foo/bar में मौजूद टेस्ट को तीन बार चलाता है. इस विकल्प को कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई भी मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह विकल्प, टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को name या name=value पेयर के ज़रिए तय किया जा सकता है. अगर name के ज़रिए वैरिएबल तय किया जाता है, तो उसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. पहले से सेट किए गए वैरिएबल को =name की मदद से अनसेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.

टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> default: "-1"

जांच के टाइम आउट के लिए, जांच के टाइम आउट की डिफ़ॉल्ट वैल्यू (सेकंड में) बदलें. अगर कोई एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे short, moderate, long, और eternal के लिए टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 की वैल्यू से Blaze को यह पता चलता है कि उसे उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करना है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है, तो टेस्ट के ऐसे आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा जिनके बारे में जानकारी नहीं दी गई है.

टैग: test_runner

बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]cc_dotd_files default: "true"

.d फ़ाइलों को जनरेट और उनका विश्लेषण करना है या नहीं.

टैग: loading_and_analysis, execution, changes_inputs

--[no]cc_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false"

ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद सभी क्लास हट जाएं.

टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files default: "true"

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, रिमोट बिल्ड नोड से सीधे मेमोरी में पास किया जाएगा.

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files default: "true"

अगर यह सुविधा चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly default: "true"

इस नीति के चालू होने पर, --trim_test_configuration उन नियमों के लिए टेस्ट कॉन्फ़िगरेशन को नहीं काटेगा जिन्हें testonly=1 के तौर पर मार्क किया गया है. इसका मकसद, कार्रवाई से जुड़ी उन समस्याओं को कम करना है जो तब होती हैं, जब टेस्ट के अलावा अन्य नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.

टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing default: "true"

यह हर जार फ़ाइल के लिए, अलग-अलग डेक्सिंग का ज़्यादातर काम करता है.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning default: "true"

अगर इसे सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को कम करने के लिए किया जाएगा.

टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "false"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग चालू हो.

टैग: execution

--[no]trim_test_configuration default: "true"

यह सुविधा चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.

टैग: loading_and_analysis, loses_incremental_state

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.

टैग: terminal_output

--[no]verbose_visibility_errors डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो दिखने से जुड़ी गड़बड़ियों में गड़बड़ी की अतिरिक्त जानकारी शामिल होती है.

टैग: build_file_semantics, non_configurable

Bazel कमांड के लिए सामान्य इनपुट तय करने या उसमें बदलाव करने वाले विकल्प. ये विकल्प, अन्य कैटगरी में नहीं आते.:

--flag_alias=<a 'name=label' flag alias> कई बार इस्तेमाल किया गया हो

यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह {key}={value} के फ़ॉर्म में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.

टैग: changes_inputs, non_configurable

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "false"

इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में init.py फ़ाइलें अपने-आप न बन पाएं. जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तब इस फ़्लैग को सेट करने पर ही इसे फ़ॉल्स के तौर पर माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.

टैग: affects_outputs, incompatible_change

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] default: "auto"

अगर इसे auto पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब:

1. Bazel, टेस्ट या उसकी डिपेंडेंसी में हुए बदलावों का पता लगाता है,
2. टेस्ट को external के तौर पर मार्क किया गया हो,
3. --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या
4. यह जांच पहले पूरी नहीं हो सकी थी. अगर इसे yes पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें external के तौर पर मार्क नहीं किया गया है. अगर इसे no पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता.

--[no]experimental_cancel_concurrent_tests default: "never"

अगर on_failed या on_passed, तो Blaze उस नतीजे के साथ पहली बार सफल होने पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह नीति सिर्फ़ --runs_per_test_detects_flakes के साथ काम करेगी.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false"

अगर यह विकल्प 'सही है' पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.

टैग: affects_outputs, loading_and_analysis, experimental

--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "bazel"

यह Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ को चालू करता है.

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "false"

java_* सोर्स की पुष्टि करनी है या नहीं.

टैग: affects_outputs, experimental

--[no]explicit_java_test_deps डिफ़ॉल्ट: "false"

java_test में, TestRunner के deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.

--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो

बिल्ड के दौरान लागू होने वाले टूल बनाते समय, javac को पास किए जाने वाले अतिरिक्त विकल्प.

--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--[no]incompatible_check_sharding_support default: "true"

अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को फ़ेल कर देगा. ऐसा तब होगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में दिए गए पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, सभी टेस्ट को हर शार्ड में चलाएगा.

टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed default: "true"

अगर यह विकल्प चुना जाता है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. local टैग जोड़कर, लोकल लेवल पर सिर्फ़ एक टेस्ट रन करें

टैग: incompatible_change

--[no]incompatible_strict_action_env default: "true"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है. साथ ही, LD_LIBRARY_PATH को इनहेरिट नहीं करता है. अगर आपको क्लाइंट से कुछ खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि शेयर की गई कैश मेमोरी का इस्तेमाल करने पर, ऐसा करने से अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा.

टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.

--java_debug

इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार करती है. इसके बाद ही, टेस्ट शुरू होता है. इसका मतलब है कि -test_output=streamed.

बढ़कर:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps default: "true"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करता है. फ़िलहाल, यह कंपाइल-टाइम क्लासपाथ के लिए है.

--[no]java_header_compilation default: "true"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> default: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> default: "local_jdk"

Java रनटाइम का वर्शन

--javacopt=<a string> कई बार इस्तेमाल किया गया हो

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> कई बार इस्तेमाल किया गया हो

Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जिन्हें लेगसी मल्टीडेक्स को कंपाइल करते समय, मुख्य डेक्स में होना चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किया जाने वाला बाइनरी तय करता है.

--plugin=<a build target label> कई बार इस्तेमाल किया गया हो

बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

इससे यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.

--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.

टैग: affects_outputs, loading_and_analysis

--[no]proto_profile default: "true"

प्रोटो कंपाइलर को profile_path पास करना है या नहीं.

टैग: affects_outputs, loading_and_analysis

--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain"

proto_lang_toolchain() का लेबल, जिसमें C++ प्रोटो को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जिसमें Java protos को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जिसमें JavaLite protos को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> कई बार इस्तेमाल किया गया हो

प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का पूरा पाथ. अगर इसे सेट नहीं किया गया है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन पर सेट किया गया है (जो Bazel सर्वर शुरू करता है), तो Bazel इसका इस्तेमाल करता है. अगर दोनों में से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है;

• Windows: c:/msys64/usr/bin/bash.exe
• FreeBSD: /usr/local/bin/bash
• अन्य सभी: /bin/bash.

ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में समस्याएं आ सकती हैं.

टैग: loading_and_analysis

--test_arg=<a string> कई बार इस्तेमाल किया गया हो

इस विकल्प की मदद से, टेस्ट एक्ज़ीक्यूटेबल को पास किए जाने वाले अतिरिक्त विकल्पों और आर्ग्युमेंट के बारे में बताया जाता है. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ bazel test कमांड के लिए किया जाता है.

--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.

--test_result_expiration=<an integer> default: "-1"

इस विकल्प को बंद कर दिया गया है और इससे कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "false"

यह विकल्प, टेस्ट रनर को तुरंत फ़ॉरवर्ड करता है. टेस्ट रनर को पहली गड़बड़ी होने पर ही बंद हो जाना चाहिए.

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit"

टेस्ट शार्डिंग के लिए रणनीति तय करें:

• explicit का इस्तेमाल सिर्फ़ तब करें, जब shard_count BUILD एट्रिब्यूट मौजूद हो.
• disabled का इस्तेमाल करके, टेस्ट शार्डिंग को कभी भी इस्तेमाल न करें.
• forced=k का इस्तेमाल करके, shard_count BUILD एट्रिब्यूट की परवाह किए बिना, टेस्टिंग के लिए k शार्ड लागू करें.

--tool_java_language_version=<a string> default: ""

बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया गया Java भाषा का वर्शन

--tool_java_runtime_version=<a string> default: "remotejdk_11"

बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन

--[no]use_ijars default: "true"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इंक्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

Canonicalize-flags के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]canonicalize_policy डिफ़ॉल्ट: "false"

नीति को बड़ा करने और फ़िल्टर करने के बाद, कैननिकल नीति को आउटपुट करें. इस विकल्प को 'सही है' पर सेट करने पर, कैननिकल किए गए कमांड आर्ग्युमेंट नहीं दिखाए जाएंगे. इससे आउटपुट साफ़ रहेगा. ध्यान दें कि --for_command से तय की गई कमांड का असर, फ़िल्टर की गई नीति पर पड़ता है. अगर कोई कमांड तय नहीं की जाती है, तो डिफ़ॉल्ट कमांड 'build' होती है.

टैग: affects_outputs, terminal_output

--[no]experimental_include_default_values default: "true"

क्या Starlark के ऐसे विकल्प आउटपुट में शामिल किए गए हैं जिनकी वैल्यू डिफ़ॉल्ट पर सेट है.

टैग: affects_outputs, terminal_output

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "false"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होती है. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility default: "true"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है' पर सेट है, तो हर config_setting, हर टारगेट को दिखेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.

टैग: loading_and_analysis, incompatible_change

Bazel कमांड के लिए सामान्य इनपुट तय करने या उसमें बदलाव करने वाले विकल्प. ये विकल्प, अन्य कैटगरी में नहीं आते.:

--for_command=<a string> default: "build"

वह कमांड जिसके विकल्पों को कैननिकल किया जाना चाहिए.

टैग: affects_outputs, terminal_output

--invocation_policy=<a string> default: ""

यह उन विकल्पों पर इनवोकेशन नीति लागू करता है जिन्हें कैननिकल बनाना है.

टैग: affects_outputs, terminal_output

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD को मिटा दिया है, तो बिल्ड सिस्टम को '//x:y/z' लेबल मिलने पर शिकायत हो सकती है. ऐसा तब होता है, जब यह लेबल अब भी किसी अन्य package_path एंट्री से मिला हो. --deleted_packages x/y विकल्प का इस्तेमाल करने पर, यह समस्या नहीं होती.

--[no]fetch default: "true"

इस कमांड से बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर ऐसा कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.

--package_path=<colon-separated list of options> default: "%workspace%"

पैकेज ढूंढने की जगहों की सूची, जिसे कोलन से अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस के हिसाब से होते हैं. अगर इसे शामिल नहीं किया जाता है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट इस्तेमाल किया जाता है.

--[no]show_loading_progress default: "true"

अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

साफ़ करने के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]async डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही है' पर सेट है, तो आउटपुट को एसिंक्रोनस तरीके से साफ़ किया जाता है. इस कमांड के पूरा होने के बाद, उसी क्लाइंट में नई कमांड को सुरक्षित तरीके से लागू किया जा सकेगा. भले ही, बैकग्राउंड में डेटा मिटाने की प्रोसेस जारी रहे.

टैग: host_machine_resource_optimizations

--[no]expunge डिफ़ॉल्ट: "false"

अगर यह सही है, तो क्लीन इस Bazel इंस्टेंस के लिए पूरे वर्किंग ट्री को हटा देता है. इसमें Bazel की बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर Bazel सर्वर चल रहा है, तो उसे बंद कर देता है.

टैग: host_machine_resource_optimizations

--expunge_async

अगर बताया गया है, तो clean कमांड इस Bazel इंस्टेंस के लिए पूरे वर्किंग ट्री को एसिंक्रोनस तरीके से हटा देती है. इसमें Bazel की बनाई गई सभी अस्थायी और बिल्ड आउटपुट फ़ाइलें शामिल होती हैं. साथ ही, अगर Bazel सर्वर चल रहा है, तो उसे बंद कर देती है. इस कमांड के पूरा होने के बाद, उसी क्लाइंट में नई कमांड को सुरक्षित तरीके से लागू किया जा सकेगा. भले ही, बैकग्राउंड में डेटा मिटाने की प्रोसेस जारी रहे.

बढ़कर:
  --expunge
  --async

टैग: host_machine_resource_optimizations

कॉन्फ़िगरेशन के विकल्प

कवरेज के विकल्प

test से सभी विकल्प इनहेरिट करता है.

Cquery के विकल्प

test से सभी विकल्प इनहेरिट करता है.

क्वेरी के आउटपुट और सिमैंटिक से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> default: "conservative"

जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तब आसपेक्ट डिपेंडेंसी की समस्या कैसे हल करें. 'बंद है' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें सीधे तौर पर डिपेंडेंसी के नियम क्लास के तौर पर दिया गया हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो सीधे तौर पर डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हैं. ध्यान दें कि सटीक मोड में, एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह विश्लेषण के चरण में तय किया जाता है. यह चरण, 'bazel query' के दौरान नहीं चलता है.

टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे कि Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के हिसाब से रिपॉज़िटरी के नाम दिखा सकते हैं.

टैग: terminal_output

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "false"

aquery, cquery: क्या आउटपुट में, आसपेक्ट से जनरेट हुई कार्रवाइयों को शामिल करना है. query: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).

टैग: terminal_output

--[no]graph:factored default: "true"

अगर सही है, तो ग्राफ़ को 'फ़ैक्टर्ड' किया जाएगा. इसका मतलब है कि टोपोलॉजिकल तौर पर एक जैसे नोड को एक साथ मर्ज कर दिया जाएगा और उनके लेबल को एक साथ जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.

टैग: terminal_output

--graph:node_limit=<an integer> default: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. बड़े लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि लेबल छोटे नहीं किए जाएंगे. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.

टैग: terminal_output

--[no]implicit_deps default: "true"

अगर यह विकल्प चालू है, तो क्वेरी जिस डिपेंडेंसी ग्राफ़ पर काम करती है उसमें इंप्लिसिट डिपेंडेंसी शामिल की जाएंगी. इंप्लिसिट डिपेंडेंसी ऐसी डिपेंडेंसी होती है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया जाता, लेकिन Bazel इसे जोड़ता है. cquery के लिए, यह विकल्प हल की गई टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.

टैग: build_file_semantics

--[no]include_aspects default: "true"

aquery, cquery: क्या आउटपुट में, आसपेक्ट से जनरेट हुई कार्रवाइयों को शामिल करना है. query: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).

टैग: terminal_output

--[no]incompatible_package_group_includes_double_slash default: "true"

इस सेटिंग को चालू करने पर, package_group packages एट्रिब्यूट की वैल्यू देते समय, लीडिंग // को नहीं हटाया जाएगा.

टैग: terminal_output, incompatible_change

--[no]infer_universe_scope डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और --universe_scope को सेट नहीं किया गया है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि क्वेरी एक्सप्रेशन के लिए अनुमानित --universe_scope वैल्यू, आपकी ज़रूरत के हिसाब से नहीं हो सकती.ऐसा तब होता है, जब क्वेरी एक्सप्रेशन में यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे,allrdeps) का इस्तेमाल किया जाता है.इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करें, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query पर जाएं. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ query पर लागू होता है. इसका मतलब है कि यह cquery पर लागू नहीं होता.

टैग: loading_and_analysis

--[no]line_terminator_null डिफ़ॉल्ट: "false"

क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया गया है.

टैग: terminal_output

--[no]nodep_deps default: "true"

अगर यह विकल्प चालू है, तो "nodep" एट्रिब्यूट से मिले डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल किए जाएंगे. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, info build-language को चलाएं और उसके आउटपुट को पार्स करें.

टैग: build_file_semantics

--output=<a string> default: "label"

वह फ़ॉर्मैट जिसमें cquery के नतीजों को प्रिंट किया जाना चाहिए. cquery के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: label, label_kind, textproto, transitions, proto, streamed_proto, jsonproto. 'transitions' चुनने पर, आपको --transitions=(lite|full) विकल्प भी तय करना होगा.

टैग: terminal_output

--output_file=<a string> default: ""

इस विकल्प को सेट करने पर, क्वेरी के नतीजे सीधे इस फ़ाइल में लिखे जाएंगे. साथ ही, Bazel के स्टैंडर्ड आउटपुट स्ट्रीम (stdout) में कुछ भी प्रिंट नहीं किया जाएगा. आम तौर पर, बेंचमार्क में यह <code>bazel query > file</code> से ज़्यादा तेज़ होता है.

टैग: terminal_output

--[no]proto:default_values default: "true"

अगर यह विकल्प सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. अगर यह विकल्प गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प, --output=proto पर लागू होता है

टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "false"

definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, हर नियम इंस्टेंस के लिए Starlark कॉल स्टैक को रिकॉर्ड करता है. यह स्टैक, नियम की क्लास को तय किए जाने के समय का होता है.

टैग: terminal_output

--[no]proto:flatten_selects default: "true"

इस विकल्प को चालू करने पर, select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किया गया डेटा एक ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू ठीक एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.

टैग: build_file_semantics

--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "false"

हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, उस सोर्स पहलू की जानकारी भरें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स पहलू से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.

टैग: terminal_output

--[no]proto:include_configurations default: "true"

अगर यह विकल्प चालू है, तो प्रोटो आउटपुट में कॉन्फ़िगरेशन के बारे में जानकारी शामिल होगी. इस सुविधा के बंद होने पर, cquery प्रोटो आउटपुट फ़ॉर्मैट, क्वेरी आउटपुट फ़ॉर्मैट जैसा दिखता है.

टैग: affects_outputs

--[no]proto:include_starlark_rule_env default: "true"

जनरेट किए गए $internal_attr_hash एट्रिब्यूट की वैल्यू में, Starlark एनवायरमेंट का इस्तेमाल करें. इससे यह पक्का होता है कि स्टार्लार्क नियम की परिभाषा (और इसके ट्रांज़िटिव इंपोर्ट) इस आइडेंटिफ़ायर का हिस्सा हैं.

टैग: terminal_output

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "false"

$internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.

टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "false"

हर नियम के इंस्टैंटिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए, स्टैक का मौजूद होना ज़रूरी है

टैग: terminal_output

--[no]proto:locations default: "true"

जगह की जानकारी को प्रोटो आउटपुट में दिखाना है या नहीं.

टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> default: "all"

आउटपुट में शामिल करने के लिए एट्रिब्यूट की कॉमा लगाकर बनाई गई सूची. डिफ़ॉल्ट रूप से, सभी एट्रिब्यूट के लिए लागू होता है. किसी भी एट्रिब्यूट को आउटपुट न करने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प, --output=proto पर लागू होता है.

टैग: terminal_output

--[no]proto:rule_classes डिफ़ॉल्ट: "false"

हर नियम के rule_class_key फ़ील्ड में वैल्यू डालें. साथ ही, दिए गए rule_class_key वाले पहले नियम के लिए, उसके rule_class_info proto फ़ील्ड में भी वैल्यू डालें. rule_class_key फ़ील्ड, नियम क्लास की खास तौर पर पहचान करता है. साथ ही, rule_class_info फ़ील्ड, Stardoc फ़ॉर्मैट में नियम क्लास की एपीआई डेफ़िनिशन है.

टैग: terminal_output

--[no]proto:rule_inputs_and_outputs default: "true"

rule_input और rule_output फ़ील्ड में वैल्यू डालनी है या नहीं.

टैग: terminal_output

--query_file=<a string> default: ""

अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.

टैग: changes_inputs

--[no]relative_locations डिफ़ॉल्ट: "false"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह की जानकारी, रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह अलग-अलग मशीनों पर एक जैसा नहीं होता. इस विकल्प को true पर सेट करके, सभी मशीनों पर एक जैसा नतीजा पाया जा सकता है.

टैग: terminal_output

--show_config_fragments=<off, direct or transitive> default: "off"

इससे उन कॉन्फ़िगरेशन फ़्रैगमेंट के बारे में पता चलता है जिनकी ज़रूरत किसी नियम और उसकी ट्रांज़िटिव डिपेंडेंसी के लिए होती है. इससे यह पता लगाने में मदद मिल सकती है कि कॉन्फ़िगर किए गए टारगेट ग्राफ़ को कितना कम किया जा सकता है.

टैग: affects_outputs

--starlark:expr=<a string> default: ""

cquery के --output=starlark मोड में, कॉन्फ़िगर किए गए हर टारगेट को फ़ॉर्मैट करने के लिए Starlark एक्सप्रेशन. कॉन्फ़िगर किया गया टारगेट, 'target' से जुड़ा होता है. अगर --starlark:expr या --starlark:file में से किसी को भी तय नहीं किया गया है, तो यह विकल्प डिफ़ॉल्ट रूप से 'str(target.label)' पर सेट होगा. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल नहीं किया जा सकता.

टैग: terminal_output

--starlark:file=<a string> default: ""

यह उस फ़ाइल का नाम है जो 'format' नाम के Starlark फ़ंक्शन को तय करती है. इसमें एक आर्ग्युमेंट होता है. इसे हर कॉन्फ़िगर किए गए टारगेट पर लागू किया जाता है, ताकि उसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जा सके. --starlark:expr और --starlark:file, दोनों को एक साथ इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, --output=starlark के लिए सहायता देखें.

टैग: terminal_output

--[no]tool_deps default: "true"

क्वेरी: अगर यह सुविधा बंद है, तो 'एक्ज़ीक्यूशन कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'exec configuration' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से लेकर प्रोटोकॉल कंपाइलर तक, आम तौर पर उसी 'target' प्रोग्राम के किसी हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल की ओर इशारा करता है. Cquery: अगर यह सुविधा बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर दिया जाता है जो टॉप-लेवल के उस टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं जिसने इस कॉन्फ़िगर किए गए टारगेट का पता लगाया था. इसका मतलब है कि अगर टॉप-लेवल का टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प से, हल की गई टूलचेन को शामिल नहीं किया जाएगा.

टैग: build_file_semantics

--transitions=<full, lite or none> डिफ़ॉल्ट: "none"

यह वह फ़ॉर्मैट है जिसमें cquery, ट्रांज़िशन की जानकारी प्रिंट करेगा.

टैग: affects_outputs

--universe_scope=<comma-separated list of options> default: ""

कॉमा लगाकर अलग किए गए टारगेट पैटर्न का सेट (जोड़ने और घटाने वाले). क्वेरी को, तय किए गए टारगेट के ट्रांज़िटिव क्लोज़र से तय किए गए यूनिवर्स में किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट होते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर इस विकल्प के बारे में नहीं बताया जाता है, तो यह माना जाता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के टारगेट हैं. ध्यान दें: cquery के लिए, इस विकल्प को तय न करने पर, बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ नहीं बनाए जा सकते.

टैग: loading_and_analysis

बिल्ड के एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false"

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.

टैग: execution, experimental

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट कार्रवाइयों को रिमोट किया जा सकता है या नहीं

टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false"

सही होने पर, Bazel टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.

टैग: execution, experimental

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.

टैग: execution, experimental

--[no]incompatible_modify_execution_info_additive default: "true"

इस सुविधा के चालू होने पर, एक से ज़्यादा --modify_execution_info फ़्लैग पास करने पर, उन्हें जोड़ दिया जाता है. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.

टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो

कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई के एक्ज़ीक्यूशन की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, और TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि एक ही नेमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.

सिंटैक्स: regex=[+-]key,regex=[+-]key,....

उदाहरण:

• .*=+x,.*=-y,.*=+z सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में x और z जोड़ता है. साथ ही, y को हटाता है.
• Genrule=+requires-x, Genrule की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में requires-x जोड़ता है.
• (?!Genrule).*=-requires-x, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से requires-x हटा देता है.

टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू करें.

बढ़कर:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को लगातार चालू रखें.

बढ़कर:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार कई बार चलाने की सुविधा चालू करें.

बढ़कर:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.

इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (डेक्सिंग, डिसुगरिंग, संसाधन प्रोसेसिंग) चालू करें.

बढ़कर:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो टेस्ट चलाने के लिए टेस्ट एक्ज़ेक ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करें.

टैग: execution

ऐक्शन लागू करने के लिए इस्तेमाल की जाने वाली टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Android टारगेट कंपाइलर.

टैग: affects_outputs, 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> default: ""

यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.

टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--cc_output_directory_tag=<a string> default: ""

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.

टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger"

उस बाइनरी का पाथ जिसका इस्तेमाल, रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:lcov_merger पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी की जगह. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:coverage_report_generator पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support"

सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, यह //tools/test:coverage_support पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह विकल्प, malloc को लागू करने का कस्टम तरीका तय करता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.

टैग: changes_inputs, affects_outputs

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "false"

अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.

टैग: loses_incremental_state, loading_and_analysis, execution, experimental

--[no]experimental_prefer_mutual_xcode default: "true"

अगर यह नीति 'सही है' पर सेट है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए Xcode के लोकल वर्शन का इस्तेमाल करें.

टैग: loses_incremental_state, experimental

--extra_execution_platforms=<comma-separated list of options> default: ""

कार्रवाइयां करने के लिए, इन प्लैटफ़ॉर्म का इस्तेमाल किया जा सकता है. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. register_execution_platforms() की ओर से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद में, फ़्लैग की गई सेटिंग पहले की सेटिंग को बदल देंगी.

टैग: execution

--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() की ओर से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले माना जाएगा.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.

टैग: action_command_lines, affects_outputs

--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

यह फ़्लैग कोई कार्रवाई नहीं करता. आने वाले समय में इसे हटा दिया जाएगा.

टैग: loading_and_analysis, execution

--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

अगर यह सेटिंग तय की जाती है, तो exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.

टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform"

होस्ट सिस्टम की जानकारी देने वाले प्लैटफ़ॉर्म के नियम का लेबल.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_bazel_test_exec_run_under default: "true"

अगर यह सुविधा चालू है, तो bazel test --run_under=//:runner, exec configuration में //:runner बनाता है. अगर यह सुविधा बंद है, तो टारगेट कॉन्फ़िगरेशन में //:runner बनाया जाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे bazel run पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में --run_under=//foo बनाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_builtin_objc_strip_action default: "true"

यह तय करता है कि objc लिंकिंग के हिस्से के तौर पर स्ट्रिप ऐक्शन को चालू करना है या नहीं.

टैग: action_command_lines, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true"

अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाएं चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false"

ऐपल के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive default: "true"

अगर यह विकल्प सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.

टैग: action_command_lines, incompatible_change

--[no]interface_shared_objects default: "true"

अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल करने की सुविधा है, तो उनका इस्तेमाल करें. फ़िलहाल, सभी 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 main workspace-relative path> default: ""

मैपिंग फ़ाइल की जगह. इससे यह पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो कौनसा प्लैटफ़ॉर्म इस्तेमाल करना है या अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसा फ़्लैग सेट करना है. यह मुख्य वर्कस्पेस रूट से जुड़ा होना चाहिए. डिफ़ॉल्ट रूप से, यह platform_mappings (वर्कस्पेस रूट के ठीक नीचे मौजूद फ़ाइल) पर सेट होता है.

टैग: affects_outputs, changes_inputs, loading_and_analysis, non_configurable

--platforms=<a build target label> default: ""

प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains ने बंद कर दिया है.

टैग: loading_and_analysis, affects_outputs

--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

यह tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK टूल का वर्शन तय करता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से tvOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--[no]use_platforms_in_apple_crosstool_transition डिफ़ॉल्ट: "false"

इससे apple_crosstool_transition, ज़रूरत पड़ने पर लेगसी --cpu के बजाय --platforms फ़्लैग की वैल्यू का इस्तेमाल करता है.

टैग: loading_and_analysis

--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

यह watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें

अगर बताया गया है, तो यह संबंधित बिल्ड कार्रवाइयों के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी जाती है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes"

यह xcode_config नियम का लेबल है. इसका इस्तेमाल, बिल्ड कॉन्फ़िगरेशन में Xcode का वर्शन चुनने के लिए किया जाता है.

टैग: loses_incremental_state, loading_and_analysis

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]apple_generate_dsym डिफ़ॉल्ट: "false"

डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करनी हैं या नहीं.

टैग: affects_outputs, action_command_lines

--[no]build_runfile_links default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.

टैग: affects_outputs

--[no]build_runfile_manifests default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर ये गलत हैं, तो इन्हें शामिल न करें. इस विकल्प के गलत होने पर, स्थानीय जांच नहीं हो पाएंगी.

टैग: affects_outputs

--[no]build_test_dwp डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.

टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h"

यह cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc"

यह विकल्प, cc_proto_library से बनाई गई सोर्स फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "false"

proto_library में Java api के वैकल्पिक वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "false"

इस कुकी का इस्तेमाल, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को कंपाइल करने के आउटपुट के तौर पर सेव करने के लिए किया जाता है.

टैग: affects_outputs, experimental

--fission=<a set of compilation modes> डिफ़ॉल्ट: "no"

इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल करने वाले कंपाइलेशन मोड कौनसे हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.

टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम अपनी रनफ़ाइल में DefaultInfo.files डेटा डिपेंडेंसी जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाती है (रनफ़ाइल की ऐसी सुविधाएं जिनका इस्तेमाल नहीं करना चाहिए).

टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest default: "true"

चालू होने पर, {binary}.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन के रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन से जनरेट होने वाले हर रेपो के लिए एक बार दिखाने के बजाय, रनफ़ाइलें योगदान करती हैं.

टैग: affects_outputs, incompatible_change

--incompatible_disable_select_on=<comma-separated set of options> default: ""

उन फ़्लैग की सूची जिनके लिए select() में इस्तेमाल करने की सुविधा बंद है.

टैग: loading_and_analysis, incompatible_change, non_configurable

--[no]incompatible_filegroup_runfiles_for_data default: "true"

अगर यह सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें, उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.

टैग: incompatible_change

--[no]objc_generate_linkmap डिफ़ॉल्ट: "false"

इससे यह तय किया जाता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.

टैग: affects_outputs

--[no]save_temps डिफ़ॉल्ट: "false"

अगर यह सेट है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C), और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.

टैग: affects_outputs

ऐसे विकल्प जिनसे उपयोगकर्ता, वैरिएबल के आउटपुट को कॉन्फ़िगर कर सकता है. इससे वैरिएबल की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को name के ज़रिए तय किया जा सकता है. ऐसे में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. वहीं, अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को जोड़ दिया जाता है.

ध्यान दें कि जब तक --incompatible_repo_env_ignores_action_env सही नहीं होता, तब तक सभी name=value जोड़े, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.

टैग: action_command_lines

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.

टैग: changes_inputs, affects_outputs

--[no]android_databinding_use_androidx default: "true"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args default: "true"

3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> default: "off"

इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तो Android नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical"

यह विकल्प, Android बाइनरी के लिए मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. ALPHABETICAL का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से पाथ के हिसाब से क्रम से लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस तरह से क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.

टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "false"

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis

--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

उन आर्किटेक्चर की कॉमा लगाकर अलग की गई सूची जिनके लिए Apple Catalyst बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मेल खाते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं चुना जाना चाहिए. इसके बजाय, bazel coverage कमांड का इस्तेमाल करना चाहिए.

टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

उस मोड के बारे में बताएं जिसमें बाइनरी बनाई जाएगी. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--conlyopt=<a string> कई बार इस्तेमाल किया गया हो

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--copt=<a string> कई बार इस्तेमाल किया गया हो

gcc को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--cpu=<a string> default: ""

बंद कर दिया गया है: Blaze इस फ़्लैग का इस्तेमाल इंटरनल तौर पर नहीं करता है. हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा के लिए, लेगसी प्लैटफ़ॉर्म मैपिंग मौजूद हैं. इस फ़्लैग का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म की सही परिभाषा के साथ --platforms का इस्तेमाल करें.

टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.

टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.

टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.

टैग: affects_outputs

--cxxopt=<a string> कई बार इस्तेमाल किया गया हो

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू मौजूद हैं, तो सबसे बाद में सेट की गई वैल्यू का इस्तेमाल किया जाता है.

टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> default: "default"

इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: loading_and_analysis, affects_outputs

--[no]enable_propeller_optimize_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.

टैग: affects_outputs

--[no]enable_remaining_fdo_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी दिखेगी.

टैग: affects_outputs

--[no]enable_runfiles default: "auto"

रनफ़ाइल के सिमलिंक ट्री को चालू करें. Windows पर यह डिफ़ॉल्ट रूप से बंद होता है, जबकि अन्य प्लैटफ़ॉर्म पर चालू होता है.

टैग: affects_outputs

--exec_aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन पहलुओं की सूची जिन्हें एक्ज़ीक्यूटिव के कॉन्फ़िगर किए गए टारगेट पर लागू किया जाना है. भले ही, वे टॉप-लेवल के टारगेट हों या न हों. इस सुविधा पर एक्सपेरिमेंट जारी है और इसमें बदलाव हो सकता है.

टैग: loading_and_analysis

--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो

इसे पहलुओं के पक्ष में बंद कर दिया गया है. extra_action को मौजूदा बिल्ड ऐक्शन से अटैच करने के लिए, action_listener का इस्तेमाल करें.

टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "false"

APK में Java संसाधनों को कंप्रेस करना

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 default: "true"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "false"

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "false"

dex फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करें

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.

टैग: affects_outputs, experimental

--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.

टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "false"

अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.

टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off or strip> default: "off"

आउटपुट ट्री में कहां पर किस मॉडल का इस्तेमाल करना है, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, GH-6526 देखें. Starlark ऐक्शन, execution_requirements डिक्शनरी में supports-path-mapping कुंजी जोड़कर, पाथ मैपिंग की सुविधा के लिए ऑप्ट-इन कर सकते हैं.

टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_platform_cpu_name=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री label=value के फ़ॉर्मैट में होनी चाहिए. इसमें लेबल का मतलब किसी प्लैटफ़ॉर्म से है. साथ ही, वैल्यू वह छोटा नाम है जिसका इस्तेमाल करके, $(TARGET_CPU) मेक वैरिएबल और आउटपुट पाथ में प्लैटफ़ॉर्म के सीपीयू के नाम को बदला जा सकता है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform या --incompatible_bep_cpu_from_platform की वैल्यू 'सही है' पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.

टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir default: "Auto"

अगर यह विकल्प सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है:

1. अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है. ऐसा कभी-कभी होता है.
2. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है.
3. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर, छोटा नाम इस्तेमाल करें.
4. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.

टैग: affects_outputs, experimental

--[no]experimental_py_binaries_include_label डिफ़ॉल्ट: "false"

py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.

टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो collect_code_coverage चालू होने पर Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.

टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस अनुमानित तरीके में कुछ कमियां हैं. इसलिए, हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करने के लिए माइग्रेट करें.

टैग: affects_outputs, experimental

--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.

टैग: affects_outputs

--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है.जैसे, //foo/bar:file.afdo - आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है. साथ ही, यह fdo_profile टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, fdo_profile नियम की जगह लागू होगा.

टैग: affects_outputs

--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कैश मेमोरी में पहले से फ़ेच करने के सुझावों का इस्तेमाल करें.

टैग: affects_outputs

--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.

टैग: affects_outputs

--features=<a string> कई बार इस्तेमाल किया गया हो

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं. --host_features भी देखें.

टैग: changes_inputs, affects_outputs

--[no]force_pic डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, पीआईसी प्री-बिल्ट लाइब्रेरी को नॉन-पीआईसी लाइब्रेरी के मुकाबले ज़्यादा प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.

टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह उन एनवायरमेंट वैरिएबल के सेट के बारे में बताता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को name से तय किया जा सकता है. इस मामले में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर से भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name से भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.

टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

यह तय करें कि बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो

C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C (लेकिन C++) सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है.

टैग: action_command_lines, affects_outputs

--host_copt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_cpu=<a string> default: ""

होस्ट सीपीयू.

टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं.

टैग: changes_inputs, affects_outputs

--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, macOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false"

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर toolchain पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, GH-17134 देखें.

टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में शामिल किया जाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_target_cpu_from_platform default: "true"

अगर टारगेट प्लैटफ़ॉर्म के सीपीयू की सीमा (@platforms//cpu:cpu) तय की गई है, तो $(TARGET_CPU) मेक वैरिएबल सेट करने के लिए इसका इस्तेमाल किया जाता है.

टैग: loading_and_analysis, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "false"

कवरेज की सुविधा चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल नियमों की जांच की जाती है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.

टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, तय किए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को शामिल नहीं किया जाता. ध्यान दें कि सिर्फ़ टेस्ट से जुड़े नियमों को इंस्ट्रूमेंट किया जाता है. हालांकि, अगर --instrument_test_targets चालू है, तो सभी नियमों को इंस्ट्रूमेंट किया जाता है.

टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'ios_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें सभी आर्किटेक्चर शामिल होते हैं.

टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive default: "true"

इस विकल्प का इस्तेमाल अब नहीं किया जा सकता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.

टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> कई बार इस्तेमाल किया गया हो

लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ बैकएंड के चरण में पास करने का अतिरिक्त विकल्प (under --features=thin_lto).

टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (--features=thin_lto के तहत).

टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple macOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, macOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.

टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.

टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "false"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग की जानी चाहिए या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.

टैग: action_command_lines

--objccopt=<a string> कई बार इस्तेमाल किया गया हो

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto). इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों के LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller की प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller की प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल के इनपुट फ़ाइलों के बारे में होना चाहिए. उदाहरण के लिए, a/b/BUILD फ़ाइल में लेबल को इस तरह से तय किया गया है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile

टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

test और run कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू foo -bar है और एक्ज़ीक्यूशन कमांड लाइन test_binary -baz है, तो फ़ाइनल कमांड लाइन foo -bar test_binary -baz होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण यहां दिए गए हैं:

• valgrind
• strace
• strace -c
• valgrind --quiet --num-callers=20
• //package:target
• //package:target --options

टैग: action_command_lines

--[no]share_native_deps default: "true"

अगर यह वैल्यू सही है, तो एक जैसी सुविधा वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा

टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "false"

बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.

टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

इससे यह तय किया जाता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.

टैग: affects_outputs

--stripopt=<a string> कई बार इस्तेमाल किया गया हो

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple visionOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]check_visibility default: "true"

अगर यह सुविधा बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.

टैग: build_file_semantics, non_configurable

--[no]desugar_for_android default: "true"

यह तय करता है कि Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "false"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 के साथ काम करने वाली लाइब्रेरी शामिल करनी हैं या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints default: "true"

यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की डिपेंडेंसी ऐसे एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है

टैग: build_file_semantics

--[no]experimental_check_desugar_deps default: "true"

Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.

टैग: eagerness_to_exit, loading_and_analysis, experimental

--[no]experimental_enforce_transitive_visibility डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो package()s को transitive_visibility एट्रिब्यूट सेट करने की अनुमति दें. इससे यह तय किया जा सकेगा कि कौनसे पैकेज उन पर निर्भर हो सकते हैं.

टैग: build_file_semantics, experimental

--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है"

इस विकल्प को चालू करने पर, यह लागू किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल नहीं किए जा सकते. इस नीति के उल्लंघन की वजह से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.

टैग: loading_and_analysis

--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default"

अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false"

यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें

टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.

टैग: eagerness_to_exit, incompatible_change

--[no]one_version_enforcement_on_java_tests default: "true"

इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.

टैग: loading_and_analysis

--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

--incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).

टैग: loading_and_analysis

--[no]strict_filesets डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.

टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> default: "off"

अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--[no]strict_system_includes डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.

टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

यह कुकी, इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताती है. यह environment नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.

--platforms भी देखें.

टैग: 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 default: "true"

अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.

टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें

iOS पर हस्ताक्षर करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.

टैग: action_command_lines

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "false"

जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.

टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही' पर सेट है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के लिए AnalysisFailureInfo का एक इंस्टेंस जनरेट होगा. इसमें गड़बड़ी की जानकारी शामिल होगी. ऐसा, बिल्ड पूरा न होने की वजह से होगा.

टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट के ज़रिए ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.

टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो dex2oat की कार्रवाई पूरी न होने पर, टेस्ट रनटाइम के दौरान dex2oat को लागू करने के बजाय, बिल्ड रुक जाएगा.

टैग: loading_and_analysis, experimental

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. यह {resource}={value} फ़ॉर्मैट में होना चाहिए. अगर {value} के तौर पर कोई पॉज़िटिव नंबर दिया जाता है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगा. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे small, medium, large, enormous के टेस्ट साइज़ के लिए संसाधन की रकम को बदल देंगे. वैल्यू HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]{float} (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). इस फ़्लैग के ज़रिए तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को टैग में तय किए गए संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false"

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.

टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "false"

ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.

टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. जैसे, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची पाई जा सकती है.

टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर पर चलाने या टेस्ट करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.

टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो

इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी भी वजह से, इनमें से कोई भी कोशिश पूरी नहीं हो पाती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, दी गई वैल्यू सिर्फ़ एक पूर्णांक होती है.

उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे.

वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू और regex_filter का मतलब, शामिल और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें.

उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट चलाता है. हालांकि, //foo/bar में मौजूद टेस्ट को तीन बार चलाता है. इस विकल्प को कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई भी मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह विकल्प, टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को name या name=value पेयर के ज़रिए तय किया जा सकता है. अगर name के ज़रिए वैरिएबल तय किया जाता है, तो उसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. पहले से सेट किए गए वैरिएबल को =name की मदद से अनसेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.

टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> default: "-1"

जांच के टाइम आउट के लिए, जांच के टाइम आउट की डिफ़ॉल्ट वैल्यू (सेकंड में) बदलें. अगर कोई एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे short, moderate, long, और eternal के लिए टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 की वैल्यू से Blaze को यह पता चलता है कि उसे उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करना है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है, तो टेस्ट के ऐसे आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा जिनके बारे में जानकारी नहीं दी गई है.

टैग: test_runner

बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]cc_dotd_files default: "true"

.d फ़ाइलों को जनरेट और उनका विश्लेषण करना है या नहीं.

टैग: loading_and_analysis, execution, changes_inputs

--[no]cc_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false"

ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद सभी क्लास हट जाएं.

टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files default: "true"

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, रिमोट बिल्ड नोड से सीधे मेमोरी में पास किया जाएगा.

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files default: "true"

अगर यह सुविधा चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly default: "true"

इस नीति के चालू होने पर, --trim_test_configuration उन नियमों के लिए टेस्ट कॉन्फ़िगरेशन को नहीं काटेगा जिन्हें testonly=1 के तौर पर मार्क किया गया है. इसका मकसद, कार्रवाई से जुड़ी उन समस्याओं को कम करना है जो तब होती हैं, जब टेस्ट के अलावा अन्य नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.

टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing default: "true"

यह हर जार फ़ाइल के लिए, अलग-अलग डेक्सिंग का ज़्यादातर काम करता है.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning default: "true"

अगर इसे सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को कम करने के लिए किया जाएगा.

टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "false"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग चालू हो.

टैग: execution

--[no]trim_test_configuration default: "true"

यह सुविधा चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.

टैग: loading_and_analysis, loses_incremental_state

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.

टैग: terminal_output

--[no]verbose_visibility_errors डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो दिखने से जुड़ी गड़बड़ियों में गड़बड़ी की अतिरिक्त जानकारी शामिल होती है.

टैग: build_file_semantics, non_configurable

Bazel कमांड के लिए सामान्य इनपुट तय करने या उसमें बदलाव करने वाले विकल्प. ये विकल्प, अन्य कैटगरी में नहीं आते.:

--flag_alias=<a 'name=label' flag alias> कई बार इस्तेमाल किया गया हो

यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह {key}={value} के फ़ॉर्म में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.

टैग: changes_inputs, non_configurable

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "false"

इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में init.py फ़ाइलें अपने-आप न बन पाएं. जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तब इस फ़्लैग को सेट करने पर ही इसे फ़ॉल्स के तौर पर माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.

टैग: affects_outputs, incompatible_change

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] default: "auto"

अगर इसे auto पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब:

1. Bazel, टेस्ट या उसकी डिपेंडेंसी में हुए बदलावों का पता लगाता है,
2. टेस्ट को external के तौर पर मार्क किया गया हो,
3. --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या
4. यह जांच पहले पूरी नहीं हो सकी थी. अगर इसे yes पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें external के तौर पर मार्क नहीं किया गया है. अगर इसे no पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता.

--[no]experimental_cancel_concurrent_tests default: "never"

अगर on_failed या on_passed, तो Blaze उस नतीजे के साथ पहली बार सफल होने पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह नीति सिर्फ़ --runs_per_test_detects_flakes के साथ काम करेगी.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false"

अगर यह विकल्प 'सही है' पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.

टैग: affects_outputs, loading_and_analysis, experimental

--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "bazel"

यह Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ को चालू करता है.

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "false"

java_* सोर्स की पुष्टि करनी है या नहीं.

टैग: affects_outputs, experimental

--[no]explicit_java_test_deps डिफ़ॉल्ट: "false"

java_test में, TestRunner के deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.

--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो

बिल्ड के दौरान लागू होने वाले टूल बनाते समय, javac को पास किए जाने वाले अतिरिक्त विकल्प.

--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--[no]incompatible_check_sharding_support default: "true"

अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को फ़ेल कर देगा. ऐसा तब होगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में दिए गए पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, सभी टेस्ट को हर शार्ड में चलाएगा.

टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed default: "true"

अगर यह विकल्प चुना जाता है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. local टैग जोड़कर, लोकल लेवल पर सिर्फ़ एक टेस्ट रन करें

टैग: incompatible_change

--[no]incompatible_strict_action_env default: "true"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है. साथ ही, LD_LIBRARY_PATH को इनहेरिट नहीं करता है. अगर आपको क्लाइंट से कुछ खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि शेयर की गई कैश मेमोरी का इस्तेमाल करने पर, ऐसा करने से अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा.

टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.

--java_debug

इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार करती है. इसके बाद ही, टेस्ट शुरू होता है. इसका मतलब है कि -test_output=streamed.

बढ़कर:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps default: "true"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करता है. फ़िलहाल, यह कंपाइल-टाइम क्लासपाथ के लिए है.

--[no]java_header_compilation default: "true"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> default: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> default: "local_jdk"

Java रनटाइम का वर्शन

--javacopt=<a string> कई बार इस्तेमाल किया गया हो

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> कई बार इस्तेमाल किया गया हो

Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जिन्हें लेगसी मल्टीडेक्स को कंपाइल करते समय, मुख्य डेक्स में होना चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किया जाने वाला बाइनरी तय करता है.

--plugin=<a build target label> कई बार इस्तेमाल किया गया हो

बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

इससे यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.

--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.

टैग: affects_outputs, loading_and_analysis

--[no]proto_profile default: "true"

प्रोटो कंपाइलर को profile_path पास करना है या नहीं.

टैग: affects_outputs, loading_and_analysis

--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain"

proto_lang_toolchain() का लेबल, जिसमें C++ प्रोटो को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जिसमें Java protos को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जिसमें JavaLite protos को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> कई बार इस्तेमाल किया गया हो

प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का पूरा पाथ. अगर इसे सेट नहीं किया गया है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन पर सेट किया गया है (जो Bazel सर्वर शुरू करता है), तो Bazel इसका इस्तेमाल करता है. अगर दोनों में से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है;

• Windows: c:/msys64/usr/bin/bash.exe
• FreeBSD: /usr/local/bin/bash
• अन्य सभी: /bin/bash.

ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में समस्याएं आ सकती हैं.

टैग: loading_and_analysis

--test_arg=<a string> कई बार इस्तेमाल किया गया हो

इस विकल्प की मदद से, टेस्ट एक्ज़ीक्यूटेबल को पास किए जाने वाले अतिरिक्त विकल्पों और आर्ग्युमेंट के बारे में बताया जाता है. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ bazel test कमांड के लिए किया जाता है.

--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.

--test_result_expiration=<an integer> default: "-1"

इस विकल्प को बंद कर दिया गया है और इससे कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "false"

यह विकल्प, टेस्ट रनर को तुरंत फ़ॉरवर्ड करता है. टेस्ट रनर को पहली गड़बड़ी होने पर ही बंद हो जाना चाहिए.

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit"

टेस्ट शार्डिंग के लिए रणनीति तय करें:

• explicit का इस्तेमाल सिर्फ़ तब करें, जब shard_count BUILD एट्रिब्यूट मौजूद हो.
• disabled का इस्तेमाल करके, टेस्ट शार्डिंग को कभी भी इस्तेमाल न करें.
• forced=k का इस्तेमाल करके, shard_count BUILD एट्रिब्यूट की परवाह किए बिना, टेस्टिंग के लिए k शार्ड लागू करें.

--tool_java_language_version=<a string> default: ""

बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया गया Java भाषा का वर्शन

--tool_java_runtime_version=<a string> default: "remotejdk_11"

बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन

--[no]use_ijars default: "true"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इंक्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

डंप के विकल्प

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]action_cache डिफ़ॉल्ट: "false"

ऐक्शन कैश मेमोरी में सेव किए गए कॉन्टेंट को डंप करें.

टैग: bazel_monitoring

--memory=<memory mode> डिफ़ॉल्ट: ब्यौरा देखें

दिए गए Skyframe नोड के लिए, मेमोरी के इस्तेमाल की जानकारी डंप करें.

टैग: bazel_monitoring

--[no]packages डिफ़ॉल्ट: "false"

पैकेज की कैश मेमोरी में सेव किए गए कॉन्टेंट को डंप करें.

टैग: bazel_monitoring

--[no]rule_classes डिफ़ॉल्ट: "false"

डंप नियम क्लास.

टैग: bazel_monitoring

--[no]rules डिफ़ॉल्ट: "false"

डंप के नियम, जिनमें मेमोरी के इस्तेमाल की संख्या और जानकारी शामिल है (अगर मेमोरी को ट्रैक किया जाता है).

टैग: bazel_monitoring

--skyframe=<off, summary, count, value, deps, rdeps, function_graph, active_directories or active_directories_frontier_deps> default: "off"

Skyframe ग्राफ़ को डंप करो.

टैग: bazel_monitoring

--skykey_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: ".*"

आउटपुट के लिए SkyKey के नामों का रेगुलर एक्सप्रेशन वाला फ़िल्टर. इसका इस्तेमाल सिर्फ़ --skyframe=deps, rdeps, function_graph के साथ किया जाता है.

टैग: bazel_monitoring

--skylark_memory=<a string> डिफ़ॉल्ट: ब्यौरा देखें

यह कमांड, pprof के साथ काम करने वाली मेमोरी प्रोफ़ाइल को तय किए गए पाथ पर डंप करती है. ज़्यादा जानने के लिए, कृपया https://github.com/google/pprof पर जाएं.

टैग: bazel_monitoring

डेटा फ़ेच करने के विकल्प

test से सभी विकल्प इनहेरिट करता है.

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]all डिफ़ॉल्ट: "false"

यह किसी टारगेट या रिपॉज़िटरी को बनाने के लिए ज़रूरी सभी बाहरी रिपॉज़िटरी को फ़ेच करता है. अगर कोई अन्य फ़्लैग और तर्क नहीं दिया गया है, तो यह डिफ़ॉल्ट रूप से लागू होता है. यह सुविधा सिर्फ़ तब काम करती है, जब --enable_bzlmod चालू हो.

टैग: changes_inputs

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.

टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto"

डेटा लोड करने/विश्लेषण करने के लिए, एक साथ इस्तेमाल की जाने वाली थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS.5". "auto" विकल्प, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करता है. कम से कम 1 होना चाहिए

टैग: bazel_internal_configuration

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "false"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होती है. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility default: "true"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है' पर सेट है, तो हर config_setting, हर टारगेट को दिखेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.

टैग: loading_and_analysis, incompatible_change

Bzlmod के आउटपुट और सिमैंटिक्स से जुड़े विकल्प:

--[no]configure डिफ़ॉल्ट: "false"

सिर्फ़ उन रिपॉज़िटरी को फ़ेच करता है जिन्हें सिस्टम कॉन्फ़िगरेशन के मकसद से configure के तौर पर मार्क किया गया है. इसका इस्तेमाल सिर्फ़ तब किया जा सकता है, जब --enable_bzlmod चालू हो.

टैग: changes_inputs

--[no]force डिफ़ॉल्ट: "false"

अगर कोई मौजूदा रिपॉज़िटरी है, तो उसे अनदेखा करें और रिपॉज़िटरी को फिर से फ़ेच करें. यह सुविधा सिर्फ़ तब काम करती है, जब --enable_bzlmod चालू हो.

टैग: changes_inputs

--repo=<a string> कई बार इस्तेमाल किया गया हो

यह सिर्फ़ चुनी गई रिपॉज़िटरी को फ़ेच करता है. यह रिपॉज़िटरी @apparent_repo_name या @@canonical_repo_name हो सकती है. यह सुविधा सिर्फ़ तब काम करती है, जब --enable_bzlmod चालू हो.

टैग: changes_inputs

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD को मिटा दिया है, तो बिल्ड सिस्टम को '//x:y/z' लेबल मिलने पर शिकायत हो सकती है. ऐसा तब होता है, जब यह लेबल अब भी किसी अन्य package_path एंट्री से मिला हो. --deleted_packages x/y विकल्प का इस्तेमाल करने पर, यह समस्या नहीं होती.

--[no]fetch default: "true"

इस कमांड से बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर ऐसा कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.

--package_path=<colon-separated list of options> default: "%workspace%"

पैकेज ढूंढने की जगहों की सूची, जिसे कोलन से अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस के हिसाब से होते हैं. अगर इसे शामिल नहीं किया जाता है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट इस्तेमाल किया जाता है.

--[no]show_loading_progress default: "true"

अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

बिल्ड के एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false"

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.

टैग: execution, experimental

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट कार्रवाइयों को रिमोट किया जा सकता है या नहीं

टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false"

सही होने पर, Bazel टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.

टैग: execution, experimental

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.

टैग: execution, experimental

--[no]incompatible_modify_execution_info_additive default: "true"

इस सुविधा के चालू होने पर, एक से ज़्यादा --modify_execution_info फ़्लैग पास करने पर, उन्हें जोड़ दिया जाता है. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.

टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो

कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई के एक्ज़ीक्यूशन की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, और TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि एक ही नेमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.

सिंटैक्स: regex=[+-]key,regex=[+-]key,....

उदाहरण:

• .*=+x,.*=-y,.*=+z सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में x और z जोड़ता है. साथ ही, y को हटाता है.
• Genrule=+requires-x, Genrule की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में requires-x जोड़ता है.
• (?!Genrule).*=-requires-x, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से requires-x हटा देता है.

टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू करें.

बढ़कर:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को लगातार चालू रखें.

बढ़कर:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार कई बार चलाने की सुविधा चालू करें.

बढ़कर:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.

इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (डेक्सिंग, डिसुगरिंग, संसाधन प्रोसेसिंग) चालू करें.

बढ़कर:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो टेस्ट चलाने के लिए टेस्ट एक्ज़ेक ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करें.

टैग: execution

ऐक्शन लागू करने के लिए इस्तेमाल की जाने वाली टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Android टारगेट कंपाइलर.

टैग: affects_outputs, 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> default: ""

यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.

टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--cc_output_directory_tag=<a string> default: ""

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.

टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger"

उस बाइनरी का पाथ जिसका इस्तेमाल, रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:lcov_merger पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी की जगह. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:coverage_report_generator पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support"

सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, यह //tools/test:coverage_support पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह विकल्प, malloc को लागू करने का कस्टम तरीका तय करता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.

टैग: changes_inputs, affects_outputs

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "false"

अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.

टैग: loses_incremental_state, loading_and_analysis, execution, experimental

--[no]experimental_prefer_mutual_xcode default: "true"

अगर यह नीति 'सही है' पर सेट है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए Xcode के लोकल वर्शन का इस्तेमाल करें.

टैग: loses_incremental_state, experimental

--extra_execution_platforms=<comma-separated list of options> default: ""

कार्रवाइयां करने के लिए, इन प्लैटफ़ॉर्म का इस्तेमाल किया जा सकता है. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. register_execution_platforms() की ओर से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद में, फ़्लैग की गई सेटिंग पहले की सेटिंग को बदल देंगी.

टैग: execution

--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() की ओर से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले माना जाएगा.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.

टैग: action_command_lines, affects_outputs

--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

यह फ़्लैग कोई कार्रवाई नहीं करता. आने वाले समय में इसे हटा दिया जाएगा.

टैग: loading_and_analysis, execution

--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

अगर यह सेटिंग तय की जाती है, तो exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.

टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform"

होस्ट सिस्टम की जानकारी देने वाले प्लैटफ़ॉर्म के नियम का लेबल.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_bazel_test_exec_run_under default: "true"

अगर यह सुविधा चालू है, तो bazel test --run_under=//:runner, exec configuration में //:runner बनाता है. अगर यह सुविधा बंद है, तो टारगेट कॉन्फ़िगरेशन में //:runner बनाया जाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे bazel run पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में --run_under=//foo बनाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_builtin_objc_strip_action default: "true"

यह तय करता है कि objc लिंकिंग के हिस्से के तौर पर स्ट्रिप ऐक्शन को चालू करना है या नहीं.

टैग: action_command_lines, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true"

अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाएं चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false"

ऐपल के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive default: "true"

अगर यह विकल्प सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.

टैग: action_command_lines, incompatible_change

--[no]interface_shared_objects default: "true"

अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल करने की सुविधा है, तो उनका इस्तेमाल करें. फ़िलहाल, सभी 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 main workspace-relative path> default: ""

मैपिंग फ़ाइल की जगह. इससे यह पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो कौनसा प्लैटफ़ॉर्म इस्तेमाल करना है या अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसा फ़्लैग सेट करना है. यह मुख्य वर्कस्पेस रूट से जुड़ा होना चाहिए. डिफ़ॉल्ट रूप से, यह platform_mappings (वर्कस्पेस रूट के ठीक नीचे मौजूद फ़ाइल) पर सेट होता है.

टैग: affects_outputs, changes_inputs, loading_and_analysis, non_configurable

--platforms=<a build target label> default: ""

प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains ने बंद कर दिया है.

टैग: loading_and_analysis, affects_outputs

--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

यह tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK टूल का वर्शन तय करता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से tvOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--[no]use_platforms_in_apple_crosstool_transition डिफ़ॉल्ट: "false"

इससे apple_crosstool_transition, ज़रूरत पड़ने पर लेगसी --cpu के बजाय --platforms फ़्लैग की वैल्यू का इस्तेमाल करता है.

टैग: loading_and_analysis

--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

यह watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें

अगर बताया गया है, तो यह संबंधित बिल्ड कार्रवाइयों के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी जाती है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes"

यह xcode_config नियम का लेबल है. इसका इस्तेमाल, बिल्ड कॉन्फ़िगरेशन में Xcode का वर्शन चुनने के लिए किया जाता है.

टैग: loses_incremental_state, loading_and_analysis

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]apple_generate_dsym डिफ़ॉल्ट: "false"

डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करनी हैं या नहीं.

टैग: affects_outputs, action_command_lines

--[no]build_runfile_links default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.

टैग: affects_outputs

--[no]build_runfile_manifests default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर ये गलत हैं, तो इन्हें शामिल न करें. इस विकल्प के गलत होने पर, स्थानीय जांच नहीं हो पाएंगी.

टैग: affects_outputs

--[no]build_test_dwp डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.

टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h"

यह cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc"

यह विकल्प, cc_proto_library से बनाई गई सोर्स फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "false"

proto_library में Java api के वैकल्पिक वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "false"

इस कुकी का इस्तेमाल, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को कंपाइल करने के आउटपुट के तौर पर सेव करने के लिए किया जाता है.

टैग: affects_outputs, experimental

--fission=<a set of compilation modes> डिफ़ॉल्ट: "no"

इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल करने वाले कंपाइलेशन मोड कौनसे हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.

टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम अपनी रनफ़ाइल में DefaultInfo.files डेटा डिपेंडेंसी जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाती है (रनफ़ाइल की ऐसी सुविधाएं जिनका इस्तेमाल नहीं करना चाहिए).

टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest default: "true"

चालू होने पर, {binary}.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन के रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन से जनरेट होने वाले हर रेपो के लिए एक बार दिखाने के बजाय, रनफ़ाइलें योगदान करती हैं.

टैग: affects_outputs, incompatible_change

--incompatible_disable_select_on=<comma-separated set of options> default: ""

उन फ़्लैग की सूची जिनके लिए select() में इस्तेमाल करने की सुविधा बंद है.

टैग: loading_and_analysis, incompatible_change, non_configurable

--[no]incompatible_filegroup_runfiles_for_data default: "true"

अगर यह सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें, उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.

टैग: incompatible_change

--[no]objc_generate_linkmap डिफ़ॉल्ट: "false"

इससे यह तय किया जाता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.

टैग: affects_outputs

--[no]save_temps डिफ़ॉल्ट: "false"

अगर यह सेट है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C), और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.

टैग: affects_outputs

ऐसे विकल्प जिनसे उपयोगकर्ता, वैरिएबल के आउटपुट को कॉन्फ़िगर कर सकता है. इससे वैरिएबल की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को name के ज़रिए तय किया जा सकता है. ऐसे में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. वहीं, अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को जोड़ दिया जाता है.

ध्यान दें कि जब तक --incompatible_repo_env_ignores_action_env सही नहीं होता, तब तक सभी name=value जोड़े, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.

टैग: action_command_lines

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.

टैग: changes_inputs, affects_outputs

--[no]android_databinding_use_androidx default: "true"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args default: "true"

3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> default: "off"

इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तो Android नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical"

यह विकल्प, Android बाइनरी के लिए मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. ALPHABETICAL का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से पाथ के हिसाब से क्रम से लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस तरह से क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.

टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "false"

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis

--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

उन आर्किटेक्चर की कॉमा लगाकर अलग की गई सूची जिनके लिए Apple Catalyst बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मेल खाते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं चुना जाना चाहिए. इसके बजाय, bazel coverage कमांड का इस्तेमाल करना चाहिए.

टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

उस मोड के बारे में बताएं जिसमें बाइनरी बनाई जाएगी. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--conlyopt=<a string> कई बार इस्तेमाल किया गया हो

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--copt=<a string> कई बार इस्तेमाल किया गया हो

gcc को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--cpu=<a string> default: ""

बंद कर दिया गया है: Blaze इस फ़्लैग का इस्तेमाल इंटरनल तौर पर नहीं करता है. हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा के लिए, लेगसी प्लैटफ़ॉर्म मैपिंग मौजूद हैं. इस फ़्लैग का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म की सही परिभाषा के साथ --platforms का इस्तेमाल करें.

टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.

टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.

टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.

टैग: affects_outputs

--cxxopt=<a string> कई बार इस्तेमाल किया गया हो

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू मौजूद हैं, तो सबसे बाद में सेट की गई वैल्यू का इस्तेमाल किया जाता है.

टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> default: "default"

इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: loading_and_analysis, affects_outputs

--[no]enable_propeller_optimize_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.

टैग: affects_outputs

--[no]enable_remaining_fdo_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी दिखेगी.

टैग: affects_outputs

--[no]enable_runfiles default: "auto"

रनफ़ाइल के सिमलिंक ट्री को चालू करें. Windows पर यह डिफ़ॉल्ट रूप से बंद होता है, जबकि अन्य प्लैटफ़ॉर्म पर चालू होता है.

टैग: affects_outputs

--exec_aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन पहलुओं की सूची जिन्हें एक्ज़ीक्यूटिव के कॉन्फ़िगर किए गए टारगेट पर लागू किया जाना है. भले ही, वे टॉप-लेवल के टारगेट हों या न हों. इस सुविधा पर एक्सपेरिमेंट जारी है और इसमें बदलाव हो सकता है.

टैग: loading_and_analysis

--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो

इसे पहलुओं के पक्ष में बंद कर दिया गया है. extra_action को मौजूदा बिल्ड ऐक्शन से अटैच करने के लिए, action_listener का इस्तेमाल करें.

टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "false"

APK में Java संसाधनों को कंप्रेस करना

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 default: "true"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "false"

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "false"

dex फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करें

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.

टैग: affects_outputs, experimental

--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.

टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "false"

अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.

टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off or strip> default: "off"

आउटपुट ट्री में कहां पर किस मॉडल का इस्तेमाल करना है, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, GH-6526 देखें. Starlark ऐक्शन, execution_requirements डिक्शनरी में supports-path-mapping कुंजी जोड़कर, पाथ मैपिंग की सुविधा के लिए ऑप्ट-इन कर सकते हैं.

टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_platform_cpu_name=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री label=value के फ़ॉर्मैट में होनी चाहिए. इसमें लेबल का मतलब किसी प्लैटफ़ॉर्म से है. साथ ही, वैल्यू वह छोटा नाम है जिसका इस्तेमाल करके, $(TARGET_CPU) मेक वैरिएबल और आउटपुट पाथ में प्लैटफ़ॉर्म के सीपीयू के नाम को बदला जा सकता है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform या --incompatible_bep_cpu_from_platform की वैल्यू 'सही है' पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.

टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir default: "Auto"

अगर यह विकल्प सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है:

1. अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है. ऐसा कभी-कभी होता है.
2. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है.
3. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर, छोटा नाम इस्तेमाल करें.
4. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.

टैग: affects_outputs, experimental

--[no]experimental_py_binaries_include_label डिफ़ॉल्ट: "false"

py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.

टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो collect_code_coverage चालू होने पर Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.

टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस अनुमानित तरीके में कुछ कमियां हैं. इसलिए, हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करने के लिए माइग्रेट करें.

टैग: affects_outputs, experimental

--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.

टैग: affects_outputs

--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है.जैसे, //foo/bar:file.afdo - आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है. साथ ही, यह fdo_profile टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, fdo_profile नियम की जगह लागू होगा.

टैग: affects_outputs

--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कैश मेमोरी में पहले से फ़ेच करने के सुझावों का इस्तेमाल करें.

टैग: affects_outputs

--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.

टैग: affects_outputs

--features=<a string> कई बार इस्तेमाल किया गया हो

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं. --host_features भी देखें.

टैग: changes_inputs, affects_outputs

--[no]force_pic डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, पीआईसी प्री-बिल्ट लाइब्रेरी को नॉन-पीआईसी लाइब्रेरी के मुकाबले ज़्यादा प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.

टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह उन एनवायरमेंट वैरिएबल के सेट के बारे में बताता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को name से तय किया जा सकता है. इस मामले में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर से भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name से भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.

टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

यह तय करें कि बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो

C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C (लेकिन C++) सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है.

टैग: action_command_lines, affects_outputs

--host_copt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_cpu=<a string> default: ""

होस्ट सीपीयू.

टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं.

टैग: changes_inputs, affects_outputs

--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, macOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false"

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर toolchain पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, GH-17134 देखें.

टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में शामिल किया जाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_target_cpu_from_platform default: "true"

अगर टारगेट प्लैटफ़ॉर्म के सीपीयू की सीमा (@platforms//cpu:cpu) तय की गई है, तो $(TARGET_CPU) मेक वैरिएबल सेट करने के लिए इसका इस्तेमाल किया जाता है.

टैग: loading_and_analysis, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "false"

कवरेज की सुविधा चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल नियमों की जांच की जाती है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.

टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, तय किए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को शामिल नहीं किया जाता. ध्यान दें कि सिर्फ़ टेस्ट से जुड़े नियमों को इंस्ट्रूमेंट किया जाता है. हालांकि, अगर --instrument_test_targets चालू है, तो सभी नियमों को इंस्ट्रूमेंट किया जाता है.

टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'ios_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें सभी आर्किटेक्चर शामिल होते हैं.

टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive default: "true"

इस विकल्प का इस्तेमाल अब नहीं किया जा सकता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.

टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> कई बार इस्तेमाल किया गया हो

लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ बैकएंड के चरण में पास करने का अतिरिक्त विकल्प (under --features=thin_lto).

टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (--features=thin_lto के तहत).

टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple macOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, macOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.

टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.

टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "false"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग की जानी चाहिए या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.

टैग: action_command_lines

--objccopt=<a string> कई बार इस्तेमाल किया गया हो

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto). इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों के LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller की प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller की प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल के इनपुट फ़ाइलों के बारे में होना चाहिए. उदाहरण के लिए, a/b/BUILD फ़ाइल में लेबल को इस तरह से तय किया गया है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile

टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

test और run कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू foo -bar है और एक्ज़ीक्यूशन कमांड लाइन test_binary -baz है, तो फ़ाइनल कमांड लाइन foo -bar test_binary -baz होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण यहां दिए गए हैं:

• valgrind
• strace
• strace -c
• valgrind --quiet --num-callers=20
• //package:target
• //package:target --options

टैग: action_command_lines

--[no]share_native_deps default: "true"

अगर यह वैल्यू सही है, तो एक जैसी सुविधा वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा

टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "false"

बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.

टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

इससे यह तय किया जाता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.

टैग: affects_outputs

--stripopt=<a string> कई बार इस्तेमाल किया गया हो

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple visionOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]check_visibility default: "true"

अगर यह सुविधा बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.

टैग: build_file_semantics, non_configurable

--[no]desugar_for_android default: "true"

यह तय करता है कि Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "false"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 के साथ काम करने वाली लाइब्रेरी शामिल करनी हैं या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints default: "true"

यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की डिपेंडेंसी ऐसे एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है

टैग: build_file_semantics

--[no]experimental_check_desugar_deps default: "true"

Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.

टैग: eagerness_to_exit, loading_and_analysis, experimental

--[no]experimental_enforce_transitive_visibility डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो package()s को transitive_visibility एट्रिब्यूट सेट करने की अनुमति दें. इससे यह तय किया जा सकेगा कि कौनसे पैकेज उन पर निर्भर हो सकते हैं.

टैग: build_file_semantics, experimental

--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है"

इस विकल्प को चालू करने पर, यह लागू किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल नहीं किए जा सकते. इस नीति के उल्लंघन की वजह से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.

टैग: loading_and_analysis

--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default"

अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false"

यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें

टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.

टैग: eagerness_to_exit, incompatible_change

--[no]one_version_enforcement_on_java_tests default: "true"

इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.

टैग: loading_and_analysis

--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

--incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).

टैग: loading_and_analysis

--[no]strict_filesets डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.

टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> default: "off"

अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--[no]strict_system_includes डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.

टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

यह कुकी, इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताती है. यह environment नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.

--platforms भी देखें.

टैग: 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 default: "true"

अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.

टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें

iOS पर हस्ताक्षर करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.

टैग: action_command_lines

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "false"

जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.

टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही' पर सेट है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के लिए AnalysisFailureInfo का एक इंस्टेंस जनरेट होगा. इसमें गड़बड़ी की जानकारी शामिल होगी. ऐसा, बिल्ड पूरा न होने की वजह से होगा.

टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट के ज़रिए ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.

टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो dex2oat की कार्रवाई पूरी न होने पर, टेस्ट रनटाइम के दौरान dex2oat को लागू करने के बजाय, बिल्ड रुक जाएगा.

टैग: loading_and_analysis, experimental

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. यह {resource}={value} फ़ॉर्मैट में होना चाहिए. अगर {value} के तौर पर कोई पॉज़िटिव नंबर दिया जाता है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगा. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे small, medium, large, enormous के टेस्ट साइज़ के लिए संसाधन की रकम को बदल देंगे. वैल्यू HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]{float} (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). इस फ़्लैग के ज़रिए तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को टैग में तय किए गए संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false"

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.

टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "false"

ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.

टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. जैसे, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची पाई जा सकती है.

टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर पर चलाने या टेस्ट करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.

टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो

इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी भी वजह से, इनमें से कोई भी कोशिश पूरी नहीं हो पाती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, दी गई वैल्यू सिर्फ़ एक पूर्णांक होती है.

उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे.

वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू और regex_filter का मतलब, शामिल और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें.

उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट चलाता है. हालांकि, //foo/bar में मौजूद टेस्ट को तीन बार चलाता है. इस विकल्प को कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई भी मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह विकल्प, टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को name या name=value पेयर के ज़रिए तय किया जा सकता है. अगर name के ज़रिए वैरिएबल तय किया जाता है, तो उसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. पहले से सेट किए गए वैरिएबल को =name की मदद से अनसेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.

टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> default: "-1"

जांच के टाइम आउट के लिए, जांच के टाइम आउट की डिफ़ॉल्ट वैल्यू (सेकंड में) बदलें. अगर कोई एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे short, moderate, long, और eternal के लिए टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 की वैल्यू से Blaze को यह पता चलता है कि उसे उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करना है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है, तो टेस्ट के ऐसे आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा जिनके बारे में जानकारी नहीं दी गई है.

टैग: test_runner

बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]cc_dotd_files default: "true"

.d फ़ाइलों को जनरेट और उनका विश्लेषण करना है या नहीं.

टैग: loading_and_analysis, execution, changes_inputs

--[no]cc_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false"

ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद सभी क्लास हट जाएं.

टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files default: "true"

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, रिमोट बिल्ड नोड से सीधे मेमोरी में पास किया जाएगा.

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files default: "true"

अगर यह सुविधा चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly default: "true"

इस नीति के चालू होने पर, --trim_test_configuration उन नियमों के लिए टेस्ट कॉन्फ़िगरेशन को नहीं काटेगा जिन्हें testonly=1 के तौर पर मार्क किया गया है. इसका मकसद, कार्रवाई से जुड़ी उन समस्याओं को कम करना है जो तब होती हैं, जब टेस्ट के अलावा अन्य नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.

टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing default: "true"

यह हर जार फ़ाइल के लिए, अलग-अलग डेक्सिंग का ज़्यादातर काम करता है.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning default: "true"

अगर इसे सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को कम करने के लिए किया जाएगा.

टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "false"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग चालू हो.

टैग: execution

--[no]trim_test_configuration default: "true"

यह सुविधा चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.

टैग: loading_and_analysis, loses_incremental_state

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.

टैग: terminal_output

--[no]verbose_visibility_errors डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो दिखने से जुड़ी गड़बड़ियों में गड़बड़ी की अतिरिक्त जानकारी शामिल होती है.

टैग: build_file_semantics, non_configurable

Bazel कमांड के लिए सामान्य इनपुट तय करने या उसमें बदलाव करने वाले विकल्प. ये विकल्प, अन्य कैटगरी में नहीं आते.:

--flag_alias=<a 'name=label' flag alias> कई बार इस्तेमाल किया गया हो

यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह {key}={value} के फ़ॉर्म में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.

टैग: changes_inputs, non_configurable

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "false"

इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में init.py फ़ाइलें अपने-आप न बन पाएं. जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तब इस फ़्लैग को सेट करने पर ही इसे फ़ॉल्स के तौर पर माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.

टैग: affects_outputs, incompatible_change

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] default: "auto"

अगर इसे auto पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब:

1. Bazel, टेस्ट या उसकी डिपेंडेंसी में हुए बदलावों का पता लगाता है,
2. टेस्ट को external के तौर पर मार्क किया गया हो,
3. --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या
4. यह जांच पहले पूरी नहीं हो सकी थी. अगर इसे yes पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें external के तौर पर मार्क नहीं किया गया है. अगर इसे no पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता.

--[no]experimental_cancel_concurrent_tests default: "never"

अगर on_failed या on_passed, तो Blaze उस नतीजे के साथ पहली बार सफल होने पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह नीति सिर्फ़ --runs_per_test_detects_flakes के साथ काम करेगी.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false"

अगर यह विकल्प 'सही है' पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.

टैग: affects_outputs, loading_and_analysis, experimental

--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "bazel"

यह Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ को चालू करता है.

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "false"

java_* सोर्स की पुष्टि करनी है या नहीं.

टैग: affects_outputs, experimental

--[no]explicit_java_test_deps डिफ़ॉल्ट: "false"

java_test में, TestRunner के deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.

--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो

बिल्ड के दौरान लागू होने वाले टूल बनाते समय, javac को पास किए जाने वाले अतिरिक्त विकल्प.

--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--[no]incompatible_check_sharding_support default: "true"

अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को फ़ेल कर देगा. ऐसा तब होगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में दिए गए पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, सभी टेस्ट को हर शार्ड में चलाएगा.

टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed default: "true"

अगर यह विकल्प चुना जाता है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. local टैग जोड़कर, लोकल लेवल पर सिर्फ़ एक टेस्ट रन करें

टैग: incompatible_change

--[no]incompatible_strict_action_env default: "true"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है. साथ ही, LD_LIBRARY_PATH को इनहेरिट नहीं करता है. अगर आपको क्लाइंट से कुछ खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि शेयर की गई कैश मेमोरी का इस्तेमाल करने पर, ऐसा करने से अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा.

टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.

--java_debug

इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार करती है. इसके बाद ही, टेस्ट शुरू होता है. इसका मतलब है कि -test_output=streamed.

बढ़कर:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps default: "true"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करता है. फ़िलहाल, यह कंपाइल-टाइम क्लासपाथ के लिए है.

--[no]java_header_compilation default: "true"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> default: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> default: "local_jdk"

Java रनटाइम का वर्शन

--javacopt=<a string> कई बार इस्तेमाल किया गया हो

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> कई बार इस्तेमाल किया गया हो

Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जिन्हें लेगसी मल्टीडेक्स को कंपाइल करते समय, मुख्य डेक्स में होना चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किया जाने वाला बाइनरी तय करता है.

--plugin=<a build target label> कई बार इस्तेमाल किया गया हो

बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

इससे यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.

--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.

टैग: affects_outputs, loading_and_analysis

--[no]proto_profile default: "true"

प्रोटो कंपाइलर को profile_path पास करना है या नहीं.

टैग: affects_outputs, loading_and_analysis

--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain"

proto_lang_toolchain() का लेबल, जिसमें C++ प्रोटो को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जिसमें Java protos को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जिसमें JavaLite protos को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> कई बार इस्तेमाल किया गया हो

प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का पूरा पाथ. अगर इसे सेट नहीं किया गया है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन पर सेट किया गया है (जो Bazel सर्वर शुरू करता है), तो Bazel इसका इस्तेमाल करता है. अगर दोनों में से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है;

• Windows: c:/msys64/usr/bin/bash.exe
• FreeBSD: /usr/local/bin/bash
• अन्य सभी: /bin/bash.

ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में समस्याएं आ सकती हैं.

टैग: loading_and_analysis

--test_arg=<a string> कई बार इस्तेमाल किया गया हो

इस विकल्प की मदद से, टेस्ट एक्ज़ीक्यूटेबल को पास किए जाने वाले अतिरिक्त विकल्पों और आर्ग्युमेंट के बारे में बताया जाता है. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ bazel test कमांड के लिए किया जाता है.

--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.

--test_result_expiration=<an integer> default: "-1"

इस विकल्प को बंद कर दिया गया है और इससे कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "false"

यह विकल्प, टेस्ट रनर को तुरंत फ़ॉरवर्ड करता है. टेस्ट रनर को पहली गड़बड़ी होने पर ही बंद हो जाना चाहिए.

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit"

टेस्ट शार्डिंग के लिए रणनीति तय करें:

• explicit का इस्तेमाल सिर्फ़ तब करें, जब shard_count BUILD एट्रिब्यूट मौजूद हो.
• disabled का इस्तेमाल करके, टेस्ट शार्डिंग को कभी भी इस्तेमाल न करें.
• forced=k का इस्तेमाल करके, shard_count BUILD एट्रिब्यूट की परवाह किए बिना, टेस्टिंग के लिए k शार्ड लागू करें.

--tool_java_language_version=<a string> default: ""

बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया गया Java भाषा का वर्शन

--tool_java_runtime_version=<a string> default: "remotejdk_11"

बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन

--[no]use_ijars default: "true"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इंक्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

सहायता के विकल्प

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--help_verbosity=<long, medium or short> default: "medium"

सहायता कमांड के लिए वर्बोसिटी लेवल चुनें.

टैग: terminal_output

--long [-l]

हर विकल्प का सिर्फ़ नाम दिखाने के बजाय, उसकी पूरी जानकारी दिखाएं.

बढ़ाकर:
  --help_verbosity=long

टैग: terminal_output

--short

सिर्फ़ विकल्पों के नाम दिखाओ, उनके टाइप या मतलब नहीं.

बढ़ाकर:
  --help_verbosity=short

टैग: terminal_output

जानकारी के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

ऐसे विकल्प जिनसे उपयोगकर्ता, आउटपुट को कॉन्फ़िगर कर सकता है. इससे आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--info_output_type=<stdout or response_proto> default: "stdout"

अगर stdout है, तो नतीजे सीधे कंसोल में प्रिंट किए जाते हैं. अगर response_proto है, तो जानकारी देने वाले कमांड के नतीजे, रिस्पॉन्स एक्सटेंशन में पैक किए जाते हैं.

टैग: affects_outputs, terminal_output

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--[no]show_make_env डिफ़ॉल्ट: "false"

जवाब में "Make" एनवायरमेंट को शामिल करें.

टैग: affects_outputs, terminal_output

लाइसेंस के विकल्प

मोबाइल ऐप्लिकेशन इंस्टॉल करने के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--mode=<classic, classic_internal_test_do_not_use or skylark> default: "skylark"

'कोई इफ़ेक्ट नहीं' फ़्लैग का इस्तेमाल अब नहीं किया जा सकता. सिर्फ़ स्काईलार्क मोड अब भी काम करता है.

टैग: loading_and_analysis, execution, incompatible_change

ऐक्शन लागू करने के लिए इस्तेमाल की जाने वाली टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--adb=<a string> default: ""

'mobile-install' कमांड के लिए इस्तेमाल किया जाने वाला adb बाइनरी. अगर यह जानकारी नहीं दी गई है, तो --android_sdk_channel कमांड-लाइन विकल्प में बताए गए Android SDK टूल का इस्तेमाल किया जाता है. अगर --android_sdk_channel विकल्प नहीं दिया गया है, तो डिफ़ॉल्ट SDK टूल का इस्तेमाल किया जाता है.

टैग: changes_inputs

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]incremental डिफ़ॉल्ट: "false"

यह तय करता है कि इंक्रीमेंटल इंस्टॉल करना है या नहीं. अगर ऐसा है, तो जिस डिवाइस पर कोड इंस्टॉल करना है उसकी स्थिति पढ़कर, गैर-ज़रूरी अतिरिक्त काम से बचें. साथ ही, उस जानकारी का इस्तेमाल करके, गैर-ज़रूरी काम से बचें. अगर यह वैल्यू 'गलत है' (डिफ़ॉल्ट रूप से), तो हमेशा पूरा इंस्टॉलेशन करें.

टैग: loading_and_analysis

--[no]split_apks डिफ़ॉल्ट: "false"

डिवाइस पर ऐप्लिकेशन को इंस्टॉल और अपडेट करने के लिए, स्प्लिट एपीके का इस्तेमाल करना है या नहीं. यह सुविधा, सिर्फ़ Marshmallow या इसके बाद के वर्शन वाले डिवाइसों पर काम करती है

टैग: loading_and_analysis, affects_outputs

ऐसे विकल्प जिनसे उपयोगकर्ता, वैरिएबल के आउटपुट को कॉन्फ़िगर कर सकता है. इससे वैरिएबल की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--adb_arg=<a string> कई बार इस्तेमाल किया गया हो

adb को पास करने के लिए अतिरिक्त आर्ग्युमेंट. आम तौर पर, इसका इस्तेमाल किसी डिवाइस पर ऐप्लिकेशन इंस्टॉल करने के लिए किया जाता है.

टैग: action_command_lines

--debug_app

ऐप्लिकेशन शुरू करने से पहले, डीबगर के लिए इंतज़ार करना है या नहीं.

बढ़ाकर:
  --start=DEBUG

टैग: execution

--device=<a string> default: ""

adb डिवाइस का सीरियल नंबर. अगर यह जानकारी नहीं दी जाती है, तो पहले डिवाइस का इस्तेमाल किया जाएगा.

टैग: action_command_lines

--start=<no, cold, warm or debug> default: "NO"

ऐप्लिकेशन इंस्टॉल करने के बाद, उसे कैसे शुरू किया जाना चाहिए. इंक्रीमेंटल इंस्टॉल पर ऐप्लिकेशन की स्थिति को बनाए रखने और उसे पहले जैसा करने के लिए, इसे WARM पर सेट करें.

टैग: execution

--start_app

यह तय करता है कि ऐप्लिकेशन इंस्टॉल होने के बाद उसे शुरू करना है या नहीं.

बढ़ाकर:
  --start=COLD

टैग: execution

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--incremental_install_verbosity=<a string> default: ""

इंक्रीमेंटल इंस्टॉल के लिए वर्बोसिटी. डीबग लॉगिंग के लिए, इसे 1 पर सेट करें.

टैग: bazel_monitoring

मॉड के विकल्प

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट कार्रवाइयों को रिमोट किया जा सकता है या नहीं

टैग: loading_and_analysis, execution, experimental

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.

टैग: execution, experimental

--[no]incompatible_modify_execution_info_additive default: "true"

इस सुविधा के चालू होने पर, एक से ज़्यादा --modify_execution_info फ़्लैग पास करने पर, उन्हें जोड़ दिया जाता है. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.

टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto"

डेटा लोड करने/विश्लेषण करने के लिए, एक साथ इस्तेमाल की जाने वाली थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS.5". "auto" विकल्प, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करता है. कम से कम 1 होना चाहिए

टैग: bazel_internal_configuration

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो

कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई के एक्ज़ीक्यूशन की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, और TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि एक ही नेमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.

सिंटैक्स: regex=[+-]key,regex=[+-]key,....

उदाहरण:

• .*=+x,.*=-y,.*=+z सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में x और z जोड़ता है. साथ ही, y को हटाता है.
• Genrule=+requires-x, Genrule की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में requires-x जोड़ता है.
• (?!Genrule).*=-requires-x, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से requires-x हटा देता है.

टैग: execution, affects_outputs, loading_and_analysis

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो टेस्ट चलाने के लिए टेस्ट एक्ज़ेक ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करें.

टैग: execution

ऐक्शन लागू करने के लिए इस्तेमाल की जाने वाली टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--[no]incompatible_bazel_test_exec_run_under default: "true"

अगर यह सुविधा चालू है, तो bazel test --run_under=//:runner, exec configuration में //:runner बनाता है. अगर यह सुविधा बंद है, तो टारगेट कॉन्फ़िगरेशन में //:runner बनाया जाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे bazel run पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में --run_under=//foo बनाता है.

टैग: affects_outputs, incompatible_change

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]build_runfile_links default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.

टैग: affects_outputs

--[no]build_runfile_manifests default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर ये गलत हैं, तो इन्हें शामिल न करें. इस विकल्प के गलत होने पर, स्थानीय जांच नहीं हो पाएंगी.

टैग: affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम अपनी रनफ़ाइल में DefaultInfo.files डेटा डिपेंडेंसी जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाती है (रनफ़ाइल की ऐसी सुविधाएं जिनका इस्तेमाल नहीं करना चाहिए).

टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest default: "true"

चालू होने पर, {binary}.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन के रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन से जनरेट होने वाले हर रेपो के लिए एक बार दिखाने के बजाय, रनफ़ाइलें योगदान करती हैं.

टैग: affects_outputs, incompatible_change

--incompatible_disable_select_on=<comma-separated set of options> default: ""

उन फ़्लैग की सूची जिनके लिए select() में इस्तेमाल करने की सुविधा बंद है.

टैग: loading_and_analysis, incompatible_change, non_configurable

--[no]incompatible_filegroup_runfiles_for_data default: "true"

अगर यह सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें, उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.

टैग: incompatible_change

ऐसे विकल्प जिनसे उपयोगकर्ता, वैरिएबल के आउटपुट को कॉन्फ़िगर कर सकता है. इससे वैरिएबल की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को name के ज़रिए तय किया जा सकता है. ऐसे में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. वहीं, अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को जोड़ दिया जाता है.

ध्यान दें कि जब तक --incompatible_repo_env_ignores_action_env सही नहीं होता, तब तक सभी name=value जोड़े, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.

टैग: action_command_lines

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.

टैग: changes_inputs, affects_outputs

--[no]collect_code_coverage डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मेल खाते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं चुना जाना चाहिए. इसके बजाय, bazel coverage कमांड का इस्तेमाल करना चाहिए.

टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

उस मोड के बारे में बताएं जिसमें बाइनरी बनाई जाएगी. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--cpu=<a string> default: ""

बंद कर दिया गया है: Blaze इस फ़्लैग का इस्तेमाल इंटरनल तौर पर नहीं करता है. हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा के लिए, लेगसी प्लैटफ़ॉर्म मैपिंग मौजूद हैं. इस फ़्लैग का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म की सही परिभाषा के साथ --platforms का इस्तेमाल करें.

टैग: changes_inputs, affects_outputs

--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू मौजूद हैं, तो सबसे बाद में सेट की गई वैल्यू का इस्तेमाल किया जाता है.

टैग: changes_inputs, affects_outputs

--[no]enable_runfiles default: "auto"

रनफ़ाइल के सिमलिंक ट्री को चालू करें. Windows पर यह डिफ़ॉल्ट रूप से बंद होता है, जबकि अन्य प्लैटफ़ॉर्म पर चालू होता है.

टैग: affects_outputs

--exec_aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन पहलुओं की सूची जिन्हें एक्ज़ीक्यूटिव के कॉन्फ़िगर किए गए टारगेट पर लागू किया जाना है. भले ही, वे टॉप-लेवल के टारगेट हों या न हों. इस सुविधा पर एक्सपेरिमेंट जारी है और इसमें बदलाव हो सकता है.

टैग: loading_and_analysis

--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो

इसे पहलुओं के पक्ष में बंद कर दिया गया है. extra_action को मौजूदा बिल्ड ऐक्शन से अटैच करने के लिए, action_listener का इस्तेमाल करें.

टैग: execution, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.

टैग: affects_outputs, experimental

--experimental_output_paths=<off or strip> default: "off"

आउटपुट ट्री में कहां पर किस मॉडल का इस्तेमाल करना है, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, GH-6526 देखें. Starlark ऐक्शन, execution_requirements डिक्शनरी में supports-path-mapping कुंजी जोड़कर, पाथ मैपिंग की सुविधा के लिए ऑप्ट-इन कर सकते हैं.

टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_platform_cpu_name=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री label=value के फ़ॉर्मैट में होनी चाहिए. इसमें लेबल का मतलब किसी प्लैटफ़ॉर्म से है. साथ ही, वैल्यू वह छोटा नाम है जिसका इस्तेमाल करके, $(TARGET_CPU) मेक वैरिएबल और आउटपुट पाथ में प्लैटफ़ॉर्म के सीपीयू के नाम को बदला जा सकता है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform या --incompatible_bep_cpu_from_platform की वैल्यू 'सही है' पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.

टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir default: "Auto"

अगर यह विकल्प सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है:

1. अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है. ऐसा कभी-कभी होता है.
2. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है.
3. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर, छोटा नाम इस्तेमाल करें.
4. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.

टैग: affects_outputs, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस अनुमानित तरीके में कुछ कमियां हैं. इसलिए, हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करने के लिए माइग्रेट करें.

टैग: affects_outputs, experimental

--features=<a string> कई बार इस्तेमाल किया गया हो

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं. --host_features भी देखें.

टैग: changes_inputs, affects_outputs

--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह उन एनवायरमेंट वैरिएबल के सेट के बारे में बताता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को name से तय किया जा सकता है. इस मामले में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर से भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name से भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.

टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

यह तय करें कि बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--host_cpu=<a string> default: ""

होस्ट सीपीयू.

टैग: changes_inputs, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं.

टैग: changes_inputs, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false"

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर toolchain पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, GH-17134 देखें.

टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में शामिल किया जाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_target_cpu_from_platform default: "true"

अगर टारगेट प्लैटफ़ॉर्म के सीपीयू की सीमा (@platforms//cpu:cpu) तय की गई है, तो $(TARGET_CPU) मेक वैरिएबल सेट करने के लिए इसका इस्तेमाल किया जाता है.

टैग: loading_and_analysis, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "false"

कवरेज की सुविधा चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल नियमों की जांच की जाती है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.

टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, तय किए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को शामिल नहीं किया जाता. ध्यान दें कि सिर्फ़ टेस्ट से जुड़े नियमों को इंस्ट्रूमेंट किया जाता है. हालांकि, अगर --instrument_test_targets चालू है, तो सभी नियमों को इंस्ट्रूमेंट किया जाता है.

टैग: affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

test और run कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू foo -bar है और एक्ज़ीक्यूशन कमांड लाइन test_binary -baz है, तो फ़ाइनल कमांड लाइन foo -bar test_binary -baz होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण यहां दिए गए हैं:

• valgrind
• strace
• strace -c
• valgrind --quiet --num-callers=20
• //package:target
• //package:target --options

टैग: action_command_lines

--[no]stamp डिफ़ॉल्ट: "false"

बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]check_visibility default: "true"

अगर यह सुविधा बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.

टैग: build_file_semantics, non_configurable

--[no]enforce_constraints default: "true"

यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की डिपेंडेंसी ऐसे एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है

टैग: build_file_semantics

--[no]experimental_enforce_transitive_visibility डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो package()s को transitive_visibility एट्रिब्यूट सेट करने की अनुमति दें. इससे यह तय किया जा सकेगा कि कौनसे पैकेज उन पर निर्भर हो सकते हैं.

टैग: build_file_semantics, experimental

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.

टैग: build_file_semantics, incompatible_change

--[no]strict_filesets डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.

टैग: build_file_semantics, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

यह कुकी, इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताती है. यह environment नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.

--platforms भी देखें.

टैग: changes_inputs

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "false"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होती है. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility default: "true"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है' पर सेट है, तो हर config_setting, हर टारगेट को दिखेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.

टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही' पर सेट है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के लिए AnalysisFailureInfo का एक इंस्टेंस जनरेट होगा. इसमें गड़बड़ी की जानकारी शामिल होगी. ऐसा, बिल्ड पूरा न होने की वजह से होगा.

टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट के ज़रिए ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.

टैग: loading_and_analysis

`mod` सब-कमांड के आउटपुट और सिमैंटिक्स से जुड़े विकल्प:

--[no]all_repos डिफ़ॉल्ट: "false"

mod show_repo के लिए: पूरे वर्कस्पेस में मौजूद सभी रिपॉज़िटरी दिखाएं.

टैग: terminal_output

--[no]all_visible_repos डिफ़ॉल्ट: "false"

mod show_repo के लिए: चुने गए बेस मॉड्यूल में दिखने वाले सभी रेपो, उनके असली नामों के साथ दिखाएं.

टैग: terminal_output

--base_module=<"<root>" for the root module; <module>@<version> for a specific version of a module; <module> for all versions of a module; @<name> for a repo with the given apparent name; or @@<name> for a repo with the given canonical name> default: "<root>"

उस मॉड्यूल के बारे में बताएं जिसके हिसाब से टारगेट किए गए रिपॉज़िटरी को इंटरप्रेट किया जाएगा.

टैग: terminal_output

--charset=<utf8 or ascii> default: "utf8"

यह कुकी, ट्री के लिए इस्तेमाल किए जाने वाले वर्ण सेट को चुनती है. इसका असर सिर्फ़ टेक्स्ट आउटपुट पर पड़ता है. मान्य वैल्यू utf8 या ascii हैं. डिफ़ॉल्ट वैल्यू utf8 है

टैग: terminal_output

--[no]cycles default: "true"

दिखाए गए ट्री में डिपेंडेंसी साइकल के बारे में बताता है.

टैग: terminal_output

--depth=<an integer> default: "-1"

डिपेंडेंसी ट्री की ज़्यादा से ज़्यादा डिसप्ले डेप्थ. डेप्थ 1 से, सीधे तौर पर जुड़ी डिपेंडेंसी दिखती हैं. उदाहरण के लिए. tree, path, और all_paths के लिए, यह डिफ़ॉल्ट रूप से Integer.MAX_VALUE पर सेट होता है. वहीं, deps और explain के लिए, यह डिफ़ॉल्ट रूप से 1 पर सेट होता है. इसका मतलब है कि यह टारगेट लीफ़ और उनके पैरंट के अलावा, सिर्फ़ रूट के डायरेक्ट डिपेंडेंसी दिखाता है.

टैग: terminal_output

--extension_filter=<a comma-separated list of <extension>s> डिफ़ॉल्ट: ब्यौरा देखें

इन मॉड्यूल एक्सटेंशन के इस्तेमाल और उनसे जनरेट की गई रिपॉज़िटरी को सिर्फ़ तब दिखाएं, जब उनके फ़्लैग सेट हों. अगर यह विकल्प सेट किया जाता है, तो नतीजे के ग्राफ़ में सिर्फ़ वे पाथ शामिल होंगे जिनमें बताए गए एक्सटेंशन का इस्तेमाल करने वाले मॉड्यूल शामिल हैं. खाली सूची से फ़िल्टर बंद हो जाता है. इससे सभी संभावित एक्सटेंशन तय हो जाते हैं.

टैग: terminal_output

--extension_info=<hidden, usages, repos or all> default: "hidden"

यह तय करें कि क्वेरी के नतीजे में, एक्सटेंशन के इस्तेमाल के बारे में कितनी जानकारी शामिल करनी है.

• hidden में एक्सटेंशन की कोई जानकारी नहीं दिखेगी.
• usages सिर्फ़ एक्सटेंशन के नाम दिखाएगा.
• repos में, use_repo का इस्तेमाल करके इंपोर्ट की गई रिपॉज़िटरी भी शामिल होंगी.
• all में, एक्सटेंशन से जनरेट की गई अन्य रिपॉज़िटरी भी दिखेंगी.

टैग: terminal_output

--extension_usages=<a comma-separated list of <module>s> default: ""

उन मॉड्यूल के बारे में बताएं जिनके एक्सटेंशन के इस्तेमाल को show_extension क्वेरी में दिखाया जाएगा.

टैग: terminal_output

--from=<a comma-separated list of <module>s> default: "<root>"

वे मॉड्यूल जिनसे डिपेंडेंसी ग्राफ़ क्वेरी दिखनी शुरू होगी. सटीक सिमैंटिक के लिए, हर क्वेरी का ब्यौरा देखें. डिफ़ॉल्ट रूप से, यह <root> पर सेट होता है.

टैग: terminal_output

--[no]include_builtin डिफ़ॉल्ट: "false"

डिपेंडेंसी ग्राफ़ में पहले से मौजूद मॉड्यूल शामिल करें. डिफ़ॉल्ट रूप से इसे बंद कर दिया जाता है, क्योंकि इससे काफ़ी आवाज़ आती है.

टैग: terminal_output

--[no]include_unused डिफ़ॉल्ट: "false"

क्वेरी में, इस्तेमाल नहीं किए गए मॉड्यूल भी शामिल किए जाएंगे और उन्हें दिखाया जाएगा. ये मॉड्यूल, चुने जाने के बाद मॉड्यूल रिज़ॉल्यूशन ग्राफ़ में मौजूद नहीं होते. ऐसा, कम से कम वर्शन चुनने या नियमों को बदलने की वजह से होता है. इसका असर अलग-अलग तरह की क्वेरी पर अलग-अलग पड़ सकता है. जैसे, all_paths कमांड में नए पाथ शामिल करना या explain कमांड में अतिरिक्त डिपेंडेंट शामिल करना.

टैग: terminal_output

--output=<text, json, graph, streamed_proto or streamed_jsonproto> default: "text"

क्वेरी के नतीजों को प्रिंट करने का फ़ॉर्मैट. क्वेरी के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: text, json, graph.

टैग: terminal_output

--[no]verbose डिफ़ॉल्ट: "false"

क्वेरी में यह भी दिखेगा कि मॉड्यूल को उनके मौजूदा वर्शन में क्यों बदला गया (अगर बदला गया है). 'व्याख्या करें' क्वेरी के लिए, डिफ़ॉल्ट रूप से यह विकल्प 'सही' पर सेट होता है.

टैग: terminal_output

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--[no]verbose_visibility_errors डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो दिखने से जुड़ी गड़बड़ियों में गड़बड़ी की अतिरिक्त जानकारी शामिल होती है.

टैग: build_file_semantics, non_configurable

Bazel कमांड के लिए सामान्य इनपुट तय करने या उसमें बदलाव करने वाले विकल्प. ये विकल्प, अन्य कैटगरी में नहीं आते.:

--flag_alias=<a 'name=label' flag alias> कई बार इस्तेमाल किया गया हो

यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह {key}={value} के फ़ॉर्म में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.

टैग: changes_inputs, non_configurable

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD को मिटा दिया है, तो बिल्ड सिस्टम को '//x:y/z' लेबल मिलने पर शिकायत हो सकती है. ऐसा तब होता है, जब यह लेबल अब भी किसी अन्य package_path एंट्री से मिला हो. --deleted_packages x/y विकल्प का इस्तेमाल करने पर, यह समस्या नहीं होती.

--[no]fetch default: "true"

इस कमांड से बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर ऐसा कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.

--package_path=<colon-separated list of options> default: "%workspace%"

पैकेज ढूंढने की जगहों की सूची, जिसे कोलन से अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस के हिसाब से होते हैं. अगर इसे शामिल नहीं किया जाता है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट इस्तेमाल किया जाता है.

--[no]show_loading_progress default: "true"

अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

Print_action के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--print_action_mnemonics=<a string> कई बार इस्तेमाल किया गया हो

यह उन निमोनिक की सूची है जिनके हिसाब से print_action डेटा को फ़िल्टर करना है. अगर इसे खाली छोड़ दिया जाता है, तो कोई फ़िल्टरिंग नहीं होती है.

क्वेरी के विकल्प

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट कार्रवाइयों को रिमोट किया जा सकता है या नहीं

टैग: loading_and_analysis, execution, experimental

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.

टैग: execution, experimental

--[no]incompatible_modify_execution_info_additive default: "true"

इस सुविधा के चालू होने पर, एक से ज़्यादा --modify_execution_info फ़्लैग पास करने पर, उन्हें जोड़ दिया जाता है. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.

टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.

टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto"

डेटा लोड करने/विश्लेषण करने के लिए, एक साथ इस्तेमाल की जाने वाली थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS.5". "auto" विकल्प, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करता है. कम से कम 1 होना चाहिए

टैग: bazel_internal_configuration

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो

कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई के एक्ज़ीक्यूशन की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, और TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि एक ही नेमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.

सिंटैक्स: regex=[+-]key,regex=[+-]key,....

उदाहरण:

• .*=+x,.*=-y,.*=+z सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में x और z जोड़ता है. साथ ही, y को हटाता है.
• Genrule=+requires-x, Genrule की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में requires-x जोड़ता है.
• (?!Genrule).*=-requires-x, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से requires-x हटा देता है.

टैग: execution, affects_outputs, loading_and_analysis

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो टेस्ट चलाने के लिए टेस्ट एक्ज़ेक ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करें.

टैग: execution

ऐक्शन लागू करने के लिए इस्तेमाल की जाने वाली टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--[no]incompatible_bazel_test_exec_run_under default: "true"

अगर यह सुविधा चालू है, तो bazel test --run_under=//:runner, exec configuration में //:runner बनाता है. अगर यह सुविधा बंद है, तो टारगेट कॉन्फ़िगरेशन में //:runner बनाया जाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे bazel run पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में --run_under=//foo बनाता है.

टैग: affects_outputs, incompatible_change

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]build_runfile_links default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.

टैग: affects_outputs

--[no]build_runfile_manifests default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर ये गलत हैं, तो इन्हें शामिल न करें. इस विकल्प के गलत होने पर, स्थानीय जांच नहीं हो पाएंगी.

टैग: affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम अपनी रनफ़ाइल में DefaultInfo.files डेटा डिपेंडेंसी जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाती है (रनफ़ाइल की ऐसी सुविधाएं जिनका इस्तेमाल नहीं करना चाहिए).

टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest default: "true"

चालू होने पर, {binary}.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन के रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन से जनरेट होने वाले हर रेपो के लिए एक बार दिखाने के बजाय, रनफ़ाइलें योगदान करती हैं.

टैग: affects_outputs, incompatible_change

--incompatible_disable_select_on=<comma-separated set of options> default: ""

उन फ़्लैग की सूची जिनके लिए select() में इस्तेमाल करने की सुविधा बंद है.

टैग: loading_and_analysis, incompatible_change, non_configurable

--[no]incompatible_filegroup_runfiles_for_data default: "true"

अगर यह सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें, उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.

टैग: incompatible_change

ऐसे विकल्प जिनसे उपयोगकर्ता, वैरिएबल के आउटपुट को कॉन्फ़िगर कर सकता है. इससे वैरिएबल की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को name के ज़रिए तय किया जा सकता है. ऐसे में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. वहीं, अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को जोड़ दिया जाता है.

ध्यान दें कि जब तक --incompatible_repo_env_ignores_action_env सही नहीं होता, तब तक सभी name=value जोड़े, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.

टैग: action_command_lines

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.

टैग: changes_inputs, affects_outputs

--[no]collect_code_coverage डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मेल खाते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं चुना जाना चाहिए. इसके बजाय, bazel coverage कमांड का इस्तेमाल करना चाहिए.

टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

उस मोड के बारे में बताएं जिसमें बाइनरी बनाई जाएगी. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--cpu=<a string> default: ""

बंद कर दिया गया है: Blaze इस फ़्लैग का इस्तेमाल इंटरनल तौर पर नहीं करता है. हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा के लिए, लेगसी प्लैटफ़ॉर्म मैपिंग मौजूद हैं. इस फ़्लैग का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म की सही परिभाषा के साथ --platforms का इस्तेमाल करें.

टैग: changes_inputs, affects_outputs

--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू मौजूद हैं, तो सबसे बाद में सेट की गई वैल्यू का इस्तेमाल किया जाता है.

टैग: changes_inputs, affects_outputs

--[no]enable_runfiles default: "auto"

रनफ़ाइल के सिमलिंक ट्री को चालू करें. Windows पर यह डिफ़ॉल्ट रूप से बंद होता है, जबकि अन्य प्लैटफ़ॉर्म पर चालू होता है.

टैग: affects_outputs

--exec_aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन पहलुओं की सूची जिन्हें एक्ज़ीक्यूटिव के कॉन्फ़िगर किए गए टारगेट पर लागू किया जाना है. भले ही, वे टॉप-लेवल के टारगेट हों या न हों. इस सुविधा पर एक्सपेरिमेंट जारी है और इसमें बदलाव हो सकता है.

टैग: loading_and_analysis

--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो

इसे पहलुओं के पक्ष में बंद कर दिया गया है. extra_action को मौजूदा बिल्ड ऐक्शन से अटैच करने के लिए, action_listener का इस्तेमाल करें.

टैग: execution, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.

टैग: affects_outputs, experimental

--experimental_output_paths=<off or strip> default: "off"

आउटपुट ट्री में कहां पर किस मॉडल का इस्तेमाल करना है, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, GH-6526 देखें. Starlark ऐक्शन, execution_requirements डिक्शनरी में supports-path-mapping कुंजी जोड़कर, पाथ मैपिंग की सुविधा के लिए ऑप्ट-इन कर सकते हैं.

टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_platform_cpu_name=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री label=value के फ़ॉर्मैट में होनी चाहिए. इसमें लेबल का मतलब किसी प्लैटफ़ॉर्म से है. साथ ही, वैल्यू वह छोटा नाम है जिसका इस्तेमाल करके, $(TARGET_CPU) मेक वैरिएबल और आउटपुट पाथ में प्लैटफ़ॉर्म के सीपीयू के नाम को बदला जा सकता है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform या --incompatible_bep_cpu_from_platform की वैल्यू 'सही है' पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.

टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir default: "Auto"

अगर यह विकल्प सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है:

1. अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है. ऐसा कभी-कभी होता है.
2. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है.
3. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर, छोटा नाम इस्तेमाल करें.
4. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.

टैग: affects_outputs, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस अनुमानित तरीके में कुछ कमियां हैं. इसलिए, हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करने के लिए माइग्रेट करें.

टैग: affects_outputs, experimental

--features=<a string> कई बार इस्तेमाल किया गया हो

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं. --host_features भी देखें.

टैग: changes_inputs, affects_outputs

--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह उन एनवायरमेंट वैरिएबल के सेट के बारे में बताता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को name से तय किया जा सकता है. इस मामले में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर से भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name से भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.

टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

यह तय करें कि बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--host_cpu=<a string> default: ""

होस्ट सीपीयू.

टैग: changes_inputs, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं.

टैग: changes_inputs, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false"

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर toolchain पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, GH-17134 देखें.

टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में शामिल किया जाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_target_cpu_from_platform default: "true"

अगर टारगेट प्लैटफ़ॉर्म के सीपीयू की सीमा (@platforms//cpu:cpu) तय की गई है, तो $(TARGET_CPU) मेक वैरिएबल सेट करने के लिए इसका इस्तेमाल किया जाता है.

टैग: loading_and_analysis, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "false"

कवरेज की सुविधा चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल नियमों की जांच की जाती है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.

टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, तय किए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को शामिल नहीं किया जाता. ध्यान दें कि सिर्फ़ टेस्ट से जुड़े नियमों को इंस्ट्रूमेंट किया जाता है. हालांकि, अगर --instrument_test_targets चालू है, तो सभी नियमों को इंस्ट्रूमेंट किया जाता है.

टैग: affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

test और run कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू foo -bar है और एक्ज़ीक्यूशन कमांड लाइन test_binary -baz है, तो फ़ाइनल कमांड लाइन foo -bar test_binary -baz होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण यहां दिए गए हैं:

• valgrind
• strace
• strace -c
• valgrind --quiet --num-callers=20
• //package:target
• //package:target --options

टैग: action_command_lines

--[no]stamp डिफ़ॉल्ट: "false"

बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]check_visibility default: "true"

अगर यह सुविधा बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.

टैग: build_file_semantics, non_configurable

--[no]enforce_constraints default: "true"

यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की डिपेंडेंसी ऐसे एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है

टैग: build_file_semantics

--[no]experimental_enforce_transitive_visibility डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो package()s को transitive_visibility एट्रिब्यूट सेट करने की अनुमति दें. इससे यह तय किया जा सकेगा कि कौनसे पैकेज उन पर निर्भर हो सकते हैं.

टैग: build_file_semantics, experimental

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.

टैग: build_file_semantics, incompatible_change

--[no]strict_filesets डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.

टैग: build_file_semantics, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

यह कुकी, इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताती है. यह environment नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.

--platforms भी देखें.

टैग: changes_inputs

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "false"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होती है. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility default: "true"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है' पर सेट है, तो हर config_setting, हर टारगेट को दिखेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.

टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही' पर सेट है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के लिए AnalysisFailureInfo का एक इंस्टेंस जनरेट होगा. इसमें गड़बड़ी की जानकारी शामिल होगी. ऐसा, बिल्ड पूरा न होने की वजह से होगा.

टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट के ज़रिए ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.

टैग: loading_and_analysis

क्वेरी के आउटपुट और सिमैंटिक्स से जुड़े विकल्प:

--aspect_deps=<off, conservative or precise> default: "conservative"

जब आउटपुट फ़ॉर्मैट {xml,proto,record} में से कोई एक हो, तब आसपेक्ट डिपेंडेंसी की समस्या कैसे हल करें. 'बंद है' का मतलब है कि किसी भी पहलू की डिपेंडेंसी हल नहीं की गई है. 'सामान्य' (डिफ़ॉल्ट) का मतलब है कि सभी पहलुओं की डिपेंडेंसी जोड़ी गई हैं. भले ही, उन्हें सीधे तौर पर डिपेंडेंसी के नियम क्लास के तौर पर दिया गया हो या नहीं. 'सटीक' का मतलब है कि सिर्फ़ उन पहलुओं को जोड़ा गया है जो सीधे तौर पर डिपेंडेंसी के नियम क्लास के हिसाब से शायद चालू हैं. ध्यान दें कि सटीक मोड में, एक टारगेट का आकलन करने के लिए अन्य पैकेज लोड करने पड़ते हैं. इसलिए, यह अन्य मोड की तुलना में धीमा होता है. यह भी ध्यान दें कि सटीक मोड भी पूरी तरह से सटीक नहीं होता: किसी पहलू का हिसाब लगाना है या नहीं, यह विश्लेषण के चरण में तय किया जाता है. यह चरण, 'bazel query' के दौरान नहीं चलता है.

टैग: build_file_semantics

--[no]consistent_labels डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो हर क्वेरी कमांड, लेबल को इस तरह से दिखाती है जैसे कि Starlark <code>str</code> फ़ंक्शन को <code>Label</code> इंस्टेंस पर लागू किया गया हो. यह उन टूल के लिए काम का है जिन्हें नियमों के हिसाब से, अलग-अलग क्वेरी कमांड और/या लेबल के आउटपुट से मैच करना होता है. अगर यह सुविधा चालू नहीं है, तो आउटपुट फ़ॉर्मेटर, आउटपुट को ज़्यादा आसानी से पढ़ने के लिए, मुख्य रिपॉज़िटरी के हिसाब से रिपॉज़िटरी के नाम दिखा सकते हैं.

टैग: terminal_output

--[no]experimental_explicit_aspects डिफ़ॉल्ट: "false"

aquery, cquery: क्या आउटपुट में, आसपेक्ट से जनरेट हुई कार्रवाइयों को शामिल करना है. query: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).

टैग: terminal_output

--[no]experimental_graphless_query default: "auto"

अगर यह वैल्यू सही है, तो Query के ऐसे तरीके का इस्तेमाल किया जाता है जो ग्राफ़ की कॉपी नहीं बनाता. नया वर्शन सिर्फ़ --order_output=no के साथ काम करता है. साथ ही, यह सिर्फ़ आउटपुट फ़ॉर्मैट करने वाले कुछ टूल के साथ काम करता है.

टैग: build_file_semantics, eagerness_to_exit

--graph:conditional_edges_limit=<an integer> default: "4"

शर्त के हिसाब से लेबल दिखाने की ज़्यादा से ज़्यादा संख्या. -1 का मतलब है कि कोई काट-छांट नहीं की गई है और 0 का मतलब है कि कोई एनोटेशन नहीं है. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.

टैग: terminal_output

--[no]graph:factored default: "true"

अगर सही है, तो ग्राफ़ को 'फ़ैक्टर्ड' किया जाएगा. इसका मतलब है कि टोपोलॉजिकल तौर पर एक जैसे नोड को एक साथ मर्ज कर दिया जाएगा और उनके लेबल को एक साथ जोड़ दिया जाएगा. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.

टैग: terminal_output

--graph:node_limit=<an integer> default: "512"

आउटपुट में मौजूद ग्राफ़ नोड के लिए, लेबल स्ट्रिंग की ज़्यादा से ज़्यादा लंबाई. बड़े लेबल छोटे कर दिए जाएंगे; -1 का मतलब है कि लेबल छोटे नहीं किए जाएंगे. यह विकल्प सिर्फ़ --output=graph पर लागू होता है.

टैग: terminal_output

--[no]implicit_deps default: "true"

अगर यह विकल्प चालू है, तो क्वेरी जिस डिपेंडेंसी ग्राफ़ पर काम करती है उसमें इंप्लिसिट डिपेंडेंसी शामिल की जाएंगी. इंप्लिसिट डिपेंडेंसी ऐसी डिपेंडेंसी होती है जिसे BUILD फ़ाइल में साफ़ तौर पर नहीं बताया जाता, लेकिन Bazel इसे जोड़ता है. cquery के लिए, यह विकल्प हल की गई टूलचेन को फ़िल्टर करने की सुविधा को कंट्रोल करता है.

टैग: build_file_semantics

--[no]include_aspects default: "true"

aquery, cquery: क्या आउटपुट में, आसपेक्ट से जनरेट हुई कार्रवाइयों को शामिल करना है. query: no-op (आसपेक्ट हमेशा फ़ॉलो किए जाते हैं).

टैग: terminal_output

--[no]incompatible_lexicographical_output default: "true"

यह विकल्प सेट होने पर, --order_output=auto आउटपुट को लेक्सिकोग्राफ़िकल क्रम में लगाता है.

टैग: terminal_output, incompatible_change

--[no]incompatible_package_group_includes_double_slash default: "true"

इस सेटिंग को चालू करने पर, package_group packages एट्रिब्यूट की वैल्यू देते समय, लीडिंग // को नहीं हटाया जाएगा.

टैग: terminal_output, incompatible_change

--[no]infer_universe_scope डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और --universe_scope को सेट नहीं किया गया है, तो --universe_scope की वैल्यू को क्वेरी एक्सप्रेशन में, यूनीक टारगेट पैटर्न की सूची के तौर पर माना जाएगा. ध्यान दें कि क्वेरी एक्सप्रेशन के लिए अनुमानित --universe_scope वैल्यू, आपकी ज़रूरत के हिसाब से नहीं हो सकती.ऐसा तब होता है, जब क्वेरी एक्सप्रेशन में यूनिवर्स के स्कोप वाले फ़ंक्शन (जैसे,allrdeps) का इस्तेमाल किया जाता है.इसलिए, इस विकल्प का इस्तेमाल सिर्फ़ तब करें, जब आपको पता हो कि आपको क्या करना है. ज़्यादा जानकारी और उदाहरणों के लिए, https://bazel.build/reference/query#sky-query पर जाएं. अगर --universe_scope सेट है, तो इस विकल्प की वैल्यू को अनदेखा कर दिया जाता है. ध्यान दें: यह विकल्प सिर्फ़ query पर लागू होता है. इसका मतलब है कि यह cquery पर लागू नहीं होता.

टैग: loading_and_analysis

--[no]line_terminator_null डिफ़ॉल्ट: "false"

क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया गया है.

टैग: terminal_output

--[no]nodep_deps default: "true"

अगर यह विकल्प चालू है, तो "nodep" एट्रिब्यूट से मिले डिपेंडेंसी, डिपेंडेंसी ग्राफ़ में शामिल किए जाएंगे. इस ग्राफ़ पर क्वेरी काम करती है. "nodep" एट्रिब्यूट का एक सामान्य उदाहरण "visibility" है. बिल्ड लैंग्वेज में मौजूद सभी "nodep" एट्रिब्यूट के बारे में जानने के लिए, info build-language को चलाएं और उसके आउटपुट को पार्स करें.

टैग: build_file_semantics

--noorder_results

नतीजों को निर्भरता के क्रम (डिफ़ॉल्ट) या बिना क्रम के दिखाएं. बिना क्रम वाली आउटपुट फ़ाइल तेज़ी से जनरेट होती है. हालांकि, यह सुविधा सिर्फ़ तब काम करती है, जब --output को minrank, maxrank या graph के तौर पर सेट न किया गया हो.

बढ़ाकर:
  --order_output=no

टैग: terminal_output

--null

क्या हर फ़ॉर्मैट को नई लाइन के बजाय \0 से खत्म किया गया है.

बढ़ाकर:
  --line_terminator_null=true

टैग: terminal_output

--order_output=<no, deps, auto or full> default: "auto"

नतीजों को क्रम से न लगाएं (no), निर्भरता के हिसाब से क्रम से लगाएं (deps) या पूरी तरह से क्रम से लगाएं (full). डिफ़ॉल्ट रूप से, यह 'auto' पर सेट होता है. इसका मतलब है कि नतीजे, आउटपुट फ़ॉर्मेटर के हिसाब से क्रम में या पूरी तरह से क्रम में लगाए जाते हैं. जैसे, proto, minrank, maxrank, और graph के लिए क्रम में लगाए जाते हैं, जबकि अन्य सभी के लिए पूरी तरह से क्रम में लगाए जाते हैं. जब आउटपुट पूरी तरह से क्रम में होता है, तो नोड को पूरी तरह से तय किए गए क्रम में प्रिंट किया जाता है. सबसे पहले, सभी नोड को वर्णमाला के क्रम में लगाया जाता है. इसके बाद, सूची में मौजूद हर नोड का इस्तेमाल, पोस्ट-ऑर्डर डेप्थ-फ़र्स्ट सर्च की शुरुआत के तौर पर किया जाता है. इसमें, उन नोड के आउटगोइंग एज को ट्रैवर्स किया जाता है जिन पर पहले नहीं जाया गया है. ऐसा, सक्सेसर नोड के वर्णमाला क्रम में किया जाता है. आखिर में, नोड को उस क्रम के उलट क्रम में प्रिंट किया जाता है जिस क्रम में उन्हें देखा गया था.

टैग: terminal_output

--order_results

नतीजों को निर्भरता के क्रम (डिफ़ॉल्ट) या बिना क्रम के दिखाएं. बिना क्रम वाली आउटपुट फ़ाइल तेज़ी से जनरेट होती है. हालांकि, यह सुविधा सिर्फ़ तब काम करती है, जब --output को minrank, maxrank या graph के तौर पर सेट न किया गया हो.

बढ़ाकर:
  --order_output=auto

टैग: terminal_output

--output=<a string> default: "label"

क्वेरी के नतीजों को प्रिंट करने का फ़ॉर्मैट. क्वेरी के लिए इन वैल्यू का इस्तेमाल किया जा सकता है: build, graph, streamed_jsonproto, label, label_kind, location, maxrank, minrank, package, proto, streamed_proto, xml.

टैग: terminal_output

--output_file=<a string> default: ""

इस विकल्प को सेट करने पर, क्वेरी के नतीजे सीधे इस फ़ाइल में लिखे जाएंगे. साथ ही, Bazel के स्टैंडर्ड आउटपुट स्ट्रीम (stdout) में कुछ भी प्रिंट नहीं किया जाएगा. आम तौर पर, बेंचमार्क में यह <code>bazel query > file</code> से ज़्यादा तेज़ होता है.

टैग: terminal_output

--[no]proto:default_values default: "true"

अगर यह विकल्प सही है, तो उन एट्रिब्यूट को शामिल किया जाता है जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं बताई गई है. अगर यह विकल्प गलत है, तो उन एट्रिब्यूट को शामिल नहीं किया जाता है. यह विकल्प, --output=proto पर लागू होता है

टैग: terminal_output

--[no]proto:definition_stack डिफ़ॉल्ट: "false"

definition_stack proto फ़ील्ड भरें. यह फ़ील्ड, हर नियम इंस्टेंस के लिए Starlark कॉल स्टैक को रिकॉर्ड करता है. यह स्टैक, नियम की क्लास को तय किए जाने के समय का होता है.

टैग: terminal_output

--[no]proto:flatten_selects default: "true"

इस विकल्प को चालू करने पर, select() फ़ंक्शन से बनाए गए कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को फ़्लैट कर दिया जाता है. सूची टाइप के लिए, फ़्लैट किया गया डेटा एक ऐसी सूची होती है जिसमें चुने गए मैप की हर वैल्यू ठीक एक बार शामिल होती है. स्केलर टाइप को शून्य पर सेट किया जाता है.

टैग: build_file_semantics

--[no]proto:include_attribute_source_aspects डिफ़ॉल्ट: "false"

हर एट्रिब्यूट के source_aspect_name प्रोटो फ़ील्ड में, उस सोर्स पहलू की जानकारी भरें जिससे एट्रिब्यूट मिला है. अगर एट्रिब्यूट किसी सोर्स पहलू से नहीं मिला है, तो इस फ़ील्ड में खाली स्ट्रिंग डालें.

टैग: terminal_output

--[no]proto:include_starlark_rule_env default: "true"

जनरेट किए गए $internal_attr_hash एट्रिब्यूट की वैल्यू में, Starlark एनवायरमेंट का इस्तेमाल करें. इससे यह पक्का होता है कि स्टार्लार्क नियम की परिभाषा (और इसके ट्रांज़िटिव इंपोर्ट) इस आइडेंटिफ़ायर का हिस्सा हैं.

टैग: terminal_output

--[no]proto:include_synthetic_attribute_hash डिफ़ॉल्ट: "false"

$internal_attr_hash एट्रिब्यूट की वैल्यू का हिसाब लगाना है या नहीं.

टैग: terminal_output

--[no]proto:instantiation_stack डिफ़ॉल्ट: "false"

हर नियम के इंस्टैंटिएशन कॉल स्टैक को पॉप्युलेट करें. ध्यान दें कि इसके लिए, स्टैक का मौजूद होना ज़रूरी है

टैग: terminal_output

--[no]proto:locations default: "true"

जगह की जानकारी को प्रोटो आउटपुट में दिखाना है या नहीं.

टैग: terminal_output

--proto:output_rule_attrs=<comma-separated list of options> default: "all"

आउटपुट में शामिल करने के लिए एट्रिब्यूट की कॉमा लगाकर बनाई गई सूची. डिफ़ॉल्ट रूप से, सभी एट्रिब्यूट के लिए लागू होता है. किसी भी एट्रिब्यूट को आउटपुट न करने के लिए, इसे खाली स्ट्रिंग पर सेट करें. यह विकल्प, --output=proto पर लागू होता है.

टैग: terminal_output

--[no]proto:rule_classes डिफ़ॉल्ट: "false"

हर नियम के rule_class_key फ़ील्ड में वैल्यू डालें. साथ ही, दिए गए rule_class_key वाले पहले नियम के लिए, उसके rule_class_info proto फ़ील्ड में भी वैल्यू डालें. rule_class_key फ़ील्ड, नियम क्लास की खास तौर पर पहचान करता है. साथ ही, rule_class_info फ़ील्ड, Stardoc फ़ॉर्मैट में नियम क्लास की एपीआई डेफ़िनिशन है.

टैग: terminal_output

--[no]proto:rule_inputs_and_outputs default: "true"

rule_input और rule_output फ़ील्ड में वैल्यू डालनी है या नहीं.

टैग: terminal_output

--query_file=<a string> default: ""

अगर इसे सेट किया जाता है, तो क्वेरी, कमांड लाइन के बजाय यहां दी गई फ़ाइल से क्वेरी पढ़ेगी. यहां फ़ाइल और कमांड-लाइन क्वेरी, दोनों को एक साथ नहीं बताया जा सकता.

टैग: changes_inputs

--[no]relative_locations डिफ़ॉल्ट: "false"

अगर इस नीति को 'सही है' पर सेट किया जाता है, तो एक्सएमएल और प्रोटो आउटपुट में BUILD फ़ाइलों की जगह की जानकारी, रिलेटिव होगी. डिफ़ॉल्ट रूप से, जगह की जानकारी का आउटपुट एक ऐब्सलूट पाथ होता है. यह अलग-अलग मशीनों पर एक जैसा नहीं होता. इस विकल्प को true पर सेट करके, सभी मशीनों पर एक जैसा नतीजा पाया जा सकता है.

टैग: terminal_output

--[no]strict_test_suite डिफ़ॉल्ट: "false"

अगर यह सही है, तो tests() एक्सप्रेशन, टेस्ट के अलावा अन्य टारगेट वाली test_suite मिलने पर गड़बड़ी दिखाता है.

टैग: build_file_semantics, eagerness_to_exit

--[no]tool_deps default: "true"

क्वेरी: अगर यह सुविधा बंद है, तो 'एक्ज़ीक्यूशन कॉन्फ़िगरेशन' पर निर्भरता, डिपेंडेंसी ग्राफ़ में शामिल नहीं की जाएगी. इस ग्राफ़ पर क्वेरी काम करती है. 'exec configuration' डिपेंडेंसी एज, जैसे कि किसी भी 'proto_library' नियम से लेकर प्रोटोकॉल कंपाइलर तक, आम तौर पर उसी 'target' प्रोग्राम के किसी हिस्से के बजाय, बिल्ड के दौरान एक्ज़ीक्यूट किए गए टूल की ओर इशारा करता है. Cquery: अगर यह सुविधा बंद है, तो कॉन्फ़िगर किए गए उन सभी टारगेट को फ़िल्टर कर दिया जाता है जो टॉप-लेवल के उस टारगेट से एक्ज़ीक्यूशन ट्रांज़िशन को पार करते हैं जिसने इस कॉन्फ़िगर किए गए टारगेट का पता लगाया था. इसका मतलब है कि अगर टॉप-लेवल का टारगेट, टारगेट कॉन्फ़िगरेशन में है, तो टारगेट कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए टारगेट ही दिखाए जाएंगे. अगर टॉप-लेवल का टारगेट, exec कॉन्फ़िगरेशन में है, तो सिर्फ़ exec कॉन्फ़िगर किए गए टारगेट दिखाए जाएंगे. इस विकल्प से, हल की गई टूलचेन को शामिल नहीं किया जाएगा.

टैग: build_file_semantics

--universe_scope=<comma-separated list of options> default: ""

कॉमा लगाकर अलग किए गए टारगेट पैटर्न का सेट (जोड़ने और घटाने वाले). क्वेरी को, तय किए गए टारगेट के ट्रांज़िटिव क्लोज़र से तय किए गए यूनिवर्स में किया जा सकता है. इस विकल्प का इस्तेमाल, क्वेरी और cquery कमांड के लिए किया जाता है. cquery के लिए, इस विकल्प का इनपुट वे टारगेट होते हैं जिनके तहत सभी जवाब बनाए जाते हैं. इसलिए, यह विकल्प कॉन्फ़िगरेशन और ट्रांज़िशन पर असर डाल सकता है. अगर इस विकल्प के बारे में नहीं बताया जाता है, तो यह माना जाता है कि क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के टारगेट हैं. ध्यान दें: cquery के लिए, इस विकल्प को तय न करने पर, बिल्ड में गड़बड़ी हो सकती है. ऐसा तब होता है, जब क्वेरी एक्सप्रेशन से पार्स किए गए टारगेट, टॉप-लेवल के विकल्पों के साथ नहीं बनाए जा सकते.

टैग: loading_and_analysis

--[no]xml:default_values डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो उन नियमों के एट्रिब्यूट प्रिंट किए जाते हैं जिनकी वैल्यू BUILD फ़ाइल में साफ़ तौर पर नहीं दी गई है. ऐसा न होने पर, उन्हें शामिल नहीं किया जाता है.

टैग: terminal_output

--[no]xml:line_numbers default: "true"

अगर सही है, तो एक्सएमएल आउटपुट में लाइन नंबर शामिल होते हैं. इस विकल्प को बंद करने से, अंतर को आसानी से पढ़ा जा सकता है. यह विकल्प सिर्फ़ --output=xml पर लागू होता है.

टैग: terminal_output

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--[no]verbose_visibility_errors डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो दिखने से जुड़ी गड़बड़ियों में गड़बड़ी की अतिरिक्त जानकारी शामिल होती है.

टैग: build_file_semantics, non_configurable

Bazel कमांड के लिए सामान्य इनपुट तय करने या उसमें बदलाव करने वाले विकल्प. ये विकल्प, अन्य कैटगरी में नहीं आते.:

--flag_alias=<a 'name=label' flag alias> कई बार इस्तेमाल किया गया हो

यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह {key}={value} के फ़ॉर्म में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.

टैग: changes_inputs, non_configurable

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD को मिटा दिया है, तो बिल्ड सिस्टम को '//x:y/z' लेबल मिलने पर शिकायत हो सकती है. ऐसा तब होता है, जब यह लेबल अब भी किसी अन्य package_path एंट्री से मिला हो. --deleted_packages x/y विकल्प का इस्तेमाल करने पर, यह समस्या नहीं होती.

--[no]fetch default: "true"

इस कमांड से बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर ऐसा कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.

--package_path=<colon-separated list of options> default: "%workspace%"

पैकेज ढूंढने की जगहों की सूची, जिसे कोलन से अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस के हिसाब से होते हैं. अगर इसे शामिल नहीं किया जाता है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट इस्तेमाल किया जाता है.

--[no]show_loading_progress default: "true"

अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

रन करने के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

ऐसे विकल्प जो कमांड से पहले दिखते हैं और जिन्हें क्लाइंट पार्स करता है:

--[no]portable_paths डिफ़ॉल्ट: "false"

अगर यह सही है, तो इसमें ExecRequest में बदलने के लिए पाथ शामिल होते हैं, ताकि नतीजे के तौर पर मिलने वाले पाथ को पोर्टेबल बनाया जा सके.

टैग: affects_outputs

--[no]run default: "true"

अगर यह वैल्यू 'गलत है' पर सेट है, तो बनाए गए टारगेट के लिए बनाई गई कमांड लाइन को चलाने की प्रोसेस को स्किप कर दें. ध्यान दें कि --script_path का इस्तेमाल करके बनाए गए सभी बिल्ड के लिए, इस फ़्लैग को अनदेखा कर दिया जाता है.

टैग: affects_outputs

--run_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

इस विकल्प से, टारगेट को चलाने के लिए उपलब्ध एनवायरमेंट वैरिएबल के सेट के बारे में पता चलता है. वैरिएबल को नाम के हिसाब से तय किया जा सकता है. ऐसे में, वैल्यू को इनवोकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, <code>name=value</code> पेयर से भी वैल्यू को सेट किया जा सकता है. इससे वैल्यू को इनवोकेशन एनवायरमेंट से अलग सेट किया जा सकता है. साथ ही, <code>=name</code> से उस नाम के वैरिएबल को अनसेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. हालांकि, अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को एक साथ इस्तेमाल किया जा सकता है. ध्यान दें कि आम तौर पर, होस्ट के पूरे एनवायरमेंट को टारगेट किया जाएगा. हालांकि, उन वैरिएबल को टारगेट नहीं किया जाएगा जिन्हें साफ़ तौर पर अनसेट किया गया है.

टैग: affects_outputs

--[no]run_in_cwd डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो टारगेट को रनफ़ाइल ट्री के बजाय, मौजूदा वर्किंग डायरेक्ट्री में चलाया जाता है.

टैग: affects_outputs

ऐसे विकल्प जिनसे उपयोगकर्ता, वैरिएबल के आउटपुट को कॉन्फ़िगर कर सकता है. इससे वैरिएबल की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--script_path=<a path> डिफ़ॉल्ट: ब्यौरा देखें

अगर सेट है, तो दी गई फ़ाइल में टारगेट को शुरू करने वाली शेल स्क्रिप्ट लिखें. अगर यह विकल्प सेट किया जाता है, तो टारगेट को Bazel से नहीं चलाया जाता है. '//foo' टारगेट को शुरू करने के लिए, 'bazel run --script_path=foo //foo && ./foo' का इस्तेमाल करें. यह 'bazel run //foo' से इस मामले में अलग है कि Bazel लॉक को रिलीज़ कर दिया जाता है और एक्ज़ीक्यूटेबल को टर्मिनल के stdin से कनेक्ट कर दिया जाता है.

टैग: affects_outputs, execution

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--[no]omit_run_args default: "true"

इससे पता चलता है कि निजता की वजहों से, क्या रन किए जा सकने वाले टारगेट को पास किए गए आर्ग्युमेंट को आउटपुट से हटाया जाएगा. अगर इसे 'सही' पर सेट किया जाता है, तो आउटपुट में टारगेट को पास किए गए आर्ग्युमेंट शामिल नहीं होंगे. अगर इसे 'गलत है' पर सेट किया जाता है, तो आउटपुट में टारगेट को पास किए गए आर्ग्युमेंट शामिल होंगे.

टैग: terminal_output

शटडाउन के विकल्प

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--iff_heap_size_greater_than=<an integer> default: "0"

अगर यह वैल्यू शून्य नहीं है, तो शटडाउन की प्रोसेस सिर्फ़ तब सर्वर को बंद करेगी, जब JVM की ओर से इस्तेमाल की गई कुल मेमोरी (MB में) इस वैल्यू से ज़्यादा होगी.

टैग: loses_incremental_state, eagerness_to_exit

टेस्ट के विकल्प

यह build से सभी विकल्प इनहेरिट करता है.

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--[no]print_relative_test_log_paths डिफ़ॉल्ट: "false"

अगर यह सही है, तो टेस्ट लॉग का पाथ प्रिंट करते समय, ऐसे रिलेटिव पाथ का इस्तेमाल करें जो 'testlogs' सुविधा वाले सिमलंक का इस्तेमाल करता है. ध्यान दें - अलग कॉन्फ़िगरेशन के साथ 'बिल्ड'/'टेस्ट'/वगैरह को बाद में इनवोक करने से, इस सिंबल लिंक का टारगेट बदल सकता है. इससे पहले प्रिंट किया गया पाथ अब काम नहीं करेगा.

टैग: affects_outputs

--[no]test_verbose_timeout_warnings डिफ़ॉल्ट: "false"

अगर यह सही है, तो टेस्ट के असल में पूरा होने का समय, टेस्ट के लिए तय किए गए टाइम आउट से मेल न खाने पर, अतिरिक्त चेतावनियां प्रिंट करें. टाइम आउट का मतलब साफ़ तौर पर बताया गया हो या न बताया गया हो.

टैग: affects_outputs

--[no]verbose_test_summary default: "true"

सही होने पर, टेस्ट की खास जानकारी में अतिरिक्त जानकारी (समय, फ़ेल हुए रन की संख्या वगैरह) प्रिंट करें.

टैग: affects_outputs

वेंडर के विकल्प

test से सभी विकल्प इनहेरिट करता है.

बिल्ड एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]keep_going [-k] डिफ़ॉल्ट: "false"

गड़बड़ी होने के बाद भी, ज़्यादा से ज़्यादा काम जारी रखें. हालांकि, फ़ेल हुए टारगेट और उस पर निर्भर टारगेट का विश्लेषण नहीं किया जा सकता. हालांकि, इन टारगेट की अन्य ज़रूरी शर्तों का विश्लेषण किया जा सकता है.

टैग: eagerness_to_exit

--loading_phase_threads=<an integer, or a keyword ("auto", "HOST_CPUS", "HOST_RAM"), optionally followed by an operation ([-|*]<float>) eg. "auto", "HOST_CPUS*.5"> default: "auto"

डेटा लोड करने/विश्लेषण करने के लिए, एक साथ इस्तेमाल की जाने वाली थ्रेड की संख्या. इसमें पूर्णांक या कीवर्ड ("auto", "HOST_CPUS", "HOST_RAM") का इस्तेमाल किया जाता है. इसके बाद, ऑपरेशन ([-|]<float>) का इस्तेमाल किया जा सकता है. उदाहरण के लिए, "auto", "HOST_CPUS.5". "auto" विकल्प, होस्ट के संसाधनों के आधार पर डिफ़ॉल्ट रूप से एक सही वैल्यू सेट करता है. कम से कम 1 होना चाहिए

टैग: bazel_internal_configuration

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_config_setting_private_default_visibility डिफ़ॉल्ट: "false"

अगर incompatible_enforce_config_setting_visibility=false है, तो यह noop है. अगर यह फ़्लैग गलत है, तो दिखने की सेटिंग के एट्रिब्यूट के बिना कोई भी config_setting, //visibility:public होती है. अगर यह फ़्लैग 'सही है' पर सेट है, तो config_setting के लिए भी वही लॉजिक लागू होगा जो अन्य सभी नियमों के लिए लागू होता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12933 पर जाएं.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enforce_config_setting_visibility default: "true"

अगर सही है, तो config_setting के दिखने से जुड़ी पाबंदियां लागू करें. अगर यह वैल्यू 'गलत है' पर सेट है, तो हर config_setting, हर टारगेट को दिखेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/12932 पर जाएं.

टैग: loading_and_analysis, incompatible_change

Bzlmod के आउटपुट और सिमैंटिक्स से जुड़े विकल्प:

--repo=<a string> कई बार इस्तेमाल किया गया हो

सिर्फ़ वे वेंडर, जिन्हें आपने रिपॉज़िटरी के लिए चुना है. यह रिपॉज़िटरी @apparent_repo_name या @@canonical_repo_name हो सकती है. इस विकल्प को कई बार सेट किया जा सकता है.

टैग: changes_inputs

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--deleted_packages=<comma-separated list of package names> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग किए गए उन पैकेज के नामों की सूची जिन्हें बिल्ड सिस्टम, मौजूद नहीं मानता. भले ही, वे पैकेज पाथ पर कहीं दिख रहे हों. किसी मौजूदा पैकेज 'x' के सबपैकेज 'x/y' को मिटाने के लिए, इस विकल्प का इस्तेमाल करें. उदाहरण के लिए, अगर आपने अपने क्लाइंट में x/y/BUILD को मिटा दिया है, तो बिल्ड सिस्टम को '//x:y/z' लेबल मिलने पर शिकायत हो सकती है. ऐसा तब होता है, जब यह लेबल अब भी किसी अन्य package_path एंट्री से मिला हो. --deleted_packages x/y विकल्प का इस्तेमाल करने पर, यह समस्या नहीं होती.

--[no]fetch default: "true"

इस कमांड से बाहरी डिपेंडेंसी फ़ेच की जा सकती हैं. अगर इसे 'गलत है' पर सेट किया जाता है, तो कमांड, डिपेंडेंसी के कैश मेमोरी में सेव किए गए किसी भी वर्शन का इस्तेमाल करेगी. अगर ऐसा कोई वर्शन मौजूद नहीं है, तो कमांड काम नहीं करेगी.

--package_path=<colon-separated list of options> default: "%workspace%"

पैकेज ढूंढने की जगहों की सूची, जिसे कोलन से अलग किया गया है. '%workspace%' से शुरू होने वाले एलिमेंट, शामिल किए गए वर्कस्पेस के हिसाब से होते हैं. अगर इसे शामिल नहीं किया जाता है या यह खाली है, तो डिफ़ॉल्ट रूप से 'bazel info default-package-path' का आउटपुट इस्तेमाल किया जाता है.

--[no]show_loading_progress default: "true"

अगर यह विकल्प चालू है, तो Bazel "Loading package:" मैसेज प्रिंट करेगा.

बिल्ड के एक्ज़ीक्यूशन को कंट्रोल करने वाले विकल्प:

--[no]experimental_persistent_aar_extractor डिफ़ॉल्ट: "false"

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट एएआर एक्सट्रैक्टर चालू करें.

टैग: execution, experimental

--[no]experimental_remotable_source_manifests डिफ़ॉल्ट: "false"

सोर्स मेनिफ़ेस्ट कार्रवाइयों को रिमोट किया जा सकता है या नहीं

टैग: loading_and_analysis, execution, experimental

--[no]experimental_split_coverage_postprocessing डिफ़ॉल्ट: "false"

सही होने पर, Bazel टेस्ट के लिए कवरेज पोस्टप्रोसेसिंग को नए स्पॉन में चलाएगा.

टैग: execution, experimental

--[no]experimental_strict_fileset_output डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो फ़ाइलसेट सभी आउटपुट आर्टफ़ैक्ट को सामान्य फ़ाइलों के तौर पर मैनेज करेंगे. ये डायरेक्ट्री में नहीं जाएंगे और सिंबॉलिक लिंक के लिए संवेदनशील नहीं होंगे.

टैग: execution, experimental

--[no]incompatible_modify_execution_info_additive default: "true"

इस सुविधा के चालू होने पर, एक से ज़्यादा --modify_execution_info फ़्लैग पास करने पर, उन्हें जोड़ दिया जाता है. इस सुविधा के बंद होने पर, सिर्फ़ आखिरी फ़्लैग को ध्यान में रखा जाता है.

टैग: execution, affects_outputs, loading_and_analysis, incompatible_change

--modify_execution_info=<regex=[+-]key,regex=[+-]key,...> कई बार इस्तेमाल किया गया हो

कार्रवाई के लिए इस्तेमाल किए गए नेमोनिक के आधार पर, कार्रवाई के एक्ज़ीक्यूशन की जानकारी में कुंजियां जोड़ें या हटाएं. यह सिर्फ़ उन कार्रवाइयों पर लागू होता है जिनमें एक्ज़ीक्यूशन की जानकारी शामिल होती है. कई सामान्य कार्रवाइयों में एक्ज़ीक्यूशन की जानकारी शामिल होती है. जैसे, Genrule, CppCompile, Javac, StarlarkAction, और TestRunner. एक से ज़्यादा वैल्यू तय करते समय, क्रम मायने रखता है. ऐसा इसलिए, क्योंकि एक ही नेमोनिक पर कई रेगुलर एक्सप्रेशन लागू हो सकते हैं.

सिंटैक्स: regex=[+-]key,regex=[+-]key,....

उदाहरण:

• .*=+x,.*=-y,.*=+z सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में x और z जोड़ता है. साथ ही, y को हटाता है.
• Genrule=+requires-x, Genrule की सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी में requires-x जोड़ता है.
• (?!Genrule).*=-requires-x, Genrule के अलावा अन्य सभी कार्रवाइयों के लिए, एक्ज़ीक्यूशन की जानकारी से requires-x हटा देता है.

टैग: execution, affects_outputs, loading_and_analysis

--persistent_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार चालू करें.

बढ़कर:
  --internal_persistent_android_dex_desugar
  --strategy=Desugar=worker
  --strategy=DexBuilder=worker

टैग: host_machine_resource_optimizations, execution

--persistent_android_resource_processor

वर्कर्स का इस्तेमाल करके, Android रिसॉर्स प्रोसेसर को लगातार चालू रखें.

बढ़कर:
  --internal_persistent_busybox_tools
  --strategy=AaptPackage=worker
  --strategy=AndroidResourceParser=worker
  --strategy=AndroidResourceValidator=worker
  --strategy=AndroidResourceCompiler=worker
  --strategy=RClassGenerator=worker
  --strategy=AndroidResourceLink=worker
  --strategy=AndroidAapt2=worker
  --strategy=AndroidAssetMerger=worker
  --strategy=AndroidResourceMerger=worker
  --strategy=AndroidCompiledResourceMerger=worker
  --strategy=ManifestMerger=worker
  --strategy=AndroidManifestMerger=worker
  --strategy=Aapt2Optimize=worker
  --strategy=AARGenerator=worker
  --strategy=ProcessDatabinding=worker
  --strategy=GenerateDataBindingBaseClasses=worker

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_dex_desugar

वर्कर्स का इस्तेमाल करके, Android dex और desugar की कार्रवाइयों को लगातार कई बार चलाने की सुविधा चालू करें.

बढ़कर:
  --persistent_android_dex_desugar
  --internal_persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_resource_processor

वर्कर्स का इस्तेमाल करके, पर्सिस्टेंट मल्टीप्लेक्स किए गए Android रिसॉर्स प्रोसेसर को चालू करें.

इनमें बदल जाता है:
  --persistent_android_resource_processor
  --modify_execution_info=AaptPackage=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceParser=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceValidator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceCompiler=+supports-multiplex-workers
  --modify_execution_info=RClassGenerator=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceLink=+supports-multiplex-workers
  --modify_execution_info=AndroidAapt2=+supports-multiplex-workers
  --modify_execution_info=AndroidAssetMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidResourceMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidCompiledResourceMerger=+supports-multiplex-workers
  --modify_execution_info=ManifestMerger=+supports-multiplex-workers
  --modify_execution_info=AndroidManifestMerger=+supports-multiplex-workers
  --modify_execution_info=Aapt2Optimize=+supports-multiplex-workers
  --modify_execution_info=AARGenerator=+supports-multiplex-workers

टैग: host_machine_resource_optimizations, execution

--persistent_multiplex_android_tools

Android के लगातार काम करने वाले और मल्टीप्लेक्स किए गए टूल (डेक्सिंग, डिसुगरिंग, संसाधन प्रोसेसिंग) चालू करें.

बढ़कर:
  --internal_persistent_multiplex_busybox_tools
  --persistent_multiplex_android_resource_processor
  --persistent_multiplex_android_dex_desugar

टैग: host_machine_resource_optimizations, execution

--[no]use_target_platform_for_tests डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो टेस्ट चलाने के लिए टेस्ट एक्ज़ेक ग्रुप के बजाय टारगेट प्लैटफ़ॉर्म का इस्तेमाल करें.

टैग: execution

ऐक्शन लागू करने के लिए इस्तेमाल की जाने वाली टूलचेन को कॉन्फ़िगर करने वाले विकल्प:

--android_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Android टारगेट कंपाइलर.

टैग: affects_outputs, 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> default: ""

यह उन प्लैटफ़ॉर्म को सेट करता है जिनका इस्तेमाल android_binary टारगेट करते हैं. अगर एक से ज़्यादा प्लैटफ़ॉर्म तय किए गए हैं, तो बाइनरी एक फ़ैट APK है. इसमें हर टारगेट प्लैटफ़ॉर्म के लिए नेटिव बाइनरी शामिल होती हैं.

टैग: changes_inputs, loading_and_analysis, loses_incremental_state

--cc_output_directory_tag=<a string> default: ""

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: affects_outputs

--compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट को कंपाइल करने के लिए इस्तेमाल किया जाने वाला C++ कंपाइलर.

टैग: loading_and_analysis, execution

--coverage_output_generator=<a build target label> default: "@bazel_tools//tools/test:lcov_merger"

उस बाइनरी का पाथ जिसका इस्तेमाल, रॉ कवरेज रिपोर्ट को पोस्टप्रोसेस करने के लिए किया जाता है. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:lcov_merger पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_report_generator=<a build target label> default: "@bazel_tools//tools/test:coverage_report_generator"

कवरेज रिपोर्ट जनरेट करने के लिए इस्तेमाल किए गए बाइनरी की जगह. यह बाइनरी टारगेट होना चाहिए. डिफ़ॉल्ट रूप से, यह @bazel_tools//tools/test:coverage_report_generator पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--coverage_support=<a build target label> default: "@bazel_tools//tools/test:coverage_support"

सहायता देने वाली फ़ाइलों की जगह. ये फ़ाइलें, हर उस टेस्ट ऐक्शन के इनपुट के लिए ज़रूरी होती हैं जो कोड कवरेज इकट्ठा करता है. डिफ़ॉल्ट रूप से, यह //tools/test:coverage_support पर सेट होता है.

टैग: changes_inputs, affects_outputs, loading_and_analysis

--custom_malloc=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह विकल्प, malloc को लागू करने का कस्टम तरीका तय करता है. यह सेटिंग, बिल्ड के नियमों में malloc एट्रिब्यूट को बदल देती है.

टैग: changes_inputs, affects_outputs

--[no]experimental_include_xcode_execution_requirements डिफ़ॉल्ट: "false"

अगर सेट है, तो हर Xcode ऐक्शन में "requires-xcode:{version}" एक्ज़ीक्यूशन की ज़रूरी शर्त जोड़ें. अगर Xcode के वर्शन में हाइफ़न वाला लेबल है, तो "requires-xcode-label:{version_label}" एक्ज़ीक्यूशन की ज़रूरी शर्त भी जोड़ें.

टैग: loses_incremental_state, loading_and_analysis, execution, experimental

--[no]experimental_prefer_mutual_xcode default: "true"

अगर यह नीति 'सही है' पर सेट है, तो स्थानीय और रिमोट, दोनों जगहों पर उपलब्ध Xcode के सबसे नए वर्शन का इस्तेमाल करें. अगर यह गलत है या दोनों के लिए कोई भी वर्शन उपलब्ध नहीं है, तो xcode-select के ज़रिए चुने गए Xcode के लोकल वर्शन का इस्तेमाल करें.

टैग: loses_incremental_state, experimental

--extra_execution_platforms=<comma-separated list of options> default: ""

कार्रवाइयां करने के लिए, इन प्लैटफ़ॉर्म का इस्तेमाल किया जा सकता है. प्लैटफ़ॉर्म को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. register_execution_platforms() की ओर से WORKSPACE फ़ाइल में बताए गए प्लैटफ़ॉर्म से पहले, इन प्लैटफ़ॉर्म पर विचार किया जाएगा. इस विकल्प को सिर्फ़ एक बार सेट किया जा सकता है. बाद में, फ़्लैग की गई सेटिंग पहले की सेटिंग को बदल देंगी.

टैग: execution

--extra_toolchains=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

टूलचेन के नियमों को टूलचेन रिज़ॉल्यूशन के दौरान ध्यान में रखा जाना चाहिए. टूलचेन को सटीक टारगेट या टारगेट पैटर्न के तौर पर तय किया जा सकता है. इन टूलचेन को, register_toolchains() की ओर से WORKSPACE फ़ाइल में बताए गए टूलचेन से पहले माना जाएगा.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

चेक-इन की गई libc लाइब्रेरी का लेबल. डिफ़ॉल्ट वैल्यू को क्रॉसटूल टूलचेन चुनता है. आपको इसे बदलने की ज़रूरत शायद ही कभी पड़ती है.

टैग: action_command_lines, affects_outputs

--host_compiler=<a string> डिफ़ॉल्ट: ब्यौरा देखें

यह फ़्लैग कोई कार्रवाई नहीं करता. आने वाले समय में इसे हटा दिया जाएगा.

टैग: loading_and_analysis, execution

--host_grte_top=<a label> डिफ़ॉल्ट: ब्यौरा देखें

अगर यह सेटिंग तय की जाती है, तो exec कॉन्फ़िगरेशन के लिए, libc की टॉप-लेवल डायरेक्ट्री (--grte_top) को बदल देती है.

टैग: action_command_lines, affects_outputs

--host_platform=<a build target label> default: "@bazel_tools//tools:host_platform"

होस्ट सिस्टम की जानकारी देने वाले प्लैटफ़ॉर्म के नियम का लेबल.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--[no]incompatible_bazel_test_exec_run_under default: "true"

अगर यह सुविधा चालू है, तो bazel test --run_under=//:runner, exec configuration में //:runner बनाता है. अगर यह सुविधा बंद है, तो टारगेट कॉन्फ़िगरेशन में //:runner बनाया जाता है. Bazel, एक्ज़ेक मशीनों पर टेस्ट करता है. इसलिए, पहला विकल्प ज़्यादा सही है. इससे bazel run पर कोई असर नहीं पड़ता. यह हमेशा टारगेट कॉन्फ़िगरेशन में --run_under=//foo बनाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_builtin_objc_strip_action default: "true"

यह तय करता है कि objc लिंकिंग के हिस्से के तौर पर स्ट्रिप ऐक्शन को चालू करना है या नहीं.

टैग: action_command_lines, incompatible_change

--[no]incompatible_dont_enable_host_nonhost_crosstool_features default: "true"

अगर यह सही है, तो Bazel, C++ टूलचेन में 'होस्ट' और 'नॉनहोस्ट' सुविधाएं चालू नहीं करेगा. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7407 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_enable_apple_toolchain_resolution डिफ़ॉल्ट: "false"

ऐपल के नियमों (Starlark और नेटिव) के लिए Apple SDK टूल चुनने के लिए, टूलचेन रिज़ॉल्यूशन का इस्तेमाल करें

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_remove_legacy_whole_archive default: "true"

अगर यह विकल्प सही है, तो Bazel डिफ़ॉल्ट रूप से लाइब्रेरी की डिपेंडेंसी को पूरे संग्रह के तौर पर लिंक नहीं करेगा. माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/7362 देखें.

टैग: loading_and_analysis, incompatible_change

--[no]incompatible_strip_executable_safely डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो एक्ज़ीक्यूटेबल के लिए स्ट्रिप ऐक्शन, -x फ़्लैग का इस्तेमाल करेगा. इससे डाइनैमिक सिंबल रिज़ॉल्यूशन में कोई रुकावट नहीं आएगी.

टैग: action_command_lines, incompatible_change

--[no]interface_shared_objects default: "true"

अगर टूलचेन में इंटरफ़ेस शेयर किए गए ऑब्जेक्ट इस्तेमाल करने की सुविधा है, तो उनका इस्तेमाल करें. फ़िलहाल, सभी 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 main workspace-relative path> default: ""

मैपिंग फ़ाइल की जगह. इससे यह पता चलता है कि अगर कोई प्लैटफ़ॉर्म सेट नहीं है, तो कौनसा प्लैटफ़ॉर्म इस्तेमाल करना है या अगर कोई प्लैटफ़ॉर्म पहले से मौजूद है, तो कौनसा फ़्लैग सेट करना है. यह मुख्य वर्कस्पेस रूट से जुड़ा होना चाहिए. डिफ़ॉल्ट रूप से, यह platform_mappings (वर्कस्पेस रूट के ठीक नीचे मौजूद फ़ाइल) पर सेट होता है.

टैग: affects_outputs, changes_inputs, loading_and_analysis, non_configurable

--platforms=<a build target label> default: ""

प्लैटफ़ॉर्म के नियमों के लेबल, जो मौजूदा कमांड के लिए टारगेट प्लैटफ़ॉर्म के बारे में बताते हैं.

टैग: affects_outputs, changes_inputs, loading_and_analysis

--python_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट प्लैटफ़ॉर्म पर Python टारगेट चलाने के लिए, Python इंटरप्रेटर का ऐब्सलूट पाथ. अब काम नहीं करता; --incompatible_use_python_toolchains ने बंद कर दिया है.

टैग: loading_and_analysis, affects_outputs

--tvos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

यह tvOS ऐप्लिकेशन बनाने के लिए, tvOS SDK टूल का वर्शन तय करता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से tvOS SDK के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--[no]use_platforms_in_apple_crosstool_transition डिफ़ॉल्ट: "false"

इससे apple_crosstool_transition, ज़रूरत पड़ने पर लेगसी --cpu के बजाय --platforms फ़्लैग की वैल्यू का इस्तेमाल करता है.

टैग: loading_and_analysis

--watchos_sdk_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

यह watchOS ऐप्लिकेशन बनाने के लिए, watchOS SDK के वर्शन के बारे में बताता है. अगर यह जानकारी नहीं दी जाती है, तो 'xcode_version' से watchOS SDK टूल के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xcode_version=<a string> डिफ़ॉल्ट: ब्यौरा देखें

अगर बताया गया है, तो यह संबंधित बिल्ड कार्रवाइयों के लिए, दिए गए वर्शन के Xcode का इस्तेमाल करता है. अगर यह जानकारी नहीं दी जाती है, तो Xcode के एक्ज़ीक्यूटर के डिफ़ॉल्ट वर्शन का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xcode_version_config=<a build target label> default: "@bazel_tools//tools/cpp:host_xcodes"

यह xcode_config नियम का लेबल है. इसका इस्तेमाल, बिल्ड कॉन्फ़िगरेशन में Xcode का वर्शन चुनने के लिए किया जाता है.

टैग: loses_incremental_state, loading_and_analysis

कमांड के आउटपुट को कंट्रोल करने वाले विकल्प:

--[no]apple_generate_dsym डिफ़ॉल्ट: "false"

डीबग सिंबल (.dSYM) फ़ाइलें जनरेट करनी हैं या नहीं.

टैग: affects_outputs, action_command_lines

--[no]build_runfile_links default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल के सिमलंक फ़ॉरेस्ट बनाएं. अगर यह वैल्यू 'गलत है' पर सेट है, तो इन्हें सिर्फ़ तब लिखें, जब स्थानीय कार्रवाई, जांच या कमांड चलाने के लिए इनकी ज़रूरत हो.

टैग: affects_outputs

--[no]build_runfile_manifests default: "true"

अगर सही है, तो सभी टारगेट के लिए रनफ़ाइल मेनिफ़ेस्ट लिखें. अगर ये गलत हैं, तो इन्हें शामिल न करें. इस विकल्प के गलत होने पर, स्थानीय जांच नहीं हो पाएंगी.

टैग: affects_outputs

--[no]build_test_dwp डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो C++ टेस्ट को स्टैटिक तौर पर और फ़िशन के साथ बनाने पर, टेस्ट बाइनरी के लिए .dwp फ़ाइल भी अपने-आप बन जाएगी.

टैग: loading_and_analysis, affects_outputs

--cc_proto_library_header_suffixes=<comma-separated set of options> default: ".pb.h"

यह cc_proto_library से बनाई गई हेडर फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

--cc_proto_library_source_suffixes=<comma-separated set of options> default: ".pb.cc"

यह विकल्प, cc_proto_library से बनाई गई सोर्स फ़ाइलों के सफ़िक्स सेट करता है.

टैग: affects_outputs, loading_and_analysis

--[no]experimental_proto_descriptor_sets_include_source_info डिफ़ॉल्ट: "false"

proto_library में Java api के वैकल्पिक वर्शन के लिए अतिरिक्त कार्रवाइयां चलाएं.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_save_feature_state डिफ़ॉल्ट: "false"

इस कुकी का इस्तेमाल, चालू की गई और अनुरोध की गई सुविधाओं की स्थिति को कंपाइल करने के आउटपुट के तौर पर सेव करने के लिए किया जाता है.

टैग: affects_outputs, experimental

--fission=<a set of compilation modes> डिफ़ॉल्ट: "no"

इससे यह तय होता है कि C++ कंपाइलेशन और लिंक के लिए, फ़िशन का इस्तेमाल करने वाले कंपाइलेशन मोड कौनसे हैं. यह {'fastbuild', 'dbg', 'opt'} का कोई भी कॉम्बिनेशन हो सकता है. इसके अलावा, सभी मोड चालू करने के लिए 'yes' और सभी मोड बंद करने के लिए 'no' जैसी खास वैल्यू भी इस्तेमाल की जा सकती हैं.

टैग: loading_and_analysis, action_command_lines, affects_outputs

--[no]incompatible_always_include_files_in_data default: "true"

अगर यह सही है, तो नेटिव नियम अपनी रनफ़ाइल में DefaultInfo.files डेटा डिपेंडेंसी जोड़ते हैं. यह Starlark नियमों के लिए सुझाई गई सेटिंग से मेल खाती है (रनफ़ाइल की ऐसी सुविधाएं जिनका इस्तेमाल नहीं करना चाहिए).

टैग: affects_outputs, incompatible_change

--[no]incompatible_compact_repo_mapping_manifest default: "true"

चालू होने पर, {binary}.repo_mapping फ़ाइल, मॉड्यूल एक्सटेंशन के रेपो मैपिंग को सिर्फ़ एक बार दिखाती है. ऐसा तब होता है, जब एक्सटेंशन से जनरेट होने वाले हर रेपो के लिए एक बार दिखाने के बजाय, रनफ़ाइलें योगदान करती हैं.

टैग: affects_outputs, incompatible_change

--incompatible_disable_select_on=<comma-separated set of options> default: ""

उन फ़्लैग की सूची जिनके लिए select() में इस्तेमाल करने की सुविधा बंद है.

टैग: loading_and_analysis, incompatible_change, non_configurable

--[no]incompatible_filegroup_runfiles_for_data default: "true"

अगर यह सही है, तो srcs एट्रिब्यूट में शामिल टारगेट की रनफ़ाइलें, उन टारगेट के लिए उपलब्ध होती हैं जो फ़ाइल ग्रुप को डेटा डिपेंडेंसी के तौर पर इस्तेमाल करते हैं.

टैग: incompatible_change

--[no]objc_generate_linkmap डिफ़ॉल्ट: "false"

इससे यह तय किया जाता है कि लिंकमैप फ़ाइल जनरेट करनी है या नहीं.

टैग: affects_outputs

--[no]save_temps डिफ़ॉल्ट: "false"

अगर यह सेट है, तो gcc से मिले कुछ समय के लिए आउटपुट सेव किए जाएंगे. इनमें .s फ़ाइलें (असेंबलर कोड), .i फ़ाइलें (प्रीप्रोसेस्ड C), और .ii फ़ाइलें (प्रीप्रोसेस्ड C++) शामिल हैं.

टैग: affects_outputs

ऐसे विकल्प जिनसे उपयोगकर्ता, वैरिएबल के आउटपुट को कॉन्फ़िगर कर सकता है. इससे वैरिएबल की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह टारगेट कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध एनवायरमेंट वैरिएबल का सेट तय करता है. वैरिएबल को name के ज़रिए तय किया जा सकता है. ऐसे में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name के ज़रिए भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. वहीं, अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को जोड़ दिया जाता है.

ध्यान दें कि जब तक --incompatible_repo_env_ignores_action_env सही नहीं होता, तब तक सभी name=value जोड़े, रिपॉज़िटरी के नियमों के लिए उपलब्ध रहेंगे.

टैग: action_command_lines

--allowed_cpu_values=<comma-separated set of options> default: ""

--cpu फ़्लैग के लिए इस्तेमाल की जा सकने वाली वैल्यू.

टैग: changes_inputs, affects_outputs

--[no]android_databinding_use_androidx default: "true"

AndroidX के साथ काम करने वाली डेटा-बाइंडिंग फ़ाइलें जनरेट करें. इसका इस्तेमाल सिर्फ़ डेटा बाइंडिंग v2 के साथ किया जाता है. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]android_databinding_use_v3_4_args default: "true"

3.4.0 आर्ग्युमेंट के साथ android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--android_dynamic_mode=<off, default or fully> default: "off"

इससे यह तय होता है कि जब cc_binary, शेयर की गई लाइब्रेरी को साफ़ तौर पर नहीं बनाता है, तो Android नियमों की C++ डिपेंडेंसी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक रूप से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: affects_outputs, loading_and_analysis

--android_manifest_merger_order=<alphabetical, alphabetical_by_configuration or dependency> default: "alphabetical"

यह विकल्प, Android बाइनरी के लिए मेनिफ़ेस्ट मर्जर को पास किए गए मेनिफ़ेस्ट का क्रम सेट करता है. ALPHABETICAL का मतलब है कि मेनिफ़ेस्ट को execroot के हिसाब से पाथ के हिसाब से क्रम में लगाया जाता है. ALPHABETICAL_BY_CONFIGURATION का मतलब है कि मेनिफ़ेस्ट को आउटपुट डायरेक्ट्री में कॉन्फ़िगरेशन डायरेक्ट्री के हिसाब से पाथ के हिसाब से क्रम से लगाया जाता है. DEPENDENCY का मतलब है कि मेनिफ़ेस्ट को इस तरह से क्रम में लगाया जाता है कि हर लाइब्रेरी का मेनिफ़ेस्ट, उसकी डिपेंडेंसी के मेनिफ़ेस्ट से पहले आता है.

टैग: action_command_lines, execution

--[no]android_resource_shrinking डिफ़ॉल्ट: "false"

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis

--catalyst_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

उन आर्किटेक्चर की कॉमा लगाकर अलग की गई सूची जिनके लिए Apple Catalyst बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--[no]collect_code_coverage डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो Bazel कोड को इंस्ट्रुमेंट करेगा. इसके लिए, जहां भी मुमकिन होगा वहां ऑफ़लाइन इंस्ट्रुमेंटेशन का इस्तेमाल किया जाएगा. साथ ही, टेस्ट के दौरान कवरेज की जानकारी इकट्ठा करेगा. सिर्फ़ उन टारगेट पर असर पड़ेगा जो --instrumentation_filter से मेल खाते हैं. आम तौर पर, इस विकल्प को सीधे तौर पर नहीं चुना जाना चाहिए. इसके बजाय, bazel coverage कमांड का इस्तेमाल करना चाहिए.

टैग: affects_outputs

--compilation_mode=<fastbuild, dbg or opt> [-c] default: "fastbuild"

उस मोड के बारे में बताएं जिसमें बाइनरी बनाई जाएगी. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--conlyopt=<a string> कई बार इस्तेमाल किया गया हो

C सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--copt=<a string> कई बार इस्तेमाल किया गया हो

gcc को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--cpu=<a string> default: ""

बंद कर दिया गया है: Blaze इस फ़्लैग का इस्तेमाल इंटरनल तौर पर नहीं करता है. हालांकि, पुराने सिस्टम के साथ काम करने की सुविधा के लिए, लेगसी प्लैटफ़ॉर्म मैपिंग मौजूद हैं. इस फ़्लैग का इस्तेमाल न करें. इसके बजाय, प्लैटफ़ॉर्म की सही परिभाषा के साथ --platforms का इस्तेमाल करें.

टैग: changes_inputs, affects_outputs

--cs_fdo_absolute_path=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, सीएसएफ़डीओ प्रोफ़ाइल की जानकारी का इस्तेमाल करें. प्रोफ़ाइल फ़ाइल, रॉ या इंडेक्स की गई LLVM प्रोफ़ाइल फ़ाइल वाली ZIP फ़ाइल का पूरा पाथ डालें.

टैग: affects_outputs

--cs_fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कॉन्टेक्स्ट के हिसाब से संवेदनशील FDO इंस्ट्रुमेंटेशन के साथ बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.

टैग: affects_outputs

--cs_fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

cs_fdo_profile, कॉन्टेक्स्ट के हिसाब से काम करने वाली प्रोफ़ाइल को दिखाता है. इसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाता है.

टैग: affects_outputs

--cxxopt=<a string> कई बार इस्तेमाल किया गया हो

C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--define=<a 'name=value' assignment> कई बार इस्तेमाल किया गया हो

हर --define विकल्प, बिल्ड वैरिएबल के लिए असाइनमेंट तय करता है. अगर किसी वैरिएबल के लिए एक से ज़्यादा वैल्यू मौजूद हैं, तो सबसे बाद में सेट की गई वैल्यू का इस्तेमाल किया जाता है.

टैग: changes_inputs, affects_outputs

--dynamic_mode=<off, default or fully> default: "default"

इससे यह तय होता है कि C++ बाइनरी को डाइनैमिक तरीके से लिंक किया जाएगा या नहीं. 'default' का मतलब है कि Bazel यह तय करेगा कि डाइनैमिक तरीके से लिंक करना है या नहीं. 'पूरी तरह से' का मतलब है कि सभी लाइब्रेरी डाइनैमिक तरीके से लिंक होंगी. 'off' का मतलब है कि सभी लाइब्रेरी, ज़्यादातर स्टैटिक मोड में लिंक की जाएंगी.

टैग: loading_and_analysis, affects_outputs

--[no]enable_propeller_optimize_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो Propeller Optimize के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी होगी.

टैग: affects_outputs

--[no]enable_remaining_fdo_absolute_paths default: "true"

अगर इसे सेट किया जाता है, तो FDO के लिए ऐब्सलूट पाथ का इस्तेमाल करने पर गड़बड़ी दिखेगी.

टैग: affects_outputs

--[no]enable_runfiles default: "auto"

रनफ़ाइल के सिमलिंक ट्री को चालू करें. Windows पर यह डिफ़ॉल्ट रूप से बंद होता है, जबकि अन्य प्लैटफ़ॉर्म पर चालू होता है.

टैग: affects_outputs

--exec_aspects=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन पहलुओं की सूची जिन्हें एक्ज़ीक्यूटिव के कॉन्फ़िगर किए गए टारगेट पर लागू किया जाना है. भले ही, वे टॉप-लेवल के टारगेट हों या न हों. इस सुविधा पर एक्सपेरिमेंट जारी है और इसमें बदलाव हो सकता है.

टैग: loading_and_analysis

--experimental_action_listener=<a build target label> कई बार इस्तेमाल किया गया हो

इसे पहलुओं के पक्ष में बंद कर दिया गया है. extra_action को मौजूदा बिल्ड ऐक्शन से अटैच करने के लिए, action_listener का इस्तेमाल करें.

टैग: execution, experimental

--[no]experimental_android_compress_java_resources डिफ़ॉल्ट: "false"

APK में Java संसाधनों को कंप्रेस करना

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_databinding_v2 default: "true"

Android databinding v2 का इस्तेमाल करें. इस फ़्लैग का कोई असर नहीं होता.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_android_resource_shrinking डिफ़ॉल्ट: "false"

यह विकल्प, ProGuard का इस्तेमाल करने वाले android_binary APK के लिए, संसाधन कम करने की सुविधा चालू करता है.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_android_rewrite_dexes_with_rex डिफ़ॉल्ट: "false"

dex फ़ाइलों को फिर से लिखने के लिए, rex टूल का इस्तेमाल करें

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_collect_code_coverage_for_generated_files डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो Bazel जनरेट की गई फ़ाइलों के लिए, कवरेज की जानकारी भी इकट्ठा करेगा.

टैग: affects_outputs, experimental

--experimental_objc_fastbuild_options=<comma-separated list of options> default: "-O0,-DDEBUG=1"

इन स्ट्रिंग का इस्तेमाल, objc fastbuild कंपाइलर के विकल्पों के तौर पर करता है.

टैग: action_command_lines

--[no]experimental_omitfp डिफ़ॉल्ट: "false"

अगर सही है, तो स्टैक अनवाइंडिंग के लिए libunwind का इस्तेमाल करें. साथ ही, -fomit-frame-pointer और -fasynchronous-unwind-tables के साथ कंपाइल करें.

टैग: action_command_lines, affects_outputs, experimental

--experimental_output_paths=<off or strip> default: "off"

आउटपुट ट्री में कहां पर किस मॉडल का इस्तेमाल करना है, ताकि नियम अपने आउटपुट लिख सकें. खास तौर पर, मल्टी-प्लैटफ़ॉर्म / मल्टी-कॉन्फ़िगरेशन बिल्ड के लिए. यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है. ज़्यादा जानकारी के लिए, GH-6526 देखें. Starlark ऐक्शन, execution_requirements डिक्शनरी में supports-path-mapping कुंजी जोड़कर, पाथ मैपिंग की सुविधा के लिए ऑप्ट-इन कर सकते हैं.

टैग: loses_incremental_state, bazel_internal_configuration, affects_outputs, execution

--experimental_override_platform_cpu_name=<a 'label=value' assignment> कई बार इस्तेमाल किया गया हो

हर एंट्री label=value के फ़ॉर्मैट में होनी चाहिए. इसमें लेबल का मतलब किसी प्लैटफ़ॉर्म से है. साथ ही, वैल्यू वह छोटा नाम है जिसका इस्तेमाल करके, $(TARGET_CPU) मेक वैरिएबल और आउटपुट पाथ में प्लैटफ़ॉर्म के सीपीयू के नाम को बदला जा सकता है. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाता है, जब --experimental_platform_in_output_dir, --incompatible_target_cpu_from_platform या --incompatible_bep_cpu_from_platform की वैल्यू 'सही है' पर सेट हो. नाम रखने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है.

टैग: affects_outputs, experimental

--[no]experimental_platform_in_output_dir default: "Auto"

अगर यह विकल्प सही है, तो आउटपुट डायरेक्ट्री के नाम में सीपीयू के बजाय टारगेट प्लैटफ़ॉर्म के लिए शॉर्टनेम का इस्तेमाल किया जाता है. यह स्कीम एक्सपेरिमेंट के तौर पर उपलब्ध है और इसमें बदलाव हो सकता है:

1. अगर --platforms विकल्प में सिर्फ़ एक वैल्यू नहीं है, तो प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है. ऐसा कभी-कभी होता है.
2. इसके बाद, अगर मौजूदा प्लैटफ़ॉर्म के लिए कोई छोटा नाम --experimental_override_name_platform_in_output_dir ने रजिस्टर किया है, तो उस छोटे नाम का इस्तेमाल किया जाता है.
3. इसके बाद, अगर --experimental_use_platforms_in_output_dir_legacy_heuristic सेट है, तो मौजूदा प्लैटफ़ॉर्म के लेबल के आधार पर, छोटा नाम इस्तेमाल करें.
4. आखिर में, प्लैटफ़ॉर्म के विकल्प के हैश का इस्तेमाल किया जाता है.

टैग: affects_outputs, experimental

--[no]experimental_py_binaries_include_label डिफ़ॉल्ट: "false"

py_binary टारगेट में उनका लेबल शामिल होता है. भले ही, स्टैंपिंग की सुविधा बंद हो.

टैग: affects_outputs, experimental

--[no]experimental_use_llvm_covmap डिफ़ॉल्ट: "false"

अगर ऐसा तय किया गया है, तो collect_code_coverage चालू होने पर Bazel, gcov के बजाय llvm-cov कवरेज मैप की जानकारी जनरेट करेगा.

टैग: changes_inputs, affects_outputs, loading_and_analysis, experimental

--[no]experimental_use_platforms_in_output_dir_legacy_heuristic default: "true"

कृपया इस फ़्लैग का इस्तेमाल सिर्फ़ माइग्रेशन या टेस्टिंग की सुझाई गई रणनीति के तहत करें. ध्यान दें कि इस अनुमानित तरीके में कुछ कमियां हैं. इसलिए, हमारा सुझाव है कि आप सिर्फ़ --experimental_override_name_platform_in_output_dir पर भरोसा करने के लिए माइग्रेट करें.

टैग: affects_outputs, experimental

--fdo_instrument=<a string> डिफ़ॉल्ट: ब्यौरा देखें

एफ़डीओ इंस्ट्रुमेंटेशन की मदद से बाइनरी जनरेट करें. Clang/LLVM कंपाइलर के साथ, यह उस डायरेक्ट्री का नाम भी स्वीकार करता है जिसमें रनटाइम के दौरान रॉ प्रोफ़ाइल फ़ाइलें डंप की जाएंगी.

टैग: affects_outputs

--fdo_optimize=<a string> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, FDO प्रोफ़ाइल की जानकारी का इस्तेमाल करें. .gcda फ़ाइल ट्री वाली zip फ़ाइल, ऑटो प्रोफ़ाइल वाली afdo फ़ाइल या LLVM प्रोफ़ाइल फ़ाइल का नाम डालें. यह फ़्लैग, लेबल के तौर पर तय की गई फ़ाइलों को भी स्वीकार करता है.जैसे, //foo/bar:file.afdo - आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ने की ज़रूरत पड़ सकती है. साथ ही, यह fdo_profile टारगेट की ओर इशारा करने वाले लेबल को भी स्वीकार करता है. यह फ़्लैग, fdo_profile नियम की जगह लागू होगा.

टैग: affects_outputs

--fdo_prefetch_hints=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कैश मेमोरी में पहले से फ़ेच करने के सुझावों का इस्तेमाल करें.

टैग: affects_outputs

--fdo_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

fdo_profile, उस प्रोफ़ाइल को दिखाता है जिसका इस्तेमाल ऑप्टिमाइज़ेशन के लिए किया जाना है.

टैग: affects_outputs

--features=<a string> कई बार इस्तेमाल किया गया हो

टारगेट कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं. --host_features भी देखें.

टैग: changes_inputs, affects_outputs

--[no]force_pic डिफ़ॉल्ट: "false"

इस विकल्प के चालू होने पर, सभी C++ कंपाइलेशन, पोज़िशन-इंडिपेंडेंट कोड ("-fPIC") जनरेट करते हैं. लिंक, पीआईसी प्री-बिल्ट लाइब्रेरी को नॉन-पीआईसी लाइब्रेरी के मुकाबले ज़्यादा प्राथमिकता देते हैं. साथ ही, लिंक, पोज़िशन-इंडिपेंडेंट एक्ज़ीक्यूटेबल ("-pie") जनरेट करते हैं.

टैग: loading_and_analysis, affects_outputs

--host_action_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह उन एनवायरमेंट वैरिएबल के सेट के बारे में बताता है जो एक्ज़ीक्यूशन कॉन्फ़िगरेशन वाली कार्रवाइयों के लिए उपलब्ध होते हैं. वैरिएबल को name से तय किया जा सकता है. इस मामले में, वैल्यू को इनवॉकेशन एनवायरमेंट से लिया जाएगा. इसके अलावा, name=value पेयर से भी वैरिएबल को तय किया जा सकता है. यह इनवॉकेशन एनवायरमेंट से अलग वैल्यू सेट करता है. साथ ही, =name से भी वैरिएबल को तय किया जा सकता है. यह उस नाम के वैरिएबल को अनसेट करता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है. एक ही वैरिएबल के लिए दिए गए विकल्पों में से, सबसे नया विकल्प चुना जाता है. अलग-अलग वैरिएबल के लिए दिए गए विकल्पों को इकट्ठा किया जाता है.

टैग: action_command_lines

--host_compilation_mode=<fastbuild, dbg or opt> default: "opt"

यह तय करें कि बिल्ड के दौरान इस्तेमाल किए जाने वाले टूल किस मोड में बनाए जाएंगे. वैल्यू: fastbuild, dbg, opt.

टैग: affects_outputs, action_command_lines

--host_conlyopt=<a string> कई बार इस्तेमाल किया गया हो

C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प. इसका इस्तेमाल, exec कॉन्फ़िगरेशन में C (लेकिन C++) सोर्स फ़ाइलों को कंपाइल करते समय किया जाता है.

टैग: action_command_lines, affects_outputs

--host_copt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_cpu=<a string> default: ""

होस्ट सीपीयू.

टैग: changes_inputs, affects_outputs

--host_cxxopt=<a string> कई बार इस्तेमाल किया गया हो

exec कॉन्फ़िगरेशन में बनाए गए टूल के लिए, C++ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_features=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में बनाए गए टारगेट के लिए, दी गई सुविधाएं डिफ़ॉल्ट रूप से चालू या बंद रहेंगी. -{feature} को सेट करने पर, यह सुविधा बंद हो जाएगी. नकारात्मक फ़ीचर, हमेशा सकारात्मक फ़ीचर की जगह लेती हैं.

टैग: changes_inputs, affects_outputs

--host_linkopt=<a string> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में टूल लिंक करते समय, लिंकर को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--host_macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

होस्ट टारगेट के लिए, macOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--host_per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

एक्ज़ेक कॉन्फ़िगरेशन में कुछ फ़ाइलों को कंपाइल करते समय, C/C++ कंपाइलर को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --host_per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों के gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--[no]incompatible_auto_exec_groups डिफ़ॉल्ट: "false"

इस सुविधा को चालू करने पर, नियम के लिए इस्तेमाल की गई हर टूलचेन के लिए, एक्ज़ेक ग्रुप अपने-आप बन जाता है. इसके लिए, नियम को अपनी कार्रवाइयों पर toolchain पैरामीटर तय करना होगा. ज़्यादा जानकारी के लिए, GH-17134 देखें.

टैग: affects_outputs, incompatible_change

--[no]incompatible_merge_genfiles_directory default: "true"

अगर सही है, तो genfiles डायरेक्ट्री को बिन डायरेक्ट्री में शामिल किया जाता है.

टैग: affects_outputs, incompatible_change

--[no]incompatible_target_cpu_from_platform default: "true"

अगर टारगेट प्लैटफ़ॉर्म के सीपीयू की सीमा (@platforms//cpu:cpu) तय की गई है, तो $(TARGET_CPU) मेक वैरिएबल सेट करने के लिए इसका इस्तेमाल किया जाता है.

टैग: loading_and_analysis, incompatible_change

--[no]instrument_test_targets डिफ़ॉल्ट: "false"

कवरेज की सुविधा चालू होने पर, यह तय करता है कि टेस्ट के नियमों को लागू करना है या नहीं. इस विकल्प को सेट करने पर, --instrumentation_filter में शामिल नियमों की जांच की जाती है. ऐसा न होने पर, टेस्ट के नियमों को हमेशा कवरेज इंस्ट्रूमेंटेशन से बाहर रखा जाता है.

टैग: affects_outputs

--instrumentation_filter=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-/javatests[/:],-/test/java[/:]"

कवरेज की सुविधा चालू होने पर, सिर्फ़ उन नियमों को इंस्ट्रुमेंट किया जाएगा जिनके नाम, तय किए गए रेगुलर एक्सप्रेशन (रेगुलर एक्सप्रेशन) पर आधारित फ़िल्टर में शामिल हैं. इसके बजाय, '-' से शुरू होने वाले नियमों को शामिल नहीं किया जाता. ध्यान दें कि सिर्फ़ टेस्ट से जुड़े नियमों को इंस्ट्रूमेंट किया जाता है. हालांकि, अगर --instrument_test_targets चालू है, तो सभी नियमों को इंस्ट्रूमेंट किया जाता है.

टैग: affects_outputs

--ios_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, iOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'ios_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--ios_multi_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

ios_application बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची. नतीजा एक यूनिवर्सल बाइनरी होती है, जिसमें सभी आर्किटेक्चर शामिल होते हैं.

टैग: loses_incremental_state, loading_and_analysis

--[no]legacy_whole_archive default: "true"

इस विकल्प का इस्तेमाल अब नहीं किया जा सकता. इसकी जगह --incompatible_remove_legacy_whole_archive का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/7362 पर जाएं. चालू होने पर, cc_binary नियमों के लिए --whole-archive का इस्तेमाल करें. इन नियमों में linkshared=True और linkopts में linkstatic=True या '-static' होना चाहिए. यह सिर्फ़ पुराने सिस्टम के साथ काम करने की सुविधा के लिए है. इसके बजाय, हमेशा लिंक करने की सुविधा (alwayslink=1) का इस्तेमाल करना बेहतर विकल्प है.

टैग: action_command_lines, affects_outputs, deprecated

--linkopt=<a string> कई बार इस्तेमाल किया गया हो

लिंक करते समय gcc को पास करने का अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--ltobackendopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ बैकएंड के चरण में पास करने का अतिरिक्त विकल्प (under --features=thin_lto).

टैग: action_command_lines, affects_outputs

--ltoindexopt=<a string> कई बार इस्तेमाल किया गया हो

एलटीओ इंडेक्सिंग के चरण में पास करने के लिए अतिरिक्त विकल्प (--features=thin_lto के तहत).

टैग: action_command_lines, affects_outputs

--macos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple macOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

--macos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट के लिए, macOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'macos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--memprof_profile=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

memprof प्रोफ़ाइल का इस्तेमाल करें.

टैग: affects_outputs

--[no]objc_debug_with_GLIBCXX डिफ़ॉल्ट: "false"

अगर इसे सेट किया गया है और कंपाइलेशन मोड को 'dbg' पर सेट किया गया है, तो GLIBCXX_DEBUG, GLIBCXX_DEBUG_PEDANTIC, और GLIBCPP_CONCEPT_CHECKS को तय करें.

टैग: action_command_lines

--[no]objc_enable_binary_stripping डिफ़ॉल्ट: "false"

लिंक की गई बाइनरी पर सिंबल और डेड-कोड स्ट्रिपिंग की जानी चाहिए या नहीं. अगर यह फ़्लैग और --compilation_mode=opt, दोनों दिए गए हैं, तो बाइनरी स्ट्रिपिंग की जाएगी.

टैग: action_command_lines

--objccopt=<a string> कई बार इस्तेमाल किया गया हो

Objective-C/C++ सोर्स फ़ाइलों को कंपाइल करते समय, gcc को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines

--per_file_copt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ फ़ाइलों को कंपाइल करते समय, gcc को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प. इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_copt=//foo/.*.cc,-//foo/bar.cc@-O0, //foo/ में मौजूद bar.cc को छोड़कर, सभी cc फ़ाइलों की gcc कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--per_file_ltobackendopt=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths followed by an @ and a comma separated list of options> कई बार इस्तेमाल किया गया हो

कुछ बैकएंड ऑब्जेक्ट को कंपाइल करते समय, LTO बैकएंड को चुनिंदा तौर पर पास करने के लिए अतिरिक्त विकल्प (under --features=thin_lto). इस विकल्प को कई बार पास किया जा सकता है. सिंटैक्स: regex_filter@option_1,option_2,...,option_n. यहां regex_filter का मतलब, शामिल और बाहर किए गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. option_1 से लेकर option_n तक का मतलब, कमांड लाइन के किसी भी विकल्प से है. अगर किसी विकल्प में कॉमा है, तो उसे बैकस्लैश के साथ कोट करना होगा. विकल्पों में @ शामिल हो सकता है. स्ट्रिंग को अलग करने के लिए, सिर्फ़ पहले @ का इस्तेमाल किया जाता है. उदाहरण: --per_file_ltobackendopt=//foo/.*.o,-//foo/bar.o@-O0, //foo/ में मौजूद bar.o को छोड़कर, सभी o फ़ाइलों के LTO बैकएंड कमांड लाइन में -O0 कमांड लाइन विकल्प जोड़ता है.

टैग: action_command_lines, affects_outputs

--platform_suffix=<a string> डिफ़ॉल्ट: ब्यौरा देखें

इससे कॉन्फ़िगरेशन डायरेक्ट्री में जोड़े जाने वाले सफ़िक्स के बारे में पता चलता है.

टैग: loses_incremental_state, affects_outputs, loading_and_analysis

--propeller_optimize=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

बिल्ड टारगेट को ऑप्टिमाइज़ करने के लिए, Propeller की प्रोफ़ाइल की जानकारी का इस्तेमाल करें.Propeller की प्रोफ़ाइल में, cc प्रोफ़ाइल और ld प्रोफ़ाइल में से कम से कम एक फ़ाइल होनी चाहिए. यह फ़्लैग, बिल्ड लेबल स्वीकार करता है. यह लेबल, प्रोपेलर प्रोफ़ाइल के इनपुट फ़ाइलों के बारे में होना चाहिए. उदाहरण के लिए, a/b/BUILD फ़ाइल में लेबल को इस तरह से तय किया गया है:propeller_optimize( name = "propeller_profile", cc_profile = "propeller_cc_profile.txt", ld_profile = "propeller_ld_profile.txt",)Bazel को ये फ़ाइलें दिखाने के लिए, हो सकता है कि आपको संबंधित पैकेज में exports_files डायरेक्टिव जोड़ना पड़े. इस विकल्प का इस्तेमाल इस तरह किया जाना चाहिए: --propeller_optimize=//a/b:propeller_profile

टैग: action_command_lines, affects_outputs

--propeller_optimize_absolute_cc_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए cc_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

--propeller_optimize_absolute_ld_profile=<a string> डिफ़ॉल्ट: ब्यौरा देखें

Propeller Optimized बिल्ड के लिए, ld_profile फ़ाइल का पूरा पाथ.

टैग: affects_outputs

--run_under=<a prefix in front of command> डिफ़ॉल्ट: ब्यौरा देखें

test और run कमांड के लिए, एक्ज़ीक्यूटेबल से पहले डालने के लिए प्रीफ़िक्स. अगर वैल्यू foo -bar है और एक्ज़ीक्यूशन कमांड लाइन test_binary -baz है, तो फ़ाइनल कमांड लाइन foo -bar test_binary -baz होगी. यह एक्ज़ीक्यूटेबल टारगेट का लेबल भी हो सकता है. इसके कुछ उदाहरण यहां दिए गए हैं:

• valgrind
• strace
• strace -c
• valgrind --quiet --num-callers=20
• //package:target
• //package:target --options

टैग: action_command_lines

--[no]share_native_deps default: "true"

अगर यह वैल्यू सही है, तो एक जैसी सुविधा वाली नेटिव लाइब्रेरी को अलग-अलग टारगेट के साथ शेयर किया जाएगा

टैग: loading_and_analysis, affects_outputs

--[no]stamp डिफ़ॉल्ट: "false"

बाइनरी पर तारीख, उपयोगकर्ता नाम, होस्टनेम, Workspace की जानकारी वगैरह की मुहर लगाएं.

टैग: affects_outputs

--strip=<always, sometimes or never> डिफ़ॉल्ट: "कभी-कभी"

इससे यह तय किया जाता है कि बाइनरी और शेयर की गई लाइब्रेरी को हटाना है या नहीं. इसके लिए, "-Wl,--strip-debug" का इस्तेमाल किया जाता है. 'sometimes' की डिफ़ॉल्ट वैल्यू का मतलब है कि अगर --compilation_mode=fastbuild है, तो स्ट्रिप करें.

टैग: affects_outputs

--stripopt=<a string> कई बार इस्तेमाल किया गया हो

'<name>.stripped' बाइनरी जनरेट करते समय, स्ट्रिप को पास करने के लिए अतिरिक्त विकल्प.

टैग: action_command_lines, affects_outputs

--tvos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई उन आर्किटेक्चर की सूची जिनके लिए Apple tvOS बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--tvos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, tvOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'tvos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--visionos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

Apple visionOS के लिए बाइनरी बनाने के लिए, कॉमा लगाकर अलग किए गए आर्किटेक्चर की सूची.

टैग: loses_incremental_state, loading_and_analysis

--watchos_cpus=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

कॉमा लगाकर अलग की गई, उन आर्किटेक्चर की सूची जिनके लिए Apple watchOS बाइनरी बनानी हैं.

टैग: loses_incremental_state, loading_and_analysis

--watchos_minimum_os=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

टारगेट सिम्युलेटर और डिवाइसों के लिए, watchOS का कम से कम ज़रूरी वर्शन. अगर यह जानकारी नहीं दी जाती है, तो 'watchos_sdk_version' का इस्तेमाल किया जाता है.

टैग: loses_incremental_state

--xbinary_fdo=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

कंपाइलेशन को ऑप्टिमाइज़ करने के लिए, XbinaryFDO की प्रोफ़ाइल की जानकारी का इस्तेमाल करें. डिफ़ॉल्ट क्रॉस बाइनरी प्रोफ़ाइल का नाम तय करें. इस विकल्प का इस्तेमाल --fdo_instrument/--fdo_optimize/--fdo_profile के साथ करने पर, उन विकल्पों को हमेशा प्राथमिकता दी जाएगी. ऐसा माना जाएगा कि xbinary_fdo को कभी भी तय नहीं किया गया है.

टैग: affects_outputs

ऐसे विकल्प जिनसे यह तय होता है कि Bazel, मान्य बिल्ड इनपुट (नियम की परिभाषाएं, फ़्लैग कॉम्बिनेशन वगैरह) को कितनी सख्ती से लागू करता है:

--[no]check_visibility default: "true"

अगर यह सुविधा बंद है, तो टारगेट डिपेंडेंसी में दिखने वाली गड़बड़ियों को चेतावनियों में बदल दिया जाता है.

टैग: build_file_semantics, non_configurable

--[no]desugar_for_android default: "true"

यह तय करता है कि Java 8 के बाइटकोड को dexing से पहले desugar करना है या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]desugar_java8_libs डिफ़ॉल्ट: "false"

लेगसी डिवाइसों के लिए बनाए गए ऐप्लिकेशन में, Java 8 के साथ काम करने वाली लाइब्रेरी शामिल करनी हैं या नहीं.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state, experimental

--[no]enforce_constraints default: "true"

यह जांच करता है कि हर टारगेट किस एनवायरमेंट के साथ काम करता है. साथ ही, अगर किसी टारगेट की डिपेंडेंसी ऐसे एनवायरमेंट के साथ काम नहीं करती हैं, तो गड़बड़ियों की जानकारी देता है

टैग: build_file_semantics

--[no]experimental_check_desugar_deps default: "true"

Android बाइनरी लेवल पर, सही डिसुगरिंग की दोबारा जांच करनी है या नहीं.

टैग: eagerness_to_exit, loading_and_analysis, experimental

--[no]experimental_enforce_transitive_visibility डिफ़ॉल्ट: "false"

अगर यह वैल्यू सही है, तो package()s को transitive_visibility एट्रिब्यूट सेट करने की अनुमति दें. इससे यह तय किया जा सकेगा कि कौनसे पैकेज उन पर निर्भर हो सकते हैं.

टैग: build_file_semantics, experimental

--experimental_one_version_enforcement=<off, warning or error> डिफ़ॉल्ट: "बंद है"

इस विकल्प को चालू करने पर, यह लागू किया जाता है कि java_binary नियम में क्लासपाथ पर एक ही क्लास फ़ाइल के एक से ज़्यादा वर्शन शामिल नहीं किए जा सकते. इस नीति के उल्लंघन की वजह से, बिल्ड में गड़बड़ी हो सकती है या सिर्फ़ चेतावनियां मिल सकती हैं.

टैग: loading_and_analysis

--experimental_strict_java_deps=<off, warn, error, strict or default> default: "default"

अगर यह सही है, तो यह जांच करता है कि Java टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit

--[no]incompatible_check_testonly_for_output_files डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो ज़रूरी शर्तों को पूरा करने वाले उन टारगेट के लिए testonly की जांच करें जो आउटपुट फ़ाइलें हैं. इसके लिए, जनरेट करने वाले नियम के testonly को देखें. यह सेटिंग, दिखने की स्थिति की जांच करने की सुविधा से मेल खाती है.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_disable_native_android_rules डिफ़ॉल्ट: "false"

यह नीति चालू होने पर, Android के नेटिव नियमों का सीधे तौर पर इस्तेमाल नहीं किया जा सकेगा. कृपया https://github.com/bazelbuild/rules_android पर जाकर, Starlark Android के नियमों का इस्तेमाल करें

टैग: eagerness_to_exit, incompatible_change

--[no]incompatible_disable_native_apple_binary_rule डिफ़ॉल्ट: "false"

कोई कार्रवाई नहीं. इसे पुराने सिस्टम के साथ काम करने की सुविधा के लिए यहां रखा गया है.

टैग: eagerness_to_exit, incompatible_change

--[no]one_version_enforcement_on_java_tests default: "true"

इसे चालू करने पर और experimental_one_version_enforcement को NONE के अलावा किसी अन्य वैल्यू पर सेट करने पर, java_test टारगेट पर एक वर्शन लागू करें. इस फ़्लैग को बंद किया जा सकता है. इससे इंक्रीमेंटल टेस्ट की परफ़ॉर्मेंस बेहतर होती है. हालांकि, इससे एक वर्शन के संभावित उल्लंघनों का पता नहीं चल पाता.

टैग: loading_and_analysis

--python_native_rules_allowlist=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

--incompatible_python_disallow_native_rules को लागू करते समय इस्तेमाल की जाने वाली अनुमति वाली सूची (package_group टारगेट).

टैग: loading_and_analysis

--[no]strict_filesets डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो पैकेज की सीमाओं को पार करने वाले फ़ाइलसेट को गड़बड़ियों के तौर पर रिपोर्ट किया जाता है.

टैग: build_file_semantics, eagerness_to_exit

--strict_proto_deps=<off, warn, error, strict or default> डिफ़ॉल्ट: "error"

अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, सीधे तौर पर इस्तेमाल किए गए सभी टारगेट को डिपेंडेंसी के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--strict_public_imports=<off, warn, error, strict or default> default: "off"

अगर यह विकल्प बंद नहीं है, तो यह जांच करता है कि proto_library टारगेट, 'import public' में इस्तेमाल किए गए सभी टारगेट को एक्सपोर्ट के तौर पर साफ़ तौर पर दिखाता है या नहीं.

टैग: build_file_semantics, eagerness_to_exit, incompatible_change

--[no]strict_system_includes डिफ़ॉल्ट: "false"

अगर यह विकल्प चालू है, तो सिस्टम में शामिल पाथ (-isystem) के ज़रिए मिले हेडर भी घोषित करने होंगे.

टैग: loading_and_analysis, eagerness_to_exit

--target_environment=<a build target label> कई बार इस्तेमाल किया गया हो

यह कुकी, इस बिल्ड के टारगेट एनवायरमेंट के बारे में बताती है. यह environment नियम का लेबल रेफ़रंस होना चाहिए. अगर यह तय किया गया है, तो सभी टॉप-लेवल टारगेट इस एनवायरमेंट के साथ काम करने चाहिए.

--platforms भी देखें.

टैग: 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 default: "true"

अगर यह वैल्यू सेट है और कंपाइलेशन मोड 'opt' नहीं है, तो objc ऐप्लिकेशन में साइन इन करते समय डीबग एनटाइटलमेंट शामिल होंगे.

टैग: changes_inputs

--ios_signing_cert_name=<a string> डिफ़ॉल्ट: ब्यौरा देखें

iOS पर हस्ताक्षर करने के लिए इस्तेमाल किए जाने वाले सर्टिफ़िकेट का नाम. इसे सेट न करने पर, प्रोविज़निंग प्रोफ़ाइल का इस्तेमाल किया जाएगा. यह सर्टिफ़िकेट की कीचेन आइडेंटिटी प्रेफ़रेंस या सर्टिफ़िकेट के कॉमन नेम का (सबस्ट्रिंग) हो सकता है. यह codesign के मैन पेज (SIGNING IDENTITIES) के मुताबिक होता है.

टैग: action_command_lines

इस विकल्प से, Starlark भाषा के सिमैंटिक या BUILD फ़ाइलों, .bzl फ़ाइलों या WORKSPACE फ़ाइलों के लिए उपलब्ध बिल्ड एपीआई पर असर पड़ता है.:

--[no]incompatible_disallow_sdk_frameworks_attributes डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में sdk_frameworks और weak_sdk_frameworks एट्रिब्यूट को अनुमति न दें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_objc_alwayslink_by_default डिफ़ॉल्ट: "false"

अगर सही है, तो objc_library और objc_import में alwayslink एट्रिब्यूट के लिए डिफ़ॉल्ट वैल्यू को सही पर सेट करें.

टैग: build_file_semantics, incompatible_change

--[no]incompatible_python_disallow_native_rules डिफ़ॉल्ट: "false"

जब यह सही होता है, तो बिल्ट-इन py_* नियमों का इस्तेमाल करने पर गड़बड़ी होती है. इसके बजाय, rule_python नियमों का इस्तेमाल किया जाना चाहिए. ज़्यादा जानकारी और माइग्रेशन के निर्देशों के लिए, https://github.com/bazelbuild/bazel/issues/17773 पर जाएं.

टैग: loading_and_analysis, incompatible_change

टेस्ट एनवायरमेंट या टेस्ट रनर के व्यवहार को कंट्रोल करने वाले विकल्प:

--[no]allow_analysis_failures डिफ़ॉल्ट: "false"

अगर यह वैल्यू 'सही' पर सेट है, तो नियम के टारगेट का विश्लेषण पूरा न होने पर, टारगेट के लिए AnalysisFailureInfo का एक इंस्टेंस जनरेट होगा. इसमें गड़बड़ी की जानकारी शामिल होगी. ऐसा, बिल्ड पूरा न होने की वजह से होगा.

टैग: loading_and_analysis, experimental

--analysis_testing_deps_limit=<an integer> डिफ़ॉल्ट: "2000"

यह for_analysis_testing कॉन्फ़िगरेशन ट्रांज़िशन के साथ, नियम एट्रिब्यूट के ज़रिए ट्रांज़िटिव डिपेंडेंसी की ज़्यादा से ज़्यादा संख्या सेट करता है. इस सीमा से ज़्यादा नियम बनाने पर, गड़बड़ी का मैसेज दिखेगा.

टैग: loading_and_analysis

--[no]break_build_on_parallel_dex2oat_failure डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो dex2oat की कार्रवाई पूरी न होने पर, टेस्ट रनटाइम के दौरान dex2oat को लागू करने के बजाय, बिल्ड रुक जाएगा.

टैग: loading_and_analysis, experimental

--default_test_resources=<a resource name followed by equal and 1 float or 4 float, e.g memory=10,30,60,100> कई बार इस्तेमाल किया गया हो

टेस्ट के लिए, संसाधनों की डिफ़ॉल्ट सीमा को बदलें. यह {resource}={value} फ़ॉर्मैट में होना चाहिए. अगर {value} के तौर पर कोई पॉज़िटिव नंबर दिया जाता है, तो यह सभी टेस्ट साइज़ के लिए डिफ़ॉल्ट संसाधनों को बदल देगा. अगर कॉमा लगाकर अलग किए गए चार नंबर दिए जाते हैं, तो वे small, medium, large, enormous के टेस्ट साइज़ के लिए संसाधन की रकम को बदल देंगे. वैल्यू HOST_RAM/HOST_CPU भी हो सकती हैं. इसके बाद, [-|*]{float} (उदाहरण के लिए, memory=HOST_RAM*.1,HOST_RAM*.2,HOST_RAM*.3,HOST_RAM*.4). इस फ़्लैग के ज़रिए तय किए गए डिफ़ॉल्ट टेस्ट संसाधनों को टैग में तय किए गए संसाधनों से बदल दिया जाता है.

--[no]experimental_android_use_parallel_dex2oat डिफ़ॉल्ट: "false"

android_test को तेज़ करने के लिए, dex2oat का इस्तेमाल करें.

टैग: loading_and_analysis, host_machine_resource_optimizations, experimental

--[no]ios_memleaks डिफ़ॉल्ट: "false"

ios_test टारगेट में मेमोरी लीक की जांच करने की सुविधा चालू करें.

टैग: action_command_lines

--ios_simulator_device=<a string> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर में iOS ऐप्लिकेशन चलाते समय, सिम्युलेट किए जाने वाले डिवाइस का नाम. जैसे, 'iPhone 6'. सिम्युलेटर को जिस मशीन पर चलाया जाएगा उस पर 'xcrun simctl list devicetypes' कमांड चलाकर, डिवाइसों की सूची पाई जा सकती है.

टैग: test_runner

--ios_simulator_version=<a dotted version (for example '2.3' or '3.3alpha2.4')> डिफ़ॉल्ट: ब्यौरा देखें

सिम्युलेटर पर चलाने या टेस्ट करने के दौरान, iOS का वर्शन. अगर नियम में कोई टारगेट डिवाइस तय किया गया है, तो ios_test नियमों के लिए इसे अनदेखा कर दिया जाता है.

टैग: test_runner

--runs_per_test=<a positive integer or test_regex@runs. This flag may be passed more than once> कई बार इस्तेमाल किया गया हो

इससे यह तय किया जाता है कि हर टेस्ट को कितनी बार चलाना है. अगर किसी भी वजह से, इनमें से कोई भी कोशिश पूरी नहीं हो पाती है, तो पूरे टेस्ट को फ़ेल माना जाता है. आम तौर पर, दी गई वैल्यू सिर्फ़ एक पूर्णांक होती है.

उदाहरण: --runs_per_test=3 से सभी टेस्ट तीन बार चलेंगे.

वैकल्पिक सिंटैक्स: regex_filter@runs_per_test. यहां runs_per_test का मतलब पूर्णांक वैल्यू और regex_filter का मतलब, शामिल और बाहर रखे गए रेगुलर एक्सप्रेशन पैटर्न की सूची से है. --instrumentation_filter भी देखें.

उदाहरण: --runs_per_test=//foo/.*,-//foo/bar/.*@3, //foo/ में मौजूद सभी टेस्ट चलाता है. हालांकि, //foo/bar में मौजूद टेस्ट को तीन बार चलाता है. इस विकल्प को कई बार पास किया जा सकता है. सबसे हाल ही में पास किए गए उस आर्ग्युमेंट को प्राथमिकता दी जाती है जो मैच करता है. अगर कोई भी मैच नहीं होता है, तो टेस्ट सिर्फ़ एक बार चलाया जाता है.

--test_env=<a 'name[=value]' assignment with an optional value part or the special syntax '=name' to unset a variable> कई बार इस्तेमाल किया गया हो

यह विकल्प, टेस्ट रनर एनवायरमेंट में इंजेक्ट किए जाने वाले अतिरिक्त एनवायरमेंट वैरिएबल के बारे में बताता है. वैरिएबल को name या name=value पेयर के ज़रिए तय किया जा सकता है. अगर name के ज़रिए वैरिएबल तय किया जाता है, तो उसकी वैल्यू Bazel क्लाइंट एनवायरमेंट से पढ़ी जाएगी. पहले से सेट किए गए वैरिएबल को =name की मदद से अनसेट किया जा सकता है. इस विकल्प का इस्तेमाल कई बार किया जा सकता है, ताकि कई वैरिएबल तय किए जा सकें. इसका इस्तेमाल सिर्फ़ 'bazel test' कमांड करती है.

टैग: test_runner

--test_timeout=<a single integer or comma-separated list of 4 integers> default: "-1"

जांच के टाइम आउट के लिए, जांच के टाइम आउट की डिफ़ॉल्ट वैल्यू (सेकंड में) बदलें. अगर कोई एक पॉज़िटिव पूर्णांक वैल्यू दी जाती है, तो यह सभी कैटगरी को बदल देगी. अगर कॉमा लगाकर अलग किए गए चार पूर्णांक दिए जाते हैं, तो वे short, moderate, long, और eternal के लिए टाइम आउट को बदल देंगे. दोनों फ़ॉर्म में, -1 की वैल्यू से Blaze को यह पता चलता है कि उसे उस कैटगरी के लिए डिफ़ॉल्ट टाइमआउट का इस्तेमाल करना है.

--[no]zip_undeclared_test_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प सही पर सेट है, तो टेस्ट के ऐसे आउटपुट को zip फ़ाइल में संग्रहित किया जाएगा जिनके बारे में जानकारी नहीं दी गई है.

टैग: test_runner

बिल्ड टाइम को ऑप्टिमाइज़ करने वाले विकल्प:

--[no]cc_dotd_files default: "true"

.d फ़ाइलों को जनरेट और उनका विश्लेषण करना है या नहीं.

टैग: loading_and_analysis, execution, changes_inputs

--[no]cc_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]experimental_filter_library_jar_with_program_jar डिफ़ॉल्ट: "false"

ProGuard ProgramJar को फ़िल्टर करें, ताकि LibraryJar में मौजूद सभी क्लास हट जाएं.

टैग: action_command_lines, experimental

--[no]experimental_inmemory_dotd_files default: "true"

अगर यह विकल्प चालू है, तो C++ .d फ़ाइलों को डिस्क पर लिखने के बजाय, रिमोट बिल्ड नोड से सीधे मेमोरी में पास किया जाएगा.

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_inmemory_jdeps_files default: "true"

अगर यह सुविधा चालू है, तो Java कंपाइलेशन से जनरेट हुई डिपेंडेंसी (.jdeps) फ़ाइलों को डिस्क में सेव करने के बजाय, सीधे रिमोट बिल्ड नोड से मेमोरी में पास किया जाएगा.

टैग: loading_and_analysis, execution, affects_outputs, experimental

--[no]experimental_retain_test_configuration_across_testonly default: "true"

इस नीति के चालू होने पर, --trim_test_configuration उन नियमों के लिए टेस्ट कॉन्फ़िगरेशन को नहीं काटेगा जिन्हें testonly=1 के तौर पर मार्क किया गया है. इसका मकसद, कार्रवाई से जुड़ी उन समस्याओं को कम करना है जो तब होती हैं, जब टेस्ट के अलावा अन्य नियम, cc_test नियमों पर निर्भर होते हैं. अगर --trim_test_configuration की वैल्यू false है, तो इसका कोई असर नहीं होगा.

टैग: loading_and_analysis, loses_incremental_state, experimental

--[no]experimental_unsupported_and_brittle_include_scanning डिफ़ॉल्ट: "false"

क्या इनपुट फ़ाइलों से #include लाइनें पार्स करके, C/C++ कंपाइलेशन के लिए इनपुट को कम करना है. इससे कंपाइलेशन इनपुट ट्री का साइज़ कम करके, परफ़ॉर्मेंस और इंक्रीमेंटैलिटी को बेहतर बनाया जा सकता है. हालांकि, इससे बिल्ड भी टूट सकते हैं, क्योंकि include स्कैनर, C प्रीप्रोसेसर सिमैंटिक्स को पूरी तरह से लागू नहीं करता है. खास तौर पर, यह डाइनैमिक #include डायरेक्टिव को नहीं समझता और प्रीप्रोसेसर की शर्त वाली लॉजिक को अनदेखा करता है. इसे अपने जोखिम पर इस्तेमाल करें. इस फ़्लैग से जुड़ी किसी भी समस्या को बंद कर दिया जाएगा. इस फ़्लैग के बिना, Google पर आपकी बिल्ड फ़ेल हो जाएगी.

टैग: loading_and_analysis, execution, changes_inputs, experimental

--[no]incremental_dexing default: "true"

यह हर जार फ़ाइल के लिए, अलग-अलग डेक्सिंग का ज़्यादातर काम करता है.

टैग: affects_outputs, loading_and_analysis, loses_incremental_state

--[no]objc_use_dotd_pruning default: "true"

अगर इसे सेट किया जाता है, तो clang से जनरेट हुई .d फ़ाइलों का इस्तेमाल, objc कंपाइल में पास किए गए इनपुट के सेट को कम करने के लिए किया जाएगा.

टैग: changes_inputs, loading_and_analysis

--[no]process_headers_in_dependencies डिफ़ॉल्ट: "false"

//a:a टारगेट बनाते समय, उन सभी टारगेट में हेडर प्रोसेस करें जिन पर //a:a निर्भर करता है. ऐसा तब करें, जब टूलचेन के लिए हेडर प्रोसेसिंग चालू हो.

टैग: execution

--[no]trim_test_configuration default: "true"

यह सुविधा चालू करने पर, टेस्ट से जुड़े विकल्प, बिल्ड के टॉप लेवल के नीचे से हट जाएंगे. इस फ़्लैग के चालू होने पर, टेस्ट को नॉन-टेस्ट नियमों की डिपेंडेंसी के तौर पर नहीं बनाया जा सकता. हालांकि, टेस्ट से जुड़े विकल्पों में बदलाव करने से, नॉन-टेस्ट नियमों का फिर से विश्लेषण नहीं किया जाएगा.

टैग: loading_and_analysis, loses_incremental_state

लॉगिंग की जानकारी, फ़ॉर्मैट या जगह पर असर डालने वाले विकल्प:

--toolchain_resolution_debug=<a comma-separated list of regex expressions with prefix '-' specifying excluded paths> default: "-.*"

टूलचेन रिज़ॉल्यूशन के दौरान डीबग की जानकारी प्रिंट करें. इस फ़्लैग में एक रेगुलर एक्सप्रेशन होता है. इसकी जांच टूलचेन टाइप और खास टारगेट के हिसाब से की जाती है, ताकि यह पता चल सके कि किसे डीबग करना है. एक से ज़्यादा रेगुलर एक्सप्रेशन को कॉमा लगाकर अलग किया जा सकता है. इसके बाद, हर रेगुलर एक्सप्रेशन की अलग-अलग जांच की जाती है. ध्यान दें: इस फ़्लैग का आउटपुट बहुत जटिल होता है. इसलिए, यह सिर्फ़ टूलचेन की समस्या हल करने वाले विशेषज्ञों के लिए काम का हो सकता है.

टैग: terminal_output

--[no]verbose_visibility_errors डिफ़ॉल्ट: "false"

अगर यह सुविधा चालू है, तो दिखने से जुड़ी गड़बड़ियों में गड़बड़ी की अतिरिक्त जानकारी शामिल होती है.

टैग: build_file_semantics, non_configurable

Bazel कमांड के लिए सामान्य इनपुट तय करने या उसमें बदलाव करने वाले विकल्प. ये विकल्प, अन्य कैटगरी में नहीं आते.:

--flag_alias=<a 'name=label' flag alias> कई बार इस्तेमाल किया गया हो

यह Starlark फ़्लैग के लिए छोटा नाम सेट करता है. यह {key}={value} के फ़ॉर्म में एक की-वैल्यू पेयर को आर्ग्युमेंट के तौर पर लेता है.

टैग: changes_inputs, non_configurable

--[no]incompatible_default_to_explicit_init_py डिफ़ॉल्ट: "false"

इस फ़्लैग से डिफ़ॉल्ट व्यवहार बदल जाता है, ताकि Python टारगेट की रनफ़ाइल में init.py फ़ाइलें अपने-आप न बन पाएं. जब किसी py_binary या py_test टारगेट के लिए legacy_create_init को "auto" (डिफ़ॉल्ट) पर सेट किया जाता है, तब इस फ़्लैग को सेट करने पर ही इसे फ़ॉल्स के तौर पर माना जाता है. ज़्यादा जानकारी के लिए, https://github.com/bazelbuild/bazel/issues/10076 पर जाएं.

टैग: affects_outputs, incompatible_change

अन्य विकल्प, जिन्हें किसी और कैटगरी में नहीं रखा गया है.:

--[no]cache_test_results [-t] default: "auto"

अगर इसे auto पर सेट किया जाता है, तो Bazel किसी टेस्ट को सिर्फ़ तब फिर से चलाता है, जब:

1. Bazel, टेस्ट या उसकी डिपेंडेंसी में हुए बदलावों का पता लगाता है,
2. टेस्ट को external के तौर पर मार्क किया गया हो,
3. --runs_per_test के साथ कई टेस्ट रन का अनुरोध किया गया हो या
4. यह जांच पहले पूरी नहीं हो सकी थी. अगर इसे yes पर सेट किया जाता है, तो Bazel उन सभी टेस्ट के नतीजों को कैश मेमोरी में सेव करता है जिन्हें external के तौर पर मार्क नहीं किया गया है. अगर इसे no पर सेट किया जाता है, तो Bazel किसी भी टेस्ट के नतीजे को कैश मेमोरी में सेव नहीं करता.

--[no]experimental_cancel_concurrent_tests default: "never"

अगर on_failed या on_passed, तो Blaze उस नतीजे के साथ पहली बार सफल होने पर, एक साथ चल रहे टेस्ट रद्द कर देगा. यह नीति सिर्फ़ --runs_per_test_detects_flakes के साथ काम करेगी.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_fetch_all_coverage_outputs डिफ़ॉल्ट: "false"

अगर यह विकल्प सही है, तो कवरेज रन के दौरान Bazel, हर टेस्ट के लिए कवरेज डेटा डायरेक्ट्री को फ़ेच करता है.

टैग: affects_outputs, loading_and_analysis, experimental

--[no]experimental_generate_llvm_lcov डिफ़ॉल्ट: "false"

अगर यह विकल्प 'सही है' पर सेट है, तो क्लैंग के लिए कवरेज, LCOV रिपोर्ट जनरेट करेगा.

टैग: affects_outputs, loading_and_analysis, experimental

--experimental_java_classpath=<off, javabuilder, bazel or bazel_no_fallback> default: "bazel"

यह Java कंपाइलेशन के लिए, कम किए गए क्लासपाथ को चालू करता है.

--[no]experimental_run_android_lint_on_java_rules डिफ़ॉल्ट: "false"

java_* सोर्स की पुष्टि करनी है या नहीं.

टैग: affects_outputs, experimental

--[no]explicit_java_test_deps डिफ़ॉल्ट: "false"

java_test में, TestRunner के deps से गलती से पाने के बजाय, JUnit या Hamcrest के लिए साफ़ तौर पर डिपेंडेंसी तय करें. फ़िलहाल, यह सिर्फ़ Bazel के लिए काम करता है.

--host_java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह Java लॉन्चर है. इसका इस्तेमाल उन टूल के लिए किया जाता है जिन्हें बिल्ड के दौरान एक्ज़ीक्यूट किया जाता है.

--host_javacopt=<a string> कई बार इस्तेमाल किया गया हो

बिल्ड के दौरान लागू होने वाले टूल बनाते समय, javac को पास किए जाने वाले अतिरिक्त विकल्प.

--host_jvmopt=<a string> कई बार इस्तेमाल किया गया हो

बिल्ड के दौरान एक्ज़ीक्यूट किए जाने वाले टूल बनाते समय, Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--[no]incompatible_check_sharding_support default: "true"

अगर यह विकल्प सही है, तो Bazel, शार्ड किए गए टेस्ट को फ़ेल कर देगा. ऐसा तब होगा, जब टेस्ट रनर यह नहीं बताता कि वह TEST_SHARD_STATUS_FILE में दिए गए पाथ पर फ़ाइल को ऐक्सेस करके, शार्डिंग की सुविधा के साथ काम करता है. अगर यह वैल्यू गलत है, तो शार्डिंग की सुविधा के साथ काम न करने वाला टेस्ट रनर, सभी टेस्ट को हर शार्ड में चलाएगा.

टैग: incompatible_change

--[no]incompatible_exclusive_test_sandboxed default: "true"

अगर यह विकल्प चुना जाता है, तो खास टेस्ट, सैंडबॉक्स की गई रणनीति के साथ चलेंगे. local टैग जोड़कर, लोकल लेवल पर सिर्फ़ एक टेस्ट रन करें

टैग: incompatible_change

--[no]incompatible_strict_action_env default: "true"

अगर यह सही है, तो Bazel, PATH के लिए स्टैटिक वैल्यू वाले एनवायरमेंट का इस्तेमाल करता है. साथ ही, LD_LIBRARY_PATH को इनहेरिट नहीं करता है. अगर आपको क्लाइंट से कुछ खास एनवायरमेंट वैरिएबल इनहेरिट करने हैं, तो --action_env=ENV_VARIABLE का इस्तेमाल करें. हालांकि, ध्यान दें कि शेयर की गई कैश मेमोरी का इस्तेमाल करने पर, ऐसा करने से अलग-अलग उपयोगकर्ताओं के लिए कैश मेमोरी का इस्तेमाल नहीं किया जा सकेगा.

टैग: loading_and_analysis, incompatible_change

--j2objc_translation_flags=<comma-separated list of options> कई बार इस्तेमाल किया गया हो

J2ObjC टूल को पास करने के लिए अतिरिक्त विकल्प.

--java_debug

इस विकल्प का इस्तेमाल करने पर, Java टेस्ट की Java वर्चुअल मशीन, JDWP के साथ काम करने वाले डीबगर (जैसे कि jdb) से कनेक्शन मिलने का इंतज़ार करती है. इसके बाद ही, टेस्ट शुरू होता है. इसका मतलब है कि -test_output=streamed.

बढ़कर:
  --test_arg=--wrapper_script_flag=--debug
  --test_output=streamed
  --test_strategy=exclusive
  --test_timeout=9999
  --nocache_test_results

--[no]java_deps default: "true"

हर Java टारगेट के लिए, डिपेंडेंसी की जानकारी जनरेट करता है. फ़िलहाल, यह कंपाइल-टाइम क्लासपाथ के लिए है.

--[no]java_header_compilation default: "true"

सीधे सोर्स से ijars कंपाइल करें.

--java_language_version=<a string> default: ""

Java भाषा का वर्शन

--java_launcher=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

Java बाइनरी बनाते समय इस्तेमाल किया जाने वाला Java लॉन्चर. अगर इस फ़्लैग को खाली स्ट्रिंग पर सेट किया जाता है, तो JDK लॉन्चर का इस्तेमाल किया जाता है. "launcher" एट्रिब्यूट इस फ़्लैग को बदल देता है.

--java_runtime_version=<a string> default: "local_jdk"

Java रनटाइम का वर्शन

--javacopt=<a string> कई बार इस्तेमाल किया गया हो

javac को पास करने के लिए अन्य विकल्प.

--jvmopt=<a string> कई बार इस्तेमाल किया गया हो

Java VM को पास करने के लिए अतिरिक्त विकल्प. ये विकल्प, हर java_binary टारगेट के वीएम स्टार्टअप विकल्पों में जोड़ दिए जाएंगे.

--legacy_main_dex_list_generator=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह एक बाइनरी तय करता है, जिसका इस्तेमाल उन क्लास की सूची जनरेट करने के लिए किया जाता है जिन्हें लेगसी मल्टीडेक्स को कंपाइल करते समय, मुख्य डेक्स में होना चाहिए.

--optimizing_dexer=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह बिना शार्डिंग के डेक्सिंग करने के लिए, इस्तेमाल किया जाने वाला बाइनरी तय करता है.

--plugin=<a build target label> कई बार इस्तेमाल किया गया हो

बिल्ड में इस्तेमाल किए जाने वाले प्लगिन. फ़िलहाल, यह java_plugin के साथ काम करता है.

--proguard_top=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

इससे यह तय किया जाता है कि Java बाइनरी बनाते समय, कोड हटाने के लिए ProGuard के किस वर्शन का इस्तेमाल किया जाए.

--proto_compiler=<a build target label> default: "@bazel_tools//tools/proto:protoc"

प्रोटो-कंपाइलर का लेबल.

टैग: affects_outputs, loading_and_analysis

--[no]proto_profile default: "true"

प्रोटो कंपाइलर को profile_path पास करना है या नहीं.

टैग: affects_outputs, loading_and_analysis

--proto_profile_path=<a build target label> डिफ़ॉल्ट: ब्यौरा देखें

यह प्रोफ़ाइल, proto कंपाइलर को profile_path के तौर पर पास की जाती है. अगर इसे सेट नहीं किया गया है, लेकिन --proto_profile सही है (डिफ़ॉल्ट रूप से), तो --fdo_optimize से पाथ का अनुमान लगाता है.

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_cc=<a build target label> default: "@bazel_tools//tools/proto:cc_toolchain"

proto_lang_toolchain() का लेबल, जिसमें C++ प्रोटो को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_j2objc=<a build target label> default: "@bazel_tools//tools/j2objc:j2objc_proto_toolchain"

proto_lang_toolchain() का लेबल, जिसमें j2objc प्रोटो को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_java=<a build target label> default: "@bazel_tools//tools/proto:java_toolchain"

proto_lang_toolchain() का लेबल, जिसमें Java protos को कंपाइल करने के तरीके के बारे में बताया गया है

टैग: affects_outputs, loading_and_analysis

--proto_toolchain_for_javalite=<a build target label> default: "@bazel_tools//tools/proto:javalite_toolchain"

proto_lang_toolchain() का लेबल, जिसमें JavaLite protos को कंपाइल करने का तरीका बताया गया है

टैग: affects_outputs, loading_and_analysis

--protocopt=<a string> कई बार इस्तेमाल किया गया हो

प्रोटोबफ़ कंपाइलर को पास करने के लिए अतिरिक्त विकल्प.

टैग: affects_outputs

--[no]runs_per_test_detects_flakes डिफ़ॉल्ट: "false"

अगर यह विकल्प चुना जाता है, तो जिस भी शार्ड में कम से कम एक रन/कोशिश पास होती है और कम से कम एक रन/कोशिश फ़ेल होती है उसे FLAKY स्टेटस मिलता है.

--shell_executable=<a path> डिफ़ॉल्ट: ब्यौरा देखें

Bazel के इस्तेमाल के लिए, शेल एक्ज़ीक्यूटेबल का पूरा पाथ. अगर इसे सेट नहीं किया गया है, लेकिन BAZEL_SH एनवायरमेंट वैरिएबल को Bazel के पहले इनवोकेशन पर सेट किया गया है (जो Bazel सर्वर शुरू करता है), तो Bazel इसका इस्तेमाल करता है. अगर दोनों में से कोई भी सेट नहीं है, तो Bazel, ऑपरेटिंग सिस्टम के हिसाब से हार्ड-कोड किए गए डिफ़ॉल्ट पाथ का इस्तेमाल करता है;

• Windows: c:/msys64/usr/bin/bash.exe
• FreeBSD: /usr/local/bin/bash
• अन्य सभी: /bin/bash.

ध्यान दें कि bash के साथ काम न करने वाले शेल का इस्तेमाल करने से, जनरेट की गई बाइनरी के बिल्ड या रनटाइम में समस्याएं आ सकती हैं.

टैग: loading_and_analysis

--test_arg=<a string> कई बार इस्तेमाल किया गया हो

इस विकल्प की मदद से, टेस्ट एक्ज़ीक्यूटेबल को पास किए जाने वाले अतिरिक्त विकल्पों और आर्ग्युमेंट के बारे में बताया जाता है. कई आर्ग्युमेंट तय करने के लिए, इसका इस्तेमाल कई बार किया जा सकता है. अगर एक से ज़्यादा टेस्ट किए जाते हैं, तो हर टेस्ट को एक जैसे आर्ग्युमेंट मिलेंगे. इसका इस्तेमाल सिर्फ़ bazel test कमांड के लिए किया जाता है.

--test_filter=<a string> डिफ़ॉल्ट: ब्यौरा देखें

टेस्ट फ़्रेमवर्क को फ़ॉरवर्ड करने के लिए फ़िल्टर तय करता है. इस कुकी का इस्तेमाल, टेस्ट को सीमित करने के लिए किया जाता है. ध्यान दें कि इससे इस बात पर कोई असर नहीं पड़ता कि कौनसे टारगेट बनाए गए हैं.

--test_result_expiration=<an integer> default: "-1"

इस विकल्प को बंद कर दिया गया है और इससे कोई असर नहीं पड़ता.

--[no]test_runner_fail_fast डिफ़ॉल्ट: "false"

यह विकल्प, टेस्ट रनर को तुरंत फ़ॉरवर्ड करता है. टेस्ट रनर को पहली गड़बड़ी होने पर ही बंद हो जाना चाहिए.

--test_sharding_strategy=<explicit, disabled or forced=k where k is the number of shards to enforce> default: "explicit"

टेस्ट शार्डिंग के लिए रणनीति तय करें:

• explicit का इस्तेमाल सिर्फ़ तब करें, जब shard_count BUILD एट्रिब्यूट मौजूद हो.
• disabled का इस्तेमाल करके, टेस्ट शार्डिंग को कभी भी इस्तेमाल न करें.
• forced=k का इस्तेमाल करके, shard_count BUILD एट्रिब्यूट की परवाह किए बिना, टेस्टिंग के लिए k शार्ड लागू करें.

--tool_java_language_version=<a string> default: ""

बिल्ड के दौरान ज़रूरी टूल को चलाने के लिए इस्तेमाल किया गया Java भाषा का वर्शन

--tool_java_runtime_version=<a string> default: "remotejdk_11"

बिल्ड के दौरान टूल को एक्ज़ीक्यूट करने के लिए इस्तेमाल किया गया Java रनटाइम वर्शन

--[no]use_ijars default: "true"

अगर यह विकल्प चालू है, तो Java कंपाइलेशन के लिए इंटरफ़ेस जार का इस्तेमाल किया जाता है. इससे इंक्रीमेंटल कंपाइलेशन तेज़ी से होगा, लेकिन गड़बड़ी के मैसेज अलग-अलग हो सकते हैं.

वर्शन के विकल्प

ऐसे विकल्प जिनसे उपयोगकर्ता, आउटपुट को कॉन्फ़िगर कर सकता है. इससे आउटपुट की वैल्यू पर असर पड़ता है, न कि उसके मौजूद होने पर:

--[no]gnu_format डिफ़ॉल्ट: "false"

अगर सेट है, तो GNU के मानकों में बताए गए नियमों का इस्तेमाल करके, stdout पर वर्शन लिखें.

टैग: affects_outputs, execution

विकल्प के असर वाले टैग

unknown	इस विकल्प का असर क्या होगा, इसकी जानकारी नहीं है या इसके बारे में दस्तावेज़ में नहीं बताया गया है.
no_op	इस विकल्प से कोई असर नहीं पड़ता.
loses_incremental_state	इस विकल्प की वैल्यू बदलने से, इंक्रीमेंटल स्टेट में काफ़ी नुकसान हो सकता है. इससे बिल्ड की प्रोसेस धीमी हो जाती है. सर्वर के रीस्टार्ट होने या डिपेंडेंसी ग्राफ़ के बड़े हिस्से के अमान्य होने की वजह से, स्थिति बदल सकती है.
changes_inputs	यह विकल्प, उन इनपुट को तुरंत बदल देता है जिन्हें Bazel, बिल्ड के लिए इस्तेमाल करता है. जैसे, फ़ाइल सिस्टम से जुड़ी पाबंदियां, रिपॉज़िटरी के वर्शन या अन्य विकल्प.
affects_outputs	इस विकल्प से Bazel के आउटपुट पर असर पड़ता है. यह टैग जान-बूझकर ब्रॉड रखा गया है. इसमें ट्रांज़िटिव इफ़ेक्ट शामिल हो सकते हैं. साथ ही, यह नहीं बताता कि इससे किस तरह के आउटपुट पर असर पड़ता है.
build_file_semantics	इस विकल्प से BUILD या .bzl फ़ाइलों के सिमैंटिक पर असर पड़ता है.
bazel_internal_configuration	इस विकल्प से, Bazel के इंटरनल सिस्टम की सेटिंग पर असर पड़ता है. इस टैग का मतलब यह नहीं है कि बिल्ड आर्टफ़ैक्ट पर असर पड़ा है.
loading_and_analysis	इस विकल्प से, डिपेंडेंसी लोड करने और उनका विश्लेषण करने के साथ-साथ डिपेंडेंसी ग्राफ़ बनाने पर असर पड़ता है.
execution	इस विकल्प से, एक्ज़ीक्यूशन फ़ेज़ पर असर पड़ता है. जैसे, सैंडबॉक्सिंग या रिमोट एक्ज़ीक्यूशन से जुड़े विकल्प.
host_machine_resource_optimizations	इस विकल्प से एक ऑप्टिमाइज़ेशन ट्रिगर होता है. यह मशीन के हिसाब से अलग-अलग हो सकता है. साथ ही, यह ज़रूरी नहीं है कि यह सभी मशीनों पर काम करे. ऑप्टिमाइज़ेशन में, परफ़ॉर्मेंस के अन्य पहलुओं के साथ समझौता करना पड़ सकता है. जैसे, मेमोरी या सीपीयू की लागत.
eagerness_to_exit	इस विकल्प से यह तय होता है कि Bazel किसी गड़बड़ी के बाद कितनी जल्दी बंद हो जाएगा. इसमें यह विकल्प होता है कि गड़बड़ी के बावजूद काम जारी रखा जाए या इनवॉकेशन को खत्म कर दिया जाए.
bazel_monitoring	इस विकल्प का इस्तेमाल, Bazel के काम करने के तरीके और परफ़ॉर्मेंस पर नज़र रखने के लिए किया जाता है.
terminal_output	इस विकल्प से, Bazel के टर्मिनल आउटपुट पर असर पड़ता है.
action_command_lines	इस विकल्प से, एक या उससे ज़्यादा बिल्ड ऐक्शन के कमांड लाइन आर्ग्युमेंट बदल जाते हैं.
test_runner	इस विकल्प से, बिल्ड के टेस्ट रनर एनवायरमेंट में बदलाव होता है.

विकल्प के मेटाडेटा टैग

experimental	इस विकल्प से, एक्सपेरिमेंट के तौर पर उपलब्ध सुविधा चालू हो जाती है. हालांकि, इस सुविधा के काम करने की कोई गारंटी नहीं है.
incompatible_change	इस विकल्प से, एपीआई में ऐसा बदलाव होता है जो पहले से मौजूद फ़ंक्शन को तोड़ देता है. इस विकल्प का इस्तेमाल करके, यह जांच करें कि माइग्रेशन के लिए आपका सेटअप तैयार है या नहीं. इसके अलावा, नई सुविधा का ऐक्सेस पहले ही पाएं
deprecated	यह विकल्प अब उपलब्ध नहीं है. ऐसा हो सकता है कि जिस सुविधा पर इसका असर पड़ता है वह बंद हो गई हो या जानकारी देने के किसी दूसरे तरीके को प्राथमिकता दी जा रही हो.
non_configurable	इस विकल्प को ट्रांज़िशन में नहीं बदला जा सकता. साथ ही, इसका इस्तेमाल select() स्टेटमेंट में नहीं किया जा सकता.