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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की रिपोर्ट करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

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

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

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

my_attr = "prefix $(FOO) suffix"

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

my_attr = "prefix bar suffix"

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

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

my_attr = "prefix $@ suffix"

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

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

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

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

bazel info --show_make_env [build options]

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

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

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

पाथ वैरिएबल

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

    ध्यान दें कि एक भिन्न ट्री का उपयोग ऐसे प्रोग्राम के लिए किया जा सकता है जो जिसमें क्रॉस-कंपाइलिंग की सुविधा मिलती है.

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

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

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

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

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

निम्न genrule's के लिए विशेष रूप से उपलब्ध हैं 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: यह कॉलम के नीचे के पाथ को दिखाता है एक्सक्रूट जहां बेज़ल बिल्ड ऐक्शन चलाता है.

    ऊपर दिए गए उदाहरण में, Baze, लिंक की गई डायरेक्ट्री में बिल्ड ऐक्शन को चलाता है अपने फ़ाइल फ़ोल्डर के रूट में 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.

    किसी बाहरी डेटा स्टोर करने की जगह में मौजूद फ़ाइल का 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 सब ठीक है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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