नियम
- cc_बाइनरी
- cc_Import
- cc_library
- cc_proto_library
- fdo_preorder_hints
- fdo_profile
- proppel_optimize
- cc_test
- cc_toolchain
- cc_toolchain_suite
cc_बाइनरी
cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)
इंप्लिसिट आउटपुट टारगेट
name.stripped(सिर्फ़ तब अनुरोध किया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): बाइनरी का हटाया गया वर्शन.strip -gको बाइनरी पर चलाया जाता है, ताकि डीबग के चिह्नों को हटाया जा सके.--stripopt=-fooका इस्तेमाल करके, कमांड लाइन पर अतिरिक्त स्ट्रिप विकल्प भी उपलब्ध कराए जा सकते हैं. यह आउटपुट सिर्फ़ तब बनाया जाता है, जब इसका साफ़ तौर पर अनुरोध किया गया हो.name.dwp(सिर्फ़ तभी अनुरोध किया जा सकता है, जब साफ़ तौर पर अनुरोध किया गया हो): अगर फ़िशन चालू है: डीबग की जानकारी देने वाली पैकेज फ़ाइल, जो दूर से डिप्लॉय की गई बाइनरी को डीबग करने के लिए सही है. या: एक खाली फ़ाइल.
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
ये टारगेट |
srcs
|
सभी
सभी अगर किसी नियम का नाम
ऐसा
...और वे नियम जो वे फ़ाइलें बनाते हैं. अलग-अलग एक्सटेंशन, gcc कन्वेंशन के अनुसार अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं. |
additional_linker_inputs
|
उदाहरण के लिए, यहां कंपाइल की गई Windows .res फ़ाइलें, बाइनरी टारगेट में एम्बेड की जा सकती हैं. |
copts
|
बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को
अगर पैकेज सुविधा
|
defines
|
-D से पहले जोड़ा जाता है. इसके बाद, इस टारगेट को कंपाइल करने वाली कमांड लाइन में जोड़ा जाता है.
साथ ही, इसमें हर एक नियम उस पर लागू होता है. सावधान रहें, क्योंकि इसका बहुत दूर तक असर हो सकता है. अगर समझ में न आए, तो local_defines में वैल्यू डालें.
|
includes
|
"वैरिएबल और कोट बनाएं विकल्प के अधीन.
हर स्ट्रिंग को कंपाइल को सैंडबॉक्स या hr में जोड़ा जाना चाहिए, नहीं तो कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) पर निर्भर नियमों पर उपलब्ध नहीं होंगे. |
linkopts
|
LINKOPTS में जोड़ा जाता है.
यह माना जाता है कि |
linkshared
|
linkshared=True शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है.
इस फ़्लैग की मौजूदगी का मतलब है कि लिंक करने पर
अगर आप |
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में जोड़ें. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह चालू होता है और यह बाइनरी या टेस्ट होता है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को एक्ज़ीक्यूटेबल के लिए तीन तरह से लिंक करने के तरीके हैं:
अगर किसी
अगर |
local_defines
|
-D से पहले जोड़ा जाता है. इसके बाद, इस टारगेट के लिए कंपाइल कमांड लाइन जोड़ी जाती है, लेकिन इससे जुड़ी चीज़ों पर नहीं.
|
malloc
|
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
nocopts
|
COPTS को
COPTS से हटा दिया जाएगा. इसमें, नियम के कोड एट्रिब्यूट में साफ़ तौर पर दी गई वैल्यू शामिल हैं.
इस एट्रिब्यूट की ज़रूरत कभी-कभी ही होनी चाहिए.
|
stamp
|
स्टैंप वाली बाइनरी को तब तक नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी नहीं बदलती. |
win_def_file
|
इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब Windows टारगेट प्लैटफ़ॉर्म हो. शेयर की गई लाइब्रेरी को लिंक करते समय, सिंबल के एक्सपोर्ट का इस्तेमाल किया जा सकता है. |
cc_Import
cc_import(name, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)
cc_import नियमों की मदद से, उपयोगकर्ता कंपाइल की गई C/C++ लाइब्रेरी इंपोर्ट कर सकते हैं.
आम तौर पर, इन मामलों का इस्तेमाल किया जाता है:
1. स्टैटिक लाइब्रेरी को लिंक करना
cc_import( name = "mylib", hdrs = ["mylib.h"], static_library = "libmylib.a", # If alwayslink is turned on, # libmylib.a will be forcely linked into any binary that depends on it. # alwayslink = 1, )2. शेयर की गई लाइब्रेरी को लिंक करना (Unix)
cc_import( name = "mylib", hdrs = ["mylib.h"], shared_library = "libmylib.so", )3. शेयर की गई लाइब्रेरी को इंटरफ़ेस लाइब्रेरी से लिंक करना (Windows)
cc_import( name = "mylib", hdrs = ["mylib.h"], # mylib.lib is a import library for mylib.dll which will be passed to linker interface_library = "mylib.lib", # mylib.dll will be available for runtime shared_library = "mylib.dll", )4. शेयर की गई लाइब्रेरी को
system_provided=True (Windows) से लिंक करना
cc_import( name = "mylib", hdrs = ["mylib.h"], # mylib.lib is an import library for mylib.dll which will be passed to linker interface_library = "mylib.lib", # mylib.dll is provided by system environment, for example it can be found in PATH. # This indicates that Bazel is not responsible for making mylib.dll available. system_provided = 1, )5. स्टैटिक या शेयर की गई लाइब्रेरी से लिंक करना
Unix पर:
cc_import( name = "mylib", hdrs = ["mylib.h"], static_library = "libmylib.a", shared_library = "libmylib.so", ) # first will link to libmylib.a cc_binary( name = "first", srcs = ["first.cc"], deps = [":mylib"], linkstatic = 1, # default value ) # second will link to libmylib.so cc_binary( name = "second", srcs = ["second.cc"], deps = [":mylib"], linkstatic = 0, )Windows पर:
cc_import( name = "mylib", hdrs = ["mylib.h"], static_library = "libmylib.lib", # A normal static library interface_library = "mylib.lib", # An import library for mylib.dll shared_library = "mylib.dll", ) # first will link to libmylib.lib cc_binary( name = "first", srcs = ["first.cc"], deps = [":mylib"], linkstatic = 1, # default value ) # second will link to mylib.dll through mylib.lib cc_binary( name = "second", srcs = ["second.cc"], deps = [":mylib"], linkstatic = 0, )
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
hdrs
|
|
alwayslink
|
अगर Windows पर हमेशा लिंक करने की सुविधा बनाम Windows 2017 काम नहीं करती है, तो ऐसा पहले से मालूम समस्या की वजह से हो सकता है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें. |
interface_library
|
इन फ़ाइल टाइप की अनुमति है:
|
shared_library
|
इन फ़ाइल टाइप को अनुमति दी गई है:
|
static_library
|
इन फ़ाइल टाइप को अनुमति दी गई है:
|
system_provided
|
interface_library बताना ज़रूरी है और
shared_library खाली होना चाहिए.
|
cc_library
cc_library(name, deps, srcs, data, hdrs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)
हेडर शामिल करने की जांच
बिल्ड में इस्तेमाल की जाने वाली सभी हेडर फ़ाइलें, cc_* के hdrs या
srcs नियमों में बताई जानी चाहिए. यह लागू किया गया है.
cc_library नियमों के लिए, hdrs के हेडर में लाइब्रेरी का सार्वजनिक इंटरफ़ेस शामिल होता है. साथ ही, इसे hdrs की फ़ाइलों और खुद लाइब्रेरी में मौजूद hdrs और srcs के उन नियमों से भी शामिल किया जा सकता है जो लाइब्रेरी को deps में शामिल करते हैं.
srcs में मौजूद हेडर, सिर्फ़ hdrs और srcs की फ़ाइलों में सीधे तौर पर शामिल किए जाने चाहिए. यह तय करते समय कि हेडर को hdrs या srcs में रखा जाए या नहीं, आपको यह पूछना चाहिए कि इस लाइब्रेरी के उपभोक्ताओं को
इसे सीधे शामिल करना है या नहीं. यह करीब-करीब वही फ़ैसला है जो प्रोग्रामिंग भाषाओं में public और private के दिखने के बीच है.
cc_binary और cc_test नियमों में एक्सपोर्ट किया गया कोई इंटरफ़ेस नहीं है. इसलिए, इनके पास hdrs एट्रिब्यूट भी नहीं है. बाइनरी या टेस्ट से जुड़े सभी हेडर, srcs में मौजूद होने चाहिए.
इन नियमों को दिखाने के लिए, नीचे दिया गया उदाहरण देखें.
cc_binary(
name = "foo",
srcs = [
"foo.cc",
"foo.h",
],
deps = [":bar"],
)
cc_library(
name = "bar",
srcs = [
"bar.cc",
"bar-impl.h",
],
hdrs = ["bar.h"],
deps = [":baz"],
)
cc_library(
name = "baz",
srcs = [
"baz.cc",
"baz-impl.h",
],
hdrs = ["baz.h"],
)
इस उदाहरण में, सीधे तौर पर शामिल किए जाने की अनुमति नीचे दी गई टेबल में दी गई है. उदाहरण के लिए, foo.cc को सीधे foo.h और bar.h को शामिल करने की अनुमति है, लेकिन baz.h को नहीं.
| फ़ाइल शामिल है | शामिल किए जाने की अनुमति है |
|---|---|
| फ़ू | Bar.h |
| foo.cc | foo.h बार |
| Bar.h | Bar-impl.h baz.h |
| Bar-impl.h | Bar.h baz.h |
| Bar.cc | Bar.h Bar-impl.h baz.h |
| CANNOT TRANSLATE | baz-impl.h |
| baz-impl.h | CANNOT TRANSLATE |
| baz.cc | baz.h baz-impl.h |
शामिल किए जाने की जांच से जुड़े नियम, सिर्फ़ सीधे तौर पर शामिल किए जाने पर लागू होते हैं. ऊपर दिए गए उदाहरण में, foo.cc को bar.h को शामिल करने की अनुमति है, जिसमें baz.h शामिल हो सकता है, जिसके बदले में baz-impl.h शामिल किया जा सकता है. तकनीकी रूप से, .cc फ़ाइल के संग्रह में, ट्रांज़िशनिव deps क्लोज़ में hdrs की srcs या
srcs में मौजूद किसी भी हेडर फ़ाइल को, समय-समय पर शामिल किया जा सकता है. इस मामले में, कंपाइलर foo.cc को कंपाइल करते समय baz.h और baz-impl.h पढ़ सकता है, लेकिन foo.cc में #include "baz.h" नहीं होना चाहिए. ऐसा करने के लिए, baz को foo के
deps में जोड़ना ज़रूरी है.
फ़िलहाल, Bazel को सीधे तौर पर होने वाले और ट्रांज़िट समय में शामिल किए जाने के बीच अंतर नहीं किया जा सकता. इसलिए, वह गड़बड़ी के ऐसे मामलों का पता नहीं लगा सकता जहां किसी फ़ाइल में सीधे तौर पर ऐसा हेडर शामिल हो और जिसे ट्रांज़िट समय में ही शामिल किया जा सकता हो. उदाहरण के लिए, अगर बेज़ल foo.cc के ऊपर के उदाहरण में सीधे baz.h शामिल हैं, तो वे शिकायत नहीं करेंगे. यह गैरकानूनी होगा, क्योंकि foo सीधे तौर पर baz पर निर्भर नहीं है. फ़िलहाल, उस मामले में कोई गड़बड़ी नहीं दिखाई गई है. हालांकि, आने वाले समय में इस तरह की गड़बड़ी की जांच की जा सकती है.
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
ये टारगेट |
srcs
|
सभी
सभी अगर किसी नियम का नाम
ऐसा
...और वे नियम जो वे फ़ाइलें बनाते हैं. अलग-अलग एक्सटेंशन, gcc कन्वेंशन के अनुसार अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं. |
hdrs
|
हेडर फ़ाइलों के लिए, यह वही जगह होनी चाहिए जो लाइब्रेरी के इंटरफ़ेस की जानकारी देती हो. ये हेडर, सोर्स के तहत या नियम से जुड़े नियमों में शामिल करने के लिए
उपलब्ध कराए जाएंगे.
इस लाइब्रेरी के क्लाइंट के ज़रिए शामिल किए जाने वाले हेडर को |
alwayslink
|
srcs में दी गई फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों से लिंक की जाएगी. भले ही, कुछ फ़ाइलों में बाइनरी से जुड़ी कोई जानकारी न हो.
यह तब मददगार होता है, जब बाइनरी में आपके कोड को साफ़ तौर पर कॉल नहीं किया जाता है. उदाहरण के लिए, अगर आपके कोड को किसी सेवा से मिले कुछ कॉलबैक पाने के लिए रजिस्टर किया गया है.
अगर Windows पर हमेशा लिंक करने की सुविधा बनाम Windows 2017 काम नहीं करती है, तो ऐसा पहले से मालूम समस्या की वजह से हो सकता है. कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें. |
copts
|
बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को
अगर पैकेज सुविधा
|
defines
|
-D से पहले जोड़ा जाता है. इसके बाद, इस टारगेट को कंपाइल करने वाली कमांड लाइन में जोड़ा जाता है.
साथ ही, इसमें हर एक नियम उस पर लागू होता है. सावधान रहें, क्योंकि इसका बहुत दूर तक असर हो सकता है. अगर समझ में न आए, तो local_defines में वैल्यू डालें.
|
implementation_deps
|
deps से अलग, हेडर और इनमें इन लाइब्रेरी के पाथ शामिल होते हैं. साथ ही, इन सभी ट्रांज़िटिव पाथ का इस्तेमाल, सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है, न कि इस लाइब्रेरी पर निर्भर करने वाले लाइब्रेरी पर. implementation_deps के साथ तय की गई लाइब्रेरी अब भी बाइनरी टारगेट में लिंक की गई हैं. ये टारगेट, इस लाइब्रेरी से तय होते हैं.
अभी इस सुविधा का इस्तेमाल, cc_library (सीमित संख्या) तक सीमित है और फ़्लैग |
include_prefix
|
अगर इस नियम को सेट किया जाता है, तो इस नियम के इस प्रीफ़िक्स को जोड़ने से पहले, |
includes
|
"वैरिएबल और कोट बनाएं विकल्प के अधीन.
हर स्ट्रिंग को कंपाइल को सैंडबॉक्स या hr में जोड़ा जाना चाहिए, नहीं तो कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) पर निर्भर नियमों पर उपलब्ध नहीं होंगे. |
linkopts
|
LINKOPTS में जोड़ा जाता है.
यह माना जाता है कि |
linkstamp
|
base पैकेज में होनी चाहिए.
|
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में जोड़ें. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह चालू होता है और यह बाइनरी या टेस्ट होता है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को एक्ज़ीक्यूटेबल के लिए तीन तरह से लिंक करने के तरीके हैं:
अगर किसी
अगर |
local_defines
|
-D से पहले जोड़ा जाता है. इसके बाद, इस टारगेट के लिए कंपाइल कमांड लाइन जोड़ी जाती है, लेकिन इससे जुड़ी चीज़ों पर नहीं.
|
nocopts
|
COPTS को
COPTS से हटा दिया जाएगा. इसमें, नियम के कोड एट्रिब्यूट में साफ़ तौर पर दी गई वैल्यू शामिल हैं.
इस एट्रिब्यूट की ज़रूरत कभी-कभी ही होनी चाहिए.
|
strip_include_prefix
|
सेट होने पर, इस नियम के अगर यह एक रिलेटिव पाथ है, तो इसे पैकेज-रिलेटिव के तौर पर लिया जाता है. अगर यह सटीक है, तो इसे रिपॉज़िटरी-रिलेटिव पाथ के तौर पर समझा जाता है. इस प्रीफ़िक्स को हटाने के बाद, |
textual_hdrs
|
यह वह जगह है जहां हेडर फ़ाइलों का एलान किया जा सकता है और उन्हें इकट्ठा नहीं किया जा सकता. इसका मतलब है कि मान्य कोड बनाने के लिए, उन्हें दूसरी सोर्स फ़ाइलों में टेक्स्ट के तौर पर शामिल करना होगा. |
win_def_file
|
इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब Windows टारगेट प्लैटफ़ॉर्म हो. शेयर की गई लाइब्रेरी को लिंक करते समय, सिंबल के एक्सपोर्ट का इस्तेमाल किया जा सकता है. |
cc_proto_library
cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
cc_proto_library, .proto फ़ाइलों से C++ कोड जनरेट करता है.
deps में proto_library
नियम होने चाहिए.
उदाहरण:
cc_library(
name = "lib",
deps = [":foo_cc_proto"],
)
cc_proto_library(
name = "foo_cc_proto",
deps = [":foo_proto"],
)
proto_library(
name = "foo_proto",
)
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
proto_library नियमों की सूची, जिनके लिए C++ कोड जनरेट किया जाना है.
|
CANNOT TRANSLATE
fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)
एफ़डीओ दिखाने के सुझाव वाली प्रोफ़ाइल का प्रतिनिधित्व करता है. यह प्रोफ़ाइल, फ़ाइल फ़ोल्डर में या किसी खास ऐब्सलूट पाथ पर मौजूद होती है. उदाहरण:
fdo_prefetch_hints(
name = "hints",
profile = "//path/to/hints:profile.afdo",
)
fdo_profile(
name = "hints_abs",
absolute_path_profile = "/absolute/path/profile.afdo",
)
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
profile
|
|
fdo_profile
fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)
ऐसी FDO प्रोफ़ाइल के बारे में जानकारी देता है जो या तो फ़ाइल फ़ोल्डर में हो या बताए गए पूरे पाथ पर हो. उदाहरण:
fdo_profile(
name = "fdo",
profile = "//path/to/fdo:profile.zip",
)
fdo_profile(
name = "fdo_abs",
absolute_path_profile = "/absolute/path/profile.zip",
)
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
absolute_path_profile
|
|
profile
|
|
proto_profile
|
|
परफ़ॉर्मर_ऑप्टिमाइज़
propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
फ़ाइल फ़ोल्डर में Propler ऑप्टिमाइज़ेशन प्रोफ़ाइल को दिखाता है. उदाहरण:
propeller_optimize(
name = "layout",
cc_profile = "//path:cc_profile.txt",
ld_profile = "//path:ld_profile.txt"
)
propeller_optimize(
name = "layout_absolute",
absolute_cc_profile = "/absolute/cc_profile.txt",
absolute_ld_profile = "/absolute/ld_profile.txt"
)
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
ld_profile
|
|
cc_test
cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
ये टारगेट |
srcs
|
सभी
सभी अगर किसी नियम का नाम
ऐसा
...और वे नियम जो वे फ़ाइलें बनाते हैं. अलग-अलग एक्सटेंशन, gcc कन्वेंशन के अनुसार अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं. |
additional_linker_inputs
|
उदाहरण के लिए, यहां कंपाइल की गई Windows .res फ़ाइलें, बाइनरी टारगेट में एम्बेड की जा सकती हैं. |
copts
|
बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को
अगर पैकेज सुविधा
|
defines
|
-D से पहले जोड़ा जाता है. इसके बाद, इस टारगेट को कंपाइल करने वाली कमांड लाइन में जोड़ा जाता है.
साथ ही, इसमें हर एक नियम उस पर लागू होता है. सावधान रहें, क्योंकि इसका बहुत दूर तक असर हो सकता है. अगर समझ में न आए, तो local_defines में वैल्यू डालें.
|
includes
|
"वैरिएबल और कोट बनाएं विकल्प के अधीन.
हर स्ट्रिंग को कंपाइल को सैंडबॉक्स या hr में जोड़ा जाना चाहिए, नहीं तो कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) पर निर्भर नियमों पर उपलब्ध नहीं होंगे. |
linkopts
|
LINKOPTS में जोड़ा जाता है.
यह माना जाता है कि |
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में जोड़ें. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह चालू होता है और यह बाइनरी या टेस्ट होता है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को एक्ज़ीक्यूटेबल के लिए तीन तरह से लिंक करने के तरीके हैं:
अगर किसी
अगर |
local_defines
|
-D से पहले जोड़ा जाता है. इसके बाद, इस टारगेट के लिए कंपाइल कमांड लाइन जोड़ी जाती है, लेकिन इससे जुड़ी चीज़ों पर नहीं.
|
malloc
|
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
nocopts
|
COPTS को
COPTS से हटा दिया जाएगा. इसमें, नियम के कोड एट्रिब्यूट में साफ़ तौर पर दी गई वैल्यू शामिल हैं.
इस एट्रिब्यूट की ज़रूरत कभी-कभी ही होनी चाहिए.
|
stamp
|
स्टैंप वाली बाइनरी को तब तक नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी नहीं बदलती. |
win_def_file
|
इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब Windows टारगेट प्लैटफ़ॉर्म हो. शेयर की गई लाइब्रेरी को लिंक करते समय, सिंबल के एक्सपोर्ट का इस्तेमाल किया जा सकता है. |
cc_toolchain
cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler, compiler_files, compiler_files_without_includes, coverage_files, cpu, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)
एक C++ टूलचेन दिखाता है.
यह नियम इनके लिए ज़िम्मेदार है:
-
C++ से जुड़ी कार्रवाइयों के लिए, ज़रूरी आर्टफ़ैक्ट इकट्ठा करना.
all_files,compiler_files,linker_filesया_filesसे खत्म होने वाले दूसरे एट्रिब्यूट जैसे एट्रिब्यूट की मदद से, ऐसा किया जाता है. ये आम तौर पर ऐसे सभी फ़ाइल ग्रुप होते हैं जो सभी ज़रूरी फ़ाइलों को इकट्ठा करते हैं. -
C++ कार्रवाइयों के लिए सही कमांड लाइन जनरेट कर रहे हैं. ऐसा करने के लिए,
CcToolchainConfigInfoकी सेवा देने वाली कंपनी का इस्तेमाल किया जाता है. इसके बारे में ज़्यादा जानकारी नीचे दी गई है.
C++ टूलचेन को कॉन्फ़िगर करने के लिए, toolchain_config एट्रिब्यूट का इस्तेमाल करें.
C++ टूलचेन कॉन्फ़िगरेशन और टूलचेन चुनने से जुड़े दस्तावेज़ के लिए, यह
पेज
भी देखें.
tags = ["manual"] का इस्तेमाल करके, bazel build //... को शुरू करते समय टूल चेन को बनने से रोकें और उन्हें ज़रूरत के हिसाब से कॉन्फ़िगर न करें
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
all_files
|
all_files आर्टफ़ैक्ट देने वाले दूसरे सभी एट्रिब्यूट का सुपरसेट है (उदाहरण के लिए, लिंक स्टैंप कंपाइल को कंपाइल करने और लिंक करने, दोनों की ज़रूरत होती है. इसलिए, इसमें all_files लग सकते हैं).
|
ar_files
|
संग्रहित की गई कार्रवाइयों के लिए, cc_toolchain की सभी कलाकृतियों का संग्रह. |
as_files
|
असेंबली की कार्रवाइयों के लिए ज़रूरी cc_toolchain की सभी कलाकृतियों का संग्रह. |
compiler
|
toolchain_identifier एट्रिब्यूट का इस्तेमाल करें.
CROSSटूल पर स्टारलार्क
के माइग्रेशन के बाद
यह नूप होगा और
#7075 से हटा दिया जाएगा.
सेट होने पर, इसका इस्तेमाल क्रॉसटूल_कॉन्फ़िगरेशन.टूलचेन चुनने के लिए किया जाएगा. इसे -- cpu Bazel के विकल्प की जगह प्राथमिकता दी जाएगी. |
compiler_files
|
|
compiler_files_without_includes
|
|
coverage_files
|
|
cpu
|
सेट होने पर, इसका इस्तेमाल क्रॉसटूल_कॉन्फ़िगरेशन.टूलचेन चुनने के लिए किया जाएगा. इसे -- cpu Bazel के विकल्प की जगह प्राथमिकता दी जाएगी. |
dwp_files
|
|
dynamic_runtime_lib
|
इसका इस्तेमाल तब किया जाएगा, जब ##39;static_link_cpp_runtimes' सुविधा चालू होगी और हम डिपेंडेंसी को डाइनैमिक तौर पर लिंक करेंगे. |
exec_transition_for_inputs
|
|
libc_top
|
|
linker_files
|
|
module_map
|
|
objcopy_files
|
|
static_runtime_lib
|
इसका इस्तेमाल तब किया जाएगा, जब ##39;static_link_cpp_runtimes' सुविधा चालू होगी और हम डिपेंडेंसी को स्टैटिक रूप से लिंक करेंगे. |
strip_files
|
|
supports_header_parsing
|
|
supports_param_files
|
|
toolchain_config
|
cc_toolchain_config_info को उपलब्ध कराने वाले नियम का लेबल.
|
toolchain_identifier
|
जब तक समस्या #5380 को ठीक नहीं कर लिया जाता, तब तक |
cc_toolchain_suite
cc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
C++ टूलचेन के संग्रह का प्रतिनिधित्व करता है.
यह नियम इनके लिए ज़िम्मेदार है:
- काम के सभी C++ टूलचेन इकट्ठा करना.
-
--cpuसे लेकर--compilerतक के विकल्पों के हिसाब से, एक टूल चेन को चुना गया. इसके लिए, उन्होंने बैज़ेल में पास किया.
C++ टूलचेन कॉन्फ़िगरेशन और टूलचेन चुनने से जुड़े दस्तावेज़ के लिए, यह पेज भी देखें.
तर्क
| विशेषताएं | |
|---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
toolchains
|
cc_toolchain लेबल की स्ट्रिंग. "<cpu>" का इस्तेमाल तभी किया जाएगा जब --cpu
को बैज़ल को पास किया गया हो और "<cpu>|<compiler>" का इस्तेमाल तब किया जाएगा जब --cpu और --compiler दोनों हों उदाहरण:
cc_toolchain_suite(
name = "toolchain",
toolchains = {
"piii|gcc": ":my_cc_toolchain_for_piii_using_gcc",
"piii": ":my_cc_toolchain_for_piii_using_default_compiler",
},
)
|