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

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

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

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

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

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

अपनी बिड को ऑटोमेट और ऑप्टिमाइज़ करने के लिए,

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

my_attr = "prefix $(FOO) suffix"

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

my_attr = "prefix bar suffix"

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

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

my_attr = "prefix $@ suffix"

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

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

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

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

bazel info --show_make_env [build options]

कैपिटल लेटर का इस्तेमाल करके, सबसे ऊपर वाली आउटपुट लाइन को देखें.

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

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

पाथ वैरिएबल

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

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

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

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

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

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

पहले से तय किए गए जेनरूल वैरिएबल

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

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

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

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

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

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

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

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

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

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

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

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

  • execpath: यह execruit के नीचे मौजूद पाथ को दिखाता है. इसकी मदद से, Basel की टीम, बिल्ड ऐक्शन को रन करती है.

    ऊपर दिए गए उदाहरण में, Baज़ल, आपके फ़ाइल फ़ोल्डर के रूट में मौजूद bazel-myproject सिमलिंक से लिंक की गई डायरेक्ट्री में, सभी बिल्ड ऐक्शन को चलाता है. सोर्स फ़ाइल empty.source को bazel-myproject/testapp/empty.source पाथ से लिंक किया गया है. इसलिए, इसका एक्ज़िक्यूटिव पाथ (जो रूट के नीचे मौजूद सबपाथ है) 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 के मुकाबले, इसकी एक वजह यह है कि यह सभी प्लैटफ़ॉर्म पर काम करती है. भले ही, रनफ़ाइल डायरेक्ट्री उपलब्ध न हो.

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

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

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

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

यह ज़रूरी नहीं है कि लेबल, कैननिकल रूप में हों: foo, :foo, और //somepkg:foo सब ठीक है.

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

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

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

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

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

पहले से मौजूद C++ के नियम, "इस पर कंपाइलर चलाएं" के मुकाबले ज़्यादा बेहतर हैं. मॉड्यूल के साथ/बिना मॉड्यूल के साथ-साथ अलग-अलग तरह के कंपाइलेशन मोड, साथ ही,

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

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

  • CC: C और C++ कंपाइलर निर्देश.

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

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

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

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

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

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

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