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

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

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

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

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

    पाथ:

    • Linux/macOS/Unixes पर: /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/Unixes पर: $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 से इनहेरिट करता है

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

  • यह प्राथमिकता का नियम, फ़ाइल के क्रम से मेल नहीं खाता. इसलिए, अगर आरसी फ़ाइलों में प्राथमिकता के क्रम का पालन किया जाता है, तो इससे फ़ाइल को आसानी से पढ़ा जा सकता है: सबसे ऊपर 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 को अनदेखा करना है. जैसे, ऐसे प्रोजेक्ट जो अन्य बिल्ड सिस्टम का इस्तेमाल करते हैं. फ़ाइल फ़ोल्डर के रूट में .bazelignore नाम की फ़ाइल रखें. इसके बाद, उन डायरेक्ट्री को जोड़ें जिन्हें Bazel को अनदेखा करना है. हर लाइन में एक डायरेक्ट्री जोड़ें. ये एंट्री, वर्कस्पेस के रूट के हिसाब से होती हैं.

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

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

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

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