bazelrc कॉन्फ़िगरेशन फ़ाइलें लिखें

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

Basel के कई विकल्प स्वीकार किए जाते हैं. कुछ विकल्पों में अक्सर बदलाव होता है (उदाहरण के लिए, --subcommands), जबकि अन्य विकल्प कई बिल्ड में एक जैसे रहते हैं (जैसे, --package_path). हर बिल्ड (और अन्य निर्देशों) के लिए, इन विकल्पों को बताने से बचने के लिए, .bazelrc नाम की कॉन्फ़िगरेशन फ़ाइल में विकल्पों की जानकारी दी जा सकती है.

.bazelrc फ़ाइलें कहां हैं?

Bazel, वैकल्पिक कॉन्फ़िगरेशन फ़ाइलों को यहां दी गई जगहों पर ढूंढता है. साथ ही, उन्हें यहां दिए गए क्रम में ढूंढता है. विकल्पों को इस क्रम में समझा जाता है, ताकि किसी विवाद की स्थिति में, बाद की फ़ाइलों के विकल्प, पिछली फ़ाइल की वैल्यू को बदल सकें. इनमें से किन फ़ाइलों को लोड किया जाए, यह कंट्रोल करने वाले सभी विकल्प, स्टार्टअप विकल्प हैं. इसका मतलब है कि ये bazel के बाद और निर्देश (build, test वगैरह) से पहले होने चाहिए.

1. सिस्टम की आरसी फ़ाइल, बशर्ते --nosystem_rc मौजूद न हो.

   पाथ:

   • Linux/macOS/Unix पर: /etc/bazel.bazelrc
   • Windows पर: %ProgramData%\bazel.bazelrc

   अगर इस फ़ाइल के मौजूद नहीं हैं, तो यह कोई गड़बड़ी नहीं होगी.

   अगर आपको सिस्टम की बताई गई किसी अन्य जगह की ज़रूरत है, तो आपको //src/main/cpp:option_processor में BAZEL_SYSTEM_BAZELRC_PATH वैल्यू को बदलकर, कस्टम Bazel बाइनरी बनानी होगी. सिस्टम की तय की गई जगह में, एनवायरमेंट वैरिएबल के रेफ़रंस हो सकते हैं. जैसे, Unix पर ${VAR_NAME} या Windows पर %VAR_NAME%.

2. फ़ाइल फ़ोल्डर की आरसी फ़ाइल, बशर्ते --noworkspace_rc मौजूद न हो.

   पाथ: आपकी फ़ाइल फ़ोल्डर डायरेक्ट्री में .bazelrc (मुख्य MODULE.bazel फ़ाइल के बगल में).

   अगर इस फ़ाइल के मौजूद नहीं हैं, तो यह कोई गड़बड़ी नहीं होगी.

3. होम की आरसी फ़ाइल, बशर्ते --nohome_rc मौजूद न हो.

   पाथ:

   • Linux/macOS/Unix पर: $HOME/.bazelrc
   • Windows पर: %USERPROFILE%\.bazelrc अगर मौजूद है या %HOME%/.bazelrc

   अगर इस फ़ाइल के मौजूद नहीं हैं, तो यह कोई गड़बड़ी नहीं होगी.

4. उपयोगकर्ता की बताई गई आरसी फ़ाइल, अगर --bazelrc=file के साथ बताई गई हो

   यह फ़्लैग वैकल्पिक है, लेकिन इसे एक से ज़्यादा बार भी तय किया जा सकता है.

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

   उदाहरण के लिए:

   --bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc
   

   • x.rc और y.rc पढ़े जाते हैं.
   • पहले से मौजूद /dev/null की वजह से, z.rc को अनदेखा किया जाता है.

इस वैकल्पिक कॉन्फ़िगरेशन फ़ाइल के अलावा, Baज़र, ग्लोबल rc फ़ाइल की तलाश में है. ज़्यादा जानकारी के लिए, global bazelrc सेक्शन देखें.

.bazelrc सिंटैक्स और सिमेंटिक्स

सभी UNIX "rc" फ़ाइलों की तरह, .bazelrc फ़ाइल भी एक टेक्स्ट फ़ाइल है. इसमें लाइन पर आधारित ग्रामर का इस्तेमाल किया जाता है. खाली लाइनों और # (टिप्पणियों) से शुरू होने वाली लाइनों को अनदेखा किया जाता है. हर लाइन में शब्दों का एक क्रम होता है. इन्हें बॉर्न शेल के नियमों के हिसाब से टोकन किया जाता है.

आयात

import या try-import से शुरू होने वाली लाइनें खास होती हैं: इनका इस्तेमाल, अन्य "rc" फ़ाइलों को लोड करने के लिए करें. वर्कस्पेस के रूट से जुड़ा पाथ तय करने के लिए, import %workspace%/path/to/bazelrc लिखें.

import और try-import के बीच अंतर यह है कि import की फ़ाइल मौजूद न होने (या उसे पढ़ा नहीं जा सकता) होने पर Basel काम नहीं करता है. हालांकि, try-import'ed फ़ाइल के लिए ऐसा नहीं होता है.

इंपोर्ट के लिए प्राथमिकता:

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

विकल्प डिफ़ॉल्ट

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

• startup: स्टार्टअप के विकल्प, जो कमांड से पहले आते हैं और जिनके बारे में bazel help startup_options में बताया गया है.
• common: ऐसे विकल्प जिन्हें उन सभी Bazel निर्देशों पर लागू किया जाना चाहिए जिनमें ये काम करते हैं. अगर कोई कमांड इस तरह से बताए गए विकल्प के साथ काम नहीं करता है, तो विकल्प को तब तक अनदेखा कर दिया जाता है, जब तक कि वह किसी अन्य Bazel कमांड के लिए मान्य है. ध्यान दें कि यह सिर्फ़ विकल्प के नाम पर लागू होता है: अगर मौजूदा निर्देश, तय किए गए नाम वाले विकल्प को स्वीकार करता है, लेकिन तय की गई वैल्यू के साथ काम नहीं करता, तो यह निर्देश काम नहीं करेगा.
• always: ऐसे विकल्प जो Basel के सभी कमांड पर लागू होते हैं. अगर कोई निर्देश इस तरीके से दिए गए विकल्प के साथ काम नहीं करता है, तो वह काम नहीं करेगा.
• command: Basel कमांड, जैसे कि build या query, जिस पर ये विकल्प लागू होते हैं. ये विकल्प उन सभी निर्देशों पर भी लागू होते हैं जो बताए गए कमांड से इनहेरिट किए जाते हैं. (उदाहरण के लिए, test, build से इनहेरिट करता है.)

इनमें से हर लाइन का इस्तेमाल एक से ज़्यादा बार किया जा सकता है. साथ ही, पहले शब्द के बाद मौजूद आर्ग्युमेंट को इस तरह जोड़ा जाता है जैसे कि वे एक ही लाइन में मौजूद हों. (सीवीएस के उपयोगकर्ताओं को "स्विस आर्मी चाकू" कमांड-लाइन इंटरफ़ेस वाला एक अन्य टूल मिलेगा. उन्हें .cvsrc के जैसा ही सिंटैक्स मिलेगा. उदाहरण के लिए, लाइनें:

build --test_tmpdir=/tmp/foo --verbose_failures
build --test_tmpdir=/tmp/bar

इन्हें इस तरह जोड़ा जाता है:

build --test_tmpdir=/tmp/foo --verbose_failures --test_tmpdir=/tmp/bar

इसलिए, असरदार फ़्लैग --verbose_failures और --test_tmpdir=/tmp/bar हैं.

विकल्प की प्राथमिकता:

• कमांड लाइन के विकल्पों को, rc फ़ाइलों में मौजूद विकल्पों के मुकाबले हमेशा प्राथमिकता दी जाती है. उदाहरण के लिए, अगर किसी rc फ़ाइल में build -c opt है, लेकिन कमांड लाइन फ़्लैग -c dbg है, तो कमांड लाइन फ़्लैग को प्राथमिकता दी जाती है.

• rc फ़ाइल में, प्राथमिकता तय करने के लिए यह देखा जाता है कि कमांड कितना सटीक है: ज़्यादा सटीक कमांड की लाइनें, कम सटीक कमांड की लाइनों से ज़्यादा प्राथमिकता पाती हैं.

  खास जानकारी, इनहेरिटेंस से तय होती है. कुछ कमांड, दूसरे कमांड से विकल्पों को इनहेरिट करते हैं. इससे, इनहेरिट करने वाला कमांड, मूल कमांड से ज़्यादा खास हो जाता है. उदाहरण के लिए, test, build निर्देश से इनहेरिट करता है. इसलिए, सभी bazel build फ़्लैग bazel test के लिए मान्य होते हैं. साथ ही, सभी build लाइनें bazel test पर भी लागू होती हैं. ऐसा तब तक होता है, जब तक उसी विकल्प के लिए test लाइन मौजूद न हो. अगर rc फ़ाइल में लिखा है:

  test -c dbg --test_env=PATH
  build -c opt --verbose_failures
  

  तो bazel build //foo, -c opt --verbose_failures का इस्तेमाल करेगा और bazel test //foo, --verbose_failures -c dbg --test_env=PATH का इस्तेमाल करेगा.

  इनहेरिटेंस (खासियत) ग्राफ़ यह है:

  • हर कमांड को common से इनहेरिट किया जाता है
  • ये निर्देश, build से इनहेरिट किए जाते हैं और इनमें build से ज़्यादा जानकारी होती है: test, run, clean, mobile-install, info, print_action, config, cquery, और aquery
  • coverage, fetch, और vendor को test से इनहेरिट किया गया

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

• प्राथमिकता का यह नियम, फ़ाइल के क्रम से मेल नहीं खाता. इसलिए, rc फ़ाइलों में प्राथमिकता के क्रम का पालन करने से, उन्हें पढ़ने में आसानी होती है: सबसे ऊपर common विकल्पों से शुरू करें और फ़ाइल के सबसे नीचे सबसे खास निर्देशों के साथ खत्म करें. इस तरह, विकल्पों को पढ़े जाने का क्रम और उन्हें लागू करने का क्रम समान होता है, जो ज़्यादा आसान होता है.

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

--config

विकल्पों के डिफ़ॉल्ट तौर पर सेट होने के अलावा, rc फ़ाइल का इस्तेमाल विकल्पों को ग्रुप करने और सामान्य ग्रुपिंग के लिए शॉर्टहैंड देने के लिए किया जा सकता है. ऐसा करने के लिए, कमांड में :name सर्फ़िक्स जोड़ें. इन विकल्पों को डिफ़ॉल्ट रूप से अनदेखा किया जाता है. हालांकि, जब कमांड लाइन या .bazelrc फ़ाइल में --config=name विकल्प मौजूद होगा, तब इन्हें शामिल किया जाएगा. ऐसा बार-बार किया जाएगा, भले ही यह किसी दूसरे कॉन्फ़िगरेशन की परिभाषा में हो. command:name से तय किए गए विकल्प, सिर्फ़ लागू निर्देशों के लिए, ऊपर बताए गए प्राथमिकता क्रम में ही दिखाए जाएंगे.

ध्यान दें: कॉन्फ़िगरेशन को किसी भी .bazelrc फ़ाइल में तय किया जा सकता है. साथ ही, लागू होने वाले निर्देशों के लिए, command:name फ़ॉर्म की सभी लाइनों को अलग-अलग rc फ़ाइलों में बड़ा किया जाएगा. नाम से जुड़ी समस्याओं से बचने के लिए, हमारा सुझाव है कि निजी rc फ़ाइलों में तय किए गए कॉन्फ़िगरेशन, अंडरस्कोर (_) से शुरू हों. इससे, अनजाने में नाम शेयर होने से बचा जा सकता है.

--config=foo, rc फ़ाइलों में "जगह पर" तय किए गए विकल्पों में बड़ा हो जाता है, ताकि कॉन्फ़िगरेशन के लिए तय किए गए विकल्पों की प्राथमिकता वही हो जो --config=foo विकल्प की थी.

इस सिंटैक्स में स्टार्टअप के विकल्प सेट करने के लिए, startup का इस्तेमाल नहीं किया जा सकता. .baडेलrc में startup:config-name --some_startup_option को सेट करने पर, इसे अनदेखा कर दिया जाएगा.

--enable_platform_specific_config

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

--enable_platform_specific_config देखें.

उदाहरण

यहां ~/.bazelrc फ़ाइल का एक उदाहरण दिया गया है:

# Bob's Bazel option defaults

startup --host_jvm_args=-XX:-UseParallelGC
import /home/bobs_project/bazelrc
build --show_timestamps --keep_going --jobs 600
build --color=yes
query --keep_going

# Definition of --config=memcheck
build:memcheck --strip=never --test_timeout=3600

Bazel के काम करने के तरीके को कंट्रोल करने वाली अन्य फ़ाइलें

.bazelignore

फ़ाइल फ़ोल्डर में, ऐसी डायरेक्ट्री के बारे में बताया जा सकता है जिसे आपको बेज़ल से अनदेखा करना है. जैसे, अन्य बिल्ड सिस्टम का इस्तेमाल करने वाले मिलते-जुलते प्रोजेक्ट. फ़ाइल फ़ोल्डर के रूट में .bazelignore नाम की फ़ाइल रखें और उन डायरेक्ट्री को जोड़ें जिन्हें आपको Basel को अनदेखा करना है. एक हर लाइन में एक डायरेक्ट्री जोड़ें. एंट्री, फ़ाइल फ़ोल्डर के रूट से जुड़ी होती हैं.

ग्लोबल bazelrc फ़ाइल

Bazel, वैकल्पिक bazelrc फ़ाइलों को इस क्रम में पढ़ता है:

1. सिस्टम की rc-फ़ाइल, etc/bazel.bazelrc पर मौजूद है.
2. Workspace rc-फ़ाइल, $workspace/tools/bazel.rc पर मौजूद है.
3. होम rc-फ़ाइल, $HOME/.bazelrc पर मौजूद है

यहां दी गई हर bazelrc फ़ाइल के लिए एक फ़्लैग होता है.इसका इस्तेमाल, फ़ाइल को बंद करने के लिए किया जा सकता है. जैसे, --nosystem_rc, --noworkspace_rc, --nohome_rc. --ignore_all_rc_files स्टार्टअप विकल्प को पास करके, Bazel को सभी bazelrc फ़ाइलों को अनदेखा करने के लिए भी कहा जा सकता है.