- इस्तेमाल करें
- पहले से तय वैरिएबल
- पहले से तय किए गए जेनरूल वैरिएबल
- पहले से तय सोर्स/आउटपुट पाथ के वैरिएबल
- कस्टम वैरिएबल
"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]
कैपिटल लेटर का इस्तेमाल करके, सबसे ऊपर वाली आउटपुट लाइन को देखें.
पहले से तय वैरिएबल का उदाहरण देखें.
टूलचेन के विकल्प वैरिएबल
COMPILATION_MODE
:fastbuild
,dbg
याopt
. (ज़्यादा जानकारी)
पाथ वैरिएबल
-
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
एट्रिब्यूट के ज़रिए इन नियमों के आधार पर तय किया गया कोई भी नियम, इनकी वैल्यू पढ़ सकता है: