Separate compilation

Alain.Frisch at ens.fr Alain.Frisch at ens.fr
Thu Nov 20 01:00:41 CET 2003


Hello,

La prochaine release de CDuce aura la compilation séparée. Comme vous le
savez, j'ai implementé un truc provisoire, pour tester les routines
internes de serialization, et ça a l'air de marcher. Il faudrait finir le
boulot et proposer un système qui se tient, même s'il pourra évoluer par
la suite.

Rappels sur le système actuel:

1. on peut mettre dans un fichier CDuce une déclaration de la forme

    using M = "blabla"

   et utiliser par la suite les types et valeurs de l'unité blabla
   par la syntaxe M:t M:v

2. l'unité désignée par la chaine "blabla" fait référence à un fichier
   blabla.cdo cherché dans une liste de repertoire (spécifiée par l'option
   -I sur la ligne de commande)

3. au moment où un programme est executé, les unités utilisées sont
   chargées et évaluées dans un ordre qui satisfait les dépendances, mais
   est difficilement prévisible


Question:

Sur le point 1: ok pour la syntaxe? Est-ce que l'on a besoin d'une
declaration   using M = "..." in expr/type ?   Est-ce que l'on veut
avoir un using "..." (equivalent d'un open en OCaml)?

Sur le point 2: je crois que l'on est tous plus ou moins d'accord sur le
fait que la chaine "..." dans using M = "..." ne doit pas être directement
interpretée comme un nom de fichier, mais plutôt comme un handle qui
référence une unité externe, le binding handle->fichier étant fait
par une table associative externe, stocké dans un ou plusieurs fichiers
facilement manipulables. Il faudrait préciser tous les details, là.

J'imagine d'avoir typiquement une table "globale" pour les librairies
CDuce installées globalement sur le systeme (dans /usr/lib/cduce, par
exemple), une table par utilisateur pour ses propres packages (dans
~/.cduce), et une table pour le "projet" courant (dans le repertoire
courant ou spécifié sur la ligne de commande). Il faut une notion de
priorité pour pouvoir contredire par exemple la table globale.  Le tout
avec des variables d'environnement pour pouvoir changer les chemins
hardcodés. L'objectif est de rendre la chose facilement utilisable
pour de tous petits projets multi-unités (juste créer une table
dans le repertoire courant), mais de permettre la mise en place d'un
système de packages à la findlib pour CDuce.


Pour le point 3, on peut garder la chose comme maintenant (s'il n'y a pas
d'effets de bords dans les modules chargés, ce n'est pas genant), ou alors
faire comme OCaml, qui demande de fournir explicitement toutes les unités
lors du link, et dans un ordre qui respecte les dependances.

À plus long terme, ca serait bien d'avoir des fichiers .cdi et .cdo
séparés (x.cdi est nécessaire pour compiler une unité qui utiliser x,
alors que x.cdo n'est utilisé qu'au link final), mais on peut très bien
vivre sans pour le moment, je pense.


Commentaires et suggestions bienvenus. Parlez maintenant ou ...


-- Alain




More information about the Cduce-devel mailing list