नियम
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- fdo_fetch_hints
- fdo_profile
- propelle_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(सिर्फ़ तब अनुरोध किया गया, जब साफ़ तौर पर अनुरोध किया गया हो): अगर Fision चालू है: डीबग की जानकारी देने वाली पैकेज फ़ाइल, जो रिमोट तरीके से डिप्लॉय की गई बाइनरी को डीबग करने के लिए सही है. दूसरा तरीका: एक खाली फ़ाइल.
तर्क
| एट्रिब्यूट | |
|---|---|
name |
इस टारगेट का एक यूनीक नाम. |
deps
|
ये |
srcs
|
सभी
सभी अगर कोई नियम' का नाम
इन
...और ये फ़ाइलें बनाने वाले सभी नियम. अलग-अलग एक्सटेंशन, जीसीसी कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं. |
additional_linker_inputs
|
उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां दिया जा सकता है, ताकि वे बाइनरी टारगेट में एम्बेड कर सकें. |
copts
|
बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में
अगर पैकेज में, सुविधा
|
defines
|
-D के साथ जोड़ा जाता है. साथ ही, इसे इस टारगेट में कंपाइल करने के लिए कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर करने वाले हर नियम को जोड़ा जाता है. सावधान रहें, क्योंकि इसका
बहुत दूर तक असर पड़ सकता है. संदेह होने पर, local_defines में वैल्यू तय करें.
|
includes
|
&kot;वैरिएबल बनाएं&कोटेशन के तहत.
हर स्ट्रिंग को हेडर, src या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, वे कंपाइलेशन के सैंडबॉक्स (डिफ़ॉल्ट) पर निर्भर मोड के लिए उपलब्ध नहीं होंगे. |
linkopts
|
LINKOPTS में जोड़ दिया जाता है.
इस सूची का हर एलिमेंट जो |
linkshared
|
linkshared=True को शामिल करें. डिफ़ॉल्ट रूप से, यह विकल्प बंद होता है.
इस फ़्लैग के मौजूद होने का मतलब है कि
अगर आप |
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में जोड़ें. cc_library.linkstatic के लिए: नीचे देखें.
यह विकल्प डिफ़ॉल्ट रूप से
अगर इसे चालू किया जाता है और यह बाइनरी या टेस्ट है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं:
अगर
अगर |
local_defines
|
-D के साथ जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल करने वाली कमांड लाइन में जोड़ा जाता है, लेकिन इसके निर्भर समूह पर नहीं.
|
malloc
|
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
nocopts
|
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, include_prefix, includes, interface_deps, 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, दोनों में सीधे शामिल किया जा सकता है. साथ ही, cc_* में मौजूद
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.h बार.h |
| Bar.h | Bar- पक्का.बज़.h |
| बार-इंप्रेशन | Bar.h baz.h |
| बार | Bar.h Bar-ंट.h baz.h |
| baz.h | baz-impl.h |
| baz-impl.h | baz.h |
| baz.cc | baz.h baz-Impact.h |
शामिल किए जाने की जांच करने के नियम, डायरेक्ट शामिल किए जाने पर ही लागू होते हैं. ऊपर दिए गए उदाहरण में, foo.cc को bar.h शामिल करने की अनुमति है, जिसमें baz.h शामिल हो सकता है. इसके बदले में, baz-impl.h को शामिल किया जा सकता है. तकनीकी तौर पर, .cc फ़ाइल को कंपाइल करके, ट्रांज़िट समय के दौरान deps में किसी भी cc_library में, hdrs या srcs में किसी भी हेडर फ़ाइल को कुछ समय के लिए शामिल किया जा सकता है. इस
मामले में, कंपाइलर foo.cc को कंपाइल करते समय baz.h और baz-impl.h को पढ़ सकता है, लेकिन foo.cc में #include "baz.h" नहीं होना चाहिए. इसके लिए
baz को foo के deps
में जोड़ना ज़रूरी है.
फ़िलहाल, बेज़ेल सीधे तौर पर होने वाले और ट्रांज़िट समय के बीच शामिल नहीं किए जा सकते.
इसलिए, यह गड़बड़ी के ऐसे मामलों का पता नहीं लगा सकता जहां किसी फ़ाइल में गैरकानूनी तरीके से
एक हेडर को सीधे शामिल करने की अनुमति होती है. उदाहरण के लिए, अगर ऊपर दिए गए उदाहरण में foo.cc सीधे तौर पर baz.h शामिल करता है, तो बेज़ल शिकायत नहीं करेंगे. यह गैरकानूनी होगा, क्योंकि foo सीधे baz पर निर्भर नहीं है. फ़िलहाल, इस तरह की कोई गड़बड़ी नहीं होती है. हालांकि, आने वाले समय में इस तरह की गड़बड़ी की जांच की जा सकती है.
तर्क
| एट्रिब्यूट | |
|---|---|
name |
इस टारगेट का एक यूनीक नाम. |
deps
|
ये |
srcs
|
सभी
सभी अगर कोई नियम' का नाम
इन
...और ये फ़ाइलें बनाने वाले सभी नियम. अलग-अलग एक्सटेंशन, जीसीसी कन्वेंशन के मुताबिक अलग-अलग प्रोग्रामिंग भाषाओं को दिखाते हैं. |
hdrs
|
यह हेडर फ़ाइलों के बारे में जानकारी देने के लिए पूरी तरह से पसंदीदा जगह है. इससे, लाइब्रेरी के इंटरफ़ेस के बारे में जानकारी मिलती है. इन हेडर को
इस नियम या निर्भर नियमों के स्रोतों में शामिल करने के लिए उपलब्ध कराया जाएगा.
इस लाइब्रेरी के क्लाइंट के ज़रिए शामिल नहीं किए जाने वाले हेडर को
|
alwayslink
|
srcs में मौजूद फ़ाइलों के लिए, सभी ऑब्जेक्ट फ़ाइलों से लिंक हो जाएगी. भले ही, कोई बाइनरी फ़ाइल में किसी भी बाइनरी का संदर्भ न दिया गया हो.
यह कोड तब काम आता है, जब कोड को बाइनरी में कोड से साफ़ तौर पर कॉल न किया गया हो. उदाहरण के लिए, अगर आपका कोड रजिस्टर किया जाता है, ताकि कुछ सेवाओं की मदद से कॉलबैक किया जा सके.
अगर हमेशा लिंक करने की सुविधा Windows पर VS 2017 के साथ काम नहीं करती है, तो यह आपकी पहले से मालूम समस्या की वजह से होता है. इसलिए, कृपया अपने VS 2017 को नए वर्शन में अपग्रेड कर लें. |
copts
|
बाइनरी टारगेट को कंपाइल करने से पहले, इस एट्रिब्यूट की हर स्ट्रिंग को दिए गए क्रम में
अगर पैकेज में, सुविधा
|
defines
|
-D के साथ जोड़ा जाता है. साथ ही, इसे इस टारगेट में कंपाइल करने के लिए कमांड लाइन में जोड़ा जाता है. साथ ही, इस पर निर्भर करने वाले हर नियम को जोड़ा जाता है. सावधान रहें, क्योंकि इसका
बहुत दूर तक असर पड़ सकता है. संदेह होने पर, local_defines में वैल्यू तय करें.
|
include_prefix
|
इसके सेट होने पर, इस नियम के इस प्रीफ़िक्स को जोड़ने से पहले, |
includes
|
&kot;वैरिएबल बनाएं&कोटेशन के तहत.
हर स्ट्रिंग को हेडर, src या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, वे कंपाइलेशन के सैंडबॉक्स (डिफ़ॉल्ट) पर निर्भर मोड के लिए उपलब्ध नहीं होंगे. |
interface_deps
|
--experimental_cc_interface_deps सही है, तो डेप में दिए गए टारगेट, लागू करने के तरीके के तौर पर काम करेंगे. सामान्य डेप के उलट, हेडर और उस में शामिल इंप्लीमेंटेशन पाथ (और उनके सभी ट्रांज़िटिव डे) का इस्तेमाल, सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है, न कि इस पर निर्भर लाइब्रेरी पर निर्भर करता है. लाइब्रेरी के आधार पर लागू की गई लाइब्रेरी, अब भी उन बाइनरी टारगेट में लिंक होंगी जो लाइब्रेरी से तय की गई हैं. इंटरफ़ेस_deps में दी गई डिपेंडेंसी
का व्यवहार पुराने लेआउट की तरह ही रहेगा जहां हेडर और
पाथ शामिल किए जाने से डाउनस्ट्रीम लागू होता है.
|
linkopts
|
LINKOPTS में जोड़ दिया जाता है.
इस सूची का हर एलिमेंट जो |
linkstamp
|
base पैकेज में होनी चाहिए.
|
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में जोड़ें. cc_library.linkstatic के लिए: नीचे देखें.
यह विकल्प डिफ़ॉल्ट रूप से
अगर इसे चालू किया जाता है और यह बाइनरी या टेस्ट है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं:
अगर
अगर |
local_defines
|
-D के साथ जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल करने वाली कमांड लाइन में जोड़ा जाता है, लेकिन इसके निर्भर समूह पर नहीं.
|
nocopts
|
COPTS को हटा दिया जाएगा.
इस एट्रिब्यूट की ज़रूरत कभी-कभी ही होनी चाहिए.
|
strip_include_prefix
|
सेट करने पर, इस नियम के अगर यह एक मिलता-जुलता पाथ है, तो इसे पैकेज-रिलेटिव माना जाता है. अगर यह ##39 है, तो इसे रिपॉज़िटरी-रिलेटिव पाथ के तौर पर समझा जाता है. इस प्रीफ़िक्स को हटाने के बाद, |
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_fetch_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
|
|
propelle_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
|
&kot;वैरिएबल बनाएं&कोटेशन के तहत.
हर स्ट्रिंग को हेडर, src या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, वे कंपाइलेशन के सैंडबॉक्स (डिफ़ॉल्ट) पर निर्भर मोड के लिए उपलब्ध नहीं होंगे. |
linkopts
|
LINKOPTS में जोड़ दिया जाता है.
इस सूची का हर एलिमेंट जो |
linkstatic
|
cc_binary और
cc_test के लिए: बाइनरी को स्टैटिक
मोड में जोड़ें. cc_library.linkstatic के लिए: नीचे देखें.
यह विकल्प डिफ़ॉल्ट रूप से
अगर इसे चालू किया जाता है और यह बाइनरी या टेस्ट है, तो जब भी संभव हो, इस विकल्प से बिल्ड टूल को एक्ज़ीक्यूटेबल को लिंक करने के तीन अलग-अलग तरीके हैं:
अगर
अगर |
local_defines
|
-D के साथ जोड़ा जाता है. साथ ही, इसे इस टारगेट के लिए कंपाइल करने वाली कमांड लाइन में जोड़ा जाता है, लेकिन इसके निर्भर समूह पर नहीं.
|
malloc
|
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
nocopts
|
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++ टूलचेन कॉन्फ़िगरेशन और टूलचेन दस्तावेज़ों के लिए, इस
पेज
को भी देखें.
bazel build //... का इस्तेमाल करते समय, टूलचेन को बिना ज़रूरत के कॉन्फ़िगर और कॉन्फ़िगर करने से रोकने के लिए, tags = ["manual"] का इस्तेमाल करें
तर्क
| एट्रिब्यूट | |
|---|---|
name |
इस टारगेट का एक यूनीक नाम. |
all_files
|
all_files आर्टफ़ैक्ट देने वाली दूसरी सभी विशेषताओं का एक सुपरसेट है (उदाहरण के लिए, लिंकस्टांप कंपाइलेशन के लिए कंपाइल करने और लिंक फ़ाइलों, दोनों की ज़रूरत होती है, इसलिए यह all_files लेता है).
|
ar_files
|
संग्रह करने के लिए ज़रूरी, cc_toolchain से जुड़ी सभी कलाकृतियों का संग्रह. |
as_files
|
असेंबली कार्रवाइयों के लिए आवश्यक सभी cc_toolchain कलाकृतियों का संग्रह. |
compiler
|
toolchain_identifier एट्रिब्यूट का इस्तेमाल करें.
CROSSTool को Starlark पर
माइग्रेट करने
के बाद, यह ग़ैर-ज़रूरी नहीं होगा. इसे
#7075 से हटा दिया जाएगा.
सेट होने पर, इसका इस्तेमाल crosstool_config.toolchain चुनने के लिए किया जाएगा. इसे --cpu Bazer के विकल्प के ऊपर प्राथमिकता दी जाएगी. |
compiler_files
|
फ़िलहाल, सिर्फ़ lto_backend कार्रवाइयों के लिए इस्तेमाल की जाती है. रेगुलर कंपाइल कार्रवाइयां, all_files (#6927) का इस्तेमाल करती हैं. |
compiler_files_without_includes
|
|
coverage_files
|
|
cpu
|
सेट होने पर, इसका इस्तेमाल crosstool_config.toolchain चुनने के लिए किया जाएगा. इसे --cpu Bazer के विकल्प के ऊपर प्राथमिकता दी जाएगी. |
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के विकल्पों के हिसाब से, एक टूलचेन चुनकर, बज़ेल को पास किया गया.
बेहतर C++ टूलचेन कॉन्फ़िगरेशन और टूलचेन दस्तावेज़ों के लिए, इस पेज को भी देखें.
तर्क
| एट्रिब्यूट | |
|---|---|
name |
इस टारगेट का एक यूनीक नाम. |
toolchains
|
cc_toolchain</t> "<cpu>" --cpu का इस्तेमाल सिर्फ़ तब होगा, जब बेज़ेल को --cpu भेजा जाएगा. साथ ही, &&tt;cpu>|<compiler>&kot; तब इस्तेमाल किया जाएगा, जब
--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",
},
)
|