Un échafaudage pour le développement de vos applications Ada

Introduction et généralités¶

Dans le cadre du développement d’applications conséquentes ou critiques, l’environnement de développement devant être mis en place doit au minimum satisfaire aux besoins suivants :

• Il doit être peu ou non adhérent à l’OS,

• Il doit offrir des fonctionnalités de haut niveau,

• Il doit être autoporteur,

• Il doit facilement être modifiable et configurable au gré de l’évolution des besoins projet,

• Il doit vérifier et assurer la complétude et la consistance des outils mis en œuvre en son sein,

Dans la suite de l’article, nous allons considérer que notre projet se nomme de façon peu originale « MON_PROJET ».

Un échafaudage transportable¶

Pour l’ossature de notre échafaudage, la solution choisie est d’utiliser BASH (Bourne-Again Shell). Sous Windows nous utilisons soit Babun soit MSYS2. Un soin tout particulier est apporté pour que les scripts BASH fonctionnent indifféremment sous Windows et Linux en testant par exemple la variable OSTYPE.

Dans tous les cas, la mise en place de l’échafaudage consiste simplement à mettre dans le fichier ~/.bashrc :

export PROJECT_ROOT_DIR=<chemin vers MON PROJET>
source $PROJECT_ROOT_DIR/.env

Une fois fait, et lors de l’ouverture d’un terminal, l’utilisateur verra apparaitre :

Copie d’écran du terminal à l’ouverture

Lancer par exemple la commande mon_projet_r va afficher (ici à titre indicatif) :

Copie d’écran du terminal après le lancement de la commande mon_projet_r.

L’utilisateur se retrouve alors dans l’environnement de MON_PROJET où son instance est clairement affichée (ici cible=NATIVE, mode=RELEASE, versions et builds des composants générés, ainsi que des outils utilisés).

Un échafaudage utile et pratique¶

Une fois lancé, et hormis les commandes affichées, l’environnement met à disposition de l’utilisateur plus d’une vingtaine de fonctions.

Les principales sont :

• La production de l’ensemble des métriques du code Ada basé entre autres sur GNATmetric.

• La vérification des règles de codage du code Ada basé entre autres sur GNATcheck.

• La génération des harnais de tests du code Ada basé entre autres sur GNATtest.

• Le comptage et l’identification des pragma Compile_Time_Warning.

• Le comptage et l’identification des pragma contrôlant l’ordre des élaborations Ada.

• La transposition sous forme de macros des informations de configuration de l’environnement basée entre autres sur GNATprep.

• La mise à disposition dans l’ensemble des répertoires du projet des cibles build, clean, test, etc. rendant l’utilisation de la commande make simple et efficace.

• La fermeture Ada (closure) de l’ensemble des codes.

• Le lancement de l’ensemble des tests unitaires et de couvertures.

• Etc.

Un échafaudage autoporteur¶

Dans la « remise en route » d’un projet (par exemple pour la gestion d’obsolescences) on constate souvent que les principaux constitutifs de celui-ci ont été égarés. C’est pour cela que, dans la mesure du possible, un projet doit être autoporteur. Il y a encore quelques années, cela pouvait être une contrainte du fait de la nécessité de dupliquer une grande quantité de données. Aujourd’hui, manipuler quelques dizaines de giga-octets est-il vraiment un problème ? La réponse est non.

Hormis le fait de dupliquer les données, une solution est d’embarquer les sources des différents outils mis en œuvre et de les construire à la volée lors de la première instance de l’environnement.

Ainsi donc, dans les environnements qui ont été mis en œuvre par Systerel, une partie des outils ont été développés en Ada. On retrouve dans le bestiaire de ces outils : des générateurs de données de configuration du système, des normalisateurs de code en vue de la mise en œuvre de l’outil SPARK, une console virtuelle NetCatAda (NCA), etc.

Un échafaudage modifiable et configurable¶

Une fois mon « chantier » terminé, il faut que je puisse facilement réutiliser mon échafaudage.

Pour ce faire il faut :

• Que mon environnement soit faiblement dépendant de l’architecture de mon projet et plus particulièrement de son arborescence.

• Que mon environnement cantonne les définitions propres au projet dans quelques fichiers.

Généralement nous utilisons trois fichiers :

• MON_PROJET.conf : fichier déclaratif en BASH décrivant les spécificités de « MON_PROJET ».

• tools.conf : fichier déclaratif en BASH décrivant l’ensemble des outils utilisés,

• versioning.conf : fichier déclaratif en BASH décrivant les versions des différents composants produits par l’environnement.

Par exemple dans ce dernier fichier nous pourrions trouver :

export MON_PROJET_MAJOR_VERSION=7
export MON_PROJET_MINOR_VERSION=5

Un échafaudage sûr¶

Lors du démarrage de l’environnement, toutes les informations saisies dans les fichiers de configuration précédents seront vérifiées et/ou incluses dans le code en utilisant le préprocesseur GNATprep.

Ainsi donc, l’unité de compilation Mon_Projet.Versions disponible sera :

package Mon Projet.Versions is

   Mon_Projet_Major  : constant Natural := 7 -- $MON_PROJET_MAJOR_VERSION
   Mon_Projet_Minor  : constant Natural := 5 -- $MON_PROJET_MINOR_VERSION

La version de mon projet sera donc intégrée et il y aura une consistance entre mon environnement et les codes sources qu’il héberge.

Conclusion¶

Ce qui vous a été présenté n’est qu’un exemple de ce qui peut être fait dans un environnement. Le plus important est de bien évaluer l’importance de tels environnements qui est bien souvent négligée en début de projet.

Cela peut être un mauvais calcul, car oui, sur le court terme le bénéfice peut apparaitre comme étant faible, mais sur le long terme cela s’avérera toujours gagnant. De plus, si celui-ci a été fait en prenant en compte les quelques préconisations que nous avons données, alors, celui-ci pourrait être réutilisé et amélioré sur d’autres « chantiers » nécessitant des échafaudages encore plus imposants !

Références¶

[1] : GNAT User’s Guide for Native Platforms

[2] : GNAT Reference Manual