Environnement de Développement Unix

SOMMAIRE

À propos du développement dans FrameKit
Comment créer un programme ou une librairie

Les fichiers d'interfaces de base de FrameKit
Particularités des plate-formes cibles
Les variables de compilation
Migration AMI vers FrameKit

Ce document décrit la manière de développer des applications portables pour FrameKit. Après une introduction générale et une analyse des enseignements issus de l'expérience de développement de l'atelier AMI, le document présente l'arborescence des fichiers de FrameKit et décrit pas à pas comment créer une librairie ou un service pour FrameKit.

A propos du développement dans FrameKit

Le développement dans FrameKit est issu des enseignements tirés des problèmes de developpement rencontrés dans AMI (1988-1994).

L'idée principale est de rendre beaucoup plus facile la maintenance et de permettre les re-compilations des outils et de la plateforme sans la présence des auteurs des logiciels.

FrameKit versus AMI

Contrairement au développement dans AMI, le développement dans FrameKit est, à la base, multi-cibles. C'est à dire qu'il est prévu pour être compatible entre les plate-formes Unix suivantes: SunOs, Solaris, HP-UX, FreeBSD et linux (Solaris, Linux et MacOS X depuis 2001). Pour les détails techniques, voir "Particularités des plate-formes cibles".

Comme dans AMI, vous trouverez un certain nombre de bibliothèques de base prêtes à l'emploi. Exemple: libTools.a contenant les CListes.

Nous avons essayé de rendre la migration d'AMI vers FrameKit la plus automatique possible en fournissant un scripts et des explications écrites.
Cependant, il est clair que le travail de migration ne sera pas nul. Il sera aussi possible d'effectuer cette migration en plusieurs temps grace à l'emploi de variables de compilation.

Arborescence de fichiers

L'ensemble des fichiers d'inclusion et les librairies stables de FrameKit se situent sous le répertoire de base nommé FRAME_KIT_ROOT. FRAME_KIT_ROOT prend la valeur

FrameKit/development

sur les machines de l'équipe Sytèmes Répartis et Coopératifs.

Contenu du répertoire de base

Les fichiers d'interface de base de FrameKit pour la programmation en langage C (.h) se situent dans le répertoire interfaces/C.
Les répertoires sunos, solaris,… contiennent les librairies de base pour les différentes plate-formes cibles.
Le répertoire tools/interfaces contient les interfaces C des CListes.
Les répertoire tools/{Cible} contient la librairies tools pour les différentes cibles.

(dans cette figure les noms ont évolués)

Les fichiers specific_program.make et specific_library.make servent de base d'exemples pour créer des MakeFile pour des programmes exécutables ou des librairies. Les MakeFile sont configurés pour l'utilisation du make de gnu (gmake) et utilisent le fichier generic.make (voir Modifier le fichier specific.make). Le fichier ConfigureForLinks.sh est utilisé lors de la configuration. Le fichier toFrameKit.script est un script utilisé pour la migration de AMI vers FrameKit ("Le script", page 7).

Comment créer un programme ou une librairie

La mise au point de programmes et de librairies pour FrameKit peut se faire dans n'importe quel répertoire. Par contre, lorsque qu'une version est devenue assez stable, l'ensemble des sources doit être installé dans un répertoire particulier afin qu'un administrateur de FrameKit puisse a tout moment ré-effectuer une compilation. Le répertoire est le suivant FRAME_KIT/services/{formalisme}/[SecondaryStandard/]{ProjectName}.

Répertoire de projet

La création des répertoires n'est pas faite par les scripts de FrameKit. Les répertoires peuvent être créés soit depuis unix (mkdir), soit depuis un Macintosh (Nouveau Dossier) sur le serveur AppleShare de la machine. Si vous désirez éditer vos fichiers depuis un Macintosh, il faut absolument créer les répertoires depuis le Macintosh.

• Créer un répertoire du nom de votre projet
  Le chemin Unix de ce répertoire sera nommé PROJECT_ROOT dans la suite de ce document.
• Entrer dans le répertoire du projet

  cd PROJECT_ROOT

Répertoires sources et interfaces

L'organisation de FrameKit impose le nom et le contenu de ces répertoires.
Créer les deux répertoires sources et interfaces et y mettre respectivement vos sources (.c) et vos fichiers d'interfaces (.h).

Makefile

Les makefiles de FrameKit sont basés sur l'utilisation du gnu make. Ils sont conçus pour être facilement configurables et ils utilisent des inclusions pour obtenir la généricité nécessaire au développement multi-cibles.

• Recopier le makefile spécifique
  Suivant que vous désirez créer un programme exécutable ou une librairie, vous allez copier le fichier specific_program.make ou specific_library.make dans specific.make.
  Vous pouvez recopier ces fichiers à partir d'un Macintosh, vous allez devoir les éditer par la suite.

  cp $(FRAME_KIT_ROOT)/specific_program.make specific.make

  ou

  cp $(FRAME_KIT_ROOT)/specific_library.make specific.make

Modifier le fichier specific.make

Il faut modifier le fichier le fichier specific.make afin d'indiquer les programmes sources qui composent votre projet.

Editer le fichier specific.make et modifier les lignes suivantes:

1. Remplacer le nom de votre projet à la ligne PROJECT_NAME.
2. Remplacer le chemin PROJECT_ROOT par votre chemin.
3. Suivant le cas, remplacer PROGRAM ou LIBRARY. Attention pour une librairie, mettre le nom complet libXXXX.a.
4. Mettre les noms des fichiers sources séparés par des espaces dans CFILES, vous pouvez utiliser plusieurs lignes en terminant chacune d'elle par un '\'.
5. Modifier INCDIR si vous utilisez d'autres chemins d'inclusion que ceux qui y sont déjà (En particulier si vous utilisez des librairies).
6. Modifier LIBDIR si vous utilisez d'autres chemins de libraires que ceux qui y sont déjà (cela doit être rare). En cas de modification, utilisez la variable $(FK_OS) afin d'obtenir la librairie de la bonne machine cible.
7. Vous pouvez modifier les EXTRA_CFLAGS mais ceux qui sont proposés vous assurent une bonne compilation ANSI-C. En particulier, ces options vous permettront de valider l'intégration dans FrameKit lorsqu'il n'y aura plus aucun warning.
8. Pour un programme exécutable, donner la liste des librairies nécessaires dans LIBRARIES. Ici, il faut donner le nom court (XXX au lieu de libXXXX.a).
9. LIB_DEPEND permet d'effectuer de nouveau l'édition des liens lorsque la librairie est modifiée. Mettre le même contenu que LIBRARIES.
10. Mettre vos propres définitions dans DEFINES. Dans FrameKit d'autres variables sont définies par défaut .

Le fichier specific.make inclu le fichier generic.make permettant de gérer automatiquement les dépendances des fichiers, de compilation et d'édition de liens.

Etant donné que vous avez modifié le fichier specific.make, il nous sera impossible de le remplacer. Si des modifications sont nécessaires, elles vous seront demandées par courrier électronique.

Fichier de Configuration

Le fichier de configuration (Configure) est indépendant des plate-formes cibles. Il permet de mettre en place des variables de compilation des différents unix.

Pour éviter les problèmes de mise à jour (modification par les developpeurs de la plate-forme), il est conseillé de faire un lien symbolique.

ln -s $(FRAME_KIT_ROOT)/../export/ConfigureForLinks.sh Configure

Première phase de configuration

Exécuter une première fois le fichier de configuration. Il vous sera alors demandé de créer un répertoire du nom de votre machine cible. Si vous développez pour plusieurs machines cibles (ce que nous vous conseillons), il faut excécuter le fichier de configuration sur chaque machine.

Première phase de configuration sur sunos:

> Configure          Configuring for SunOS
Directory sunos not found, please create it from Unix or from AppleShare
and run Configure again.

Dans l'exemple ci-dessus, il est demandé de créer un répertoire de nom sunos. Comme pour le répertoire PROJECT_ROOT, vous créez ce répertoire soit depuis unix soit à partir du Macintosh.

Deuxième phase de configuration

Exécuter une deuxième fois le fichier de configuration. Cette fois ci, le fichier de configuration va créer votre fichier Makefile par un lien sur specific.make et va générer les fichiers d'inclusion fkdefines.make et fkos.make nécessaires au Makefile.

Deuxième phase de configuration sur sunos:

> Configure
Configuring for SunOS
To compile, cd sunos;gmake

Compilation et édition de lien

Aller dans le bon répertoire (rappelé par Configure) et exécuter le gmake (make sous Linux).
La commande gmake clean permet d'effacer tous les objets générés.

Les fichiers d'interfaces de base de FrameKit

Les fichiers d'interface de base de FrameKit reprennent en partie les fichiers d'interface unix pour plusieurs raisons:

1. Il est possible de modifier légèrement certains types ou certaines macros avant l'inclusion du fichier unix.
2. Il est possible de compléter, au format ANSI, pour certaines machines, les définitions d'appels systèmes non définis.
3. Il est possible de changer par macro des appels systèmes afin qu'ils ne soient plus utilisés (car non compatibles avec la philosophie de FrameKit).

Pour modifier d'anciens fichiers sources, vous pouvez utiliser le script décrit dans "Le script", page 7.

Les variables de compilation

Variables prédéfinies

Suivant les systèmes d'exploitation, des variables permettent de faire de la compilation conditionnelle.

Système	sunos	solaris	hpux	linux	freebsd
	FK_SUN_OS	FK_SOLARIS	FK_HP_UX	FK_LINUX	FK_FREE_BSD
FK_OS_NAME	SunOS	Solaris 2.x in native SVR4 mode	HP-UX (for 9000 series)	Linux	FreeBSD 2.x

Voir aussi les plates-formes de développement.

Variables optionnelles

FK_KERNEL	Utilisé pour fabriquer le 'noyau' de FrameKit.
PRINTF_ALLOWED	permet d'utiliser le printf.
_MARS_TYPE_COMPATIBLE_	permet d'utiliser les types Ptr, Handle, Boolean et les constantes true et false utilisés dans AMI.
_OLD_MARS_MEMORY_	permet d'utiliser les anciennes fonctions NewHandle et DisposHandle utilisées dans AMI. (à supprimer au plus tôt).
_OLD_AMI_TRACE_	permet d'utiliser l'ancienne fonction SVimpression utilisées dans AMI. Sera remplacé plus tard par une primitive de trace de FrameKit.
_OLD_AMI_DECODE_	permet d'utiliser les anciennes syntaxes InitDecodeCami, InitialiseFonctions, ChangerFonction, DecodeCami de la librairie de décodage des commandes CAMI de AMI.

Note: Dans la version 1.2, si vous utilisez _OLD_AMI_TRACE_ il faut utilser aussi PRINTF_ALLOWED car SVimpression est remplacé par printf actuellement.

Migration AMI vers FrameKit

Compatibilité ascendante

Si vous voulez pas immédiatement modifier votre code utilisant les types Ptr, Handle, Boolean et les constantes true et false (il faudra pourtant le faire un jour surtout pour Handle qui a disparu définitivement), vous devez définir la variable _MARS_TYPE_COMPATIBLE_.

Le script toFrameKit.script

Pour modifier vos fichiers sources, vous pouvez utiliser le script toFrameKit.script.

sh toFrameKit.script *.c

Celui-ci va remplacer un ensemble de #include <…> par les #include de FrameKit

Le script conservera l'ancien fichier sous son ancien nom suffixé par .orig.

Il ne faudrait pas garder un .orig si il n'y a pas de différence !

Particularités des plate-formes cibles

La particularité principale de l'environnement SunOS est l'absence de prototypes dans les interfaces C.

Le principe général est de remplacer les fichiers d'interface système par un fichier d'interface de FrameKit. Par exemple, il faut remplacer

#include <stdio.h> par des <FKstdio.h>. Le fichier FKstdio.h incluant stdio.h complété des prototypes manquant dans stdio.h suivant les architectures. Voir table de conversion.