C++ टूलचेन कॉन्फ़िगरेशन

खास जानकारी

कंपाइलर को सही विकल्पों के साथ शुरू करने के लिए, Basel को इसके बारे में कुछ जानकारी होनी चाहिए कंपाइलर इंटर्नल, जैसे कि डायरेक्ट्री और ज़रूरी फ़्लैग शामिल करने होंगे. दूसरे शब्दों में, Basel को कंपाइलर के एक आसान मॉडल की ज़रूरत होती है, ताकि काम.

Bazel को इन चीज़ों की जानकारी चाहिए:

• कंपाइलर, thinLTO, मॉड्यूल, डाइनैमिक लिंकिंग या PIC (पोज़िशन इंडिपेंडेंट कोड) के साथ काम करता है या नहीं.
• ज़रूरी टूल के पाथ, जैसे कि gcc, ld, ar, objcopy वगैरह.
• बिल्ट-इन सिस्टम में डायरेक्ट्री शामिल होती हैं. बेज़ल को इनकी ज़रूरत है, ताकि सोर्स फ़ाइल में शामिल सभी हेडर सही तरीके से BUILD फ़ाइल.
• डिफ़ॉल्ट सिस्टम.
• कंपाइल करने, लिंक करने, और संग्रहित करने के लिए किन फ़्लैग का इस्तेमाल करना है.
• काम करने वाले कंपाइलेशन मोड (opt, dbg, fastbuild) के लिए, किन फ़्लैग का इस्तेमाल करना है.
• कंपाइलर के लिए खास तौर पर ज़रूरी वैरिएबल बनाएं.

अगर कंपाइलर में एक से ज़्यादा आर्किटेक्चर के लिए सहायता है, तो Bazel को उन्हें अलग से कॉन्फ़िगर करना होगा.

CcToolchainConfigInfo एक ऐसी कंपनी है जो ज़रूरी लेवल की जानकारी देती है बेज़ल के C++ नियमों के व्यवहार को कॉन्फ़िगर करने के लिए, जानकारी का स्तर. डिफ़ॉल्ट रूप से, Bazel आपके बिल्ड के लिए CcToolchainConfigInfo को अपने-आप कॉन्फ़िगर करता है. हालांकि, आपके पास इसे मैन्युअल तरीके से कॉन्फ़िगर करने का विकल्प होता है. इसके लिए, आपको स्टारलार्क नियम की ज़रूरत होगी जो CcToolchainConfigInfo उपलब्ध कराता है और आपको एट्रिब्यूट की वैल्यू के तौर पर toolchain_config cc_toolchain को आपके नियम में जोड़ा गया. CcToolchainConfigInfo बनाने के लिए, इस नंबर पर कॉल करें cc_common.create_cc_toolchain_config_info(). आपको @rules_cc//cc:cc_toolchain_config_lib.bzl में, उन सभी स्ट्रक्चर के लिए Starlark कन्स्ट्रक्टर मिल सकते हैं जिनकी आपको प्रोसेस में ज़रूरत होगी.

जब C++ टारगेट, विश्लेषण के चरण में आता है, तो Baज़र सही विकल्प चुन लेता है cc_toolchain BUILD फ़ाइल के आधार पर टारगेट करता है और इसमें बताए गए टारगेट से CcToolchainConfigInfo कंपनी cc_toolchain.toolchain_config एट्रिब्यूट की वैल्यू सबमिट करें. cc_toolchain टारगेट, CcToolchainProvider के ज़रिए इस जानकारी को C++ टारगेट को भेजता है.

उदाहरण के लिए, cc_binary या cc_library जैसे नियम से शुरू की गई कंपाइल या लिंक करने की कार्रवाई के लिए, यह जानकारी ज़रूरी है:

• इस्तेमाल करने के लिए कंपाइलर या लिंकर
• कंपाइलर/लिंकर के लिए कमांड-लाइन फ़्लैग
• कॉन्फ़िगरेशन फ़्लैग को --copt/--linkopt विकल्पों से पास किया गया है
• एनवायरमेंट वैरिएबल
• सैंडबॉक्स में ऐसी आर्टफ़ैक्ट जिनमें कार्रवाई पूरी होती है

सैंडबॉक्स में ज़रूरी आर्टफ़ैक्ट को छोड़कर, ऊपर दी गई सभी जानकारी Starlark के उस टारगेट में मौजूद है जिस पर cc_toolchain ले जाता है.

सैंडबॉक्स में शिप किए जाने वाले आर्टफ़ैक्ट, cc_toolchain टारगेट में दिखाए जाते हैं. उदाहरण के लिए, cc_toolchain.linker_files एट्रिब्यूट की मदद से ये काम किए जा सकते हैं सैंडबॉक्स में भेजने के लिए, लिंकर बाइनरी और टूलचेन लाइब्रेरी को तय करना.

टूलचेन चुनना

टूलचेन को चुनने का लॉजिक इस तरह काम करता है:

1. उपयोगकर्ता, BUILD फ़ाइल में cc_toolchain_suite टारगेट तय करता है और --crosstool_top विकल्प का इस्तेमाल करके, Bazel को टारगेट पर ले जाता है.

2. cc_toolchain_suite टारगेट में कई टूलचेन का इस्तेमाल होता है. कॉन्टेंट बनाने --cpu और --compiler फ़्लैग की वैल्यू से तय होता है कि इनमें से किस टूलचेन को चुना जाता है. ऐसा सिर्फ़ --cpu फ़्लैग की वैल्यू के आधार पर किया जाता है या संयुक्त --cpu | --compiler वैल्यू के आधार पर. चुनने की प्रक्रिया ऐसी है: अनुसरण करता है:

   • अगर --compiler बताया गया है, तो Baze cc_toolchain_suite.toolchains से संबंधित एंट्री विशेषता --cpu | --compiler वाली होनी चाहिए. अगर बेज़ल को न मिले एंट्री करने पर गड़बड़ी दिखती है.

   • अगर --compiler विकल्प तय नहीं किया गया है, तो Basel को चुना जाता है cc_toolchain_suite.toolchains से जुड़ी हुई एंट्री एट्रिब्यूट की वैल्यू सिर्फ़ --cpu के साथ जोड़ी जा सकती है.

   • अगर कोई फ़्लैग बताया नहीं गया है, तो Basel, होस्ट सिस्टम की जांच करता है और जानकारी के आधार पर --cpu की वैल्यू. जांच करने के तरीके का कोड देखें.

टूलचेन चुनने के बाद, Starlark नियम में मौजूद उससे जुड़े feature और action_config ऑब्जेक्ट, बिल्ड के कॉन्फ़िगरेशन को कंट्रोल करते हैं. इसका मतलब है कि बाद में बताए गए आइटम. इन मैसेज की मदद से, बेज़ल में C++ की सभी बेहतरीन सुविधाएँ, बिना किसी बदलाव के बेज़ल बाइनरी. C++ नियमों में कई यूनीक कार्रवाइयां की जा सकती हैं. इनके बारे में ज़्यादा जानकारी Bazel सोर्स कोड में दी गई है.

सुविधाएं

सुविधा एक ऐसी इकाई है जिसके लिए कमांड-लाइन फ़्लैग, कार्रवाई, एक्ज़ीक्यूशन एनवायरमेंट पर कंस्ट्रेंट या डिपेंडेंसी में बदलाव करने पर. कोई सुविधा, BUILD फ़ाइलों को treat_warnings_as_errors जैसे फ़्लैग के कॉन्फ़िगरेशन चुनने की अनुमति देने या C++ नियमों के साथ इंटरैक्ट करने और header_modules या thin_lto जैसी नई कंपाइल ऐक्शन और इनपुट को कंपाइलेशन में शामिल करने जैसी कोई आसान सुविधा हो सकती है.

आम तौर पर, CcToolchainConfigInfo में सुविधाओं की एक सूची होती है. इसमें हर सुविधा में एक या एक से ज़्यादा फ़्लैग ग्रुप होते हैं. हर फ़्लैग ग्रुप में, उन फ़्लैग की सूची होती है जो खास Bazel कार्रवाइयों पर लागू होते हैं.

किसी सुविधा को नाम से तय किया जाता है. इससे Starlark नियम कॉन्फ़िगरेशन को Bazel रिलीज़ से पूरी तरह अलग किया जा सकता है. दूसरे शब्दों में, Bazel रिलीज़ से CcToolchainConfigInfo कॉन्फ़िगरेशन के काम करने के तरीके पर तब तक कोई असर नहीं पड़ता, जब तक उन कॉन्फ़िगरेशन के लिए नई सुविधाओं का इस्तेमाल ज़रूरी न हो.

सुविधा को इनमें से किसी एक तरीके से चालू किया जाता है:

• सुविधा के enabled फ़ील्ड को true पर सेट किया गया है.
• Bazel या नियम का मालिक, साफ़ तौर पर इसे चालू करता है.
• उपयोगकर्ता, --feature Bazel विकल्प या features नियम के एट्रिब्यूट के ज़रिए इसे चालू करता है.

सुविधाओं में एक-दूसरे पर निर्भरता हो सकती है. ये कमांड-लाइन फ़्लैग, BUILD फ़ाइल सेटिंग, और अन्य वैरिएबल पर निर्भर करती हैं.

सुविधाओं के साथ ऐसेट जोड़ना

आम तौर पर, डिपेंडेंसी को सीधे Basel की मदद से मैनेज किया जाता है, जो अपने-आप लागू होती है साथ ही, सुविधाओं की प्रकृति से जुड़े विवादों को मैनेज करती है और बिल्ड में परिभाषित किया गया है. टूलचेन स्पेसिफ़िकेशन की मदद से, Starlark नियम में सीधे तौर पर इस्तेमाल करने के लिए ज़्यादा सटीक पाबंदियां लगाई जा सकती हैं. यह नियम, सुविधा के लिए सहायता और उसके दायरे को तय करता है. इनके उदाहरण हैं:

requires = [
   feature_set (features = [
       'feature-name-1',
       'feature-name-2'
   ]),
]

implies = ['feature']

provides = ['feature']

with_features = [
  with_feature_set(
    features = ['feature-1'],
    not_features = ['feature-2'],
  ),
]

कार्रवाइयां

कार्रवाइयों से, इन स्थितियों में बदलाव करने की सुविधा मिलती है यह कार्रवाई किए बिना ही कार्रवाई पूरी होती है. अगर आप action_config किसी कार्रवाई को शुरू करने वाली टूल बाइनरी के बारे में बताता है, जबकि feature कॉन्फ़िगरेशन (फ़्लैग) के बारे में बताता है, जो यह तय करता है कि टूल कार्रवाई शुरू होने पर काम करता है.

सुविधाएं, ऐक्शन का रेफ़रंस देती हैं, ताकि यह पता चल सके कि वे किन Bazel ऐक्शन पर असर डालती हैं. ऐसा इसलिए, क्योंकि ऐक्शन, Bazel ऐक्शन ग्राफ़ में बदलाव कर सकते हैं. कॉन्टेंट बनाने सेवा देने वाली CcToolchainConfigInfo कंपनी के पास ऐसी कार्रवाइयां हैं जिनमें फ़्लैग और टूल मौजूद हैं जैसे कि c++-compile. हर कार्रवाई के लिए फ़्लैग असाइन किए जाते हैं और उन्हें किसी सुविधा से जोड़कर.

हर कार्रवाई के नाम से, एक ही तरह की कार्रवाई के बारे में पता चलता है. यह कार्रवाई Basel ने की है, जैसे कि कंपाइल या लिंक करना. हालांकि, कार्रवाइयों और Bazel ऐक्शन टाइप के बीच कई-एक का संबंध है. यहां Bazel ऐक्शन टाइप से, किसी ऐसी Java क्लास का मतलब है जो किसी ऐक्शन को लागू करती है, जैसे कि CppCompileAction. खास तौर पर, यहां दी गई टेबल में "असेम्बलर ऐक्शन" और "कंपाइलर ऐक्शन" CppCompileAction हैं, जबकि लिंक ऐक्शन CppLinkAction हैं.

असेंबलर की कार्रवाइयां

कंपाइलर ऐक्शन

लिंक से जुड़ी कार्रवाइयां

एआर से जुड़ी कार्रवाइयां

एआर ऐक्शन, ar के ज़रिए ऑब्जेक्ट फ़ाइलों को संग्रह लाइब्रेरी (.a फ़ाइलें) में इकट्ठा करते हैं और नाम में कुछ सेमेटिक कोड डालते हैं.

एलटीओ से जुड़ी कार्रवाइयां

action_config का इस्तेमाल करना

action_config एक Starlark स्ट्रक्चर है, जो किसी Bazel ऐक्शन के बारे में बताता है. यह ऐक्शन के दौरान इस्तेमाल किए जाने वाले टूल (बाइनरी) और सुविधाओं के हिसाब से तय किए गए फ़्लैग के सेट की जानकारी देता है. ये फ़्लैग, कार्रवाई के लागू करता है.

action_config() कंस्ट्रक्टर में ये पैरामीटर हैं:

action_config के लिए दूसरी सुविधाओं की ज़रूरत पड़ सकती है और उन्हें लागू किया जा सकता है. action_config सुविधाओं के साथ जुड़ाव के बारे में ऊपर बताया गया है. यह व्यवहार किसी सुविधा के समान है.

आखिरी दो एट्रिब्यूट, सुविधाओं के एट्रिब्यूट के मुकाबले ग़ैर-ज़रूरी हैं. इन्हें इसलिए शामिल किया गया है, क्योंकि Bazel की कुछ कार्रवाइयों के लिए कुछ फ़्लैग या एनवायरमेंट वैरिएबल की ज़रूरत होती है. साथ ही, इसका मकसद action_config+feature के ग़ैर-ज़रूरी पेयर से बचना है. आम तौर पर, एक ही सुविधा को कई action_config के साथ शेयर करना बेहतर होता है.

एक ही action_name के साथ, एक से ज़्यादा action_config नहीं दिए जा सकते एक ही टूलचेन में. इससे टूल पाथ में किसी तरह की गड़बड़ी नहीं होती और action_config के मकसद को पूरा किया जाता है. इसका मकसद यह है कि टूलचेन में किसी ऐक्शन की प्रॉपर्टी को एक ही जगह पर साफ़ तौर पर बताया जाए.

टूल कंस्ट्रक्टर का इस्तेमाल करना

action_config अपने tools पैरामीटर की मदद से, टूल का एक सेट तय कर सकता है. tool() कन्स्ट्रक्टर में ये पैरामीटर इस्तेमाल किए जाते हैं:

किसी दिए गए action_config के लिए, सिर्फ़ एक tool लागू होता है इसके टूल पाथ और इसे लागू करने की ज़रूरी शर्तों को पूरा करता है. किसी टूल को तब तक action_config पर मौजूद tools एट्रिब्यूट के ज़रिए दोहराया जाता है, जब तक कि सुविधा के कॉन्फ़िगरेशन से मैच करने वाला with_feature सेट वाला टूल न मिल जाए. ज़्यादा जानकारी के लिए, इस पेज पर पहले मौजूद सुविधा के बीच के संबंध देखें. आपको टूल की सूचियों को डिफ़ॉल्ट टूल के साथ खत्म करना चाहिए, जो किसी खाली सुविधा कॉन्फ़िगरेशन से जुड़ा हो.

इस्तेमाल से जुड़ा उदाहरण

Basel की कार्रवाइयों को लागू करने के लिए, सुविधाओं और कार्रवाइयों का एक साथ इस्तेमाल किया जा सकता है जिसमें अलग-अलग क्रॉस-प्लैटफ़ॉर्म सिमेंटिक्स शामिल हैं. उदाहरण के लिए, macOS पर डीबग सिंबल जनरेट करने के लिए, सबसे पहले कंपाइल ऐक्शन में सिंबल जनरेट करने होंगे. इसके बाद, लिंक ऐक्शन के दौरान एक खास टूल का इस्तेमाल करके, कंप्रेस किया गया dsym संग्रह बनाया जाएगा. इसके बाद, उस संग्रह को डिकंप्रेस करके ऐप्लिकेशन बंडल और .plist ऐसी फ़ाइलें बनाई जाएंगी जिन्हें Xcode इस्तेमाल कर सकता है.

Bazel की मदद से, इस प्रोसेस को इस तरह लागू किया जा सकता है. इसमें unbundle-debuginfo, Bazel ऐक्शन है:

load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")

action_configs = [
    action_config (
        action_name = ACTION_NAMES.cpp_link_executable,
        tools = [
            tool(
                with_features = [
                    with_feature(features=["generate-debug-symbols"]),
                ],
                path = "toolchain/mac/ld-with-dsym-packaging",
            ),
            tool (path = "toolchain/mac/ld"),
        ],
    ),
]

features = [
    feature(
        name = "generate-debug-symbols",
        flag_sets = [
            flag_set (
                actions = [
                    ACTION_NAMES.c_compile,
                    ACTION_NAMES.cpp_compile
                ],
                flag_groups = [
                    flag_group(
                        flags = ["-g"],
                    ),
                ],
            )
        ],
        implies = ["unbundle-debuginfo"],
   ),
]

इस सुविधा को Linux के लिए पूरी तरह से अलग तरीके से लागू किया जा सकता है, जो fission या Windows के लिए, जो .pdb फ़ाइलें बनाती है. उदाहरण के लिए, fission पर आधारित डीबग सिंबल जनरेशन को लागू करने का तरीका कुछ ऐसा दिख सकता है:

load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")

action_configs = [
    action_config (
        name = ACTION_NAMES.cpp_compile,
        tools = [
            tool(
                path = "toolchain/bin/gcc",
            ),
        ],
    ),
]

features = [
    feature (
        name = "generate-debug-symbols",
        requires = [with_feature_set(features = ["dbg"])],
        flag_sets = [
            flag_set(
                actions = [ACTION_NAMES.cpp_compile],
                flag_groups = [
                    flag_group(
                        flags = ["-gsplit-dwarf"],
                    ),
                ],
            ),
            flag_set(
                actions = [ACTION_NAMES.cpp_link_executable],
                flag_groups = [
                    flag_group(
                        flags = ["-Wl", "--gdb-index"],
                    ),
                ],
            ),
      ],
    ),
]

ग्रुप फ़्लैग करना

CcToolchainConfigInfo से आपको फ़्लैग को उन ग्रुप में शामिल करने की अनुमति मिलती है जो किसी खास मकसद के लिए बनाया गया हो. फ़्लैग की वैल्यू में पहले से तय किए गए वैरिएबल का इस्तेमाल करके, फ़्लैग तय किया जा सकता है. कंपाइलर, फ़्लैग को बिल्ड कमांड में जोड़ते समय उसे बड़ा कर देता है. उदाहरण के लिए:

flag_group (
    flags = ["%{output_execpath}"],
)

इस मामले में, फ़्लैग के कॉन्टेंट को कार्रवाई की आउटपुट फ़ाइल के पाथ से बदल दिया जाएगा.

फ़्लैग ग्रुप, बिल्ड कमांड तक उस क्रम में बड़े किए जाते हैं जिस क्रम में वे दिखते हैं सूची में ऊपर से नीचे, बाएं से दाएं.

उन फ़्लैग के लिए जिन्हें बिल्ड में जोड़ने पर अलग-अलग मानों के साथ दोहराने की ज़रूरत होती है निर्देश देने के लिए, फ़्लैग ग्रुप list टाइप के वैरिएबल को दोहरा सकता है. उदाहरण के लिए, list टाइप का वैरिएबल include_path:

flag_group (
    iterate_over = "include_paths",
    flags = ["-I%{include_paths}"],
)

include_paths सूची में हर पाथ एलिमेंट के लिए, -I<path> तक बड़ा होता है. फ़्लैग ग्रुप के एलान के मुख्य हिस्से में मौजूद सभी फ़्लैग (या flag_group) को एक यूनिट के तौर पर बड़ा किया जाता है. उदाहरण के लिए:

flag_group (
    iterate_over = "include_paths",
    flags = ["-I", "%{include_paths}"],
)

include_paths सूची में हर पाथ एलिमेंट के लिए, -I <path> तक बड़ा होता है.

किसी वैरिएबल को कई बार दोहराया जा सकता है. उदाहरण के लिए:

flag_group (
    iterate_over = "include_paths",
    flags = ["-iprefix=%{include_paths}", "-isystem=%{include_paths}"],
)

इसमें बड़ा होगा:

-iprefix=<inc0> -isystem=<inc0> -iprefix=<inc1> -isystem=<inc1>

वैरिएबल, बिंदु-नोटेशन का इस्तेमाल करके ऐक्सेस किए जा सकने वाले स्ट्रक्चर से जुड़े हो सकते हैं. उदाहरण के लिए:

flag_group (
    flags = ["-l%{libraries_to_link.name}"],
)

स्ट्रक्चर को नेस्ट किया जा सकता है और उनमें क्रम भी शामिल हो सकते हैं. नाम के टकराव से बचने के लिए साफ़ तौर पर कहा जाए, तो आपको फ़ील्ड के ज़रिए पूरा पाथ बताना होगा. इसके लिए उदाहरण:

flag_group (
    iterate_over = "libraries_to_link",
    flag_groups = [
        flag_group (
            iterate_over = "libraries_to_link.shared_libraries",
            flags = ["-l%{libraries_to_link.shared_libraries.name}"],
        ),
    ],
)

शर्त के हिसाब से एक्सपैंशन

फ़्लैग ग्रुप, expand_if_available, expand_if_not_available, expand_if_true, expand_if_false या expand_if_equal एट्रिब्यूट का इस्तेमाल करके, किसी खास वैरिएबल या उसके फ़ील्ड की मौजूदगी के आधार पर, शर्त के मुताबिक डेटा एक्सपैंशन की सुविधा देते हैं. उदाहरण के लिए:

flag_group (
    iterate_over = "libraries_to_link",
    flag_groups = [
        flag_group (
            iterate_over = "libraries_to_link.shared_libraries",
            flag_groups = [
                flag_group (
                    expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
                    flags = ["--whole_archive"],
                ),
                flag_group (
                    flags = ["-l%{libraries_to_link.shared_libraries.name}"],
                ),
                flag_group (
                    expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
                    flags = ["--no_whole_archive"],
                ),
            ],
        ),
    ],
)

CcToolchainConfigInfo का रेफ़रंस

इस सेक्शन में, C++ नियमों को कॉन्फ़िगर करने के लिए ज़रूरी, बिल्ड वैरिएबल, सुविधाओं, और अन्य जानकारी का रेफ़रंस दिया गया है.

CcToolchainConfigInfo बिल्ड वैरिएबल

यहां CcToolchainConfigInfo बिल्ड वैरिएबल का रेफ़रंस दिया गया है.

लोकप्रिय सुविधाएं

सुविधाओं और उनके चालू होने के बारे में यहां बताया गया है शर्तें.

लेगसी सुविधाओं को पैच करने का लॉजिक

Basel ने टूलचेन की सुविधाओं में ये बदलाव लागू किए. ये बदलाव, पीछे की ओर करने के लिए किए गए हैं साथ काम करता है:

• legacy_compile_flags सुविधा को टूलचैन में सबसे ऊपर ले जाता है
• default_compile_flags सुविधा को टूलचेन के सबसे ऊपर ले जाता है
• टूलचेन के सबसे ऊपर dependency_file (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर pic (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर per_object_debug_info (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर preprocessor_defines (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर includes (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर include_paths (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर fdo_instrument (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर fdo_optimize (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर cs_fdo_instrument (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर cs_fdo_optimize (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर fdo_prefetch_hints (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर autofdo (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर build_interface_libraries (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर dynamic_library_linker_tool (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर shared_flag (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर linkstamps (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर output_execpath_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर runtime_library_search_directories (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर library_search_directories (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर archiver_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर libraries_to_link (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर force_pic_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर user_link_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर legacy_link_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर static_libgcc (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर fission_support (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर strip_debug_symbols (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर coverage (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर llvm_coverage_map_format (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे ऊपर gcc_coverage_map_format (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे नीचे fully_static_link (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे नीचे user_compile_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है
• इससे टूलचेन के सबसे नीचे sysroot (अगर मौजूद नहीं है) सुविधा जोड़ दी जाती है
• टूलचेन के सबसे नीचे unfiltered_compile_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे नीचे linker_param_file (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे नीचे compiler_input_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है
• टूलचेन के सबसे नीचे compiler_output_flags (अगर मौजूद नहीं है) सुविधा जोड़ता है

यह सुविधाओं की एक लंबी सूची है. Starlark में क्रॉसटूल बन जाने के बाद, इनका इस्तेमाल बंद कर दिया जाएगा. दिलचस्पी रखने वाले लोगों के लिए, इसे लागू करने की प्रोसेस को CppActionConfigs, और प्रोडक्शन टूलचेन के लिए, no_legacy_features को जोड़कर ज़्यादा अलग तरीके से बनाया जा सकता है.