API et ABI

From VLE

La compatibilité entre deux versions de VLE dépend de deux paramètres que sont l'API et l'ABI.

API & ABI

Ces deux éléments font partis de tout projet informatique et particulièrement pour les projets informatiques utilisant des ressources compilées sur le système d'exploitation, par exemple des bibliothèques de fonctions.

API

API, application programming interface, est le code source qui fait l'interface entre une bibliothèque ou un système d'exploitation et les codes sources clients, par exemples d'autres bibliothèques ou des programmes.

Par exemple, le fichier stdio.h est une API que vous pouvez utiliser depuis des codes sources C. De la même manière, le fichier vle/devs/Dynamics.hpp est une API que vous pouvez utiliser pour développer des modèles.

ABI

ABI, application binary interface, décris le code bas-niveau (code compilé) qui fait le lien entre une bibliothèques ou un système d'exploitation est les codes sources clients, par exemples d'autres bibliothèques ou des programmes.

Par exemple, le fichier libvledevs.so sous GNU/Linux ou libvledevs.dll sous Windows représente l'ABI que vous utilisez lorsque vous exécutez une simulation avec VLE.

Casser l'API ou l'ABI

Casser l'API

Casser l'API est simplement le fait de venir modifier des structures, classes, fonctions des fichiers de l'API. Ainsi, modifier le code suivant casse l'API :

void function(int x, int y);
 
void functionSomme(int x, int y);
 
class Point { ... };
 
class point { ... };
 
namespace x { 
  class X { ... };
}
 
namespace x { namespace y {
  class X { ... };
}

Casser l'ABI

Casser l'ABI consiste simplement modifier la structure binaire bas-niveau du objet compiler. Toute modification de l'API touche profondément l'ABI. Par exemple :

typedef float matrice[3][3];
void multiplie_matrice(matrice a, matrice b, matrice resultat);
 
typedef double matrice[3][3];
void multiplie_matrice(matrice a, matrice b, matrice resultat);

Mais pas uniquement, les modifications de tailles entre variables, casse la compatibilité alors que la compilation passera sans problème. Par exemple :

class Position
{
public:
  int x, y;
};
 
class Position
{
public:
  int x, y, z;
};

Pourquoi VLE n'assure pas de compatibilité ascendante API/ABI ?

• oblige à polluer le code source de VLE avec des structures de maintient de compatibilité.
• nécessite trop de temps.
• le code source est le meilleur moyen de partage de modèles.

Ce que nous assurons

Les versions d'une même branche (Cf. Feuille de route), par exemple les version 0.5.0, 0.5.1 etc. seront compatibles en terme d'API et d'ABI dans la mesure du possible. Ainsi, un modèle compilé pour la version 0.5.0 sera compatible avec la version 0.5.1 etc. c'est-à-dire, pour l'ensemble de la branche 0.5.x.

En ce qui concerne les modèles écrits pour la version 0.5.x, leurs fonctionnement dans la version 0.6.x ne sera pas assuré même si nous essayons de limiter les modifications de l'API et de l'ABI mais en aucun cas, nous ne pourrons assurer cette compatibilité.

Langues :

English