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

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

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

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

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

   पाथ:

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

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

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

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

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

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

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

   पाथ:

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

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

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

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

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

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

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

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

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

.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: ऐसे विकल्प जिन्हें Basel के उन सभी कमांड पर लागू किया जाना चाहिए जो इसके साथ काम करते हैं. अगर कोई कमांड इस तरह से बताए गए विकल्प के साथ काम नहीं करता है, तो विकल्प को तब तक अनदेखा कर दिया जाता है, जब तक कि वह किसी अन्य Bazel कमांड के लिए मान्य है. ध्यान दें कि यह सिर्फ़ विकल्प के नामों पर लागू होता है: अगर मौजूदा निर्देश, तय किए गए नाम वाले विकल्प को स्वीकार करता है, लेकिन तय की गई वैल्यू के साथ काम नहीं करता है, तो वह काम नहीं करेगा.
• always: ऐसे विकल्प जो Basel के सभी कमांड पर लागू होते हैं. अगर कोई कमांड इस तरह से बताए गए विकल्प के साथ काम नहीं करता है, तो वह काम नहीं करेगा.
• command: Basel कमांड, जैसे कि build या query, जिस पर ये विकल्प लागू होते हैं. ये विकल्प, बताए गए कमांड से इनहेरिट होने वाले सभी कमांड पर भी लागू होते हैं. (उदाहरण के लिए, test, build से इनहेरिट करता है.)

इनमें से हर लाइन को एक से ज़्यादा बार इस्तेमाल किया जा सकता है और पहले शब्द के बाद आने वाले तर्क को इस तरह से जोड़ दिया जाता है जैसे कि वे एक ही लाइन में आ गए हों. (CVS के उपयोगकर्ताओं को, "स्विज़ आर्मी नाइफ़" कमांड-लाइन इंटरफ़ेस वाला एक और टूल मिलेगा. इसमें सिंटैक्स, .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 फ़ाइलों में मौजूद विकल्पों के मुकाबले हमेशा प्राथमिकता दी जाती है. उदाहरण के लिए, अगर किसी आरसी फ़ाइल में 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 को test से इनहेरिट किया गया है

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

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

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

--config

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

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

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

उदाहरण

यहां ~/.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

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

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

Baज़ल, वैकल्पिक bagelrc फ़ाइलों को इस क्रम में पढ़ता है: - सिस्टम rc-file मौजूद है, जो etc/bazel.bazelrc पर मौजूद है. - Workspace की rc-फ़ाइल, $workspace/tools/bazel.rc पर मौजूद है. - $HOME/.bazelrc पर मौजूद होम आरसी-फ़ाइल

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