नियम
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- cc_shared_library
- fdo_prefetch_hints
- fdo_profile
- memprof_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, link_extra_lib, 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
(सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो): अगर Fission चालू है: डीबग जानकारी पैकेज फ़ाइल, रिमोट तरीके से डिप्लॉय की गई बाइनरी को डीबग करने के लिए सही है. अगर ऐसा नहीं है: एक खाली फ़ाइल.
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
deps
|
लेबल की सूची; डिफ़ॉल्ट रूप से ये |
srcs
|
लेबल की सूची; डिफ़ॉल्ट रूप से सभी
सभी अगर किसी नियम का नाम
अनुमति वाले
...और उन फ़ाइलों को बनाने वाले किसी भी नियम की जानकारी शामिल कर सकते हैं. अलग-अलग एक्सटेंशन, अलग-अलग प्रोग्रामिंग भाषाओं को gcc कन्वेंशन के मुताबिक होना चाहिए. |
additional_linker_inputs
|
लेबल की सूची; डिफ़ॉल्ट रूप से उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां एम्बेड किया जा सकता है, ताकि उन्हें बाइनरी टारगेट. |
copts
|
स्ट्रिंग की सूची;
इस एट्रिब्यूट की हर स्ट्रिंग, दिए गए क्रम में
अगर पैकेज, सुविधा का एलान करता है
|
defines
|
स्ट्रिंग की सूची; -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है,
सभी नियम लागू कर सकते हैं. बहुत सावधान रहें, क्योंकि
दूर तक पहुंचने के लिए. संदेह होने पर, 'तय करें' वैल्यू
इसके बजाय, local_defines का इस्तेमाल करें.
|
includes
|
स्ट्रिंग की सूची;
"वैरिएबल बनाएं" विकल्प पर निर्भर करता है.
हर स्ट्रिंग, हेडर, srcs या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, ये डिपेंडेंट कंपाइलेशन के सैंडबॉक्स में उपलब्ध नियम (डिफ़ॉल्ट). |
link_extra_lib
|
लेबल; डिफ़ॉल्ट रूप से
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
linkopts
|
स्ट्रिंग की सूची; LINKOPTS में जोड़ दिया गया है
बाइनरी टारगेट को लिंक करना.
इस सूची का हर वह एलिमेंट जो |
linkshared
|
बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से linkshared=True शामिल करें. डिफ़ॉल्ट तौर पर
यह विकल्प बंद है.
इस फ़्लैग के मौजूद होने का मतलब है कि लिंकिंग
अगर |
linkstatic
|
बूलियन; cc_binary और
cc_test : बाइनरी को स्टैटिक से लिंक करें
मोड. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह नीति चालू है और यह एक बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को
जब भी मुमकिन हो, तब यूज़र लाइब्रेरी के लिए किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं:
अगर
अगर |
local_defines
|
स्ट्रिंग की सूची; -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है,
हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
|
malloc
|
लेबल; डिफ़ॉल्ट रूप से
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
nocopts
|
String; COPTS
(इसमें वे वैल्यू भी शामिल हैं जो नियम के कोप्ट एट्रिब्यूट में साफ़ तौर पर दी गई हैं)
इस नियम को कंपाइल करने के लिए, COPTS का इस्तेमाल किया जाएगा.
इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
|
stamp
|
पूर्णांक;
स्टैंप वाली बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी नहीं बदलती. |
win_def_file
|
लेबल; डिफ़ॉल्ट रूप से इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब करना चाहिए, जब Windows टारगेट किया गया प्लैटफ़ॉर्म हो. इसका इस्तेमाल इन कामों के लिए किया जा सकता है शेयर की गई लाइब्रेरी लिंक करते समय सिंबल एक्सपोर्ट करें. |
cc_import
नियम का सोर्स देखेंcc_import(name, deps, 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 an 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. स्टैटिक या शेयर की गई लाइब्रेरी
से लिंक किया जा रहा है यूनिक्स पर:
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, )
cc_import
में एक एट्रिब्यूट शामिल किया जा सकता है. जैसे:
cc_import( name = "curl_lib", hdrs = glob(["vendor/curl/include/curl/*.h"]), includes = [ "vendor/curl/include" ], shared_library = "vendor/curl/lib/.libs/libcurl.dylib", )अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
deps
|
लेबल की सूची; डिफ़ॉल्ट रूप से deps के बारे में सामान्य टिप्पणियां देखें
पर सामान्य विशेषताएं
ज़्यादातर बिल्ड रूल के तहत आते हैं.
|
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, additional_compiler_inputs, additional_linker_inputs, 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)
हेडर को शामिल करने की जांच करना
बिल्ड में इस्तेमाल की जाने वाली सभी हेडर फ़ाइलों का एलान, hdrs
में किया जाना चाहिए या
cc_*
में से srcs
नियम. यह लागू किया गया है.
cc_library
नियमों के लिए, hdrs
में हेडर
लाइब्रेरी से शामिल किया जा सकता है और उसे hdrs
और
लाइब्रेरी के srcs
और hdrs
और
cc_*
में से 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
नहीं.
फ़ाइल शामिल है | शामिल करने की अनुमति है |
---|---|
foo.h | bar.h |
foo.cc | फ़ू.ह बार.ह |
bar.h | Bar-impl.h baz.h |
बार-इंप्लि.एच | बार.ह बाज़.एच |
bar.cc | बार.ह बार-इंप्ल.ह बाज़.एच |
baz.h | बाज़-इंप्ल॰एच |
बाज़-इंप्ल॰एच | baz.h |
baz.cc | बाज़.ह बाज़-इंप्ल.एच |
शामिल किए जाने की जांच के नियम सिर्फ़ सीधे तौर पर
शामिल किए गए हैं. ऊपर दिए गए उदाहरण में, foo.cc
की अनुमति है
bar.h
शामिल है, जिसमें baz.h
शामिल हो सकता है, जो
baz-impl.h
को शामिल करने की अनुमति है. तकनीकी रूप से,
एक .cc
फ़ाइल को कंपाइल करने में, कोई भी हेडर शामिल हो सकता है
फ़ाइल को hdrs
में या srcs
में
ट्रांज़िटिव deps
बंद स्थिति में कोई भी cc_library
. तय सीमा में
इस केस में कंपाइलर baz.h
और baz-impl.h
को पढ़ सकता है
foo.cc
को कंपाइल करते समय, लेकिन foo.cc
को
#include "baz.h"
शामिल है. इसके लिए
अनुमति है, baz
को deps
में जोड़ना ज़रूरी है
foo
महीने में से.
बिना किसी भेदभाव के सभी को शामिल करने की जांच से जुड़े नियम लागू करने के लिए, Baze, टूलचेन की सुविधा पर निर्भर करता है.
layering_check
सुविधा, टूलचेन के साथ काम करती हो
और साफ़ तौर पर अनुरोध किया गया है, उदाहरण के लिए
--features=layering_check
कमांड लाइन फ़्लैग या
features
पैरामीटर
package
फ़ंक्शन का इस्तेमाल करें. टूलचेन
यह सुविधा सिर्फ़ Unix और macOS पर clang के साथ काम करती है.
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
deps
|
लेबल की सूची; डिफ़ॉल्ट रूप से ये |
srcs
|
लेबल की सूची; डिफ़ॉल्ट रूप से सभी
सभी अगर किसी नियम का नाम
अनुमति वाले
...और उन फ़ाइलों को बनाने वाले किसी भी नियम की जानकारी शामिल कर सकते हैं. अलग-अलग एक्सटेंशन, अलग-अलग प्रोग्रामिंग भाषाओं को gcc कन्वेंशन के मुताबिक होना चाहिए. |
hdrs
|
लेबल की सूची; डिफ़ॉल्ट रूप से यह हेडर फ़ाइलों का एलान करने के लिए सबसे ज़्यादा प्राथमिकता दी जाती है
लाइब्रेरी के इंटरफ़ेस के बारे में बताता है. इन हेडर को
का इस्तेमाल, इस नियम में मौजूद सोर्स से या अलग-अलग नियमों के तहत किया जा सकता है.
ऐसे हेडर जिन्हें इस लाइब्रेरी के क्लाइंट द्वारा शामिल नहीं किया जाना चाहिए
इसके बजाय, |
additional_compiler_inputs
|
लेबल की सूची; डिफ़ॉल्ट रूप से |
additional_linker_inputs
|
लेबल की सूची; डिफ़ॉल्ट रूप से उदाहरण के लिए, कंपाइल की गई Windows .res फ़ाइलों को यहां एम्बेड किया जा सकता है, ताकि उन्हें बाइनरी टारगेट. |
alwayslink
|
बूलियन; srcs , भले ही कुछ में बाइनरी से रेफ़र किया गया कोई सिंबल मौजूद न हो.
यह तब उपयोगी होता है, जब आपके कोड को स्पष्ट रूप से कोड द्वारा कॉल नहीं किया जाता है
बाइनरी, जैसे कि अगर आपका कोड कुछ कॉलबैक पाने के लिए रजिस्टर होता है
कुछ सेवाओं ने उपलब्ध कराया है.
अगर हमेशा लिंक Windows पर VS 2017 के साथ काम नहीं करता है, तो इसकी वजह से आम समस्या, कृपया अपने VS 2017 को सबसे नए वर्शन में अपग्रेड करें. |
copts
|
स्ट्रिंग की सूची;
इस एट्रिब्यूट की हर स्ट्रिंग, दिए गए क्रम में
अगर पैकेज, सुविधा का एलान करता है
|
defines
|
स्ट्रिंग की सूची; -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है,
सभी नियम लागू कर सकते हैं. बहुत सावधान रहें, क्योंकि
दूर तक पहुंचने के लिए. संदेह होने पर, 'तय करें' वैल्यू
इसके बजाय, local_defines का इस्तेमाल करें.
|
implementation_deps
|
लेबल की सूची; डिफ़ॉल्ट रूप से deps , हेडर और इन लाइब्रेरी के पाथ (और उनके सभी
ट्रांज़िटिव डिप) का इस्तेमाल सिर्फ़ इस लाइब्रेरी को कंपाइल करने के लिए किया जाता है, न कि उन लाइब्रेरी के लिए जिन्हें
निर्भर है. implementation_deps के साथ तय की गई लाइब्रेरी अब भी इसमें लिंक हैं
इस लाइब्रेरी पर निर्भर बाइनरी टारगेट.
फ़िलहाल, इसका इस्तेमाल cc_लाइब्रेरी तक सीमित किया गया है और उसे फ़्लैग किया गया है
|
include_prefix
|
String; अगर नीति को सेट किया जाता है, तो इस नियम के इससे पहले |
includes
|
स्ट्रिंग की सूची;
"वैरिएबल बनाएं" विकल्प पर निर्भर करता है.
हर स्ट्रिंग, हेडर, srcs या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, ये डिपेंडेंट कंपाइलेशन के सैंडबॉक्स में उपलब्ध नियम (डिफ़ॉल्ट). |
linkopts
|
स्ट्रिंग की सूची; LINKOPTS में जोड़ दिया गया है
बाइनरी टारगेट को लिंक करना.
इस सूची का हर वह एलिमेंट जो |
linkstamp
|
लेबल; डिफ़ॉल्ट रूप से base पैकेज.
|
linkstatic
|
बूलियन; cc_binary और
cc_test : बाइनरी को स्टैटिक से लिंक करें
मोड. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह नीति चालू है और यह एक बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को
जब भी मुमकिन हो, तब यूज़र लाइब्रेरी के लिए किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं:
अगर
अगर |
local_defines
|
स्ट्रिंग की सूची; -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है,
हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
|
nocopts
|
String; COPTS
(इसमें वे वैल्यू भी शामिल हैं जो नियम के कोप्ट एट्रिब्यूट में साफ़ तौर पर दी गई हैं)
इस नियम को कंपाइल करने के लिए, COPTS का इस्तेमाल किया जाएगा.
इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
|
strip_include_prefix
|
String; अगर नीति को सेट किया जाता है, तो इस नियम के अगर यह रिलेटिव पाथ है, तो इसे पैकेज के हिसाब से लिया जाता है. अगर यह पूरी तरह से सही है, तो इसे रिपॉज़िटरी-रिलेटिव पाथ के तौर पर समझा जाएगा.
|
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++ कोड जनरेट करने के नियम तय करें.
|
cc_shared_library
नियम का सोर्स देखेंcc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)
इससे एक शेयर की गई लाइब्रेरी बनती है.
उदाहरण
cc_shared_library( name = "foo_shared", deps = [ ":foo", ], dynamic_deps = [ ":bar_shared", ], additional_linker_inputs = [ ":foo.lds", ], user_link_flags = [ "-Wl,--version-script=$(location :foo.lds)", ], ) cc_library( name = "foo", srcs = ["foo.cc"], hdrs = ["foo.h"], deps = [ ":bar", ":baz", ], ) cc_shared_library( name = "bar_shared", shared_lib_name = "bar.so", deps = [":bar"], ) cc_library( name = "bar", srcs = ["bar.cc"], hdrs = ["bar.h"], ) cc_library( name = "baz", srcs = ["baz.cc"], hdrs = ["baz.h"], )
उदाहरण foo_shared
में, foo
को स्टैटिक रूप से लिंक किया गया है
और baz
हैं, जो एक ट्रांज़िटिव डिपेंडेंसी है. इस काम नहीं किया
लिंक bar
क्योंकि यह पहले से ही डायनामिक रूप से
bar_shared
dynamic_dep
.
foo_shared
लिंकर स्क्रिप्ट *.lds फ़ाइल का इस्तेमाल करके तय करता है कि किस
चिह्न एक्सपोर्ट किए जा सकते हैं. cc_shared_library
नियम का तर्क यह करता है
यह इस पर कंट्रोल नहीं करता कि कौनसे सिंबल एक्सपोर्ट किए जा सकते हैं. यह सिर्फ़ उन चिह्नों का इस्तेमाल करता है जिन्हें एक्सपोर्ट किया जाता है
अगर दो शेयर की गई लाइब्रेरी,
टारगेट नहीं किए जा रहे हैं.
सीधे तौर पर होने वाली cc_shared_library
की डिपेंडेंसी को यह माना जाता है कि
निर्यात किया गया. इसलिए, बेज़ल विश्लेषण के दौरान यह मान लेता है कि foo
foo_shared
ने एक्सपोर्ट किया. baz
को एक्सपोर्ट नहीं किया जाना चाहिए
foo_shared
ने. हर टारगेट exports_filter
से मेल खाता है
को भी एक्सपोर्ट किया जाना माना जाता है.
उदाहरण में दिया गया हर cc_library
, ज़्यादा से ज़्यादा एक यूआरएल में दिखना चाहिए
cc_shared_library
. अगर हम baz
को भी
bar_shared
हमें जोड़ना होगा
tags = ["LINKABLE_MORE_THAN_ONCE"]
से baz
.
shared_lib_name
एट्रिब्यूट की वजह से, फ़ाइल बनाने वाली कंपनी
bar_shared
का नाम bar.so
होगा
libbar.so
जो कि Linux पर डिफ़ॉल्ट रूप से उपलब्ध होगा.
गड़बड़ियां
Two shared libraries in dependencies export the same symbols.
ऐसा तब होगा, जब आप दो अलग-अलग चीज़ों के साथ कोई टारगेट बनाएंगे
cc_shared_library
डिपेंडेंसी जो एक ही टारगेट को एक्सपोर्ट करती हैं. इसे ठीक करने के लिए
आपको लाइब्रेरी को किसी एक
cc_shared_library
डिपेंडेंसी.
Two shared libraries in dependencies link the same library statically
दो के साथ नया cc_shared_library
बनाने पर ऐसा होगा
अलग-अलग cc_shared_library
डिपेंडेंसी जो एक ही टारगेट को स्टैटिक रूप से लिंक करती हैं.
यह डेटा एक्सपोर्ट करने में होने वाली गड़बड़ी की तरह है.
इसे ठीक करने का एक तरीका यह है कि लाइब्रेरी को किसी एक
cc_shared_library
डिपेंडेंसी. साथ ही, वह जो इसे अब भी लिंक करता है
लाइब्रेरी को निर्यात करने की आवश्यकता है, ताकि जो लिंक नहीं है वह लाइब्रेरी में दिखाई दे
चिह्नों का इस्तेमाल करें. दूसरा तरीका यह है कि टारगेट को एक्सपोर्ट करने वाली एक तीसरी लाइब्रेरी बनाई जाए.
तीसरा तरीका है कि आप अपराधी cc_library
को LINKABLE_MORE_THAN_ONCE
से टैग करें
लेकिन यह समाधान कभी-कभार ही होगा और आपको पक्का करना चाहिए कि
cc_library
को एक से ज़्यादा बार लिंक करना वाकई सुरक्षित है.
'//foo:foo' is already linked statically in '//bar:bar' but not exported`
इसका मतलब है कि आपके deps
के अस्थायी बंद होने की स्थिति में लाइब्रेरी ऐक्सेस की जा सकती है
किसी cc_shared_library
डिपेंडेंसी का इस्तेमाल किए बिना, लेकिन पहले से ही
dynamic_deps
के किसी भिन्न cc_shared_library
से लिंक है और नहीं
निर्यात किया गया.
इसे cc_shared_library
डिपेंडेंसी से एक्सपोर्ट किया जाता है या पुल आउट किया जाता है
इसे एक तीसरा cc_shared_library
एक्सपोर्ट करता है.
Do not place libraries which only contain a precompiled dynamic library in deps.
अगर आपके पास पहले से कंपाइल की गई डाइनैमिक लाइब्रेरी है, तो इसके लिए ज़रूरी नहीं है और न ही ऐसा किया जा सकता है
आपके मौजूदा cc_shared_library
टारगेट से स्टैटिक रूप से लिंक किया गया
वर्तमान में बना रहे हैं. इसलिए, यह इसके deps
में नहीं आता है
cc_shared_library
. अगर पहले से कंपाइल की गई यह डाइनैमिक लाइब्रेरी, किसी एक की डिपेंडेंसी है
आपके cc_libraries
का, तो cc_library
को इस पर निर्भर होना चाहिए
सकता है.
Trying to export a library already exported by a different shared library
आपको यह गड़बड़ी तब दिखेगी, जब आप मौजूदा नियम के तहत, टारगेट किया जा सकता है, जिसे आपकी किसी डाइनैमिक डिपेंडेंसी के ज़रिए पहले से ही एक्सपोर्ट किया जा रहा हो.
इसे ठीक करने के लिए, deps
से टारगेट को हटाएं और डाइनैमिक वैल्यू पर बस उस पर भरोसा करें
निर्भरता न हो या पक्का करें कि exports_filter
इस टारगेट को न पकड़ सके.
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
deps
|
लेबल की सूची; डिफ़ॉल्ट रूप से
इन डायरेक्ट डिपार्टमेंट की सभी ट्रांज़िटिव लाइब्रेरी डिपेंडेंसी को शेयर किए गए इस डेटा में लिंक कर दिया जाएगा
लाइब्रेरी को तभी जोड़ा जा सकता है, जब उसे पहले से किसी
विश्लेषण के दौरान, नियम लागू होने के दौरान, नीचे दी गई सूची में मौजूद किसी भी टारगेट पर विचार किया जाएगा
लागू करने की वजह से जब भी एक ही लाइब्रेरी स्टैटिक रूप से लिंक होगी, तब भी गड़बड़ियां ट्रिगर होंगी
एक से ज़्यादा |
additional_linker_inputs
|
लेबल की सूची; डिफ़ॉल्ट रूप से user_link_flags एट्रिब्यूट के ज़रिए किया जा सकता है.
|
dynamic_deps
|
लेबल की सूची; डिफ़ॉल्ट रूप से cc_shared_library डिपेंडेंसी हैं, जिन पर मौजूदा टारगेट निर्भर करता है.
|
exports_filter
|
स्ट्रिंग की सूची;
टारगेट
ध्यान दें कि यह एट्रिब्यूट असल में उन टारगेट में डिपेंडेंसी एज नहीं जोड़ रहा है,
इसके बजाय, इस सिंटैक्स की अनुमति है: foo/BUILD में किसी भी टारगेट को पूरा करने के लिए foo/BUILD या किसी दूसरे टारगेट में शामिल टारगेट के लिए |
shared_lib_name
|
String; |
user_link_flags
|
स्ट्रिंग की सूची; cc_shared_library( name = "foo_shared", additional_linker_inputs = select({ "//src/conditions:linux": [ ":foo.lds", ":additional_script.txt", ], "//conditions:default": []}), user_link_flags = select({ "//src/conditions:linux": [ "-Wl,-rpath,kittens", "-Wl,--version-script=$(location :foo.lds)", "-Wl,--script=$(location :additional_script.txt)", ], "//conditions:default": []}), ... )अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है |
win_def_file
|
लेबल; डिफ़ॉल्ट रूप से इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब करना चाहिए, जब Windows टारगेट किया गया प्लैटफ़ॉर्म हो. इसका इस्तेमाल इन कामों के लिए किया जा सकता है शेयर की गई लाइब्रेरी लिंक करते समय सिंबल एक्सपोर्ट करें. |
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
|
String; |
profile
|
लेबल; डिफ़ॉल्ट रूप से |
proto_profile
|
लेबल; डिफ़ॉल्ट रूप से |
memprof_profile
नियम का सोर्स देखेंmemprof_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)
यह ऐसी MEMPROF प्रोफ़ाइल है जो वर्कस्पेस में या किसी ऐसे प्लैटफ़ॉर्म पर ऐब्सलूट पाथ. उदाहरण:
memprof_profile( name = "memprof", profile = "//path/to/memprof:profile.afdo", ) memprof_profile( name = "memprof_abs", absolute_path_profile = "/absolute/path/profile.afdo", )
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
absolute_path_profile
|
String; |
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, link_extra_lib, 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
|
स्ट्रिंग की सूची;
"वैरिएबल बनाएं" विकल्प पर निर्भर करता है.
हर स्ट्रिंग, हेडर, srcs या hdrs में जोड़े जाने चाहिए. ऐसा न होने पर, ये डिपेंडेंट कंपाइलेशन के सैंडबॉक्स में उपलब्ध नियम (डिफ़ॉल्ट). |
link_extra_lib
|
लेबल; डिफ़ॉल्ट रूप से
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
linkopts
|
स्ट्रिंग की सूची; LINKOPTS में जोड़ दिया गया है
बाइनरी टारगेट को लिंक करना.
इस सूची का हर वह एलिमेंट जो |
linkstatic
|
बूलियन; cc_binary और
cc_test : बाइनरी को स्टैटिक से लिंक करें
मोड. cc_library.linkstatic के लिए: नीचे देखें.
डिफ़ॉल्ट रूप से, यह विकल्प
अगर यह नीति चालू है और यह एक बाइनरी या टेस्ट है, तो यह विकल्प बिल्ड टूल को
जब भी मुमकिन हो, तब यूज़र लाइब्रेरी के लिए किसी एक्ज़ीक्यूटेबल को लिंक करने के वास्तव में तीन अलग-अलग तरीके हैं:
अगर
अगर |
local_defines
|
स्ट्रिंग की सूची; -D के साथ जोड़ा जाता है और इस टारगेट के लिए कंपाइल कमांड लाइन में जोड़ा जाता है,
हालाँकि, डिपेंडेंट लोगों के लिए लागू हो सकता है.
|
malloc
|
लेबल; डिफ़ॉल्ट रूप से
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
nocopts
|
String; COPTS
(इसमें वे वैल्यू भी शामिल हैं जो नियम के कोप्ट एट्रिब्यूट में साफ़ तौर पर दी गई हैं)
इस नियम को कंपाइल करने के लिए, COPTS का इस्तेमाल किया जाएगा.
इस एट्रिब्यूट की ज़रूरत बहुत कम पड़ती है.
|
stamp
|
पूर्णांक;
स्टैंप वाली बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी नहीं बदलती. |
win_def_file
|
लेबल; डिफ़ॉल्ट रूप से इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तब करना चाहिए, जब Windows टारगेट किया गया प्लैटफ़ॉर्म हो. इसका इस्तेमाल इन कामों के लिए किया जा सकता है शेयर की गई लाइब्रेरी लिंक करते समय सिंबल एक्सपोर्ट करें. |
cc_toolchain
नियम का सोर्स देखेंcc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, 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
एट्रिब्यूट का इस्तेमाल करें.
इसे भी देखें
पेज
पढ़ें.
टूलचेन को बनाने और कॉन्फ़िगर होने से रोकने के लिए, tags = ["manual"]
का इस्तेमाल करें
bazel build //...
का इस्तेमाल करते समय ग़ैर-ज़रूरी नहीं
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
all_files
|
लेबल; आवश्यक सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को इनपुट के तौर पर सभी रूल_सीसी से जुड़ी कार्रवाइयां (उन कार्रवाइयों को छोड़कर जो इसके ज़्यादा सटीक सेट का इस्तेमाल करती हैं आर्टफ़ैक्ट के बारे में ज़्यादा जानें). बेज़ल यह मानता है किall_files एक सुपरसेट है
आर्टफ़ैक्ट देने वाले दूसरे सभी एट्रिब्यूट शामिल हैं.उदाहरण के लिए, linkstamp को कंपाइल करना ज़रूरी है. इसके लिए,
और लिंक फ़ाइलें, इसलिए इसमें all_files लगता है).
|
ar_files
|
लेबल; डिफ़ॉल्ट रूप से संग्रहित करने की कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन चाहिए. |
as_files
|
लेबल; डिफ़ॉल्ट रूप से असेंबल करने की कार्रवाइयों के लिए सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन ज़रूरी है. |
compiler_files
|
लेबल; आवश्यक इकट्ठा करने की कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन ज़रूरी है. |
compiler_files_without_includes
|
लेबल; डिफ़ॉल्ट रूप से |
coverage_files
|
लेबल; डिफ़ॉल्ट रूप से |
dwp_files
|
लेबल; आवश्यक dwp कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन ज़रूरी है. |
dynamic_runtime_lib
|
लेबल; डिफ़ॉल्ट रूप से इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू है और हम उसे लिंक कर रहे हैं डिपेंडेंसी डाइनैमिक तौर पर. |
exec_transition_for_inputs
|
बूलियन; |
libc_top
|
लेबल; डिफ़ॉल्ट रूप से |
linker_files
|
लेबल; आवश्यक लिंक करने की कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन ज़रूरी है. |
module_map
|
लेबल; डिफ़ॉल्ट रूप से |
objcopy_files
|
लेबल; आवश्यक objकॉपी की कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन होना चाहिए. |
static_runtime_lib
|
लेबल; डिफ़ॉल्ट रूप से इसका इस्तेमाल तब किया जाएगा, जब 'static_link_cpp_runtimes' सुविधा चालू है और हम उसे लिंक कर रहे हैं डिपेंडेंसी स्थिर रूप से. |
strip_files
|
लेबल; आवश्यक स्ट्रिप से जुड़ी कार्रवाइयों के लिए, सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. |
supports_header_parsing
|
बूलियन; |
supports_param_files
|
बूलियन; |
toolchain_config
|
लेबल; आवश्यक cc_toolchain_config_info देने वाले नियम का लेबल.
|
toolchain_identifier
|
String; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से
समस्या #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
विकल्पों के आधार पर एक टूलचेन चुनना को भेजा गया.
इसे भी देखें पेज पढ़ें.
तर्क
विशेषताएं | |
---|---|
name |
नाम; आवश्यक इस टारगेट के लिए यूनीक नाम. |
toolchains
|
लेबल के लिए शब्दकोश मैपिंग; कॉन्फ़िगर नहीं किया जा सकता; आवश्यक "<cpu>" से मिला मैप या "<cpu>|<compiler>" स्ट्रिंग से एकcc_toolchain लेबल. "<cpu>" का इस्तेमाल सिर्फ़ तब किया जाएगा, जब --cpu
बेज़ल को पास किया जाता है, और "<cpu>|<compiler>" का उपयोग तब किया जाएगा जब दोनों
--cpu और --compiler , Basel को भेज दिए गए हैं. उदाहरण:
cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, ) |