Modules Android Rust

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

En règle générale, les définitions de module rust_* respectent étroitement l'utilisation et les attentes de cc_*. Voici un exemple de définition de module pour un binaire Rust :

rust_binary {
    name: "hello_rust",
    crate_name: "hello_rust",
    srcs: ["src/hello_rust.rs"],
    host_supported: true,
}

Cette page présente les propriétés les plus courantes des modules rust_*. Pour plus d'informations sur des types de modules spécifiques et des exemples de définitions de module, voir Modules binaires, Modules de bibliothèque ou Modules de test.

Types de modules de base

Propriétés communes importantes

Ces propriétés sont communes à toutes les applications Android Rust Modules. Tout établissement supplémentaire (unique) associé à un individu Les modules Rust sont répertoriés sur la page de ce module.

nom

name est le nom de votre module. Comme les autres modules Soong, il doit être unique dans la plupart des types de modules Android.bp. Par défaut, name est utilisé comme nom de fichier de sortie. Si le nom du fichier de sortie doit être différent du nom du module, utilisez la méthode stem pour la définir.

tige

stem (facultatif) permet de contrôler directement le nom de fichier de sortie (à l'exception de l'extension de fichier et des autres suffixes). Par exemple, un rust_library_rlib dont la valeur racine est libfoo génère un fichier libfoo.rlib. Si vous ne fournissent pas de valeur pour la propriété stem, le nom de fichier de sortie adopte nom du module par défaut.

Utilisez la fonction stem lorsque vous ne pouvez pas définir le nom du module sur la sortie souhaitée nom de fichier. Par exemple, le rust_library de la caisse log est nommé liblog_rust, parce qu'un liblog cc_library existe déjà. Dans ce cas, l'utilisation de la propriété stem garantit que la sortie est nommé liblog.* au lieu de liblog_rust.*.

SRC

srcs contient un seul fichier source qui représente le point d'entrée de votre module (généralement main.rs ou lib.rs). rustc gère la résolution et la découverte de tous les autres fichiers sources requis pour la compilation, qui sont énumérés dans le fichier deps généré.

Si possible, évitez cette utilisation pour le code de plate-forme. voir Générateurs de sources pour en savoir plus.

crate_name

crate_name définit les métadonnées du nom de la caisse via le --crate_name rustc. . Pour les modules qui génèrent des bibliothèques, ce nom doit correspondre au nom de crate attendu utilisé dans la source. Par exemple, si le module libfoo_bar est référencé dans la source en tant que extern crate foo_bar, alors il doit être crate_name : "foo_bar".

Cette propriété est commune à tous les modules rust_*, mais elle est obligatoire pour les modules qui génèrent des bibliothèques Rust (comme rust_libraryrust_ffi, rust_bindgen, rust_protobuf et rust_proc_macro). Ces modules appliquent les exigences rustc à la relation entre crate_name et le nom de fichier de sortie. Pour en savoir plus, consultez les Modules de la bibliothèque .

lints

Le linter rustc est exécuté par défaut pour tous les types de modules, à l'exception des générateurs de sources. Certains ensembles lint sont définis et utilisés pour valider la source du module. Valeurs possibles pour ce lint sont les suivants:

• default : ensemble de lints par défaut, en fonction de l'emplacement du module
• android : ensemble lint le plus strict qui s'applique à tout le code de la plate-forme Android
• vendor : ensemble assoupli de lint appliqué au code du fournisseur
• none pour ignorer tous les avertissements et erreurs lint

clippy_lints

L'outil clippy linter est également utilisé sont exécutés par défaut pour tous les types de modules, à l'exception des générateurs de sources. Quelques ensembles de lints sont définis et sont utilisés pour valider la source du module. Voici quelques exemples :

• Ensemble par défaut de lints default en fonction de l'emplacement du module
• android : ensemble lint le plus strict qui s'applique à tout le code de la plate-forme Android
• vendor : ensemble assoupli de lint appliqué au code du fournisseur
• none pour ignorer tous les avertissements et erreurs de lint

édition

edition définit l'édition Rust à utiliser pour la compilation de ce code. Cette méthode est semblable aux versions std pour C et C++. Valeurs valides sont 2015 et 2018 (par défaut).

indicateurs

flags contient une liste d'indicateurs de chaîne à transmettre à rustc lors de la compilation.

ld_flags

ld-flags contient une liste de chaînes d'indicateurs à transmettre à l'éditeur de liens lors de la compilation source. Celles-ci sont transmises par l'indicateur rustc -C linker-args. clang est utilisé comme interface du lisseur, qui appelle lld pour l'association réelle.

fonctionnalités

features est une liste de chaînes de fonctionnalités qui doivent être activées lors de la compilation. --cfg 'feature="foo"' le transmet à rustc. La plupart des caractéristiques s'ajoutent les unes aux autres. Dans de nombreux cas, il s'agit donc de l'ensemble des fonctionnalités requises par toutes les dépendances modules. Toutefois, lorsque des fonctionnalités s'excluent les unes des autres, définir des modules supplémentaires dans tous les fichiers de compilation qui fournissent des fonctionnalités en conflit.

cfg

cfgs contient une liste de chaînes d'indicateurs cfg à activer lors de la compilation. Ceci est transmis à rustc par --cfg foo et --cfg "fizz=buzz".

Le système de compilation définit automatiquement certains indicateurs cfg, en particulier énumérés ci-dessous:

• Le fichier de configuration android_dylib est défini pour les modules compilés en tant que dylib.

• La configuration android_vndk sera définie pour les modules qui utiliseraient le VNDK. C'est semblable à __ANDROID_VNDK__ pour C++.

strip

strip détermine si le fichier de sortie est supprimé et de quelle manière (le cas échéant). Si cette règle n'est pas configurée, les modules de l'appareil suppriment par défaut toutes les informations, à l'exception des mini informations de débogage. Par défaut, les modules hôtes ne suppriment aucun symbole. Les valeurs valides incluent none pour désactiver le dénudage et all pour supprimer tout, y compris le mini debuginfo. Vous trouverez d'autres valeurs dans le Documentation de référence sur les modules Soong

compatible avec l'hôte

Pour les modules d'appareil, le paramètre host_supported indique si le module doit également fournir une variante d'hôte.

Définir les dépendances de bibliothèque

Les modules Rust peuvent dépendre à la fois des bibliothèques CC et Rust via les propriétés suivantes :

Lorsque vous associez des bibliothèques Rust, nous vous recommandons d'utiliser la propriété rustlibs plutôt que rlibs ou dylibs, sauf si vous avez une raison spécifique de le faire. Cela permet au système de compilation de sélectionner l'association appropriée en fonction de ce que le module racine nécessite, et réduit la probabilité qu'un arbre de dépendances contienne à la fois les versions rlib et dylib d'une bibliothèque (ce qui entraînera l'échec de la compilation).

Fonctionnalités de build non compatibles et limitées

Rust de Soong offre une compatibilité limitée avec les images et les instantanés vendor et vendor_ramdisk. Toutefois, staticlibs, cdylibs, rlibs et binaries sont compatibles. Pour les cibles de compilation d'images de fournisseurs, La propriété cfg android_vndk est définie. Vous pouvez l'utiliser dans le code s'il existe des différences entre les cibles système et les cibles du fournisseur. rust_proc_macros ne sont pas capturées dans les instantanés des fournisseurs ; s'ils en dépendent, assurez-vous d'un contrôle de version approprié.

Les images de produit, VNDK et de récupération ne sont pas acceptées.

Compilations incrémentielles

Les développeurs peuvent permettre la compilation incrémentielle Rust en définissant SOONG_RUSTC_INCREMENTAL la variable d'environnement sur true.

Avertissement : Il n'est pas garanti que des binaires identiques à ceux générés par les buildbots soient produits. Adresses des fonctions ou des données contenues dans le champ peuvent être différents. Pour vous assurer que les artefacts générés sont 100 % identiques à ceux créés par l'infrastructure EngProd, ne définissez pas cette valeur.