नियम
- 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
|
स्ट्रिंग की सूची; डिफ़ॉल्ट
"वैरिएबल बनाएं" विकल्प पर निर्भर करता है.
हर स्ट्रिंग, हेडर को src या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन के सैंडबॉक्स में होने पर वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे (डिफ़ॉल्ट). |
link_extra_lib
|
लेबल; डिफ़ॉल्ट
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
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, 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. स्टैटिक या शेयर की गई लाइब्रेरी से लिंक करना
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, )
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-impl.h |
baz-impl.h | baz.h |
baz.cc | बाज़.ह बाज़-इंप्ल.एच |
शामिल किए जाने की जांच करने से जुड़े नियम, सिर्फ़ सीधे तौर पर
शामिल किए जाने पर लागू होते हैं. ऊपर दिए गए उदाहरण में, 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
में जोड़ना ज़रूरी है.
बिना किसी भेदभाव के सभी को शामिल करने की जांच से जुड़े नियम लागू करने के लिए, Baze, टूलचेन की सुविधा पर निर्भर करता है.
यह ज़रूरी है कि layering_check
सुविधा, टूलचेन के साथ काम करती हो और
इसके लिए साफ़ तौर पर अनुरोध किया गया हो. उदाहरण के लिए,
--features=layering_check
कमांड-लाइन फ़्लैग या
package
फ़ंक्शन के
features
पैरामीटर के ज़रिए. Baze के टूल
सिर्फ़ Unix और macOS पर इस सुविधा के साथ काम करते हैं.
तर्क
विशेषताएं | |
---|---|
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
|
स्ट्रिंग; डिफ़ॉल्ट तौर पर सेट होने पर, इस नियम के इस प्रीफ़िक्स को जोड़ने से पहले, |
includes
|
स्ट्रिंग की सूची; डिफ़ॉल्ट
"वैरिएबल बनाएं" विकल्प पर निर्भर करता है.
हर स्ट्रिंग, हेडर को src या 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 के नियमों की सूची.
|
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
से लिंक नहीं करता, क्योंकि इसे पहले ही dynamic_dep
bar_shared
से डाइनैमिक तौर पर उपलब्ध कराया गया है.
कौनसे सिंबल एक्सपोर्ट करने हैं, यह कंट्रोल करने के लिए foo_shared
, लिंकर स्क्रिप्ट *.lds फ़ाइल का इस्तेमाल करता है. cc_shared_library
नियम वाला लॉजिक, यह कंट्रोल नहीं करता कि कौनसे सिंबल एक्सपोर्ट किए जा सकते हैं. यह सिर्फ़ उस डेटा का इस्तेमाल करता है जिसे एक्सपोर्ट के दौरान गड़बड़ी माना जाता है. ऐसा तब होता है, जब शेयर की गई दो लाइब्रेरी एक जैसे टारगेट एक्सपोर्ट करती हैं.
यह माना जाता है कि cc_shared_library
की डायरेक्ट डिपेंडेंसी को एक्सपोर्ट किया जाता है. इसलिए, विश्लेषण के दौरान Basel यह मान लेता है कि
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
होगा, जबकि Linux का नाम डिफ़ॉल्ट रूप से libbar.so
होगा.
गड़बड़ियां
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
टारगेट के साथ स्टैटिक रूप से लिंक करने की ज़रूरत नहीं है और न ही इसे लिंक किया जा सकता है. इसलिए, यह cc_shared_library
के deps
में नहीं है. अगर पहले से कंपाइल की गई यह डाइनैमिक लाइब्रेरी, आपके 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 में टारगेट किए गए किसी भी टारगेट या foo/ जैसे कि foo/bar/BUILD से कम के किसी भी अन्य पैकेज को शामिल करने के लिए |
shared_lib_name
|
स्ट्रिंग; डिफ़ॉल्ट तौर पर |
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
|
स्ट्रिंग; डिफ़ॉल्ट तौर पर |
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
|
स्ट्रिंग; डिफ़ॉल्ट तौर पर |
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
|
स्ट्रिंग की सूची; डिफ़ॉल्ट
"वैरिएबल बनाएं" विकल्प पर निर्भर करता है.
हर स्ट्रिंग, हेडर को src या hdrs में जोड़ना ज़रूरी है. ऐसा न होने पर, कंपाइलेशन के सैंडबॉक्स में होने पर वे डिपेंडेंट नियमों के लिए उपलब्ध नहीं होंगे (डिफ़ॉल्ट). |
link_extra_lib
|
लेबल; डिफ़ॉल्ट
डिफ़ॉल्ट रूप से, C++ बाइनरी को |
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_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
एट्रिब्यूट का इस्तेमाल करें.
C++ टूलचेन कॉन्फ़िगरेशन और टूलचेन को चुनने से जुड़े ज़्यादा दस्तावेज़ देखने के लिए, इस
पेज
पर जाएं.
bazel build //...
का इस्तेमाल करते समय, tags = ["manual"]
का इस्तेमाल करें, ताकि टूलचेन को ज़रूरत के हिसाब से
बेवजह नहीं बनाया और कॉन्फ़िगर किया जा सके
तर्क
विशेषताएं | |
---|---|
name |
नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम. |
all_files
|
लेबल; ज़रूरी है सभी cc_toolchain आर्टफ़ैक्ट का कलेक्शन. इन आर्टफ़ैक्ट को Terms_cc से जुड़ी सभी कार्रवाइयों में इनपुट के तौर पर जोड़ दिया जाएगा. इनमें वे कार्रवाइयां शामिल नहीं हैं जो नीचे दिए गए एट्रिब्यूट में से, ज़्यादा सटीक आर्टफ़ैक्ट के सेट का इस्तेमाल करती हैं. बेज़ल यह मानता है किall_files , आर्टफ़ैक्ट देने वाले
दूसरे सभी एट्रिब्यूट का सुपरसेट है. उदाहरण के लिए, linktamp को कंपाइल करने के लिए फ़ाइलों को कंपाइल और लिंक करना
ज़रूरी है, इसलिए इसमें 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
|
स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट रूप से
समस्या #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++ के सभी ज़रूरी टूलचेन इकट्ठा करना.
-
Basel को भेजे गए
--cpu
और--compiler
विकल्पों के आधार पर एक टूलचेन चुनना.
C++ टूलचेन कॉन्फ़िगरेशन और टूलचेन को चुनने से जुड़े ज़्यादा दस्तावेज़ देखने के लिए, इस पेज पर जाएं.
तर्क
विशेषताएं | |
---|---|
name |
नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम. |
toolchains
|
डिक्शनरी को लेबल से मैप करने वाली स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; ज़रूरी है "<cpu>" या "<cpu>|<compiler>" स्ट्रिंग सेcc_toolchain लेबल में
मैप किया गया. "<cpu>" का इस्तेमाल तब किया जाएगा, जब सिर्फ़ --cpu
Basel को पास किया गया हो. साथ ही, "<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", }, ) |