# 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`.