caml-list - the Caml user's mailing list
 help / Atom feed
From: "Jocelyn Sérot" <>
To: Caml Mailinglist <>
Subject: Re: [Caml-list] A (silly ?) question about opam and ocamlfind
Date: Thu, 15 Aug 2019 08:26:57 +0200
Message-ID: <> (raw)
In-Reply-To: <>

Thanks for the answer and the « historical » perspective. 

In fact, I’ve started to use dune a few weeks ago and this is a problem with the transition from a package previously developed with ocamlfind to dune which triggers my initial question.

Anyway, after carefully re-reading the opam and dune documentation, i’ve finally fixed the problem.

I’m about to publish a small repository on github summerizing the solution(s) with the hope that it can  be useful to other programmers.


Le 14 août 2019 à 21:08, a écrit :

> Hello!
> The more tools are added on top of each others to make life easier for newcomers, and the harder it is to understand what's happening.
> So let's get back to the beginning. I'm assuming you know already most of this but I'd rather give a picture of the whole stack so that you know which documentation you need to read to learn the details about various steps.
> OCaml compiler without any other helper tool knows very little about where to find the files it needs.
> Following the tradition, it just knows one directory, where the system libraries are located. And it takes everything else from the command line: the inputs (some .ml, .cmx, .cmxa, .o, .a, etc files, some additional paths where to look for libraries if more are needed), and the single output (-o somefile).
> You can work only with this, that's very simple, but also quickly cumbersome as the number of libraries you need grow, each requiring other libraries and special options for the compiler, recursively.
> So at some point, you want a package manager: something that organise libraries in your local disk with some additional metadata about what depends on what, so that you only have to say "I want to link with the foobar, preferably the lwt variant".
> This is ocamlfind. To play by the rules, you have to install all the package in a given directory, with an additional small META file that contains the dependencies and various options and other meta data such as a unique name and a description.
> If library authors play by the rules and provide that META file and install their libraries in a standardized manner (which is greatly simplified by ocamlfind command line tool) then everything become as easy as `ocamlfind ocamlc -package 'foo bar baz'`.
> This is great and nice, and by and large OCaml library authors have played by the rules for a very long time now (such a tool, to be successful, have to be reliable and _stable_ for a long time ; ocamlfind have been very successful and essential to OCaml popularity, because it has stayed the same for many years ; thank you so much to its maintainers to resist the need to break backward compatibility).
> There is still an important annoyance though: for the above to work, you still need libraries foo, bar and baz to be downloaded, compiled, and installed on your local machine. For this, you need a standard package repository. This is OPAM. Opam also have it's small file with metainfo about each package, except this one is called "opam" (or "$package.opam") and states where to get the package from, what command to run to build it, and how to install it.
> Sounds familiar? Yes that's exactly what your Linux distribution does, but it works also on non-linux systems and is also updated much quicker, as there are less bureaucracy involved (notice it solves a human problem not a technical problem here).
> There is a bit of redundancy between ocamlfind and opam, because, despite ocamlfind being used by >90% of packages, opam is ocamlfind agnostic and can work, in theory, for non-ocamlfind packages (indeed, it can also be used to deploy about anything not only OCaml packages). So you have to give names, description, dependencies both to ocamlfind and opam.
> But that's only a minor annoyance.
> If it really bothers you, then you can use another tool on top of all that, such as dune, that will not only build your project but also write the META and the opam file for you (and more). With the risk that, if something fails at this point, you have all the above stack to unfold to understand what's happening.
> If you have read this far then maybe you are interested in the topic of software packaging and deployment.
> Then it must be mentioned that better, more sophisticated package managers do exist, which solve this whole problem once and for all, such as nix or guix, and that hopefully one day we will all abandon our compartmentalised solutions that are popular today and move on to the next level.

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 13:20 Jocelyn Sérot
2019-08-14 13:42 ` Kakadu
2019-08-14 19:08 ` rixed
2019-08-15  6:26   ` Jocelyn Sérot [this message]
2019-08-15  8:25   ` Malcolm Matalka

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

caml-list - the Caml user's mailing list

Archives are clonable:
	git clone --mirror
	git clone --mirror

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox