BazelCon 2022, 16 नवंबर से 17 नवंबर तक न्यूयॉर्क में और ऑनलाइन उपलब्ध है.
आज ही रजिस्टर करें!

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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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

"विषय के रूप में मार्क किए गए एट्रिब्यूट ' सब्स्टीट्यूशन और कोटेशन के तौर पर मार्क किए गए एट्रिब्यूट, इस तरह से &kot;मेक&कोटेशनFOO दे सकते हैं:

my_attr = "prefix $(FOO) suffix"

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

my_attr = "prefix bar suffix"

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

& बताना</a>; वैरिएबल, जिनके नाम अक्षर नहीं हैं, जैसे @, उन्हें बिना ब्रैकेट के, सिर्फ़ डॉलर के निशान का इस्तेमाल करके भी बताया जा सकता है. उदाहरण के लिए:

my_attr = "prefix $@ suffix"

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

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

पहले से तय &कोटेशन & कोटेशन

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

bazel info --show_make_env [build options]

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

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

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

पाथ वैरिएबल

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

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

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

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

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

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

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

नीचे दी गई चीज़ें genrule और #39; cmd विशेषता के लिए खास तौर पर उपलब्ध हैं. आम तौर पर, ये विशेषताएं काम करने के लिए ज़रूरी होती हैं.

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

  • OUTS: genrule's outs सूची. अगर आपके पास सिर्फ़ एक आउटपुट फ़ाइल है, तो $@ का भी इस्तेमाल किया जा सकता है.
  • SRCS: genrule&#39s की srcs सूची (या ज़्यादा सटीक: srcs सूची में लेबल से जुड़ी फ़ाइलों के पाथ के नाम). अगर आपके पास सिर्फ़ एक स्रोत फ़ाइल है, तो आप $< का भी इस्तेमाल कर सकते हैं.
  • <: SRCS, अगर यह एक ही फ़ाइल है. इससे बिल्ड गड़बड़ी होती है.
  • @: OUTS, अगर यह एक ही फ़ाइल है. इससे बिल्ड गड़बड़ी होती है.
  • RULEDIR: टारगेट की आउटपुट डायरेक्ट्री, यानी जो पैकेज का नाम हो और जिसमें genfiles या bin ट्री के नीचे टारगेट हो. //my/pkg:my_genrule के लिए, यह हमेशा my/pkg पर खत्म होता है. भले ही, //my/pkg:my_genrule' आउटपुट, सबडायरेक्ट्री में हों.

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

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

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

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

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

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

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

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

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

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

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

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

  • rootpath: रनवे पाथ को दिखाता है, जिसे रनटाइम के दौरान डिपेंडेंसी ढूंढने के लिए, बनाई गई बाइनरी का इस्तेमाल किया जा सकता है.

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

    इसमें execpath के तौर पर एक ही &कोटेशन वाले आउटपुट की ज़रूरी शर्तें हैं.

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

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

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

यह ज़रूरी नहीं है कि लेबल सभी के कैननिकल वर्शन में हों: foo, :foo और //somepkg:foo का इस्तेमाल किया जा सकता है.

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

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

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

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

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

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

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

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

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

  • 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 नियम, अपस्ट्रीम टूल की तुलना में Java कंपाइलेशन और पैकेजिंग के लिए ज़्यादा बेहतर तरीके इस्तेमाल करते हैं. इनमें, इंटरफ़ेस Javas, हेडर इंटरफ़ेस Jars, और बहुत ज़्यादा ऑप्टिमाइज़ किए गए Java पैकेजिंग और मर्जिंग को लागू करना शामिल है.

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

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

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

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

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