ocamlc.opt (same options)
Le compilateur bytecode d'Objective Caml ocamlc(1) compile des fichiers sources en Caml et crée des fichiers objets de bytecode puis lie ces fichiers d'exécution pour produire des dossiers exécutables de bytecode autonome. Ces exécutables seront alors lancés par l'interpréteur de bytecode ocamlrun(1).
La commande ocamlc(1) a une ligne de commande d'interface semblable à celle de la plupart des compilateurs C. Elle accepte plusieurs types d'arguments et procède alors séquentiellement :
Les arguments finissant par .mli sont utilisés pour être des fichiers sources pour des interfaces de compilation. Les interfaces spécifient les noms exportés lors des compilations : ils déclarent des noms de valeur avec leurs types, définissent les types de données publics, déclarent les types de données abstraits, et ainsi de suite. À partir du fichier x.mli, le compilateur ocamlc(1) produit une interface compilée dans le fichier x.cmi.
Les arguments finissant par .ml sont utilisés pour être des fichiers sources pour l'implémentation lors de la compilation. Les implémentations produisent des définitions pour les noms exportés par le "unit" (à peu près le même rôle que void en C), et contiennent également des expressions qui devront être évaluées pour leurs effets secondaires.
À partir du fichier
x.ml,
le compilateur
ocamlc(1)
produit de l'objet bytecode dans un fichier
x.cmo.
Si le fichier d'interface
x.mli
existe, l'implémentation
x.ml
est vérifiée avec l'interface compilée correspondante à
x.cmi,
en supposant qu'il existe. Si aucune interface
x.mli
n' est fournie, la compilation de
x.ml
produit un fichier d'interface compilé
x.cmi
en plus du fichier objet compilé
x.cmo.
Le fichier
x.cmi
produit, correspond à une interface qui exporte tout ce qui est défini dans l'implémentation de
x.ml.
Les arguments finissant par .cmo sont utilisés pour être compilés avec le bytecode objet. Ces fichiers sont liés ensemble, avec les fichiers objets obtenus en compilant les arguments .ml (s'il y en a), et avec la bibliothèque standard de Caml Light afin de produire un fichier exécutable autonome. L'ordre dans lequel les arguments .cmo et .ml sont présentés sur la ligne de commande est essentiel: la compilation est initialisée dans l'ordre d'exécution, et c'est un lien à temps réel qu'utilise le unit avant de l'initialiser. C'est pourquoi un fichier donné x.cmo doit venir avant tous les fichiers de .cmo qui se rapportent au module x.
Les arguments finissant par .cma sont utilisés pour être bliothèques es d'objet bytecode.
Une bibliothèque d'objet bytecode regroupe en un seul fichier les fichiers objets bytecode (fichiers .cmo). Ces bibliothèques sont créées avec
ocamlc -a
(voir la description de l'option
-a
ci-dessous). Les fichiers objets contenus dans la bibliothèque sont liés comme des fichiers classique .cmo (voir ci-dessus), dans l'ordre spécifié lorsque le .cma a été construit. La seule différence est que si un fichier objet contenu dans une bibliothèque n'est pas référencé n'importe où dans le programme, alors il n'est pas lié.
Les arguments finissant par .c sont passés au compilateur C avec généralement des fichiers objets .o . Ce fichier objet est lié dans le programme si l'argument -custom est précisé (voir la description de -custom ci-dessous).
Les arguments finissant par .o ou .a sont utilisés comme fichiers objets C et bibliothèques C. Ils sont passés à l'éditeur de liens de C en liant avec le mode donné par : -custom mode (voir la description de -custom ci-dessous).
ocamlc.opt est le même compilateur qu' ocamlc, mais compilé avec le code natif du compilateur ocamlopt(1). Ainsi, il se comporte exactement comme ocamlc, mais compile plus rapidement. ocamlc.opt n'est pas disponible dans toutes les installations d'Objective Caml.
``custom runtime'' (voir l'option -custom ). Par exemple, -ccopt -L dir fait recherche le liens C de ses bibliothèques dans le répertoire dir.