प्लैटफ़ॉर्म की मदद से इमारत बनाना

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

इस पेज पर, प्लैटफ़ॉर्म बनाने के मकसद के बारे में खास जानकारी दी गई है. साथ ही, उन्हें बनाने का तरीका भी बताया गया है.

tl;dr: Basel का प्लैटफ़ॉर्म और टूलचेन एपीआई उपलब्ध हैं, लेकिन वे काम नहीं करेंगे सभी भाषा नियम, select() और अन्य लीगेसी संदर्भ तक हर जगह अपडेट किए गए हैं. यह काम जारी है. आखिरकार, सभी बिल्ड प्लैटफ़ॉर्म-आधारित होंगे. आपके बिल्ड कहां फ़िट होते हैं, यह जानने के लिए नीचे पढ़ें.

ज़्यादा औपचारिक दस्तावेज़ के लिए, इन्हें देखें:

बैकग्राउंड

सॉफ़्टवेयर के मानकों को तय करने के लिए, प्लैटफ़ॉर्म और टूलचेन की शुरुआत की गई अलग-अलग मशीनों को टारगेट किया जाता है और उनमें सही भाषा के टूल बनाए जाते हैं.

यह Baज़ल की तुलना में हाल ही का है. हां प्रेरणा देने वाला यह देखा कि भाषा की देखरेख करने वाले लोग विज्ञापन में पहले से ऐसा कर रहे थे अमान्य, असंगत तरीके. उदाहरण के लिए, C++ नियम --cpu और --crosstool_top का इस्तेमाल करते हैं का इस्तेमाल कैसे किया जाता है. इनमें से कोई भी सही मॉडल नहीं है "प्लैटफ़ॉर्म". ऐसा करने की ऐतिहासिक कोशिशों की वजह से, बनाना अजीब और गलत तरीके से बना था. ये फ़्लैग, Java को कंपाइल करने की सुविधा को कंट्रोल नहीं करते हैं. इसने अपने सिस्टम में, --java_toolchain के साथ इंडिपेंडेंट इंटरफ़ेस.

Basel को बड़े, कई भाषाओं वाले, और कई प्लैटफ़ॉर्म पर काम करने वाले प्रोजेक्ट के लिए बनाया गया है. यह इन सिद्धांतों के लिए ज़्यादा सैद्धांतिक समर्थन की ज़रूरत है. इसमें ऐसे साफ़ एपीआई शामिल हैं जो भाषा और प्रोजेक्ट इंटरऑपरेबिलिटी को बढ़ावा दिया जा सके. ये नए एपीआई के लिए.

माइग्रेशन

प्लैटफ़ॉर्म और टूलचेन एपीआई सिर्फ़ तब काम करते हैं, जब प्रोजेक्ट उनका इस्तेमाल करते हैं. यह यह आसान नहीं है, क्योंकि प्रोजेक्ट के नियम लॉजिक, टूलचेन, डिपेंडेंसी, और select() को भी उनका साथ देना चाहिए. इसके लिए, माइग्रेशन का क्रम सोच-समझकर करना ज़रूरी है ताकि सभी प्रोजेक्ट और उनकी डिपेंडेंसी सही तरीके से काम करती रहे.

उदाहरण के लिए, Basel की C++ रूल इस्तेमाल करने वाले प्लैटफ़ॉर्म के लिए उपलब्ध हैं. हालांकि, Apple के नियम लागू नहीं होते. आपका C++ प्रोजेक्ट Apple की परवाह नहीं करती. हालांकि, अन्य हो सकते हैं. तो फ़िलहाल, सभी C++ बिल्ड के लिए प्लैटफ़ॉर्म को ग्लोबल लेवल पर चालू करना सुरक्षित नहीं है.

इस पेज के बाकी हिस्से में, माइग्रेशन के इस क्रम के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि कब और कैसे आपके प्रोजेक्ट काम आ सकते हैं.

लक्ष्य

जब सभी प्रोजेक्ट इस फ़ॉर्म के साथ तैयार होते हैं, तब Baज़र का प्लैटफ़ॉर्म माइग्रेशन पूरा हो जाता है:

bazel build //:myproject --platforms=//:myplatform

इसका मतलब है कि:

  1. आपके प्रोजेक्ट में जिन नियमों का इस्तेमाल किया जाता है वे सही टूलचेन का अनुमान लगा सकते हैं. //:myplatform.
  2. आपके प्रोजेक्ट की डिपेंडेंसी का इस्तेमाल करने वाले नियमों से, सही टूलचेन का पता लग सकता है //:myplatform से.
  3. या तो आपकी मदद के आधार पर ये प्रोजेक्ट, //:myplatform या आपका प्रोजेक्ट, लेगसी एपीआई (जैसे --crosstool_top) के साथ काम करता है.
  4. //:myplatform रेफ़रंस [सामान्य एलान][प्लैटफ़ॉर्म से जुड़ी सामान्य घोषणा]{: .external} CPU, OS, और अन्य सामान्य कॉन्सेप्ट हैं, जो ऑटोमैटिक क्रॉस-प्रोजेक्ट के साथ काम करते हैं साथ काम करता है.
  5. सभी संबंधित प्रोजेक्ट की select() से॰ //:myplatform की बताई गई मशीन की प्रॉपर्टी को समझता है.
  6. //:myplatform को ऐसी जगह पर बताया गया है जहां साफ़ तौर पर और फिर से इस्तेमाल किया जा सकता है: आपके प्रोजेक्ट के अगर यह प्लैटफ़ॉर्म आपके प्रोजेक्ट के हिसाब से अलग है, तो फिर से स्टोर करें. अगर ऐसा नहीं है, तो सभी प्रोजेक्ट में जो इस प्लैटफ़ॉर्म का इस्तेमाल कर सकते हैं.

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

क्या मुझे प्लैटफ़ॉर्म का इस्तेमाल करना चाहिए?

अगर आपको सिर्फ़ कोई प्रोजेक्ट बनाना या क्रॉस-कंपाइल करना है, तो आपको का आधिकारिक दस्तावेज़ पढ़ें.

अगर आप कोई प्रोजेक्ट, भाषा या टूलचेन मेंटेनर हैं, तो आपको ताकि नए एपीआई काम कर सकें. ग्लोबल माइग्रेशन पूरा होने तक इंतज़ार करें या नहीं या जल्दी ऑप्ट इन करना, आपकी लागत / लागत की ज़रूरतों पर निर्भर करता है:

मान

  • आपके पास अपनी पसंदीदा प्रॉपर्टी पर select() या टूलचेन चुनने का विकल्प होता है के बजाय --cpu जैसे हार्ड कोड किए गए फ़्लैग का इस्तेमाल किया होगा. उदाहरण के लिए, एक से ज़्यादा सीपीयू एक ही निर्देशों के सेट का इस्तेमाल किया जा सकता हो.
  • ज़्यादा सही बिल्ड. अगर ऊपर दिए गए उदाहरण में आपने --cpu से select() किया है, तो एक नया सीपीयू जोड़ें जो उसी निर्देश सेट के साथ काम करता हो, select() नए CPU को पहचानने में विफल. हालांकि, प्लैटफ़ॉर्म पर select() का डेटा सही है.
  • बेहतर उपयोगकर्ता अनुभव. सभी प्रोजेक्ट जानते हैं: --platforms=//:myplatform. कई भाषाओं के लिए कोई ज़रूरत नहीं है फ़्लैग जोड़ें.
  • आसान भाषा डिज़ाइन. परिभाषित करने के लिए सभी भाषाएं एक समान एपीआई शेयर करती हैं बनाने, टूलचेन का इस्तेमाल करने, और प्लैटफ़ॉर्म के लिए सही टूलचेन चुनने में मदद करता है.
  • टारगेट को स्किप किया जा सकता है बिल्ड और टेस्ट करें, अगर वे टारगेट प्लैटफ़ॉर्म के साथ काम न करते हों.

लागत

  • ऐसा हो सकता है कि जो डिपेंडेंट प्रोजेक्ट, प्लैटफ़ॉर्म के साथ काम नहीं करते वे अपने-आप काम न करें सबसे सही तरीके.
  • इन्हें काम करने के लिए, हो सकता है कि कुछ समय के लिए अतिरिक्त रखरखाव की ज़रूरत हो.
  • नए और लेगसी एपीआई के साथ काम करने के लिए, उपयोगकर्ता के लिए सावधानी बरतने की ज़रूरत होती है, ताकि भ्रम की स्थिति से बचें.
  • सामान्य प्रॉपर्टी के लिए कैननिकल परिभाषाएं, जैसे कि OS और CPU को बेहतर बनाया जा रहा है. इसके लिए, हो सकता है कि आपको कुछ और योगदान देने पड़ें.
  • अलग-अलग भाषाओं के लिए बने टूलचेन की कैननिकल परिभाषाएं अब भी बेहतर हो रही हैं और हो सकता है कि आपको अतिरिक्त योगदान देना पड़े.

एपीआई की समीक्षा

platform constraint_value टारगेट:

platform(
    name = "myplatform",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)

constraint_value एक मशीन है प्रॉपर्टी. एक जैसी "तरह" की वैल्यू एक कॉमन के तहत ग्रुप किए जाते हैं. constraint_setting:

constraint_setting(name = "os")
constraint_value(
    name = "linux",
    constraint_setting = ":os",
)
constraint_value(
    name = "mac",
    constraint_setting = ":os",
)

toolchain, स्टारलार्क का नियम है. यह एट्रिब्यूट किसी भाषा के टूल के बारे में बताते हैं (जैसे कि compiler = "//mytoolchain:custom_gcc"). इसके सेवा देने वालों का पास यह जानकारी उन नियमों के लिए है जिन्हें इन टूल की मदद से बनाने की ज़रूरत है.

टूलचेन से, constraint_value मशीनों के बारे में पता चलता है टारगेट (target_compatible_with = ["@platforms//os:linux"]) और उनके टूल यह काम कर सकते हैं इस पर चलाएं (exec_compatible_with = ["@platforms//os:mac"]).

$ bazel build //:myproject --platforms=//:myplatform को तैयार करते समय, Basel अपने-आप ऐसा टूलचेन चुनता है जो बिल्ड मशीन पर चल सकता है और //:myplatform के लिए बाइनरी बनाएं. इसे टूलचेन रिज़ॉल्यूशन के नाम से जाना जाता है.

उपलब्ध टूलचेन के सेट को WORKSPACE में, इसके साथ रजिस्टर किया जा सकता है register_toolchains या कमांड लाइन, --extra_toolchains शामिल है.

ज़्यादा जानकारी के लिए यहां देखें.

स्थिति

मौजूदा प्लैटफ़ॉर्म पर यह सुविधा, अलग-अलग भाषाओं में उपलब्ध है. बेज़ल के सभी मुख्य नियम हैं प्लैटफ़ॉर्म पर जाने में कितना समय लगा. हालांकि, इस प्रोसेस में समय लगेगा. ऐसा तीन मुख्य वजहों से होता है:

  1. नए टूलचैन से टूल की जानकारी पाने के लिए, नियम तर्क को अपडेट करना ज़रूरी है एपीआई (ctx.toolchains) इस्तेमाल कर सकते हैं और लेगसी सेटिंग को पढ़ना बंद कर सकते हैं, जैसे कि --cpu और --crosstool_top. यह ज़्यादा आसान है.

  2. टूलचेन में, रखरखाव करने वाले लोगों को टूलचेन तय करनी चाहिए. साथ ही, उन्हें ऐसा बनाना चाहिए कि सभी उपयोगकर्ता (GitHub डेटा स्टोर करने की जगह और WORKSPACE एंट्री में). यह तकनीकी तौर पर आसान है. हालांकि, इसे सही तरीके से व्यवस्थित किया जाना चाहिए, ताकि उपयोगकर्ता अनुभव आसान बनाए रखने के लिए किया जा सकता है.

    प्लैटफ़ॉर्म की परिभाषाएं भी ज़रूरी हैं (जब तक कि एक ही मशीन के लिए ऐसा न किया जा रहा हो) Basel चलता है). आम तौर पर, प्रोजेक्ट को अपने प्लैटफ़ॉर्म तय करने चाहिए.

  3. मौजूदा प्रोजेक्ट माइग्रेट करने होंगे. select() और ट्रांज़िशन भी होना चाहिए माइग्रेट किए गए. यह सबसे बड़ी चुनौती है. यह उन लोगों के लिए खास तौर पर चुनौती भरा है जो कई भाषाओं वाले प्रोजेक्ट (जो तब काम करना बंद कर सकते हैं, जब सभी भाषाएं नहीं पढ़ी जा सकतीं --platforms).

अगर आप नया नियम सेट डिज़ाइन कर रहे हैं, तो आपको शुरुआत. इससे आपके नियम अपने-आप ही अन्य नियम और प्रोजेक्ट, जिनमें प्लैटफ़ॉर्म एपीआई बनने का मतलब है कि और हर जगह उपलब्ध.

सामान्य प्लैटफ़ॉर्म प्रॉपर्टी

OS और CPU जैसी प्लैटफ़ॉर्म प्रॉपर्टी, जो सभी प्रोजेक्ट में एक जैसी हैं उन्हें एक मानक और एक ही जगह पर रखा जाएगा. इससे क्रॉस-प्रोजेक्ट को बढ़ावा मिलता है और दूसरी भाषाओं में काम करने की सुविधा मिलती है.

उदाहरण के लिए, अगर MyApp में constraint_value पर select() है @myapp//cpus:arm और SomeCommonLib के पास select() का ऐक्सेस है @commonlib//constraints:arm, ये उनकी "आर्म" को ट्रिगर करते हैं के साथ काम न करने वाले मोड शर्तें.

दुनिया भर की सामान्य प्रॉपर्टी के बारे में जानकारी @platforms डेटा स्टोर करने की जगह (इसलिए, ऊपर दिए गए उदाहरण के लिए कैननिकल लेबल @platforms//cpu:arm है). लैंग्वेज-कॉमन प्रॉपर्टी को उनसे जुड़ी जगहों की जानकारी में शामिल किया जाना चाहिए भाषाएं.

डिफ़ॉल्ट प्लैटफ़ॉर्म

आम तौर पर, प्रोजेक्ट के मालिकों को प्लैटफ़ॉर्म का इस्तेमाल करके जो वे बनाना चाहते हैं. इसके बाद, ये ट्रिगर --platforms.

--platforms के सेट न होने पर, Baze डिफ़ॉल्ट रूप से platform को दिखाता है. यह लोकल बिल्ड मशीन. यह @local_config_platform//:host पर अपने-आप जनरेट हुआ है इसलिए, इसे साफ़ तौर पर बताने की ज़रूरत नहीं है. यह लोकल मशीन के OS को मैप करता है और CPU के साथ constraint_value का एलान किया गया @platforms.

C++

जब आप सेट करते हैं, तो बेज़ल के C++ नियम टूलचेन चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं --incompatible_enable_cc_toolchain_resolution अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (#7260).

इसका मतलब है कि C++ प्रोजेक्ट को इनके साथ कॉन्फ़िगर किया जा सकता है:

bazel build //:my_cpp_project --platforms=//:myplatform

के बजाय:

bazel build //:my_cpp_project` --cpu=... --crosstool_top=...  --compiler=...

अगर आपका प्रोजेक्ट सिर्फ़ C++ है और गैर-C++ प्रोजेक्ट पर निर्भर नहीं है, तो सुरक्षित रखने के लिए, select और ट्रांज़िशन का इस्तेमाल किया जा सकता है. यहां जाएं: #7260 और ज़्यादा जानकारी के लिए, C++ टूलचेन कॉन्फ़िगर करना.

यह मोड डिफ़ॉल्ट रूप से चालू नहीं होता. ऐसा इसलिए है, क्योंकि Apple C++ डिपेंडेंसी को अब भी --cpu और --crosstool_top के साथ कॉन्फ़िगर करें (उदाहरण). इसलिए, यह प्लैटफ़ॉर्म पर माइग्रेट किए जा रहे Apple के नियमों पर निर्भर करता है.

Java

बेज़ेल के Java के नियम, प्लैटफ़ॉर्म का इस्तेमाल करते हैं.

यह लेगसी फ़्लैग --java_toolchain, --host_java_toolchain की जगह लेगा, --javabase और --host_javabase.

कॉन्फ़िगरेशन फ़्लैग का इस्तेमाल करने का तरीका जानने के लिए, Bazu और Java मैन्युअल देखें. ज़्यादा जानकारी के लिए, डिज़ाइन दस्तावेज़ देखें.

अगर अब भी लेगसी फ़्लैग का इस्तेमाल किया जा रहा है, तो समस्या #7849 में दी गई माइग्रेशन प्रोसेस अपनाएं.

Android

जब आप सेट करते हैं, तब Bagel के Android नियम, टूलचेन को चुनने के लिए प्लैटफ़ॉर्म का इस्तेमाल करते हैं --incompatible_enable_android_toolchain_resolution.

यह सुविधा डिफ़ॉल्ट रूप से चालू नहीं होती. लेकिन माइग्रेशन जारी है.

Apple

Basel के Apple के नियम, फ़िलहाल Apple के टूलचेन को चुनने के लिए किसी प्लैटफ़ॉर्म का इस्तेमाल नहीं करते.

ये प्लैटफ़ॉर्म के साथ काम करने वाली C++ डिपेंडेंसी के साथ भी काम नहीं करते, क्योंकि वे C++ टूलचेन सेट करने के लिए --crosstool_top का लेगसी वर्शन इस्तेमाल करें. जब तक इसे माइग्रेट नहीं किया जाता, Apple प्रोजेक्ट को platorm-चालू C++ के साथ प्लैटफ़ॉर्म जोड़ सकता है मैपिंग (उदाहरण).

अन्य भाषाएं

अगर आपको किसी नई भाषा के लिए नियम तय करने हैं, तो प्लैटफ़ॉर्म इस्तेमाल करें का इस्तेमाल करके, अपनी भाषा के टूलचेन को चुना जा सकता है. ज़्यादा जानकारी के लिए, toolchains से जुड़े दस्तावेज़ पढ़ें.

select()

प्रोजेक्ट चालू select() किए जा सकते हैं constraint_value लक्ष्य, लेकिन पूरे नहीं प्लैटफ़ॉर्म. इसे जान-बूझकर इसलिए बनाया गया है, ताकि select() ज़्यादा से ज़्यादा कई तरह के मशीन लर्निंग का इस्तेमाल करते हैं. ARM-खास सोर्स वाली लाइब्रेरी को सभी ARM फ़ंक्शन वाली मशीन का इस्तेमाल किया जा सकता है. ऐसा तब तक किया जा सकता है, जब तक कि ज़्यादा सटीक जानकारी न दी जा सके.

एक या उससे ज़्यादा constraint_value चुनने के लिए, इनका इस्तेमाल करें:

config_setting(
    name = "is_arm",
    constraint_values = [
        "@platforms//cpu:arm",
    ],
)

यह --cpu पर पारंपरिक रूप से चुनने के बराबर है:

config_setting(
    name = "is_arm",
    values = {
        "cpu": "arm",
    },
)

ज़्यादा जानकारी के लिए यहां जाएं.

--cpu, --crosstool_top वगैरह पर मौजूद select, --platforms को समझ नहीं पाते हैं. टास्क कब शुरू होगा अपने प्रोजेक्ट को प्लैटफ़ॉर्म पर माइग्रेट करना है, तो आपको उन्हें constraint_values या सहायता के लिए प्लैटफ़ॉर्म मैपिंग का इस्तेमाल करें माइग्रेशन विंडो से दोनों स्टाइल के लिए.

ट्रांज़िशन

स्टारलार्क ट्रांज़िशन में बदलाव आपके बिल्ड ग्राफ़ के हिस्सों को फ़्लैग करता है. अगर आपके प्रोजेक्ट में किसी ऐसे ट्रांज़िशन का इस्तेमाल किया जाता है जो --cpu, --crossstool_top या अन्य लेगसी फ़्लैग सेट करता है. --platforms को ये बदलाव नहीं दिखेंगे.

अपने प्रोजेक्ट को प्लैटफ़ॉर्म पर माइग्रेट करते समय, आपको या तो इन बदलावों को बदलना होगा return { "//command_line_option:platforms": "//:my_arm_platform" } के लिए return { "//command_line_option:cpu": "arm" } या प्लैटफ़ॉर्म का इस्तेमाल करें माइग्रेशन के दौरान दोनों स्टाइल का इस्तेमाल करने के लिए मैपिंग विंडो.

आज प्लैटफ़ॉर्म इस्तेमाल करने का तरीका

अगर आपको सिर्फ़ कोई प्रोजेक्ट बनाना या क्रॉस-कंपाइल करना है, तो आपको आधिकारिक दस्तावेज़ पढ़ें. यह भाषा और प्रोजेक्ट मेंटेन करने वालों पर निर्भर करता है कि तय करते हैं कि प्लैटफ़ॉर्म के साथ कब और कैसे इंटिग्रेट करना है और उनके फ़ायदे क्या हैं.

अगर आप कोई प्रोजेक्ट, भाषा या टूलचेन मेंटेनर हैं और आपका बिल्ड डिफ़ॉल्ट रूप से प्लेटफ़ॉर्म का उपयोग करते हैं, तो आपके पास तीन विकल्प (वैश्विक स्तर पर आने के माइग्रेशन):

  1. "प्लैटफ़ॉर्म इस्तेमाल करें" पर टैप करें फ़्लैग कर सकते है (अगर उनके पास है एक) और टेस्ट करें. इससे, आपको यह पता चल सकेगा कि ऐसे प्रोजेक्ट जिन पर आपको काम करने की ज़रूरत है काम नहीं करता.

  2. अगर आपके पसंदीदा प्रोजेक्ट अब भी पुराने फ़्लैग पर निर्भर हैं, जैसे कि --cpu और --crosstool_top, --platforms के साथ इनका इस्तेमाल करें:

    bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...
    

    इसमें रखरखाव की कुछ लागत है (आपको मैन्युअल रूप से यह पक्का करना होगा कि सेटिंग मिलान). लेकिन नाराज़गी के अभाव में यह काम करना चाहिए ट्रांज़िशन.

  3. इसके ज़रिए दोनों स्टाइल का इस्तेमाल करने के लिए प्लैटफ़ॉर्म मैपिंग लिखें --cpu-स्टाइल सेटिंग को संबंधित प्लैटफ़ॉर्म से मैप कर सकते हैं और इसके साथ उन्हें मैप कर सकते हैं.

प्लैटफ़ॉर्म मैपिंग

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

प्लैटफ़ॉर्म मैपिंग, platform() से लेकर के सेट का इस्तेमाल कर सकते हैं. उदाहरण के लिए:

platforms:
  # Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
  //platforms:ios
    --cpu=ios_x86_64
    --apple_platform_type=ios

flags:
  # Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
  --cpu=ios_x86_64
  --apple_platform_type=ios
    //platforms:ios

  # Maps "--cpu=darwin --apple_platform_type=macos" to "//platform:macos".
  --cpu=darwin
  --apple_platform_type=macos
    //platforms:macos

Basel का इस्तेमाल, प्लैटफ़ॉर्म-आधारित और वे पूरे बिल्ड में लगातार इस्तेमाल किए जाते हैं. इनमें शामिल हैं ट्रांज़िशन.

डिफ़ॉल्ट रूप से Basel, आपके ब्राउज़र में मौजूद platform_mappings फ़ाइल में मौजूद मैप को पढ़ता है फ़ाइल फ़ोल्डर रूट. इन्हें भी सेट किया जा सकता है --platform_mappings=//:my_custom_mapping.

यहां जाएं: यहां देखें.

सवाल

माइग्रेशन की समयावधि के बारे में सामान्य सहायता और सवालों के लिए, यहां संपर्क करें bazel-discuss@googlegroups.com या लागू नियमों के स्वामी हैं.

प्लैटफ़ॉर्म/टूलचेन एपीआई के डिज़ाइन और आगे बढ़ने पर चर्चा करने के लिए, संपर्क bazel-dev@googlegroups.com.

इन्हें भी देखें