वैरिएबल बनाएं

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

"Make" वैरिएबल, स्ट्रिंग वाले ऐसे वैरिएबल होते हैं जिन्हें बड़ा किया जा सकता है. ये वैरिएबल, "'Make वैरिएबल' के बदले इस्तेमाल किए जा सकते हैं" के तौर पर मार्क किए गए एट्रिब्यूट के लिए उपलब्ध होते हैं.

उदाहरण के लिए, इनका इस्तेमाल, उपयोगकर्ता की बनाई गई बिल्ड ऐक्शन में खास टूलचेन पाथ को इंजेक्ट करने के लिए किया जा सकता है.

Bazel, पहले से तय वैरिएबल और कस्टम वैरिएबल, दोनों उपलब्ध कराता है. पहले से तय वैरिएबल सभी टारगेट के लिए उपलब्ध होते हैं. वहीं, कस्टम वैरिएबल, डिपेंडेंसी टारगेट में तय किए जाते हैं और सिर्फ़ उन टारगेट के लिए उपलब्ध होते हैं जो उन पर निर्भर होते हैं.

"Make" शब्द का इस्तेमाल इसलिए किया जाता है, क्योंकि इन वैरिएबल के सिंटैक्स और सेमेटिक्स को मूल रूप से GNU Make से मैच करने के लिए बनाया गया था.

इस्तेमाल करें

"'Make वैरिएबल' के बदले इस्तेमाल किए जा सकते हैं" के तौर पर मार्क किए गए एट्रिब्यूट, "Make" वैरिएबल FOO का रेफ़रंस इस तरह दे सकते हैं:

my_attr = "prefix $(FOO) suffix"

दूसरे शब्दों में, $(FOO) से मैच करने वाली कोई भी सबस्ट्रिंग, FOO की वैल्यू तक बढ़ जाती है. अगर वह वैल्यू "bar" है, तो आखिरी स्ट्रिंग इस तरह दिखेगी:

my_attr = "prefix bar suffix"

अगर FOO, इस्तेमाल करने वाले टारगेट के किसी ऐसे वैरिएबल से मेल नहीं खाता है जिसकी जानकारी है, तो Bazel गड़बड़ी के साथ फ़ेल हो जाता है.

"Make" वैरिएबल के नाम, अक्षर के बजाय चिह्न होते हैं. जैसे, @. इनका रेफ़रंस देने के लिए, ब्रैकेट के बिना सिर्फ़ डॉलर के चिह्न का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

my_attr = "prefix $@ suffix"

$ को स्ट्रिंग लिटरल के तौर पर लिखने के लिए, $$ लिखें. इससे वैरिएबल का बड़ा होना रुक जाता है.

पहले से तय वेरिएबल

पहले से तय "Make" वैरिएबल का रेफ़रंस, किसी भी टारगेट पर "'Make वैरिएबल' के बदले इस्तेमाल किया जा सकता है" के तौर पर मार्क किए गए किसी भी एट्रिब्यूट से लिया जा सकता है.

बिल्ड के विकल्पों के किसी दिए गए सेट के लिए, इन वैरिएबल और उनकी वैल्यू की सूची देखने के लिए,

bazel info --show_make_env [build options]

और कैपिटल लेटर वाली सबसे ऊपर की आउटपुट लाइनें देखें.

पहले से तय वैरिएबल का उदाहरण देखें.

टूलचेन के विकल्प के वैरिएबल

पाथ वैरिएबल

  • BINDIR: टारगेट आर्किटेक्चर के लिए जनरेट की गई बाइनरी ट्री का आधार.

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

    अगर आपको genrule में किसी टूल को चलाना है, तो उसका पाथ पाने के लिए $(execpath toolname) का सुझाव दिया जाता है. इसमें toolname को genrule के tools एट्रिब्यूट में शामिल करना ज़रूरी है.

  • GENDIR: यह टारगेट आर्किटेक्चर के लिए, जनरेट किए गए कोड ट्री का बेस होता है.

मशीन आर्किटेक्चर वैरिएबल

  • TARGET_CPU: टारगेट आर्किटेक्चर का सीपीयू, जैसे कि k8.

पहले से तय किए गए genrule वैरिएबल

ये खास तौर पर genrule के cmd एट्रिब्यूट के लिए उपलब्ध हैं. आम तौर पर, इस एट्रिब्यूट को काम करने के लिए, इनका इस्तेमाल करना ज़रूरी होता है.

पहले से तय किए गए genrule वैरिएबल का उदाहरण देखें.

  • OUTS: genrule की outs सूची. अगर आपके पास सिर्फ़ एक आउटपुट फ़ाइल है, तो $@ का इस्तेमाल भी किया जा सकता है.
  • SRCS: genrule की srcs सूची (या ज़्यादा सटीक तरीके से: srcs सूची में लेबल से जुड़ी फ़ाइलों के पाथ के नाम). अगर आपके पास सिर्फ़ एक सोर्स फ़ाइल है, तो $< का इस्तेमाल भी किया जा सकता है.
  • <: SRCS, अगर यह एक फ़ाइल है. ऐसा न करने पर, बिल्ड करने में गड़बड़ी होती है.
  • @: OUTS, अगर यह एक फ़ाइल है. ऐसा न करने पर, बिल्ड करने से जुड़ी गड़बड़ी का मैसेज दिखता है.

  • RULEDIR: टारगेट की आउटपुट डायरेक्ट्री, यानी कि genfiles या bin ट्री में टारगेट वाले पैकेज के नाम से जुड़ी डायरेक्ट्री. //my/pkg:my_genrule के लिए, यह हमेशा my/pkg पर खत्म होता है. भले ही, //my/pkg:my_genrule के आउटपुट सबडायरेक्ट्री में हों.

  • @D: आउटपुट डायरेक्ट्री. अगर outs में एक एंट्री है, तो यह उस फ़ाइल वाली डायरेक्ट्री तक बड़ा हो जाता है. अगर इसमें एक से ज़्यादा एंट्री हैं, तो यह genfiles ट्री में पैकेज की रूट डायरेक्ट्री तक फैल जाता है. भले ही, सभी आउटपुट फ़ाइलें एक ही सबडायरेक्ट्री में हों!

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

    अगर genrule को कुछ समय के लिए इंटरमीडियरी फ़ाइलें जनरेट करनी हैं (शायद कंपाइलर जैसे किसी दूसरे टूल का इस्तेमाल करने की वजह से), तो उसे उन फ़ाइलों को @D में लिखने की कोशिश करनी चाहिए (हालांकि, /tmp में भी लिखा जा सकता है). साथ ही, फ़ाइलें जनरेट होने के बाद उन्हें हटा देना चाहिए.

    खास तौर पर, इनपुट वाली डायरेक्ट्री में लिखने से बचें. ये फ़ाइलें, सिर्फ़ पढ़ने के लिए उपलब्ध फ़ाइल सिस्टम पर हो सकती हैं. भले ही ऐसा न हो, लेकिन ऐसा करने से सोर्स ट्री को ट्रैश में डाल दिया जाएगा.

पहले से तय किए गए सोर्स/आउटपुट पाथ वैरिएबल

पहले से तय वैरिएबल execpath, execpaths, rootpath, rootpaths, location, और locations, लेबल पैरामीटर (उदाहरण के लिए, $(execpath //foo:bar)) लेते हैं और उस लेबल से दिखाए गए फ़ाइल पाथ को बदल देते हैं.

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

पहले से तय किए गए पाथ वैरिएबल का उदाहरण देखें.

  • execpath: execroot के नीचे मौजूद उस पाथ को दिखाता है जहां Bazel, बिल्ड ऐक्शन चलाता है.

    ऊपर दिए गए उदाहरण में, Bazel आपके Workspace रूट में bazel-myproject सिमलिंक से लिंक की गई डायरेक्ट्री में, सभी बिल्ड ऐक्शन चलाता है. सोर्स फ़ाइल empty.source को पाथ bazel-myproject/testapp/empty.source पर लिंक किया गया है. इसलिए, इसका exec पाथ (जो कि रूट के नीचे का सबपाथ है) testapp/empty.source है. यह पाथ, फ़ाइल ढूंढने के लिए, पाथ बिल्ड करने वाली कार्रवाइयों का इस्तेमाल कर सकता है.

    आउटपुट फ़ाइलों को भी इसी तरह से स्टैज किया जाता है. हालांकि, इनके नाम के आगे सबपाथ bazel-out/cpu-compilation_mode/bin (या टूल के आउटपुट के लिए: bazel-out/cpu-opt-exec-hash/bin) भी जोड़ा जाता है. ऊपर दिए गए उदाहरण में, //testapp:app एक टूल है, क्योंकि यह show_app_output के tools एट्रिब्यूट में दिखता है. इसलिए, इसकी आउटपुट फ़ाइल app को bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app में लिखा जाता है. इसलिए, exec पाथ bazel-out/cpu-opt-exec-hash/bin/testapp/app है. इस अतिरिक्त प्रीफ़िक्स की मदद से, एक ही बिल्ड में दो अलग-अलग सीपीयू के लिए एक ही टारगेट बनाया जा सकता है. ऐसा करने पर, नतीजों पर एक-दूसरे का असर नहीं पड़ता.

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

  • rootpath: इस पैरामीटर से उस पाथ का पता चलता है जिसका इस्तेमाल, बने हुए बाइनरी, मुख्य रिपॉज़िटरी से जुड़ी अपनी रनफ़ाइल डायरेक्ट्री की सबडायरेक्ट्री के मुकाबले, रनटाइम पर डिपेंडेंसी ढूंढने के लिए कर सकते हैं. ध्यान दें: यह सुविधा सिर्फ़ तब काम करती है, जब --enable_runfiles चालू हो. यह सुविधा, डिफ़ॉल्ट रूप से Windows पर चालू नहीं होती. इसके बजाय, rlocationpath का इस्तेमाल करें, ताकि आपके ऐप्लिकेशन को कई प्लैटफ़ॉर्म पर इस्तेमाल किया जा सके.

    यह execpath जैसा ही है, लेकिन इसमें ऊपर बताए गए कॉन्फ़िगरेशन के प्रीफ़िक्स नहीं होते. ऊपर दिए गए उदाहरण में इसका मतलब है कि empty.source और app, दोनों ही वर्कस्पेस के हिसाब से सिर्फ़ इन पाथ का इस्तेमाल करते हैं: testapp/empty.source और testapp/app.

    किसी बाहरी रिपॉज़िटरी repo में मौजूद फ़ाइल का rootpath, ../repo/ से शुरू होगा. इसके बाद, रिपॉज़िटरी से जुड़ा पाथ आएगा.

    इसमें execpath की तरह ही "सिर्फ़ एक आउटपुट" की ज़रूरी शर्तें लागू होती हैं.

  • rlocationpath: रनटाइम पर डिपेंडेंसी ढूंढने के लिए, बने हुए बाइनरी का पाथ, रनफ़ाइल्स लाइब्रेरी के Rlocation फ़ंक्शन को पास किया जा सकता है. इसके लिए, रनफ़ाइल्स डायरेक्ट्री (अगर उपलब्ध हो) या रनफ़ाइल्स मेनिफ़ेस्ट का इस्तेमाल किया जा सकता है.

    यह rootpath से मिलता-जुलता है, क्योंकि इसमें कॉन्फ़िगरेशन के प्रीफ़िक्स शामिल नहीं होते. हालांकि, यह इस बात में अलग है कि यह हमेशा रिपॉज़िटरी के नाम से शुरू होता है. ऊपर दिए गए उदाहरण में इसका मतलब है कि empty.source और app से ये पाथ मिलते हैं: myproject/testapp/empty.source और myproject/testapp/app.

    किसी बाहरी रिपॉज़िटरी repo में मौजूद फ़ाइल का rlocationpath, repo/ से शुरू होगा. इसके बाद, रिपॉज़िटरी से जुड़ा पाथ आएगा.

    रनटाइम पर डिपेंडेंसी ढूंढने के लिए, इस पाथ को किसी बाइनरी में पास करना और इसे रनफ़ाइल लाइब्रेरी का इस्तेमाल करके फ़ाइल सिस्टम पाथ में बदलना, सबसे सही तरीका है. rootpath की तुलना में, इसका फ़ायदा यह है कि यह सभी प्लैटफ़ॉर्म पर काम करता है. भले ही, runfiles डायरेक्ट्री उपलब्ध न हो.

    इसमें execpath की तरह ही "सिर्फ़ एक आउटपुट" की ज़रूरी शर्तें लागू होती हैं.

  • location: execpath या rootpath का एक समानार्थी शब्द. यह इस बात पर निर्भर करता है कि किस एट्रिब्यूट को बड़ा किया जा रहा है. यह Starlark से पहले के लेगसी वर्शन का व्यवहार है. इसका सुझाव तब तक नहीं दिया जाता, जब तक आपको यह पता न हो कि यह किसी खास नियम के लिए क्या करता है. ज़्यादा जानकारी के लिए, #2475 देखें.

execpaths, rootpaths, rlocationpaths, और locations, execpath, rootpath, rlocationpaths, और location के बहुवचन के वैरिएंट हैं. ये कई आउटपुट देने वाले लेबल के साथ काम करते हैं. ऐसे में, हर आउटपुट को स्पेस से अलग करके लिस्ट किया जाता है. शून्य आउटपुट वाले नियम और गलत तरीके से बने लेबल की वजह से, बिल्ड करने में गड़बड़ियां होती हैं.

रेफ़र किए गए सभी लेबल, डेटा का इस्तेमाल करने वाले टारगेट की srcs, आउटपुट फ़ाइलों या deps में दिखने चाहिए. ऐसा न करने पर, बिल्ड पूरा नहीं होता. C++ टारगेट, data में मौजूद लेबल का रेफ़रंस भी दे सकते हैं.

लेबल को कैननिकल फ़ॉर्मैट में होना ज़रूरी नहीं है: foo, :foo और //somepkg:foo, सभी सही हैं.

कस्टम वैरिएबल

कस्टम "Make" वैरिएबल का रेफ़रंस, "'Make वैरिएबल' के बदले इस्तेमाल किए जाने के तौर पर मार्क किए गए किसी भी एट्रिब्यूट से लिया जा सकता है. हालांकि, ऐसा सिर्फ़ उन टारगेट के लिए किया जा सकता है जो उन अन्य टारगेट पर निर्भर करते हैं जो इन वैरिएबल को तय करते हैं.

सबसे सही तरीके के तौर पर, सभी वैरिएबल कस्टम होने चाहिए. ऐसा तब तक करना चाहिए, जब तक कि उन्हें कोर Bazel में शामिल करने की कोई बहुत अच्छी वजह न हो. इससे Bazel को, वैरिएबल की आपूर्ति करने के लिए, संभावित तौर पर महंगी डिपेंडेंसी लोड करने से बचना पड़ता है. ऐसा उन टारगेट के लिए किया जाता है जिनमें वैरिएबल का इस्तेमाल नहीं किया जाता.

C++ टूलचेन वैरिएबल

ये C++ टूलचेन के नियमों में बताए गए हैं और toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"] को सेट करने वाले किसी भी नियम के लिए उपलब्ध हैं java_binary जैसे कुछ नियमों में, उनके नियम की परिभाषा में C++ टूलचेन को शामिल किया गया है. ये वैरिएबल,

C++ के लिए पहले से मौजूद नियम, "इस पर कंपाइलर चलाएं" से काफ़ी बेहतर हैं. *SAN, ThinLTO जैसे अलग-अलग कंपाइलेशन मोड के साथ-साथ, कई प्लैटफ़ॉर्म पर तेज़ी से चलने वाले टेस्ट के साथ-साथ, मॉड्यूल के साथ/बिना और ध्यान से ऑप्टिमाइज़ की गई बाइनरी के साथ काम करने के लिए, पहले से मौजूद नियमों को बहुत ज़्यादा ध्यान से बनाया गया है. इससे यह पक्का किया जा सकता है कि अंदरूनी तौर पर जनरेट की गई कई कार्रवाइयों में, सही इनपुट, आउटपुट, और कमांड-लाइन फ़्लैग सेट किए गए हों.

ये वैरिएबल, फ़ॉलबैक मैकेनिज्म के तौर पर काम करते हैं. इनका इस्तेमाल, भाषा विशेषज्ञ बहुत ही कम मामलों में करते हैं. अगर आपको इनका इस्तेमाल करना है, तो कृपया पहले Bazel डेवलपर से संपर्क करें.

  • ABI: C++ ABI वर्शन.
  • AR: crosstool से "ar" कमांड.
  • C_COMPILER: C/C++ कंपाइलर आइडेंटिफ़ायर, जैसे कि llvm.

  • CC: C और C++ कंपाइलर कमांड.

    हमारा सुझाव है कि आप हमेशा CC_FLAGS के साथ CC का इस्तेमाल करें. ऐसा न करने पर, आपके खाते पर असर पड़ सकता है.

  • CC_FLAGS: C/C++ के लिए, फ़्लैग का एक छोटा सेट, ताकि genrules का इस्तेमाल किया जा सके. खास तौर पर, इसमें फ़्लैग होते हैं, ताकि CC के एक से ज़्यादा आर्किटेक्चर के साथ काम करने पर, सही आर्किटेक्चर चुना जा सके.
  • NM: crosstool से "nm" कमांड.
  • OBJCOPY: C/C++ compiler के सुइट में मौजूद, objcopy कमांड.
  • STRIP: C/C++ के कंपाइलर के सुइट में मौजूद, स्ट्रिप कमांड.

Java टूलचेन के वैरिएबल

ये Java टूलचेन के नियमों में बताए गए हैं. साथ ही, ये उन सभी नियमों के लिए उपलब्ध हैं जो toolchains = ["@bazel_tools//tools/jdk:current_java_runtime"] (या होस्ट टूलचेन के बराबर के लिए "@bazel_tools//tools/jdk:current_host_java_runtime") सेट करते हैं.

JDK में मौजूद ज़्यादातर टूल का सीधे तौर पर इस्तेमाल नहीं किया जाना चाहिए. Java के लिए पहले से मौजूद नियम, Java कोड को कंपाइल करने और पैकेज करने के लिए, अपस्ट्रीम टूल के मुकाबले ज़्यादा बेहतर तरीके इस्तेमाल करते हैं. जैसे, इंटरफ़ेस Jars, हेडर इंटरफ़ेस Jars, और ज़्यादा ऑप्टिमाइज़ की गई Jar पैकेजिंग और मर्ज करने की सुविधा.

ये वैरिएबल, फ़ॉलबैक मैकेनिज्म के तौर पर काम करते हैं. इनका इस्तेमाल, भाषा विशेषज्ञ बहुत ही कम मामलों में करते हैं. अगर आपको इनका इस्तेमाल करना है, तो कृपया पहले Bazel डेवलपर से संपर्क करें.

  • JAVA: "java" कमांड (Java वर्चुअल मशीन). ऐसा करने से बचें और जहां भी हो सके वहां java_binary नियम का इस्तेमाल करें. यह रिलेटिव पाथ हो सकता है. अगर आपको java को शुरू करने से पहले डायरेक्ट्री बदलनी है, तो आपको बदलने से पहले, काम करने वाली डायरेक्ट्री को कैप्चर करना होगा.
  • JAVABASE: यह वह डायरेक्ट्री है जिसमें Java की यूटिलिटी मौजूद होती हैं. यह रिलेटिव पाथ हो सकता है. इसमें "bin" सबडायरेक्ट्री होगी.

Starlark से तय किए गए वैरिएबल

नियम और टूलचेन लिखने वाले लोग, TemplateVariableInfo प्रोवाइडर को दिखाकर, पूरी तरह से कस्टम वैरिएबल तय कर सकते हैं. toolchains एट्रिब्यूट के ज़रिए इन पर निर्भर करने वाले सभी नियम, उनकी वैल्यू पढ़ सकते हैं:

Starlark से तय किए गए वैरिएबल का उदाहरण देखें.