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

किसी समस्या की रिपोर्ट करें सोर्स देखें रात · 7.4 को अपनाएं. 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

"Make" शब्द बनाने की वजह ऐतिहासिक है: इसका सिंटैक्स और सिमेंटिक्स ये वैरिएबल मूल रूप से GNU बनाएं.

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

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

my_attr = "prefix $(FOO) suffix"

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

my_attr = "prefix bar suffix"

अगर FOO किसी ऐसे वैरिएबल से मेल नहीं खाता है जो उपभोक्ता का लक्ष्य तय नहीं किया है, तो गड़बड़ी की वजह से Basel का इस्तेमाल नहीं किया जा सका.

"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's के लिए विशेष रूप से उपलब्ध हैं 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 का मतलब आसान है और यह उसी तरह काम करता है आउटपुट फ़ाइलों की संख्या पर ध्यान दिए बिना.

    अगर जेनरुल को अस्थायी इंटरमीडिएट फ़ाइलें जनरेट करने की ज़रूरत है (शायद कंपाइलर जैसे किसी अन्य टूल का इस्तेमाल करने पर, इसे उन्हें @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 है. इस अतिरिक्त प्रीफ़िक्स की मदद से, एक ही बिल्ड में दो अलग-अलग सीपीयू के लिए एक ही टारगेट बनाया जा सकता है. ऐसा करने पर, नतीजों पर एक-दूसरे का असर नहीं पड़ता.

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

  • 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.

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

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

    इसमें "सिर्फ़ एक आउटपुट" जैसा ही है 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 में शामिल करने की कोई बहुत अच्छी वजह न हो. इससे बेज़ल को लोड होने से बचाया जा सकता है टार्ट का इस्तेमाल करने वाले वैरिएबल की सप्लाई के लिए महंगी डिपेंडेंसी हो सकती है कोई फ़र्क़ नहीं पड़ता.

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

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

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

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

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

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

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

  • CC_FLAGS: C/C++ के लिए, फ़्लैग का एक छोटा सेट, ताकि genrules का इस्तेमाल किया जा सके. खास तौर पर, इसमें फ़्लैग होते हैं, जो अगर CC एक से ज़्यादा प्लैटफ़ॉर्म के साथ काम करता है, तो सही आर्किटेक्चर चुनें डिज़ाइन किया गया है.
  • NM: "एनएम" क्रॉसटूल का आदेश मिलता है.
  • OBJCOPY: C/C++ वाले सुइट से ही 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 पैकेजिंग और मर्ज करने की सुविधा.

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

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

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

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

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