&कोटेशन&कोटेशन

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

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

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

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

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

आपके कैंपेन के लक्ष्यों के हिसाब से किन लोगों के ग्राहक में बदलने की संभावना ज़्यादा है, यह जानने के लिए

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

my_attr = "prefix $(FOO) suffix"

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

my_attr = "prefix bar suffix"

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

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

my_attr = "prefix $@ suffix"

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

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

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

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

bazel info --show_make_env [build options]

और बड़े आउटपुट लाइन को बड़े अक्षरों में देखें.

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

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

पाथ वैरिएबल

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

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

    अगर आप genrule में कोई टूल चलाना चाहते हैं, तो इसका पाथ पाने का सुझाया गया तरीका $(execpath 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: आउटपुट डायरेक्ट्री. अगर outs में एक एंट्री है, तो यह फ़ाइल वाली फ़ाइल तक पहुंच जाती है. अगर इसमें एक से ज़्यादा एंट्री हैं, तो यह genfiles ट्री में पैकेज की रूट डायरेक्ट्री में बढ़ जाती है. भले ही, सभी आउटपुट फ़ाइलें एक ही सबडायरेक्ट्री में हों!

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

    अगर जनरेटर में कुछ समय तक चलने वाली इंटरमीडिएट फ़ाइलें जनरेट होने की ज़रूरत पड़ती है (शायद किसी कंपाइलर जैसे दूसरे टूल के इस्तेमाल की वजह से), तो उसे @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 के tools एट्रिब्यूट में दिखता है. इसलिए, आउटपुट फ़ाइल app को bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app पर लिखा गया है. उदाहरण के लिए, क्लास bazel-out/cpu-opt-exec-hash/bin/testapp/app. उदाहरण के तौर पर, इस प्रीफ़िक्स से, एक ही बिल्ड में दो अलग-अलग सीपीयू का इस्तेमाल किया जा सकता है. इससे, नतीजे एक-दूसरे से नहीं जुड़े होते.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • CC_FLAGS: C/C++ कंपाइलर के लिए झंडों का एक ज़रूरी सेट, जिसे genनियमों से इस्तेमाल किया जा सके. खास तौर पर, अगर 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 कंपाइलेशन और पैकेजिंग के लिए ज़्यादा बेहतर तरीके अपनाते हैं. उदाहरण के लिए, इंटरफ़ेस Java, हेडर इंटरफ़ेस Java, और बेहतर तरीके से ऑप्टिमाइज़ किया गया Java पैकेजिंग और मर्ज लागू करने के तरीके.

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

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

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

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

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