이 페이지에서는 Bazel의 두 가지 가시성 시스템을 다룹니다. 타겟 공개 상태 및 로드 가시성입니다.
이 두 가지 공개 유형은 다른 개발자가 공개 API 및 구현 세부정보, 구조 강제 적용 지원 관리할 수 있습니다 공개를 지원 중단할 때 공개 상태를 사용할 수도 있습니다. 현재 사용자는 허용하고 신규 사용자를 거부하는 API.
대상 공개 상태
타겟 공개 상태는 타겟을 신뢰할 수 있는 사용자, 즉
deps
와 같은 속성 안에 타겟의 라벨을 사용하세요.
타겟 A
는 동일한 패키지에 있거나 타겟 B
에 표시되는 경우
A
는 B
의 패키지에 대한 가시성을 부여합니다. 따라서 패키지는
액세스 허용 여부를 결정할 수 있습니다. B
가 A
에 의존하는 경우
A
가 B
에 표시되지 않으면 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
속성 이렇게 하면 가독성이 높아지고
목록이 동기화되지 않게 할 수 있습니다.
권장사항: 다른 팀의 프로젝트를 공개하는 경우 다음을 사용하세요.
__pkg__
보다 __subpackages__
하여 불필요한 가시성 이탈을 방지합니다.
프로젝트가 발전하고 새로운 하위 패키지가 추가됩니다.
규칙 대상 공개 상태
규칙 대상의 공개 상태는 다음과 같습니다.
visibility
속성 값(설정된 경우) 또는 기타이
default_visibility
드림 인수package
대상의BUILD
파일(선언이 있는 경우) 또는 기타//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"],
)
구성 설정 공개 상태
지금까지 Bazel은
config_setting
대상
select()
의 키에서 참조됩니다. 거기
는 이 기존 동작을 제거하는 두 개의 플래그입니다.
--incompatible_enforce_config_setting_visibility
드림 를 사용하면 이러한 대상에 대한 가시성 확인을 사용할 수 있습니다. 마이그레이션을 지원하기 위해 또한visibility
를 지정하지 않는 모든config_setting
가 패키지 수준default_visibility
과 관계없이 공개로 간주됩니다.--incompatible_config_setting_private_default_visibility
드림visibility
를 지정하지 않는config_setting
이 비공개로 대체하고default_visibility
다른 규칙 대상처럼 말이죠 다음 경우에는 노옵스(no-ops)입니다.--incompatible_enforce_config_setting_visibility
가 설정되지 않았습니다.
기존 동작에 의존하지 마세요. 다음을 의도하는 모든 config_setting
현재 패키지 외부에서 사용하려면 명시적인 visibility
가 있어야 합니다.
패키지가 아직 적절한 default_visibility
를 지정하지 않았습니다.
패키지 그룹 타겟 공개 상태
package_group
타겟에는 visibility
속성이 없습니다. 그들은 항상
볼 수 있습니다.
암시적 종속 항목의 공개 상태
일부 규칙에는 암시적 종속 항목이 있습니다.
종속 항목은 BUILD
파일에 명시되어 있지 않지만
해당 규칙의 모든 인스턴스 예를 들어 cc_library
규칙은
실행 가능한 대상에 대한 암시적 종속 항목을 설치합니다.
는 C++ 컴파일러를 나타냅니다.
이러한 암시적 종속성의 표시 여부는
규칙 (또는 관점)이 정의된 .bzl
파일이 포함된 패키지입니다. 포함
예를 들어, C++ 컴파일러가
패키지를 cc_library
규칙의 정의로 사용합니다. 대체로
암시적 종속 항목이 정의에 표시되지 않으면
cc_library
타겟 관련
특정 패키지로 규칙 사용을 제한하려면 다음을 사용합니다. 로드 가시성을 대신 제공합니다.
로드 공개 상태
로드 공개 상태는 .bzl
파일을 다른 기기에서 로드할 수 있는지를 제어합니다.
현재 패키지 외부의 BUILD
또는 .bzl
파일
타겟 가시성이 캡슐화된 소스 코드를 보호하는 것과 같은 방식으로
타겟별로, 로드 가시성은 .bzl
로 캡슐화된 빌드 로직을 보호합니다.
할 수 있습니다. 예를 들어 BUILD
파일 작성자는 몇 가지 반복적인
타겟 정의를 .bzl
파일의 매크로로 변환합니다. 부하 보호 장치 미적용
다른 공동작업자가 매크로를 재사용하고
따라서 매크로를 수정하면 다른 팀의 살펴보겠습니다
.bzl
파일에는 상응하는 소스 파일 타겟이 있을 수도 있고 없을 수도 있습니다.
이 경우에는 로드 가시성과 타겟이
표시됩니다. 즉, 동일한 BUILD
파일이
.bzl
파일이지만 filegroup
의 srcs
에는 나열되지 않음
그 반대의 경우도 마찬가지입니다. 이로 인해
.bzl
파일(예: 문서 생성 또는 테스트용 소스 코드)
프로토타입 제작의 경우
--check_bzl_visibility=false
--check_visibility=false
와 마찬가지로
수행되지 않습니다.
로드 공개 상태는 Bazel 6.0부터 사용할 수 있습니다.
로드 가시성 선언
.bzl
파일의 로드 공개 상태를 설정하려면 다음을 호출합니다.
visibility()
함수를 호출합니다.
visibility()
의 인수는 다음과 같이 패키지 사양 목록입니다.
다음의 packages
속성
package_group
입니다. 하지만 visibility()
는 네거티브 패키지를 허용하지 않습니다.
지정할 수도 있습니다
visibility()
호출은 파일당 최상위 수준에서 한 번만 발생해야 합니다(
load()
문 바로 뒤에 추가하는 것이 가장 좋습니다.
대상 공개 상태와 달리 기본 로드 공개 상태는 항상 공개됩니다. 파일
visibility()
를 호출하지 않는 API는 항상
살펴보겠습니다 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
파일을 허용 목록에 추가해야 할 수 있습니다.
여러 개의 작은 허용 목록으로 구성됩니다. 이것은 Kubernetes가
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- visibility Buildifier 린트
Buildifier 린트가 있음
- 사용자가 internal
디렉터리에서 파일을 로드할 경우 경고를 표시합니다.
또는 private
: 사용자의 파일 자체가 상위 파일 아래에 있지 않은 경우
를 참조하세요. 이 린트는 로드 공개 상태 기능보다 먼저 존재하며
.bzl
파일이 공개 상태를 선언하는 작업공간