209 lines
5.0 KiB
Markdown
209 lines
5.0 KiB
Markdown
# 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`.
|