किसको दिखाई दे

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

इस पेज पर बेज़ल के दो विज़िबिलिटी सिस्टम के बारे में बताया गया है: टारगेट किसको दिखे और लोड किसको दिखे.

विज़िबिलिटी से जुड़ी दोनों सुविधाएं, अन्य डेवलपर को आपके ऐप्लिकेशन के बीच अंतर करने में मदद करती हैं सार्वजनिक API और उसे लागू करने से जुड़ी जानकारी शामिल है. साथ ही, स्ट्रक्चर को लागू करने में मदद की जाती है जैसे-जैसे आपका वर्कस्पेस बढ़ता है. किसी सार्वजनिक खाते का इस्तेमाल बंद करने के लिए भी, 'किसको दिखे' सेटिंग का इस्तेमाल किया जा सकता है मौजूदा उपयोगकर्ताओं को अनुमति देने और नए उपयोगकर्ताओं को अनुमति न देने के लिए एपीआई.

दिखने वाले टारगेट (विज्ञापन के लिए सही दर्शक चुनना)

टारगेट विज़िबिलिटी: यह कंट्रोल करती है कि आपके टारगेट पर कौन निर्भर कर सकता है — यानी कि deps जैसी किसी एट्रिब्यूट में अपने टारगेट के लेबल का इस्तेमाल करें.

टारगेट A, टारगेट B को दिखता है. ऐसा तब होता है, जब वे एक ही पैकेज में हों या A, B के पैकेज को देखने की अनुमति देता है. इस तरह, पैकेज इसकी इकाई होते हैं: ऐक्सेस देने या न देने का फ़ैसला लेने के लिए, जानकारी का स्तर. अगर B, A पर निर्भर करता है लेकिन B को A नहीं दिखता. फिर भी, B बनाने की कोशिश फ़ेल हो जाएगी विश्लेषण.

ध्यान दें कि किसी पैकेज को दिखने की अनुमति देने से, अपने-आप दिखने की अनुमति नहीं मिल जाती सबपैकेज में बदल जाएगा. पैकेज और सबपैकेज के बारे में ज़्यादा जानकारी के लिए, यहां देखें सिद्धांत और शब्दावली.

प्रोटोटाइपिंग के लिए, आप --check_visibility=false को फ़्लैग करें. प्रोडक्शन ट्रैक के इस्तेमाल में ऐसा नहीं किया जाना चाहिए सबमिट किया गया कोड.

दृश्यता नियंत्रित करने का प्राथमिक तरीका यह है visibility एट्रिब्यूट चालू है नियम वाले टारगेट. इस सेक्शन में, इस एट्रिब्यूट के फ़ॉर्मैट के साथ-साथ, टारगेट की विज़िबिलिटी तय की जा सकती है.

प्रॉडक्ट के दिखने की जानकारी

नियम के सभी टारगेट में एक visibility एट्रिब्यूट होता है, जो लेबल की सूची लेता है. हर लेबल में निम्न में से एक फ़ॉर्म है. पिछले फ़ॉर्म को छोड़कर, ये सिर्फ़ वाक्यात्मक प्लेसहोल्डर हैं जो किसी असल टारगेट से जुड़े नहीं हैं.

• "//visibility:public": सभी पैकेज का ऐक्सेस देता है. (जोड़ा नहीं जा सकता में उपलब्ध है.)

• "//visibility:private": कोई अतिरिक्त ऐक्सेस नहीं देता है; केवल लक्ष्य इस पैकेज में इस टारगेट का इस्तेमाल किया जा सकता है. (किसी अन्य के साथ जोड़ा नहीं जा सकता specification.)

• "//foo/bar:__pkg__": //foo/bar को ऐक्सेस देता है (लेकिन इसकी नहीं सबपैकेज).

• "//foo/bar:__subpackages__": //foo/bar और इसकी सभी चीज़ों को ऐक्सेस देता है डायरेक्ट और इनडायरेक्ट हर तरह के सबपैकेज.

• "//some_pkg:my_package_group": यह ऐसे सभी पैकेज का ऐक्सेस देता है दिए गए package_group का हिस्सा हैं.

  • पैकेज ग्रुप इसका इस्तेमाल करते हैं: अलग-अलग सिंटैक्स पैकेज तय करने में मदद मिलती है. पैकेज ग्रुप में मौजूद फ़ॉर्म "//foo/bar:__pkg__" और "//foo/bar:__subpackages__" क्रम से हैं "//foo/bar" और "//foo/bar/..." से बदला गया. इसी तरह, "//visibility:public" और "//visibility:private" सिर्फ़ "public" हैं और "private".

उदाहरण के लिए, अगर //some/package:mytarget के visibility को [":__subpackages__", "//tests:__pkg__"] है, तो इसका इस्तेमाल किसी भी टारगेट में किया जा सकता है जो //some/package/... सोर्स ट्री का हिस्सा है. साथ ही, तय किए गए टारगेट //tests/BUILD में, लेकिन //tests/integration/BUILD में तय किए गए टारगेट के हिसाब से नहीं.

सबसे सही तरीका: एक ही सेट के लिए, कई टारगेट दिखाना के पैकेज में से, हर एक में सूची को दोहराने के बजाय package_group का इस्तेमाल करें टारगेट का visibility एट्रिब्यूट. इससे कॉन्टेंट पढ़ना आसान हो जाता है और सूचियों को सिंक करने से रोका जाता है.

नियम टारगेट किसको दिखे

नियम के टारगेट की विज़िबिलिटी:

1. अगर सेट हो, तो इसके visibility एट्रिब्यूट की वैल्यू; या फिर

2. इस कीवर्ड का मान default_visibility यहां दिए गए विकल्पों में से package स्टेटमेंट टारगेट की BUILD फ़ाइल, अगर ऐसा कोई एलान मौजूद है; या फिर

3. //visibility:private.

सबसे सही तरीका: default_visibility को सार्वजनिक के तौर पर सेट करने से बचें. यह हो सकता है यह प्रोटोटाइप करने या छोटे कोडबेस में सुविधाजनक है, लेकिन अनजाने में कोडबेस के बढ़ने के साथ-साथ सार्वजनिक टारगेट बनाने से जुड़ी बढ़ोतरी होती है. वह होना बेहतर है यह साफ़ तौर पर बताया गया है कि कौनसे टारगेट पैकेज के सार्वजनिक इंटरफ़ेस का हिस्सा हैं.

उदाहरण

फ़ाइल //frobber/bin/BUILD:

# This target is visible to everyone
cc_binary(
    name = "executable",
    visibility = ["//visibility:public"],
    deps = [":library"],
)

# This target is visible only to targets declared in the same package
cc_library(
    name = "library",
    # No visibility -- defaults to private since no
    # package(default_visibility = ...) was used.
)

# This target is visible to targets in package //object and //noun
cc_library(
    name = "subject",
    visibility = [
        "//noun:__pkg__",
        "//object:__pkg__",
    ],
)

# See package group "//frobber:friends" (below) for who can
# access this target.
cc_library(
    name = "thingy",
    visibility = ["//frobber:friends"],
)

फ़ाइल //frobber/BUILD:

# This is the package group declaration to which target
# //frobber/bin:thingy refers.
#
# Our friends are packages //frobber, //fribber and any
# subpackage of //fribber.
package_group(
    name = "friends",
    packages = [
        "//fribber/...",
        "//frobber",
    ],
)

जनरेट की गई फ़ाइल का टारगेट किसको दिखे

जनरेट की गई फ़ाइल का टारगेट, उस नियम के टारगेट के जैसा ही दिखेगा जनरेट करता है.

सोर्स फ़ाइल का टारगेट विज़िबिलिटी

आप exports_files. जब visibility न हो तर्क exports_files को पास किया जाता है, तो इससे विज़िबिलिटी सार्वजनिक हो जाती है. जनरेट की गई फ़ाइल के दिखने की सेटिंग बदलने के लिए, exports_files का इस्तेमाल नहीं किया जा सकता.

exports_files को किए गए कॉल में नहीं दिखाई देने वाले सोर्स फ़ाइल टारगेट के लिए, फ़्लैग की वैल्यू, उसके दिखने की स्थिति पर निर्भर करती है --incompatible_no_implicit_file_export:

• अगर फ़्लैग सेट है, तो 'किसको दिखे' सेटिंग 'निजी' के तौर पर सेट होती है.

• ऐसा नहीं होने पर, लेगसी व्यवहार लागू होता है: 'प्रॉडक्ट किसको दिखे' सेटिंग BUILD फ़ाइल default_visibility है. अगर यह डिफ़ॉल्ट रूप से दिख रही है, तो फ़ाइल निजी के तौर पर सेट है तय नहीं है.

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

सबसे सही तरीका: जब मुमकिन हो, तब उपयोगकर्ता के सामने सोर्स फ़ाइल के लिए उपलब्ध है. उदाहरण के लिए, किसी .java फ़ाइल पर exports_files को कॉल करने के बजाय, फ़ाइल को गैर-निजी java_library टारगेट में रैप करें. आम तौर पर, नियम टारगेट सिर्फ़ उन सोर्स फ़ाइलों का सीधे तौर पर रेफ़रंस देना चाहिए जो उसी पैकेज में मौजूद होती हैं.

उदाहरण

फ़ाइल //frobber/data/BUILD:

exports_files(["readme.txt"])

फ़ाइल //frobber/bin/BUILD:

cc_binary(
  name = "my-program",
  data = ["//frobber/data:readme.txt"],
)

कॉन्फ़िगरेशन सेटिंग किसको दिखे

ऐतिहासिक रूप से, Bazu ने इसके लिए दृश्यता लागू नहीं की है config_setting टारगेट select() की कुंजियों में रेफ़र किया गया है. यह लीजिए इस लेगसी व्यवहार को हटाने के लिए दो फ़्लैग हैं:

• --incompatible_enforce_config_setting_visibility टारगेट के लिए विज़िबिलिटी जांच की सुविधा चालू कर देता है. माइग्रेशन में मदद करने के लिए, इसकी वजह से ऐसा config_setting भी होता है जो visibility को नहीं बताता सार्वजनिक माना जाता है (पैकेज-लेवल default_visibility पर ध्यान दिए बिना).

• --incompatible_config_setting_private_default_visibility की वजह से config_setting होता है जोvisibility पैकेज का default_visibility और निजी दृश्यता पर फ़ॉलबैक के लिए, बस की तरह ही टारगेट किया जा सकता है. कोई काम नहीं होगा, अगर --incompatible_enforce_config_setting_visibility सेट नहीं है.

लेगसी व्यवहार पर भरोसा करने से बचें. कोई भी config_setting, जिसका मकसद का उपयोग वर्तमान पैकेज के बाहर किया जाना चाहिए, तो एक स्पष्ट visibility होना चाहिए, यदि पैकेज पहले से ही सही default_visibility तय नहीं कर रहा है.

पैकेज ग्रुप का टारगेट किसको दिखे

package_group टारगेट में visibility एट्रिब्यूट नहीं है. वे हमेशा सार्वजनिक रूप से दृश्यमान.

इंप्लिसिट डिपेंडेंसी की विज़िबिलिटी

कुछ नियमों में इंप्लिसिट डिपेंडेंसी होती है — ऐसी डिपेंडेंसी जो BUILD फ़ाइल में नहीं लिखी गई हैं, लेकिन हर इंस्टेंस पर लागू करें. उदाहरण के लिए, cc_library नियम की मदद से इसके हर नियम टारगेट से एक्ज़ीक्यूटेबल टारगेट तक इंप्लिसिट डिपेंडेंसी जो C++ कंपाइलर का प्रतिनिधित्व करता है.

इंप्लिसिट डिपेंडेंसी की विज़िबिलिटी वह पैकेज जिसमें .bzl फ़ाइल शामिल है, जिसमें नियम (या पहलू) तय किया गया है. तय सीमा में उदाहरण के लिए, C++ कंपाइलर तब तक निजी रह सकता है, जब तक वह पैकेज को cc_library नियम की परिभाषा के तौर पर मार्क करना चाहिए. फ़ॉलबैक के तौर पर, अगर परिभाषा में इंप्लिसिट डिपेंडेंसी नहीं दिख रही है. इसकी मदद से जांच की जाती है cc_library टारगेट के मुताबिक.

आप इसे अक्षम करके इस व्यवहार को बदल सकते हैं --incompatible_visibility_private_attributes_at_definition. बंद होने पर, इंप्लिसिट डिपेंडेंसी को किसी दूसरी डिपेंडेंसी की तरह माना जाता है. इसका मतलब है कि जिस टारगेट पर निर्भर रहना है (जैसे कि हमारा C++ कंपाइलर) नियम के हर इंस्टेंस पर दिखेगा. आम तौर पर, इसका मतलब यह होता है कि सार्वजनिक तौर पर दिखना चाहिए.

अगर आपको किसी नियम के इस्तेमाल को कुछ खास पैकेज तक सीमित करना है, तो इसके बजाय, load दिखने की सुविधा का इस्तेमाल करें.

विज़िबिलिटी लोड करें

लोड दिखने की सेटिंग से यह कंट्रोल किया जाता है कि .bzl फ़ाइल को किसी अन्य प्लैटफ़ॉर्म से लोड किया जा सकता है या नहीं BUILD या .bzl फ़ाइलें.

जिस तरह टारगेट विज़िबिलिटी, इनकैप्सुलेट किए गए सोर्स कोड को टारगेट करती है उसी तरह टारगेट के हिसाब से, लोड के हिसाब से दिखने की सेटिंग, उस बिल्ड लॉजिक को सुरक्षित रखती है जिसे .bzl ने एन्क्रिप्ट (सुरक्षित) किया है फ़ाइलें शामिल हैं. उदाहरण के लिए, हो सकता है कि BUILD फ़ाइल का लेखक, कुछ दोहराव वाले फ़ैक्टर शामिल करना चाहे .bzl फ़ाइल में मैक्रो में लक्षित परिभाषाएं. लोड से सुरक्षा के बिना नहीं दिखाई देता है, तो हो सकता है कि वे अपने मैक्रो को ताकि मैक्रो में बदलाव करने से दूसरी टीमों के बिल्ड.

ध्यान दें कि .bzl फ़ाइल से जुड़ा सोर्स फ़ाइल टारगेट हो भी सकता है और नहीं भी. अगर ऐसा होता है, तो इस बात की कोई गारंटी नहीं है कि पेज के लोड होने की स्थिति और टारगेट विज़िबिलिटी मेल खा रही है. इसका मतलब है कि वही BUILD फ़ाइल, .bzl फ़ाइल है, लेकिन उसे filegroup के srcs में शामिल नहीं है, और इसके विपरीत. इसकी वजह से कभी-कभी, नियमों का पालन करने में समस्या आ सकती है सोर्स कोड के तौर पर .bzl फ़ाइलें, जैसे कि दस्तावेज़ जनरेट करने या जांच करने के लिए.

प्रोटोटाइपिंग के लिए, 'लोड किसको दिखे' सेटिंग बंद करके, यह तय किया जा सकता है कि --check_bzl_visibility=false. --check_visibility=false की तरह ही, इसमें सबमिट किए गए कोड के लिए ऐसा नहीं किया जाता है.

Basel 6.0 के बाद से, लोड होने की सुविधा उपलब्ध है.

यह तय किया जा रहा है कि कॉन्टेंट लोड हो रहा है या नहीं

.bzl फ़ाइल की लोड दृश्यता सेट करने के लिए, visibility() फ़ंक्शन का इस्तेमाल किया जा सकता है. visibility() का तर्क, पैकेज विशिष्टताओं की एक सूची है, ठीक इसकी packages विशेषता package_group. हालांकि, visibility() नेगेटिव पैकेज स्वीकार नहीं करता है खास जानकारी.

visibility() को कॉल, हर फ़ाइल के लिए सिर्फ़ एक बार ही होना चाहिए, न कि ऊपर के लेवल पर फ़ंक्शन के अंदर) और आम तौर पर load() स्टेटमेंट के तुरंत बाद.

'टारगेट किसको दिखे' सेटिंग के उलट, लोड होने की डिफ़ॉल्ट सेटिंग हमेशा 'सार्वजनिक' के तौर पर सेट रहती है. फ़ाइल जो visibility() को कॉल नहीं करते हैं, वे हमेशा name@yourcompany.com जैसा कोई प्रोफ़ेशनल ईमेल पता बनाएं. इससे आपका कारोबार ज़्यादा भरोसेमंद बनेगा. किसी भी शब्द के सबसे ऊपर visibility("private") जोड़ना बेहतर होगा नई .bzl फ़ाइल, जिसे खास तौर पर पैकेज के बाहर इस्तेमाल करने के लिए न बनाया गया हो.

उदाहरण

# //mylib/internal_defs.bzl

# Available to subpackages and to mylib's tests.
visibility(["//mylib/...", "//tests/mylib/..."])

def helper(...):
    ...

# //mylib/rules.bzl

load(":internal_defs.bzl", "helper")
# Set visibility explicitly, even though public is the default.
# Note the [] can be omitted when there's only one entry.
visibility("public")

myrule = rule(
    ...
)

# //someclient/BUILD

load("//mylib:rules.bzl", "myrule")          # ok
load("//mylib:internal_defs.bzl", "helper")  # error

...

कॉन्टेंट दिखने के तरीके लोड करें

इस सेक्शन में, कॉन्टेंट लोड होने से जुड़ी सूचनाओं को मैनेज करने के बारे में सलाह दी गई है.

दिखने वाले विज्ञापनों के फ़ैक्टर तय करना

जब कई .bzl फ़ाइलों के दिखने की सेटिंग एक जैसी होनी चाहिए, तो एक सामान्य सूची में पैकेज के स्पेसिफ़िकेशन की जानकारी शामिल करती है. उदाहरण के लिए:

# //mylib/internal_defs.bzl

visibility("private")

clients = [
    "//foo",
    "//bar/baz/...",
    ...
]

# //mylib/feature_A.bzl

load(":internal_defs.bzl", "clients")
visibility(clients)

...

# //mylib/feature_B.bzl

load(":internal_defs.bzl", "clients")
visibility(clients)

...

इससे अलग-अलग .bzl फ़ाइलों के बीच अचानक किसी तरह के बदलाव से बचा जा सकता है दिखाई दे. clients सूची बड़ी होने पर भी, इसे आसानी से पढ़ा जा सकता है.

विज़ुअल तौर पर लिखना

कभी-कभी हो सकता है कि .bzl फ़ाइल, अनुमति वाली सूची में दिखे इसमें अनुमति वाली कई छोटी-छोटी सूची होती हैं. यह दिखाता है कि package_group इसके ज़रिए अन्य package_group को शामिल कर सकता है: includes एट्रिब्यूट.

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

# //mylib/macros.bzl

load(":internal_defs.bzl", "our_packages")
load("//some_big_client:defs.bzl", "their_remaining_uses)

# List concatenation. Duplicates are fine.
visibility(our_packages + their_remaining_uses)

पैकेज ग्रुप की डुप्लीकेट कॉपी हटाई जा रही हैं

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

# //mylib/BUILD

load(":internal_defs", "clients")

package_group(
    name = "my_pkg_grp",
    packages = clients,
)

यह सिर्फ़ तब काम करता है, जब सूची में कोई नेगेटिव पैकेज न हो खास जानकारी.

अलग-अलग सिंबल की सुरक्षा

कोई भी Starlark चिह्न जिसका नाम अंडरस्कोर से शुरू होता है उसे लोड नहीं किया जा सकता दूसरी फ़ाइल से भी संबंधित है. इसकी मदद से, आसानी से निजी सिंबल बनाए जा सकते हैं. हालांकि, इसमें ऐसा करने की अनुमति नहीं है आप इन चिह्नों को भरोसेमंद फ़ाइलों के सीमित सेट के साथ शेयर कर सकते हैं. दूसरे पर इससे, आपको यह कंट्रोल करने की सुविधा मिलती है कि अन्य पैकेज किस तरह के हैं .bzl file, लेकिन यह आपको किसी भी बिना अंडरस्कोर वाले निशान को रोकने की अनुमति नहीं देता लोड हो रहा है.

अच्छी बात यह है कि और बेहतर कंट्रोल पाने के लिए, इन दोनों सुविधाओं को मिलाया जा सकता है.

# //mylib/internal_defs.bzl

# Can't be public, because internal_helper shouldn't be exposed to the world.
visibility("private")

# Can't be underscore-prefixed, because this is
# needed by other .bzl files in mylib.
def internal_helper(...):
    ...

def public_util(...):
    ...

# //mylib/defs.bzl

load(":internal_defs", "internal_helper", _public_util="public_util")
visibility("public")

# internal_helper, as a loaded symbol, is available for use in this file but
# can't be imported by clients who load this file.
...

# Re-export public_util from this file by assigning it to a global variable.
# We needed to import it under a different name ("_public_util") in order for
# this assignment to be legal.
public_util = _public_util

bzl-विज़िबिलिटी बिल्डिफ़ायर लिंट

बिल्डिफ़ायर लिंट है इस एपीआई की मदद से, अगर उपयोगकर्ता internal नाम की डायरेक्ट्री से कोई फ़ाइल लोड करते हैं, तो एक चेतावनी दिखती है या private, जब उपयोगकर्ता की फ़ाइल खुद उसके पैरंट के नीचे न हो डायरेक्ट्री. यह लिंट लोड दृश्यता सुविधा से पहले का है और ऐसे फ़ाइल फ़ोल्डर जहां .bzl फ़ाइलें, दिखने से जुड़ी जानकारी के बारे में बताती हैं.