5.0 KiB
40. Targets, plateformes, architectures, ABI, distributions et capabilities
40.1 Dimensions orthogonales — V1 REQUIS — FIGÉES
La Bible distingue explicitement :
TargetFamily
Platform
Architecture
ABI
Distribution
Capability
Feature
ArtifactKind
ExportFormat
Ces dimensions ne doivent pas être fusionnées dans une chaîne opaque ni confondues entre elles.
Une cible de compilation concrète est décrite par la combinaison des dimensions pertinentes.
40.2 Représentation Core des domaines — V1 REQUIS — FIGÉE EN PRINCIPE
Le choix entre enum et type d'identifiant extensible dépend de la nature sémantique du domaine, et non d'une tentative de protéger artificiellement V1/V2 contre toute évolution.
Les domaines naturellement fermés pour une version donnée peuvent être des enum Core, par exemple :
Endianness
PackageType
Linkage
Deployment
Une valeur peut être ajoutée ou une représentation corrigée pendant V1/V2 si un besoin réel apparaît. Ces générations étant internes, un tel changement peut nécessiter l'adaptation simultanée du compilateur, du Core, du SDK et des outils.
Les domaines intrinsèquement ouverts ou liés à l'écosystème externe sont de meilleurs candidats à des types d'identifiants compiler/Core-known extensibles, notamment :
Platform
Architecture
ABI
Distribution
Capability
ArtifactKind
ExportFormat
TargetFamily peut être un enum ou un identifiant extensible selon la forme finale retenue pendant l'implémentation V1 ; cette décision ne doit pas modifier le modèle du manifest.
Exemples de valeurs compiler-known :
Platform::Linux
Platform::Windows
Architecture::X86_64
Architecture::AArch64
ABI::Gnu
Distribution::Debian
Capability::FileSystem
ArtifactKind::NativeExecutable
La représentation binaire/interne exacte de ces types reste une décision du Core/toolchain V1. Avant la première baseline publique V3+, la priorité est la cohérence sémantique et l'absence de verrou architectural inutile.
40.3 Target families — V1 REQUIS / RÉSERVÉ
V1 doit réellement supporter le chemin LLVM pour au minimum :
Native
Embedded
Les familles suivantes doivent être réservables sans refonte du modèle :
Browser
Wasm
Jvm
JavaScript
D'autres familles futures pourront être ajoutées sans changer la forme du manifest.
L'interpréteur V1 est un moteur d'exécution Saselang et n'est pas confondu avec une TargetFamily machine.
40.4 Platforms — V1 REQUIS / RÉSERVÉ
Le modèle doit pouvoir représenter notamment :
Linux
Windows
MacOS
FreeBSD
Android
iOS
None
None représente une cible sans OS, notamment bare-metal/embedded.
La liste n'est pas fermée.
40.5 Architectures — V1 REQUIS / RÉSERVÉ
Le modèle doit au minimum être capable de représenter les grandes familles que LLVM peut cibler, notamment :
X86
X86_64
Arm
AArch64
RiscV32
RiscV64
Wasm32
La liste exacte officiellement validée par Saselang V1 dépend de la toolchain LLVM/runtime/sysroot disponibles ; le modèle ne doit pas l'empêcher d'évoluer.
40.6 ABI — V1 REQUIS / RÉSERVÉ
Le modèle doit pouvoir représenter notamment :
Gnu
Musl
Msvc
Darwin
Eabi
Eabihf
None
Saselang peut utiliser les triples LLVM en interne, mais le triple LLVM brut n'est pas la seule abstraction publique du target.
40.7 Distribution — V1 RÉSERVÉ / FUTUR V3+
Distribution est distincte de Platform et de l'ABI.
Elle doit pouvoir représenter à terme des familles telles que :
Debian
Ubuntu
Rhel
Fedora
Arch
Alpine
ainsi que leur version lorsque pertinente.
Cette dimension sert principalement à :
résoudre/découvrir des dépendances système ;
exprimer des contraintes d'environnement de distribution ;
produire des packages/export formats spécifiques.
Elle n'est pas requise pour toute compilation native V1.
40.8 Capabilities — V1 REQUIS — SQUELETTE FIGÉ
Les capabilities décrivent des capacités réelles de l'environnement et non des options libres du package.
V1 doit pouvoir représenter au minimum :
Heap
FileSystem
Environment
Process
Threads
Network
Sockets
Clock
DynamicLoading
SharedMemory
StandardInput
StandardOutput
StandardError
Le modèle doit aussi permettre de décrire les capacités atomiques pertinentes sans supposer qu'elles sont identiques sur tous les targets.
Une capability statique signifie que l'environnement fournit la capacité ; elle ne garantit pas qu'une opération runtime particulière réussira.
40.9 Compatibilité target/dépendance — V1 REQUIS — FIGÉE EN PRINCIPE
Un package ou une dépendance peut déclarer des contraintes de target/platform/ABI/capabilities.
Le resolver/build doit détecter les incompatibilités avant la compilation effective lorsqu'elles sont déterminables.
Une dépendance native peut fournir des mappings distincts selon :
TargetFamily
Platform
Architecture
ABI
Distribution
sans changer son identité logique vendor/package@requirement.