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

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

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

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

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

इस्तेमाल

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

my_attr = "prefix $(FOO) suffix"

दूसरे शब्दों में, $(FOO) से मैच करने वाली किसी भी सबस्ट्रिंग को FOO's वैल्यू में बदला जाता है. अगर वह वैल्यू "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's tools एट्रिब्यूट में शामिल किया जाना चाहिए.

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

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

  • TARGET_CPU: टारगेट आर्किटेक्चर का सीपीयू (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's के आउटपुट, सबडायरेक्ट्री में हों.

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

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

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

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

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

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

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

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

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

    ऊपर दिए गए उदाहरण में, Bazel आपके वर्कस्पेस रूट में 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's 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 के मुकाबले, इसका फ़ायदा यह है कि यह सभी प्लैटफ़ॉर्म पर काम करता है. साथ ही, यह तब भी काम करता है, जब रनफ़ाइल डायरेक्ट्री उपलब्ध न हो.

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

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

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

रेफ़र किए गए सभी लेबल, इस्तेमाल करने वाले टारगेट के srcs, आउटपुट फ़ाइलों या deps में दिखने चाहिए. ऐसा न होने पर, बिल्ड में गड़बड़ी होती है. C++ टारगेट, `data` में मौजूद लेबल को भी रेफ़र कर सकते हैं.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: क्रॉसटूल से "ar" कमांड.
  • C_COMPILER: C/C++ कंपाइलर आइडेंटिफ़ायर. उदाहरण के लिए, llvm.

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

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

  • CC_FLAGS: C/C++ कंपाइलर के लिए, फ़्लैग का एक छोटा सेट. इसका इस्तेमाल genrules कर सकते हैं. खास तौर पर, इसमें सही आर्किटेक्चर चुनने के लिए फ़्लैग शामिल होते हैं. हालांकि, यह तब काम करता है, जब CC एक से ज़्यादा आर्किटेक्चर को सपोर्ट करता हो.
  • DUMPBIN: Microsoft Visual Studio से Microsoft COFF बाइनरी फ़ाइल डंपर (dumpbin.exe) .
  • NM: क्रॉसटूल से "nm" कमांड.
  • OBJCOPY: objcopy कमांड. यह C/C++ कंपाइलर के जैसे ही सुइट से आता है.
  • STRIP: strip कमांड. यह C/C++ कंपाइलर के जैसे ही सुइट से आता है.

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

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

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

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

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

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

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

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