Plan d’interopérabilité
Référence : cette page est une synthèse technique fondée sur le chapitre LaTeX cité ci-dessous. Pour la syntaxe exacte, la disponibilité ou les signatures ABI, vérifier le source versionné, le manifeste et les tests exécutables.
Portée et frontière de la source
Le plan d’interopérabilité dépend d’une ABI explicite, de modules natifs et de bindings externes versionnés.
L’interopérabilité relie code natif, bindings générés, modules ABI et systèmes externes au moyen de frontières explicites. La source distingue interfaces internes et points d’entrée ABI publics, et rappelle que les détails de chargement ne sont pas forcément portables. Formes des arguments, marshalling, propriété et compatibilité relèvent du contrat publié.
Règles d’ingénierie
- Ne pas faire des noms de classes internes des garanties publiques de compatibilité.
- Générer les clients depuis le manifeste ABI et sa version réelle.
- Définir qui alloue, conserve et libère valeurs et références.
- Tester le chargeur, la plateforme et le parcours de déploiement exacts.
Plan du chapitre (intitulés LaTeX d’origine)
- Why This Layer Matters
- The Public Contracts and Kernel Implementations
- Load the ABI Manifest First
- Load and Register a Native Module
- Build the Executor and FPL Bridge
- Compile Source into an ABI Invocation
Provenance LaTeX
Chapitre principal : Runtime/logiCells Runtime Programming with RadStudio/native-abi-and-fpl-native-modules.tex.