Gestion des librairies

Gestion des librairies

[Emmanuel Engel]

Je  me pose une  question sur le  cout, en terme  de place, des gros
modules en Caml. 

  Dans  un langage de  programmation  comme C,  lorsque  l'on souhaite
ecrire  une librairie, une  bonne pratique est  de  mettre chacune des
fonctions  de la librairie  dans  un fichier  separe et de transformer
l'ensemble de  tous ce  fichiers en une  seule  unite a l'aide  de  la
commande  "ar".  L'interet, par rapport au  fait d'avoir tout mis dans
un  seul et meme fichier est   de permettre a   "ld" de ne mettre dans
l'executable final que les fonctions qui sont reellement utiles.

Pour Ocaml la situtation  est differente et pas  aussi favorable.  Une
telle pratique se heurte a la gestion  des modules en Ocaml (un module
doit  etre  defini dans  un seul  fichier). Supposons que  je souhaite
reimplementer   le module  list.   Suivant    le  meme principe    que
precedement, je vais mettre une fonction par fichier:

------- list_lenght.ml ------------
let rec length_aux len = function
    [] -> len
  | a::l -> length_aux (len + 1) l

let f l = length_aux 0 l
-----------------------------------

------- list_tl.ml ----------------
let f = ...
-----------------------------------

etc... 

Je me retrouve donc avec un module par fonction.   Pour voir mes liste
comme une seule  et meme librairie, je suis  ammene a  creer le module
suivant:

module List = 
  struct
   let length = List_length.f
   and tl     = List_tl.f
   and ....	
  end

et a engendrer la libraire (ocamlopt -a  -o list.cmxa ...) qui enferme
tous   les fichiers.    Notons   au  passage que   je suis   incapable
d'interdire l'acces direct au fonctions List_lenght.f List_tl.f etc...
Cela peut etre problematique si la librairie  defini un type abstrait:
pour que chaque  fonction de la librairie  puisse acceder librement et
concretement au type je  suis ammene a le  rendre publique et je n'ais
aucun moyen de la cacher par la suite.

Sur ce principe, je me pose plusieurs questions.

 1)  Quels sont  les  benefices  que   je peut   attendre d'une  telle
pratique?

 2)  N'est-il pas envisageable  que   le compilateur (natif) fasse  ce
genre de travail pour moi, au vol ? (i.e. genere un fichier assembleur
par fonction  et me  retourne  un couple  de fichier x.cmx/x.a  plutot
qu'un couple de  fichier x.cmx/x.o).  Cela presenterait  l'avantage de
cacher les  modules  List_lenght  List_tl   etc.... et  de   permettre
d'appliquer  la technique  a des  modules  qui  definissent des  types
abstraits.




-- 

- Emmanuel Engel

Re: Gestion des librairies

[Xavier Leroy]

>   Dans  un langage de  programmation  comme C,  lorsque  l'on souhaite
> ecrire  une librairie, une  bonne pratique est  de  mettre chacune des
> fonctions  de la librairie  dans  un fichier  separe et de transformer
> l'ensemble de  tous ce  fichiers en une  seule  unite a l'aide  de  la
> commande  "ar".  L'interet, par rapport au  fait d'avoir tout mis dans
> un  seul et meme fichier est   de permettre a   "ld" de ne mettre dans
> l'executable final que les fonctions qui sont reellement utiles.
> Pour Ocaml la situtation  est differente [...]

En fait, le linker OCaml fonctionne exactement comme le linker C:
lorsqu'on linke un fichier .cma regroupant A.cmo, B.cmo, etc,
il elimine les .cmo qui ne sont pas references dans le reste du
programme.  L'unite de linking est donc le fichier .cmo, tout comme en
C l'unite de linking est le fichier .o.

Ceci dit, meme en C, mettre une fonction par fichier .o est une
granularite trop faible.  Il est largement suffisant de mettre un .o
par groupe de fonctions logiquement reliees.  Vu la taille des disques
modernes, quelques kilo-octets de code mort ne font de mal a personne.

Autrement dit: le decoupage d'un programme en fichiers doit suivre sa
structure logique.  Il n'y a pas lieu de compliquer le decoupage pour
un hypothetique gain en taille du code.

>  1)  Quels sont  les  benefices  que   je peut   attendre d'une  telle
> pratique? [une fonction par fichier + un fichier reexportant le tout]

Aucune.  Le .cmo reexportant toutes les fonctions va etre lie des que
l'une de ses fonctions est referencee, entrainant tous les autres .cmo
avec lui.

>  2)  N'est-il pas envisageable  que   le compilateur (natif) fasse  ce
> genre de travail pour moi, au vol ? (i.e. genere un fichier assembleur
> par fonction  et me  retourne  un couple  de fichier x.cmx/x.a  plutot
> qu'un couple de  fichier x.cmx/x.o).

Cela couterait cher en temps de compilation: appels repetes de
l'assembleur, manipulations de nombreux petits fichiers.  Ceci pour un
benefice douteux.

- Xavier Leroy