From: Xavier Leroy <xleroy@pauillac.inria.fr>
Message-Id: <199712021503.QAA17807@pauillac.inria.fr>
Subject: Re: Gestion des librairies
In-Reply-To: <347C1631.7691@lri.fr> from Emmanuel Engel at "Nov 26, 97 01:29:37 pm"
To: Emmanuel.Engel@lri.fr (Emmanuel Engel)
Date: Tue, 2 Dec 1997 16:03:27 +0100 (MET)
> 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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:13 MET