Épisode 15:Joe Mason à Montréal, PQ (novembre 2020)
Épisodes précédents
Chrome est un projet ambitieux qui implique de nombreux sous-systèmes. Il est courant de trouver du code écrit pour un composant qui serait utile ailleurs, mais qui peut comporter des restrictions masquées. Par sécurité, limitez l'accès externe aux fonctionnalités dangereuses. Par exemple, une fonction personnalisée adaptée à des besoins de performances spécifiques:
// Blazing fast for 2-char strings, O(n^3) otherwise.
std::string ConcatShortStringsFast(const std::string& a, const std::string& b);
Il existe plusieurs façons de restreindre l'accès. Les règles de visibilité GN empêchent le code en dehors de votre composant de dépendre d'une cible. Par défaut, les cibles sont visibles par tous, mais vous pouvez modifier cela:
# 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" ]
}
Les déclarations de visibilité sont validées avec gn check, qui s'exécute dans chaque build GN.
Un autre mécanisme est DEPS include_rules, qui limite l'accès aux fichiers d'en-tête.
Chaque répertoire hérite include_rules de son parent et peut modifier ces règles dans son propre fichier DEPS. Tous les fichiers d'en-tête inclus à partir de répertoires externes doivent être autorisés par 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",
]
Pour garantir que ces dépendances sont appropriées, les modifications qui ajoutent un répertoire à include_rules doivent être approuvées par l'élément OWNERS de ce répertoire. Aucune approbation n'est nécessaire pour restreindre un répertoire à l'aide de include_rules. Pour vous assurer que toutes les personnes qui modifient votre composant se souviennent de ne pas utiliser certains en-têtes, en ajoutant un include_rule les interdisant.
include_rules sont vérifiés par le pré-envoi. Aucune erreur ne s'affichera tant que vous n'aurez pas essayé d'importer une modification. Pour tester include_rules sans importation, exécutez buildtools/checkdeps/checkdeps.py <directory>.