[cduce-devel] Separate compilation

Giuseppe Castagna Giuseppe.Castagna at ens.fr
Thu Nov 20 10:40:50 CET 2003


On Thu, 2003-11-20 at 01:00, Alain.Frisch at ens.fr wrote:
> 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? 

Oui. Le seul point est que l'on utilise les namespaces sans avoir une
declaration de namespace explicite ce qui est un peu dommage.

> 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)?
> 

Pour l'instant using M = "   " me suffit: ajouter un using x n'est qu'un
simple extension que l'on pourra toujours rajouter si besoin est 


> 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. 

La priorite me parait evidente projet > user > global. C'est clair que
cela va compliquer le port soue Windows car il faudra faire ces modifs
dans la base de registres.

>  Le tout
> avec des variables d'environnement pour pouvoir changer les chemins
> hardcodés. 

Je pense qu'une seule variable suffira car sa definition determinera
aussi les priorites. Donc CDUCE_HOME ou CDUCE_LIB. Veut-on aussi un
CDUCE_LOCALLIB pour ~/.cduce? Je ne pense pas.

> 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), 

Peut etre la c'est encore trop. Si tu as 2 fichers dans lequels tu as
tous tes modules ca parait embetant devoir ecrire un troisieme ficher de
correspondance.

Il faudrait immaginer une programmation a 3 niveau (4 si on considere
les programmes sans modules).

Le premier niveau est celui ou le projet est si petit que il ne
necessite pas de table de correspondence, une syntaxe appropriee dans le
using qui fait l'escape du ficher de redirection. Je sais que ce n'est
pas uniforme mais ca risque d'etre le plus utilise.

Apres les deux autres niveau sont ce que tu dit.


> 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.
> 

On peut melanger le deux et au link detecter s'il existe un ficher
depend qui definit explicitement l'ordre

> À 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.
> 

Yep

> 
> Commentaires et suggestions bienvenus. Parlez maintenant ou ...
> 

... est-ce deja trop tard?

B.





More information about the Cduce-devel mailing list