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

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

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

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

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

  1. जब तक --nosystem_rc मौजूद न हो, सिस्टम 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. उपयोगकर्ता की तय की गई आरसी फ़ाइल, अगर --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 की वजह से अनदेखा किया गया है.

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

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

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

इंपोर्ट

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

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

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

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

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

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

  • startup: स्टार्टअप विकल्प, जो कमांड से पहले जाते हैं और bazel help startup_options में इनके बारे में बताया गया है.
  • common: ऐसे सभी विकल्पों पर लागू किए जाने वाले विकल्प जो डिवाइसों के साथ काम करते हैं. अगर कोई निर्देश इस तरह से दिए गए किसी विकल्प के साथ काम नहीं करता है, तो यह विकल्प तब तक नज़रअंदाज़ किया जाता है, जब तक कि वह कुछ अन्य Bazel कमांड के लिए मान्य रहता है. ध्यान दें कि यह सिर्फ़ विकल्प के नामों पर लागू होता है: अगर मौजूदा निर्देश दिए गए नाम के साथ किसी विकल्प को स्वीकार करता है, लेकिन बताई गई वैल्यू के साथ काम नहीं करता है, तो यह फ़ेल हो जाएगा.
  • always: वे सभी विकल्प जो सभी बेज़ल निर्देशों पर लागू होते हैं. अगर कोई निर्देश इस तरीके से दिए गए विकल्प पर काम नहीं करता है, तो वह फ़ेल हो जाएगा.
  • command: बैज़ल कमांड, जैसे कि 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 लागू होते हैं.

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

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

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

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

    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 विकल्पों के साथ शुरू करें और फ़ाइल के सबसे नीचे, सबसे खास निर्देशों पर खत्म करें. इस तरह, विकल्पों को पढ़े जाने का क्रम और उन्हें लागू करने का क्रम भी एक जैसा रहता है.

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

--config

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

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

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

उदाहरण

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

बेज़ल के व्यवहार को कंट्रोल करने वाली अन्य फ़ाइलें

.bazelignore

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

दुनिया की ऊंचे स्तर की फ़ाइल

बेज़ल, क्रम से लगने वाली वैकल्पिक बैच फ़ाइलों को इस क्रम में पढ़ता है:

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

यहां सूची में दी गई हर बाज़ार फ़ाइल के नाम से जुड़ा एक फ़्लैग है, जिसका इस्तेमाल करके उसे बंद किया जा सकता है (जैसे, --nosystem_rc, --noworkspace_rc, --nohome_rc). --ignore_all_rc_filesशुरू करने का विकल्प पास करके, आप बेज़ल को सभी बैजल में शामिल नहीं कर सकते.