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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

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

   पाथ:

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

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

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

2. Workspace की आरसी फ़ाइल, जब तक कि --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 की वजह से अनदेखा कर दिया गया है.

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

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

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

आयात

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

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

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

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

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

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

• startup: स्टार्टअप के विकल्प, जो निर्देश से पहले दिए जाते हैं और इनके बारे में जानकारी दी गई है bazel help startup_options में.
• common: वे विकल्प जिन्हें Basel के उन सभी कमांड पर लागू किया जाना चाहिए जो इस प्लैटफ़ॉर्म पर काम करते हैं उन्हें. अगर कोई निर्देश इस तरीके से बताए गए विकल्प के साथ काम नहीं करता है, तो विकल्प को तब तक अनदेखा किया जाता है, जब तक कि यह कुछ अन्य Baखाते के निर्देश के लिए मान्य हो. ध्यान दें कि यह सिर्फ़ विकल्प के नामों पर लागू होता है: अगर मौजूदा निर्देश तय किए गए नाम वाला विकल्प, लेकिन वह बताए गए मान के साथ काम नहीं करता, वह विफल हो जाएगा.
• 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 फ़ाइलों में मौजूद विकल्पों के मुकाबले हमेशा प्राथमिकता दी जाती है. उदाहरण के लिए, अगर किसी आरसी फ़ाइल में build -c opt लिखा है, लेकिन कमांड लाइन फ़्लैग है -c dbg, कमांड लाइन फ़्लैग को प्राथमिकता दी जाती है.

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

  विशेषता इनहेरिटेंस से तय होती है. कुछ निर्देश यहां से विकल्प इनहेरिट करते हैं अन्य कमांड, जो इनहेरिट करने वाले कमांड को बेस से ज़्यादा सटीक बनाते हैं आदेश. उदाहरण के लिए, 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: test, run, clean, mobile-install, info, print_action, config, cquery, और aquery
  • coverage को test से इनहेरिट किया गया है

• समान विशिष्टता पर एक ही आदेश के लिए विकल्प बताने वाली दो पंक्तियां ये हैं फ़ाइल में उसी क्रम में पार्स होता है जिस क्रम में वे फ़ाइल में दिखते हैं.

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

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

--config

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

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

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

यह सिंटैक्स सेट करने के लिए startup के इस्तेमाल तक सीमित नहीं है स्टार्टअप के विकल्प. सेटिंग .bazzrc में मौजूद 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

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

.bazelignore

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

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

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

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

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