Le file system est ancré sous $T4ROOT (actuellement /ccd2/t4). On y trouve les points de départ de la version OK et de la version BETA:
| ok/ | pour la version OK |
| beta/ | pour la version BETA |
Le répertoire de la version choisie est donné par $T4HOME (soit $T4ROOT/ok, soit $T4ROOT/beta)
Chacun de ces répertoires possède les répertoires standards suivant:
| scripts/ | fichiers scripts |
| bin/ | fichiers binaires exécutables sous Unix |
| btl/ | fichiers binaires exécutables pour transputer |
| lib/ | librairies Unix |
| include/ | fichiers Includes pour le C |
| config/ | fichiers de configuration (instruments et logiciels) |
| prc/ | procédures pour logiciels basés sur Inter |
| src/ | fichiers sources |
| skeleton/ | fichiers Squelettes |
ATTENTION, il n'y a aucun développement dans ces répertoires. En effet, partant du principe qu'il y a un espace de développement (version ALPHA), il ne peut pas y avoir de développement en aval de cet espace (contrôle du développement).
La structure des répertoires standards permet de retrouver ou d'adresser facilement les fichiers. Comme les fichiers qu'on y trouve sont sous la responsabilité d'un développeur, l'immense majorité des fichiers sont (et doivent être) des links vers les fichiers originaux.
Il y a cependant quelques exceptions, notament pour les librairies extérieures (ex: libnag.a) ou les fichiers de configuration des logiciels extérieurs (ex: configuration CCD d'ASTROMED), qui sont copiés (et non linkés) pour éviter des les écraser en cas de mise à jour du logiciel.
Les répertoires bin/ et lib/ dont le contenu dépend de l'Operating System possèdent des sous-répertoires nommés avec le nom de l'Operating System et du numéro de version.
Exemples:
$T4HOME/bin/SunOS_5.4 $T4HOME/bin/Linux_1.2.10
Ce suffixe est fabriqué avec la commande Unix:
uname -sr | tr ' ' '_'
Cette manière de nommer les répertoires permet de retrouver l'exécutable du bon type ou de linker les applications avec les librairies du bon type également.
Ce suffixe est également contenu dans la variable d'environnement $OSTYPE (clé du système).
L'ensemble des logiciels développé à l'observatoire est placé sous le répertoire src/. Celui-ci est subdivisé en autant de répertoires qu'il y a de développeurs. Chaque répertoire porte le nom du développeur et lui appartient. Ces répertoires sont protégés en écriture.
Les fichiers sources appartiennent aux développeurs, ils sont sous leurs responsabilités et sont protégés en écriture.
Tout doit être fait pour faciliter la copie d'une application complète vers un autre répertoire. Ce dernier aspect des choses est utile dans le cas de modifications du code, lorsque par exemple, le responsable de l'application est absent. Dans ce cas là, le développeur par interim copie l'application sous un de ses répertoire et fait les modifications adéquates. Ensuite, cette nouvelle application est jointe au reste des logiciels après avoir supprimé les liens sur la version précédente.
La version stable peut suivre le même schéma à Genève mais appartiendra certainement à un utilisateur unique sur le site d'exploitation.
Pour simplifier les tâches de sélection de version (OK, BETA ou ALPHA), de debugging (avec ou sans) et de mode de travail (simulation ou non, ...), les exécutables sous Unix ne sont jamais lancé directement, mais au travers d'un script, pointé par un link créé sous $T4HOME/scripts.
Ainsi chaque logiciel possède un script de lancement qui reconnait l'option "-H" (il reconnait aussi l'option "-h" si l'exécutable ne la gère pas). Cette option permet au script d'indiquer de quel façon il travaille. Lorsque cette option est précisée, l'exécutable n'est pas lancé, mais apparaissent clairement tout les modes de travail possibles et les moyens de les slectionner.
Dans les répertoires source, les scripts permettant de lancer les exécutables sont nommés selon le nom de l'exécutable suivi de l'extension donnant le nom du shell (.sh, .csh, ...). Exemple: le script lançant Inter s'appelle inter.csh. Par contre son link garde le nom de l'exécutable. Exemple:
$T4HOME/scripts/inter -> $T4HOME/src/weber/inter/inter.csh
Chacun des ces scripts possède une variable d'environnement associée qui permet de modifier le comportement de ce script. Le nom de cette variable est nommé comme le nom de l'exécutable. Exemple: $INTER pour Inter (voir plus bas sous chapître "Utilisation et Gestion des versions").
Si d'autre scripts sont liés à une application ceux-ci sont préfixé avec le nom de l'application. Par exemple spectro_srv_init permet de lancer les utilitaires travaillant avec spectro_srv (le serveur de base de donnée par exemple), bien entendu, spectro_srv_init est un link sur spectro_srv_init.csh.
Si tout les exécutables sont interfacés par des scripts, le path des exécutables n'a pas besoin d'être nommé dans la variable d'environnement $PATH.
Les exécutables se trouvent dans les répertoires des développeurs et sont sufixés avec le contenu de la variable $OSTYPE. Exemple: inter_SunOS_5.4.
Les links sur ces exécutables sont créés dans le répertoire $T4HOME/bin/$OSTYPE (voir plus bas sous section "Maintenance globale"). Exemple:
$T4HOME/bin/SunOS_5.4/inter -> $T4HOME/src/weber/inter/inter_SunOS_5.4
Les links sur ces exécutables sont créés dans le répertoire $T4HOME/btl (voir plus bas sous section "Maintenance globale").
Les librairies se trouvent dans les répertoires des développeurs et sont sufixés avec le contenu de la variable $OSTYPE. Exemple: libgop_SunOS_5.4.a.
Les links sur ces librairies sont créés dans le répertoire $T4HOME/lib/$OSTYPE (voir plus bas sous section "Maintenance globale"). Exemple:
$T4HOME/lib/SunOS_5.4/libgop.a ->
$T4HOME/src/weber/gop/libgop_SunOS_5.4.a