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

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

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

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

1. सिस्टम की RC फ़ाइल, जब तक कि --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 (मुख्य WORKSPACE फ़ाइल के बगल में).

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

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

   पाथ:

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

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

4. उपयोगकर्ता की ओर से तय की गई RC फ़ाइल, अगर --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 को अनदेखा कर दिया गया है.

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

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

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

आयात

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

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

इंपोर्ट करने की प्राथमिकता:

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

विकल्पों की डिफ़ॉल्ट सेटिंग

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

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

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

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, test से इनहेरिट करता है

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

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

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

--config

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

--config=foo, rc फ़ाइलों में तय किए गए विकल्पों के हिसाब से "इन-प्लेस" में फैलता है, ताकि कॉन्फ़िगरेशन के लिए तय किए गए विकल्पों को वही प्राथमिकता मिले जो --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

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

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

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

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