- इस्तेमाल करना
- पहले से तय वैरिएबल
- पहले से तय किए गए genrule वैरिएबल
- पहले से तय किए गए सोर्स/आउटपुट पाथ वैरिएबल
- कस्टम वैरिएबल
"Make" वैरिएबल, स्ट्रिंग वाले ऐसे वैरिएबल होते हैं जिन्हें बड़ा किया जा सकता है. ये वैरिएबल, "'Make वैरिएबल' के बदले इस्तेमाल किए जा सकते हैं" के तौर पर मार्क किए गए एट्रिब्यूट के लिए उपलब्ध होते हैं.
उदाहरण के लिए, इनका इस्तेमाल, उपयोगकर्ता की बनाई गई बिल्ड ऐक्शन में खास टूलचेन पाथ को इंजेक्ट करने के लिए किया जा सकता है.
Bazel, पहले से तय वैरिएबल और कस्टम वैरिएबल, दोनों उपलब्ध कराता है. पहले से तय वैरिएबल सभी टारगेट के लिए उपलब्ध होते हैं. वहीं, कस्टम वैरिएबल, डिपेंडेंसी टारगेट में तय किए जाते हैं और सिर्फ़ उन टारगेट के लिए उपलब्ध होते हैं जो उन पर निर्भर होते हैं.
"Make" शब्द का इस्तेमाल इसलिए किया जाता है, क्योंकि इन वैरिएबल के सिंटैक्स और सेमेटिक्स को मूल रूप से GNU Make से मैच करने के लिए बनाया गया था.
इस्तेमाल करें
"'Make वैरिएबल' के बदले इस्तेमाल किए जा सकते हैं" के तौर पर मार्क किए गए एट्रिब्यूट, "Make" वैरिएबल FOO
का रेफ़रंस इस तरह दे सकते हैं:
my_attr = "prefix $(FOO) suffix"
दूसरे शब्दों में, $(FOO)
से मैच करने वाली कोई भी सबस्ट्रिंग, FOO
की वैल्यू तक बढ़ जाती है. अगर वह वैल्यू "bar"
है, तो आखिरी
स्ट्रिंग इस तरह दिखेगी:
my_attr = "prefix bar suffix"
अगर FOO
, इस्तेमाल करने वाले टारगेट के किसी ऐसे वैरिएबल से मेल नहीं खाता है जिसकी जानकारी है, तो Bazel गड़बड़ी के साथ फ़ेल हो जाता है.
"Make" वैरिएबल के नाम, अक्षर के बजाय चिह्न होते हैं. जैसे, @
. इनका रेफ़रंस देने के लिए, ब्रैकेट के बिना सिर्फ़ डॉलर के चिह्न का इस्तेमाल किया जा सकता है. उदाहरण के लिए:
my_attr = "prefix $@ suffix"
$
को स्ट्रिंग लिटरल के तौर पर लिखने (जैसे कि वैरिएबल को
बड़ा होने से रोकने के लिए), $$
.
Predefined variables
Predefined "Make" variables can be referenced by any attribute marked as "Subject to 'Make variable' substitution" on any target.
To see the list of these variables and their values for a given set of build options, run
bazel info --show_make_env [build options]
and look at the top output lines with capital letters.
See an example of predefined variables.
Toolchain option variables
COMPILATION_MODE
:fastbuild
,dbg
, oropt
. (more details)
Path variables
-
BINDIR
: The base of the generated binary tree for the target architecture.Note that a different tree may be used for programs that run during the build on the host architecture, to support cross-compiling.
If you want to run a tool from within a
genrule
, the recommended way to get its path is$(execpath toolname)
, where toolname must be listed in thegenrule
'stools
attribute. GENDIR
: The base of the generated code tree for the target architecture.
Machine architecture variables
-
TARGET_CPU
: The target architecture's CPU, e.g.k8
.
Predefined genrule variables
The following are specially available to genrule
's
cmd
attribute and are
generally important for making that attribute work.
See an example of predefined genrule variables.
OUTS
: Thegenrule
'souts
list. If you have only one output file, you can also use$@
.-
SRCS
: Thegenrule
'ssrcs
list (or more precisely: the path names of the files corresponding to labels in thesrcs
list). If you have only one source file, you can also use$<
. -
<
:SRCS
, if it is a single file. Else triggers a build error. -
@
:OUTS
, if it is a single file. Else triggers a build error. -
RULEDIR
: The output directory of the target, that is, the directory corresponding to the name of the package containing the target under thegenfiles
orbin
tree. For//my/pkg:my_genrule
this always ends inmy/pkg
, even if//my/pkg:my_genrule
's outputs are in subdirectories. -
@D
: The output directory. If outs has one entry, this expands to the directory containing that file. If it has multiple entries, this expands to the package's root directory in thegenfiles
tree, even if all output files are in the same subdirectory!Note: Use
RULEDIR
over@D
becauseRULEDIR
has simpler semantics and behaves the same way regardless of the number of output files.If the genrule needs to generate temporary intermediate files (perhaps as a result of using some other tool like a compiler), it should attempt to write them to
@D
(although/tmp
will also be writable) and remove them before finishing.Especially avoid writing to directories containing inputs. They may be on read-only filesystems. Even if not, doing so would trash the source tree.
Note: If the filenames corresponding to the input labels or the output
filenames contain spaces, '
, or other special characters (or your
genrule is part of a Starlark macro which downstream users may invoke on such
files), then $(SRCS)
and $(OUTS)
are not suitable
for interpolation into a command line, as they do not have the semantics that
"${@}"
would in Bash.
One workaround is to convert to a Bash array, with
mapfile SRCS <<< "$$(sed -e 's/ /\\n/g' <<'genrule_srcs_expansion' $(SRC) genrule_srcs_expansion )
लिखें. इसके बाद,$(SRCS)
की जगह बाद की कमांड लाइन में"$$\{SRCS[@]}"
का इस्तेमाल करें. इसके बजाय, Starlark नियम लिखना एक बेहतर विकल्प है.पहले से तय सोर्स/आउटपुट पाथ के वैरिएबल
पहले से तय वैरिएबल
execpath
,execpaths
,rootpath
,rootpaths
,location
, औरlocations
, लेबल पैरामीटर (जैसे कि$(execpath //foo:bar)
) लेते हैं और उस लेबल से दिखाए गए फ़ाइल पाथ को बदल देते हैं.सोर्स फ़ाइलों के लिए, यह आपके फ़ाइल फ़ोल्डर के रूट से जुड़ा पाथ है. नियमों के आउटपुट वाली फ़ाइलों के लिए, यह फ़ाइल का आउटपुट पाथ होता है. नीचे दी गई आउटपुट फ़ाइलों के बारे में जानकारी देखें.
-
execpath
: execroot के नीचे मौजूद उस पाथ को दिखाता है जहां Bazel, बिल्ड ऐक्शन चलाता है.ऊपर दिए गए उदाहरण में, Bazel आपके Workspace रूट में
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
है. इस अतिरिक्त प्रीफ़िक्स की मदद से, एक ही बिल्ड में मौजूद दो अलग-अलग सीपीयू के लिए एक ही टारगेट बनाया जा सकता है. ऐसा करने पर, एक-दूसरे से जुड़े नतीजे नहीं दिखते.इस वैरिएबल में पास किए गए लेबल में सिर्फ़ एक फ़ाइल होनी चाहिए. सोर्स फ़ाइलों को दिखाने वाले लेबल के लिए, यह अपने-आप सही हो जाता है. नियमों को दिखाने वाले लेबल के लिए, नियम को एक ही आउटपुट जनरेट करना चाहिए. अगर यह वैल्यू 'गलत है' पर सेट है या लेबल गलत है, तो गड़बड़ी की वजह से बिल्ड पूरा नहीं हो पाता.
-
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
की तुलना में, इसका फ़ायदा यह है कि यह सभी प्लैटफ़ॉर्म पर काम करता है. भले ही, runfiles डायरेक्ट्री उपलब्ध न हो.इसमें
execpath
की तरह ही "सिर्फ़ एक आउटपुट" की ज़रूरी शर्तें लागू होती हैं. -
location
:execpath
याrootpath
का एक समानार्थी शब्द. यह इस बात पर निर्भर करता है कि किस एट्रिब्यूट को बड़ा किया जा रहा है. यह Starlark से पहले के लेगसी वर्शन का व्यवहार है. इसका सुझाव तब तक नहीं दिया जाता, जब तक आपको यह पता न हो कि यह किसी खास नियम के लिए क्या करता है. ज़्यादा जानकारी के लिए, #2475 देखें.
execpaths
, rootpaths
, rlocationpaths
, और locations
, execpath
, rootpath
, rlocationpath
, और location
के बहुवचन के वैरिएंट हैं. ये एक से ज़्यादा आउटपुट देने वाले लेबल के साथ काम करते हैं. ऐसे में, हर आउटपुट को स्पेस से अलग करके लिस्ट किया जाता है. शून्य आउटपुट वाले नियम और गलत तरीके से बने लेबल की वजह से, बिल्ड करने में गड़बड़ियां होती हैं.
रेफ़र किए गए सभी लेबल, डेटा का इस्तेमाल करने वाले टारगेट की srcs
, आउटपुट फ़ाइलों या deps
में दिखने चाहिए. ऐसा न करने पर, बिल्ड पूरा नहीं होता. C++ टारगेट,
data
में लेबल का भी रेफ़रंस दे सकते हैं.
लेबल को कैननिकल फ़ॉर्मैट में होना ज़रूरी नहीं है: foo
, :foo
और //somepkg:foo
, सभी ठीक हैं.
कस्टम वैरिएबल
कस्टम "Make" वैरिएबल का रेफ़रंस, "'Make वैरिएबल' के बदले इस्तेमाल किए जाने के लिए" के तौर पर मार्क किए गए किसी भी एट्रिब्यूट से लिया जा सकता है. हालांकि, ऐसा सिर्फ़ उन टारगेट के लिए किया जा सकता है जो उन अन्य टारगेट पर निर्भर करते हैं जो इन वैरिएबल को तय करते हैं.
सबसे सही तरीका यह है कि सभी वैरिएबल को तब तक अपने हिसाब से इस्तेमाल किया जाना चाहिए, जब तक कि उन्हें बुनियादी बेज़ल के तौर पर शामिल करने की वाकई कोई वजह न हो. इससे Bazel को, वैरिएबल की आपूर्ति करने के लिए, संभावित तौर पर महंगी डिपेंडेंसी लोड करने की ज़रूरत नहीं पड़ती. ऐसा इसलिए, क्योंकि हो सकता है कि टारगेट को इन डिपेंडेंसी की ज़रूरत न हो.
C++ टूलचेन वैरिएबल
ये C++ टूलचेन के नियमों में बताए गए हैं और toolchains =
["@bazel_tools//tools/cpp:toolchain_type"]
को सेट करने वाले किसी भी नियम के लिए उपलब्ध हैं
java_binary
जैसे कुछ नियमों में, उनके नियम की परिभाषा में C++ टूलचेन को शामिल किया गया है. ये वैरिएबल,
C++ के लिए पहले से मौजूद नियम, "इस पर कंपाइलर चलाएं" से काफ़ी बेहतर हैं. *SAN, ThinLTO जैसे अलग-अलग कंपाइलेशन मोड के साथ-साथ, कई प्लैटफ़ॉर्म पर तेज़ी से चलने वाले टेस्ट के साथ-साथ, मॉड्यूल के साथ/बिना और ध्यान से ऑप्टिमाइज़ की गई बाइनरी के साथ काम करने के लिए, पहले से मौजूद नियमों को बहुत ज़्यादा ध्यान से बनाया गया है. इससे यह पक्का किया जा सकता है कि अंदरूनी तौर पर जनरेट की गई कई कार्रवाइयों में, सही इनपुट, आउटपुट, और कमांड-लाइन फ़्लैग सेट किए गए हों.
ये वैरिएबल एक फ़ॉलबैक तरीका है. भाषा के विशेषज्ञ इनका इस्तेमाल बहुत कम मामलों में करते हैं. अगर आपको इनका इस्तेमाल करना है, तो कृपया पहले Basel के डेवलपर से संपर्क करें.
ABI
: C++ ABI वर्शन.-
AR
: crosstool से "ar" कमांड. -
C_COMPILER
: C/C++ कंपाइलर आइडेंटिफ़ायर, जैसे किllvm
. -
CC
: C और C++ कंपाइलर कमांड.हमारा सुझाव है कि आप हमेशा
CC_FLAGS
के साथCC
का इस्तेमाल करें. अपने जोखिम पर ऐसा करने में विफल. CC_FLAGS
: C/C++ के लिए, फ़्लैग का एक छोटा सेट, ताकि genrules का इस्तेमाल किया जा सके. खास तौर पर, इसमें फ़्लैग होते हैं, ताकिCC
के एक से ज़्यादा आर्किटेक्चर के साथ काम करने पर, सही आर्किटेक्चर चुना जा सके.-
DUMPBIN
: Microsoft Visual Studio से Microsoft COFF बाइनरी फ़ाइल डंपर (dumpbin.exe). -
NM
: crosstool से "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 कोड को कंपाइल करने और पैकेज करने के लिए, अपस्ट्रीम टूल के मुकाबले ज़्यादा बेहतर तरीके इस्तेमाल करते हैं. जैसे, इंटरफ़ेस Jars, हेडर इंटरफ़ेस Jars, और ज़्यादा ऑप्टिमाइज़ की गई Jar पैकेजिंग और मर्ज करने की सुविधा.
ये वैरिएबल, फ़ॉलबैक मैकेनिज्म के तौर पर काम करते हैं. इनका इस्तेमाल, भाषा विशेषज्ञ बहुत ही कम मामलों में करते हैं. अगर आपको इनका इस्तेमाल करना है, तो कृपया पहले Bazel डेवलपर से संपर्क करें.
-
JAVA
: "java" कमांड (Java वर्चुअल मशीन). इससे बचें और जहां हो सके वहांjava_binary
नियम का इस्तेमाल करें. यह रिलेटिव पाथ हो सकता है. अगर आपकोjava
को शुरू करने से पहले डायरेक्ट्री बदलनी है, तो आपको बदलने से पहले, काम करने वाली डायरेक्ट्री को कैप्चर करना होगा. JAVABASE
: वह बेस डायरेक्ट्री, जिसमें Java की सुविधाएं शामिल हैं. यह रिलेटिव पाथ हो सकता है. इसमें "bin" सबडायरेक्ट्री होगी.
Starlark से तय किए गए वैरिएबल
नियम और टूलचेन लिखने वाले लोग,
TemplateVariableInfo
सेवा देने वाली कंपनी को लौटाकर, पूरी तरह से कस्टम वैरिएबल तय कर सकते हैं. toolchains
एट्रिब्यूट के ज़रिए इन पर निर्भर करने वाले सभी नियम, इनकी वैल्यू पढ़ सकते हैं: