नियम
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- fdo_prefetch_hints
- fdo_profile
- propeller_optimize
- cc_test
- cc_toolchain
- cc_toolchain_suite
cc_binary
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
|
सभी
सभी अगर किसी नियम का नाम
...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताता है. अलग-अलग एक्सटेंशन, जीसीसी कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं. |
additional_linker_inputs
|
उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलें यहां दी जा सकती हैं, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके. |
copts
|
बाइनरी टारगेट को इकट्ठा करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में
अगर पैकेज, सुविधा
|
defines
|
-D से पहले जोड़ा जाता है. साथ ही, इस टारगेट के साथ-साथ, इस पर निर्भर हर नियम के साथ कंपाइल कमांड लाइन में जोड़ा जाता है. सावधानी बरतें, क्योंकि इसके बहुत बुरे नतीजे हो सकते हैं. अगर आपको नहीं पता कि एमपीएन सही है या नहीं, तो local_defines में वैल्यू जोड़ें.
|
includes
|
यह विकल्प "वैरिएबल बनाएं" पर निर्भर करता है.
हर स्ट्रिंग को हेडर को srcs या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने के दौरान, वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे. |
linkopts
|
LINKOPTS में जोड़ा जाता है.
इस सूची का हर वह एलिमेंट जो |
linkshared
|
linkshared=True शामिल करें. डिफ़ॉल्ट रूप से,
यह विकल्प बंद रहता है.
इस फ़्लैग के मौजूद होने का मतलब है कि
अगर |
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह नीति चालू है और यह बाइनरी या टेस्ट है, तो इस विकल्प की मदद से बिल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए एक्ज़ीक्यूटेबल लिंक को लिंक करने के तीन अलग-अलग तरीके हैं:
अगर
|
local_defines
|
-D के साथ जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है,
लेकिन डिपेंडेंट के साथ नहीं.
|
malloc
|
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
nocopts
|
COPTS (इसमें नियम के 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 पर VS 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
और srcs
में मौजूद फ़ाइलों के साथ-साथ hdrs
में मौजूद फ़ाइलों और deps
में लाइब्रेरी को शामिल करने वाले cc_*
नियमों में से srcs
फ़ाइलों से सीधे तौर पर शामिल किया जा सकता है.
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
को नहीं.
फ़ाइल शामिल है | शामिल करने की अनुमति है |
---|---|
foo.h | bar.h |
foo.cc | foo.h bar.h |
bar.h | Bar-impl.h baz.h |
बार-impl.h | बार.h baz.h |
bar.cc | bar.h bar-impl.h baz.h |
baz.h | baz-impl.h |
baz-impl.h | baz.h |
baz.cc | baz.h baz-impl.h |
शामिल करने की जांच करने के नियम, सिर्फ़ सीधे तौर पर पेज शामिल करने पर लागू होते हैं. ऊपर दिए गए उदाहरण में, foo.cc
में bar.h
को शामिल करने की अनुमति है. इसमें baz.h
शामिल हो सकता है और फिर, baz-impl.h
को भी शामिल किया जा सकता है. तकनीकी रूप से,
.cc
फ़ाइल के कंपाइलेशन में
hdrs
या srcs
में मौजूद कोई भी हेडर फ़ाइल, किसी भी cc_library
में
अस्थायी रूप से शामिल हो सकती है.deps
इस मामले में, foo.cc
को कंपाइल करते समय, कंपाइलर baz.h
और baz-impl.h
पढ़ सकता है, लेकिन foo.cc
में #include "baz.h"
नहीं होना चाहिए. इसकी अनुमति के लिए, baz
को foo
के deps
में जोड़ना ज़रूरी है.
फ़िलहाल, Bazel, सीधे तौर पर और ट्रांज़िट स्थिति वाले पेजों में अंतर नहीं कर सकता. इसलिए, यह गड़बड़ी के उन मामलों का पता नहीं लगा सकता जिनमें फ़ाइल में गैर-कानूनी तरीके से ऐसा हेडर शामिल हो जिसे सिर्फ़ ट्रांज़िट के दौरान शामिल करने की अनुमति हो. उदाहरण के लिए, अगर ऊपर दिए गए foo.cc
उदाहरण में सीधे तौर पर baz.h
शामिल है, तो Bazel शिकायत नहीं करेगा. यह गैर-कानूनी होगा, क्योंकि foo
सीधे तौर पर baz
पर निर्भर नहीं है. फ़िलहाल, ऐसे मामले में कोई गड़बड़ी नहीं होती. हालांकि, आने वाले समय में गड़बड़ी की जांच करने की सुविधा जोड़ी जा सकती है.
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
deps
|
ये |
srcs
|
सभी
सभी अगर किसी नियम का नाम
...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताता है. अलग-अलग एक्सटेंशन, जीसीसी कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं. |
hdrs
|
लाइब्रेरी के इंटरफ़ेस के बारे में बताने वाली हेडर फ़ाइलों का एलान करने के लिए, यह जगह इस्तेमाल करने का सबसे सही तरीका है. ये हेडर,
इस नियम में शामिल स्रोतों या अन्य नियमों में शामिल करने के लिए उपलब्ध कराए जाएंगे.
हालांकि, जो हेडर इस लाइब्रेरी के क्लाइंट से शामिल नहीं किए जाते उन्हें |
alwayslink
|
srcs में शामिल फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों से लिंक हो जाएगी. भले ही, कुछ में बाइनरी से रेफ़र किया गया कोई चिह्न न हो.
अगर आपके कोड को बाइनरी में साफ़ तौर पर कोड से कॉल नहीं किया गया है, तो ऐसा करना फ़ायदेमंद होता है. उदाहरण के लिए, अगर आपका कोड, किसी सेवा से मिलने वाले कॉलबैक को पाने के लिए रजिस्टर होता है.
अगर हमेशा लिंक, Windows पर VS 2017 के साथ काम नहीं करता है और ऐसा पहले से मालूम समस्या की वजह से है, तो कृपया अपने VS 2017 को नए वर्शन में अपग्रेड करें. |
copts
|
बाइनरी टारगेट को इकट्ठा करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में
अगर पैकेज, सुविधा
|
defines
|
-D से पहले जोड़ा जाता है. साथ ही, इस टारगेट के साथ-साथ, इस पर निर्भर हर नियम के साथ कंपाइल कमांड लाइन में जोड़ा जाता है. सावधानी बरतें, क्योंकि इसके बहुत बुरे नतीजे हो सकते हैं. अगर आपको नहीं पता कि एमपीएन सही है या नहीं, तो local_defines में वैल्यू जोड़ें.
|
implementation_deps
|
deps के उलट, इन लाइब्रेरी के हेडर और शामिल करने वाले पाथ (और इनके सभी ट्रांज़िटिव डिप) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है. इस लाइब्रेरी पर निर्भर लाइब्रेरी का इस्तेमाल नहीं किया जाता. implementation_deps के साथ तय की गई लाइब्रेरी, अब भी इस लाइब्रेरी पर निर्भर
बाइनरी टारगेट में लिंक हैं.
फ़िलहाल, इसका इस्तेमाल cc_libraries तक सीमित है. साथ ही, इसे |
include_prefix
|
अगर यह सेट हो जाता है, तो इस नियम के इस प्रीफ़िक्स को जोड़ने से पहले, |
includes
|
यह विकल्प "वैरिएबल बनाएं" पर निर्भर करता है.
हर स्ट्रिंग को हेडर को srcs या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने के दौरान, वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे. |
linkopts
|
LINKOPTS में जोड़ा जाता है.
इस सूची का हर वह एलिमेंट जो |
linkstamp
|
base पैकेज में होनी चाहिए.
|
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह नीति चालू है और यह बाइनरी या टेस्ट है, तो इस विकल्प की मदद से बिल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए एक्ज़ीक्यूटेबल लिंक को लिंक करने के तीन अलग-अलग तरीके हैं:
अगर
|
local_defines
|
-D के साथ जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है,
लेकिन डिपेंडेंट के साथ नहीं.
|
nocopts
|
COPTS (इसमें नियम के 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++ कोड जनरेट करना है.
|
fdo_prefetch_hints
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_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
propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
फ़ाइल फ़ोल्डर में प्रोपेलर ऑप्टिमाइज़ेशन प्रोफ़ाइल के बारे में बताता है. उदाहरण:
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
|
सभी
सभी अगर किसी नियम का नाम
...और उन फ़ाइलों को बनाने वाले किसी भी नियम के बारे में बताता है. अलग-अलग एक्सटेंशन, जीसीसी कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं. |
additional_linker_inputs
|
उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलें यहां दी जा सकती हैं, ताकि उन्हें बाइनरी टारगेट में एम्बेड किया जा सके. |
copts
|
बाइनरी टारगेट को इकट्ठा करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में
अगर पैकेज, सुविधा
|
defines
|
-D से पहले जोड़ा जाता है. साथ ही, इस टारगेट के साथ-साथ, इस पर निर्भर हर नियम के साथ कंपाइल कमांड लाइन में जोड़ा जाता है. सावधानी बरतें, क्योंकि इसके बहुत बुरे नतीजे हो सकते हैं. अगर आपको नहीं पता कि एमपीएन सही है या नहीं, तो local_defines में वैल्यू जोड़ें.
|
includes
|
यह विकल्प "वैरिएबल बनाएं" पर निर्भर करता है.
हर स्ट्रिंग को हेडर को srcs या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन सैंडबॉक्स (डिफ़ॉल्ट) होने के दौरान, वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे. |
linkopts
|
LINKOPTS में जोड़ा जाता है.
इस सूची का हर वह एलिमेंट जो |
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में लिंक करें. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह नीति चालू है और यह बाइनरी या टेस्ट है, तो इस विकल्प की मदद से बिल्ड टूल को उपयोगकर्ता लाइब्रेरी के लिए एक्ज़ीक्यूटेबल लिंक को लिंक करने के तीन अलग-अलग तरीके हैं:
अगर
|
local_defines
|
-D के साथ जोड़ा जाता है. साथ ही, इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है,
लेकिन डिपेंडेंट के साथ नहीं.
|
malloc
|
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
nocopts
|
COPTS (इसमें नियम के 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 एट्रिब्यूट का इस्तेमाल करें.
Starlark पर CROSSTOOL के माइग्रेट होने
के बाद, यह कार्रवाई नहीं की जाएगी. इसे
#7075 तक हटा दिया जाएगा.
सेट होने पर, इसका इस्तेमाल Crosstool_config.toolchain चुनने के लिए किया जाएगा. इसे --cpu Bazel विकल्प के मुकाबले प्राथमिकता दी जाएगी. |
compiler_files
|
|
compiler_files_without_includes
|
|
coverage_files
|
|
cpu
|
सेट होने पर, इसका इस्तेमाल Crosstool_config.toolchain चुनने के लिए किया जाएगा. इसे --cpu Bazel विकल्प के मुकाबले प्राथमिकता दी जाएगी. |
dwp_files
|
|
dynamic_runtime_lib
|
इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू होगी और हम डिपेंडेंसी को डाइनैमिक तौर पर लिंक कर रहे होंगे. |
exec_transition_for_inputs
|
|
libc_top
|
|
linker_files
|
|
module_map
|
|
objcopy_files
|
|
static_runtime_lib
|
इसका इस्तेमाल तब किया जाएगा, जब '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
के आधार पर एक टूलचेन चुनकर, Bazel को भेजे गए विकल्प.
C++ टूलचेन कॉन्फ़िगरेशन और टूलचेन चुनने से जुड़े दस्तावेज़ों की पूरी जानकारी के लिए, यह पेज भी देखें.
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
toolchains
|
cc_toolchain लेबल तक ले जाने वाला मैप. "<cpu>" का इस्तेमाल तब किया जाएगा, जब सिर्फ़ --cpu
को Bazel को पास किया जाएगा. साथ ही, "<cpu>|<compiler>" का इस्तेमाल तब किया जाएगा, जब
--cpu और --compiler , Bazel को पास किए जाएंगे. उदाहरण:
cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, ) |