에피소드 15: 조 메이슨, PQ 몬트리올 (2020년 11월)
이전 에피소드
Chrome은 많은 하위 시스템을 가진 대규모 프로젝트입니다. 일반적으로 한 구성 요소용으로 작성된 것으로, 다른 곳에서는 유용하지만 제한되기 때문입니다. 안전을 위해 위험한 기능에 대한 외부 액세스를 제한하세요. 특정 성능 요구사항에 맞게 조정된 맞춤 함수를 예로 들 수 있습니다.
// Blazing fast for 2-char strings, O(n^3) otherwise.
std::string ConcatShortStringsFast(const std::string& a, const std::string& b);
액세스를 제한하는 방법은 여러 가지가 있습니다. GN 공개 상태 규칙의 코드 차단 구성 요소 외부에서 타겟에 종속되지 않도록 할 수 있습니다. 기본적으로 대상은 모든 사용자에게 표시되지만 다음과 같이 수정할 수 있습니다.
# In components/restricted_component/BUILD.gn
visibility = [
# Applies to all targets in this file.
# Only the given targets can depend on them.
"//components/restricted_component:*",
"//components/authorized_other_component:a_single_target",
]
source_set("internal") {
# This dangerous target should be locked down even more.
visibility = [ "//components/restricted_component:privileged_target" ]
}
공개 상태 선언은 부분적으로 실행되는 gn check로 검증됩니다.
빌드됩니다.
또 다른 메커니즘은 헤더 파일에 대한 액세스를 제한하는 DEPS include_rules입니다.
모든 디렉터리는 상위 항목에서 include_rules를 상속하며 이를 수정할 수 있습니다.
규칙을 자체 DEPS 파일에 저장합니다. 외부에서 포함된 모든 헤더 파일
include_rules에서 허용해야 합니다.
# In //components/authorized_other_component/DEPS
include_rules = [
# Common directories like //base are inherited from
# //components/DEPS or //DEPS. Also allow includes from
# restricted_component, but not restricted_component/internal.
"+components/restricted_component",
"-components/restricted_component/internal",
# But do allow a single header from internal, for testing.
"+components/restricted_component/internal/test_support.h",
]
이러한 종속 항목이 적절한지 확인하기 위해 디렉터리를 추가하는 변경사항은
include_rules로 제출하려면 해당 디렉터리의 OWNERS에서 승인해야 합니다. 아니요
include_rules을 사용하여 디렉터리를 제한하려면 승인이 필요합니다. 다음과 같은 작업을 할 수 있습니다.
구성요소를 변경하는 모든 사용자가 특정
헤더를 사용하여 include_rule 금지합니다.
사전 제출에서 include_rules를 확인하므로 아무것도 표시되지 않습니다.
오류가 발생할 수 있습니다 다음을 사용하지 않고 include_rules를 테스트하려면 다음 안내를 따르세요.
업로드 중 buildtools/checkdeps/checkdeps.py <directory>를 실행합니다.