Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Xavier Leroy <xleroy@pauillac.inria.fr>
To: Emmanuel.Engel@lri.fr (Emmanuel Engel)
Cc: caml-list@pauillac.inria.fr
Subject: Re: Gestion des librairies
Date: Tue, 2 Dec 1997 16:03:27 +0100 (MET)	[thread overview]
Message-ID: <199712021503.QAA17807@pauillac.inria.fr> (raw)
In-Reply-To: <347C1631.7691@lri.fr> from Emmanuel Engel at "Nov 26, 97 01:29:37 pm"

>   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





      reply	other threads:[~1997-12-02 16:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-11-26 12:29 Emmanuel Engel
1997-12-02 15:03 ` Xavier Leroy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199712021503.QAA17807@pauillac.inria.fr \
    --to=xleroy@pauillac.inria.fr \
    --cc=Emmanuel.Engel@lri.fr \
    --cc=caml-list@pauillac.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox