v0.2.12

chapters/040-targets-plateformes-architectures-abi-distributions-et-capabilities.md

@@ -0,0 +1,208 @@
+# 40. Targets, plateformes, architectures, ABI, distributions et capabilities
+
+## 40.1 Dimensions orthogonales — V1 REQUIS — FIGÉES
+
+La Bible distingue explicitement :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+Native
+Embedded
+```
+
+Les familles suivantes doivent être réservables sans refonte du modèle :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+Debian
+Ubuntu
+Rhel
+Fedora
+Arch
+Alpine
+```
+
+ainsi que leur version lorsque pertinente.
+
+Cette dimension sert principalement à :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+TargetFamily
+Platform
+Architecture
+ABI
+Distribution
+```
+
+sans changer son identité logique `vendor/package@requirement`.