에피소드 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 빌드의 일부로 실행되는 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>를 실행합니다.